OSM-Wiki: neue Seiten im Zusammenhang mit Projekt "namo"

Na dann auf gehts:

Schwarz ist eine normale Straßenkreuzung in OSM wie sie heute bereits existieren.
Ergänzt um Punkte an denen eine Querung der Straße möglich ist. (man läuft ja nicht diagonal über die Kreuzung)

Daraus könnt ihr über die Sidewalkeigenschaften die Kanten entlang der Straße berechnen und die Verbindungen über die Straße ergeben sich aus den Informationen an den Punkten welche auch heute schon für Zebrastreifen und Verkehrsinseln gebräuchlich sind.

Wenn ich das richtig verstanden habe, müsste man, wenn Bürgersteig und Straße in eine Relation sollen, eine gerade Straße an jeder Kreuzung zerstückeln, weil ja dann ein anderer Bürgersteig “zuständig” ist. Vermeiden lassen würde sich das nur, wenn man versucht, die Straßen immer um die Ecken gehen zu lassen. Habe ich das richtig verstanden?

So sehe ich das auch.
Die Vorgehensweise von “namo” ist halt noch viel aufwendiger: Da gehen von dieser Kreuzung acht Bürgersteige als getrennte ways ab.

Ich stelle mir die Zuständigkeit anders vor: 1 lange Straße hat N Stücke Gehweg.

Na dann musst Du eben die Gehwege an jeder Kreuzung teilen. Letztendlich hast du einen Haufen Segmente. Und woher weiss der Router nun welcher Buergersteig zu welchem Teil der Strasse gehoert?

Ja, das ist das doofe an diesem Projekt

Sie wollen den Gehweg den “Straßenname, Straßentyp, Geschwindigkeitsbegrenzungen und weitere relevante Informationen” zuordnen. Das geht auch, wenn man die räumliche Beziehung zur Straße völlig ausser acht lässt und nur eine Verknüpfung Weg zu Straße erzeugt.

So wie ich das sehe, ist das ganze Projekt sogar darauf angelegt, die räumliche Beziehung zur Straße vernachlässigen zu können: Namo will nur auf Fußwegen routen, also bauen sie sich eine Welt aus Fußwegen. Wenn man doch mal was aus dem Rest der Daten benötigt, ein Straßenname z.B. oder deren Straßentyp, muss man sich das irgendwie über eine Relation besorgen können. Der Router muss gar nichts über die Straße wissen, er kennt sie nicht mal. Bestenfalls hat er ein Stück “ungünstigen Weg” in seinem Wegenetz, was in der echten Welt ein Zebrastreifen oder eine Ampel ist.

Danke für die Erklärung. Mein Versuch, das Ganze zu verstehen, war vielleicht doch zu wenig fußgängerzentrisch. Nun leuchtet es ein.

Nein. Eine Straße muss nur geteilt werden, wenn sich die Attributeigenschaften nach der Kreuzung ändern. Dies wird allerdings von der Community bereits heute schon so gehandhabt. Nehmen wir z.B. an, dass eine Straße über die gesamte Länge dieselben Attribute verfügt (z.B. Tempolimit 30), so ist ein Aufsplitten nicht notwendig. Ändert sich hingegen das Geschwindigkeitslimit nach einer Kreuzung, dann wäre diese Straße sowieso bereits in zwei Kanten aufgeteilt.

Wenn wir die Daten, die wir erhoben haben, den bereits bestehenden Kanten hinzufügen, dann müssten wir diese Kanten bei jeder Änderung (z.B. Oberflächenstruktur oder Neigung/ Steigung) teilen. Erschwerend kommt noch hinzu, dass die Gegebenheiten des linken und rechten Bürgersteigs unterschiedlich sein können.

Das ist richtig. Vielen Dank für diesen Hinweis. Da müssen wir noch Querungen einarbeiten.

Bezüglich der Straßenquerungsmöglichkeiten werden wir unsere Untersuchungsgebiete nochmals überarbeiten.

Richtig. Mit Hilfe der Relationsbildung vermeiden wir u.a. auch eine „unschöne“ Darstellung in gerenderten Karten. So würden z.B. die Straßennamen dargestellt, wenn wir diese an die Gehwegkante anfügen. In diesem Fall käme es zu einer Doppelung, da Straßennamen bereits über gerenderte Straßen abgebildet werden.
Ein weiterer Vorteil der Relationsbildung ist die Datenpflege. Ändern sich Attribute an der Straße, dann müssen diese für die Gehwege nicht gesondert nachgezogen werden.

Sollte es zu einer Teilung einer Straße kommen, dann betrifft dies keine bestehende Relationen, da diese dadurch nicht „zerstört“ werden.

Mit freundlichen Grüßen,
namo1

Wir testen unser Untersuchungsgebiet Bornheim in Frankfurt am Main mit mapquest (http://open.mapquest.co.uk/).

Beste Grüße,
namo1

Hallo,

Wenn man eine Travelling Salesman-Aufgabe für Fußgänger hat, dann lässt man sich von Haus zu Haus routen. Dann kann es das Ergebnis erheblich beeinflussen.

Da haben sich die anderen Forumsmitglieder vielleicht nicht gut genug ausgedrückt. Aber man kann den Node auf der Straße, der Informationen zur Bordsteinhöhe, Existenz eines Zebrastreifens usw. enthält nicht nur auf die Straßenkreuzung setzen, sondern auch fünf bis zehn Meter zurückgesetzt in die Zubringerstraßen (dort wo vielleicht eine Vekehrsinsel stehen könnte).

Dafür gibt es dann surface:sidwalk:right=paving_stones und surface:sidewalk:left=asphalt, genauso mit allen anderen Straßeneigenschaftstags (lit:sidewalk:right=yes, lit:sidewalk:left=no usw.). Left und right beziehen sich auf die Richtung des OSM-Ways.

Viele Grüße

Michael

Richtig. Allerdings wollte ich damit nur zum Ausdruck bringen, dass wir mit dieser Methode jede Menge Segmente erzeugen würden. Dies würde noch häufiger vorkommen, wenn auf den gegenüberliegenden Gehwegseiten unterschiedliche Gegebenheiten vorliegen. Mal abgesehen davon, ist das Problem mit der automatischen Kantenerzeugung noch nicht gelöst.

Ein weiteres Problem welches wir bei der Verwendung von left/right bedacht haben ist folgendes. Ändert ein Nutzer die Richtung der Kante und pflegt die left/right-Beziehung nicht nach, obwohl bei JOSM eine Warnmeldung erscheint, ist die ausgegebene Information falsch.

Viele Grüße,
namo1

+1
Das ist auch das hauptproblem früherer Wheelchairroutingansätze gewesen. Hier sollten sogar noch die ansteigende und abfallende Bordsteinkannte erfasst werden, was für eine einfach Auffahrt 3 Segmente bedeutet hätte.

Ich hatte an anderer Stelle einmal vorgeschlagen Eigenschaften nicht an Wegen sondern an Relationen aus Nodes zu erfassen. Denn etwas anderes sind Wege auch nicht. Und dann ist es nur eine Frage dessen was der Editor abbilden will.

Wie bereits im Post #78 angekündigt haben wir unsere Straßenquerungsmöglichkeiten im Untersuchungsgebiet Bornheim in Frankfurt am Main überarbeitet.

Es sind jetzt an fast jeder Kreuzung Querungsmöglichkeiten vorhanden, sodass bessere Routingergebnisse für nicht mobilitätseingeschränkte Personen ausgegeben werden können, um dadurch für diese vermeidbare Umwege zu verhindern.

Wir werden diesen Datensatz im Laufe des Tages hochladen.

Mit freundlichen Grüßen,
namo1

UPDATE: Der aktuelle Datensatz ist nun hochgeladen.

http://alba-publikation.de/alba/nahverkehr/nvtoc1.php?bestnr=nv201405

Nadine George, M. A. / Dipl.-Geogr. Michael Neuhauser / Dipl.-Geogr. Marco Gennaro / Dipl.-Inform. Joachim Kast

Open Street Map für Auskunftssysteme im ÖPNV ►

Erfahrungen mit Technik und Community aus dem FuE-Projekt namo

Zusammenfassung

Unter Federführung der Rhein-Main-Verkehrsverbund Servicegesellschaft (rms) wird im Forschungsprojekt namo basierend auf Open Street Map (OSM) ein personalisiertes Fußwegerouting entwickelt. Der Einsatz von OSM bietet Chancen, wie die hohe Genauigkeit und Aktualität der Daten, birgt aber auch Risiken, wie beispielsweise die sich ständig verändernde Datenstruktur. Im Beitrag werden erste Erfahrungen im Umgang mit der OSM-Technik und der OSM-Community beschrieben.

Wir haben nun das Relationsschema “street” angewendet, um die Gehwege mit den Straßen zu verknüpfen und hochgeladen.

Viele Grüße,
namo1

Die Erhebung unseres zweiten Untersuchungsgebietes Bad Nauheim ist abgeschlossen. Dabei haben wir unsere Erfahrungen aus dem ersten Untersuchungsgebiet Bornheim in Frankfurt am Main einfließen lassen. Diesen Datensatz werden wir im Lauf dieser Woche hochladen.

Bei Rückfragen stehen wir zur Verfügung.

Mit freundlichen Grüßen,
namo1

UPDATE: Der Datensatz für Bad Nauheim ist nun hochgeladen.

Nur mal so fürs Protokoll: Es gab Einwände.

Bezüglich der Verwendung des Relationsschemas “street” wurden hier keine Einwände verfasst. Kannst Du diese bitte zitieren, damit wir diese prüfen können. Besten Dank im Voraus.

Da habe ich mich wohl ungenau ausgedrückt: Nicht gegen “street” als type-Wert der Relation, sondern über die Modellierung mit Relationen und separaten Ways generell, was natürlich street-Relationen einschließt.

Ich verstehe schon, dass es für euch nicht einfach ist, wenn alle Forenteilnehmer widersprüchliche Aussagen durcheinander rufen und es keine eindeutig akzeptierten Standards gibt. Aber ich finde es als Befürworter von sidewalk-Tags an Straßen frustrierend, dass ihr anscheinend nicht bereit seid, euch in dieser Frage zu bewegen – auch, nachdem die zentralen Argumente für euer Modell entkräftet wurden, und auch angesichts der gewichtigen Gegenargumente.

Ich würde mir zumindest wünschen, dass ihr anerkennt, dass euer Projekt mit tag-basierten Gehwegen und Überwegen genauso gut möglich gewesen wäre, und dass ihr die Vorteile der Vermeidung separater Ways (z.B. fürs 2D- und 3D-Rendering und die Möglichkeit der Straßenquerung an beliebigen Punkten) durchdenkt und versteht.

In Beitrag Nummer 7 wurde darum gebeten, das Projekt offline durchzuführen, da nicht zu erwarten ist, dass dieses Schema sich durchsetzen wird und es wenig sinnvoll ist, veraltete Daten zu haben. Könnte namo1 mal darauf eingehen, warum dies nicht offline durchgeführt wird und wir mit diesem sehr komplizierten System belastet werden, welches nachher keiner pflegen wird?