[Tagging] RFC 2 - addr:interval

[ipswichmapper at tutanota.com]

The "geocoders should guess" section only applies when an addr:interval tag hasn't been specified. In this case, I have decided that there should be no "default value" of addr:interval, but rather geocoders can either guess if it is a range/single address or they can simply not do ranges at all.

I have updated the wiki page to make this clearer. 

Furthermore, I think this should be in the proposal, because I proposal also describes what happens if the tag is absent. Some tags give a default value (for example, with no surface tag it is assumed to be paved).

>  I doubt, though, that more complex intervals like
the 190-10|190-20 would ever get implemented. It's complex and
again involves some guessing about which part actually contains
the interval. There would have to be several thousands of uses
to make it worthwile. I'd strongly recommend just sticking with
mapping one address point per address in these cases instead of
getting carried away with defining some complex format.


I have updated to wiki page to clarify that there are two sections of this proposal:

1. The main section "addr:interval"
2. The additional section with the three options.

If you look at the page now you can see the two sections very clearly.

We could choose one of the tagging schemes from the second section. Or, the second section could be completely scraped, and if you want to interpolate hypenated addresses, you create two nodes (lowest hypenated address and highest hypenated address) and draw an addr:interpolation line between them. That should solve that problem.

What are people's thoughts? If enough people think it is a good idea, the second section could be scrapped completely. This does mean, however, that you will have to use addr:interpolation if you want to imply a range of hyphenated addresses.

Thanks,
IpswichMapper
-- 
 


3 Jan 2021, 17:05 by lonvia at denofr.de:

> On Sun, Jan 03, 2021 at 05:23:42PM +0100, ipswichmapper--- via Tagging wrote:
>
>> Hello,
>>
>> This is another RFC for the proposal "addr:interval". This page has been moved twice, and has changed significantly from the original proposal. Since discussion has stagnated a bit, I have decided to create a new RFC with specific goals in mind:
>>
>> The wiki page contains three "options" to chose from to help tag a range of addresses. Which one is the best? Please discuss.
>>
>
> I really don't like the paragraph about what geocoders should
> 'guess'. A tag proposal should give clear guidelines to mappers
> and data consumers what effect the tag has. If a data consumer
> wants to do guessing that's there choice but guessing shouldn't
> be codified in the wiki.
>
>> Are there any more simple options (other than the three on the wiki page) so to discern between single housenumbers that contain hypens and a range of addresses?
>> How will this be implimented into software (e.g. geocoders like Nominatim)?
>>
>
> Implementing a simple numberical interval is just a question
> of doing it. I doubt, though, that more complex intervals like
> the 190-10|190-20 would ever get implemented. It's complex and
> again involves some guessing about which part actually contains
> the interval. There would have to be several thousands of uses
> to make it worthwile. I'd strongly recommend just sticking with
> mapping one address point per address in these cases instead of
> getting carried away with defining some complex format.
>
> So given that. addr:housenumber=<from>-<to> when addr:interval
> is present, is currently my favourite. It has the big advantage
> that it is both human and machine readable. Renderers who only
> want to display house nubmers don't need to care about addr:interval
> at all and leave it to humans to figure out what is meant. For
> those who do care about individual addresses, the format is simple
> enough to parse. The default for addr:interval should be 'no'
> because that's what most addr:housenumber are.
>
> Sarah
>
> _______________________________________________
> 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/20210103/350122b2/attachment-0001.htm>