House numbers/Bremen Schema
|Status:||Draft (under way)|
|Applies to:||, , ,|
|Definition:||Adresses for POIs|
|Rendered as:||No rendering.|
The Bremen Schema or extended Karlsruhe Schema proposes to add contact information about a POI to the node via using contact:* instead of adding addr:* since there is already the particular address existent.
|contact:housenumber||45||analog to addr:housenumber=*|
|contact:street||Bürgermeister-Spitta-Allee||analog to addr:street=*|
|contact:postcode||45678||analog to addr:postcode=*. Discussion about replacement of addr:postcode possible.|
|contact:city||Bremen||analog to addr:city=*|
|contact:country||DE||analog to addr:country=*|
|contact:full||DE||analog to addr:full=*|
|contact:lockbox||330440||lockbox address of the POI (no analogon existend)|
|contact:door||099||analog to addr:door=*|
|contact:floor||0||analog to addr:floor=*|
|contact:unit||3||analog to addr:unit=*|
More analog addr:* keys are possible.
I experience the Karlsruhe-scheme for contact-data (i.e. adding addresses to POIs) as inappropriate and misleading.
We have the following Problem: A contributor would like to add a shop to an already entered building with its own housenumber.
1. The contributor adds the contact-data, hence the housenumber, via the Karlsruhe-scheme to the node or way (not the building-way) and ends up in a double-housenumber error. (Since you do not agree: Mapnik for example renders each of those housenumbers since there is enough space.)
2. Unfortunately the contributor wants to add the housenumber of a shop which has a number like 12-16, but those three numbers are spilted onto three buildings with one of those housenumbers each. The housenumbers also belong to the addresses of flats and other shops and offices. Hence the contributor has to create a double-housenumber-error.
3. At least one of those buildings contains another shop or office which should hold the housenumber, too. No way - the contributor has to do it double, since there is nothing implemented which applies the housenumber from the building-way.
3a. Just imagine there is another contributor moving the building finally to the right spot and forgets the shop-node. Somebody could notice the mistake, but the contributor also moved the neighbouring building=*. Hence the node seems to be on the right spot. (But of course in the wrong building.)
3b. Just imagine the tons of double-housenumbers since somebody adds addr:housenumber=* to every shop in a Mal.
4. Imagine a building with several entrance=*s and each of those has its own housenumber. A beautiful way to handle this is to add the addr:housenumber=*-Key to the entrance. Since there are two shops at the same address there is no way to avoid a double housesnumbers.
There is an other proposal to solve this issue - the relation Relations/Proposed/Provides feature