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

Ich halte das Erfassen von getrennten Gehwegen sogar als Bruch der bisher geübten Konvention, Wege (Linienzüge) nur dann getrennt zu erfassen, wenn sie baulich getrennt sind, ein Wechsel also nicht möglich ist.
Ein Beispiel dafür ist das Mappen von Fahrspuren. Da werden diese solange als Attribut einer einzigen Linie eingetragen, solange sie nicht baulich getrennt sind. Erst wenn z.B. die Autobahnausfahrt abbiegt, wird sie als getrennte Linie erfasst.

Mir fällt im Moment nichts ein, was dagegen sprechen würde, nicht getrennt verlaufende Gehwege mit allen Attributen (abgesenkt, rechts, links etc.) als Eigenschaft der Straße zu erfassen, so wie man es auch bei den Fahrspuren macht (machen sollte).
Der einzige Nachteil, den man sich dadurch einhandelt, ist, dass die Straßen dann häufiger aufgesplittet werden müssen, wenn sich die Eigenschaft des Gehwegs ändert. Damit hat man sich beim Spurtagging aber auch arrangiert.

Das sehe ich genauso, das Spurtagging ist ein gutes Vorbild. Und im Vergleich zu der Vorstellung, bei allen Straßen mit Gehwegen (also bei vollständiger Erfassung fast jeder Straße) mit Relationen arbeiten zu müssen, sind die häufigeren Wegteilungen ein eher kleines Ärgernis.

Naja, aus Sicht eines Autos besteht ja auch eine bauliche Trennung wenn der Bürgersteig nicht abgesenkt ist.
Aus meiner Sicht spricht einiges für, aber auch einiges gegen das getrennte Erfassen von straßenbegleitenden Wegen. Und mit der Tatsache, dass es sowieso praktiziert wird, muss sich dann sowieso jeder Router rumschlagen. Das kommt nunmal davon, dass wir in OSM so tolerant sind, für jedes Problem 10 Lösungen als akzeptabel anzusehen :-\

Ich finde, wer so etwas grossflächig einführen will, sollte einen Vorschlag machen, wie sich ein Router für nicht-Rollatornutzer damit rumschlagen sollte. Leider hat Namo nicht auf die Beiträge #35 bis #53 reagiert, sondern lediglich um weiteres Feedback zu einem anderen Thema gebeten.

Für den eigenen Router hat Namo ja eine Lösung: Sie modellieren die Daten so dass es für sie passt, weil sie sich mit Routingproblemen bei Bürgersteigen nicht rumschlagen wollen, trotz sicher vorhandener Kompetenz, wenn ich mir die Beteiligten und das Budget so ansehe.

Auf die Gefahr hin, dass wir aneinander vorbei reden: das separate Mapping von Fuß- und Radwegen ist schon länger standardisiert. Die vorgeschlagenen Erweiterungen von Namo zu den Relationen haben ja nichts damit zu tun, dass bereits heute schon Bürgersteige separat gemapped werden und sich Router damit arrangieren müssen. Ob das wirklich nötig ist, bezweifle ich, aber ich habe auch bisher keinen Router für OSM programmiert. Ich halte es allerdings für falsch sich das Programmieren eines Routers durch Einführen von Relationen zu erleichtern.

Besten Dank für die Anregungen und Hinweise. Nachdem wir uns mit unseren Projektpartnern abgestimmt haben (das dauert natürlich immer ein paar Tage … deshalb sind wir leider etwas langsam für das Forum), möchten wir gerne auf einige Punkte antworten.

Es gibt unseres Wissens nach keine richtigen „Fußgänger-Router“ basierend auf OSM, welche nur Fußwege verwenden. Grundsätzlich werden Fußgänger über Straßen ohne jegliche Restriktion (bis auf Autobahn) geroutet, ohne zu wissen, ob es einen Fußweg gibt.

Informationen an Punkten sind schlecht nutzbar, da Informationen in der Datenaufbereitung an die Kante müssen. Allerdings ist dann unklar, welche Kante die Eigenschaft bekommen soll. Es können auch virtuelle Kanten mit der Länge 0m hinzugefügt werden. Dann kann man aber keinen Faktor mehr drauf rechnen, wenn die Kreuzung laut Anforderung des Nutzers möglichst vermieden werden soll.

Nein, kann unser “Fußgängerrouter” leider nicht.

Aber grundsätzlich ist in solchen Situationen immer eine Art Überquerung durch das Straßenbauamt vorgesehen. Daher können dann auch Überquerungen in den Daten modelliert werden. Das einzige Problem ist wirklich nur, wenn man auf einer Seite der Straße startet (egal ob von einer Haustür oder einer Haltestelle) und einfach nur auf die andere Seite muss.

Wir haben diese Variante geprüft und uns dagegen entschieden, da wir dabei keine Straßenquerungen modellieren können.

Die Lösung, Fußwege so zu modellieren wie wir, ist generisch und kann von jedem Router (bei entsprechender Datenaufbereitung) interpretiert werden. Derzeit bestehende Router arbeiten auf Straßen und sind somit nicht betroffen. Fußwege gibt es in OSM bisher kaum, daher ist dieses Routing-Problem zurzeit nicht lösbar. Allerdings wäre es aus unserer Sicht doch wirklich hilfreich eine Beschreibung zu erstellen, wie auf diesen Daten gut geroutet werden kann. Das kann man am Projektende machen, wenn gezeigt wurde, dass der Prototyp auch funktioniert.

Mit freundlichen Grüßen,
namo1

Hallo,

Ich muss mich schon ein bisschen zusammenreißen, damit ich Verständnis aufbringen kann. OSM ist ein Community-Projekt, wir antworten nunmal etwas schneller …

Ja, weil Fußwege noch nicht so stark im Fokus der Mapper angekommen sind. sidewalk=* gibt es, aber momentan sind die meisten auf Adressen, POIs und Radwege fixiert. Das sidewalk-Tag hat halt noch ein Henne-Ei-Problem.

Doch, bestehende Router sind von eurem Mapping betroffen. Wenn ich von meinem Haus zum Haus meines Nachbar gegenüber route und ihr auf beiden Straßenseiten die Bürgersteige als eigene Ways eingetragen habt, dann schickt mich mein Router bis zur nächsten Kreuzung! Dabei kann ich (als nicht mobilitätseingeschränkter Fußgänger) problemlos den Bordstein überqueren. Bitte berücksichtigt, dass es auch Leute gibt, die keinen Rollator brauchen.

Euer Datenmodell ist nicht kompatibel mit dem bestehenden und den Datennutzern. Mapping-/Tagginschemata, die bestehende Konventionen über den Haufen werfen, setzen sich in der OSM-Community erfahrungsgemäß nur sehr langsam (public_transport-Schema) oder gar nicht (bread_bakery) durch.

Bitte passt euch den Gepflogenheiten in OSM an und versucht nicht, uns euer Mappingschema aufzudrücken. Wenn ihr meint, dass es besser ginge, dann geht bitte den Weg eines Proposals, diskutiert das mit der Community und stellt nicht einfach eure Schemata auf eine Wiki-Seite.

Wenn ihr euer Schema nicht ändern und auf die Community zugehen wollt, dann wäre für euch das beste, die OSM-DB auf einem privaten Server zu installieren und OSM zu forken. Die OSM-DB samt Zubehör ist freie Software. Das Projekt Moabi hat das schon gemacht und dazu auf der SotM-US einen Vortrag gehalten. In eurem Privat-OSM könnt ihr dann mappen, wie ihr wollt.

Wer sagt denn das? Die Propaganda von TomTom, die ihre teuren, aber in Deutschland nicht mehr konkurrenzfähigen Daten verkaufen will? Nennt mir mal bitte einen Anbieter, der mehr Fußwege in Deutschland hat und kein Amt ist! OSM hat in Deutschland ca. 80.000 km Fußwege.

Ich und vermutlich auch manch anderer hier haben immer noch den Eindruck, dass ihr nicht verstanden habt, wie OSM bzw. die Community funktioniert. Ihr könnt uns nicht einfach euer Mappingschema aufdrücken, welches vorschreibt, dass baulich nicht getrennte Fußwege als separate Ways gemappt werden. Bitte respektiert das. Passt eure Software daran an. Ihr müsst dann halt in der Vorverarbeitung bei jedem Straßen-Way, der ein sidewalk=yes hat, diesen um ein paar Meter zur Seite versetzen und anschließend an Kreuzungen die Ways, die “übestehen” kappen (falls ihr AutoCAD kennt, dort nennt man diese Funktion “versetzen”). Wenn ihr nicht die Kenntnisse/Fähigkeiten/Zeit habt, euch selbst OSM aufzusetzen, dann gibt es bestimmt Anbieter, die das gegen Bezahlung für euch tun.

Wisst ihr eigentlich, dass eure Aktivitäten und euer Umgang mit Community sowie das Auftreten von drei weiteren Firmen/Projekten dazu geführt hat, dass es wohl über kurz oder lang eine Organizational Mapping Policy, also ein Verhaltenskodex für weisungsgebundene und bezahlte Mapper gibt? Auf der OSMF-talk-Mailingliste wurdet ihr schon letzten Herbst erwähnt, das Thema (die Policy) wird nun auf der internationalen talk-Mailingliste diskutiert.

Viele Grüße

Michael

Hallo namo,

Ja, vermutlich routet keiner nur auf Fußwegen. Das Problem ist, dass es einige Fußgänger-Router gibt, die auf Fußwegen und Straßen routen. Was generell auch gut ist, sonst kämen meine rollatorschiebende Nachbarin und ich nicht aus unserem Haus an der gehsteiglosen Straße.
Solche Router freuen sich auch über Eure Fußwege und werden die vermutlich sogar bevorzugt zur Routen verwenden. Nur kommen die dann nicht mehr an jeder Stelle vom Fußweg runter, sondern nur an Kreuzungen oder anderen von Euch bevorzugten Punkten.

Naja, ich denke, die meisten davon kennen schon noch Abstufungen zwischen “Du darfst da nicht laufen” und “Super Weg, den nehme ich”… Sie können auch in Erfahrung bringen, ob da ein Fußweg ist, indem sie “sidewalk=*” auswerten. Ich kenne einen Router, der diese Wege bevorzugt, aber andere Leute kamen sicher auch schon auf diese nicht ganz abseitige Idee.

Was sie dann natürlich nicht können, ist die Antwort auf “Kann ich hier über die Straße” zu geben. Bei Straßen mit “sidewalk=*” ist die Antwort immer “ja” (1), bei Euch wird sie “Nein” sein.

Derzeitige Router für Fußgänger arbeiten auf Straßen und Fußwegen, sind also schon betroffen. Sie können Fußwege natürlich auch verarbeiten, nur finden sie halt nicht an jeder Stelle über die Straße, wo ihr Benutzer das könnte. Stattdessen routen sie bis zur nächsten Kreuzung, wo Fußweg und Straße verbunden sind. In manchen Fällen mag das richtig sein (in #43 ist ein Beispiel), in den meisten Fällen eben nicht. Ich glaube es nicht, aber ich würde mich freuen, wenn Ihr eine Lösung dafür findet :wink:

Grüße, Max

Edit: (1) Eigentlich müsste die Antwort bei sidewalk=left|right|both nicht immer “ja” sein. Aus dem könnte man ja ableiten, wo der Gehweg ist und dann das überqueren nur an bestimmten Punkten erlauben (Ne Idee dazu in #48). Allerdings wüsste ich keinen Router, der das auswertet. Das hielte ich für einen viel schöneren Ansatz für Eure Forschung…

Mit verlaub, aber diese Antwort ist nicht stichhaltig!
Wenn man Dinge an Kanten braucht, dann erzeugt euch doch Kanten aus highway mit sidewalk=yes die können sogar links und rechts neben der Straße liegen.
Ein vermeiden der Kreuzung geht dann nicht mit einem Faktor. Aber sehrwohl mit einem absolutwert. Nehmen wir an die Straße ist in der Regel 6m mit Parkstreifen 10m breit und schon hat man Ansätze welche Standardwerte für die Vermeidung erforderlich sind. Möchte man das genauer machen, kann man sicher auch die selten gefüllten Straßenbreiten auslesen. Zusätzlich könnte man das auch an den Crossings angeben, wenn das gebraucht wird.

Wir sind uns dieser Problematik bewusst, dass unser Router nur an vordefinierten Übergängen die Straßenseite wechseln kann. Jedoch ist das beschriebene Beispiel nicht unser wahrscheinlichster Anwendungsfall. Wer lässt sich von seinem Haus zum gegenüberliegenden Haus routen? Und falls wir dennoch von diesem Beispiel ausgehen und dann annehmen, dass diese Straße eine Hauptverkehrsstraße in einer Großstadt ist, bevorzugt sicher auch die nichtmobilitätseingeschränkte Person die Ampelquerung.

Wir möchten Querungen berücksichtigen. Auch nicht mobilitätseingeschränkte Fußgänger sollten laut StVO Ampelquerungen und Zebrastreifen verwenden, wenn diese vorhanden sind. Außerdem werden im Straßenraum dort abgesenkte Bordsteine, Ampeln und Zebrastreifen angelegt, wo eine Querung für alle sinnvoll erscheint.

Das Problem ist, dass die Erzeugung von zusätzlichen Kanten wie im Forum vorgeschlagen in der Realität Probleme birgt. Hier ist vor allem die Informationsweitergabe zu den Kreuzungen, die an den Punkten vorliegt schwierig. Außerdem hängt an diesem Punkt EINE Information. Welche der vielleicht 4 Querung einer Kreuzung dies betrifft lässt sich nicht ablesen. Richtungsangaben lassen sich auch nicht sinnvoll an den Punkt schreiben, da dies darauf ankommt von wo nach wo man laufen möchte. Außerdem lassen sich die Kreuzungen nicht in allen Fällen allein rechnerbasiert erzeugen. Und wir können nicht wirklich bei jedem Datenimport aus OSM jede Kreuzung in Deutschland in einem Zeichenprogramm nachziehen. Wir freuen uns über Lösungsansätze und prüfen jene auch.

Mit freundlichen Grüßen,
namo1

Die Relationen sind keine Pflicht, aber für den Prototyp wichtig. Wenn es diese Relation nicht gibt, gibt es keine Informationen über die angrenzende Straße.

Relationen stören keine bestehenden Systeme, solange sie korrekt verwendet werden.

Besten Dank für den Hinweis! Diese Möglichkeit der Relationsbildung (http://wiki.openstreetmap.org/wiki/Relation:street) haben wir intern geprüft und sind zu der Entscheidung gekommen, dass wir dieses Relationsschema nun anwenden werden, wenn es hierzu keine Einwände gibt. Anbei ein Bild zur Verdeutlichung.

Als Rolle werden wir weiterhin sidewalk für die Gehwege verwenden, da dies auch bereits auf folgender OSM-Wiki Seite vorgeschlagen wurde (http://wiki.openstreetmap.org/wiki/Proposed_features/Sidewalk_as_separate_way).

Zitat daraus unter Relation : “There are proposals suitable for linking the sidewalks and the main road with a relation. associatedStreet, or the proposed street relations are possible candidates. The sidewalks could be added with role sidewalk.”

Bei Fragen stehen wir zur Verfügung.

Mit freundlichen Grüßen,
namo1

Hi namo,

Ihr habt im Sommer euren mehrmonatigen Feldtest. Könnt Ihr, wenn ihr so weit seid, mal eine Gegend nennen, wo ihr glaubt, das Mapping sei halbwegs perfekt für eure Bedürfnisse?

Ich fürchte, das Problem beschränkt sich nicht auf Nakaners Besuch bei seinem Nachbar gegenüber. Er könnte z.B. auch nur schwer die Kirche besuchen. Das könnten natürlich alles noch Dinge auf Eurer todo-Liste für den Sommer sein, deshlb wäre es gut, wenn man ein Demo-Gebiet hätte, um einen anderen Router mal drauf los zu lassen…

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