GIS
› OpenStreetMap
› General
›
Tagging
RFC 2 - addr:interval
Locked
1234
1234
 
|
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:
Thanks, IpswichMapper _______________________________________________ Tagging mailing list [hidden email] https://lists.openstreetmap.org/listinfo/tagging |
|
|
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 |
Re: RFC 2 - addr:interval
|
|
has stray word in last line Is it to be removed or unfinished? Jan 3, 2021, 17:39 by [hidden email]:
_______________________________________________ Tagging mailing list [hidden email] https://lists.openstreetmap.org/listinfo/tagging |
Re: RFC 2 - addr:interval
|
|
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]:
_______________________________________________ Tagging mailing list [hidden email] https://lists.openstreetmap.org/listinfo/tagging |
|
|
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 |
|
|
On Sun, Jan 3, 2021 at 12:07 PM Sarah Hoffmann <[hidden email]> wrote: Implementing a simple numberical interval is just a question 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 |
Re: RFC 2 - addr:interval
|
|
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]:
_______________________________________________ Tagging mailing list [hidden email] https://lists.openstreetmap.org/listinfo/tagging |
|
|
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]>:
_______________________________________________ Tagging mailing list [hidden email] https://lists.openstreetmap.org/listinfo/tagging |
Re: default surface was: RFC 2 - addr:interval
|
|
In reply to this post by Tagging mailing list
Jan 3, 2021, 21:01 by [hidden email]:
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 |
|
|
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 |
|
|
In reply to this post by Kevin Kenny-3
On 1/3/2021 2:03 PM, Kevin Kenny wrote:
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: 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 |
Re: RFC 2 - addr:interval
|
|
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]:
_______________________________________________ Tagging mailing list [hidden email] https://lists.openstreetmap.org/listinfo/tagging |
|
|
On 1/5/2021 12:32 PM, ipswichmapper---
via Tagging wrote:
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 |
|
|
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 |
|
|
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:
_______________________________________________ Tagging mailing list [hidden email] https://lists.openstreetmap.org/listinfo/tagging |
OpenPGP_signature (505 bytes) |
|
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 > 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 |
|
|
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 |
Re: RFC 2 - addr:interval
|
|
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]:
_______________________________________________ Tagging mailing list [hidden email] https://lists.openstreetmap.org/listinfo/tagging |
|
|
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 |
|
|
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 |
«
Return to Tagging
|
1 view|%1 views
| Free forum by Nabble | Edit this page |