Routing / Spurmapping

hurdygurdyman · 2012-02-08T10:18:42.000Z

de_muur:

Sicher, dass dadurch die Werte richtungsinvariant werden? Eigentlich haengt die Abfolge der Lane-Erfassung immer von der Richtung des Weges ab. (Hast du noch mal einen Link zu benshus Vorschlag?)

Das Plugin legt Relationen genau wie bei restrictions als from-via-to an. Hier der link zum proposal:
http://wiki.openstreetmap.org/wiki/Relations/Proposed/turn_lanes

… Aber nur, weil es fuer einen Vorschlag schon mal ein JOSM-Plugin gibt, ist der Vorschlag damit bestimmt nicht automatisch anwenderfreundlicher als andere. Oder soll das hier mal wieder das JOSM-Diktat fuer eine suboptimale Entscheidung sorgen?

Sicher nicht. Weiter oben habe ich gesagt:
Mein Fazit:
Ein tolles Plugin und eine gute Möglichkeit, Abbiegespuren zu erfassen, die man weiter verfolgen sollte. Danke benshu. Ob Auswertungen damit umgehen können, muss aber noch getestet werden. Für weitere Überlegungen in diese Richtung ist es nun erforderlich, dass die Auswertungsfraktion beteiligt wird und deren Bedürfnisse einfließen.

Sprach der Mensch, der nicht mal ohne spezielles Eingabe-Tool ueber die Moeglichkeiten der Datenerfassung werten kann

Mir gefällt die für diesen Fall bewusst gewählte Rolle als DAU. http://de.wiktionary.org/wiki/DAU
http://www.sprueche-ueber-sprueche.de/index.php?page=indianersprueche&sprueche-id=1 (die ersten drei )

Scherz beiseite: Niemand wird fuer die verschiedenen Vorschlaege mal eben so einen Beispielrouter mit Spurrouting zaubern. Das gibt es zur Zeit nicht fertig und das wird auch erst irgendwann in der Zukunft entstehen, wenn dafuer geeignete Daten als Grundlage existieren.

An der Grundlage arbeiten wir.

Fuer die automatische Auswertung waere es sicherlich einfacher, wenn die Verbindungen der Spuren zu den anderen Wegen ueber Relationen erfasst wuerden, als ueber Tags wie left, right oder so. Letztendlich muss sich die Auswertung daraus naemlich die Relation selber zusammen basteln, indem sie sucht, welche Weg jeweils gemeint ist. Das ist nicht unmoeglich, erhoeht aber den Aufwand fuer die Auswertung. Auf der anderen Seite erleichtert das aber die Erfassung, verlagert die Arbeit also vom Mapper zur Auswertung.

Das Thema ist nicht trivial zu lösen. Die Frage für mich ist generell, wie wir - trotz und entgegen dem Mantra - den Spagat zwischen anwenderfreundlicher Erfassung und einem auswertungsfreundlichem Datenschema schaffen.

Eigentlich denke ich nicht, dass das ein geschickter Ansatz ist. Auf der anderen Seite halte ich den massiven Einsatz von Relationen auch fuer suboptimal. Und ich denke auch nicht, dass ein auf Relationen basierender Vorschlag mehrheitsfaehig ist. Denn aufgrund der Anzahl wird OSM doch von den Mappern getrieben.

http://www.sprueche-ueber-sprueche.de/index.php?page=indianersprueche&sprueche-id=1 (zweiter Spruch)
Wir haben soviel subopimales in OSM, über das wir hier wiederholt ergebnislos raufen. Ich bin offen für jede überzeugende Alternative.

Fabi2 · 2012-02-08T21:39:34.000Z

fkv:

Grundsätzlich zu Plugins: Ich finde es gefährlich, dass hier schon Implementierungen entwickelt werden, obwohl das Taggingschema noch gar nicht ausgereift ist. Sobald es ein Plugin gibt, finden sich Leute, die es benutzen, und dann kommt gerade beim Spurtagging ein Wildwuchs im Datenbestand heraus.

Das sehe ich auch so, die Leute hier, die meinen Spurrouting zu brauchen sollen erst einmal ein vom Menschen benutzbares Taggingschema entwickeln und es eine Weile testen, bevor man über Tools oder Plugins nachdenkt. Man darf nämlich nicht vergessen, das die Daten letztendlich vom Menschen verwaltet werden müssen!

Ich frage mich eh, was der wirkliche Nutzen des Spurroutings sein soll, bis darauf, das das Rendering noch realitätsnäher ist? Es ist ja nicht so, das die Naviansage im Moment wie folgt ist:
“Wenn sie jetzt beim Autofahren aufmerksam aus dem Fenster sehen und auf den Verkehr achten sollten, werden sie erkennen, das da vorne im 200 m eine Ampelkreuung ist. Da sie sich auf einer mehrspurigen Straße befinden, sollten sie, wenn sie links abbiegen wollen, davon ausgehen, das sie sich evtl. in die Linksabbiegespur einordnen müssen.”

Ach ja, und dann sind da ja auch noch die Mapper, die meinen, der highway=footway + footway=sidewalk wäre kein getrenntes Objekt, was man neben der Straße zusätzlich mappen sollte. Weil schließlich ist die GPS-Genauigkeit ja viel zu schlecht… …ja, aber bei Abbiegespuren, wo im Unterschied zum footway/cycleway, nicht einmal eine Abgrenzung über die gewählte Verhersmittelart möglich ist, soll das dann gehen?

de_muur · 2012-02-09T06:42:44.000Z

Fabi2:

Ich frage mich eh, was der wirkliche Nutzen des Spurroutings sein soll, bis darauf, das das Rendering noch realitätsnäher ist?
…

Ach ja, und dann sind da ja auch noch die Mapper, die meinen, der highway=footway + footway=sidewalk wäre kein getrenntes Objekt, was man neben der Straße zusätzlich mappen sollte. Weil schließlich ist die GPS-Genauigkeit ja viel zu schlecht… …ja, aber bei Abbiegespuren, wo im Unterschied zum footway/cycleway, nicht einmal eine Abgrenzung über die gewählte Verhersmittelart möglich ist, soll das dann gehen?

Ich weiss nicht, ob ich dich jetzt missverstehe. Denn die Vorschlaege fuers Spur-Mapping hier zielen ja gerade darauf ab, dass man NICHT eigenstaendige Wege fuer die einzelnen Spuren eintraegt, weil genau das auch das Routing mit den bereits existierenden Navis verschlechtert/unbrauchbar macht.

Man kann die Flaechen bei OSM so detailliert erfassen, wie man lustig ist. Aber beim Routinggraphen ist es nun mal so, dass uebertriebene Details echt schaedlich sind. In meinen Augen geht es bei dieser Diskussion also darum, wie man den Mappern eine Loesung fuer die Detailerfassung bieten kann, die A) fuer eine automatische Auswertung (Spurrouting) in Zukunft vorbereitet und B) die bestehenden Navigationsloesungen nicht behindert sondern so gut wie moeglich unterstuetzt.

hurdygurdyman:

Das Plugin legt Relationen genau wie bei restrictions als from-via-to an. Hier der link zum proposal:
http://wiki.openstreetmap.org/wiki/Rela … turn_lanes

Wie ich es schon vermutet hatte: Die Reihenfolge bei der Spurnummerierung haengt natuerlich von den Richtung des Weges ab, also kann man auch hier nicht beliebig die Wegrichtung aendern.

Ob man die Verbindungen der Spuren von einem Weg zum naechsten besser per Tags oder besser per Relation erfasst, bin ich mir nicht sicher. Aber der Vorschlag von benschu, die Laengen der Spuren in eine Relation zu packen, ist echt ganz schoen daneben.

Aber noch mal die Frage: Wie kommen wir bei den verschiedenen Vorschlaegen jetzt weiter voran, am besten zu einer gemeinsamen Loesung?

Gruss
Torsten

hurdygurdyman · 2012-02-09T08:07:35.000Z

Fabi2:

…die Leute hier, die meinen Spurrouting zu brauchen sollen erst einmal ein vom Menschen benutzbares Taggingschema entwickeln und es eine Weile testen, bevor man über Tools oder Plugins nachdenkt. Man darf nämlich nicht vergessen, das die Daten letztendlich vom Menschen verwaltet werden müssen!

Neben dem turnlane-plugin gibt es noch zwei weitere, die in den Weiten der Wiki schlummern:
http://wiki.openstreetmap.org/wiki/User:%C3%96mmes/Wayparts
zeigt einen Ansatz am Beispiel einer kreuzungsfreien Autobahn-Auf-/Abfahrt.
http://wiki.openstreetmap.org/wiki/Proposed_features/lane_and_lane_group
ist ein Versuch, Straßenspuren mit Rad- und Fußwegen unter einen Hut zu bringen.

Auch sie entstanden aus der Erkenntnis, dass mapping von Spuren für den normalen OSM-Mapper nicht ohne Eingabehilfe attraktiv wird bzw. überhaupt umsetzbar ist. Ich habe beide noch nicht getestet und kann sie deshalb auch nicht beurteilen. Aber deshalb muss man die Plugins ja nicht gleich verurteilen. Schließlich haben da Menschen Hirnschmalz und Zeit investiert um OSM voran zu bringen.
Eine Vision wäre, die Vorteile der verschiedenen Erfassungshilfen zu kombinieren, um dann ein anwenderfreundliches Tool für die Erfassung von Spuren bzw. Linienbündeln zu haben, welches die Daten robust und auswertungsfähig speichert.
Hier noch einige weitere links zum Thema:
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Lane
http://wiki.openstreetmap.org/wiki/Proposed_features/Lanes_as_Relations
http://wiki.openstreetmap.org/wiki/Users:cmuelle8/multiple_way_tagging_on_single_geometry
http://wiki.openstreetmap.org/wiki/Vorschlag_Mittelstreifen_und_Seitenbereiche
http://wiki.openstreetmap.org/wiki/DE:Lane_Assist
Vielleicht bieten die auch noch ein paar gute Ideen

Fabi2:

Ich frage mich eh, was der wirkliche Nutzen des Spurroutings sein soll, bis darauf, das das Rendering noch realitätsnäher ist? Es ist ja nicht so, das die Naviansage im Moment wie folgt ist:
“Wenn sie jetzt beim Autofahren aufmerksam aus dem Fenster sehen und auf den Verkehr achten sollten, werden sie erkennen, das da vorne im 200 m eine Ampelkreuung ist. Da sie sich auf einer mehrspurigen Straße befinden, sollten sie, wenn sie links abbiegen wollen, davon ausgehen, das sie sich evtl. in die Linksabbiegespur einordnen müssen.”

Aber es wäre doch z.B. hier
http://maps.google.de/maps?saddr=St%C3%BClerstra%C3%9Fe&daddr=Spreeweg&hl=de&ie=UTF8&ll=52.508572,13.350325&spn=0.002563,0.004812&sll=52.508136,13.349888&sspn=0.001282,0.002406&geocode=FYE1IQMdPLHLAA%3BFSpSIQMdz7nLAA&mra=mift&mrsp=0&sz=19&t=h&z=18
hilfreich, wenn ich als Ortsfremder im tosenden Verkehr folgende Ansage bekäme:
„In hundert Metern auf die zweite Spur von links einordnen, dann nach hundert Metern links abbiegen und der zweiten Spur von links geradeaus bis zum Kreisverkehr folgen."

Fabi2:

Ach ja, und dann sind da ja auch noch die Mapper, die meinen, der highway=footway + footway=sidewalk wäre kein getrenntes Objekt, was man neben der Straße zusätzlich mappen sollte. Weil schließlich ist die GPS-Genauigkeit ja viel zu schlecht… …ja, aber bei Abbiegespuren, wo im Unterschied zum footway/cycleway, nicht einmal eine Abgrenzung über die gewählte Verhersmittelart möglich ist, soll das dann gehen?

Richtungsabhängige Fahrspuren sind genauso Realität wie footways oder Hundekottütenspender, weshalb deren exklusive Erfassung in OSM durchaus berechtigt ist. Solange Spurwechsel möglich ist, sollten sie aber nicht als eigenständiger way angelegt werden, denn sie sind dann Bestandteil des highway.
Auch dieser thread enthält einige interessante Ansätze zur Problemlösung. Lasst uns doch die „best of" bündeln und daraus etwas Vernünftiges machen.
Unser Problem entsteht auch durch Linienbündel. Da wurde schon vor vier Jahren in einem Workshop dran gearbeitet.
http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Workshops/Linienb%C3%BCndel
Die Erkenntnisse treffen heute noch zu. Leider sind wir immer noch nicht weiter. Das lanetool-plugin entstand übrigens infolge dieses Workshops.

de_muur:

Aber noch mal die Frage: Wie kommen wir bei den verschiedenen Vorschlaegen jetzt weiter voran, am besten zu einer gemeinsamen Loesung?

Genau, denn es gilt:
„Wo kämen wir hin, wenn jeder sagte, wo kämen wir hin und keiner ginge, um zu sehen, wohin wir kämen, wenn wir gingen." (Kurt Marti)

hurdygurdyman · 2012-02-09T08:41:59.000Z

de_muur:

…
Wie ich es schon vermutet hatte: Die Reihenfolge bei der Spurnummerierung haengt natuerlich von den Richtung des Weges ab, also kann man auch hier nicht beliebig die Wegrichtung aendern.

Sehe ich nicht so
Schau dir mal diese Test-Relation an: http://www.openstreetmap.org/browse/relation/2006310
Die Information zur zusätzlichen Abbiegespur nach links steckt in der Relation als “lanes:extra” und bezieht sich nur auf die Fahrt in Richtung zum Abbiegepunkt “via”. Siehe auch http://wiki.openstreetmap.org/wiki/Relations/Proposed/turn_lanes#Allowed_Turns
und im Beispiel http://wiki.openstreetmap.org/wiki/Relations/Proposed/turn_lanes#Example_2 mit einer Rechtsabbiegespur.
Das ganze ist genauso robust wie die turn-restrictions , da from-via-to die Richtung bestimmt.

de_muur:

Aber der Vorschlag von benschu, die Laengen der Spuren in eine Relation zu packen, ist echt ganz schoen daneben.

Hast du einen besseren? Diese Ansatz hat den “Vorteil”, dass man ways nicht für Abbiegespuren zusätzlich teilen muss und dass bei ways, die wegen bridge, embankment usw schon geteilt sind, die zusätzlichen lanes nicht über alle Wegteile anlegen muss, wenn man die Spurlänge will, was aber aus Sicht des routing sinnvoll ist. ich sehe den Vorteil darin, dass man mit Ausnahme der “Standard-lanes” an den beteiligten ways selbst nicht weiter herumbasteln muss.

edit: Dreckfuhlerberüchtigung*

geri-oc · 2012-02-09T08:58:27.000Z

Ist zwar neben der “Spur” - aber trifft auch hierzu.

hurdygurdyman:

de_muur:

Aber noch mal die Frage: Wie kommen wir bei den verschiedenen Vorschlaegen jetzt weiter voran, am besten zu einer gemeinsamen Loesung?

Genau, denn es gilt:
„Wo kämen wir hin, wenn jeder sagte, wo kämen wir hin und keiner ginge, um zu sehen, wohin wir kämen, wenn wir gingen." (Kurt Marti)

Ich hatte als Neuling vor einem Jahr schon einmal einen Vorschlag zu den vielen, viel zu vielen “Eigenständigkeiten des Taggen”.

Es gibt ein “TEAM”. Besetzt mit den “Urgesteinen von OSM”. Diese treffen nach Diskussionen auch eine “Entscheidung”. Und warum soll eine “Entscheidung” nicht auch noch einmal diskutiert werden, wenn neue Erkenntnisse es erfordern.

Etwas “Demokratie” unter die “Anarchie”.

ajoessen · 2012-02-09T09:08:50.000Z

geri-oc:

Etwas “Demokratie” unter die “Anarchie”.

So wie bei der Lizenzdiskussion? “Sag ja oder verschwinde!”

weissnich,
ajoessen

hurdygurdyman · 2012-02-09T09:16:37.000Z

ajoessen:

geri-oc:

Etwas “Demokratie” unter die “Anarchie”.

So wie bei der Lizenzdiskussion? “Sag ja oder verschwinde!”

weissnich,
ajoessen

OT on:
Unter http://forum.openstreetmap.org/viewtopic.php?pid=209019#p209019
habe ich mich unter anderem auch schon mal darüber ausgelassen
OT off:
Mindestens dieses Thema hier erfordert einfach die Zusammenarbeit von Mappern, Datenbank-Gurus und Entwicklern von Routern und ein gesundes Maß an Kompromissbereitschaft mit Fokus auf eine für alle praktikable Lösung.

de_muur · 2012-02-09T09:39:08.000Z

hurdygurdyman:

Sehe ich nicht so
…
Die Information zur zusätzlichen Abbiegespur nach links steckt in der Relation als “lanes:extra” und bezieht sich nur auf die Fahrt in Richtung zum Abbiegepunkt “via”.

Sollst auch mal recht haben, das hatte ich nicht ordentlich gelesen.

Hast du einen besseren? Diese Ansatz hat den “Vorteil”, dass man ways nicht für Abbiegespuren zusätzlich teilen muss und dass bei ways, die wegen bridge, embankment usw schon geteilt sind

Wenn wir aus allen anderen Gruenden jeweils die Wege teilen, dann halte ich es fuer eine ziemlich dumme Idee, bei einer weiteren Wegeigenschaft dieses Verfahren aufzugeben und ploetzlich etwas voellig neues einzufuehren. Alle anderen Tags koennte man auch per Relation an die Wege haengen. Aber wuerde dann da noch irgend jemand durchblicken?

Das ganze soll ja auch nicht nur per JOSM-Plugin bedienbar sein, sondern muss auch ohne spezielle Benutzeroberflaeche noch verstanden werden koennen.

=> Ein Grund mehr, warum man nicht ein Beispiel-JOSM-Plugin fuer die Bewertung eines Tagging-Schemas heranziehen sollte.

Gruss
Torsten

hurdygurdyman · 2012-02-09T10:11:24.000Z

de_muur:

…
Wenn wir aus allen anderen Gruenden jeweils die Wege teilen, dann halte ich es fuer eine ziemlich dumme Idee, bei einer weiteren Wegeigenschaft dieses Verfahren aufzugeben und ploetzlich etwas voellig neues einzufuehren.

Die Idee, Menschen und Güter mit Hilfe von damp- oder motorbetriebenen Fahrzeugen zu befördern , wurde anfangs auch als dumme Idee abgetan und hat sich doch durchgesetzt

de_muur:

Alle anderen Tags koennte man auch per Relation an die Wege haengen. Aber wuerde dann da noch irgend jemand durchblicken?
Das ganze soll ja auch nicht nur per JOSM-Plugin bedienbar sein, sondern muss auch ohne spezielle Benutzeroberflaeche noch verstanden werden koennen.

Welches Relationskonstrukt in OSM wird ohne Hilfmittel in Potlatch, JOSM usw. angelegt und von allen verstanden?

de_muur:

=> Ein Grund mehr, warum man nicht ein Beispiel-JOSM-Plugin fuer die Bewertung eines Tagging-Schemas heranziehen sollte.

Das Tagging-Schema ergibt sich aus dem proposal und wird anhand dessen bewertet. Das Plugin setzt das Tagging-Schema anwenderfreundlich um. Beides ist sicher ausbaufähig, kann aber auch in Folge einer genaueren Betrachtung verworfen werden. Kommen wir zu dem Ergebnis, dass das Proposal unbrauchbar ist, macht das Plugin auch so keinen Sinn mehr.
Für mich zeigen alle drei oben genannten und mit Plugins hinterlegten Proposals lediglich, dass für die verschiedenen Ansätze eine technische Unterstützung des Mappers bei der Eingabe möglich ist (und auch bei der Komplexität Sinn macht).

de_muur · 2012-02-09T12:11:00.000Z

hurdygurdyman:

Welches Relationskonstrukt in OSM wird ohne Hilfmittel in Potlatch, JOSM usw. angelegt und von allen verstanden?

…

Für mich zeigen alle drei oben genannten und mit Plugins hinterlegten Proposals lediglich, dass für die verschiedenen Ansätze eine technische Unterstützung des Mappers bei der Eingabe möglich ist (und auch bei der Komplexität Sinn macht).

Und fuer mich zeigt das, dass diese Vorschlage einfach schon von sich aus zu kompliziert sind. Wenn die Laenge der Spuren nicht in einer Relation versteckt werden, dann braucht man dafuer auch kein extra Hilfswerkzeug.

Die exakte Beschreibung einer Kreuzung mit 7 Strassen mit jeweils 9 Spuren wird zwar immer kompliziert werden, ist zum Glueck ja aber nicht der Normalfall. Wenn in 99% der Faelle ein Konstrukt von einem durchschnittlichen Mapper nicht mehr ohne Hilfsmittel ueberblickt werden kann, dann ist das fuer OSM kein brauchbarer Ansatz.

Gruss
Torsten

viw · 2012-02-09T12:39:26.000Z

de_muur:

hurdygurdyman:

Welches Relationskonstrukt in OSM wird ohne Hilfmittel in Potlatch, JOSM usw. angelegt und von allen verstanden?

…

Für mich zeigen alle drei oben genannten und mit Plugins hinterlegten Proposals lediglich, dass für die verschiedenen Ansätze eine technische Unterstützung des Mappers bei der Eingabe möglich ist (und auch bei der Komplexität Sinn macht).

Und fuer mich zeigt das, dass diese Vorschlage einfach schon von sich aus zu kompliziert sind. Wenn die Laenge der Spuren nicht in einer Relation versteckt werden, dann braucht man dafuer auch kein extra Hilfswerkzeug.

Die exakte Beschreibung einer Kreuzung mit 7 Strassen mit jeweils 9 Spuren wird zwar immer kompliziert werden, ist zum Glueck ja aber nicht der Normalfall. Wenn in 99% der Faelle ein Konstrukt von einem durchschnittlichen Mapper nicht mehr ohne Hilfsmittel ueberblickt werden kann, dann ist das fuer OSM kein brauchbarer Ansatz.

Gruss
Torsten

Die Welt ist nun einmal kompliziert. Nur weil dein Gehirn ständig vereinfacht und filtert kannst du dich überhaupt auf das wesentliche konzentieren. Das andere Personen andere Dinge wesentlich finden unterscheidet die Menschen. Damit wird das Modell dann aber leider auch kompliziert. Wenn es aber ein Hilfsmittel gibt mit dem man das ganze visuell drastellen kann, so kann man wie bei OSM 3D entweder probieren oder besser gleich noch wysiwyg zusammenklicken. Wer sagt denn das ÖPNV Relationen mit den ganzen Metarelationen einfach sind? Dennoch gibt es eine Gruppe von Mappern die sich damit beschäftigen und das auch auswerten.
Gleiches gilt übrigens für TMC.

hurdygurdyman · 2012-02-09T12:39:50.000Z

Somit belasse ich es bei dem bisherigen Meinungsaustausch zu diversen plugins und proposals, der wohl in diesem Stadium keine Lösung erkennen lässt, und bringe deine berechtigte Frage wieder nach oben:

de_muur:

Aber noch mal die Frage: Wie kommen wir bei den verschiedenen Vorschlaegen jetzt weiter voran, am besten zu einer gemeinsamen Loesung?

viw · 2012-02-09T14:36:25.000Z

Also vielleicht nochmal die Probleme zusammenfassen!
Wir wollen gerne Spuren erfassen. Die einen für den ästetischen Aspekt (visuell) die anderen für gezieltes Routing.
Die Praxis bisher jede Straße eine Linie wenn keine bauliche Trennung (Sperrflächen doppelte Linie etc.)
Sie wird durch gute Luftbilder teilweise unterlaufen in dem jede Spur zu einer Linie wird.
Dies ist für alle Seiten unbefriedigend denn:

Routinganweisungen werden so gut wie unmöglich
Routing wird durch einen riesengroßen Routinggrafen unnötig erschwert (Rechenzeit)
Spurwechsel Spurerkennung nach heutigem Stand nicht abbildbar.
optisch sieht die Sache auch nicht besser aus. Da mehrer Straßen übereinander gezeichnet werden.

Lösungsversuche?
Straßen als Flächen erfassen. Damit wäre die Optik jedenfalls stark verbessert. Außerdem könnte Fuß- und Radwege sowie Parkstreifen einfach dargestellt werden.

Für das Routing ist das aber keine Lösung. Hier gabs den Vorschlag von Tags am Weg Relationen am Weg und schließlich auch Linie je Richtung (rechts mitte geradeaus) oder gar für jede Spur aber nicht als highway=*

Vielleicht können die einzelnen Verfechter Ihrer Lösung in zwei bis 4 Zeilen nochmal die Vorteile ihres Ansatzes herausstellen.

errt · 2012-02-09T18:36:03.000Z

viw:

Lösungsversuche?
Straßen als Flächen erfassen. Damit wäre die Optik jedenfalls stark verbessert. Außerdem könnte Fuß- und Radwege sowie Parkstreifen einfach dargestellt werden.

Für das Routing ist das aber keine Lösung.

Auch aus Flächen lässt sich ein Routinggraph errechnen und der muss nicht zwangsweise viel komplexer sein als jetzt. Auch könnte man ja beides (also Linie und Fläche erfassen). Aber beides löst wieder nicht das Spurenproblem beim Routing. Ich befürchte fast, dass das, was wir wollen, mit aktueller Navisoftware nicht machbar ist. Zumindest für Onlinerouter könnten aber Relationen, die die Spuren (sei es nun als Fläche oder Linie) zusammenfassen, helfen.

things-change · 2012-02-09T19:04:09.000Z

Ich würd gern für die Beispiele ein Foto einer etwas komplexeren Kreuzung einfügen, was darf denn als Quelle benutzt werden?

EDIT:

Hab grade gesehen, jemand hat ein weiteres Beispiel eingefügt. Vielleicht können die Ersteller der Alternativen dort vervollständigen?

fkv · 2012-02-10T14:22:47.000Z

things-change:

Hab grade gesehen, jemand hat ein weiteres Beispiel eingefügt.

Ich kann halt Gedanken lesen.

Aber es ist klar, dass in diesem Beispiel mein Schema (Alternative B) abschreckend wirkt, da die Werte für lane_matching so lang sind. Da hilft es nichts, dass sie viel genauer sind als die Alternativen und im Ggs. zu diesen ein zuverlässiges Routing (auch für Fußgänger) ermöglichen. Vielleicht sollte man die Routinginfos für Fußgänger in ein anderes Tag auslagern bzw. auf eine gewisse Intelligenz des Routers vertrauen (der z.B. wissen muss, dass man auf einem Gehsteig oder Radweg umkehren kann, und als Normalfall annehmen kann, dass man an einer Ampel von jedem Gehsteig auf jeden anderen wechseln kann).

de_muur · 2012-02-10T16:28:54.000Z

fkv:

Aber es ist klar, dass in diesem Beispiel mein Schema (Alternative B) abschreckend wirkt, da die Werte für lane_matching so lang sind. Da hilft es nichts, dass sie viel genauer sind als die Alternativen und im Ggs. zu diesen ein zuverlässiges Routing (auch für Fußgänger) ermöglichen.

Ich denke, dass das die eigentlich entscheidende Frage ist: Was will man alles in einem Spurschema erfassen?

Ich denke (z.Z.), dass ein Schema um so besser ist, je mehr Informationen man damit kartieren kann. Das sieht natuerlich weniger uebersichtlich aus als ein Schema, dass nur ein Bruchteil der Informationen darstellen kann.

Insofern kann man die verschiedene Vorschlaege eigentlich nur sehr schwer vergleichen. Statt einfach ein Bild einer Kreuzung als Vorlage zu nehmen, bei dem jeder Vorschlag was anderes mapped, muesste man vielleicht besser klar definierte Einzelfaelle zur Unterscheidung nehmen, wo der Rest gezielt ausgeblendet wird.

Gruss
Torsten

Fabi2 · 2012-02-10T18:07:21.000Z

de_muur:

Fabi2:

Ich frage mich eh, was der wirkliche Nutzen des Spurroutings sein soll, bis darauf, das das Rendering noch realitätsnäher ist?
…

Ach ja, und dann sind da ja auch noch die Mapper, die meinen, der highway=footway + footway=sidewalk wäre kein getrenntes Objekt, was man neben der Straße zusätzlich mappen sollte. Weil schließlich ist die GPS-Genauigkeit ja viel zu schlecht… …ja, aber bei Abbiegespuren, wo im Unterschied zum footway/cycleway, nicht einmal eine Abgrenzung über die gewählte Verhersmittelart möglich ist, soll das dann gehen?

Ich weiss nicht, ob ich dich jetzt missverstehe. Denn die Vorschlaege fuers Spur-Mapping hier zielen ja gerade darauf ab, dass man NICHT eigenstaendige Wege fuer die einzelnen Spuren eintraegt, weil genau das auch das Routing mit den bereits existierenden Navis verschlechtert/unbrauchbar macht.

Generell ist es so, das man die Realität doch das getrennte Einreichnen eines Mapfeatures am besten beschreiben kann. Weil irgendwann kommt dann früher oder später eine ungewöhnliche Abbiegespur und das war es dann mit grobschlächtigen Tags wie “links” und “halb rechts”, etc. Eben genau aus diesem Grund gibt es ja auch die “ein Objekt - ein Mapfeature”-Regel. Das gilt übrigens genauso für die straßenbegleitenden Fuß-/Radwege, usw. Damit sollte dann klar sein, das wenn man Abbiegespuren haben möchte, diese dann auch getrennte Objekte sein sollten.

Jetzt kann man darüber diskutieren, ob man die (Abbbiege)spuren nun als Linienbündel oder als Flächen in OSM abbildet. Wenn man aber bedenkt, das man die Vereinfachung von Flächen auf Linen bisher ja nur gemacht hat, weil die Genauigkeit des GPS/Luftbildes zum genauen Einzeichnen als Fläche nicht ausreicht, sollte man die Spuren auf Grund der beseren Realitätswiedergabe aus Flächen einzeichen, weil offenbar reicht ja die genauigkeit jetzt aus, sonst würde man sich doch nicht überhaupt mit dem Tagging der Spuren abgeben. oder man zeichnet doch nur Linienbündel, weil man zwar grob die Spuren, aber nicht genau deren Grenzen erkennen kann. Das wäre dann der alte Kompromiß, dismal eben nur eine Ebene (Spur statt Straßenabstraktion) tiefer. Wenn man die als Flächen an eine linienförmige Straße hängt, dann bräuchte man zusätzlich noch eine Relation die den Anschluß and die linienförmige Straße beschreibt.

de_muur:

Man kann die Flaechen bei OSM so detailliert erfassen, wie man lustig ist. Aber beim Routinggraphen ist es nun mal so, dass uebertriebene Details echt schaedlich sind. In meinen Augen geht es bei dieser Diskussion also darum, wie man den Mappern eine Loesung fuer die Detailerfassung bieten kann, die A) fuer eine automatische Auswertung (Spurrouting) in Zukunft vorbereitet und B) die bestehenden Navigationsloesungen nicht behindert sondern so gut wie moeglich unterstuetzt.

Das ist doch alles nur eine Frage der Datenvorverarbeitung für das Routingprogramm. Wenn die Spuren alle mit von der Straße (highway=*) unterscheidbaren Tags versehen sind, kann man die in der Vorverarbietung doch leicht so zurechtfiltern, das von z.B. mehr als einer Abgiegespuren in die gleiche Richtung einfach nur noch eine Verbindung für den Routingraphen übrig behalten wird, womit sich das Komplexitätsproblem dann mehrheitlich in Luft auflösen dürfte.

benshu · 2012-02-12T14:58:37.000Z

Hallo allerseits,

hurdygurdyman hat mich auf die hier tobende Diskussion aufmerksam gemacht und gefragt, ob ich meine (hoffentlich vielen und tiefgehenden :P) Überlegungen beisteuern möchte, die ich während der Entwicklung der turn-lanes-Proposal angestellt habe. Wie ich ihm bereits mitgeteilt habe, kann ich als einfacher Informatiker mit begrenztem Einblick ins Verkehrsingenieurswesen keine neuen Erkenntnisse beisteuern. Was ich beisteuern kann sind ein paar banale Feststellungen.

Bei OpenStreetMap handelt es sich um eine kollaborative Anstrengung Geodaten unserer Welt zu erfassen und der Allgemeinheit zur Verfügung zu stellen. Die Hoffnung ist, dass alle durch das gegenseitiges Geben und Nehmen profitieren. Auch wenn Vollständigkeit, Richtigkeit und Präzision das ultimative Ziel sind, so sind diese noch einen weiten Weg entfernt. Heute ist das Ziel die Diskrepanz zwischen den erfassten Daten und der Wirklichkeit soweit und schnell es geht zu minimieren. Um 1990 geisterte ein Paper mit dem Titel “Worse is Better” durch die Software-Engineering Welt. Es verbreitete die Idee, dass es besser ist jetzt etwas suboptimales zu haben, als auf ewig dem Heiligen Gral hinterherzujagen.

In der Einleitung meines Vorschlags schreibe ich “[a]t some point lanes will (hopefully) [be] mapped as individual ways or areas […]”. Einen Weg oder gar eine Fläche pro Spur zu haben ist der Heilige Gral, ein fantastischer Traum. Meiner Einschätzung nach sollte die erste Priorität sein den Detailgrad auf Teufel komm raus zu steigern. Wenn es später strikt mächtigere Modelle gibt um Spuren zu erfassen, so kann man Daten aus dem Modell von heute in das neue übertragen. Eines Tages wird es sich dabei vielleicht auch um eine Fläche pro Fahrstreifen handeln.

Ein paar Dinge zu meinem Proposal und dem zugehörigen Plugin: (Mein) Ziel war es, das Einpflegen der Spurinformationen so einfach wie möglich zu gestalten. In diesen Aspekt ist wirklich viel Arbeit geflossen. Dafür wurde aber ein wesentlicher Kompromiss gemacht, der hier zurecht angeprangert wurde: Längenangaben in Tags.
Da man die Länge einer Spur relativ bequem durch eine Art Drag-n-Drop manipulieren kann, ist eine andere Lösung nicht ohne weiteres möglich. Theoretisch könnte man jedes mal einen Knoten erzeugen um den Anfang der Spur zu beschreiben, aber man könnte den alten nicht ohne Weiteres löschen.

Ebenfalls zurecht kritisiert wurde die Tatsache, dass nur Abbiegespuren abgebildet werden können. Natürlich war das genau das angepeilte Ziel, aber hier wird ja nach einem mächtigeren Modell gesucht.

Ich erkenne die genannten Schwächen meines Vorschlags im Rahmen dieser Diskussion an. Nichtsdestotrotz finde ich, dass es zusammen mit dem bestehenden lanes-Tag eine fürs erste akzeptable Lösung ist. Nichtzuletzt weil das Erfassen der Daten durch das Plugin so einfach ist. Der Quellcode des Plugins ist Open-Source unter der GPL, wobei ich ihn bei guter Begründung auch gerne unter einer liberaleren Lizenz weitergeben würde. Ich für meinen Teil würde mich freuen, wenn jemand ein benutzerfreundliches Plugin für ein komplexeres Fahrstreifenmodell schreiben würde.

Abschließend möchte ich unterstreichen, dass es sich bei obigen Feststellungen um meine bescheidene Meinung handelt. Die hier zu fällende Entscheidung sollte von Leuten getroffen werden, die tiefer mit dem OSM-Projekt verstrickt sind als ich. In diesem Sinne werde ich mich aus der weiteren Disussion heraushalten, sofern es keine rein technischen Fragen gibt.