[Tagging] RFC 2 - addr:interval
pla16021 at gmail.com
Fri Jan 8 14:43:54 UTC 2021
On Fri, 8 Jan 2021 at 14:13, Kevin Kenny <kevin.b.kenny at gmail.com> wrote:
> On Fri, Jan 8, 2021 at 6:35 AM Paul Allen <pla16021 at gmail.com> wrote:
>> There will probably be one. And Kevin Kenny will know it. :)
> Is that a challenge? :)
Not a challenge. An invitation to share your knowledge. I know that, no
matter how much research I have done on a subject and how much
thought I have given it, you are capable of producing a dissertation
on it with little or no further research. Some people use Google to
find out more, I give you a prod. :)
> 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.
Given that a lot of the houses have the name "Casa" I suspect the mapper
wasn't very familiar with OSM conventions.
> 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),
Semicolons are used for that purpose in other languages, also serve as
a delimiter in other OSM values, and are less likely to be used to construct
> 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 think that we'll have to draw a line somewhere otherwise we end up
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.
I think the opinion of geocoders regarding feasibility of our suggestions
be given a lot of weight. If they say they refuse to handle something we
regard it as not being viable.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging