Routing / Spurmapping

hurdygurdyman · 2012-09-26T09:24:37.000Z

Cobra:

Ich sehe nur eine unstrukturierte Wall of Text ohne Bilder, die mich abschreckt, das zu lesen.

Hilft dir das?
grafischer Ansatz:
http://ubuntuone.com/6HPgoCItJy0WtwKrKpU3H2
Erläuterungen als proposal-Vorstufe:
http://ubuntuone.com/2gFbILhpniHAboIgdE9iea

Auf diese Dokumente und ein “Testgebiet” wird aus der “wall of text” verlinkt.

Cobra · 2012-09-26T09:34:58.000Z

Ich wollte dir nur eine mögliche Ursache schildern, wieso niemand darauf eingeht.

chris66 · 2012-09-26T09:49:46.000Z

hurdygurdyman:

sobald bing high res vorliegt

Super Beispiel für “Malen nach Zahlen”
http://www.openstreetmap.org/?lat=48.37175&lon=7.8203&zoom=17
Keine Straßennamen, kein Gebäudebezeichnungen, keine access-Tags,
aber hübsch sieht es aus.

hurdygurdyman · 2012-09-26T09:50:48.000Z

Cobra:

Ich wollte dir nur eine mögliche Ursache schildern, wieso niemand darauf eingeht.

Der Tip ist angekommen. Danke.
Ich bau das dann wohl besser neu auf.

hurdygurdyman · 2012-09-26T10:51:13.000Z

chris66:

Super Beispiel für “Malen nach Zahlen”
http://www.openstreetmap.org/?lat=48.37175&lon=7.8203&zoom=17
Keine Straßennamen, kein Gebäudebezeichnungen, keine access-Tags,
aber hübsch sieht es aus.

+1
Da gehe ich aber erst ran, wenn’s weg ist, weil sich da als Konversionsfläche sowieso dauernd was ändert. Die alten shelter stehen halt noch und werden auch teilweise als Lager genutzt.
Ist aber leicht OT, obwohl man auch hier sieht, wie wichtig vernünftige Lösungen für Spuren und Straßenflächen sind.
edit:
Ich gestehe: einiges dort habe ich vor knapp zwei Jahren selbst hingeklatscht. :ascheaufmeinhaupt:

hurdygurdyman · 2012-09-26T13:37:13.000Z

Zurück zum Thema:
ich habe meinen Vorschlag mal neu sortiert, damit auch Neueinsteiger in’s Thema mitkommen. Der Grund, warum ich mich an die Sache heranwagte, war der “Missbrauch” des highway-tags für die Abbildung von Spuren mit Auswüchsen wie diesen:
http://www.openstreetmap.org/?lat=51.324055&lon=12.291283&zoom=18
oder diesen, den ich für meinen Test verwendete:
http://www.openstreetmap.org/?lat=47.9901266098022&lon=7.84436970949173&zoom=18

Diese Änsätze:
Lösungsansatz grafisch: http://ubuntuone.com/6HPgoCItJy0WtwKrKpU3H2
Lösungsansatz Text: : http://ubuntuone.com/2gFbILhpniHAboIgdE9iea
wurden hier in etwas anderer Form schon mal vorgestellt und diskutiert.
Die Frage war, ob das auch an komplexen Stellen geht, weshalb ich in der hier erläuterten Form:
Testgebiet: http://ubuntuone.com/3qbMn7RH5GJWvndWS76YDg
das ganze mal mit JOSM durchgespielt habe. Dort findet ihr auch die links zu einer osm- und einer xml-Datei sowie zu zwei aerowest-Bildern, womit ihr den Ansatz auf seine Alltagstauglichkeit abklopfen könnt.

Wer also Lust hat, sich da mal rein zu hängen: viel Spaß und Feuer frei.

errt · 2012-09-26T14:16:32.000Z

Mir gefällt der Vorschlag ganz gut, selbst das etwas komplexere Testgebiet sieht durchaus übersichtlich aus.

An einer Stelle verstehe ich’s aber gerade nicht: Die Mattenstraße läuft in zwei lane=residential aus, sollte die nicht der Kompatibilität wegen weiterhin selbst mit der Kronenstraße verbunden sein, zusätzlich zu den lanes?
Außerdem haben deine Kreuzungsflächen nicht immer gemeinsame Nodes mit den einmündenden Highways, wie beschrieben.

Tordanik · 2012-09-26T18:03:43.000Z

hurdygurdyman:

Diese Änsätze:
Lösungsansatz grafisch: http://ubuntuone.com/6HPgoCItJy0WtwKrKpU3H2
Lösungsansatz Text: : http://ubuntuone.com/2gFbILhpniHAboIgdE9iea
wurden hier in etwas anderer Form schon mal vorgestellt und diskutiert.

Ich hatte den Vorschlag schon mal angeschaut, aber aus meiner Sicht lassen sich deine lane-Ways eben genauso schlecht auswerten wie alle anderen Ansätze, bei denen Ways einfach unverbunden nebeneinander liegen und die Zusammengehörigkeit nur mit einem ordentlichen Schuss menschlicher Intuition erkennbar ist. Von daher ist auch meine Kritik dieselbe: Fehlende maschinenlesbare Struktur der Daten.

Den Ansatz bei den Kreuzungen für sich genommen (mit Fläche und Ways für die Abbiegemöglichkeiten) fände ich im Gegensatz zu der Darstellung entlang der Ways ganz ok.

hurdygurdyman · 2012-09-26T18:08:51.000Z

errt:

…
An einer Stelle verstehe ich’s aber gerade nicht: Die Mattenstraße läuft in zwei lane=residential aus, sollte die nicht der Kompatibilität wegen weiterhin selbst mit der Kronenstraße verbunden sein, zusätzlich zu den lanes?
Außerdem haben deine Kreuzungsflächen nicht immer gemeinsame Nodes mit den einmündenden Highways, wie beschrieben.

Danke für dein Adlerauge. ich werde das mit der Mattenstraße nachbessern. Und das mit den gemeinsamen nodes der Kreuzungsflächen mit den highways muss ich vor lauter lanes usw. wohl auch mal übersehen haben, wobei ich mich aber mittlerweile auch frage, ob das wirklich zwingend sein muss oder ob nicht gemeinsame nodes mit den lane=* reichen Für das routing wäre es nicht erforderlich.

Fabi2 · 2012-09-26T20:18:00.000Z

hurdygurdyman:

hurdygurdyman:

So, nach mehrmaligem Schieben und Grübeln wage ich es, meinen Ansatz zum lane-mapping hier vertiefend zur Diskussion zu stellen.
…

push:
Schade, hat wohl keiner Lust, zu diskutieren.

Ich habe es grob durchgesehen, aber irgendwie keine richtige Meinung dazu, weder ist es für mich ganz schlecht, noch gut genug.

hurdygurdyman:

Und bis dahin geht der “Missbrauch von highway=*” für Spuren fröhlich weiter, sobald bing high res vorliegt
Ein aktuelles Beispiel:
http://www.openstreetmap.org/?lat=48.353639&lon=7.806424&zoom=18&layers=M
edit:
auch schön:
http://www.openstreetmap.org/?lat=48.359814&lon=7.770861&zoom=18&layers=M

Wenn dein Schema nicht damit klar kommt, das wahlweise Wege/Spuren nicht nur als Linien sondern auch als
Flächen erfasst wurden, dann solltest du es nachbessern, denn die Tendenz geht in der Zukunft ja eher mehr zu Hires-Luftbildern und damit sollte es dann auch noch funktionieren. Ob es dann noch für den Normalmapper handhabbar ist, ist dann wieder nen andere Diskussion.

Fabi2 · 2012-09-26T20:35:27.000Z

Tordanik:

Ich hatte den Vorschlag schon mal angeschaut, aber aus meiner Sicht lassen sich deine lane-Ways eben genauso schlecht auswerten wie alle anderen Ansätze, bei denen Ways einfach unverbunden nebeneinander liegen und die Zusammengehörigkeit nur mit einem ordentlichen Schuss menschlicher Intuition erkennbar ist. Von daher ist auch meine Kritik dieselbe: Fehlende maschinenlesbare Struktur der Daten.

Soweit ich es gesehen habe, ging das mit erhöhtem Rechenaufwand mit dem Schemas durchaus, auch wenn da höhere höhere Abstraktionsstufen für Fahrbahnen und die Straße fehlen. Passend getaggte nebeneinanderligende Linien geben als Abstraktion schon die Realität ganz gut wieder, wenn man es genauer haben möchte kann muß man dann eben Flächen taggen. Linien sind eben auch immer noch nur ein (detailreduziertes) Modell der Realität. Komisch fand ich auch den Ansatz mit den einheitlichen Kreuzungsflächen zusammen mit den Linien, die man ja zum Verbinden aller möglichen Fahrwege sowieso noch braucht. Dann stelle ich die Kreuzungen wie bei mir geplant, lieber als “magische Quadrate” aus Teilflächen dar. Ja, eraffsungsfreundlich ist was anderers, aber irgendwo muß man immer Kompromisse machen…

hurdygurdyman · 2012-09-27T06:25:24.000Z

Tordanik:

…
Ich hatte den Vorschlag schon mal angeschaut, aber aus meiner Sicht lassen sich deine lane-Ways eben genauso schlecht auswerten wie alle anderen Ansätze, bei denen Ways einfach unverbunden nebeneinander liegen und die Zusammengehörigkeit nur mit einem ordentlichen Schuss menschlicher Intuition erkennbar ist. Von daher ist auch meine Kritik dieselbe: Fehlende maschinenlesbare Struktur der Daten.

Den Ansatz bei den Kreuzungen für sich genommen (mit Fläche und Ways für die Abbiegemöglichkeiten) fände ich im Gegensatz zu der Darstellung entlang der Ways ganz ok.

Ich wollte mit dem Ansatz eine Alternative zum Missbrauch des highway-tags für Spuren schaffen und primär die Auswertung der Spuren für’s routing ermöglichen. Zusammengehörigkeit wäre durch eine Relation “highway” in der die Spuren zusammengefasst werden, machbar. Da könnten dann auch alle gemeinsamen Eigenschaften der Straße wie name, ref, maxspeed usw. abgebildet werden.

Fabi2:

…
Wenn dein Schema nicht damit klar kommt, das wahlweise Wege/Spuren nicht nur als Linien sondern auch als
Flächen erfasst wurden, dann solltest du es nachbessern, denn die Tendenz geht in der Zukunft ja eher mehr zu Hires-Luftbildern und damit sollte es dann auch noch funktionieren. Ob es dann noch für den Normalmapper handhabbar ist, ist dann wieder nen andere Diskussion.

Ich dachte schon mal daran, das die Straßenfläche insgesamt als Fläche erfasst und in die Relation “highway” eingebunden werden kann. Ich denke, dass routing über Flächen mittelfristig nicht vernünftig umsetzbar ist und einen hohen Aufwand des preprocessing erfordert. Routing über Kanten und Knoten ist etabliert und kann über “lane” als way problemlos erfolgen. Für eine detaillierte Karte kann man sich dann je nach Bedarf nur die Straßenfläche aus dem area oder zusätzlich die Spurinformationen mit Richtungspfeilen usw. aus den lanes holen.
edit: Wäre mit waterway vergleichbar. Da erfassen wir ja auch den Verlauf als way und die Fläche als area separat.
Ja, und ich hatte den Normalmapper im Auge, dessen Abstraktionsvermögen auch bei Nachbesserungen/Änderungen nicht überfordert werden soll.

errt:

…
An einer Stelle verstehe ich’s aber gerade nicht: Die Mattenstraße läuft in zwei lane=residential aus, sollte die nicht der Kompatibilität wegen weiterhin selbst mit der Kronenstraße verbunden sein, zusätzlich zu den lanes?
Außerdem haben deine Kreuzungsflächen nicht immer gemeinsame Nodes mit den einmündenden Highways, wie beschrieben.

Wurde nachgebessert.

Tordanik · 2012-09-27T09:30:48.000Z

Fabi2:

Soweit ich es gesehen habe, ging das mit erhöhtem Rechenaufwand mit dem Schemas durchaus, auch wenn da höhere höhere Abstraktionsstufen für Fahrbahnen und die Straße fehlen.

Wenn du keinen Algorithmus kennst, der mich davon überzeugt, sehe ich da keine verlässliche Methode.

Meine momentane Einschätzung:

Lose Spurways ohne irgendeine Verbindung → keine Chance

Lose Spurways “eingerahmt” von einer area:highway-Fläche, oder in einer Relation pro highway → machbar mit großem Rechenaufwand und sehr komplexer Programmierarbeit

Tag-basierende Lösung (:lanes) → verhältnismäßig einfach auswertbar, aber hat keine Lösung für komplizierte Kreuzungen und einige andere Details

hurdygurdyman:

Ich wollte mit dem Ansatz eine Alternative zum Missbrauch des highway-tags für Spuren schaffen und primär die Auswertung der Spuren für’s routing ermöglichen. Zusammengehörigkeit wäre durch eine Relation “highway” in der die Spuren zusammengefasst werden, machbar. Da könnten dann auch alle gemeinsamen Eigenschaften der Straße wie name, ref, maxspeed usw. abgebildet werden.

Eine Relation wäre machbar, aber ihre flächendeckende Verwendung in der Praxis sehe ich als unwahrscheinlich. Ich befürchte eher, dass Mapper das Konzept mit Spur-Ways dann einfach verwenden und (vergeblich) auf eine funktionierende Auswertung hoffen würden, weil es für den naiven Betrachter ja so aussieht, als sei alles erfasst.

Auch für Routing ist übrigens die Zusammengehörigkeit relevant - zum einen für Straßennamen etc. wegen entsprechender Hinweise, was man notfalls auch über ein Duplizieren der Tags der Straße erreichen könnte, aber auch für Spurwechsel. Hast du dafür eine Lösung parat?

hurdygurdyman · 2012-09-27T10:32:23.000Z

Tordanik:

Eine Relation wäre machbar, aber ihre flächendeckende Verwendung in der Praxis sehe ich als unwahrscheinlich. Ich befürchte eher, dass Mapper das Konzept mit Spur-Ways dann einfach verwenden und (vergeblich) auf eine funktionierende Auswertung hoffen würden, weil es für den naiven Betrachter ja so aussieht, als sei alles erfasst.

Auch für Routing ist übrigens die Zusammengehörigkeit relevant - zum einen für Straßennamen etc. wegen entsprechender Hinweise, was man notfalls auch über ein Duplizieren der Tags der Straße erreichen könnte, aber auch für Spurwechsel. Hast du dafür eine Lösung parat?

Ich sehe auch nicht unbedingt den flächendeckenden Einsatz. Aber dort, wo jetzt schon highway “vergewaltigt” wird, um Spuren abzubilden (siehe http://forum.openstreetmap.org/viewtopic.php?pid=277700#p277700 und extrem http://www.openstreetmap.org/?lat=51.324055&lon=12.291283&zoom=18 ), sehe ich den Ansatz als Alternative. Durch die high res-Bilder befürchte ich eine Inflation des highway-Missbrauchs, und da sollten wir schnell eine vernünftige Lösung finden.
Zum routing und Spurwechsel:
Vorausschauendes routing sollte über mehrere Kreuzungen/Abzweigungen hinaus möglichst wenig Spurwechsel erzeugen. Verlaufen parallele Spuren über eine längere Strecke oder über die nächste Abbiegemöglichkeit hinaus geradeaus, könnte entweder die geometrische Mitte zwischen den Spuren oder die gemäß regionaler Vorschriften bevorzugt zu verwendende Spur (rechte Spur bei Rechtsverkehr) für den Graph verwendet werden.
Für die Spurwahl bzw. den Wechsel kann der Router den frühestmöglichen Verbindungsknoten wählen. Die GPS-Ungenauigkeit macht insbesondere in Häuserschluchten die genaue Ortung der Spur als Standort sowieso unmöglich.

Fabi2 · 2012-09-27T21:37:13.000Z

hurdygurdyman:

Ich wollte mit dem Ansatz eine Alternative zum Missbrauch des highway-tags für Spuren schaffen und primär die Auswertung der Spuren für’s routing ermöglichen. Zusammengehörigkeit wäre durch eine Relation “highway” in der die Spuren zusammengefasst werden, machbar. Da könnten dann auch alle gemeinsamen Eigenschaften der Straße wie name, ref, maxspeed usw. abgebildet werden.

Bild doch erst mal die Fahrbahnen ab, bevor du die ganze Straße zusammen bastelst, weil bei ner zusätzlichen carriageway-Relation wäre das ganze dann wenigstens von der Realtionstypen kompatibel zu meiner Idee. Jetzt gerade habe ich auch gesehen, das man aus meiner Sicht lane_restriction nicht braucht, da man ja bei dir eh nur an der Kreuzung immer dahin fahren darf, wo auch ein verbundener Weg hinführt.

hurdygurdyman:

Ich dachte schon mal daran, das die Straßenfläche insgesamt als Fläche erfasst und in die Relation “highway” eingebunden werden kann. Ich denke, dass routing über Flächen mittelfristig nicht vernünftig umsetzbar ist und einen hohen Aufwand des preprocessing erfordert. Routing über Kanten und Knoten ist etabliert und kann über “lane” als way problemlos erfolgen. Für eine detaillierte Karte kann man sich dann je nach Bedarf nur die Straßenfläche aus dem area oder zusätzlich die Spurinformationen mit Richtungspfeilen usw. aus den lanes holen.

Naja, ich bin da so heran gegangen: Flächenunterstützung ist aus meiner Sicht auf jeden Fall Pflicht, auch soll darüber geroutet werden können. Dann sollen ja unbedingt auch die Spuren auf der Fläche richtig abgebildet werden können, weil dafür machen wir die Veranstaltung hier ja. Wenn man das alles als Anforderung zur Grunde legt, gibt es für Flächen ja nur zwei Möglichkeiten:

Man sieht die Fahrbahn, wie in der Realität, als eine zusammenhängende Fläche an. Die Spuren müßten dann, in logischen Konsequenz, über das Einzeichenn von Linien bzw. Stützpunkten auf dieser Fläche repräsentiert werden. Was sicher auch irgendwie geht, aber was aus meiner Sicht den Auswerteaufwand, weil man ja gerade über die Spuren routen will, enorm nach oben treibt. Im Grunde müßte man in der vorverarbeitung die Fahrbahn dann wieder segmentieren und dann über die Segmente routen, also kann man es aus meiner Sicht auch gleich mit Teilflächen machen.
Man mappt die (Teil)Spuren und setzt daraus dann die Fahrbahn zusammen. Damit kann man dann auch die Übergänge impliziet definieren, was gegenüber der Gesamtfahrbahn ein Vorteil ist. Routing ist da dann auch problemlos möglich, da er jeweils zwiscchen den Linien bzw. Mittelpunkten der gemeinsamen Linien der Flächen, definiert durch die Übergangsrelationen erfolgt. Ja, das geht, schließlich kommt man ja nur über eine Übergangskante der Fläche überhaupt auf sie rauf. Dann klappert man einfach lokal alle Relationen auf den Übergangslinien ab und schon weiß der Router, wo er potenziell weiter hinfahren darf. Somit sind also die Flächen problemlos auf Kanten/Knoten für den Router abgebildet worden und damit auch an sich zu einer Linienabbildung selbst kompatibel. So, jetzt kommt aber der große Nachteil: Nein, es ist nicht der erhöhte Speicherbedarf, da die Festplattenkapazitäten ja schneller wachsen sollten, als wie alle Straßen mit Spuren gemappt haben, es ist der Aufwand bzw. das fehlerträchtige Gefummel für das Mappen selbst! Mal abgesehen davon, das durch die vielen Teilflächen und Übergangsrelatione,n man da um vernüftige Toolunterstützung leider nicht drum herum kommt, hat das Schema ja auch mindestens die Komplexität des Oxomoa-Schemas… Immerhin sollte sich, bei meinem leider noch nicht überarbeiten Schema, die Flächenumsetzung leicht automatisiert zu Liniendarstellung wandeln lassen, sowie die Liniendarstellung in eine vorläufige, vom Mapper noch zu zu bearbeitende, Flächendarstellung (flächige Aufweitung der Linien und Erzeugen von Recht-/Vielecken an den Knotenpunkten der Wege).

hurdygurdyman:

Ja, und ich hatte den Normalmapper im Auge, dessen Abstraktionsvermögen auch bei Nachbesserungen/Änderungen nicht überfordert werden soll.

Unübersichtliches Gefummel gibt es bei dir ja auch, da brauch ich mir ja nur mal die Kreuzungsflächen anzusehen, neben den ganzen Zusatztags für die Lanes selbst. Ob das trotz des bisherigen Verzichts auf Relationen, anfängertauglich ist, bezweifele ich stark, da ich es nach selbst nach nochmaligen kurzen Ansehen, zwar vom Ansatz, aber noch lange nicht im Detail verstanden, geschweige selbst getestet, habe.

Fabi2 · 2012-09-27T22:27:54.000Z

Tordanik:

Fabi2:

Soweit ich es gesehen habe, ging das mit erhöhtem Rechenaufwand mit dem Schemas durchaus, auch wenn da höhere höhere Abstraktionsstufen für Fahrbahnen und die Straße fehlen.

Wenn du keinen Algorithmus kennst, der mich davon überzeugt, sehe ich da keine verlässliche Methode.

Meine momentane Einschätzung:

Lose Spurways ohne irgendeine Verbindung → keine Chance

Lose Spurways “eingerahmt” von einer area:highway-Fläche, oder in einer Relation pro highway → machbar mit großem Rechenaufwand und sehr komplexer Programmierarbeit

Tag-basierende Lösung (:lanes) → verhältnismäßig einfach auswertbar, aber hat keine Lösung für komplizierte Kreuzungen und einige andere Details

Wie oben schon im Nachsatz andeutungsweise geschrieben, könnte es gehen, wenn mindestestens einer der Teilwege irgendwie mit dem restlichen Spurnetz verbunden ist und da dann eine Relation drauf ist, wo der unverbundenen Weg Mitglied ist. Das aber imho auch nur bei erhöhten Rechenaufwand, geht aber imho über entsprechendes Tagging (*:left/right=yes). Kennt jemand einen Fall eines Weges, welcher potentiell fürs Routing in Frage kommt und der in der Realität komplett unverbunden ist? Weil mir fällt da gerade echt nichts ein und der wäre mal eine interessanter Testfall. Ansonsten stimme ich da deiner Sicht zu den anderen Punkten voll zu.

Gedacht ist, zumindest bei mir, das *:left/right=yes/no-Tagging ja auch nur dafür um Sachen wie: “Man kann ja aber mit dem Fahrrad vom Radweg aus jederzeit über die Straße fahren…” abzubilden. Durch dieses Tagging weiß der Router dann nämlich da Bescheid!

Tordanik:

Eine Relation wäre machbar, aber ihre flächendeckende Verwendung in der Praxis sehe ich als unwahrscheinlich. Ich befürchte eher, dass Mapper das Konzept mit Spur-Ways dann einfach verwenden und (vergeblich) auf eine funktionierende Auswertung hoffen würden, weil es für den naiven Betrachter ja so aussieht, als sei alles erfasst.

Naja, nicht wenn man die alte Verkehrsbedeutungsklassifizierung in eine, bei mir, carriageway-Relation, und den Straßennamen und Sachen wie wikipedia=* dann in eine highway-Relation, bestehend aus carriageway-Relationen packt. Schließlich besteht die Straße ja, abstrakt, aus mehreren generischen Fahrbahnen (zusammenhängende Fläche von surface=*) und die Verkehrsbedeutung der Fahrbahn ist ja das, was eigentlich mit highway=primary/secondary/… gemeint ist. Und natürlich hat sie Straße den namen ja unabhängig davon, aus wie vielen Fahrbahnen, welcher Verkehrsbedeutung auch immer, sie sich zusammensetzt.

seawolff · 2012-09-27T23:55:59.000Z

Moin!

hurdygurdyman:

Zurück zum Thema:
ich habe meinen Vorschlag mal neu sortiert, damit auch Neueinsteiger in’s Thema mitkommen.

Die Definition der “lane”-Tags finde ich brauchbar, nur lane=signals ist als name nicht intuitiv verständlich.
Wie schon von anderen erwähnt, fehlen einfach auswertbare Angaben zu möglichen Spurwechseln.
Die “highway_junction”-Fläche als bloßes Hilfsobjekt für den Renderer passt m. E. nicht zum OSM-Konzept.
Eine Fläche, die bis zu den Haltelinien reicht und auch Rad- und Fußwege umfasst, entspricht eher dem intuitiven Verständnis einer Kreuzung. Damit lassen sich bessere Routinganweisungen generieren und auch Fußwegquerungen der Kreuzung zuordnen.

Dort findet ihr auch die links zu einer osm- und einer xml-Datei sowie zu zwei aerowest-Bildern, womit ihr den Ansatz auf seine Alltagstauglichkeit abklopfen könnt.

Warum lädst du die Daten nicht in die Hauptdatenbank? Es sollten sich doch keine Konflikte zu bestehenden Tags ergeben.
Ich hatte auch einmal mit Einzelspurmapping experimentiert [1]. Die dabei erstellt Kreuzung [2] ist noch unverändert und hat niemanden gestört.

Viele Grüße
Stephan

[1] http://lists.openstreetmap.org/pipermail/talk-de/2012-January/092178.html
[2] http://osm.org/go/0HsPVeHXn-

hurdygurdyman · 2012-09-28T07:12:35.000Z

seawolff:

Die Definition der “lane”-Tags finde ich brauchbar, nur lane=signals ist als name nicht intuitiv verständlich.

ok, was hältst du von lane=control_signs? Suchmaschinen spucken das aus.

Wie schon von anderen erwähnt, fehlen einfach auswertbare Angaben zu möglichen Spurwechseln.

Nö, Spurwechsel ist möglich, solange lane_changing=no/no_right/no_left nicht gestetzt ist. Sollte ich vielleicht deutlicher machen

Die “highway_junction”-Fläche als bloßes Hilfsobjekt für den Renderer passt m. E. nicht zum OSM-Konzept.
Eine Fläche, die bis zu den Haltelinien reicht und auch Rad- und Fußwege umfasst, entspricht eher dem intuitiven Verständnis einer Kreuzung. Damit lassen sich bessere Routinganweisungen generieren und auch Fußwegquerungen der Kreuzung zuordnen.

Stimmt, Hilfsflächen waren mein erster Ansatz. Die Zeichnungen in der grafischen Erläuterung stammen daher. Wenn wir die Straßenflächen sowieso erfassen wollen, macht dein Vorschlag Sinn. Dann wäre “highway_junction” unabhängig auch vom lane-tagging der Verbindungsbereich mehrerer highways.

Warum lädst du die Daten nicht in die Hauptdatenbank? Es sollten sich doch keine Konflikte zu bestehenden Tags ergeben…

Leider ist das Testgebiet http://www.openstreetmap.org/?lat=47.99061&lon=7.84464&zoom=18&layers=M durch den exzessiven Gebrauch von highway zur Spurdarstellung derart unübersichtlich, dass “meine” lanes dort das totale Chaos anrichten würden. Außerdem halte ich nichts davon, die Datenbank mit derartigen Gedankenspielen zu belasten.

hurdygurdyman · 2012-09-28T09:29:06.000Z

Fabi2:

Bild doch erst mal die Fahrbahnen ab, bevor du die ganze Straße zusammen bastelst, weil bei ner zusätzlichen carriageway-Relation wäre das ganze dann wenigstens von der Realtionstypen kompatibel zu meiner Idee.

Da räumlich getrennte Fahrbahnen schon jetzt als highway=* erfasst werden, ist ein zusätzliches carriageway auch als Relation wohl überflüssig und irritierend.

Jetzt gerade habe ich auch gesehen, das man aus meiner Sicht lane_restriction nicht braucht, da man ja bei dir eh nur an der Kreuzung immer dahin fahren darf, wo auch ein verbundener Weg hinführt.

Das sehe ich anders, denn lane_restriction bildet die Verkehrszeichen bzw. die Richtungspfeile auf den Spuren ab, die Renderer dann auf die Straßen zeichnen und router für die Abbiegeanweisungen auch vorausschauend verwenden können, ohne dass dies aus den Winkeln der Spuren am nächsten Knoten erraten werden muss.

Naja, ich bin da so heran gegangen: Flächenunterstützung ist aus meiner Sicht auf jeden Fall Pflicht, auch soll darüber geroutet werden können. Dann sollen ja unbedingt auch die Spuren auf der Fläche richtig abgebildet werden können, weil dafür machen wir die Veranstaltung hier ja. Wenn man das alles als Anforderung zur Grunde legt, gibt es für Flächen ja nur zwei Möglichkeiten:…

Ich kann doch den routern nichts als Pflicht diktieren. Ich kenne keine Methode, die routing über Flächen ermöglicht. Kanten und Knoten sind etabliert und die Spurerfassung als gerichteter Graph und die deren Auswertung ist bewährt und erfordert weniger Erfassungsaufwand, Speicher und Preprocessing.

hurdygurdyman:

Ja, und ich hatte den Normalmapper im Auge, dessen Abstraktionsvermögen auch bei Nachbesserungen/Änderungen nicht überfordert werden soll.

Unübersichtliches Gefummel gibt es bei dir ja auch, da brauch ich mir ja nur mal die Kreuzungsflächen anzusehen, neben den ganzen Zusatztags für die Lanes selbst. Ob das trotz des bisherigen Verzichts auf Relationen, anfängertauglich ist, bezweifele ich stark, da ich es nach selbst nach nochmaligen kurzen Ansehen, zwar vom Ansatz, aber noch lange nicht im Detail verstanden, geschweige selbst getestet, habe.

Hier im Forum wurde von mir eine praktische Umsetzung an einem komplexen Beispiel gefordert. Dies habe ich mit dem Testgebiet in Freiburg geliefert. Zum Grundverständnis ist das aber nicht geeignet. Dazu dient http://ubuntuone.com/6HPgoCItJy0WtwKrKpU3H2.
Ich ging so vor:
Beginne an einer einmündenden Spur, verbinde diese mit allen von dieser aus erlaubten abgehenden Spuren und mache das im Uhrzeigersinn mit den nächsten einmündenden Spuren, bis du einmal um die Kreuzungsfläche herum bist.

Fabi2 · 2012-09-28T19:45:22.000Z

hurdygurdyman:

Fabi2:

Bild doch erst mal die Fahrbahnen ab, bevor du die ganze Straße zusammen bastelst, weil bei ner zusätzlichen carriageway-Relation wäre das ganze dann wenigstens von der Realtionstypen kompatibel zu meiner Idee.

Da räumlich getrennte Fahrbahnen schon jetzt als highway=* erfasst werden, ist ein zusätzliches carriageway auch als Relation wohl überflüssig und irritierend.

Ich denke da nur an die ganzen Befürworter von Sachen wie cycleway/sidewalk=letf/right/both, weil die sehen highway=* bestimmt nicht nur als Ersatz für die Fahrbahn an, weil sonst würden sie ja die Fuß-/Radwege getrennt mappen. In der Praxis ist highway=* mehr als schwammig definiert und ist irgendwie inzwischen quasi Alles zwischen Fahrbahn, Fahrspur, Straße und z.B. Fahrstuhl. Ich denke eher schon noch an eine zusätzliche Relation für die Fahrspur, wenn sie als Fläche gemappt wurde, weil dann ist die Zugehörigkeit der Teilflächen zu den einzelnen Spuren ja nicht mehr unbedingt eindeutig…

hurdygurdyman:

Jetzt gerade habe ich auch gesehen, das man aus meiner Sicht lane_restriction nicht braucht, da man ja bei dir eh nur an der Kreuzung immer dahin fahren darf, wo auch ein verbundener Weg hinführt.

Das sehe ich anders, denn lane_restriction bildet die Verkehrszeichen bzw. die Richtungspfeile auf den Spuren ab, die Renderer dann auf die Straßen zeichnen und router für die Abbiegeanweisungen auch vorausschauend verwenden können, ohne dass dies aus den Winkeln der Spuren am nächsten Knoten erraten werden muss.

Ich würde/habe das Problem von Verkehrszeichen und Richtungspfeilen, wenn es sich denn nicht immer per Algorithmus lösen läßt, als weitere Relation (z.B. type=street_marking) auf den jeweiligen Spuren definieren. Ich hatte das ja schon mal beschrieben und inzwischen gibt es eine testweise Umsetzung:
http://www.openstreetmap.org/browse/node/1925906781 und http://www.openstreetmap.org/browse/node/1925906794 als zu ergänzende (weitere Tags für die Realtion) Teillösung für meine simple Testkreuzung http://wiki.openstreetmap.org/wiki/File:Kreuzung.JPG. Das ist im Unterschied zu deiner Teillösung dann wenigstens universell.

hurdygurdyman:

Naja, ich bin da so heran gegangen: Flächenunterstützung ist aus meiner Sicht auf jeden Fall Pflicht, auch soll darüber geroutet werden können. Dann sollen ja unbedingt auch die Spuren auf der Fläche richtig abgebildet werden können, weil dafür machen wir die Veranstaltung hier ja. Wenn man das alles als Anforderung zur Grunde legt, gibt es für Flächen ja nur zwei Möglichkeiten:…

Ich kann doch den routern nichts als Pflicht diktieren. Ich kenne keine Methode, die routing über Flächen ermöglicht. Kanten und Knoten sind etabliert und die Spurerfassung als gerichteter Graph und die deren Auswertung ist bewährt und erfordert weniger Erfassungsaufwand, Speicher und Preprocessing.

Das war ja auch nur meine Anforderungsliste an ein Erfassungsschema, welche ich für mich zusammengetragen hatte. Flächenrouting ist sehr wohl möglich! Lösung siehe oben. Das die Erfassung dann aber alles andere als feierlich ist, hatte ich da ja auch schon geschreiben, aber das Schema löst zumindest erst mal recht universell die Spurmappingprobleme, die ich bisher so überlegen konnte, funktioniert für (hoffentlich) Flächen (für Flächen ist es noch nicht ganz zu Ende überprüft) und Linien und läßt sich dazwischen ohne große Probleme auch gemischt benutzen. Die Grundsätze sind soweit klar, die Feinheiten werden aber sicher noch Arbeit machen. Das sind solche Sachen wie z.B. das man natürlich die Übergansrelationen auch für das Linienschmea benutzen könnte, und zum Teil sogar muß, so das die Idee mit den 4-Richtungen da eher eine Vereinfachung war (die ist noch aus der Ueit wo das ganze ein reines Linienschema war…), aber wohlmöglich ist die nicht haltbar und man braucht die Übergansrelationen immer.

hurdygurdyman:

Fabi2:

Unübersichtliches Gefummel gibt es bei dir ja auch, da brauch ich mir ja nur mal die Kreuzungsflächen anzusehen, neben den ganzen Zusatztags für die Lanes selbst. Ob das trotz des bisherigen Verzichts auf Relationen, anfängertauglich ist, bezweifele ich stark, da ich es nach selbst nach nochmaligen kurzen Ansehen, zwar vom Ansatz, aber noch lange nicht im Detail verstanden, geschweige selbst getestet, habe.

Hier im Forum wurde von mir eine praktische Umsetzung an einem komplexen Beispiel gefordert. Dies habe ich mit dem Testgebiet in Freiburg geliefert. Zum Grundverständnis ist das aber nicht geeignet. Dazu dient http://ubuntuone.com/6HPgoCItJy0WtwKrKpU3H2.
Ich ging so vor:
Beginne an einer einmündenden Spur, verbinde diese mit allen von dieser aus erlaubten abgehenden Spuren und mache das im Uhrzeigersinn mit den nächsten einmündenden Spuren, bis du einmal um die Kreuzungsfläche herum bist.

Es seh es mir vielleicht noch mal genauer an, auch wenn es vielleciht sinnvoller ist, mein Schema stattdessen zu optimieren, was ja überhaupt ja nur existiert, weil ich einen Vorschlag brauchte, um zu belegen, warum mir die anderen Schemata nicht so zusagen bzw. wie man es aus meiner Sicht noch besser machen könnte… Sicher sind viele Lösungen auch und dadurch übersichtlicher, aber sie sind dafür meist nicht unversell oder teilweise schlecht auszuwerten.