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 
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
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.
Nicht mal, wenn die Relation nicht ganz geschlossen ist.
(Außer bei Rechtschreibfehlern).
Und verwendet Mkgmap tatsächlich eine spatiale Datenbank samt Vorverarbeitung zum Erzeugen der Karten?
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
Bei der Adresszuordnung können separate, aufbereitete OSM-Dateien (“bounds”) mit den Admin-Relationen verwendet werden.
ich fasse das mal als ein JA auf.
Ist das Tool zum Erstellen der “bounds” bei Mkgmap mit dabei oder überläßt er jedem Mkgmap-Anwender die nette Aufgabe, diese bereitzustellen?
Ansonsten könnte man das Karslruher Schema inzwischen - wenn man ganz pingelig ist - auch als “Taggen für den Auswerter” bezeichnen. Ok, es hat für die Auswerter sehr viele Vorteile aber so langsam (2015?) sollte man da mal was reduzieren.
Vorschlag:
Ich stelle “mein” Dorf Wambach gerne als Testobjekt zur Verfügung und schmeiße alle addr:city, addr:country, addr:suburb und addr:postcode raus. (*) Im Extremfall könnte sogar addr:street raus und wird nur dort benötigt, wo eine eindeutige Zuordnung zur passenden Straße nicht möglich ist (z.B. an Ecken). Davon würde ich aber vorerst absehen.
Dazu machen wir eine kleine Tabelle und beschreiben, welche Anwendung das packt und welche nicht.
Motto: Was nicht in OSM drin ist, kann nicht falsch sein.
Gruss
walter
*) Wer will schon nach Wambach?
Moin,
und was falsch ist (Relation), kann dann nicht in OSM drin (Adressen) sein.
siehe
im PLZ-Thread.
Gruß
Georg
Ok, wenn ein Grenzpolygon defekt ist und die Auswertung/Datenübernahme diese aber braucht, haben wir ein Qualitäts-Problem.
Das in den Griff zu bekommen, ist eine starke Herausforderung. Dieser Thread mit dem Thema Notes mit frei definierbaren Tags? beschäftigt sich ja auch mit dem Thema - obwohl ich mit der Lösung per Note nicht konform gehe.
Ich arbeite gerade an einem “Grenzwächter”, der nahezu in Realtime fehlerhafte Grenzen findet und meldet.
Step 1: falsche PLZ in PLZ-Boundaries bei korrekter Geometrie
Step 2: falsche Tags in Administrativen und PLZ-Boundaries bei korrekter Geometrie
Step 3: Meldung bei fehlerhafter Geometrie (*)
Step 4: Meldung bei vom Mapper gelöschten Grenzen
*) das ist der häufigste Fehlerfall. Dabei ist es der Software (bei mir osm2pgsql) nicht möglich, ein “vernünftiges” Grenzpolygon zu erstellen. Und so nebeibei wird die Grenze bisher kommentarlos verworfen. Da ich aber auf PostgreSQL-Trigger aufsetze, ist es eigentlich völlig egal, wer wann wie womit die Grenze geschreddert hat.
Mal sehen, was daraus wird.
Gruss
walter
Das Tool wird beim Download von mkgmap mit ausgeliefert. Man benötigt aber zusätzlich noch osmfilter oder osmosis.
Eine Beschreibung, wie’s funktioniert, findet sich hier: http://wiki.openstreetmap.org/wiki/Mkgmap/help/options#Using_preprocessed_bounds_for_the_address_index
Von Zeit zu Zeit generiere ich diese Dateien aber für den ganzen Planeten. Sie sind hier downloadbar: http://www.navmaps.eu/boundaries
Wenn jemand Interesse daran hat, dies als Job regelmässig auf einem Server laufen zu lassen, kann ich ihm gerne Skripte hierfür zukommen lassen.
WanMil
Moin,
ich muss da nochmal einhaken, bin jetzt erst gerade wieder darauf gestoßen worden:
beides habe ich getan - und musste doch wieder einen Schritt zurück denken:
Es gibt postalische Adressen, die sich nicht über die Grenzrelation abbilden lassen - weil sie nämlich der Nachbargemeinde zugeordnet sind:
Beispiele:
http://www.openstreetmap.org/way/136306277
http://www.openstreetmap.org/way/136306278
Klar, dies ist eindeutig die Minderheit und es lassen sich bestimmt Regeln (er)finden, die dann mit dem vorhandenen addr:city die Relations-Adresse überschreiben … - aber ohne geht es nicht ganz.
Gruß
Georg
Das geht nicht über die admin-Relation, wohl aber über die postal_code-Rel, die es in D inzwischen überall gibt. Die stimmen längst nicht immer mit den admin-Grenzen überein. Müssten in OSMPC als Fehler sichtbar sein, wenn das Gebäude nicht im richtigen PLZ-Gebiet liegt.
Nach Korrektur der PLZ-Grenze ist addr:postcode aus Relation ableitbar.
Auf einem anderen Blatt steht, ob diese Redundanz nicht erwünscht ist, da sich die Information halt viel leichter aus einem Tag als aus einer Geometrie-Relation gewinnen lässt. Im Extremfall hat man die bei einem kleinen Ausschnitt nicht einmal heruntergeladen.
Ich würde erwarten, dass man weiss, dass man in Europa ist wenn man nur die Schweiz lädt, und daher diese Information nicht extra braucht. Oder dass man weiss, dass man in Niedersachsen ist, wenn man nur Hannover lädt; Oder in $Stadtteil von $Stadt, wenn man nur eine Strassenecke lädt. Ebenso bei den Postleitzahlen (falls man sie braucht).
Moin,
klar, machbar ist wie gesagt nahezu alles.
Aber auch hier muss man bereits einen Schritt weiterdenken:
Es betrifft ja nicht nur addr:postcode, sondern auch addr:city.
D.h. man müsste die PLZ-Relation bereits zu einer Addr-Relation erweitern, wenn man es allgemein halten will …
Klar weiß man wo man sich befindet - aber einer Software muss das immer gesagt werden.
Entweder einmal vorher - oder jedesmal hinterher.
Es ist keine Frage, ob man es weiß - sondern wer es wie einträgt - und wer es wie verarbeiten muss/kann.
Eine Frage des Aufwandes vorher (in die Datenbank) und nachher (aus der Datenbank und in die Anwendung).
Und damit auch eine Frage der Machbarkeit.
OSM hat sich das Ziel gesetzt, eine Datenbank für Jedermann zu sein - es nützt aber nicht, wenn Jedermann nur eintragen - aber nicht mehr verwerten - kann.
Gruß
Georg
Aber eine Anwendung müsste ja auch damit zurecht kommen wenn es einen admin_level nicht gibt. Wenn es den eigentlich schon gibt, er aber nicht vorhanden ist weil das geladene Gebiet zu klein ist würde halt z.B. nur “Hannover” statt “Hannover, DE-NI” ausgegeben. Wenn eine Anwendung das tatsächlich selbst braucht (z.B. weil etwas länderspezifisch interpretiert werden muss) wird es wohl auch eine Möglichkeit geben das manuell anzugeben.