Korrekte Adressdaten von einem Dorf, das zu einer Gemeinde gehört

Hallo,

ich habe vor in einem Dorf Häuser einzuzeichnen. Nun geht es mir um die korrekten Adressdaten.
Das Dorf selbst heißt Atzenzell (Bayerischer Wald) gehört aber zur Gemeinde Traitsching. In addr:city und addr:postcode kommt ja dann Traitsching, bzw. die PLZ davon.

Meine Frage. Fällt nun der Name Atzenzell weg, oder gibt es dafür extra Tags um diese Information irgendwo einzutragen?

Danke und Gruß

addr:suburb nimmt man dafür.

Gruss
walter

Super, vielen Dank.

Wenn ich das richtig verstanden habe, nimmt man addr:suburb also für Ortsteile.
Gilt das auch für Stadtteile?
Und spielt es da eine Rolle ob der Stadtteil “innerhalb” der Stadt liegt, oder ob es ein Dorf ist, das eingemeindet wurde?

soweit ich das verstanden habe, ist das egal (ansonsten melden sich gleich die Kollegen und hauen mir auf die Finger korrigieren das).

Gruss
walter

Hallo,

Es ist egal, ob es ein Ortsteil einer Gemeinde ist oder die Gemeinde Stadtrechte hat und es ein Stadtteil ist.

OT: Bei Atzenzell fallen mir die vielen highway=road negativ auf. highway=road ist ein Platzhalter, wenn man nicht weiß, was für ein highway es ist (path, …, track, …, motorway). IMHO wäre im Raum Attenzell track, service und unclassified für diese roads passender. Ein Blick in die History verrät, dass diese Wege zu Zeiten der bayrischen 2m-Luftbild-Spende in OSM kamen.

Wenn man addr:* als postalische Adresse versteht, ist es sowieso egal, was man in addr:suburb einträgt (Unfug natürlich ausgeschlossen) weil Ortsteil (oder auch Bundesland in D (addr:state=*)) nicht Teil der Adresse ist. Nominatim zeigt ohnehin auch nahegelegene Orte/Ortsteile an - somit ist addr:suburb häufig nicht wirklich erforderlich (ähnlich dem “is_in”-Tag).

Ortsteil wird aber in der Praxis gerne verwendet, weil Adressen auch von Nicht-Postlern genutzt werden (addr:state=Bayern habe ich allerdings bisher nur in OSM gesehen).

Moin,

Das Eine ist eben, was eine geographische Suchmaschine auf einer geographischen Datenbank leisten kann (in der Nähe von)…

… und das Andere ist eben, was ein Such-Index (z.B. in einem Navi) leisten kann.
Das Nicht-Vorhandensein von addr:suburb würde eine entsprechende Vorverarbeitung erforderlich machen - die wiederum nicht so ganz ohne ist, denn nicht alles, was ein place ist, ist auch ein Ortsteil …

Gruß
Georg

Schon richtig, aber ich schrieb:

Und was administrativ ein Ort-/Ortsteil/Stadtteil oder was auch immer ist - und was der normale Mensch verwendet, kann nochmal was anderes sein :wink: Ich kenne zum Beispiel Orte, für die noch immer (sogar im BayernAtlas) Namen verwendet werden, die es administrativ seit 200 Jahren gar nicht mehr gibt.

Moin,

muss nochmal “nachtreten” :wink:

Da ist die entsprechende Organisation aber anderer Meinung, siehe
http://www.deutschepost.de//mlm.nf/dpag/images/f/frankiermaschine/dp_automationsfaehige_briefsendungen_2013.pdf
dort Seite 11, Punkt 3.

Gruß
Georg

meine Nachbarstadt heisst “Bad Schwalbach” - nur nennt sie jeder Schwalbach. Da es nun ca 50 Km weiter östlich bei Frankfurt das “richtige” Schwalbach gibt und wir hier auch schon mal Verirrte bei uns hatten, ist folgender Dialog durchaus denkbar:

Tourist: “wo bin ich?”
Einheimischer: “In Schwalbach, wo wollen Sie denn hin?”
T: “Nach Schwalbach”
E: “Ja, da müssen sie Richtung Frankfurt fahren”

Gruss
walter

Erst mal vielen Dank für die ganzen Antworten.

Ich hätte nun noch folgende Verständnisfrage:
Wenn addr:suburb keine so hohe Relevanz hat, wie findet man dann so Orte wie Atzenzell, die ja bei Gebäuden eine “andere Adresse” haben? Mit anderer Adresse meine ich die Adresse der Gemeinde.
Oder anders gefragt. Wo und wie muss/sollte Atzenzell eingetragen werden, damit es in der Suche, oder für Navianwendungen gefunden werden kann, wenn ich nur nach dem Ort und nicht nach der genauen Adresse suche?

Hi,
den Navis steht es frei das addr:suburb auszuwerten. Ansonsten wäre die Info noch was für die
admin_level = 9-11 Relation.

Chris

Es geht jetzt um den Ort selbst, nicht die Adressen von Gebäuden? Dann so: http://www.openstreetmap.org/node/354989078 (bis auf is_in, das ist nicht mehr wirklich Stand der Technik). Und wenn es eine Verwaltungsgrenze Attenzell gibt, dann noch besser diese mit einer Relation abbilden.

Zur Frage “addr:suburb benutzen oder nicht” ein Vorschlag: wenn üblicherweise der Ortsteil mit auf den Briefumschlag geschrieben wird (oder geschrieben werden muß, weil sonst die Post nicht ankommt), kommt der Ortsteil in addr:suburb. Ist das hingegen unüblich (etwa in Großstädten), ist addr:suburb unnötig (schadet aber auch nicht wirklich).

Ich übersetze das mal für Newbies:

Bisher gibt es in OSM eine Grenzrelation für die Verwaltungsgrenze von Kipfenberg. Sowas nennen wird “Administrative Grenze” oder auch AL8 für admin_level=8 (Stadt/Gemeinde).
Wenn du nun die lokalen Grenzen der Dörfer kennen würdest, könntest du die als weitere Admin-Grenzen mit admin_level=10 eintragen.
Danach weiss OSM und auch die meisten der Anwendungen genau, welches Objekt (Haus) sich in welchem Stadtteil befindet. Einfach aufgrund der Spatialen Informationen.

Alle Konstrukte wie is_in=* oder auch addr:suburb oder gar das von mir so gehasste ungeliebte place=* sind mal entstanden, als die Grenzen noch nicht sauber im System waren.

Daher verwende lieber etwas Zeit damit, die lokalen Grenzen einzutragen als Haus für Haus mit immer der gleichen Zusatzinformation zu versehen. Die AL10-Grenzen kann/darf man auch schätzen, was auf dem Land relativ einfach sein sollte.

Gruss
walter

ps: Aber “versau” uns nicht die bestehenden Grenzen :wink:

Einen Schritt weiter gedacht: Warum überhaupt “addr:city” oder “addr:country”? Ist doch alles durch die Relationen kodiert.
Und eigentlich wäre in DE bald dann auch “addr:postcode” unnötig. Man könnte es aber zur Prüfung der Konsistenz gebrauchen.

Sehe ich auch so.

Dafür reichen auch einzelne Objekte, bei denen man z.B. sicher die Postleitzahl kennt, statt wie momentan alle, bei denen man einfach geraten hat…

1+

auch auf die Gefahr hin das ich wieder großen Mist schreibe versuche ich es noch mal :wink:

dadurch spart man sich auch die Arbeit es später zu ändern wenn sich der Name mal ändert, wie bei uns Hilbersdorf kam zu Bobritzsch und ist jetzt Bobritzsch-Hilbersdorf

Absolut korrekt - und wenn man es dann wirklich an die neue Situation anpassen will, übersieht man bestimmt einige Adressen.

Gruss
walter

+1 Exakt.

Moin,

wenn man schon dabei ist, den Namen bzw. die Eigenschaft der Relation zu ändern, dann übersieht der Editor auch keine Adressnodes beim Replace. :wink:
Nicht mal, wenn die Relation nicht ganz geschlossen ist. :wink:
(Außer bei Rechtschreibfehlern).

Und verwendet Mkgmap tatsächlich eine spatiale Datenbank samt Vorverarbeitung zum Erzeugen der Karten? :wink:

Klar ist das Konzept der relationalen/spatialen Datenbank bestechend - und wenn die Konsistenz auch immer schön gewahrt wird und die Tools zur Verarbeitung erstmal erstellt sind, kann sich auch jeder wieder seine nötigen Daten erzeugen.
Dann wäre ich auch sofort mit dabei - aber bis dahin stört mich die Redundanz nicht besonders.

Gruß
Georg