[Tagging] RFC 2 - addr:interval

Mateusz Konieczny matkoniecz at tutanota.com
Fri Jan 8 07:00:09 UTC 2021


Nominatim interprets its as a single number (literal), as I understand from
https://github.com/osm-search/Nominatim/issues/565#issuecomment-272725116

It is used in actual tagging for both, sometimes with addr:interpolation on nodes
to indicate range (what is ignored by at least Nominatim)

Jan 8, 2021, 07:48 by pelderson at gmail.com:

> I did some overpass scans in my neighbourhood. Within a 10 Km radius from my home leaving out the hyphen and/or spaces would get you many errors.
> I think any range solution should leave the housenumber strings intact.  Adding special punctuation characters for added functionality should work, if it includes an easy escape for situations where reserved character is part of the number string.
>
> I still like to know how eg addr:housenumber=10-15 is generally interpreted now: single number (literal), range, or a mix of interpretations (aka chaos). 
>
> Peter Elderson
>
>
> Op vr 8 jan. 2021 om 00:23 schreef Jmapb <> jmapb at gmx.com> >:
>
>> On 1/7/2021 2:41 PM, Jmapb wrote:
>>  
>>  > Would it also be advantageous to assert that a range-like address is
>>  > not a range? I'd hope that, knowing that any hyphens found in a
>>  > housenumber are just for formatting, a geocoder could then index the
>>  > housenumber without hyphens. This would allow digit-only address
>>  > searches to work in Queens without requiring the correct hyphen
>>  > placement. Which would be good because it's not uncommon for
>>  > Queensians to omit the hyphen in both speech and writing. (This
>>  > currently works in Apple, Google, Here, and Bing maps, by the way.)
>>  >
>>  Been rethinking this and checking over the data. The suggestion (my
>>  suggestion) that geocoders index a de-hyphenated version of all
>>  non-range hyphenated addresses does not hold up under scrutiny.
>>  
>>  First of all, just looking in Queens, the hyphenated addresses are not
>>  all in the XX-YY or XXX-YY format. You'll see XX-Y or XXX-Y at start of
>>  some blocks. It looks like addresses where the post-hyphen portion is
>>  less than ten were padded with a zero when the addresses were applied to
>>  an entire imported building way, but not when the addresses were
>>  imported as a nodes, which was how multiple-address buildings were done.
>>  
>>  Eg, 65-1 174th Street >> https://www.openstreetmap.org/node/2552890712
>>  versus 65-04 174th Street >> https://www.openstreetmap.org/way/248516462
>>  
>>  In this context, indexing 65-04 as 6504 makes sense, indexing 65-1 as
>>  651 does not. In fact I think 65-1 and similar are probably errors, but
>>  that's going to take some more investigation.
>>  
>>  Second, scanning through the world beyond Queens, I see that it's not at
>>  all uncommon to have an address with a hyphenated numeric suffix. It's
>>  very common in the Netherlands. Here's an example, Utrechtseweg 13-9 in
>>  Hilvesum: >> https://www.openstreetmap.org/node/2878703055
>>  It's not a range (obviously) but I seriously doubt that it would be
>>  correct to index it as Utrechtseweg 139 -- especially since Utrechtseweg
>>  139 is down here: >> https://www.openstreetmap.org/node/2878370113
>>  
>>  I still feel it's a serious compromise in map usability to require
>>  correct hyphen placement to search Queens addresses (and apparently
>>  Apple, Google, Here, and Bing agree) but I don't know how best to crack
>>  this nut. The addr:interval proposal is a related issue, but it's not a
>>  complete solution.
>>  
>>  Jason
>>  
>>  
>>  _______________________________________________
>>  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/20210108/3d5db55f/attachment.htm>


More information about the Tagging mailing list