[Tagging] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

Wed Dec 23 20:06:53 UTC 2020

Vertical bar character is already in use for turn lanes[1]. Not a big deal to type it, at least on a US keyboard. Certainly easier to type it than to enter two key/value pairs for the same information. Seems like a poor reason to avoid it since it is one of the few characters that seems unlikely to exist on an address in the wild.

[1] https://wiki.openstreetmap.org/wiki/Key:turn#Turning_indications_per_lane

> On Dec 23, 2020, at 11:46 AM, Mateusz Konieczny via Tagging <tagging at openstreetmap.org> wrote:
> 
> I am not so happy about it.
> 
> Typing that would be extremely unnatural.
> 
> Maybe better have additional add:range:from= addr:range:to=
> for ranges?
> 
> Dec 23, 2020, 20:10 by tagging at openstreetmap.org:
> Im gping to update the proposal tonight, when I have time.
> 
> I currently think suggesting a new character, | , used to explicitally specify ranges. The advantage of this is that ypu can interpolation hypenated addresses, e.g. :
> 
> addr:housenumber="19-100|19-200"
> 
> Would imply : 19-100, 19-102, 19-104, 19-106 etc.
> 
> Renderers can use "19-100 to 19-200"
> 
> Hypens would be accepted, but this is clearer.
> 
> The problem is that now you will have to get every single renderer and geocoder to understand this (which will take months ,even years).
> 
> 
> 
> --
> 23 Dec 2020, 16:29 by lonvia at denofr.de:
> On Mon, Dec 21, 2020 at 07:05:10PM +0100, ipswichmapper--- via Tagging wrote:
> Okay. In this case I can rename to proposal page to "addr:range".
> 
> This new tag:
> 
> - applies to nodes and closed ways that have addr:housenumber
> - "addr:range=n" means every nth house is counted in a range
> - "addr:range=even/odd" means every even/odd house is counted
> - "addr:range=all" means every house is counted (default value for a housenumber tag with a hyphen in it if no range is given).
> - "addr:range=no" means that the housenumber tag is NOT a range of values but rather a single housenumber.
> 
> It's better. It would resolve half the issue. addr:housenumber would still
> have a double interpretation but it's the smaller of the two issues.
> 
> addr:housenumber:range would capture a bit better what the tag means
> but it starts to get uncomfortably long.
> "addr:range=all" is the default because that is what the wiki says and what software like streetcomplete suggests. Many buildings with multiple housenumbers are tagged like this.
> 
> That would only make sense, when you define addr:range as being
> applicable to housenumbers with hyphens only. However your definition
> above was imo more sensible:
> "applies to nodes and closed ways that have addr:housenumber"
> 
> If you look at all nodes and ways with addr:housenumbers 99.999% have
> a addr:range=no. So that makes more sense as a default then.
> However, software can create different defaults for different countries. For example, in the UK a hypenated address most probably means a range of even/odd addresses (so "addr:range=2")
> 
> What are your thoughts on this?
> Also, I had linked the talk-gb thread, which discusses how addr:interpolation on closed ways and nodes is already standard. That is the problem with suggesting a new tag. This proposal would now require informing multiple mappers to switch up the taggong scheme.
> 
> My guess would be that the main reason that people started using the
> hyphen notation with addr:housenumber is that they wanted something
> human readable on the map. And addr:housenumber was already rendered.
> 
> With that in mind, I think there is a reasonable way forward even for
> a addr:range tag as you suggest and also for a separate
> addr:housenumber_range=1-15 like I would prefer. For both it is relatively
> easy to support a new agreed on proposal while still using the old
> behaviour where the new one is not yet implemented. So the transition would
> be:
> 
> 1. Agree on proposal.
> 2. Get openstreetmap-carto, Nominatim and others to support new proposal.
> 3. Tell mappers about proposal.
> 4. Wait a few years.
> 5. Drop support for addr:housenumbers with interpolations.
> 
> Sarah
> 
> Thanks,
> IpswichMapper
> --
> 
> 
> 21 Dec 2020, 15:19 by lonvia at denofr.de:
> 
> > On Mon, Dec 21, 2020 at 02:37:08PM +0100, ipswichmapper--- via Tagging wrote:
> >
> >> https://wiki.openstreetmap.org/wiki/Proposed_features/addr:interpolation_on_closed_ways_and_nodes
> >>
> >> Quick proposal I just created to accept this form of tagging. This follows from a discussion on the Talk-GB mailing list.
> >>
> >> https://lists.openstreetmap.org/pipermail/talk-gb/2020-December/025553.html
> >>
> >>
> >> Please comment if there are issues with accepting this form of tagging.
> >>
> >
> > I dislike this kind of tagging to the point that I've refused to
> > support it in Nominatim in the past. See
> > https://github.com/osm-search/Nominatim/issues/565 for the full disucssion.
> >
> > The problem is that it makes the interpretation of addr:housenumber and
> > addr:interpolation dependent on the presence of another tag.
> >
> > Note that addr:housenumber=40-48 can be a valid housenumber. Example:
> > https://www.openstreetmap.org/way/285077586 So to know if the tag needs
> > to be interpreted as a single housenumber or as a housenumber range
> > you need to check if the node/way has a addr:interpolation tag in addtion
> > to the addr:housenumber tag.
> >
> > Similarly, a way with addr:interpolation needs to be processed in two
> > different ways: If a addr:housenumber is present, then assume it's a
> > building and parse the addr:housenumber tag to get the range. If no
> > housenumber is on the way, assume it is a good old interpolation line
> > and look at the housenumbers along the nodes of the way.
> >
> > I find this kind of double meaning for tagging confusing and error-prone.
> > But I might be fighting wind mills here.
> >
> > Sarah
> >
> >
> > _______________________________________________
> > Tagging mailing list
> > Tagging at openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> >
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 
> 
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20201223/257e6856/attachment.sig>