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.