[Tagging] RFC 2 - addr:interval

[Kevin Kenny]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20210108/32d4ec9f/attachment.htm>