DE talk:Proposed features/House numbers/Karlsruhe Schema

From OpenStreetMap Wiki
(Redirected from DE talk:Karlsruhe Schema)
Jump to navigation Jump to search

Orte mit Strassen ohne Namen

Auf dem Land werden in kleinen Orten oft keine Strassennamen vergeben. Die Häuser erhalten (meist) in der Reihenfolge ihrer Fertigstellung eine fortlaufende Nummer. Diese Hausnummern sind folglich höchst unregelmässig und meist ohne erkennbares geografisches System verteil. Die Strassen haben logischerweise keine Strassenschilder.

Die Deutsche Post AG gibt für solche Fälle folgendes Adressierungsschema vor: 

Empfängername
OrtsnameAlsStrassenname Hausnummer
PLZ Ortsname

Ich vermute, für Routingprogramme ist es hilfreich, wenn sie dieses Adressierungsschema auch im Strassenverzeichnis finden:

Ort Strasse
OrtsnameMitUnbenanntenStrassen Ortsname
OrtsnameMitBenanntenStrassen Strassenname

Das würde für die Attribute in Orten mit unbenannten Strassen bedeuten: 

highway=residental
+ name=Ortsname

und für die Häuser: 

building=yes
+ addr:housenumber=###
+ addr:street=Ortsname
+ addr:postcode=#####
+ addr:village=Ortsname

Meinungen? Erfahrungen? Danke, --Markus 22:30, 4 September 2008 (UTC)

Häuser mit mehreren, postalisch unterschiedlichen Eingängen

Bei Häusern mit mehreren, postalisch unterschiedlichen Eingängen möchte ich vorschlagen, diese wie folgt zu taggen.

Man setze für jeden Eingang einen Node in den way der Fläche des Hauses und tagge diesen mit den jeweiligen Adressinformationen. Die Nodes lassen sich, wenn das Gebäude nicht als Fläche vorhanden ist, per Relation zu einer Gebäudeeinheit zusammenfassen, siehe dazu:

http://wiki.openstreetmap.org/index.php/Relations/Proposed/Buildings

--René Falk 15:11, 18 September 2008 (UTC)

Nun, in Wien ist es so, dass (fast) jedes Eckhaus automatisch eine Postadresse (inkl. eigener Hausnummer) für jede Straße hat, jedoch (fast immer) nur einen Eingang. Jetzt macht es natürlich Sinn, dass im ersten Schritt nur jene Adresse in OSM angelegt wird, zu der es auch einen Eingang gibt, da sie zu 99 % auch die Adresse ist, die im Postverkehr benutzt wird. Wie (bzw. wo) soll aber die zweite Adresse angelegt werden? P.S.: Das gleich würde ja auch auf historische Adressen zutreffen. -- MapFlea 10:13, 1 December 2008 (UTC)

Mehr als eine Hausnummer für ein einzelnes Gebäude/Node

Hab das auch schon auf der englischen Diskussion gefragt. Wie sollten wir Situationen behandeln in denen ein Gebäude mehr als eine Hausnummer hat? Zum Beispiel haben größere Geschäfte häufig Adressen wie "Schönestr. 12-17", wie sollen wir sowas taggen? addr:housenumber=12-17 (evtl. ein anderer Trenner) oder addr:housenumber=12,13,14,15,16,17? Ich denke ich bevorzuge die kürzere Variante, aber die lange sollte auch unterstützt werden, damit man so etwas wie addr:housenumber=34,36,37,56 darstellen kann. Im Moment benutze ich dieses Schema: addr:housenumber=12-17. --Patzi 06:46, 19 September 2008 (UTC)

Am häufigsten vertretenes Verfahren scheint eigentlich ein Node für jede Nummer zu sein, u.U. an den jeweiligen Eingängen (ggf. auch nur Start und Ende mit Interpolation). Ich muss auch sagen, dass ich es nicht so toll finde, den Anwendungen noch ein bis zwei weitere Sachen zum Parsen aufzuladen, das Karlsruher Schema ist mit seinen sehr vielen Sonderfällen (Nodes oder Flächen oder Interpolation, Straßenbezug über a) Nähe b) Straßenname c) Relation …) schon kompliziert genug. --Tordanik 17:54, 19 September 2008 (UTC)
ich glaube offiziell hat zB 3-5 eine andere Bedeutung und 3 4 und 5.--Shmias 21:42, 23 March 2009 (UTC)
Es fehlte ja nur zu sagen, wie interpoliert werden soll. Also even, odd oder all.--Cracklinrain (talk) 13:22, 20 June 2013 (UTC)
Dieses Problem sollte vielleicht schon gelöst werden. Auf den Personalausweis kann man z.B. keine 25-29 eintragen lassen. Es ist dann nur eine Zahl möglich. Wenn man also die Schreibweise mit Bindestrich wählt sollte man auch eingeben könne, dass z.B. nur über die ungeraden interpoliert wird.--Cracklinrain (talk) 13:22, 20 June 2013 (UTC)

Relationen und mehrteilige Straßen

Für die Relations ist derzeit nur die Angabe eines Way-Elements angedacht. Das ist ungünstig, wenn die Straße aus mehreren Way-Elementen besteht, was oft nicht zu vermeiden ist. Ich würde daher vorschlagen

  • mehrere Ways zuzulassen
  • diese Relation gleich als "Container" für alle Ways einer Straße zu nehmen, wie es unter Relations/Proposed/Collected_Ways vorgeschlagen wird. D. h., beide Anliegen sollten zusammengeführt werden. Sonst müsste man zwei fast identische Relations pro Straße anlegen, das ist unnütz.
ACK. Hinweis: Eine Straße kann in zwei oder mehreren PLZ-Bereichen liegen, dann macht die Auftrennung in n Relationen Sinn. --Elwood 12:17, 12 November 2008 (UTC)
NOACK. Ich würde vorschlagen, die Relation, die Strassensegmente zusammenfasst (type=street) als Member für die Relation (type=associatedStreet,role=street) zu verwenden. Damit wird redundante Speicherung dieser Daten verhindert. --Andre68 18:19, 13 November 2008 (UTC)

Außerdem wäre es m. E. sinnvoll, übergeordnete Hierarchiestufen für Orte und PLZ-Bereiche einzuführen um Redundanzen zu minimieren. Die Relation für einen PLZ-Bereich fasst alle Straßen (bzw. deren Relationen) zusammen, die die gleiche PLZ besitezn. Die für Orte diejenigen Straßen, die zu einem Ort(steil) gehören. Je nachdem, ob ein (großer) Ort aus mehreren PLZ-Bereichen besteht oder ein PLZ-Bereich mehrere Orte (Dörfer) zusammenfasst, brauchen nur die Unterrelationen eingebunden zu werden.

ACK. --Andre68 18:19, 13 November 2008 (UTC)

--Plasmon 18:58, 11 November 2008 (UTC)

Gibt es jetzt, nachdem diese Diskussion vor nunmehr 2 einhalb Jahren beendet wurde, einen Konsens wie man mit mehrteiligen Straßen in Bezug auf associated_street-Relationen verfährt? JOSM gibt nämlich immer noch Warnungen heraus, wenn in dieser Relation mehrmals die Rolle street vergeben wurde. --HawkPat 10:22, 20 May 2011 (UTC)

Kannst Du JOSM-Probleme bitte auf der JOSM-Seite diskutieren? Ich als Potlatch-User bin an diesem Problem nicht interessiert. --Lulu-Ann 14:11, 10 June 2011 (BST)
Das ist kein JOSM-Problem, denn JOSM hält sich einfach nur an die Dokumentation im Wiki. Und wo, wenn nicht im Wiki, sollte man Probleme mit der hiesigen Dokumentation diskutieren? Ich als addr:street-User bin an dem Problem aber eigentlich auch nicht besonders interessiert. --Tordanik 14:28, 10 June 2011 (BST)

Gebäude, die sich an zwei Straßen befinden

Gebäude, die sich an an einer Kreuzung befinden haben manchmal mehrere Eingänge, jeder an einer anderen Straße. Also hier ist für ein Objekt quasi mehrere Adressinformationen zu verzeichnen. Was nun?--Shmias 21:55, 23 March 2009 (UTC)

Ich würde sagen: Die Straße, die auch in der Anschrift des Gebäudes verwendet wird?

Ortsteile

Im Feld addr:city wird ja die übergeordnete Gemeinde bzw. Stadt angegeben. Ein solches Gebilde umfasst ja meist auch einzeln benannte Ortsteile, die mitunter weit von der betreffenden Stadt entfernt sein können. Möglicherweise wissen die Adresssuchenden mitunter gar nicht, dass die Straße im Ortsteil gar nicht zu der betreffenden Stadt/Gemeinde gehört. Sollte man nicht deshalb noch ein weiteren Key für den Ortsteil einführen? Z.B. addr:locality neben addr:city für Gemeinde/Stadt.

Beispiel: Die Straße "Friedberger Straße" liegt im Ortsteil Melbach der Gemeinde Wölfersheim Derzeit sind die Adresstags: addr:city = Wölfersheim addr:street = Friedberger Straße addr:postcode = 61200 addr:interpolation addr:country = DE gibt als Ergebnis der Suche (z.B. in Navi): Friedberger Straße, 61200 Wölfersheim. Wölfersheim ist aber 2 km entfernt. Mit einem zusätzlichen Tag "addr:locality = Melbach" könnte das Ergebnis sein:

Friedberger Straße, 61200 Wölfersheim OT Melbach.

Das halte ich für ein zu bevorzugendes Ergebnis für Leute, die über die Verwaltungszugehörigkeit des Zielortes keine Vorstellung haben. Eventuell müsste man noch für locality einen geeigneteren Key finden, z.B. village etc. Was haltet ihr davon? Longbow4u 14:28, 24 September 2009 (UTC)

Ich nutze das tag addr:locality . Da es durch die Eingemeindungen von Ortsteilen zu doppelten Straßennamen unter der gleichen Postleitzahl kommt, wäre dies auch für Router zur Auswertung angebracht. In vielen Ortsteilen gibt es fast immer eine "Dorfstraße" oder "Siedlung" oder "Hauptstraße"

Auch bei der Post wird die Angabe (optional) unter dem Namen/Firma vorgeschlagen:

Name des Empfängers

Nähere Empfängerbezeichnungen (optional)

Ortsteil (optional)

Zustell- bzw. Abholangaben

PLZ Bestimmungsort


http://www.deutschepost.de/dpag?xmlFile=1004048&lang=de_DE

Es kann auch für die Benennung von Stadtteilen genutzt werden.

Als tag für den Ort nutze ich:

is_in:(offizieller Gemeinde-/Stadtname nach PLZ) name:* place:village/suburb/...(nach http://wiki.openstreetmap.org/wiki/Key:place)

Beispiel: http://www.openstreetmap.org/?lat=50.85989&lon=13.66278&zoom=15&layers=M --Geri-oc 08:30, 17 July 2011 (BST)

Relations

Ich hab zwei Fragen zu den Relations: Zuerst eine Feinheit, die wahrscheinlich nur ein Formulierungsprobem ist: Warum steht da dran , dass es nur eine Straße in der Relation geben kann, es kommt schließlich häufig genug vor, dass die Straßen in mehrere Teile zerstückelt sind.

Die wichtige Frage ist, worein dann die weiteren Adress-Tags wie addr:postcode, addr:country, etc. geschrieben werden sollen. Ich habe dazu nichts weiter gefunden (vielleicht bin ich auch blind). Ich mache es derzeit so, dass ich sie in die Relation reinschreibe, da es, wie oben erwähnt, passiert, dass eine Straße in mehrere Teile zerstückelt ist und man sich so das mehrmalige eintragen spart. Der Nachteil ist, dass es sich mit den bisherigen Eintragungsarten beißt, da dabei die Daten direkt an die Straßen vergeben wurden. Der Renderer müsste also beides überprüfen. Ich wäre dennoch dafür es in die Relation mit aufzunehmen. Wie habt ihr das bisher gelöst, bzw. wurde das schon irgendwo besprochen? --T3QU1LA 20:54, 16 October 2009 (UTC)

Routing zu Eingängen

Um Routing für Blinde zu ermöglichen, sollen die Hausnummern nicht irgendwo am Gebäudeumriß angebracht werden, sondern mit einer Node building=entrance am Eingang getaggt werden. Es wäre schön, wenn die Anleitung dementsprechend präzisiert werden könnte. --Lulu-Ann 16:36, 22 January 2010 (UTC)

Meiner Ansicht nach sollten die Hausnummern sehr wohl als Tags des Gebäudeumrisses angebracht werden, sofern sie fürs ganze Gebäude mit allen seinen Eingängen gelten. Wenn der Gebäudeumriss außerdem einen geeignet mit z.B. building:entrance=yes getaggten Eingangsnode (oder mehrere) enthält, ist die Zuordnung ja trotzdem möglich.
Ein Eintragen prinzipiell am Eingang wäre keine "Präzisierung", sondern schlicht eine Änderung der bestehenden Vorgehensweise. --Tordanik 23:11, 23 January 2010 (UTC)
Hier gibt es scheinbar keine stringenten Vorgaben: "There is currently no consensus on this. Here are some possibilities: " Ich finde es allerdings sehr sonderbar, dass man sich nicht auf eine Methode einigen kann, in der es eine Default gibt und dann alle nötigen Ausnahmen aufgeführt werden. Dass man Knoten, die innerhalb der Gebäudewege zulässt finde ich nicht OK. Dass man eine Hausnummer an die Stelle des Einganges auf dem Gebäudeweg macht, halte ich für selbstverständlich, wenn man weiß wo dieser liegt. Das heißt also, dass man entrance=* setzen sollte, aber ich muss diese Methode als default ablehnen, da nicht jeder weiß, wo der Eingang eines Gebäudes ist. --Cracklinrain

Gestrichelt?

Was bedeutet die unterschiedliche "Strichellung" (also ---- oder - - - - -) bei der Hausnummern? Dazu konnte ich keine Erklärung auf der Seite finden....

Gerade oder ungerade Interpolation.
Oder über alle natürlichen Zahlen (all).

Doppelte Hausnummern durch Adressen an (Geschäfte-)knoten

Es gibt zunehmend das Problem, dass jemand einen Node eingibt, der z.B. ein Geschäft oder anderes beschreibt, das eigene Kontaktinformationen und die bereits am Gebäude vorhandene Hausnummer ein weiteres Mal enthält.

Ich kann teilwese verstehen, dass so etwas gemacht wird: Man hat die Daten erfasst und möchte nicht, dass sie schließlich bei einer Überarbeitung der falschen Hausnummer zugeordnet werden oder man möchte, dass bei einer Sache nach dem Objekt auch die Hausnummer mit ausgegeben wird.

Solange es nichts gibt, das einem Geschäft innerhalb eines Gebäudes nicht die Hausnummer des Gebäudes automatisch zuordnet, ist diese Sache ziemlich unfertig und sorgt für Datenwust. Falls da keine Lösungen in absehbarer Zeit geplant sind, werde ich ein Proposal formulieren, dass eine Hausnummer anhand von contact:housenumber erfasst. Hausnummern gehören für mich weiterhin an Gebäude (oder an Knoten, die Elemente des Gebäudes sind). Wenn diese vorhanden sind, sollte es keine weiteren Knoten geben (Ausnahmen sind natürlich unzureichend erfasste Gebiete).

Ein weiteres Problem sind Hausnummern von Gebäuden, die so nicht in der Anschrift eines Geschäfts genutzt werden. Konkret geht es dabei um Geschäfte, die sich über mehrere Häuser erstrecken, in denen jeweils Wohnungen mit unterschiedlichen Anschriften befinden, aber eine Sammelhausnummer wie 17-22 haben.

BTW: Ich wundere mich, dass ich hierzu nirgendwo eine Diskussion oder anderes entdecken konnte. Bitte ggf. auf solch eine verweisen.

--Cracklinrain (talk) 23:07, 17 June 2013 (UTC)

Warum willst du den zwingend an nem POI-Node nochmal die Adresse stehen haben? Wenn jemand ne vollständige Liste aller POIs mit Adressen haben will muss er halt auch schauen in was für nem Gebäude der POI liegt und welche Adresse das Gebäude hat. Das ist mit jeder vernünftigen Geo-Datenbank ne relativ einfache Übung. Bei OSM ist es halt nun mal so das viele Sachen redundant erfasst sind. Ein weiteres Proposal zu formulieren macht für mich da gar keinen Sinn. Übrigens ist es durchaus ne valide Form Hausnummern durch Nodes zu taggen die in einem Gebäude liegen, aber nicht mit diesem verbunden sind. Und die werden halt oft gleichzeitig als POI missbraucht. --Andi 10:43, 20 June 2013 (UTC)
Die Leute wollen die Anschrift des POIs erfassen. Was in OSM gespeichert ist, sind aber die Adressen von Orten. Das Schema soll sich nur mit Abweichungen beschäftigen und nicht den Regelfall behandeln, der durch klare Formulierungen im Wiki erklärt werden könnte. Mir geht es letztlich nicht darum etwas redundant einzugeben, sondern etwas, das so nicht in de Daten vorhanden ist oder man nicht aus ihnen erhalten kann (siehe oben: POI, der über mehrere Gebäude verteilt ist).
Hausnummern mit Knoten innerhalb eines Gebäudes sind ähnlich zu Hausnummern auf Knoten eines Gebäude-Weges und führt in seltenen Fällen zu dem Zuordnungsproblem, das dieses Schema lösen soll.
In manchen Fällen mögen Hausnummern als Knoten innerhalb von Gebäuden keine Probleme hervorrufen, aber als finales Tagging ist das absolut inakzeptabel für weitere Editierungen am Gebäude oder um Hausnummerfehler zu vermeiden. Sind es mehr als zwei Knoten bietet sich in einigen Fällen ohnehin eher die Interpolation an, die die deutlich bessere Alternative zu einzelnen Knoten ist, sofern anwendbar (Probleme gibt es z.B. mit Buchstaben in Hausnummern: 1a-1c). Zudem sind einzelne Knoten nicht die schönere Methode und machen auch nicht zwingend weniger Arbeit. --Cracklinrain (talk) 13:12, 20 June 2013 (UTC)
Dann schau dir mal an wie KeypadMapper arbeitet und wie viele Hausnummer auf welche Art und Weise gemappt sind. Die Editoren müssen das "Problem" dann halt wegabstrahieren. Ein contact:* Schema würde die User ja grade dazu ermutigen zeug nochmal einzutragen. Da ist es mir dann doch lieber, addr:housenumber=1-25 für die paar Sonderfälle wo sich Firmen über mehrere Hausnummern erstrecken zu Missbrauchen. --Andi 15:13, 21 June 2013 (UTC)
Danke für den Link zu KeypadMapper. Das mit den .osm-Files wusste ich noch nicht. Das hat aber leider nichts mit dem Problem zu tun (auch Hausnummerverteilungen und Häufigkeiten nicht). Ich finde ja gerade, dass wenn eine Firma/Unternehmen meint, sie hätten die Adresse 17-30, dass sie das dann von mir aus machen können, aber wir erfassen die Hausnummern an den Eingängen der Gebäude. Das heißt, dass ich gar nicht möchte, dass wir diese 17-30 an irgendeinem Gebäude erfassen (wenn diese auf mehrere Gebäude mit Hausnummern verteilt ist), sondern in dem Knoten oder den Weg für den POI. Aber für so etwas können wir nicht addr:* nehmen (Denn addr:* gehört für mich ans Gebäude). Den Vorschlag Adressen (implizit) doppelt zu mappen spricht dagegen Sachen doppelt zu mappen. --Cracklinrain
Das sieht die breite Maße wohl anders. Nur rund 38% der Hausnummern hängen direkt an Gebäuden (Objekte mit building=yes). [1]. Aber wenn du mehr Feedback bekommen willst frag doch mal auf tagging@lists.openstreetmap.org. --Andi 17:58, 24 June 2013 (UTC)
Und zu den 62% der übrigen Hausnummern existiert nur bei 30% ein building=yes. Du musst die Mapper schon fragen, was sie als Tagging-Ziel möchten und nicht einen temporären Status als Meinung werten. --Cracklinrain 24. Juni 2013, 21:13 Uhr --Cracklinrain (talk) 21:15, 24 June 2013 (UTC)
Bitte unterschreib deine Beiträge. Da gibt es oben beim Bearbeiten den vorletzten Button... Kannst du das deine Zahlen mal erklären, ich versteh die Aussage so nicht. Ansonsten: so lange wir keine Abstimmungssystem, haben ist TagInfo der beste Weg zu schauen was die meisten machen. Proposals sind da keine Lösung. --Andi 20:13, 24 June 2013 (UTC)
Bevor ich auf meine Zahlen eingehe: Das ist nur building=yes. Also kann man mit der Zahl noch nicht viel machen. --Cracklinrain (talk) 21:15, 24 June 2013 (UTC)

Erweiterung des Schemas

--Dresl (talk) 11:54, 22 January 2015 (UTC)

Zum Thema Redundanz hätte ich noch einen Vorschlag: So, wie ich Straße und Gebäude in einer Relation erfasse, könnte ich doch die Strassen und die Stadt zusammenlegen. Das hiese, z.B: den Node "Stadt" mit addr:Country/city/postcode taggen und somit würde ich die Adresstaggerei an Straßen sparen.

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=DE_talk:Proposed_features/House_numbers/Karlsruhe_Schema&oldid=1322144"