Proposal:House numbers/Bremen Schema

Key:contact:housenumber
Proposal status:	Abandoned (inactive)
Proposed by:	cracklinrain
Tagging:	contact:housenumber=* Data item
Applies to:	, , ,
Definition:	Adresses for POIs
Statistics:
Rendered as:	No rendering.
Draft started:	2013-06-20

Proposal

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.

Tagging

Key	Value	Comment
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.

Examples

Key	Value
contact:housenumber	53
contact:street	Osterdeich
name	Ihr Korbmacher
craft	basket_maker
website	http://www.korbmacher.de/

Motivation

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.
   1. 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.)
   2. 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.

See also

There is an other proposal to solve this issue - the relation Relations/Proposed/Provides feature