Proposal:House numbers/Bremen Schema

From OpenStreetMap Wiki
Jump to navigation Jump to search
Key:contact:housenumber
Proposal status: Abandoned (inactive)
Proposed by: cracklinrain
Tagging: contact:housenumber=*
Applies to: node, way, area, relation
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