Talk:Key:addr

From OpenStreetMap Wiki
Jump to: navigation, search

is addr:housenumber also useable for trucks, cars and motorbikes? ^^ Malenki 16:16, 22 March 2009 (UTC)

Contents

addr:housename vs. name

Here in Brazil, building addresses are usually like: "Rua XPTO, 123" (as in "123 XPTO Street" in english, always with a street name and a number. Besides that, most buildings/condos have a name - a name that's not used in routing or whatever, it's just the building name as in a POI name - like a hotel name etc. That being said, should the polygons be tagged with name=* or addr:housename=*? --Nighto 18:50, 9 June 2011 (BST)

Why does the suggested housenumber separator differ from OSM practice?

separator for multiple housenumbers on page suggests comma, "," rather than OSM customary semi-colon, ";". Why? Should this be reconciled with OSM practice?

I agree! In fact I use ";". If nobody find a good reason, I'll modify the instruction.--Stemby 00:11, 11 March 2012 (UTC)
Done--Stemby 12:40, 18 March 2012 (UTC)

Additional address tags needed

There is a need to extend the (standardized) list of address tags. Some countries use county/district in addition to (or instead of) national subdivision (state/province). Also often street names are unique on suburb/city-district level, and address should contain both city name and suburb name.

This idea is well supported by other standards for address elements:

I suggest extending the list of address elements here on global basis rather than developing local conventions for each country in order to facilitate unified mapping and allow various software to understand various address components. --Yuri Nazarov 09:31, 26 August 2009 (UTC)

Where to put addr:housenumber?

In cases where a single building area corresponds to a single housenumber - should one preferably tag the whole building or add a node for the main entrance and tag that?--hagman 21:13, 10 January 2010 (UTC)

Please put on the building=entrance node, as this is the only way to make it accurate enough for navigation for the blind, Lulu-Ann
It's not the only way, if the software looks for building entrances on the way depicting the whole building. Alv 11:09, 18 May 2010 (UTC)
If there is one building with one housenumber, then you should, ideally
--Tordanik 13:49, 18 May 2010 (UTC)
This is not sufficient, as there can be entrances that only have one housenumber while the building has several! Nobody wants to be routed to a building, everybody needs an entrance. A housenumber is not a polygon, it is one or several nodes. --Lulu-Ann 12:05, 21 May 2010 (UTC)
Look at the question: "where a single building area corresponds to a single housenumber". !. Alv 14:24, 21 May 2010 (UTC)
Still the entrance is needed! Lulu-Ann
Please stop unilaterally changing documentation! Tags on building polygons were described in the Karlsruhe schema and are used a lot. People have told you here that while there is a good reason to add a building=entrance tag even if there is only one entrance, there is not a good reason to tag the housenumber to that entrance, instead of the building polygon, and you have not been able to give a reason why we shouldn't continue the current practice of tagging building polygons.
If your software needs nodes as routing targets or for whatever other reason, then just do the following:
  • Find polygons with addr:* tags
  • for every node of the polygon:
  • if node has building=entrance tag: use it just as if it had an addr: tag itself
--Tordanik 18:40, 1 June 2010 (UTC)
There is something completely wrong in your text. Nobody ever gave me an argument (Yes, I am not talking about a good argument, I am talking about ANY argument) against the tagging of the housenumber on the building entrance. You idea for the navigation does not work for buildings with several housenumber and several entrances. Lulu-Ann
I did. The very building I live in has a house number 7, and several entraces with letters as a ref. The house number belongs only on the building way (or multipolygon, if needed). There is no housenumber 7 A. Continuing down the street, the next house on the street is "5a" and has entrances A and B; the one after that is house number "5", and has entrances "A" to "H". Alv 09:44, 2 June 2010 (UTC)

So let's start with arguments:

topic addr:housenumber on building=entrance nodes
that are members of the building polygon 		addr:housenumber on building polygon addr:housenumber on building polygon and
entrances as nodes on that polygon with ref=* 		addr:housenumber as "high" as possible ****
Is used more frequently because it was proposed earlier. No Yes No No
(Consistent with addr:housenumber on building polygons, but wasn't explicitly defined that way)
Using and routing is already established because a housenumber can be on a node anyway. Yes Yes Yes* Yes
Works on buildings with several housenumbers and several entrances without data loss Yes No Yes Yes
Can be tagged by blind users who currently can only tag nodes, but not areas
(and are not able to detect the form of a building in any other way like photos, estimating the shape, walk in straigt lines to building walls if the GPS receiver fails near the wall or estimate if it is easily possible to walk around the building.) 		Yes, partially
(only the entrances can be mapped) 		No
(they can map nodes as a first step until someone adds/integrates the building polygon) 		Yes (they can map nodes as a first step until someone adds/integrates the building polygon)** No
(they can map nodes as a first step until someone adds/integrates the building polygon; the nodes can even keep the addr:tags later)
When navigating to an address with housenumber:
Gives you the distance to the entrance, not to the middle of the building (There is no usecase to know the middle of the building, and if there is one, the polygon can be queried) 		Yes No
Even if supported by the routing software, the concept fails when there are several house numbers for one building. 		Yes, but routing software needs to query not only addr:housenumber but also ref. Yes
(software needs to query members/nodes)
Gives you the better angle if you navigate there, especially if the entrance is at the short wall.
(Chooses the correct street along the building) 		Yes No
Even if supported by the routing software, the concept fails when there are several house numbers for one building. 		Yes Yes
(software needs to query members/nodes)
Connects the position of the house number to a way (footway to the entrance),
this is easier for routing than finding a place to go to that is somewhere near the building polygon. 		Yes No
Even if supported by the routing software, the concept fails when there are several house numbers for one building. 		Yes Yes
(software needs to query members/nodes)
Offers access to building polygon from address (e.g. for highlighting the house found in an address search) Yes
(software needs to query ways that contain the entrance node) 		Yes Yes Yes
Offers access to address from building polygon (e.g. for showing a bubble with the address after clicking on a building) Yes
(software needs to query members/nodes) 		Yes Yes Yes
Redundance-free No
(for buildings with multiple entrances that all have the same house number, each entrance would need the same set of addr: tags) 		Yes, Information incomplete Information available, requires some preprocessing*** Yes Yes
* Trivial to add an input for a door ref, or parse it from the "house number + entrance" if entered, once any software wants to provide the feature. Alv 10:10, 2 June 2010 (UTC)
Choice 1 is nothing else but a trivial adding of the door, except is is called what it is: A housenumber and not a ref. Lulu-Ann
In your region people might call every door "a housenumber", but in other countries the housenumber is only a property of the whole building (or several buildings, even). Alv 11:55, 2 June 2010 (UTC)
Ah, in you country people do not enter houses through doors? The usecase is (pedestrian) navigation. What is you usecase where you need something different? Lulu-Ann
Corny jokes really don't support your reasoning. The staircase ref is as much part of the housenumber, as is the apartment number inside the building. Alv 12:40, 2 June 2010 (UTC)
I was not joking at all. What is you usecase where you need something different than the entrance of a building ? Lulu-Ann
The concept you started talking about, "entering houses without using doors", is a joke. Use cases aside (which others have given), it's about how to reasonably accurately model the world, not about whether there exists other use cases. Alv 16:47, 2 June 2010 (UTC)
** Enter the data as they please, if the shape is not available, or don't tag the way as a building until it resembles the real shape - but data may then later get improved to "number on the building only" case. Alv 10:10, 2 June 2010 (UTC) Naturally, they'll include the tag building=entrance on that node. Alv 16:47, 2 June 2010 (UTC)
*** Good routing software has to be able to handle entrances. Moving the housenumbers to the entrances might help primitive routing software (= routing software that only handles nodes well) provide somewhat better results, but it won't fix the problem. The software will then guide me to the entrance of a shop if I search for a shop's house number, but if I search for the shop by name/type, I won't. Or do you suggest to move shop=* tags to the entrances, too? --Tordanik 14:05, 2 June 2010 (UTC)
If there are several shops in one building, with different entrances, this makes sense. Thanks for the hint. It is not sensible to move complexity to routing algorithms instead of correcting a strange data model. You still did not answer my question what the usecase is to have the housenumber on the polygon. Do I need to assume there is none? Lulu-Ann
The primary "usecase" from a mapper's perspective is: "I want to tag a building with n entrances that have all the same house numbers with as few tags as possible". "As few tags as as possible", in this case, is 1 tag. That's the reason why your model does cause redundancy: It requires n tags for this situation that are all the same.
If you want applications that require an association between house numbers and building polygons: Highlighting a building in a map after a successful address search. Writing the housenumber label to the center of a polygon (where there is enough space) rather than at the edge. Finding out what amenities are within a building using an inclusion test. Clicking on a building and showing the house number. --Tordanik 14:56, 2 June 2010 (UTC)
I have to agree with that sentiment. Just because no one has implemented something doesn't mean they won't. Over-simplifying it now for convenience will end up coming back to bite you in the end. Semantic data should be accurate, ie my local shop has an address, not just its front door. If the penalty of that is that you need to marginally increase the complexity of routing algorithms, then so be it. Ultimately on complex buildings there is no reason you can't use relations to attach the door to the address - even on the more simple cases, although it would increase the workload of mapping. Essjayhch 09:41, 7 December 2011 (UTC)
**** As "high" as possible means: If all buildings of a site have the same address, add it to the site relation. If all entrances of a building have the same address, add it to the building polygon. If every entrance has its own address, add it to the entrance. Additionally tagging the same addr:*-Tags to the lower level objects isn't required and doesn't change the meaning, but is acceptable if the mapper wants to do it. --Tordanik 15:12, 2 June 2010 (UTC)
I think use of relations is actually the best solution here, as it is my house that has an address - not solely its front door. Removing the address from the polygon is removing valuable semantic data. I'm very much of the vein that you shouldn't try to assume what someone may use data for. Essjayhch 09:20, 7 December 2011 (UTC)

"This page requires some cleanup."

What information from the Karlsruhe Schema is missing on this page? The only obvious omissions are associatedStreet relations and the xml syntax examples. Both are intentional: The relation should be documented on Relation:associatedStreet (which doesn't exist yet, but that's not a shortcoming of this page). And xml syntax isn't the level of abstraction mappers work at, and the listings don't add any new information. --Tordanik 13:49, 8 April 2010 (UTC)

Need tags more specific than addr:housenumber=*

As noted above, RFC 5139 adds tags that are more specific than addr:housenumber=*. In particular, I propose adding addr:building=* and addr:suite=* for tagging office complexes where every building has the same addr:housenumber=*, but each business gets a different suite number. The same applies to apartment complexes.

The only question I have is should we use addr:suite=*, addr:unit=*, addr:room=*, or some combination of all of these? Do some people with a more international view have an opinion? BigPeteB 17:55, 23 June 2010 (UTC)

We need to fix the levels problem, before we can map appartments that can be on the same coordinate in different altitudes. Lulu-Ann
Hmm, that's something I'm not sure I'm ready to tackle; I've only been working on OSM for a couple months. However, building and suite numbers doesn't seem like it would be affected by that. (Well, suite numbers maybe, but most office complexes I've seen have single-story buildings, so those can be mapped without difficulty.) BigPeteB 04:58, 28 June 2010 (UTC)

i second the need for tags that represents the exact location. especially shops in malls and big apartment buildings (with sometimes offices and doctors in in) use the same address but add some kind of detailed information about the exact location. for example addresses can be written as "Musterweg 12/2/14" --> "<street> <housenumber>/<door|entrance>/<doornumber>". so i would add:

First Floor should start at 1 because 0 would be the basement. Also, you wouldn't have to remember to subtract 1 from the floor number. --Panther37 15:52, 22 March 2011 (UTC)
The ground floor is correctly at 0. The basement is, of course -1. American usage of calling the ground floor the first floor is a misnomer. --Polyglot 07:13, 24 April 2011 (BST)

this would also greatly eliminate the problem that addresses should be unique in osm. Flaimo 16:55, 03 November 2010 (UTC)

addr:street impossible (at least) in eastern Europe

When I started to map some addreses in Sofia, Bulgaria I realized that it is impossible to get a street for the addreses. Here it is organized like "Block <number> in suburb xy" for example "Block 58, Studentski Grad, Sofia, BG" - I mapped up to now with the workaround that the street is the suburb, so: "addr:housenumber=58", "addr:street=Studentski Grad" (in Cyrillic letters) and addr:town="Sofia".

The OSM Inspector shows it as wrong [1] - but anyhow I thing it's the best solution. Or has anyone different ideas? Or is there already some solution for this?

[1] http://tools.geofabrik.de/osmi/?view=addresses&lon=23.34832&lat=42.66087&zoom=16&overlays=buildings,buildings_with_addresses,postal_code,nodes_with_addresses_defined,nodes_with_addresses_interpolated,street_not_found,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads

You're right, this is a big problem for parts of the world that don't use the standard "123 Main Street" scheme. Japan is in this category too: most streets do note have names, and an address within a city usually has a ward, district, block number, and building/house number.
We should definitely not use addr:street=* for anything but a street name. Doing so will just create confusion and make it complicated to use addr:street=* to generate a proper relation. It's pretty obvious that we should implement addr:block=* for block numbers, and something else for districts/wards/suburbs.
In the long run, I think everything should be in a relation, because it's completely unambiguous that way. addr:street=* seems to be treated this way; it's just a hint that will eventually be removed when the building is added to a relation, which could be performed by bots in many cases. So, with that in mind, I would advocate using whatever makes sense:
If each of these is a strict subset of the other (for example, a suburb/ward has boundaries that can be drawn on a map) then it could be omitted and inferred the same way we infer a city, state, or country. But we can add it as a hint, or just to be explicit. BigPeteB 18:12, 10 July 2010 (UTC)
To clarify, I would tag "Block 58, Studentski Grad, Sofia, BG" with addr:housenumber=*, addr:block=58, and optionally addr:district=Studenski grad and addr:city=Sofia. BigPeteB 18:17, 10 July 2010 (UTC)
Sounds well so far, but the additional tag "addr:block" is unnecessary in my opinion. It is also for houses possible, as mentioned before in Japan. Is it possible to get only one additionaly Tag which organizes district, neighbourhood, ward and suburb in one? Beacuse the "necessary" name should occur only once? Fips Schneider 14:16, 16 July 2010 (UTC)
Maybe I've misunderstood. When you said "Block 58", is that the number of the house/building, or an entire block of buildings? In Japan both are used together (example: "Taito Ward, district 2, block 24, house number 2")
Second, I don't pretend to know how addresses work in ever country in the world, so maybe it's possible that some places have a combination of districts, neighborhoods, wards, suburbs, or maybe something else I haven't thought of. I would just use whatever seems appropriate for the region you're mapping. In Japan this would be ward, district, block, housenumber. In the Bulgarian example above, it would be district and block, or district and housenumber. --BigPeteB 01:27, 17 July 2010 (UTC)

Grid?

Many cities have nice grids where the addresses are all measured from a central point. Is there any way to map such a grid? --NE2 17:24, 13 July 2010 (UTC)

Encourage addr:street on the interpolation way?

The page specifies that only the addr:interpolation tag may be attached to the interpolation way. Wouldn't it be nice if we could attach street names to this way (and maybe also city and country), so we wouldn't need to attach those tags to each node? The nodes would naturally inherit the values from their interpolation way (which itself could come to be seen as a "row of buildings", and useful even if all the buildings are individually numbered or named). Lorp 00:08, 11 August 2010 (BST)

Just adding the tags to each node is the most easily understandable method of tagging and should be preferred for this reason. Moving features onto interpolation ways adds another alternative for tagging house numbers, and there are too many already. Don't forget that interpolation lines are intended to be a temporary replacement for the buildings (with addresses) themselves. Once there are individual building polygons with addr:* tags, there won't be any interpolation lines anymore. --Tordanik 09:52, 11 August 2010 (BST)

addr:suburb

I miss the widely used (8000+) addr:suburb Tag on the page. Should it be replaced by one of the new tags (addr:hamlet, addr:subdistrict, addr:district)? --chris66 11:37, 2 November 2010 (UTC)

Update: addr:suburb is now used 36.000 times, still missing in the key-list.

Simplified addr tag

Wikipedia explains in detail the addressing in different countries (http://en.wikipedia.org/wiki/Mailing_address). While reading this it seems that the proposed tagging scheme specific to certain countries.

Is it really necessary to have a fine grained resolution into different tags (e.g. addr:street=*, addr:housenumber=*). In many tools there is only on "address" field to fill in the details of the address. Only the city and postcode are in different fields.

Example:

In this scheme only the building needs an addr:addr=*. The postcode and city tags may be derived from surrounding area's.

This simplification could solve many country specific variants.

--mmehl 00:12, 22 January 2011 (UTC)

At least in the US, postcodes cannot be represented accurately by areas. As the city names used in addresses are tied to postcodes, they too are necessary. --NE2 00:30, 22 January 2011 (UTC)
We could make zipcode areas similar to the data in this Zip Code Finder and Boundry Map (You must left click on the map for it to show you the zipcode data.) Maybe the data owner will let us use the zipcode data for free. That would solve this problem. --Panther37 02:42, 18 October 2011 (BST)

Sub-streets

Is there an approved method for handling named ranges within streets? For instance, just today I have drawn numbers 1-6 "Antwerp Cottages, Thoday Street" and numbers 1-6 "Waters Almshouses, Seymour Street" in Cambridge - where there are also many houses (including nos. 1-6) whose addresses are simply "Thoday Street" and "Seymour Street". What should be addr:housenumber, addr:street or anything else in these cases?--Laverock 17:10, 17 October 2011 (BST)

I'd be keen to hear of one as well. Some searching shows that UK councils describe these as "subsidiary names".
I think a method to represent such addressing requires a relation. For example, an associatedStreet relation that collects all the associated buildings, and then with role=subsidiary is added as a child relation of the associatedStreet relation that describes the main street. The subsidiary relation could optionally contain an address within the scheme of the main street. The diagram below gives an example (seen: http://g.co/maps/srav2 (Street View)). I specifically chose this example because it is slightly more complicated than a typical terrace *shrug*
Houses in this example have addresses of the form:
1 Simon House, 2/4 Windmill Road, Headington, Oxford, OX3 7BU
--Craigloftus 17:48, 18 October 2011 (BST)
Craigloftus subsidiaryAssociatedStreetRel.png
Retrieved from "http://wiki.openstreetmap.org/wiki/Talk:Key:addr"
Personal tools
Namespaces
Variants
Actions
site
Toolbox