< Proposal:House numbers

Proposal:House numbers/Bremen Schema

Key:contact:housenumber
Proposal status: Abandoned (inactive)
Proposed by: cracklinrain
Tagging: contact:housenumber=*
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

KeyValueComment
contact:housenumber45analog to addr:housenumber=*
contact:streetBürgermeister-Spitta-Alleeanalog to addr:street=*
contact:postcode45678analog to addr:postcode=*. Discussion about replacement of addr:postcode possible.
contact:cityBremenanalog to addr:city=*
contact:countryDEanalog to addr:country=*
contact:fullDEanalog to addr:full=*
contact:lockbox330440lockbox address of the POI (no analogon existend)
contact:door099analog to addr:door=*
contact:floor0analog to addr:floor=*
contact:unit3analog to addr:unit=*

More analog addr:* keys are possible.

Examples

KeyValue
contact:housenumber53
contact:streetOsterdeich
nameIhr Korbmacher
craftbasket_maker
websitehttp://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

This article is issued from Openstreetmap. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.