RFC 2 - addr:interval

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
68 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

RFC 2 - addr:interval

Tagging mailing list
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:

  1. The wiki page contains three "options" to chose from to help tag a range of addresses. Which one is the best? Please discuss.
  2. 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?
  3. How will this be implimented into software (e.g. geocoders like Nominatim)?

Thanks,
IpswichMapper


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: RFC 2 - addr:interval

Stefan Tauner
On Sun, 3 Jan 2021 17:23:42 +0100 (CET)
ipswichmapper--- via Tagging <[hidden email]> wrote:

> The wiki page

https://wiki.openstreetmap.org/wiki/Proposed_features/addr:interval

--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: RFC 2 - addr:interval

Tagging mailing list
has stray word in last line

Is it to be removed or unfinished?


Jan 3, 2021, 17:39 by [hidden email]:
On Sun, 3 Jan 2021 17:23:42 +0100 (CET)
ipswichmapper--- via Tagging <[hidden email]> wrote:
The wiki page

https://wiki.openstreetmap.org/wiki/Proposed_features/addr:interval

--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

_______________________________________________
Tagging mailing list
https://lists.openstreetmap.org/listinfo/tagging


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: RFC 2 - addr:interval

Tagging mailing list
I think that was meant to be an example of how to use the addr:housenumber:range tag. Don't know why that wasn't finished.

IpswichMapper 


3 Jan 2021, 16:42 by [hidden email]:
has stray word in last line

Is it to be removed or unfinished?


Jan 3, 2021, 17:39 by [hidden email]:
On Sun, 3 Jan 2021 17:23:42 +0100 (CET)
ipswichmapper--- via Tagging <[hidden email]> wrote:
The wiki page

https://wiki.openstreetmap.org/wiki/Proposed_features/addr:interval

--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

_______________________________________________
Tagging mailing list
https://lists.openstreetmap.org/listinfo/tagging



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: RFC 2 - addr:interval

Sarah Hoffmann
In reply to this post by Tagging mailing list
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: RFC 2 - addr:interval

Kevin Kenny-3
On Sun, Jan 3, 2021 at 12:07 PM Sarah Hoffmann <[hidden email]> wrote:
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.

The only significant use of hyphenated housenumbers that I'm aware of is in the Borough of Queens, New York City, where almost all addresses are XXX-YY, where XXX is the number of the cross street and YY is the housenumber on the block.  In that specific case, there's already been a comprehensive import of building footprints, with their addresses, so it's pretty much a non-problem there - there's no need for address interpolation. For that reason, I don't think there's a real need for interpolation between already-hyphenated housenumbers. Nevertheless, we need to avoid misinterpreting each of the tens of thousands of hyphenated housenumbers in that borough as ranges.  As long as there's a separate indication that the number is an interval, and it doesn't default to being an interval just because there's a hyphen, then I have no objection. 

-- 
73 de ke9tv/2, Kevin

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: RFC 2 - addr:interval

Tagging mailing list
In reply to this post by Sarah Hoffmann
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 [hidden email]:
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
https://lists.openstreetmap.org/listinfo/tagging


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: RFC 2 - addr:interval

Peter Elderson
In reply to this post by Tagging mailing list
I don't like the |-character for up to and including, because | is regularly used for OR. 

The usual character for a range is the hyphen. Anything else will lead to mapper errors, mixed use and other things causing uncertainty what was meant, hence guessing/extra processing at the data user side.

Irregular numberings with missing numbers, lettered subranges within ranges, I think you can only enumerate or map separate addresses.

Solution should leave installed base as intact as possible. No-one wants mass retagging. 

What is the problem? I think:
1. That the interval needs to be specified, 
2. Hyphens can be part of the numbers
3. Irregular ranges.

I think a range format is needed with format options. If all the options are left out, it's a simple range. 
It will need parsing, but a data use that doesn't parse is no worse off than now.

E.g. you could have the option that <start> and <end> may be quoted strings. For a simple range quotes are allowed but not necessary; if start or end contain a hyphen you better add quotes if you want it processed as a range.

Irregular ranges: enumerate witha specified sperator, e.g. semicolon. In Nederland we would use a comma in this type of list. 

Interval: I think default of 2 is not wise. The even/odd system applies mainly to streets, where every building has its own number and one side is even, the other is odd, but I think these simply should get there own address tag. Ranges apply to larger building and blocks, for which the even/odd numbering often doesn't apply.

So, default interval=1 is best I think.
Different intervals can be specified in a separate tag, or (while you are formatting/parsing anyway) be a part of the range string. E.g. (2) or ;2 at the end of the range string (separator should be different from enumeration separator)   

Maybe make spaces optional for readability?

Examples
15-20 = '15'-'25' = 15,16,17,18,19,20
15-25 (2) = '15'-'25' = 15,17,19,21,23,25
'123-15'-'123-21' (2)  = 123-15,123-17,123-19,123-21
10, 11a,11b,11c,12,14,

The instructions would be:
0. Use m-n for a simple range m up to n with interval 1 
1. Append (2) if the interval is 2 | append (n) if the interval is n 
2. quote <start> and <end> separately if they contain a hyphen;
3. For irregular not too long ranges (max ?), enumerate all using comma separation
4. Else no range spec is possible.

Peter Elderson


Op zo 3 jan. 2021 om 17:25 schreef ipswichmapper--- via Tagging <[hidden email]>:
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:

  1. The wiki page contains three "options" to chose from to help tag a range of addresses. Which one is the best? Please discuss.
  2. 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?
  3. How will this be implimented into software (e.g. geocoders like Nominatim)?

Thanks,
IpswichMapper

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: default surface was: RFC 2 - addr:interval

Tagging mailing list
In reply to this post by Tagging mailing list



Jan 3, 2021, 21:01 by [hidden email]:
Some tags give a default value (for example, with no surface tag it is assumed to be paved).
Nope, that is not always a reasonable assumption.

For example highway=track tracktype=grade5

On the other hand highway=motorway is safe to assume as paved

Data consumer is also allowed to not guess at all and handle "missing data"
as a special case.


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: RFC 2 - addr:interval

Minh Nguyen-2
In reply to this post by Peter Elderson
Vào lúc 12:33 2021-01-03, Peter Elderson đã viết:
> I don't like the |-character for up to and including, because | is
> regularly used for OR.
>
> The usual character for a range is the hyphen. Anything else will lead
> to mapper errors, mixed use and other things causing uncertainty what
> was meant, hence guessing/extra processing at the data user side.

In [1], I mentioned the use of | in the :lanes tagging scheme, but the
"OR" use in opening_hours hadn't occurred to me. That makes an even
stronger argument to avoid overloading this character. The operator " to
" (with a space on either side) is already being used in several keys as
an optional, unambiguous range operator where either end of the range
could contain a hyphen.

[1]
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/addr:interval#Alternatives_to_the_vertical_bar

--
[hidden email]


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: RFC 2 - addr:interval

Jmapb
In reply to this post by Kevin Kenny-3
On 1/3/2021 2:03 PM, Kevin Kenny wrote:

The only significant use of hyphenated housenumbers that I'm aware of is in the Borough of Queens, New York City, where almost all addresses are XXX-YY, where XXX is the number of the cross street and YY is the housenumber on the block.  In that specific case, there's already been a comprehensive import of building footprints, with their addresses, so it's pretty much a non-problem there - there's no need for address interpolation. For that reason, I don't think there's a real need for interpolation between already-hyphenated housenumbers. Nevertheless, we need to avoid misinterpreting each of the tens of thousands of hyphenated housenumbers in that borough as ranges.  As long as there's a separate indication that the number is an interval, and it doesn't default to being an interval just because there's a hyphen, then I have no objection.

Another wrinkle in the case of Queens (and possibly anywhere else that uses the hyphen as a column separator) is that people sometimes use the unhyphenated version of the address interchangeably. The addresses that were imported with the building footprints use the hyphenated form, but many locals write the address without it.

Eg:
https://www.openstreetmap.org/node/5559802016 addr:housenumber=57-44, website says 57-44
https://www.openstreetmap.org/node/5557465669 addr:housenumber=58-10, website says 5810

And the reverse can be true as well, eg https://www.openstreetmap.org/node/6389090010 gives its housenumber as 16-23 even though the official imported building address is 1623.

I've seen this inconsistency with physical housenumber signs as well, and on mail.

So an effective geocoder for Queens needs to know to search for 58-10 when 5810 is requested, and vice versa. And in spoken language the hyphen is often silent, so this has speech recognition implications as well.

A tag like addr:range/interval=no (mechanically added to tens of thousands of Queens addresses!) would allow a geocoder to index these housenumbers in both forms, or to index just the digit form and then strip hyphens from a search.

Alternatives offhand would be adding a digit-only duplicate address node inside each Queens building way, or inventing a tag like addr:alt_housenumber=, or a location-based hack (ie when looking for a 3+ digit housenumber in Queens, also search with a hyphen inserted before the final two digits) incorporated into every geocoding library. None of those ideas thrill me.

My personal feeling is that the "real" address is just the digits, and that the hyphen is a typographic convention, like using "," (or "." in Europe) as a thousands separator. Akin to how we can give pronunciation hints to a text-to-speech engine using *:ipa=, we could invent a tag to give typographical hints on how addresses should be formatted for display. But that won't stop people from manually mapping using the hyphen (because that's what listed on most physical address signs) so it's probably not a viable solution.

Jason


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: RFC 2 - addr:interval

Tagging mailing list
Solution for queens is actually quite simple to do automatically. Make a overpass query that finds all objects in with the "nycdoitt:bin" key and hypens in the housenumber.

Then simply add addr:interval=no

Make sure you get community approval obviously.

IpswichMapper

--
Sent with Tutanota, the secure & ad-free mailbox:
https://tutanota.com


5 Jan 2021, 17:11 by [hidden email]:
On 1/3/2021 2:03 PM, Kevin Kenny wrote:

The only significant use of hyphenated housenumbers that I'm aware of is in the Borough of Queens, New York City, where almost all addresses are XXX-YY, where XXX is the number of the cross street and YY is the housenumber on the block.  In that specific case, there's already been a comprehensive import of building footprints, with their addresses, so it's pretty much a non-problem there - there's no need for address interpolation. For that reason, I don't think there's a real need for interpolation between already-hyphenated housenumbers. Nevertheless, we need to avoid misinterpreting each of the tens of thousands of hyphenated housenumbers in that borough as ranges.  As long as there's a separate indication that the number is an interval, and it doesn't default to being an interval just because there's a hyphen, then I have no objection.

Another wrinkle in the case of Queens (and possibly anywhere else that uses the hyphen as a column separator) is that people sometimes use the unhyphenated version of the address interchangeably. The addresses that were imported with the building footprints use the hyphenated form, but many locals write the address without it.

Eg:
https://www.openstreetmap.org/node/5559802016 addr:housenumber=57-44, website says 57-44
https://www.openstreetmap.org/node/5557465669 addr:housenumber=58-10, website says 5810

And the reverse can be true as well, eg https://www.openstreetmap.org/node/6389090010 gives its housenumber as 16-23 even though the official imported building address is 1623.

I've seen this inconsistency with physical housenumber signs as well, and on mail.

So an effective geocoder for Queens needs to know to search for 58-10 when 5810 is requested, and vice versa. And in spoken language the hyphen is often silent, so this has speech recognition implications as well.

A tag like addr:range/interval=no (mechanically added to tens of thousands of Queens addresses!) would allow a geocoder to index these housenumbers in both forms, or to index just the digit form and then strip hyphens from a search.

Alternatives offhand would be adding a digit-only duplicate address node inside each Queens building way, or inventing a tag like addr:alt_housenumber=, or a location-based hack (ie when looking for a 3+ digit housenumber in Queens, also search with a hyphen inserted before the final two digits) incorporated into every geocoding library. None of those ideas thrill me.

My personal feeling is that the "real" address is just the digits, and that the hyphen is a typographic convention, like using "," (or "." in Europe) as a thousands separator. Akin to how we can give pronunciation hints to a text-to-speech engine using *:ipa=, we could invent a tag to give typographical hints on how addresses should be formatted for display. But that won't stop people from manually mapping using the hyphen (because that's what listed on most physical address signs) so it's probably not a viable solution.

Jason



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: RFC 2 - addr:interval

Jmapb


On 1/5/2021 12:32 PM, ipswichmapper--- via Tagging wrote:
Solution for queens is actually quite simple to do automatically. Make a overpass query that finds all objects in with the "nycdoitt:bin" key and hypens in the housenumber.

Then simply add addr:interval=no

That's not the approach I'd recommend. The nycdoitt:bin tag is only present on imported buildings, but presumably hand-mapped buildings and POI nodes with hyphen addresses would get the same tag. I'd probably just start with geocodeArea:Queens. Also I'd definitely want a check in place to manually examine the edge cases that could conceivably be real address ranges.

This is all if, of course, this new tag is approved... And if there's community buy-in, which would probably only happen if the presence of this tag was generally understood to be advantageous to geocoding software.

J


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: RFC 2 - addr:interval

dieterdreist
as I have stated before, I would be interested in a tag that helped me formalize a description for the following situation:

1. posted housenumbers (for entrances and shop windows): 1 and 3 and 5 (individually)

2. business located at all of these addresses uses as address a housenumber range like 1-5 or 1/3/5

I am mapping the individual numbers at their spots, which is probably uncontested and without alternatives. Then I was using the combined address on the POI as advertised by them (in addr:housenumber). I was usually unsure how to do the range, and either copied literally what they used, or made semicolon separated lists. The former has the problem of inconsistent notation (different separators, hyphen notation leaving it unclear whether it is only even/odd numbers or both, and which numbers are existing (whether in 1-5 there’s maybe also a 3a hiding), the latter makes us loose the connection to what the POI uses as address, and may look confusing if presented to data users (semicolons do not typically appear in housenumbers around here)

Cheers Martin


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: RFC 2 - addr:interval

SimonPoole
In reply to this post by Tagging mailing list

Changing semantics for an existing widely unstructured tag (addr:housenumber) is a really bad idea (not to mention one of the most used ones). It really doesn't matter if you are using | - or any other character for the additional information it just isn't going to end well. In this case it is even more absurd because in practical terms (OSMOSE, OSMI etc) even the simple list form of addr:housenumber is disputed (with , or ; as delimiter).

To lighten things up though https://twitter.com/sp8962/status/617622144625831936 

Am 03.01.2021 um 17:23 schrieb ipswichmapper--- via Tagging:
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:

  1. The wiki page contains three "options" to chose from to help tag a range of addresses. Which one is the best? Please discuss.
  2. 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?
  3. How will this be implimented into software (e.g. geocoders like Nominatim)?

Thanks,
IpswichMapper


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

OpenPGP_signature (505 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC 2 - addr:interval

Jmapb
On 1/6/2021 5:12 AM, Simon Poole wrote:

> Changing semantics for an existing widely unstructured tag
> (addr:housenumber) is a really bad idea (not to mention one of the
> most used ones). It really doesn't matter if you are using | - or any
> other character for the additional information it just isn't going to
> end well. In this case it is even more absurd because in practical
> terms (OSMOSE, OSMI etc) even the simple list form of addr:housenumber
> is disputed (with , or ; as delimiter).
>
> To lighten things up though
> https://twitter.com/sp8962/status/617622144625831936
>
Well that's pretty damn funny!

We want a lot of different things out of our address tagging:

1 - Accurately map the observable world by tagging an element -- or part
of a more complicated element, like a building with multiple entrances
-- with its signed address(es).
2 - Reflect official government-issued addresses.
3 - Accurately indicate the addresses (sometimes signed, sometimes
discovered by other means) of sub-elements, like businesses and other
POIs in a building. (Some mappers desire to enumerate individual units
in residential buildings as well.)
4 - Give geocoders all the information they need to correctly position a
requested address, even when the housenumber isn't a
character-for-character match with a tagged housenumber.
5 - Allow mapping software to present a simple interface for casual
mappers to add and edit addresses.

And of course the addresses in 1, 2, and 3 might not all agree. And
their housenumbers might be atomic or might be ranges. And some atomic
housenumbers might look like ranges (eg in Queens NY.)  And an actual
housenumber range may sometimes function as an atomic housenumber (eg a
single business whose address is 10-14 Main Street.)

The current rough consensus on address tagging (which I guess is
basically the Karlsruhe schema) is often adequate, but there are a lot
of corner cases on this hypercube, and some affect millions of people.
We might not be able to nail them all down, but it would be great to
document examples of currently problematic situations and how best to
tag them. If there are viable solutions that don't require changing the
generally understood semantics of the addr:housenumber tag, that would
of course be hugely preferable!

Jason



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: RFC 2 - addr:interval

Marc_marc
Hello,

Le 06.01.21 à 17:34, Jmapb a écrit :
> there are a lot of corner cases
> affect millions of people.

can you list some "real world" issues are your trying to fix and
currently unable to fix with the existing schema ?
i'm reading
https://wiki.openstreetmap.org/wiki/Proposed_features/addr:interval and
didn't find any
of course if you use addr:housenumber=1-5 for "even number from 1 to 5",
that's a very bad idea
addr:housenumber=1;3;5 fix that that wihout the need of adding
addr:interval=2 or addr:interval=even for that

let's try to avoid having one additional standards to fill multiple addr
https://imgs.xkcd.com/comics/standards.png

PS: "changes needed" section is full of "not under your control" stuff.
it usually lists all wiki pages that need to be modified, any accepted
proposal could list "all tools using this data must be modified" and
that users may use it, that's not the purpose of this section

Regards,
Marc



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: RFC 2 - addr:interval

Tagging mailing list
Right now it is unclear is addr:housenumber=1-31 used in meaning
"addresses 1, 2, 3, 4, 5, ... to 31" or "single address '1-31'".

There is no way to specify this, and both meanings are in use.


Jan 6, 2021, 18:10 by [hidden email]:
Hello,

Le 06.01.21 à 17:34, Jmapb a écrit :
there are a lot of corner cases
affect millions of people.

can you list some "real world" issues are your trying to fix and
currently unable to fix with the existing schema ?
i'm reading
https://wiki.openstreetmap.org/wiki/Proposed_features/addr:interval and
didn't find any
of course if you use addr:housenumber=1-5 for "even number from 1 to 5",
that's a very bad idea
addr:housenumber=1;3;5 fix that that wihout the need of adding
addr:interval=2 or addr:interval=even for that

let's try to avoid having one additional standards to fill multiple addr
https://imgs.xkcd.com/comics/standards.png

PS: "changes needed" section is full of "not under your control" stuff.
it usually lists all wiki pages that need to be modified, any accepted
proposal could list "all tools using this data must be modified" and
that users may use it, that's not the purpose of this section

Regards,
Marc



_______________________________________________
Tagging mailing list
https://lists.openstreetmap.org/listinfo/tagging


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: RFC 2 - addr:interval

Marc_marc
1) witch osm object ? I'm looking for real issue, not theoretical.

2) one object with number from 1 to 31 exist or it's tagging error ?
fetching some items from https://overpass-turbo.eu/s/125J
i currently only find tagging error like
https://www.openstreetmap.org/way/97836854

3) *if* it exist, explicit listing odd numbers from 1 to 31 avoid to be
unclear. so by not using intervals in addr:housenumber, this exemple
isn't a problem.

so i'm still looking for reals exemples that can't be fixed with
addr:housenumber without addr:interval

Le 06.01.21 à 18:28, Mateusz Konieczny via Tagging a écrit :
> Right now it is unclear is addr:housenumber=1-31 used in meaning
> "addresses 1, 2, 3, 4, 5, ... to 31" or "single address '1-31'".
>
> Jan 6, 2021, 18:10 by [hidden email]:
>
>     can you list some "real world" issues are your trying to fix and
>     currently unable to fix with the existing schema ?



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: RFC 2 - addr:interval

Jmapb
In reply to this post by Tagging mailing list
On 1/6/2021 12:28 PM, Mateusz Konieczny via Tagging wrote:

> Right now it is unclear is addr:housenumber=1-31 used in meaning
> "addresses 1, 2, 3, 4, 5, ... to 31" or "single address '1-31'".
>
> There is no way to specify this, and both meanings are in use.

Example -- 1-31 Helen Drive Middletown NY
https://www.openstreetmap.org/way/694324667

Nominatim currently processes this as both a single atomic address
(1-31) and as a two-element list (1; 31). Searching for 1-31 Helen
Drive, 1 Helen Drive or 31 Helen Drive will find this building, but
searching for 3 Helen Drive will not. (Nominatim does get close because
it's a pretty short street.)

And I don't think Nominatim's behavior is wrong here because there's no
information about how to interpolate the bounds. Is it all numbers, or
just odds? As it happens there's another building tagged 8-32 Helen
Drive across the way, so probably it should be odds. But there's no
currently documented way to specify that.

I've addressed situations like this with hacky mapping like
https://www.openstreetmap.org/way/767379647 -- an address interpolation
way inside a building way to match all even addresses between 174 and
190, positioned behind an entrance node tagged with the signed address,
174-190. It's ugly but it works. Can we do better than that with current
tags? Could any new tagging schemes help, without breaking current
functionality?

Jason


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
1234