From OpenStreetMap Wiki
Jump to: navigation, search

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 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)
(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:

  • 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?


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)


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)


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 ( 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.


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)


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: (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

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 (XML, Potlatch2, iD, JOSM, history):

name=Aéroport Rennes Bretagne
addr:postbox=BP 29155
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)
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
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:

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: ). 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)