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

Schon klar. Das oben gemalte unglückliche Fussgängerrouting passiert auch ständig mit unseren jetzigen Daten (Beispiel, die Rümannstr ist überall ziemlich gefahrlos zu überqueren trotz der eingezeichneten Parkflächen), einfach weil man vergisst, die gegenüberliegenden Wege anzuschliessen. Nur war das eben bisher eine bedauerliche Fehlfunktion.

Ich meinte nicht unbedingt das man vergaß die Straße anzuschließen. Sondern ich meinte das Geländer welches das Überqueren der Straße verhindert.
Dort ist nämlich genau das vorgesehen was du vermeiden möchtest. Ohne getrennte Wege wäre das aber nicht abbildbar.

Ich wollte eher mein eigenes Argument abschwächen :wink: Das Problem ist, dass namo jetzt überall virtuelle Geländer aufstellen will, indem sie überall getrennte Wege eintragen. Das zwingt jeden Fussgängerrouter dazu, entweder “namo-Wege” zu erkennen und zu vermeiden, oder zu routen als hätte er einen Rollator.

Grüße, Max

Was mir schon beim ersten Versuch des Projekts nicht gefallen hat:
Durch die getrennten Gehwege aka “virtuelles Geländer” wird der Linienwirrwarr in den Innenstädten entlang Straßen verdreifacht.

Ein besserer Ansatz wäre mE ein geeignetes (von mir aus auch neues) Tag an der Straße (highway=) zusätzlich zu sidewalk, also etwas wie
sidewalk:right:sloped_curb=

Siehe auch http://wiki.openstreetmap.org/wiki/DE:Wheelchair_routing

Das hat zur Folge, dass Strassen häufiger abgeteilt werden müssen (an jeder Rollstuhlüberquerung), aber das scheint mir das bei weitem kleinere Übel.

Zur Vermeidung des Splittens von ways und des Einzeichnens separater Bürgersteige hätte ich folgende Idee:
An die Stelle der abgesenkten Bordsteinkante setzt man ein node mit
sidewalk=drop_kerb (beidseitige Absenkung)
Einseitige bekämen sidewalk:right=* bzw. :left=
Bei Fahrradwegen könnte man analog vorgehen.

Das scheint dir das kleinere Übel? Also mir scheint das eher ein sehr viel größeres Übel zu sein! Das Problem sind wahrscheinlich auch nicht die Wege zwischen zwei Kreuzungen. Hier könnte man das Queren ja mittels highway=crossing an einem Punkt jederzeit zulassen.
An einer Kreuzung kann ich aber mit der Punktmethode am Schnittpunkt nicht mehr eindeutig anzeigen über welche Straße man gegebenfalls kommen kann und über welche nicht.
Die Lösung dafür wäre vielleicht vier Punkte an den jeweiligen Schenkeln zu setzen. Was denkt ihr darüber?

So habe ich mir das unter #48 vorgestellt.
sidewalk=drop_kerb an highway=crossing wäre dort auch eine hilfreiche Zusatzinfo.

Das (#48-50) erscheint mir besser als die Eigenschaft an ways (aus http://wiki.openstreetmap.org/wiki/DE:Wheelchair_routing).
Entspräche ja auch dem bisherigen Vorgehen bei normalen Fußgängerüberwegen.

Ich füge dein Bild noch einmal ein:

Kann nicht auch der "Fussgängerrouter " so eingestellt werden, dass er auch über den highway=Straße auf den folgenden Punkt wechselt? (Entsprechend deinem Bild “Routing” ohne Fußwege). Und wenn der Router den anderen (längeren Weg) vorschlägt, kann der “Fußgänger” ja immer noch entscheiden “über die Straße” zu gehen.

Für Routing mit Rollator oder Schulwege (Seniorenwege) ist ein entsprechendes Routing sicherer.

Schwer zu machen… Man könnte natürlich bei den Routern irgendwas in der Art “Du darfst auch mal 2m von Weg zu Weg springen” einführen. Allerdings geben unsere Daten wenig her, was die weissen Flecken zwischen den Wegen betrifft. Da kann alles mögliche liegen: Graben, Begrünung, ein noch nicht gemappter Zaun, ein Randstein…

Das einzuführen und zu taggen dürfte mühsamer sein als alle Vorschläge in diesem Faden. Möglich wäre das mit kleinen schmale Flächen mit passenden (access/smothness/highway/kerb/…) zwischen allen Wegen, oder Relationen zwischen Straßen und ihren Gehweg, die die Überquerbarkeit des Zwischenraumes beschreibt…

Das kann man sicher besser durch ein Tag an der Straße oder grosszügig gemalte Querverbindungen hinkriegen. Wobei letztere den Nachteil haben, dass der Mapper schon wissen müsste, wo der Benutzer des Routers über die Straße will. An Kreuzungen und Einmündungen will er sicher, zwischen den Kreuzungen aber sicher auch manchmal.

Der Router wird den Fußgänger vielleicht an diese Stelle gar nicht führen, weil er auf 5km Strecke 30 solcher Situationen hat, wo er die Strecke um 50 Meter falsch einschätzt und er sich deshalb für eine ganz andere Route entscheidet.

Jo. wir brauchen eine Möglichkeit, auszuwählen, ob wir nur an besonderen Stellen oder überall über die Straße laufen wollen. Bei getrennt gemappten Wegen, die nur bei Bordsteinabsenkungen verbunden sind, haben wir die Auswahl nicht.

Nachtrag: Damit das ganze nicht so theoretisch klingt, noch ein Bildchen. Situation wie oben, eine Einmündung und gegenüber der Weg ohne Verbindung zur Straße. Der Router wird den für ihn kürzesten Weg (links) anbieten, weil ihm der Seniorenweg (mitte) länger vorkommt. Dass man auch einfach abkürzen kann (rechts), weiss der Router nicht und der Fußgänger wird es nie erfahren, weil er seinem Router folgt.


(Bitte nicht nachmessen, die Zahlen sollten stimmen, die Pixel nur so ungefähr)

Auf unserer wiki.osm-Seite http://wiki.openstreetmap.org/wiki/Namo haben wir unter Kapitel 3.3 Vorgefertigte Eingabemasken für JOSM unsere Eingabemasken veröffentlicht, die wir für die Einarbeitung der erhobenen Daten verwenden. Über ein Feedback würden wir uns freuen.

Viele Grüße,
namo1

Relation von Gehweg bzw. Straßenquerung zur Straße erzeugen

Für ein aussagekräftiges Fußwegerouting werden Informationen, die sich an den Straßen-Kanten (wie z.B. Straßenname, Straßentyp, Geschwindigkeitsbegrenzungen und weitere relevante Informationen) befinden, ebenfalls an den zugehörigen Gehweg-Kanten benötigt. Diese Verknüpfung von Straße mit Gehweg bzw. Straßenquerungen wollen wir über Relationen realisieren. Dabei orientieren wir uns an das Relationsschema associatedStreet (http://wiki.openstreetmap.org/wiki/Relation:associatedStreet) und verwenden für die Umsetzung das Programm JOSM. Dementsprechend sieht unser tagging aus.

Folgende Rollen wollen wir verwenden:

„street“ – für Straße
„sidewalk“ – für Gehweg
„crossing“ – für Straßenquerungen

Die angefügten Bilder sollen dies exemplarisch verdeutlichen.

Wir wollen Euch um ein Feedback bezüglich der Vorgehensweise bitten. Besten Dank im Voraus.

Mit freundlichen Grüßen,
namo1

Etwas allgemeiner betrachtet geht es hier wohl um die Erfassung von “komplexen Straßen” und “komplexen Kreuzungen”. Da gab es ja schon mal Anläufe, s. http://wiki.openstreetmap.org/wiki/Proposed_features/Junction und http://wiki.openstreetmap.org/wiki/Relations/Proposed/Dual_carriageways .

MMn sollte man es gleich allgemeiner angehen.

Würden das die bisherigen Auswerter von associatedStreet-Relationen verstehen?

Bisher war associatedStreet ausschliesslich dafür da, Hausnummern an Straßen zu binden. Falls ich den Quellcode von Nominatim richtig verstehe (in functions.sql einfach nach associated suchen) , wertet das z.B. auch nur die Rollen “street” und “alles andere” aus. Nach wiki gibt es auch nur zwei mögliche Rollen.

Vielleicht wäre da ein anderer Relationentyp besser, der noch nicht völlig anders definierte wurde…

Grüße, Max

Es gibt noch die street-Relation, welche auch andere Werte zulässt und demnach m.M.n der richtige
Relationstyp für den Zweck ist.

http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street

Ansonsten der Hinweis, dass diese Klimmzüge nicht notwendig wären, wenn man Bürgersteige nicht separat, sondern
als Attribut der Straße mappt.

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.