OpenStreetMap

d1g's Diary

Is there possibility to retag addr:housenumbers without european scheme? (updated)

Posted by d1g on 27 February 2016 in English.

One example would be “addr:housenumber”=”6212” http://overpass-turbo.eu/s/eEp

  • 6212 in 60 meters from 1403 (and also different streets)
  • Buildings in Ausin,TX follow odd/even rule but housenumbers start from 6K: 6212 6212 6212 - unless buildings were demolished, all streets in Europe start with 1 or 2… But not 6200 or similar

all of them are absolutely chaotic (to a typical European person) and different from this picture: or even this picture:

There http://taginfo.openstreetmap.org/keys/addr%3Aconscriptionnumber#map but what tag to use in US?

https://en.wikipedia.org/wiki/House_numbering#North_America addressing is very different from European. IMO we should develop geocoders with respect to European style and NA style (mix of grid and proximity and some European rules). By this, I mean sophisticated rules for European scheme AND sophisticated rules to NA scheme. But not rules that can process all addr:housenumbers with respect to all addressing styles (they will be overcomplicated with special cases for every territory or dumb and simply process housenumbers as text).

I think easiest way to get better software and development process is to use separate tags and NOT leave this mess to data consumers under “addr:housenumber” sauce. Another example of this mess would be in https://en.wikipedia.org/wiki/House_numbering#Portugal:

In Portugal, the European scheme is the most commonly used house numbering style. However, in Porto and several other cities in the Portuguese Northern region, houses are numbered in the North American style, with the number assigned being proportional to the distance in meters from the baseline of the street.

Location: Jewell County, Kansas, United States

Discussion

Comment from Sanderd17 on 27 February 2016 at 13:32

Europe also has some distance based numbers. You mention Portugal, but I know several villages in France that also use that schema.

Then there are also streets where numbers take “jumps” on crossings. Not often by 100, but rounding up to the nearest multiple of 10 happens sometimes (note that in taginfo, the numbers 10, 20, 30 are also everytime more popular than 9, 19, 29, which shows my point).

Then we also have things like bis-numbers. Where houses are build between adjecent numbers (f.e. new houses between 29 and 31), and the number gets an extra letter (29A, 29B, 29C, …).

Housenumbers in Europe are far from uniform. and I really see no reason why the US addressing should be handled that much differently. There are small differences between countries. And yes, starting with 6200 isn’t something I’ve seen before in Europe. But I doubt it’s different enough to need a new schema.

Comment from d1g on 27 February 2016 at 14:29

Europe also has some distance based numbers. You mention Portugal, but I know several villages in France that also use that schema.

Keyword here is “some” villages and “several” villages. I never denied this NA-style is present in Europe, but we should tag it better.

Then there are also streets where numbers take “jumps” on crossings. Not often by 100, but rounding up to the nearest multiple of 10 happens sometimes (note that in taginfo, the numbers 10, 20, 30 are also everytime more popular than 9, 19, 29, which shows my point).

  • Europe RARELY uses Multiples of 10 or skips tens of numbers but
  • NA approach OFTEN uses multiples of 100 or even 1000.

Then we also have things like bis-numbers. Where houses are build between adjecent numbers (f.e. new houses between 29 and 31), and the number gets an extra letter (29A, 29B, 29C, …).

Additional symbols are typical to both schemes (NA sometimes uses numbers instead of letters)

housenumbers in Europe are far from uniform

In terms of spatial proximity between consequent house numbers? I think they are more uniform, but of course I had no time to observe each of 60M cases.

Other problems is that improperly tagged objects screw statistic and you have no real understanding why or where bases on planet-wide stats

But I doubt it’s different enough to need a new schema.

Well maybe not a completely new schema but some tag to split odd/even numbering from proximity-based and grid-based?

Mostly/only in NA you will see 12345 housenumbers

More examples why Europe is so different:

Comment from Sanderd17 on 27 February 2016 at 16:40

Improperly tagged objects are indeed a problem. Like (AFAIK), Japan doesn’t use streetnames, but block numbers. Those should be tagged differently than our addresses.

But I still don’t get in what way you would process NA housenumbers differently from European housenumbers. A housenumber is bound to an OSM object, which is bound to a location. That’s all you need to know to guide you to an address.

In Europe, there’s also no way to estimate how far a certain number is in the street. Like just for my street (I don’t have to look far), number 28 is 440m from the start of the street. But number 29 is 1400m from the start. So there’s 1km distance between 28 and 29. And the longer the streets, the bigger the differences grow.

And yes, we don’t have 5-digit numbers, but in what way would that make a difference for data users? Housenumbers can only be processed as string, strings that you can place in an address. Is there any tool using addresses with OSM data that has problems with 5-digit housenumbers? (OsmAnd, Nominatim, …?)

In contrast, let me show you some European numbers (only from my own country actually) that Nominatim can’t handle because it doesn’t bind to streets cleanly.

http://osm.org/way/158656523 http://osm.org/way/311932649 http://osm.org/way/257712423

Especially Nominatim has problems with the above addresses.

And here some very special streetname (though no addresses mapped yet): http://osm.org/way/30126046

Comment from Sanderd17 on 27 February 2016 at 16:40

Improperly tagged objects are indeed a problem. Like (AFAIK), Japan doesn’t use streetnames, but block numbers. Those should be tagged differently than our addresses.

But I still don’t get in what way you would process NA housenumbers differently from European housenumbers. A housenumber is bound to an OSM object, which is bound to a location. That’s all you need to know to guide you to an address.

In Europe, there’s also no way to estimate how far a certain number is in the street. Like just for my street (I don’t have to look far), number 28 is 440m from the start of the street. But number 29 is 1400m from the start. So there’s 1km distance between 28 and 29. And the longer the streets, the bigger the differences grow.

And yes, we don’t have 5-digit numbers, but in what way would that make a difference for data users? Housenumbers can only be processed as string, strings that you can place in an address. Is there any tool using addresses with OSM data that has problems with 5-digit housenumbers? (OsmAnd, Nominatim, …?)

In contrast, let me show you some European numbers (only from my own country actually) that Nominatim can’t handle because it doesn’t bind to streets cleanly.

http://osm.org/way/158656523 http://osm.org/way/311932649 http://osm.org/way/257712423

Especially Nominatim has problems with the above addresses.

And here some very special streetname (though no addresses mapped yet): http://osm.org/way/30126046

Comment from Sanderd17 on 27 February 2016 at 16:41

Ugh, sorry for the double post. I got a HTTP error on the first try, and though it wasn’t processed. Both posts are exactly the same.

Comment from d1g on 27 February 2016 at 18:22

In general, a more clever auto-complete or an user interface:

  • In NA system it will display your GEO position in the road and spatially placed house-numbers (since its matters in NA version)
  • in European system house-numbers won’t get you even an estimate of position (order over proximity)

I hope you would argue that region-based addressing (in Korea or in some cities) is completely different from NA and European style? Unfortunately, we don’t have all details about this topic.

There should be hint for software “aha this house-number in Korean style”. Right now, all developers can do is to re-study topic every time, or make a guess about rules in some territory.

This knowledge should be explicit in data, so it can be processes more robustly.

And yes, we don’t have 5-digit numbers, but in what way would that make a difference for data users?

I don’t have good ideas, but IN US you should have only numeric keyboard, while in EU you have to use other symbols more often.

We need stats: how often numbers used in NA addresses vs how often they used in European house-numbers.

If there no difference in every single territory, then I give up. Otherwise, it may speed up input of house numbers.

http://osm.org/way/311932649

But I was able to hack Nominatim (a second link in the results) :)

Or I don’t understand what exactly wrong with this example.

Comment from d1g on 27 February 2016 at 18:43

As for European autocompletion, If I enter “123”, then:

  • it makes sense to suggest: 121, 125
  • it makes sense to suggest: 123A, 123B, 123C
  • 122, 124 are completely meaningless or should be ranked after other variants (it is unlikely that I will make mistake in odd/even rule)

BUT!

To implement this is Portugal you have to check if you are not in one of the exceptional areas. In order to do this:

  • every single developer must maintain list: (address style - area)
  • explicit tag can provide a direct answer about what rule set to follow

Does it makes sense why European system is different from NA? They have different use cases (and some statistical properties):

  • NA tells you “X meters from start of the street”
  • European tells you “this building was planned as number X from the beginning of the street”
  • Korean(?) is about “first find this block, then find this building”

Comment from Sanderd17 on 28 February 2016 at 13:22

Hmm, looks like Nominatim got a fix recently. At least last year, those queries wouldn’t work at all.

I understand that there are differences between the numbering schemas, but they are so minimal that data users shouldn’t treat them separately in most cases. Korea and Japan on the other hand use completely different addressing schemas (per block instead of per street), so they would need to be treated differently by data users.

For the NA vs EU case, an editor may indeed use that information to propose next numbers, but that’s something very specific IMO.

Comment from d1g on 28 February 2016 at 21:13

but they are so minimal that data users shouldn’t treat them separately in most cases.

Again, it is up to data consumers: if they want more features, or if they want simple processing/speed.

addr:system tag

Based on what was said above, I think easiest solution would be in additional tag, not in re-tagging of NA addresses (it would be easy to convince people with statistical background, but almost impossible to explain this minimal difference in styles at OSM scale):

  • addr:system=european
  • addr:system=na
  • addr:system=korean

Yes this tag is absolutely optional, similar to how addr:postcode=* has no effect on most search results. If we see no use in postal codes, It doesn’t mean that we should remove this information from database. Same about addr:system, it adds utility and possibilities for those who want them.

To me, OSM would win from clear distinction between european/na/other system.

addr:system=* can be applied to lowest admin_level=* boundaries (biggest suitable number) in hierarchy for simplicity.

Comment from DaCor on 28 February 2016 at 21:18

Is that not achieved by using the country boundaries (relations)?

Comment from d1g on 28 February 2016 at 21:26

DaCor, probably yes, but probably not :)

Like was above, there will be counter-examples in many countries (Portugal, France)

Зеленоград has no streets

One example would be Зеленоград

http://www.openstreetmap.org/relation/1988678#map=13/55.9792/37.1920

There no “streets” at all here, it uses “Korean” style (block-building addressing): http://www.openstreetmap.org/way/167350593/history

Comment from pnorman on 4 March 2016 at 15:01

I regularly tag 5-digit addresses with the Karlsruhe schema for addresses and it works fine. There are no problems with addresses that jump by large numbers when there is a crossing street.

Log in to leave a comment