Adressentags von Gebäuden

Hallo,

ich trage in meinem Ort (46…)Oberhausen die Hausnummern ein.

Dazu zeichne ich, wenn noch nicht vorhanden, die einzelnen Gebäude an den Straßen ein. Als Vorlage nehme ich dazu Bing, die Hausnummern habe ich mir vor Ort mit meinen Navi besorgt.

Mir ist nicht ganz klar, welche Tags ich den Gebäuden sinnvollerweise zuweisen soll.

Ich persönlich würde folgendes ausreichend halten:
(So habe ich dies auch bei schon vorhandenen Gebäuden in anderen Städten gesehen.)

addr:postcode
addr:street
addr:housenumber

Es gibt jedoch noch weitere Tags

addr:city
addr:country
is_in
postal_code

Wie verwende ich die Tags richtig?

Vielen Danke für die Hilfe,

Hurlie

Schon ganz gut :wink:

is_in ist mMn mausetot, addr:city und addr:country “sterben” gerade. Das liegt daran, dass zumindest bei uns die Grenzen inzwischen sauber drin sind. Viele Mapper sehen daher keinen Grund mehr, diese Tags bei uns zu erfassen.

EDIT: Gerade gelesen, dass du postal_code geschrieben hast: der wird nicht an buildings verwendet sondern nur bei Grenzen. Ab und zu auch bei Straßen, aber das “mag” ich nicht. addr:postcode ist hier richtig.

btw: wo stehen die PLZ eigentlich dran? :wink:

Gruss
walter

Hallo,

so erscheint es mir auch plausibel und nicht redundant.

Eine weitere Frage noch zu Gebäuden mit mehreren Hausnummern (und Eingängen):

Das Gebäude tagge ich mit:

addr:postcode
addr:street

Dann zeichne ich noch für jeden Eingang (mit Hausnummer)
einen zusätzliche Knoten und tagge den mit

Building=entrance
addr:housenumber=(Nummer)

Ist das so richtig?

Gruss

Hurlie

Fast: entrance=yes oder entrance=main und sogar entrance=exit ist üblich. letzteres für Ausgänge, so “komisch” das auch aussieht :wink:

building=entrance ist veraltet, weil ungenau.

Ich trage eigentlich alles an den Eingang:

addr:city=Schmiedeberg
addr:country=DE
addr:housenumber=2
addr:postcode=01762
addr:street=Gartenweg
addr:suburb=Obercarsdorf
entrance=main

suburb=* nutze ich für die Ortsteile einer Gemeinde (addr:city=*)

In der Josm-Vorlage Adresse ist:
addr:city=*
addr:country=DE
addr:housename=*
addr:housenumber=*
addr:postcode=*
addr:street=*

Wobei housename=* bei uns nicht so geläufig ist → Hausnummer.
entrance=main

Ok,

und die Hausnummer dieses Knoten definiere ich dann über:

addr:housenumber=(Nummer)?

Muss hier auch noch mal die Straße und die PLZ angegeben werden?
Oder ist das schon durch die Festlegung bei dem Gebäude erfolgt?

+1.

Ich denke das ist sicher richtig so, aber gibt auch noch Ausnahmen.
Die Grenze ist Gemeinde Ketzerbachtal, aber Adresse ist immer noch Starbach.
In den Garminkarten wird da auch Ketzerbachtal (aus der Grenze) angezeigt, wobei sich mir die Frage stellt wie das zu lösen ist. Noch ein Adminlevel erstellen wäre sicher auch falsch?
PLZ-Grenzen sollen ja auch noch nicht so sauber sein.

Da hast du wahrlich recht - die sind teilweise grottenschlecht. Gerade dort, wo sie sich nicht mit Gemeindegrenzen decken oder wo mehrere Orte eine gemeinsame PLZ haben.
Allerdings fehlt es uns ja immer noch an einer kostenfreien, legalen Datenquelle. Mag eventuell mal jemand die Post erneut anschreiben? (*) Die letzte ablehnende Antwort ist ja schon einige Jährchen alt.

Gruss
walter

*) Behördenkontakt oder wie hier Firmenkontakt ist nicht so mein Ding - da bin ich halt zu schnodderig :wink:

p.s. wer will, kann ja eines meiner “ruhenden” Projekte aufrufen: PLZ-Karte. Funzt halt nur noch nicht so, wie ich es gerne hätte und Zeit dafür fehlt mir derzeit auch.

Das ist hier keine Ausnahme, sondern ein gängiges Beispiel dafür, was passiert, wenn ähnliche Sachverhalte in unterschiedlichen Kategoriesystemen erfasst werden. Man hat ein places=village (Starbach) innerhalb einer Gemeindegrenze Ketzerbachtal (admin_level=8) und einen km weiter mitten im Acker ein places=village (name=Ketzerbachtal und vielen weitere Einträge). Was dann in address:city eingetragen wird, ist Glückssache.

Bei administrativen Grenzen dürfte in Deutschland alles bis admin_level=8 (Gemeinde, Stadt) fast komplett erfasst sein. Level 6 war schon durch den Kreisgrenzenimport von 2008 überall auf ca. 10 m genau. Bei Level 8 gibt es z.T. genaue Daten aus Freigaben der Landesbehörden, z.T. Schätzungen mit Unsicherheiten von 100 m, aber drin sind inklusive Level 7 (Verwaltungsverbände) laut http://ags.misterboo.de/test/?zoom=6&lat=51.3&lon=10.4&layers=B0000FFTFFFFTFT praktisch alle. Die höheren Level 9 (Teilort/Bezirk mit Gremien) über 10 (dto. ohne) bis 11 sind sporadisch als Grenzen vorhanden, oft aber nicht, dazu habe ich auch noch kein Verzeichnis a la AGS gesehen.

Die Einordnung in places ist dazu partiell voll redundant (city, town, village in Sinn von Stadt/Gemeinde), darunter geht das Durcheinander los: Eigentlich ist da eine Abstufung suburb (Vorort, Teilgemeinde?), neighbourhood, hamlet, isolated_dwelling, farm vorgesehen. Genutzt wird das kreuz und quer, anders als bei Grenzen hat man auch keine eindeutig zuordenbare Hierarchie. In Oberschwaben z.B. sind Weiler und Bauernhöfe zu Hunderten als place=village getaggt, was dann in QA-Tools wie http://osm.wno-edv-service.de/residentials (mMn zu Recht) angemahnt wird.

Der places-key wird in der Regel dazu verwendet, Namen zu vergeben und wird deshalb auch gerne von den Renderern genutzt, auf einigen Stufen ist er aber voll redundant und könnte aus den umgebenden boundary-Relationen abgeleitet werden (Das gilt noch viel stärker für den is_in-tag). Er hat eine Berechtigung, solange es noch keine entsprechende boundary (9-11) gibt oder kein entsprechendes area-tag. Beispielsweise landuse=residential ist zu unspezifisch, aber bei landuse=farmyard kann ich alles unterbringen, da brauche ich kein place=farm (ist im Wiki vorhanden, habe ich aber in D noch nie gesehen).

Für Hausnummern / Adressen gibt es seit Langem das “Karlsruher Schema”, das von den allermeisten Mappern verwendet wird und das z.B. auch der Prüfroutine in JOSM zugrunde liegt.

Details gibt es hier: http://wiki.openstreetmap.org/wiki/Proposed_features/De:Hausnummern

Eine Sammlung von Artikeln zum Thema Hausnummern gibt es hier:
http://wiki.openstreetmap.org/wiki/DE:Keypad-Mapper_3
http://wiki.openstreetmap.org/wiki/Keypad-Mapper_3

Danach sind folgende Tags für eine vollständige Adresse erforderlich:

  • addr:country
  • addr:city
  • addr:street
  • addr:postcode
  • addr:housenumber

Ich füge meist noch addr:suburb dazu, weil sich z.B. Berliner anhand der Bezirke orientieren aufgrund der Tatsache, daß es Straßen mit identischen Namen in der selben Stadt mehrfach gibt (in Berlin z.B. Hauptstrasse oder Helmholtzstrasse)

Implizite Zuordnungen von Stadt, Land und PLZ anhand von Grenzen sind formal super, praktisch aber problematisch, weil viele Relationen mit Grenzen defekt sind.
Bessere Ergebnisse der auswertenden Programme sind jedenfalls zu erwarten, wenn jeder Adress-Node vollständig getaggt ist.

Ich halte derzeit die Angaben zu addr:postcode (und auch addr:city) für sehr wichtig, das es immer noch einige Gegenden und besonders größere Städte gibt, wo die PLZ-Grenzen als Relation noch nicht vollständig als Relationen erfasst sind!

siehe dazu die Visualisierung von http://flosm.de → Verwaltungsgrenzen → Postleitzahlen

Auch sind bestimmt einige vorhandene PLZ-Grenzrelationen im OSM-Datenbestand ungenau, schlicht falsch oder veraltet.

Dem kann man fast nur mit den addr:postcode auf Gebäuden beikommen, wenn man dort einen Abgleich macht.

Das Karlsruhe-Schema hat seine Berechtigung, wenn jede Adresse für sich allein aussagekräftig sein soll.
Es hat auch mit allen Einträgen Sinn gemacht, solange die admin-Grenzrelationen unvollständig waren. Das ist in D nicht mehr der Fall.

Street ist sinnvoll, da die Zughörigkeit zu Straßen oft nicht eindeutig ist (Ecken) und auch nur mit erheblich Aufwand abgeschätzt werden kann, housenumber sowieso. Postcode ist noch sinnvoll, da die PLZ-Relationen noch Lücken aufweisen, das gleiche gilt für suburb und die Ortsteil-Grenzrelationen Level 9 bis 11.

City und country aber sind ein Musterbeispiel für (m.E. inzwischen unnötige) Redundanz: Wenn das bei jedem Gebäude eingetragen wäre und sich der Name der Stadt ändert, müsste das in Hunderten bis Tausenden von Gebäuden geändert werden. Das ist so, wie wenn die Bank bei jedem Kundendatensatz den Zinssatz fürs Sparbuch mitführen würde.

Auf dem flachen Land ist das address-Tag gut gemeint, aber praktisch problematisch, da dort nicht so klar ist was eingetragen werden soll: die postalische Adresse, der Name des Dorfes oder der Name der politischen Gemeinde. Bessere Ergebnisse der auswertenden Programme sind nur zu erwarten, wenn die Tags an jedem Gebäude nicht nur vollständig, sondern auch richtig sind. Da hätte ich so meine Zweifel. Wenn in der Grenzrelation ein Fehler ist, muss ich wenigstens nur an einer Stelle suchen/korrigieren.

Als pragmatischen Grund könnte ich höchstens gelten lassen, dass z.B. Routing-Apps die benötigten Informationen schneller finden. Wenn einem das die Redundanz wert ist, bitte schön.

Nicht alles was früher Sinn gemacht hat, macht jetzt noch Sinn. Zumindest sollte man sich von Zeit zu Zeit Gedanken machen dürfen, ob noch alle alten Zöpfe erforderlich sind.

Nach wie vor gilt das Karlsruher Schema und es gibt keinen Konsens darüber, dieses abzuschaffen.
Wir werden es auch mit dem Keypad-Mapper weiterhin forcieren.
Parallel dazu gibt es die Variante, Relationen zu verwenden.
Das Karlsruher Modell zu nehmen und Ort/Land einfach wegzulassen ist jedenfalls nicht wünschenswert weil damit eine erhebliche Fehlerquelle bei der Weiterverarbeitung entsteht sobald eine der Grenzrelationen kaputt ist, und das passiert leider immer wieder. Das bedeutet nämlich, dass ein einzelner Fehler gleich sehr viele Adressen kompromittiert und es ist eben mitnichten sicher dass solche Fehler schnell behoben werden weil Relationen super schwierig zu reparieren sind mit den aktuell verfügbaren Werkzeugen.

Im Übrigen wurde der Diskurs über den Sinn von Relationen bei Hausnummern oft genug geführt und muss hier nicht wiederholt werden. Diesbzgl. hat die Gemeinde auch längst abgestimmt: 95% aller Hausnummern werden defacto nach dem Karlsruher Modell erfasst.

Für den Fall, dass Du die Anwendung des Karlsruher Modells für eine Region infrage stellen möchtest schlage ich vor, dass Du die Community darüber abstimmen lässt damit die Mapper Sicherheit haben bzgl. der von der Community bevorzugten Verfahrensweise.
Bis dahin kann Deine Meinung als Einzelmeinung stehen bleiben.

Redundanz hat zwei Seiten: Zum Einen die höhere Sicherheit, wenn eine der Repräsentationen ausfällt, zu Anderen die Fehleranfälligkeit beim Eintragen oder Ändern, wodurch Widersprüche entstehen. Dazwischen muss man abwägen und diese Entscheidung kann im Laufe der Zeit verschieden ausfallen.
Aktuelle Zahlen aus dem Tagwatch Germany: housenumber 3.34 Mio, street 3.26 Mio, postcode 2.87 Mio, city 2.87 Mio, country 2.48 Mio.
Ganz so einsichtig scheint der Eintrag von city und country dann doch nicht zu sein.

Ich plädiere nicht dafür, das Karlsruhe-Schema komplett abzuschaffen, ich habe nur die Sorge, dass das Projekt OSM langfristig in widersprüchlichem und unwartbarem Ballast erstickt. Nicht umsonst gibt es in OSM die allgemeine Grundregel, Informationen zu einem Objekt nur an einer Stelle abzulegen.

Ein Vorschlag zur Güte: Wenn denn im Keypad-Mapper unbedingt city und country mit erfasst werden soll, dann bitte mit den umgebenden Relationen abgleichen. Wenn sie vorhanden sind, für den Eintrag vorschlagen, ansonsten das Eingabefeld natürlich leer lassen - möge der Nutzer das Richtige eintragen. Damit könnte man die Gefahr widersprüchlicher Eingaben mit diesem Tool deutlich reduzieren und bequemer für den User ist es auch.

@Seichter
der Quellcode vom KPM liegt auf Github. Bau Deine Vorschläge gerne ein, wir übernehmen das dann gerne in die Hauptversion.

Im Übrigen solltest Du Dir den KPM vor den nächsten Postings vielleicht erst mal anschauen.
Dann passen Deine Anmerkungen besser zur Wirklichkeit: KPM editiert keine vorhandenen Daten; das wird in JOSM gemacht und dort gibt es alle dafür erforderlichen Features inkl. der Möglichkeit, Relationen gegen Nodes und Angaben zu Strassen abzugleichen.

Redundanz vs. Relationen: das stoische Wiederholen von längst bekannten und ausdiskutierten Argumenten ist sinnlos. Ich werde mich jedenfalls daran nicht mehr beteiligen.

Bleibt noch meine Frage an Dich nach der Abstimmung: wirst Du Sie initiieren?

Cheers Markus

OK, wenn das alles bis in alle Ewigkeit geklärt ist, klinke ich mich aus.

Mensch seichter,
der Schmollwinkel ist doch nicht der Weg um OSM zur besten Kartendatensammlung der Welt zu machen.
Wir alle ringen doch gemeinsam im sportlichen Wettbewerb der Ideen um die beste Lösung für´s Projekt.
Im vorliegenden Fall sind wir beide unterschiedlicher Meinung - na und? Wir beide mögen OSM und tun was dafür - und das zählt vor allem!!

Weder Du noch ich machen die Regeln sondern der Mehrheitswille der Community ist maßgebend.
Dieser kann sich aus welchem Grund auch immer ändern, da hast Du recht, und deshalb ist es sicherlich sinnvoll, wie von Dir getan ab und an mal Themen zu hinterfragen, allerdings eben möglichst irgendwie strukturiert.

Deshalb fände ich es schon schön, wenn wir bei OSM mit der Zeit eine Kultur entwickeln könnten, die Endlos-Diskussionen ohne Ergebnis ersetzt durch ein in endlicher Zeit ausdiskutiertes Thema mit anschließender Abstimmung über die Mehrheitsmeinung. Das würde Neulingen sehr helfen und auch Mappern, die verunsichert sind, weil ihnen niemand sagt wie sie es am Besten machen sollen.
Ich selbst mappe schon lange und gehöre zu den Top 1000 Mappern in OSM, aber auch ich bin an diversen Stellen unsicher, zuletzt z.B. nach der Diskussion über wheelchair toilets.

Natürlich könnte auch nach einer Abstimmung jeder mappen was er will (Do-Ocracy), aber ich denke schon dass mit einem Abstimmungsergebnis für die Mehrheit der Mapper dann die Richtung klar wäre und sie sich dem Mehrheitsvorschlag anschließen würden mit dem Ergebnis, daß dann auch Renderer und andere Auswertungsprogramme die Daten insbesondere nach den von der Mehrheit vorgeschlagenen TAGs durchsuchen würden.

An alle Mitleser:
wie denkt ihr denn über das Thema Meinungsbildung bei OSM? Lässt sich da was verbessern? Wenn ja was? Und vor allem: wie?

Cheers Markus

Ich nutze Tags wenn sie mir sinnvoll erscheinen, egal ob darüber abgestimmt wurde oder nicht. Für die Hausnummern heisst das, dass ich nur erfasse, was nicht anders zugeordnet werden kann und das möglichst wenig redundant und verständlich (also meist nur addr:housenumber=* und associatedStreet-Relationen). Für Bushaltestellen heisst das, dass ich wo nicht mindestens ein Bussteig oder eine Halteposition erkennbar sind nur ein highway=bus_stop setze.

Für viele der Tags die kaum vernüftig auswertbar sind braucht es eher eine bessere Erklärung warum man etwas auf eine bestimmte Art erfassen sollte oder eben nicht (z.B. surface=cobblestone vs. =paving_stones) als unnötige Abstimmungen, die auch dadurch zum falschen Ergebnis kommen können weil die Erklärungen nicht ausreichend sind.

Ich schließe mich der Meinung von Seichter und rayquaza an.

Adressen soll man intuitiv erfassen können - und ich kann in der Regel nur die Hausnummer (in manchen Orten auch den Straßennamen) am Eingang sehen und den Straßennamen notfalls abschätzen (=> Adresse an die Eingangstür). Für das Routing möchte ich ohnehin an die richtige Gebäudeseite geführt werden.

An größeren Gebäuden mit mehreren Haupteingängen oder mehreren Gebäuden mit gemeinsamer Hausnummer kann auch mal ein Way Adressträger spielen. Die Postleitzahl sehe ich übrigends quasi nie, also klaue ich die auch nirgends (zum Routen braucht die auch keiner, nicht mal der Postbote) :wink: In manchen Orten wäre es auch sinnvoller, wenn statt der “offiziellen Post-Ortsnamen” (den nicht mal die Post bräuchte, weil die ja ihre ID=PLZ hat) der tatsächliche Ort dortstünde (Nein, das ist jetzt kein Änderungsvorschlag für OSM). Nicht selten steht bei uns nämlich ein Auswärtiger im Hauptort rum und sucht verzweifelt die Straße, die in einem anderen Ortsteil (vulgo Nachbardorf) liegt (ja, nicht jeder benutzt ein Navi und/oder sein Hirn). Viele ergänzen/ersetzen daher auch die Ortsangabe bei ihrer Adresse mit dem Dorfnamen…

Die angeblich so hohe Anzahl von associatedStreet-Relationen kann ich nicht beurteilen, jedenfalls sind sie mir bisher kaum begegnet. Die hohe Anzahl von coutry/city/postcode liegt sicherlich an den vielen automatisierten edits (zumindestens in “meinem” Gebiet).