Proposed features/addr keys (2011-04)
| The Feature Page for the approved proposal addr keys (2011-04) can be located at Addr. |
| addr keys (2011-04) | |
|---|---|
| Status: | Approved (active) |
| Proposed by: | flaimo |
| Tagging: | addr:unit, addr:floor, addr:door=* |
| Applies to: |  ,  , 
|
| Definition: | Additional keys for the addr namespace |
| Rendered as: | |
| Draft start: | 2011-04-24 |
| RFC start: | 2011-04-25 |
| Vote start: | 2011-05-29 |
| Vote end: | 2011-06-12 |
Contents |
Outline
This proposal introduces new keys for the addr namespace. It is only meant to deal with information on a micro level (the building itself). It is not a proposal to handle all other additional addr keys people would like to see included in the namespace. Those should be dealt with in separate proposals. That is why the name of this proposal includes the year and month, so it can be distinguished by future addr proposals.
Why would you want to tag these keys
Often bigger buildings like office blocks, shopping malls may have one general house number, but the different offices, flats or shops inside are addressed through a door number, floor number or unit. Since the distance between those kinds of POIs could be more than just a couple of feet, it it relevant to have this information for a more precise routing (probably in combination with associated_entrance.
Keys
All keys are meant to be optional.
addr:unit
While a big building could have only one entrance, sometimes the way inside divides into different units or staircases, where certain apartments/flats/offices can only be reached though a specific unit. An information necessary for postmen, for example.
addr:floor
The floor an apartment/flat/office is located. The value for the floor should always be a number:
- -n = …
- -2 = 2nd basement
- -1 = basement
- 0 = ground floor (UK), first floor (US), Erdgeschoß (DE)
- 0.5 = mezzanine
- 1 = first floor (UK), second floor (US), Erster Stock (DE)
- n = …
addr:door
The actual door to an apartment/flat/office/room. Also, normally a number, sometimes a name. Could also be called differently in some countries (In Austria for example it is sometimes referred to as "Top"). If a room has more than one door, you can tag them separately.
Examples
Unit 419C-419D, 4/F The Mega Atrium, SM Megamall, EDSA cor. Julia Vargas Avenue, Ortigas Center, Mandaluyong
- addr:city=Mandaluyong
- addr:street=EDSA cor. Julia Vargas Avenue
- addr:housename=The Mega Atrium, SM Megamall
- addr:unit=419C-419D
- addr:floor=3
Wiener Straße 23, Stiege 2, Tür 33, 1020 Wien, Österreich
- addr:country=AT
- addr:city=Wien
- addr:postcode=1020
- addr:street=Wiener Straße
- addr:housenumber=23
- addr:unit=2
- addr:door=33
Additional information
- level: Ideas on indoor mapping
Changes based on comments from the RFC phase
-
Added addr:room= (seav)removed again, since rooms are more of an internal ID, then an address information. - Changed addr:staircase= to more generic term addr:unit= (seav)
- Removed addr:entrance= since it was a bit controversial.
Voting
Voting is open until 2011-06-12. Please vote with {{vote|yes}} or {{vote|no}} and sign with ~~~~. If you oppose, please put your reason on the comments page and not in this voting chapter.
- I approve this proposal. --Flaimo 20:53, 28 May 2011 (BST)
- I oppose this proposal. This proposal is passing my line of accepted details. Approving this I wait until we are going to tag the way windows are isolated. ;-) Please do not be scared you will be out of work. Germany has a lot to do within the range of existing tags.
- I approve this proposal. --Jstein 22:40, 28 May 2011 (BST)
- I approve this proposal. --Fabi2 23:43, 28 May 2011 (BST)
- I approve this proposal. --seav 06:46, 29 May 2011 (BST)
- I approve this proposal. --Polyglot 07:23, 31 May 2011 (BST)
- I oppose this proposal. -- If we want to amend the address-tags I'd like to add all needed tag extensions in one go. This proposal is not covering staircases any more (because unit is not a replacement for staircases, you could have several staircases in one unit), it is not covering building parts (de:"Seitenflügel links", "Hinterhaus", "2. Hinterhaus", ...), it does not define unit well enough (could be apartment, staircase, building part, site, ...), does not cover apartment numbers, ... Dieterdreist 13:55, 31 May 2011 (BST)
- do you have a real life example where a building does have multiple units and staircases at the same time? even if such cases exists, it could be written as addr:unit=Unit1/Staircase1 and addr:unit=Unit1/Staircase2. you criticize the definition of "unit", yet you are not telling what you think is unclear about it. also if you like to see other subkeys, just start a proposal for it. the reason why they are not covered here is in the first paragraph of this page. --Flaimo 21:23, 31 May 2011 (BST)
- I oppose this proposal. --It would get messy if you added a node for every office. How would you tag two offices on different floors? To distinguish between these 2 nodes you would have to move them to the side (You can't really put them on top of each other). A huge shopping mall would become littered with nodes. Especially when GPS loses accuracy inside buildings nodes for such detailed mapping are pointless. If you tried to include these details in a relation or something like this I would approve it. A relation would suit this much better. LetzFetz 18:02, 1 June 2011 (BST)
- you would tag it exactly like you would tag other overlying features in OSM. btw, if there are dozens, even hundreds, of shops in a shopping mall, they will get tagged anyway, with or without address information. if you want a relation you can vote for this proposal later on: http://wiki.openstreetmap.org/wiki/Proposed_features/associatedAddress --Flaimo 19:24, 1 June 2011 (BST)
- I approve this proposal. But I'd prefer more address types, including those that were dropped from this proposal. --Zverik 11:55, 6 June 2011 (BST)
- the ones i dropped are the more controversial ones. but that doesn't mean that they can't be proposed again later on. --Flaimo 15:34, 11 June 2011 (BST)
- I approve this proposal. --Lulu-Ann 12:37, 10 June 2011 (BST)
- I oppose 2/3 of this proposal. "door" and "floor" are too much detailed for OSM. However, I think we could give a go to unit, for large buildings. --Don-vip 19:32, 11 June 2011 (BST)
- I approve this proposal. --Nfgusedautoparts 21:54, 11 June 2011 (BST)
- I oppose this proposal. --amai 23:39, 11 June 2011 (BST)
- I am OK with this proposal. Just add it to the schema and let users decide whether to use it or not. --achadwick 11:21, 14 June 2011 (BST)
- I oppose this proposal. The addr-namespace if for delivery and addr:full already covers special needs for that! For other information we have ref and name. Also have a look on Proposed_features/Building_attributes and Relations/Proposed/Level! --phobie m d 18:21, 30 June 2011 (BST)
Post voting changes
