Talk:Key:addr:*

From OpenStreetMap Wiki
Jump to navigation Jump to search
Talk:Key:addr - Other languages

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

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)

I think if the (residential) house itself has a name you should use addr:housename=*, but when you tag a special building like a hotel, shop etc. name sounds more appropriate (because it is the name of the company and not of the house itself for example). Cheers -HQQ
I disagree with HQQ here. addr:housename should be used if and only if the name is part of the postal address. Otherwise, use name. --Tordanik 15:44, 20 June 2012 (BST)
As I often see shops, offices, etc. use the name of the building on ther adresses, such as business cards, I believe the name should be tagged with addr:housename=*, I have also seen examples where a dominent business (name=* have a different name than the building, this using both will than be the solution. I also see often that letters are addressed to Rua XXX, 123, Ed. Buildingname indicating that building names as well are used in post addressing. I am not sure if this is a general rule in Brazil or just regional (Nighto and myself live in different states). --Skippern 18:12, 31 August 2012 (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)
On the Addresses page, and probably a bunch of translated pages with addr:* issues, the comma is still suggested. Here's an excerpt from Addresses: "When a building has more than one house number, use either the numbers separated by commas (e.g., '11,13,15')". Looks like different OSM wiki pages either suggest the semicolon or the comma, which is very confusing! What should we do? --Wuzzy 01:55, 5 September 2012 (BST)

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:

  • RFC 4119 defines elements a1 (state/region/province/prefecture), a2 (county/parish/gun/district), a3 (city/township/shi), a4 (city division/borough/city district/ward/chou), a5 (neighborhood/block), a6 (street); RFC 5139 extends RFC 4119 scheme by adding new thoroughfare elements
  • OASIS xAL (Extensible Address Language) uses these: Country, AdministrativeArea, SubAdministrativeArea, Locality, DependentLocality, Thoroughfare, DependentThoroughfare
  • UPU (Universal Postal Union) standard S42 (developed together with CEN) uses these: country, region, proximate town, town, district, thoroughfare, secondary thoroughfare.

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)

As we are tagging postal addresses here, the UPU scheme should be prefered. It is the most effective for the international delivery of courier.
Note however that the UPU scheme forgets to handle country-specific needs (notably PO Boxes, and special postal codes actually located in post offices with a name distinguished from an actual city name; see below the discussion about PO Boxes).
In fact the comon practice is to allow specifiying public addresses on:
  • at least 2 address lines (the first one specifying the street name and house number, or the house name and street name),
  • plus a line for the PO Box and special delivery systems (often it will use the second address line above),
  • before the line with the postal code and city,
  • and an optional final line for the country name (written in the language/script used in the originating country from where the courier is posted).
All these lines should be separated from the specification of the intended recipient (person name, service name in an organisation, organization name, floor/door and other inhouse addressing), which should fit on 2 lines written before the rest of the public address. These standards also recommand fitting everything on at most 5 lines (or 6 with the country name, which can also be specified instead by prefixing the country code just before the postal code (separated by a recommended dash). — Verdy_p (talk) 03:35, 6 April 2013 (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 (note 2017: this is now entrance=yes/main) 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 (note 2017: this is now entrance=yes/main) 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 (note 2017: this is now entrance=yes/main): 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 (note 2017: this is now entrance=yes/main) 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 (note 2017: this is now entrance=yes/main) 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:

  • addr:entrance --> which (outside-)entrance of the building
  • addr:doornumber --> which door inside the building
  • addr:floor --> which level (0=first floor ("erdgeschoss" in german), 0.5=mezzanine , 1=second floor, a.s.o.)
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)

I think a highly structured scheme like this is both hard to use for the casual mapper and hard to adapt for the needs of particular places. So I would suggest a free-form key, say addr:complement=*, to collect any addressing information more specific than the housenumber: "addr:complement=Suite 101", or "addr:complement=Apartment 4C", or "addr:complement=Building B" or even "addr:complement=Building 7, Room 301" or "addr:complement=Mezzanine". To put it another way: most address forms I see on the web have two lines for the street address, one of them being optional; this tag would capture the content of this optional line. Augusto S (talk) 19:51, 10 January 2015 (UTC)

As another example, where I map it is common for companies to rent an entire level in a commercial building. The address would then be written, say, "Level 7, 123 Some Street". In this case, tagging addr:suite=7 would be a bit of a stretch, and inventing yet another tag, say addr:levelnumber=7 is just silly. On the other hand, "addr:complement=Level 7" seems completely reasonable to me. Augusto S (talk) 19:57, 10 January 2015 (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
In terms of simplicity, couldn't we capture this information in a tag too? I.e. addr:associated_street? For example, 1 Example Court, Example Road, Example Town becomes addr:housenumber=1, addr:street=Example Court, addr:associated_street=Example Road, addr:city=Example Town Casey boy (talk) 11:18, 22 October 2020 (UTC)

More building internal addressing

I have at a few examples seen a very complex addressing (Universities, Buseniss-parks) where staircase and elevator reference is just as much part of the address. I therefor suggest the following to be added under building specific addressing:

Thus the address of some specialist office can be name=Name of company, addr:block=C, addr:entrance=A, addr:stair=F, addr:floor=4, addr:wing=South, addr:door=201

--Skippern 18:23, 31 August 2012 (BST)
Regarding floor and door please have a look at level=* and room=* --Andi 00:11, 9 March 2013 (UTC)

Virtual postal addresses with PO boxes (actually located elsewhere in a post office)

Some important locations (such as amenities, airports, many companies) have their official **postal** address located elsewhere, notably in some post office of the neighborhood. You cannot simple send any letter to their actual location on the map. This means that for the addr:* scheme, which is tuned for postal addresses and not for geolocation, we should have another key: Unfortunately the key post_box=* is meant to be used for the location where people can post new letters to deliver, not for post boxes allocated inernally in post offices for arriving letters.

I propose the key addr:postbox=* anyway for addresses such as "PO Box" in UK, "BP" (boîte postale) in France (and Belgium, Luxembourg, Switzerland, at least in the French speaking areas), or "CP" (for "case postale"). The abbreviation for PO Boxes, customarily used on enveloppes, should be present in the value of the tag (as there may be variants) : e.g. addr:postbox=BP 57. This is needed because there are sometimes different types of pobox with different (but distinctive) abbreviations for special delivery servicing, each type with its own numbering.

Note: there's another proposal using addr:pob=*, never used, but it looks not very obvious, too much cryptic. May be I such name it addr:po_box=*, this does not matter but it must be explicit for everyone. There are also tags using addr:pobox=* with the same meaning. Which common tag to use is still not decided.

Also many of these postal addresses in postal boxes of post offices have a specific postal code, different from the city where the amenity or company is actually located. The city name is also different.

One example, see way 167582917:

name=Aéroport Rennes Bretagne
addr:postbox=BP 29155
addr:postcode=35091
addr:city=Rennes CEDEX 9
(the country "France" is implied from the geolocation of the OSM tagged object, and so it does not generally need to be tagged; on enveloppes, it can be specified by writing the name of the country on the last line, or by using the "FR-" prefix before the postal code; the country name should be in the language of the origin country from where the letter is posted, or may need to be romanized if the origin or target country do not use the same script system, notably if one of them uses the Arabic or Chinese scripts, this is a good reason why the country code should be used as a prefix before the postal code; but the rest of the address should be written in a script and language understood in the target country, and not translated)

Note that:

  • The airport is named according to its official commercial name, even if it has another common designation alt_name=Aéroport de Rennes - Saint-Jacques which is translatable (e.g. alt_name:en=Rennes - Saint-Jacques Airport)
  • there's no addr:street=name, and no addr:housenumber=* when there's an addr:postbox like here (but there may exist a addr:housename=* to designate a specific building, or addr:floor=*, addr:door=* for the final delivery, not by the postal service but by the internal distribution service of the target organisation, just like there may also be the name of a specific service, or designated person for confidential letters not meant to be open by anyone not specifically authorized in the organisation). Such postal address using a PO Box is not, by itself, geolocated (it is meant for the delivery of letters, not for indicating a direction for people or drivers).
  • The postal "city" (in fact the name of the post office with a suffix to designate a special distribution : the actual post office here is not necessarily located in Rennes and may be elsewhere) shows "Rennes CEDEX 9", not "Rennes" which is an actual city name, and not "Saint-Jacques-de-la-Lande" which is the actual municipality where the airport is geolocated. addr:city is completely unrelated to geolocalisation, it is meant for postal use only, and for this reason you should not break the CEDEX suffix in another tag, as it would cause confusions. La Poste never breaks these names for this reason, they MUST fit on the same address line on enveloppes.
    The term "CEDEX" is a French abbreviation used by La Poste for "courrier d'entreprise à distribution exceptionnelle", it is used by lots of companies or governmental institutions, or local administrations, sometimes as well by large associations and non-profit foundations; the number after the CEDEX abbreviation is mandatory, where it is specified in some post offices: it designates an internal postal service that manages a collection of PO Boxes, each PO Box number is then specific to this CEDEX service in the same post office (but this service may be actually located elsewhere, notably in large cities that have several post offices for the delivery to organisations, these delivery post offices are not standard post office "amenities" with their shop and visitable by the general public).
  • The postal code 35091 (directly associated to this "CEDEX", named and used specifically for it), is different from the normal postal codes used in Rennes, or in Saint-Jacques-de-la-Lande.
    La Poste recommands writing address city names entirely in capitals so it would show "RENNES CEDEX 9" when handwritten, but if the address is printed, this is not a requirement: the postal code alone is sufficiently qualifying, but both the postal code and postal "city" name (actually the name of a post office service) must be present to prevent handling errors during the delivery (you should not just specify the postal code on enveloppes).

These tags should feed the polygon created around the airport, which also uses the following documented tags (see the Airport page), completely unrelated to postal addresses:

aeroway=aerodrome (look at this tag value page for other tags below)
aerodrome=international
type=public (note that this badly named tag is often ambiguous in mutlipolygons, it should probably become aerodrome:type=public or something more explicit such as aerodrome:operation=public
operator=Chambre de Commerce et d'Industrie de Rennes
iata=RNS
icao=LFRN
ref=RNS (i.e. the same as the IATA code, preferably, according to the documented airport tagging scheme)

And for other external information and references:

website=http://www.rennes.aeroport.fr/
wikipedia=fr:Aéroport de Rennes - Saint-Jacques

— Verdy_p (talk) 01:20, 6 April 2013 (UTC)

Venice (Italy) addresses

Hi, addresses in Venice, Italy (island, zone with "neighbourhoods" a.k.a. "sestieri" Cannaregio, Castello, Giudecca,...) shouldn't have addr:street tag. House numbers are incremental in the whole neighbourhood area; address should be listed like: "631E, Cannaregio, Venezia" and not "631E, Calle de le Canne, Venezia". That's wrong and bringing unaware users to insert a "misleading" street tag. As matter of fact, there are plenty of "streets" with same name in same neighbourhood (like "Calle del Magazen") and numbers are totally unlinked to "streets" (see the pattern on the map. Example: http://www.openstreetmap.org/node/1523608364 ). I don't know if it's an unique case, but with an important city like Venice there should be more precision even in nominatim. People should search 631E, cannaregio, Venice and find it. Arlas (talk)

Changed recommendation for addr:postcode and addr:city

I disagree with User:LeifRasmussen's changed recommendations, which essentially ask mappers to always add addr:postcode and addr:city. Unlike housenumber and street, these cannot be easily collected during on-the-ground mapping. It's also just unnecessary extra work in places that have good coverage with boundary relations. While it's true that much these aren't present in many places, text had already acknowledged this before the change with the qualifiers "if present and valid". --Tordanik 18:48, 1 June 2019 (UTC)

Sorry about that! The reason I changed it was to make clear that those tags are useful in many places. I noticed that people would import hundreds of thousands of addresses and not add addr:city or addr:postcode to any of them (even if those attributes existed in the source dataset) because they read this wiki page.
In my area, the addr:city tag often doesn't match up with the boundaries around it. For example, an address in a small town close to a city would have the postal city address of the big city, even if it's not inside of the city boundary. Because of this, it's a good idea to add addr:city.
addr:postcode is similar, but different, since that tag is usually not possible to get from boundaries.
I changed the wiki description to make it clear that these two tags are useful, and shouldn't be discarded for no reason, since the old description indicated that the tags should be removed, since they aren't necessary. I would be happy with improving the wording to indicate that the tags are not required, as long as it's still clear that the tags are useful.
Thanks for sharing your thoughts! --LeifRasmussen (talk) 17:15, 5 June 2019 (UTC)
I really don't believe it's a good idea to add a city to addresses that are not within the city boundaries. Routers should be smart enough to search an area around the city boundaries when searching for an address, if none is found within the city boundaries. If anything, I believe we should create a new tag (for instance: postal_city, post_town, whatever) to account for the situations you mention. Fearsyth (talk) 20:59, 9 September 2019 (UTC) (minor edit 21:19, 9 September 2019 (UTC))
This sounds a reasonable suggestion - but is likely to spark a moderately warm debate on whether the tag should be addr:postal_city or addr:post_town (as it is known in the UK, whether the local central addressing node is in a town or a city). There's also a lot of remedial work in bringing addresses that use addr:city for the post town (see section below for examples) and addr:village or addr:hamlet for the postal settlement into line with the new standard. Good luck! --John Grubb (talk) 21:13, 9 September 2019 (UTC)
My main issue with using addr:city for whatever city is used in postcodes using the city of Wentzville, MO USA as an example:
The incorporated portion of Wentzville, MO spans a circular area with about a 6 mile diameter, with a road that sticks out for about 2 miles on one side. Most of the city (14,xxx addresses) resides in 63385 postcode. It also has portions in 3 other postcodes (63348 - 1000, 63366 - 700, 63367 - 100). The suggested postal city for 63385 is Wentzville, MO.
The 63385 postcode spans a somewhat rectangular area about 9 miles wide by 13.5 miles tall. Wentzville is pretty much entirely in the top half of the postcode area. If using the postcode suggested city, the Wentzville, MO would cover an area more than double it's actual size (likely closer to triple). This would include unincorporated addresses more than 5 miles (more by road) outside the closest border of the city. Yes, unincorporated addresses that are on the opposite side of another city. I'm sure I could find even worse cases very easily.
My final opinions: Something needs to say "this address is within city limits". addr:city seems to be the best use outside of city multi-polygons. Having them both called "city" but meaning different things is wrong. Also, city multi-polygons are harder to correctly lay out, as you have to trace parcel borders based on which parcels are within city limits, and trace streets based on which streets are city maintained. Fearsyth (talk) 21:57, 9 September 2019 (UTC)
@LeifRasmussen:, I'm a bit late in noticing this, but you seem to not actually have changed the article? Or am I missing something? --Tordanik 15:52, 30 September 2019 (UTC)

Key addr:village introduced

Recently buildings that have "rural" official addresses (i.e. the official address references the hamlet or village and the local post town) have been changed to use addr:village for the village and addr:city for the post town, I have noticed. This is all very logical and worth pursuing since the default practice by many mappers has been to use addr:place for the village, or use addr:city for the village and not reference the post town.

Specimen "offcial" address of the format described:-

Lower Marsh Farm <-- House name
Kingston St. Mary <-- location (the village)
TAUNTON <-- Post town (addr:city)
TA2 8AB <-- Postcode

Specimen area of the map where the use of addr:village has been promulgated:- https://www.openstreetmap.org/#map=17/51.02721/-3.14149

Specimen area of the map where the official address is not defined in the tagging as the post town is omitted and addr:city used for the local settlement:- https://www.openstreetmap.org/way/670454492#map=19/50.80851/-3.52558

And specimen "official" address for the same locality:-

Willow Brook
Milford Lane
Thorverton
EXETER
EX5 5NX

Clearly the use of addr:place is incorrect in the usage described above as it is not in compliance with the wiki definition. Evidently the addition of addr:village is a worthwhile extension of the format (there is already addr:hamlet for hamlets and addr:suburb for districts in larger towns; villages are substantially different to hamlets, at least in the UK and most of Europe so their own tag would be desirable). I would thus endorse the introduction by user UKChris.

Can this be implemented merely by usage in editing or does there need to be some change to code or the configuration of routing software as well as an entry in the main addr: wiki page to make it official (sorry - still a bit new at this wiki editing business)? --John Grubb (talk) 21:37, 11 June 2019 (UTC)

Is there a way to enter a <no value> to a building's address?

Sorry if this has already been answered, but I couldn't find anything when I looked through the (many) discussions.

In many cases I have elected to ignore the building's "house address" and instead create a "door adress" with an entrance node. I do this because many of the apartment buildings around where I live have several addresses. It can be as few as "21a-21b" or as many as "34, 36, 38, 40, 42, 44". A single corner building can both be "Queen's Street 12a-b" and "Oak Road 45" at the same time. (I once even lived in a building where I could exit on 3 different streets and 4 different adresses)

I often use StreetComplete to add these addresses, but the screen is being cluttered by adress requests from building that already have a "door adress". Is there a way to enter a "no value" into the address fields to tell softwares like StreetComplete to ignore the lack of address?

I can't just enter "no" as this would be interpretator as "house number no on street no in town no". --Christoffre (talk) 20:39, 5 June 2020 (UTC)

StreetComplete does not ask the housenumber of buildings that have a node with an address on their outline. The entrance nodes that you put the address on should be part of the outline of the building. --Westnordost (talk) 21:48, 5 June 2020 (UTC)
You're right! Thanks! Is this a new feature? Or have I been unnecessarily annoyed for this long? --Christoffre (talk) 10:33, 6 June 2020 (UTC)
It is not new, is was implemented since the beginning --Westnordost (talk) 10:43, 6 June 2020 (UTC)
I found the source to my problem and confusion ... It takes several days for an update to reach StreetComplete, in conjunction with doors that aren't located on the buildings outline (i.e. under a protrusion or in a tunnel passage) --Christoffre (talk) 16:29, 13 June 2020 (UTC)

Addresses in business parks, industrial estates

In commercial and industrial zones, addresses of businesses are often referenced to a defined area (some may even have well-defined boundaries / fence lines). Commercial and industrial areas may have multiple entrances from adjoining streets (or even have named streets running through them).

What is the correct way to tag these?

Example address: Example Limited, Unit 55, Example Industrial Estate, Example City, Example Country

--Dónal (talk) 22:19, 4 September 2020 (UTC)

addr:interpolation=n

The description for addr:interpolation=n (where n is an integer) doesn't make any sense. It indicates every nth house gets a number associated with the definition in the addr:interpolation. But the detailed description says "[use an integer to] indicate the value to increment between house numbers".

Can we improve the wording?

--Dónal (talk) 22:18, 4 September 2020 (UTC)

Few users think parts of addr:* beyond street level should be derived from boundaries

Some users think that components of the Karlsruhe scheme for tagging addresses, in particular addr:city, addr:postcode, addr:country should be omitted since they could be computationally derived from surrounding boundary relations.

They are a minority. Looking at the tagging practice, we have today: 31123818 addr:county, 76 877 627 addr:city, 100 930 830 addr:street, 108 305 709 addr:housenumber.

That means roughly that 76.2% of objects that carry a street address have the city tagged as well, and 30.8% carry the country tag. And the remainder are not all mappers who deny the need of those tags but mostly those that are too lazy to add them.

Where does the opinion come from?

No such claim was in the original Karlsruhe Schema.

On 9 Nov 2016 user Gileri introduced two lines to the Addresses page claiming that POIs should not have their own addresses tagged since "software can usually link adresses to other features by geographical proximity", and "Tags such as Key:addr:country, Key:addr:city, Key:addr:postcode are often redondant as features inside administrative boundaries (when mapped) "inherit" their attributes as supported by software such as Nominatim or Photon" (sic).

On 25 Nov 2017 user Geozeisig wrote twice here in Key:addr that such "Further address tags are optional, since they can be determined from the boundary relations." Another user added "if present and valid".

There was no such discussion in the wiki here, and I checked the tagging list archives from Oct/Nov 2016 and Oct/Nov 2017, but the addr: scheme was nowhere discussed there.

Why we should use a full scheme

  • The scheme was designed to represent the full postal address.
  • Calculating the geographical containment within several boundary relations (e.g. postcode, city, country) is computationally magnitudes more demanding to a data consumer than just showing the tagged address already in the XML.
  • There are frequent exceptions to the containment of an address within a boundary. E.g. take a house that is built at the outskirts of a town. Formally it might stand in the adjacent district, a few meters beyond the boundary, but often it will use the same postal street/city address than the houses it is next to, for convenience. OSM is proud to show such exceptions, based on ground verification. Calculating some address components from the boundary relation will produce wrong results.
  • Similarly, minor errors in a boundary will produce wrong addresses. Occasional vandalism on such boundary will produce massively wrong address results.
  • Calculating the address of a POI from an address node in proximity is extremely error-prone, since another node from the neighbour address might be even closer.
  • In some countries, such as UK, the postcode is more fine-grained and more complex than a boundary relation.

Polarbear w (talk) 14:18, 26 December 2020 (UTC)

Hi! I suppose, there are some strong reasons for simlpe scheme:
  • Adding high-level address information to both buildings and boundaries can easily lead to inconsistent data due to misprints & copy-paste. For example, inside polygon place=city + name=City1 there's a building with addr:city=City2. Which city is correct? SO we'll need special validators and spend additional efforts to keep this matching.
  • It's a good idea to keep full scheme only for objects, which full address can't be correctly detected from boundaries - as in your example. This means that data processing software should prefer tags on building to values calculated from boundaries. But this also makes us sensitive to errors like above - we'll allways take that correct address is City2.
  • In case of renaming place or changing administrative structure there's no need to fix hundreds and thousands tags on all objetcts inside it.
  • It's additional good reason to keep place boundraries on OSM in right state.
AnakinNN (talk) 08:57, 23 February 2021 (UTC)

addr:country

"They are a minority." "30.8% carry the country tag" [citation needed]. "mostly those that are too lazy to add them." - I am pretty sure that it is not true for addr:country. Mateusz Konieczny (talk) 15:58, 26 December 2020 (UTC)

I made quick fact-check - see https://t.me/OpenStreetMapPolska/4568 https://budynki.openstreetmap.org.pl/#map=17.83/52.943252/19.251435 (export to JOSM to see exported address format). Community in Poland considers addr:country to be pointless and not really wanted. Though in discussion topic of addr:city usefulness appeared and there was support for including it. "mostly those that are too lazy to add them." does not really apply here Mateusz Konieczny (talk) 16:07, 26 December 2020 (UTC)
The 30.8% was taginfo country / street = 31123818 / 100930830. If there are major different practices depending on the communities themselves that needs to be adjusted accordingly, thus a larger majority here and a smaller minority there. Anyway it is as useful as the country code for phone numbes, is the PL community using +48 there or not? --Polarbear w (talk) 16:39, 26 December 2020 (UTC)
"is the PL community using +48 there or not?" - no idea. Looking at https://overpass-turbo.eu/s/11AD there is no consistency. Though much more people cares about addresses, we have large scale effort to import usable part of official data right now, involving large part of active editors. Attention to phone number is tiny, tiny part of that - so I would not consider tagging trends there as important indicators. Mateusz Konieczny (talk) 16:42, 26 December 2020 (UTC)

multiple addresses of the same building

I live in a district where most corner buildings have a valid street address for both streets they are on. I checked some of such corner houses in the neighborhood and they have only one street address on OSM, randomly chosen (at least it seems so). I tried to add the other street address but I could not find out how. Is it possible at all? It should be. Torzsmokus (talk) 15:15, 13 April 2021 (UTC)

oh I just found Proposed_features/AddrN, checking it Torzsmokus (talk) 15:22, 13 April 2021 (UTC)
In Poland some buildings have two addresses and we tag them with nodes: https://www.openstreetmap.org/?mlat=50.07127&mlon=19.92675#map=19/50.07127/19.92675 Mateusz Konieczny (talk) 06:43, 14 April 2021 (UTC)
that looks kinda great on the map, but semantically nothing tells that the two addresses belong to the very same building. Torzsmokus (talk) 10:56, 14 April 2021 (UTC)
Note that OSM elements inherently have geometry part! As this points are within building area it specifies that building has this two addresses. Mateusz Konieczny (talk) 20:29, 14 April 2021 (UTC)

What is the benefit of template here?

@Andygol: - why https://wiki.openstreetmap.org/w/index.php?title=Key:addr:*&curid=24699&diff=2424368&oldid=2422517 is an improvement? It seems to just make harder to edit this table Mateusz Konieczny (talk) 13:07, 22 October 2022 (UTC)

The former table was already in a form of template. I do not see any difficulties in editing as we already use templates on this and other pages. Having the template makes it easy to keep pages in other languages in sync. Andygol (talk) 16:01, 22 October 2022 (UTC)
This was a table, not a template. Splitting content to other pages is a barrier to any people. How having this table as a template helps with "keep pages in other languages in sync" (unless it got converted to this horrible hard to edit translating-template that is horrific to edit but actually helps to keep languages in sync so there is some point in that) Mateusz Konieczny (talk) 13:29, 23 October 2022 (UTC)
Now I see {{{addr:door:desc which are probably parameters but I am not sure of what. Dammit, it is confusing Mateusz Konieczny (talk) 13:31, 23 October 2022 (UTC)

on relations

@Gymate: [1] On which relations? maro21 19:54, 24 October 2024 (UTC)

@Maro21 E.g. relation 13362911, which is a tourism=guest_house with two side buildings. The guest house (and its operator) has the address below:

addr:city=Gyöngyös
addr:housenumber=2
addr:postcode=3232
addr:street=Avar utca
addr:suburb=Mátrafüred

Let me know if this is invalid! If it is, a number of relations need to be corrected in Hungary. Gymate (talk) 07:49, 25 October 2024 (UTC)
This doesn't seem correct to me. Tourism=guest_house shouldn't be used on relations, as the article points out. Besides, the address is already assigned to this building. What if such a guest house occupied dozens of buildings? Besides, if an amenity occupies an area, we simply mark it as an area. There is no need to make a site relation. maro21 22:56, 25 October 2024 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Key:addr:*&oldid=2769810"