Routing / Spurmapping

Gerade die zwei für mich recht wichtigen Punkte (die du erwähnst) fehlen mir bei der Abstimmung. :frowning:

Stimmt, aber richtig interessant wird die Ecke, wenn man die Breitenfurter Straße, die Edelsinnstraße und die Wienerbergbrücke mit den vier Kreuzungen betrachtet:
http://www.openstreetmap.org/?lat=48.17322&lon=16.32811&zoom=18&layers=M
da haben wir dann noch das Linienbündel/Brücken-Problem inklusive “Bim-Schienen” (Hochdeutsch: Straßenbahngleise), wobei die Spuren wegen der Brücken noch geteilt werden müssten. Hier:
http://forum.openstreetmap.org/viewtopic.php?id=15547
sind wir wie in den anderen Diskussionen zu Brücken ja nicht wirklich voran gekommen.
Streng genommen müsste “für die Renderer” jede lane=* noch bridge=yes und layer=1 bekommen und schon wird Wien zur 1000-Brücken-Stadt.
Ich sehe da eigentlich nur eine vernünftige Chance, wenn wir endlich mit Relationen für Linienbündel (type=collection oder sowas) arbeiten, auf die dann die Brücken/Tunnel-tags gelegt werden. Mit der area-Lösung klapt’s ja nicht beim rendern http://www.openstreetmap.org/?lat=48.176116&lon=11.548087&zoom=18&layers=M

Trotzdem reizt mich diese Wiener Ecke, um meinen lane-mapping-Vorschlag mal mit JOSM an einer Datenkopie zu testen.
Freiburg muss dann warten.
Edit:
Oder bleibe ich doch vor der Haustür :confused:
http://maps.google.de/maps?q=Freiburg&hl=de&ie=UTF8&ll=47.990496,7.845032&spn=0.00298,0.004823&sll=51.151786,10.415039&sspn=22.955269,39.506836&hnear=Freiburg,+Baden-W%C3%BCrttemberg&t=h&z=18
http://maps.google.de/maps?q=Freiburg&hl=de&ie=UTF8&ll=47.990496,7.854635&spn=0.00298,0.004823&sll=51.151786,10.415039&sspn=22.955269,39.506836&hnear=Freiburg,+Baden-W%C3%BCrttemberg&t=h&z=18

Garmin macht nen großen Bogen um spurgemappte Kreuzungen: :wink:

Wer Langeweile hat kann ja mal den Fehler suchen. Hier der Link:
http://www.openstreetmap.org/?lat=51.69959&lon=7.12985&zoom=16

Chris

Moin

Falscher oneway :slight_smile: Waren also nicht die Spuren :wink:
http://www.openstreetmap.org/browse/way/132071715
habs noch drin gelassen.

Ich habe der Kreuzung mal eine Runde turn restrictions spendiert. Den falschen oneway habe ich als Anschauungsobjekt aber mal stehen lassen …

Schön, dh. statt die Kreuzung zu verbessern wird sie weiter verkompliziert. :slight_smile:

Edit: Fehler ist korrigiert.

Drei “no_u_turn”, von denen eigentlich nur der südwestliche gerechtfertigt ist, weil da die durchgezogene Linie die gegenläufigen Spuren trennt. Die beiden anderen sind unnötig, denn Wenden ist dort möglich (wenn es der Verkehr zulässt).

Das muss sich doch nicht widersprechen :wink:

Bei genauer Betrachtung der bing-Fotos, sind die drei “only_straight_on” mitten auf der Abzweigung auch unnötig. Ich sehe nichts, weshalb ich da nicht auch wenden dürfte, wenn ich entsprechend risikobereit bin. Und durch die oneway schließen sich alle weiteren Möglichkeiten aus.

Edit:
gerade als Anleitung gefunden:
http://trolug.de/lib/exe/fetch.php?media=vortrag:abbiegen_trolug.pdf

Du übersiehst vielleicht, dass hier Spuren als Wege gemappt wurden. Egal, ob man vom Norden kommend links oder rechts abbiegen will, man befindet sich auf ein und derselben Straße. Natürlich kannst du dich links einordnen und im letzten Moment umentscheiden und dann doch rechts abbiegen. Aber von den Daten muss klar sein: Eine Linksabbiegespur geht nach links, oder man kann sie gleich weglassen. Die Abbiegespuren trennt auf den letzten Metern jedenfalls noch eine durchgezogene Linie und die Fahrspuren sind mit Richtungspfeilen versehen, so dass das auch in RL klar ist. Logisch, du kannst das im Auto einfach ignorieren, wenn kein anderes Fahrzeug neben dir steht … wer macht das nicht ab und zu.

Die no-u-turns sind gerechtfertigt, weil nach Zusammenführung der Spuren zuerst noch eine durchgezogene Linie vorhanden ist, bis sie später in eine gestrichelte übergeht. Wer unbedingt mitten auf der Straße wenden will, kann das ja 5m später machen, so wie es sonst überall mitten auf “normalen” Straßen erlaubt und (oft) auch möglich ist :wink: Der Cloudmade-Router arbeitet je nach Einstellung z.B. so, um Abbiegebeschränkungen zu umgehen: http://maps.cloudmade.com/?lat=54.674054&lng=9.699104&zoom=16&directions=54.67491040205561,9.699833393096924,54.674575407708446,9.70116376876831&travel=car

Für das Routing, eine der wichtigen Anwendungen der OSM-Daten (eine, nicht unbedingt die alleinseligmachende, um Missverständnisse zu vermeiden g) sind turn restrictions grundlegend. Sonst lässt dich ein Navigationssystem an jeder beliebigen derartig gemappten Kreuzung mitten drin wenden, statt dich in einem Bogen herumzuführen, falls du dich mal verfahren hast. Und das Navi meint es nicht mal böse, sondern sieht nur kreuzende Ways, die (mangels turn restriction) beliebig genutzt werden können. Da hilft es auch nicht, im Navi das Wenden auszuschalten, denn laut Daten wird ja nur abgebogen, nicht gewendet. Grob vereinfacht gesagt: Lässt man die turn restrictions weg bzw hält man sie für unnötig, kann man auch gleich die Spuren weglassen und die ganze Kreuzung wieder auf die Form “2 ways, T-förmig aufeinandertreffend” zurückführen.

+10, dann wäre die Kreuzung wieder im KISS-Prinzip[1]. :slight_smile:

Chris

[1] Keep It Simpel, ihr lieben Spurmapper

Naja, der richtige Spurmapper würde die Kreuzung wahrscheinlich auch auf die T-Kreuzung reduzieren und den Rest mit Wegen mit lane-Tag machen. Leider ist das noch nicht standardisiert und deshalb kommt’s halt zu sowas.

Das geht sogar noch, was schwieriger ist, und was Leute hier ja schon mit abbilden wollten, ist es, wenn die Straßenbahn teilweise die Spuren mitbenutzt. Da kommt man um das Erfassen aller Spuren als Flächen nicht mehr herum, denn wie will man sonst genau releativ zu einer Linie angeben, wo jetzt die Straßenbahn gleise liegen?

Das Spurproblem ist, zumindest theoretisch, gar nicht so kompliziert:
Da sind zuerst die, noch zu mappenden, Pflastersteine, die bilden dann die Spur als logisches Gebiklde. Mehrere Spuren sind die Fahrbahn, was, soweit ich weiß, die urspründliche Bedeutung von highway=* ist. Zuletzt kommt dann evtl. noch die Straße als abstraktes Gebilde aus Fahrbahnen, Fuß- und Radwegen, Lampen, etc. Was mas man in dieser Struktur nicht aus liegt_in ermitteln kann, muß man mit Relationen abbilden.

Das Problem ist, das highway=* urspünglich als Fahrbahn definiert wurde und das auch bleiben sollte, und man damit wirklich nur echt baulich abgetrennte Fahrbahnen mappen sollte. Für Spuren sollte man zumindest Wege oder besser gleich Flächen (das wäre besser für die spätere Erfassung der Plastersteine und Staßenbahngleise) nehmen. Damit man nicht noch mehr schreit wegen dem Routing das ja dann über Flächen funktionieren müsste, nimmt man vielleicht doch erst mal Wege und akzeptiert, das man die genaue Lage der Straßenbahngleise dann nicht erfassen kann, aber dann muß man später alles umständlich ändern und umtaggen, wenn man das doch Erfassen will, was ja absehbar, nur eine Frage der Zeit und an sich auch gut und möglich sein sollte.

Wenn man als Kompromiß daraus erst mal die Spuren als Wege und weitere zusätzliche Detailstufe unterhalb der, dann durch eine Relation dargestellten Fahrbahn (wo zusätzlich noch der Weg des alten highway=* aus Rückwärtskompatibilitätsgründen mit drin ist), mit rein nimmt, dann braucht man natürlich die zusätzlichen Sachen, die auf der alten fahrbahnebene die Deatils der spuren darstellen sollten, wie z.B. Abbiegebeschränkungen, nicht mehr.

Im Grunde ist das, was jetzt ja schon mit dem highway=* + oneway=yes mapping gemacht wird, genau der Ansatz den ich erweitert, eben um alle vier (Fahr)richtungen pro Verkehrsteilnehmer, hier schon als Vorschlag gepostet habe. Nur das es schlecht ist, dafür highway=* Zweckzuentfremden und man da besser eben lane=yes + vehicle:forward=yes macht, was dem alten highway=* + oneway=yes entsprciht.

Nein, der richtige Spurmapper mappt jede lane einzeln und macht dann ein Relation für die Fahrbahn drauf.

Das geht auch ohne Flächen und wird auch bei highway praktiziert, indem der way highway=* und railway=tram erhält. Sobald die Straßenbahngleise auf der “Fläche” einer Spur liegen geht das mit lane genauso.

highway bedeutet Straße http://www.dict.cc/?s=highway
Fahrbahn wäre carriageway http://www.dict.cc/englisch-deutsch/carriageway.html

Da eine Spur in der Regel nur in einer Richtung nutzbar ist, kann man oneway inpliziert setzen und spart das “vehicle:forward”.

Carriageway ist meines Wissens britisch und damit der Tag kurz gehalten wird, würde ich das (auch für Fahrbahnen richtige) lane bevorzugen, da es pro Fahrbahn 7 Zeichen weniger wären und bei der Summe an Fahrbahnen die früher oder später zu erwarten wären, das eine ordentlich Menge an Speicher fressen würde.

Eine Fahrbahn besteht aus 1 bis x lanes, das ist also exta, die lane ist die logische (nur durch Markierungen getrennt) oder pysikalische (wirkliche Trennung wie z.b. der Bordstein) Fahrspur für alle denkbaren Verkehrsteilnehmer wie Fußgänger, Fahrräder, Autos, etc. Für die Fahrbahn würde ich dann 'ne type=carriageway Relation erstellen, die auch bei getrennten Fuß-/Radwegen benutzt werden könnte, denn das ist die gleiche Abstraktionstufe.

EDIT: Ja, carriageway ist laut OALD britisch und steht für Fahrbahn im Sinne von Teil der Straße der für die Autos gedacht ist und für das Gesamtgebilde aus mehreren Spuren wie die Richtungsfahrbahnen bei Autobahnen.

Was ich meine ist der, von viv im Posting #203, aufgezeigte Fall, das läßt sich nicht ohne Flachenmapping lösen. Weil da ist die relative Lage auf der Spur und die Anzahl an Straßenbahngleisen nämlich mehr als interessant. Aus sicht der Zunkuftsfähigkeit müßte man da also alles als Flächen eintragen, weil wir sind ja keine reiner Autoroutinganbieter, die es da einfacher haben und mit so einem Linienmodell arbeiten können, da bei denen die Straßenbahn und deren Auswirkungen auf die Gesamtstraße nicht vor kommt. Das ist also bestenfalls eine Übergangslöung, wobei man es vielleicht besser gleich richtig machen sollte.

Ich meinte da die Bedutung nach OSM-Wiki, aber da ist das nicht genauer definiert als “Haupttag für Straßen und Wege aller Art” wobei da außer der Bedeutung von Spur, Fahrbahn und Straße dann auch noch Sachen wie z.B. highway=elevator und das alte highway=bus_stop wären.

Implizites setzen von Tags ist nicht sinnvoll und macht das allgemeine Konzept nur unötig kompiziert, besser ist es da Shortcuts für alle üblichen Fälle (Fahrspur, Fahrspur am Rad, Fußweg, Radweg, etc.) zu machen.

Hatte ich falsch verstanden…
Da könnte man ja auf das “klassische” Street oder Road zurückgreifen, ist ja beides glaube ich ja noch nicht genutzt.

Selbst wenn…
Ein Tagging-Schema sollte nicht scheitern müssen, wenns dann doch mal vorkommt.

sorry,gut 2 Seiten Diskussion übersehen… :expressionless: