OSM Inspector/Views/Addresses
The Addresses view in OSM Inspector shows addresses including house numbers, postal code areas etc. mapped according to the Karlsruhe Schema.
Overview
There is no standard for mapping addresses, house numbers, postal codes, etc. in OpenStreetMap. But most people use the Karlsruhe schema for addresses. This layer shows address information tagged according to the simple model of the Karlsruhe Schema. It does not include the "relational option".
Data sources
All data in this view is derived from OSM data.
Layers
Depending on zoom level the layers Postcode areas and Outline of postcode areas show pink areas or their outlines. The areas are computed from all nodes and ways tagged with a postcode, to be more exact, all nodes and ways tagged with addr:postcode=* are taken and the convex hull for any combination of addr:postcode=* algorithm will be used. There is an ongoing discussion whether it makes sense to add addr:country=* to so many objects. In the future the algorithm might take country boundaries into account. These layers are currently not available, because they can't show the postal code areas properly without the addr:country tag and this lead to too many confusions.
Nodes with defined addresses are shown as black dots. If you zoom in far enough the house numbers are shown.
The nodes can be connected by blue House number interpolation lines. For interpolation of only odd numbers a single line is shown, for even numbers a double line. For all numbers a thick blue line.
On the interpolation lines grey Nodes with interpolated addresses will appear. They don't exist in the database, but are calculated from the end nodes and the information in the interpolation line.
The Interpolation errors layer shows interpolation lines (ways tagged with addr:interpolation=*) that the OSM Inspector didn't understand or that don't make sense. The following errors are possible (the error text is shown when zoomed in far enough):
needless
|
The difference between first and last house number is 1 and the type is all. No interpolation line is needed here. |
endpoint_wrong_format
|
One or both of the endpoints are not integers. |
interpolation_even_but_number_odd
|
The interpolation line is tagged as addr:interpolation=even but at least one of the endpoints is an odd number. |
interpolation_odd_but_number_even
|
The interpolation line is tagged as addr:interpolation=odd but at least one of the endpoints is an even number. |
different_tags_on_endpoints
|
One or more of the tags addr:street=*, addr:postcode=*, addr:city=*, addr:country=*, or addr:fulladdr=* on the end nodes is different. |
unknown_type
|
Value of addr:interpolation=* is something other than all, odd, or even. |
All Buildings are shown as ocher filled polygons (holes in those polygons are not shown). Buildings with addresses are shown in the same ocher with a darker outline. When zoomed in far enough the house number is shown in the middle of the building.
For routing applications you have to know a point on a road near the node/building you are interested in. The green Connection point on roads layer shows the nearest point to some node/way with an address. The Connection lines layer shows the connection between the node/building and this connection point. The Nearest Road layer shows the nearest road as a green line along with the name of the street.
The nearest road is computed as follows: The value of the addr:street=* of the node or way (building) is searched for among all the name=*s of ways tagged with highway=*. Only streets within 0.01 degrees (about 1km) are found. To find the connection point/line a perpendicular is dropped from the node with the address to the found way. For buildings the centroid of the outline polygon is used.
If the street for a node couldn't been found (because a street of that name doesn't exist in the about 1km radius) it is shown in the Street not found layer as a red dot. If the node/building doesn't have a addr:street tag it will show up in the No addr:street tag layer with a pink dot.
The Ways tagged with postal_code layer is the odd one out. It shows roads (or other ways) tagged with postal_code=*. This tag is not used in the Karlsruhe schema. It is an older scheme where the streets themselves are tagged with the postal code.
Discussion
- Is it a bug or on purpose that every node in an addr:interpolation way has to be tagged with addr:street. I think it is way too complicated to tag something 2+ times the same. --Skywave 20:02, 18 November 2008 (UTC)
- That discussion belongs on Karlsruhe Schema -- Joto 22:28, 18 November 2008 (UTC)
- That page states that addr:street is optional, so I think his question was: Why does the inspector mark a node as "street not found" just because it has no addr:street set? (See also my message on talk-de) --Schuetzm 16:11, 19 December 2008 (UTC)
- What's the rationale for not using the relation part of the Karlsruhe Schema? Discussions I've had in the talk page showed nothing but support in favor of them. Pov 22:50, 23 November 2008 (UTC)
- Its not widely used. There are only a few hundred of those tags vs. tens of thousands for the other scheme. Of course this might change in the future and I'll try to reflect actual usage in the Inspector. -- Joto 08:43, 25 November 2008 (UTC)
- Roughly two years now have passed. :-) I would love to see an update of your statement, Joto. Will Geofabrik consider inclusion of address relations for the address view of OSM inspector? That would be great! --SB79 21:34, 4 November 2010 (UTC)
- Is it normal that the interpollation can not be "alphabetic" ? i got a interpollation error and error:unknown_type --EMerzh 16:39, 2 March 2009 (UTC)
- The Nearest Road algorithm should take relation roadAccess into account. It's not widely used, but essential to get to certain places, e.g. park garages (where the official address is not always the access road). --wolfbert 10:52, 7 March 2011 (UTC)
- It would be possible to take in consideration also the addr:place tag, for places (villages etc.) where there is no street names and the addr:housenumber is to be connected to a place=* ? --damjang 10:21, 30 January 2013 (UTC)
- Would it be possible to support extra name tags on streets?
- Sometimes, the left and right side of a street get different names (mostly when the street forms a boundary, and the different governments don't agree on how to name it). In that case, the name tag is often a combination of the two, or a compromise in spelling, and the official names are tagged as name:left=* or name:right=* for both sides. See some examples:
- In multilingual regions, there's also no official name for streets. The naming signs on different crossings of a street may differ, so there's no way to be consistent. In the case of Brussels (Dutch-French bilingual), to avoid discussion and to stimulate mapping, it's the first mapper that gets to decide the order of the languages in the name tag. Next to that, all streets have (or should have) a name:fr=* and name:nl=*. I wasn't involved in adding address data to Brussels, but it looks like many mappers didn't use the name of the street for the addr:street=* tag, instead, they used their own preference of language order. So in some areas, the addr:street=* tags don't match the name=* tag of the street at all. Since we are with two conflicting rules here (first mapper decides the language order vs the name on the address and the street must match), I think it's better to just look at the official names which are encoded in name:fr=* and name:nl=*. Examples (just pan around in Brussels to see more):
--Sanderd17 (talk) 15:57, 12 January 2015 (UTC)
- in a lot of the imported danish adressnodes (such as in https://www.openstreetmap.org/node/974193435), the traditional short names are still used. In a number of cases (such as in https://www.openstreetmap.org/way/76093555) I have put the full name in Key:name and the traditional name in Key:short_name, but this makes these adresses light up red in the OSMI Addresses view. Is there any way this can be avoided? --Hjart 8 February 2107
Is it possible that OSM inspector can show any addresses that have been duplicated within a radius of say, 100 metres of one another? A use case for this is for when multiple businesses that share an address have not had their addr:unit values specified. -- DENelson83 (talk) 03:52, 14 October 2024 (UTC)