[Tagging] RFC 2 - addr:interval

Kevin Kenny kevin.b.kenny at gmail.com
Fri Jan 8 16:13:49 UTC 2021


On Fri, Jan 8, 2021 at 10:45 AM Sarah Hoffmann <lonvia at denofr.de> wrote:

> Even with an extra tag, parsing of complexer examples is unlikely to
> happen unless there is a) a significant use with cases that cannot
> be mapped as addr:interpolation or separate address points and b)
> the parsing doesn't involve guessing again. The current proposals
> don't really meet b) yet. (Bonus points, if it also covers alphabetic
> ranges: 13a-f) And I have no idea how many cases of a) really exist.
>

I don't actually know whether https://www.openstreetmap.org/way/491160765
would fit your definition or not.

The reason that it's not mapped with separate address points is that I have
no idea where to place them.  The units share a common entrance (with all
eight housenumbers on the doorposts). The common entrance is a security
door with bells for the eight units. There was no real opportunity to
wander about and discern the layout of the individual units. (But they are
addressed as '501 Connor Court', etc.)

And, in fact, I'm not too dissatisfied with the current tagging - except
for rendering. I know that it's a common mistake here to simply wave one's
hands and talk about a 'sufficiently smart renderer', but I actually do
think that a renderer at least in theory could take a consecutive sequence
like this and decide to render it as a range. - and this would be
preferable to doing any change to the data model that will break things.

Regarding the current interpretation of addr:housenumber, I am firmly
> in the camp that its current definition of the tag is that of a single
> housenumber and that those who already have been putting intervals into
> it have been abusing it. So, while I'd be fine implementing the current
> proposal of 'addr:interval' together with the limited version of
> '<from>-<to>', Nominatim would then always interpret the absence of
> addr:interval as a 'no' because that is the only interpretation that
> is backward compatible with the current running definition.
>

Entirely sensible. Thank you for not breaking Queens.

-- 
73 de ke9tv/2, Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20210108/9b5cd57b/attachment.htm>


More information about the Tagging mailing list