[Tagging] Feature Proposal - RFC - addr:interpolation on closed ways and nodes
Mateusz Konieczny
matkoniecz at tutanota.com
Wed Dec 23 19:46:43 UTC 2020
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
>>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20201223/c66b71f2/attachment.htm>
More information about the Tagging
mailing list