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

ipswichmapper at tutanota.com ipswichmapper at tutanota.com
Wed Dec 23 23:15:53 UTC 2020


Yeah, the "hypens are still allowed" bit was after a sentence in brackets, so it was easy to miss.
--- 


23 Dec 2020, 23:10 by matkoniecz at tutanota.com:

> Sorry, you are right.
>
> I added an example to stop such dumb misinterpretation.
>
> Feel free to revert this and other edits that I made on your proposal
> https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/addr:range&diff=2076334&oldid=2076333
>
>
> Dec 24, 2020, 00:01 by ipswichmapper at tutanota.com:
>
>> It says in the proposal the the vertical bar is an alternative. You can still use hypens, however vertical bar is more explicit. With a addr:range however hypens should be enough.
>>
>> -- 
>>
>>
>> 23 Dec 2020, 22:59 by tagging at openstreetmap.org:
>>
>>> As I understand, it would mean that 40-48 range would need to be
>>> recorded as addr:housenumber=40|48 rather than more natural
>>> addr:housenumber=40-48
>>>
>>> Dec 23, 2020, 21:06 by tod at fitchfamily.org:
>>>
>>>> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20201224/c3956419/attachment.htm>


More information about the Tagging mailing list