Strukturierung der OSM-Daten für Navigationszwecke

Hi, ich arbeite mich z.Zt. ein bisschen intensiver in die Nutzung von OSM in Navigationssoftware ein, konkret am Beispiel von Navit. Wie ich gelesen habe (was aber auch leicht nachzuvollziehen ist) ergeben sich aus der zusammenhangslosen (mir fällt keine bessere Bezeichnung ein) Eintragsstruktur bei OSM Probleme für die Navigation: Da Straßen z.B. ohne Hinweis auf den übergeordneten Ort (Stadt oder Dorf) eingetragen werden, verwendet Navit - so weit ich das verstehe - eine Annäherungsabschätzung, um Straßen Orten zuzuweisen. Dies macht die Zielsuche natürlich recht schwierig. Ähnliches scheint für die Verbindung von Orten mit PLZ zu gelten. Meine Frage ist deshalb, ob es eventuell Bestrebungen gibt, hier eine stärkere Strukturierung der Geodaten zu erreichen?

Darüber hinaus würde mich interessieren, ob eine Doku existiert, wie die Auswertung des OSM-Datenbestands unter Navit erfolgt. Ich weiss, dass dies eigentlich eine Frage für das Navit-Forum wäre, doch aufgrund der sehr unterschiedlichen Aktivitäten in beiden Foren rechne ich hier eher mit einer Antwort… :wink:

Ich wäre über Hilfe oder Verweise auf weiterführende Informationen recht dankbar.

robart

Hallo, wie das unter Navit genau läuft kann ich dir nicht sagen aber
das steht unter map/ irgenwo in den sourcen dieses osm-importers.

Was die Tags und Adresen angeht, habe ich alles unter
http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing
dokumentiert.

Ich selber verwende bei
der AdvanedAdressDB (Traveling Salesman hat die Adress-Suche als
Plugin und mehrere mögliche Implementierungen)
http://travelingsales.svn.sourceforge.net/viewvc/travelingsales/trunk/libosm/src/org/openstreetmap/osm/data/searching/
das folgende Vorgehen:

  • wenn ein Polygon mit “place=” und einem Namen getaggt ist, dann ist das die exakte Begrenzung der Stadt
  • wenn nur ein Node aber kein Polygon existiert, wird ein konfigurierbarer Radius verendet. (macht Navit wohl auch so)
  • wenn “is_in:city” getagged ist, hat das immer Priorität, kann ich aber leider nicht in der Suche mit umgehen

Das aktuelle Land zu identifizieren ist ein mehrstufiger Prozess um wen irgendwie möglich
zu vermeiden das Grenzpolygon zu laden (Test gegen das Polygon ist dann wieder rasend schnell).

Bestrebungen gibt es da keine aber momentan zum wiederholten Male eine Diskussion auf der talk-de -Liste
dass Leute die 3 Stadt-Grenzen, die jetzt noch durch das place-Polygon gegeben sind in 3 verschiedene aufrennen wollen.

  • polygon der Adressen welche potalisch zum Ort gehören
  • Verwaltungsgrenze
  • Grenze der “geschlossenen Ortschaft” nach StVO

Marcus

AFAIK wird das Place-Polygon für den Bereich verwendet, der durch die Ortseingangsschilder begrenzt wird.

Die Adresszugehörigkeit müsste über die Verwaltungsgrenze (boundary) ermittelt werden.

Adresszugehörigkeit und Verwaltungsgrenze zu trennen würde meiner Meinung nach keinen Sinn ergeben. Immerhin gibt die Adresse an, in welchem Verwaltungsbezirk sich etwas gefindet.

Das kann sich bei Eingemeindungen durchaus unterscheiden.

Ausserdem GIBT es typischerweise kein boundary für die Ortschaft. Ein place=city/village/… Polygon ist das
einzige was überhaupt oft genug existiert um den Aufwand zu rechtfertigen das zu programmieren.

Marcus

Also ich sehe place-polygone nur sehr sehr selten, und dafür viele boundarys.
Was ich aber eigentlich damit sagen wollte ist, dass es auch außerhalb des place-polygons entsprechende Adressen gibt, und dass das Place-Polygon sich hervorragend eignet, um innerörtliche Straßen zu ermitteln.

Gib doch mal einen Link auf deine Gegend.
Welches admin_level haben deine Boundaries und tragen sie auch name-Tags?

Marcus

Ich wohne in Berlin, da ist die Boundary-Struktur sehr kompliziert.

Aber als Beispiel meinen Heimatort Langenhagen: http://www.openstreetmap.org/?lat=52.4601&lon=9.7198&zoom=13&layers=0B00FTF

Hat kein place-polygon, aber eine relativ genaue boundary-relation. Getaggt mit type=boundary, boundary=administrative, admin_level=7, name=Langenhagen (das selbe überigens auch bei der Nachbarstadt Hannover)

Zu Langenhagen gehören viele Dörfer, die alle “Langenhagen” als Adresse haben, zum Teil aber weit vom Place-Node entfernt sind.

Hier kannst du die Boundary-Relation gut sehen: http://www.openstreetbrowser.org/#rel_59415

Das war ja aus meiner Sicht sehr ertragreich, vielen Dank! :slight_smile:

http://travelingsales.sourceforge.net/bugs/view.php?id=117

Ok, ich hab den CitiesIndex angepasst, dass er nicht nur polygone mit place=city/town/village" bzw place=suburb nutzt sondern auch boundary=administrative mit admin_level=7 bzw. 8.

Viel spannender ist überigens noch die Nachbargemeinde Wedemark. Dort gibt es garkein Dorf oder eine Stadt, die Wedemark heißt. Trotzdem haben alle Dörfer “Wedemark” als Adresse. Leider gibt es dort noch keine Boundary-Relation.

Hier mal eine Karte davon: http://www.wedemark.de/inhalt/showfoto.php?hilfe=1&id=918000302&bez=%DCbersichtskarte+der+Gemeinde+Wedemark