Template talk:Map Features:addr

States vs. provinces

I documented the addr:state=* tag here. I don't know if its use has been approved, but it's certainly used much more than addr:province=* (560 000 vs. 35 000 objects). --T99 04:15, 26 December 2011 (UTC)

"Full" address

I browsed through hundreds of existing addr:full=* tags but I didn't find any values that would include the city or the country. It seems the tag is used primarily as a copy of the house number and the street name (the order of which depends on the local custom). Because the free format of the value, it may include additinal information such as a directional prefix/suffix or an apartment/suite/unit number. I added an example to reflect this usage. I don't know if this tag should be used in cases where all the information in it is redundant (already included in addr:housenumber=* and addr:street=* tags). --T99 07:44, 26 December 2011 (UTC)

I doubt that this tag should be used at all. So many addr:* keys have been introduced, that it should now be possible to map every address with these fine-grained keys. I suggest marking addr:full as deprecated. --Fkv 18:58, 15 January 2012 (UTC)

conscriptionnumber

"conscriptionnumber" has just been added, but it seems to duplicate usage of addr:housenumber + addr:place, which is in quite wide use already - see http://wiki.openstreetmap.org/wiki/Addresses#Addresses_without_street_names

although i can see the problem if a specific entity has both street-attached housenumber and place-attached housenumber. --Richlv (talk) 18:05, 3 January 2016 (UTC)

Both are in wide use (5157117 vs. 2730755 objects, while other tags get the "in use" status when there are 1000 or so objects), and neither has ever been approved by voting, so I think it's fair to document both. There are even more approaches that are in use for tagging conscription numbers, such as addr:street or addr:hamlet instead of addr:place. Each of these has its advantages and disadvantages. So we cannot tell that this one is right and the other is wrong. It's rather a matter of taste.

As you have already noticed, the addr:place+addr:housenumber approach runs into problem when a house has both a conscription number and an orientation number. We can use the addr:* schema for one and the addr2:* schema (for which there are at least 3 proposals) for the other. Yet there are cases where this won't suffice either. Just a few hours ago I came across a building 162878594 162878594 whose address is given by its owner on http://www.zielpunkt.at/alleFilialen/fromBildBox/24/index.html as:

 7535 St. Michael
 Oberwarter Straße 339

7535 is the postcode, St. Michael is the village, Oberwarter Straße is the street, and 339 is the housenumber. But 339 is really the conscription number, and the street name is only included to make it easier to find it. It's impossible for data consumers to recognize addr:housenumber=339 as a conscription number. This does not do any harm by now, but - as many other municipalities already did - the municipality of St. Michael may sooner or later decide to switch to orientation numbers. In that case, there will be an old address 7535 St. Michael Oberwarter Straße 339 and a new address like 7535 St. Michael Oberwarter Straße 1. Even if we use addr2:* for the old address and addr:* for the new address, data consumers cannot distinguish which of the two addresses contains the orientation number and which contains the conscription number. This distinction is only possible with a dedicated tag for the conscription number.

--Fkv (talk) 22:39, 3 January 2016 (UTC)

just a quick note that wiki voting does not mean much, so that should not be used to determine validity ;)

addr:hamlet does sound like a valid use, if the location is a hamlet indeed - in other cases addr:place would be better. can't think of any towns that would use housenumbers only. reusing addr:street for place name seems very wrong, though.

--Richlv (talk) 19:42, 5 January 2016 (UTC)

The problem with addr:place is its vague definition ("some territorial zone, island or building" in the template, and "name of village, islands, territorial zone or any other object" on the tag page). It is essentially defined as an address part that acts like a street name but is not a street name. This is a functional definition, while all the other addr keys correspond to classes of real-world objects. addr:place may suffice for address lookups (Nominatim), but for many other applications it won't. When your boss asks you to deliver him an excel table with all addresses, he certainly will not accept a "place" column, particularly when you tell him that it may be "a village, island, territorial zone or any other object". He will ask you to split that up and be more explicit. You also have a hard time when ordering the addr keys, because addr:place can be above addr:city level (when addr:place is an island) or below street level (when addr:place is a building) or somewhere in between. --Fkv (talk) 21:42, 5 January 2016 (UTC)