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@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 t...@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@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@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 lon...@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 lon...@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@openstreetmap.org >>> > https://lists.openstreetmap.org/listinfo/tagging >>> > >>> _______________________________________________ >>> Tagging mailing list >>> Tagging@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/tagging >>> >>> >>> _______________________________________________ >>> Tagging mailing list >>> Tagging@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/tagging >>> > >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
