[Tagging] RFC 2 - addr:interval

Peter Elderson pelderson at gmail.com
Fri Jan 8 20:37:30 UTC 2021

Only a positive integer between round brackets at the end of the string,
and a single hyphen.
So the examples you found do not qualify. Sorry, no cigar (yet?)

Peter Elderson

Op vr 8 jan. 2021 om 15:13 schreef Kevin Kenny <kevin.b.kenny at gmail.com>:

> On Fri, Jan 8, 2021 at 6:35 AM Paul Allen <pla16021 at gmail.com> wrote:
>> On Fri, 8 Jan 2021 at 08:30, Peter Elderson <pelderson at gmail.com> wrote:
>>> In this area, (n)  at the end of the housenumber string where n must be
>>> a positive integer value, could be used as a range indicator, without
>>> altering anything to current handling by Nominatim.
>>> Combine that with the requirement of a hyphen in the same string, and I
>>> bet that not many single housenumbers will pass that filter, worldwide
>>> (that's a challenge!)
>> There will probably be one.  And Kevin Kenny will know it. :)
> Is that a challenge?  :)
> I'm confining my search to North America.  (I don't host the planet
> locally, and haven't worked out a way to ask one of the hosted DB's that
> won't cause heartburn.)
> There is a pile of them in Natick, Massachusetts around
> https://www.openstreetmap.org/#map=19/42.27386/-71.35541, but those came
> in on an import and are pretty obviously mistagged.
> Two in Monterrey, Mexico https://www.openstreetmap.org/way/508834313 and
> https://www.openstreetmap.org/way/511821334 that I'm not sure what to
> make of.
> That's it for hyphens-in-round-brackets on this continent.
> We might be close to an answer I could live with. If we adopted a
> convention that `(start:stop)` and `(start:stop:increment)` denote address
> ranges (I'm using Python-like syntax within the parentheses), that wouldn't
> really collide with anything.
> I'm willing to concede even that we don't need address ranges for Queens
> addresses, since the buildings are already mapped. I'm not eager to
> introduce complexity for handing a range like 123-09 to 123-15.
> There are some areas in the west suburbs of Chicago, which I haven't found
> mapped on a quick troll through OSM, but peeked at in G**gl* to refresh my
> memory, where the addresses take the form xxNyyy, xxWyyy or xxSyyy (no E,
> the system doesn't go past 0W).  Addresses near the north/south baseline
> can have housnumbers like 0N020, which confuses even G**gl*''s geocoder.  I
> see them appearing in that map with several different formats (0N020, N020,
> N20, or 20), even in the same subdivision where I'm sure they're uniform.
> I'm more than willing to accept that layering address ranges atop that mess
> is a bridge too far, and settle for commoner cases.  We can always fall
> back on enumerating the individual addresses as we do today.
> I don't have any idea what to do with house numbering in locales that use
> different forms for the digits (Arabic, Thai, ...) or that express the
> numbers in non-Indo-Arabic systems. But I'm perfectly happy to have that be
> someone else's proposal when and if there's demand for it.
> There's a distinct chicken-and-egg aspect to this. Geocoders aren't going
> to trouble to implement it until the data are there, and mappers who want
> their addresses to be interpreted correctly by geocoders will resort to
> enumerations with semicolons.
> --
> 73 de ke9tv/2, Kevin
> _______________________________________________
> 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/9d2fc6d8/attachment-0001.htm>

More information about the Tagging mailing list