Routing / Spurmapping

Fabi2 · 2012-02-08 22:39:34

fkv wrote:

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?

Last edited by Fabi2 (2012-02-08 22:41:42)

de_muur · 2012-02-09 07:42:44

Fabi2 wrote:

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 wrote:

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-09 09:07:35

Fabi2 wrote:

...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 … s/Wayparts
zeigt einen Ansatz am Beispiel einer kreuzungsfreien Autobahn-Auf-/Abfahrt.
http://wiki.openstreetmap.org/wiki/Prop … 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/Rela … posed/Lane
http://wiki.openstreetmap.org/wiki/Prop … _Relations
http://wiki.openstreetmap.org/wiki/User … e_geometry
http://wiki.openstreetmap.org/wiki/Vors … enbereiche
http://wiki.openstreetmap.org/wiki/DE:Lane_Assist
Vielleicht bieten die auch noch ein paar gute Ideen

Fabi2 wrote:

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% … 9&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 wrote:

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/Wiki … %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 wrote:

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)

Last edited by hurdygurdyman (2012-02-09 09:11:19)

hurdygurdyman · 2012-02-09 09:41:59

de_muur wrote:

...
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/Rela … owed_Turns
und im Beispiel http://wiki.openstreetmap.org/wiki/Rela … #Example_2 mit einer Rechtsabbiegespur.
Das ganze ist genauso robust wie die turn-restrictions , da from-via-to die Richtung bestimmt.

de_muur wrote:

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

Last edited by hurdygurdyman (2012-02-09 09:58:25)

geri-oc · 2012-02-09 09:58:27

Ist zwar neben der "Spur" - aber trifft auch hierzu.

hurdygurdyman wrote:

de_muur wrote:
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-09 10:08:50

geri-oc wrote:

Etwas "Demokratie" unter die "Anarchie".

So wie bei der Lizenzdiskussion? "Sag ja oder verschwinde!"

weissnich,
ajoessen

hurdygurdyman · 2012-02-09 10:16:37

ajoessen wrote:

geri-oc wrote:
Etwas "Demokratie" unter die "Anarchie".
So wie bei der Lizenzdiskussion? "Sag ja oder verschwinde!"
weissnich,
ajoessen

OT on:
Unter http://forum.openstreetmap.org/viewtopi … 19#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.

Last edited by hurdygurdyman (2012-02-09 10:18:02)

de_muur · 2012-02-09 10:39:08

hurdygurdyman wrote:

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-09 11:11:24

de_muur wrote:

...
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 wrote:

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 wrote:

=> 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).

Last edited by hurdygurdyman (2012-02-09 12:29:16)

de_muur · 2012-02-09 13:11:00

hurdygurdyman wrote:

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-09 13:39:26

de_muur wrote:

hurdygurdyman wrote:
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-09 13:39:50

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 wrote:

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

Last edited by hurdygurdyman (2012-02-09 13:40:10)

viw · 2012-02-09 15:36:25

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-09 19:36:03

viw wrote:

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-09 20:04:09

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?

Last edited by things-change (2012-02-09 20:07:27)

fkv · 2012-02-10 15:22:47

things-change wrote:

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-10 17:28:54

fkv wrote:

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-10 19:07:21

de_muur wrote:

Fabi2 wrote:
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 wrote:

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.

Last edited by Fabi2 (2012-02-12 17:06:19)

benshu · 2012-02-12 15:58:37

Hallo allerseits,

hurdygurdyman hat mich auf die hier tobende Diskussion aufmerksam gemacht und gefragt, ob ich meine (hoffentlich vielen und tiefgehenden ) Ü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.

Fabi2 · 2012-02-12 17:31:38

@benshu:

Das was du vor hast, ist in etwa so, als wenn du deinen Heimatort auf Grund der "Einfachheit" als Punkt mappst und dann ein Plugin schreibts, um passende Tags für die Repräsentation der Häuser, Straßen, etc. hinzuzufügen.

Einfach ist ein Modell, dann, wenn man es, egal mit welchem Editor, als Mensch nachvollziehen und bearbeiten kann. OSM setzt ja auf die manuelle menschliche Pflege von XML-Tags, wenn man nicht wollen würde, das menschen die Berabeiten, dürften wir nur noch irgendwelche Frontends zur Bearbeitung der Geodaten benutzen.

Was ist denn das Problem dabei, wenigstens die Spuren als Linien zu mappen? Weil wenn man die dieses Detail der Realität drin haben möchte, kann man es ja auch gleich richtig machen. Spätestens bei der Datenverarbeitung muß man ja sonst eh künstlich die Spuren erzeugen, wobei dann solche Krämpfe dabei herauskommen wie z.B. die --make-cycleways-Option von mkgmap. Da gibts dann schöne gerade Linien neben der Straße, die mit der Realität meist genau Nichts zu tun haben.

railrun · 2012-02-12 17:44:24

Fabi2 wrote:

@benshu:
Das was du vor hast, ist in etwa so, als wenn du deinen Heimatort auf Grund der "Einfachheit" als Punkt mappst und dann ein Plugin schreibts, um passende Tags für die Repräsentation der Häuser, Straßen, etc. hinzuzufügen.

Äh, du hast dir das Plugin und die Videos einmal angeschaut? Den Vergleich versteh ich jetzt nicht...

Fabi2 wrote:

Einfach ist ein Modell, dann, wenn man es, egal mit welchem Editor, als Mensch nachvollziehen und bearbeiten kann. OSM setzt ja auf die manuelle menschliche Pflege von XML-Tags, wenn man nicht wollen würde, das menschen die Berabeiten, dürften wir nur noch irgendwelche Frontends zur Bearbeitung der Geodaten benutzen.

[IRONIE]Ich hab meinen Mechaniker gefragt, ob man nicht einen Motor bauen könnte, der nur aus einem Teil besteht, damit ich ohne Probleme daran rumschrauben kann...[/IRONIE]
Komplizierte Sachverhalte lassen sich nun einmal nicht einfach darstellen.

Fabi2 wrote:

Was ist denn das Problem dabei, wenigstens die Spuren als Linien zu mappen?

Wegen dem Routinggraphen vielleicht?!

Fabi2 wrote:

Weil wenn man die dieses Detail der Realität drin haben möchte, kann man es ja auch gleich richtig machen. Spätestens bei der Datenverarbeitung muß man ja sonst eh künstlich die Spuren erzeugen, wobei dann solche Krämpfe dabei herauskommen wie z.B. die --make-cycleways-Option von mkgmap. Da gibts dann schöne gerade Linien neben der Straße, die mit der Realität meist genau Nichts zu tun haben.

Hauptsache es sieht schön aus... Aber Navigation kannst du dann auch vergessen... Ziel verfehlt... Meine Meinung...

Last edited by railrun (2012-02-12 17:44:42)

Fabi2 · 2012-02-12 18:57:14

railrun wrote:

Fabi2 wrote:
@benshu:
Das was du vor hast, ist in etwa so, als wenn du deinen Heimatort auf Grund der "Einfachheit" als Punkt mappst und dann ein Plugin schreibts, um passende Tags für die Repräsentation der Häuser, Straßen, etc. hinzuzufügen.
Äh, du hast dir das Plugin und die Videos einmal angeschaut? Den Vergleich versteh ich jetzt nicht...

Wieso, das hast du doch halbwegs verstanden, siehe deine Aussage:

railrun wrote:

[IRONIE]Ich hab meinen Mechaniker gefragt, ob man nicht einen Motor bauen könnte, der nur aus einem Teil besteht, damit ich ohne Probleme daran rumschrauben kann...[/IRONIE]

Halbwegs deshalb, weil ein Modell eine begrenzte und überschaubare Menge an Varianten ohne Probleme abbilden kann. Oder überschaust du alle Varianten die in der Realität vorkommen, um ein für alle passendes Modell bauen zu können? Außerdem sammeln wie geographische Objekte in einer Datenbank und da läßt sich ein linienförmiges Objekt mit einem bestimmten Verlauf und einer bestimmten Länge nun mal am besten als Weg erfassen.

Extra für dich wiederhole ich hier noch mal meine Argumentation von oben:

Einfach ist ein Modell, dann, wenn man es, egal mit welchem Editor, als Mensch nachvollziehen und bearbeiten kann. OSM setzt ja auf die manuelle menschliche Pflege von XML-Tags, wenn man nicht wollen würde, das Menschen die bearbeiten, dürften wir nur noch irgendwelche Frontends zur Bearbeitung der Geodaten benutzen.

Fazit: Man muß es auch mit z.B. Potlatch, Merkaartor, usw. bearbeiten können.

railrun wrote:

Komplizierte Sachverhalte lassen sich nun einmal nicht einfach darstellen.

Was ist an einer Linie mit passenden Tags denn so kompliziert? Das stellt doch eine wie auch immer geartete Spur ausreichend genau da!

railrun wrote:

Fabi2 wrote:
Was ist denn das Problem dabei, wenigstens die Spuren als Linien zu mappen?
Wegen dem Routinggraphen vielleicht?!

[ ] Ich habe das obige Posting zum Thema Routinggraph gelesen.
[ ] Ich habe die Argumentation versucht zu verstehen.

railrun wrote:

Fabi2 wrote:
Weil wenn man die dieses Detail der Realität drin haben möchte, kann man es ja auch gleich richtig machen. Spätestens bei der Datenverarbeitung muß man ja sonst eh künstlich die Spuren erzeugen, wobei dann solche Krämpfe dabei herauskommen wie z.B. die --make-cycleways-Option von mkgmap. Da gibts dann schöne gerade Linien neben der Straße, die mit der Realität meist genau Nichts zu tun haben.
Hauptsache es sieht schön aus... Aber Navigation kannst du dann auch vergessen... Ziel verfehlt... Meine Meinung...

Wieso soll man da die Navigation vergessen können? Meine Argumente hab ich ja schon in den Vorpostings angeführt.

Last edited by Fabi2 (2012-02-12 19:10:30)

de_muur · 2012-02-12 19:53:20

Fabi2 wrote:

Wieso soll man da die Navigation vergessen können? Meine Argumente hab ich ja schon in den Vorpostings angeführt.

Die Antwort auf deine Frage steht auf den vorangehenden 7 Seiten dieser Diskussion. Da hat man wenig Lust, sich nochmal mit deinen Argumenten auseinanderzusetzen.

Bzgl. der geforderten Einfachheit stimme ich allerdings mit dir ueberein. Nur weil es halt sehr komplizierte Faelle gibt, bei denen zwangslaeufig auch das Mapping kompliziert wird, heisst das nicht, dass das Mapping von einfachen Faellen auch kompliziert sein muss.

Gruss
Torsten

Fabi2 · 2012-02-12 22:34:07

de_muur wrote:

Fabi2 wrote:
Wieso soll man da die Navigation vergessen können? Meine Argumente hab ich ja schon in den Vorpostings angeführt.
Die Antwort auf deine Frage steht auf den vorangehenden 7 Seiten dieser Diskussion. Da hat man wenig Lust, sich nochmal mit deinen Argumenten auseinanderzusetzen.
Bzgl. der geforderten Einfachheit stimme ich allerdings mit dir ueberein. Nur weil es halt sehr komplizierte Faelle gibt, bei denen zwangslaeufig auch das Mapping kompliziert wird, heisst das nicht, dass das Mapping von einfachen Faellen auch kompliziert sein muss.

Ja, ich geb ja zu, ich hab die vorherigen Seiten nur mal schnell durchgesehen und leider habe ich beim Überfliegen der so mal geschätzt 90% Diskussion über wenig taugliche Vorschläge in Form von Zusatztags, übersehen, das es auch schon min. einen zum Einzelmapping gab. Das ist definitiv der bessere Ansatz für das Problem, weil wenn man es sich eine Weile überlegt, ist doch schon alles da:

highway=*
lanes=*
oneway=yes
maxspeed=*

damit kann man fast alles taggen. Für die Spur mit Doppelnutzung und Sperrlinien habe ich dann noch:

barrier=other_direction oder barrier=contraflow (abstrakte Barriere in Form des Gegenverkehrs in der Mitte der doppelt genutzten Spur)
barrier=street_marking (Barriere in Form von Markierungen, kurz vor dem Ende der Spur)

Naturlich kann man die Spuren die mit Sperrlinien enden in die entsprechenden Richtungen optional auch ganz weglassen.
Das war es erst mal was ich gerade so schnell gesehen habe, ich seh das noch mal genau durch ob noch fehlen sollte.

Last edited by Fabi2 (2012-02-12 22:38:09)

hurdygurdyman · 2012-02-13 19:41:20

Fabi2 wrote:

...
Ja, ich geb ja zu, ich hab die vorherigen Seiten nur mal schnell durchgesehen und leider habe ich beim Überfliegen der so mal geschätzt 90% Diskussion über wenig taugliche Vorschläge in Form von Zusatztags, übersehen, das es auch schon min. einen zum Einzelmapping gab. Das ist definitiv der bessere Ansatz für das Problem, weil wenn man es sich eine Weile überlegt, ist doch schon alles da:
highway=*
lanes=*
oneway=yes
maxspeed=*
damit kann man fast alles taggen.
...

Ich denke, wir müssen hier unterscheiden nach
1. Verwendbarkeit der Daten für Renderer als geografische Information
2. Auswertbarkeit zum (vorausschauenden) Routing
An diesem Spagat scheitern wohl die meisten Ansätze, zumal auch noch der Anspruch besteht, in dem Schema das gesamte Linienbündel incl. bus, tram, footway und cycleway sowie aller möglichen Trennungen dazwischen erschlagen zu wollen. Und dann soll das alles auch noch für den Mapper transparent und ohne Tools erfassbar sein
Warum konzentrieren wir uns nicht auf das Thema dieses threads "Routing und Spurmapping", welches in der Masse der Fälle nur Straßen (und selten auch Radwege) betrifft. Mir ist eine Lösung für 80-95 % der Fälle lieber als für 100 % keine Lösung.

P.S. In diesem Sinne möchte ich auch benshu danken, dass er sich hier gemeldet hat

Last edited by hurdygurdyman (2012-02-13 19:42:13)

Announcement

#176 2012-02-08 22:39:34

Re: Routing / Spurmapping

#177 2012-02-09 07:42:44

Re: Routing / Spurmapping

#178 2012-02-09 09:07:35

Re: Routing / Spurmapping

#179 2012-02-09 09:41:59

Re: Routing / Spurmapping

#180 2012-02-09 09:58:27

Re: Routing / Spurmapping

#181 2012-02-09 10:08:50

Re: Routing / Spurmapping

#182 2012-02-09 10:16:37

Re: Routing / Spurmapping

#183 2012-02-09 10:39:08

Re: Routing / Spurmapping

#184 2012-02-09 11:11:24

Re: Routing / Spurmapping

#185 2012-02-09 13:11:00

Re: Routing / Spurmapping

#186 2012-02-09 13:39:26

Re: Routing / Spurmapping

#187 2012-02-09 13:39:50

Re: Routing / Spurmapping

#188 2012-02-09 15:36:25

Re: Routing / Spurmapping

#189 2012-02-09 19:36:03

Re: Routing / Spurmapping

#190 2012-02-09 20:04:09

Re: Routing / Spurmapping

#191 2012-02-10 15:22:47

Re: Routing / Spurmapping

#192 2012-02-10 17:28:54

Re: Routing / Spurmapping

#193 2012-02-10 19:07:21

Re: Routing / Spurmapping

#194 2012-02-12 15:58:37

Re: Routing / Spurmapping

#195 2012-02-12 17:31:38

Re: Routing / Spurmapping

#196 2012-02-12 17:44:24

Re: Routing / Spurmapping

#197 2012-02-12 18:57:14

Re: Routing / Spurmapping

#198 2012-02-12 19:53:20

Re: Routing / Spurmapping

#199 2012-02-12 22:34:07

Re: Routing / Spurmapping

#200 2012-02-13 19:41:20

Re: Routing / Spurmapping

Board footer