@viw:
Schön, dass du mit meinen Grundgedanken jetzt leben kannst
Ich bin mir nicht sicher, ob wir Übergangslösungen brauchen, da highway=* ja erstmal bleibt. Wenn lane=* oder die relation=highway vorhanden ist, kann der Renderer/Router je nach Willen und Können ja darauf zurückgreifen. Gibts die nicht, muss er die highway-infos nehmen.
@Netzwolf:
Die relation=highway muss also kommen, wenn highway=* an entsprechender Stelle komplett durch lane=* und relation=highway ersetzt werden kann?
@de_muur:
Ich denke über das Graphen/Knoten/Kanten-Problem nach Macht aber vielleicht erst Sinn, wenn das tagging-Schema ansatzweise steht. Da muss ich mich aber noch etwas schlauer machen. Hat jemand einen Vorschlag, wie das ohne weitere relation zu lösen ist? Ich möchte eigentlich mit Relationen so sparsam wie möglich umgehen.
Ich unterscheide jetzt im Interesse einer Lösung mal für routing und rendering:
Für routing beziehungsweise die Ansage besteht die Lösung darin, dass ja am Beginn der entsprechenden Spur ein gemeinsamer Knoten mit mindestens einer Nachbarspur besteht. Somit kann sich der router ja den hier befindlichen frühesten Punkt zum Spurwechsel wählen und auch entsprechend ansagen/anzeigen.
lane-changing wäre somit eher für den Renderer, um optisch die “durchgezogene Linie” oder “gestrichelte Linie” auf der entsprechenden Seite abzubilden. Sollte die gestrichelte irgendwann zur durchgezogenen Linie werden, müsste man den lane dort auftrennen und den tag fur den folgenden Rest setzen.
Nein, denn das funktioniert nur, wenn zusaetzlich eine Abbiegespur hinzu kommt. wenn aber eine Strasse ueber eine Kreuzung hinweg mehrspurig ist, dann klappt das nicht mehr.
Desweiteren kommt dabei Murks raus, wenn man ausserhalb einer Kreuzung auf die andere Strassenseite will.
Ausserdem ist einige Seiten weiter vorne ausgiebig dargelegt worden, dass durch die mehrfachen Wege die Kreuzungstopologien fuer die automatische Auswertung nicht mehr verstaendlich sind. So kann ein Router zwar noch eine optimale Strecke finden, er kann aber kaum noch brauchbare Abbiegeanweisungen erzeugen.
=> Mit dem Ansatz verrennst du dich in eine Sackgasse. Dass kann mir im Prinzip egal sein, es ist ja deine Zeit, die dabei rauf geht. Das Problem ist nur, dass andere dir in die Sackgasse folgen moegen, und OSM ist nun mal herdengetrieben.
Hast du alles richtig gelesen? Die bisherige Strucktur highway=* bleibt erhalten. Dein schlaues navi erzeugt also wie bisher die Abbiegehinweise aus den Grundtopologien und kann bei Bedarf die Spuren anzeigen und wenn die dann eine direction haben sagt er dir dann sogar ordnen sie sich in der Spur geradeaus nach Berlin ein. Das findest du bei den heutigen Daten sicher noch nicht.
Flächenmehrfachnutzung (korrekte Abbildung des Straßenbahn auf der Straße) geht soweit ich das übersehen kann, nur wenn man die Spuren/Objekte als Fläche mappt.
Ansonsten kann man in etwa so etwas als Spumodell nehmen:
ein Way mit:
x-Stück dieser Segmente sind dann der highway=* als Relation mit zugehörigem name=*.
Wenn sich die Eigenschaften ändern, muß man ein neues highway-Segment einzeichnen.
Das erst mal nur so als Idee zur Vereinfachung des Problems, sonst muß man mit Flächen operieren, wenn man das Straßenbahnproblem auch noch gelöst haben möcht, ist aber dann entsprechend aufwendig zu mappen, da mkann man dann nicht mal so eben nur 'ne Linie malen.
Für mich läuft das auch unter Gehirn-Jogging, was ja für einen mittlerweile fast 57-jährigen wie mich durchaus empfehlenswert sein soll und somit eine sinnvolle Zeitverschwendung darstellt
Selbst wenn nichts dabei rauskommt, ist es gut, dass wir darüber gesprochen haben. Ich habe mir dann aber erspart, im stillen Kämmerlein mühsam ein englisches proposal zu basteln, das dann keiner beachtet oder das heillos zerrissen wird.
Ich halte den Weg für sinnvoller, hier im Vertrauen auf die „german croud intelligence" gemeinsam mit euch erst einmal eine mögliche Lösung zu entwickeln, woraus dann ein proposal entstehen kann. Leider ist talk-de (noch) nicht mein Ding. Da sind wohl eher die Techniker unterwegs, deren Meinung zu diesem Thema auch interessant wäre. Da muss ich dann wohl noch ran
Solange es noch kein unausgegorenes proposal gibt, das manche Mapper dann auch noch umsetzen, sehe ich die Gefahr, dass man mir in eine Sackgasse folgt, noch nicht.
Das muss durch das tagging-Schema verhindert werden. Über Relationen wäre da wohl eine Lösung möglich, aber die sind ja nicht unbedingt erwünscht und ich will sie auch möglichst vermeiden. Ich denke darüber nach.
Da können doch die router eine Logik entwickeln die ungefähr so aussieht, dass bei mehreren Spuren mit derselben Richtung über die Kreuzung hinaus z.B. immer die rechte Spur bei Rechtsverkehr verwendet wird, was ja in Deutschland auch den geltenden Regeln entspricht. Für vorausschauendes routing wäre eine Regel im router denkbar, die z.B. für ein Abbiegen an der dann folgenden Kreuzung oder Abzweigung eine Spurempfehlung wählt, die ohne oder mit möglichst wenig Spurwechseln bis dorthin auskommt.
Da verstehe ich leider nicht, wie du das im Zusammenhang mit dem Vorschlag meinst
Aber ich verschwende meine Zeit, indem ich dir antworte. Selbst schuld.
Du hattest als Ansatz vorgeschlagen, dass es furs Routing reichen wuerde, wenn nur an den Verbindungspunkten zwischen den Spuren gewechselt wird. Und das funktioniert halt nicht, wenn man auf den anderen Strassenseite ein Ziel ansteuern will, bei dem es gerade halt keinen Verbindungspunkt zwischen den Spuren gibt. Dein Routing wird dich dann immer bis zur naechsten Kreuzung schicken und dort wenden lassen. Und wenn dort das Wenden seiner Meinung nach nicht geht, dann kommen da sehr interessante Umwege bei raus. Aber auch das ist schon weiter oben in dieser Diskussion hinreichend aufgezeigt worden.
Diese Aussage ist ja nun schon besser beschrieben wo dein Problem ist. Machen wir das anders.
Das Konzept ist zweigleisig. Zum einen gibt es die Grundstruktur so wie heute mit highway=*
Damit kann der Router auch weiterhin seine Routen berechnen und dort gibt es keine Probleme mit der Straßenseite. Und dann gibt es für Details Spuren. Diese kann der Router bei Bedarf grafisch auswerten(Spurassitent anzeigen) oder wenn Lust und Zeit hat sogar über mehrere Kreuzung hinweg die günstigste Spur berechnen.
Das Problem ist, dass man mit Tags den Spurverlauf nicht richtig darstellen kann und es würde zu riesigen Tagmonstern führen. Außerdem gibt es schon heute eine gewisse Anzahl von Mappern, welche die Spuren zeichnet und mit den altbewährten Tags (highway=*) das Routing zerstört.
Danke für die Zeit, die du diesem Thema und mir opferst. Ich unterstelle jetzt einfach mal, dass diese deine Zeit auch einem gewissen Interesse am Thema geschuldet ist.
Dann geht es bei dem Problem wohl primär um’s Routing für Fußgänger und Radfahrer, die ja je nach Belieben und Risikobereitschaft überall kreuzen könnten. Dafür gibt es soweit ich weiß auch im etablierten tagging keine Lösung. Ich kann mir momentan auch keine vorstellen, solange der “Zwang” zum routing über Knoten und Kanten besteht. Ich erinnere mich da an einen ergebnislosen thread im Zusammenhang mit dem Kreuzen von flächigen Fußgängerzonen irgendwann im letzten Jahr. Und wegen dieser Problematik schrieb ich in meine “Grundsätze”: Im ersten Schritt liegt der Fokus auf der Spurführung für motorisierten Verkehr. Cycleway und footway bleiben hier vorerst noch unberücksichtigt.
Momentan kann ich mir auch nicht vorstellen, dass irgendein Router bereit ist, derartige Empfehlungen zum beliebigen Überqueren einer Straße abzugeben. Wir reden hier ja nicht von irgendwelchen zweispurigen Straßen mit geringem Verkehrsaufkommen. Mehrere Spuren und Abbiegespuren sind eher an Verkehrsadern mit manchmal auch von der Tageszeit abhängigem erhöhtem Aufkommen zu finden, wo die Möglichkeit zum und die Gefahr beim Kreuzen nicht kalkulierbar ist. Die Benutzung eines Routers, bedeutet ja nicht, dass man dabei den gesunden Menschenverstand ausschalten darf. Jeder mir bekannte Router spuckt nach dem Einschalten einen entsprechenden Warnhinweis aus, um der Gefahr einer Haftungsklage zu entgehen.
Nein, wie kommst du jetzt darauf? Die letzten Aeusserungen von mir bezogen sich rein auf den KFZ-Verkehr. Auch hier kann beim Routing aus den bereits dargelegten Gruenden nicht auf den freien Wechsel von einer Spur zur anderen verzichtet werden.
(Um die Aussage zu praezisieren: Natuerlich kann man auch ein Routing auf Basis deines Vorschlages realissieren. Nur waere das kein Fortschritt gegenueber dem bisherigen Stand sondern schafft nur neue Probleme.)
Welche Probleme schafft das Modell? Der Vorteil ist das jeder der möchte mit lane=* jetzt detail informationen finden kann, welche vorher nicht da waren. Und wo siehst du den Nachteil?
heißt für mich, dass auch die Gegenfahrbahn als Bestandteil der Straße gekreuzt werden soll, was bei Straßen, von denen wir hier reden, in der Regel nicht möglich ist.
Aber auch für den von dir gemeinten Fall kenne ich keine etablierte Lösung mit OSM-Daten.
Ich rede hier von einer ganz normalen Strasse mit in jeder Richtung eine Fahrspur. Wenn du entsprechend deines Vorschlages die eine Spur als highway erfasst (welche von beiden auch immer) und die andere Spur als lane erfasst, dann kommst du auf die andere Strassenseite nur, indem du bis zum naechsten Verbindungsknoten zwischen den beiden Spuren faehrst und dort wendest => absoluter Murks. In Wirklicheit wirst du einfach auf der Fahrspur in deiner Richtung bis zum Erreichen des Zieles fahren und dort die Gegenfahrbahn queren.
Statt mit der Gegenfahrbahn greift die Argumentation auch genauso, wenn zwei Fahrspuren in die selbe Richtung verlaufen.
Ich praesentiere hier nicht irgendwelche ausgefuchsten Sonderfaelle, die Probleme deines Ansatzes (wie kann der Router zwischen getrennt erfassten Spuren wechseln) werden auch in den einfachsten Beispielen ersichtlich. Falls du es noch nicht gemacht hast, dann liess dir noch mal von Anfang an diese Diskussion hier durch. Wenn du dann immer noch nicht die Probleme verstehst, dann kann ich auch nicht weiter helfen.
In deinem Beispiel würde ein highway=* in der Mitte laufen und rechts und links davon je Richtung ein lane=* Der Route kann ganz normal rechts oder links von dem highway runtergehen.
Lediglich neuere Router können sehen, dass hier zwei Fahrspuren sind. Allen anderen bleibt das neue Modell eh verborgen und die machen das so wie bisher.
Wenn also jetzt neue Router entstehen dann müssen die entsprechend lernen, dass alle lanes der Straße beliebig austauschbar sind, so lange das nicht durch Tags verboten wird. Diese Tags sind dann an den jeweiligen lanes zu finden.
Welche Lane ist mit welcher austauschbar??? Der Router hat Millionen von lanes in seiner Datenbank. Solange du da nicht spezielle Relationen fuer spendierst, kann eine automatische Auswertung damit ueberhaupt nichts anfangen.
Fuer dich als Mensch ist es auf den ersten Blick erkennbar, dass der highway und die direkt daneben paralellel verlaufenden lanes zusammengehoeren. Aber probiere mal, dieses Erkennen einem Computer beizubringen. Genau mit solchen Sachen, die fuer uns Menschen trivial erscheinen, haben Computer die groessten Schwierigkeiten. Und entsprechend unsinnig ist ein Taggingschema, dass genau solche Faehigkeiten voraussetzt.
Ist mir ja neu, das der Router sich nicht, die Infos von allen Spuren, die ihn interessieren, mit als Metrik an eine Linie/Kante hängen könnte.
Man sollte eben nicht versuchen, alles als eine Linie darstellen zu wollen, die “Straße” als abstakte Ansammlung von verschiedenen Spuren, besteht nun mal aus min. einer Spur, auf der, an der jeweiligen Stelle in der Realität, unterschiedliche Verkehrsteilnnehmer entweder in einer der vier möglichen Richtungen fahren dürfen oder eben nicht. Damit kann man in Bezug aufs Spurrouting alles abbilden, was keine relative Lageinformation in Bezug auf die Fläche der Spur beinhaltet. Reicht also locker für ein Model die bei den komerziellen Autoroutern. Gut, wäre aber eine Erweiterung des Schemas für Flächendarstellungen zu haben, weil wie ja eben auch den ÖPNV haben. Es reicht aber, entweder die Straße als highway=* zu mappen, oder statt dessen alle Einzelspuren + abstrakte Straßenrelation. Da können Anfänger das alte highway-Schema nehmen.
Die Leute, die hier behaupten, da kommen bei passend reduzierten Einzelspurdaten, dann nur noch Müllansagen, mögen das doch mal belegen. Daten wegwerfen kann man immer, passende dazuerfinden ist schwiieriger. Wenn die Spur an der Kreuzung (heißt ja nicht ohne Grund so!) senkrecht gemeinsame Knotenpunkte mit allen Spuren hat, auf die man einbiegen darf, wo ist denn dann das Problem?
Außerdem muß man natürlich unterscheiden zwischen dem, was man beim Router an Daten auf der Karte sieht und dem was er intern zur Routenberechnung benutzt.
Da ist beides richtig, der Router braucht eine Relation, um zu wissen, welche Spuren denn jetzt die Straße im sinnes des alten highway-Taggings darstellen und neue Router müssen und können die lernen, sich hie metainfos für ihre Ansagen aus den Einzelspuren heraus zu suchen.
Der Router kann aus den Daten auch garantiert nicht die Anzahl der ingesamt vorhandenen Spuren auf der Straße ermitteln oder was?
Mehr als “es gibts auf der Straße x Spuren, die in diese Richtungen gehen … und von … unter folgenden Bedingungen … befahren werden dürfen” kann man doch eh auf Grund der GPS-Ungenauigkeit nicht abbilden.
Die Spur hat nur einen gemeinsamen Knoten mit der anderen Spur, wenn man auch auf sie einbiegen darf.
Turn restrictions sollten dann nur noch die Ausnahme sein, wenn man die erlaubten Richtungebn pro Verkehrsteilnehmer an sie Spur getaggt hat. Müßte man mal noch exemplarisch durchnudeln, die hoch der Aufwand beim mappen da wirklich ist.
Ach, ja, die alten highway=* braucht man aus Rückwärtkompatibilitätsgründen doch noch, aber die sind dann doch nur eine weitere Spur in der abstrakten Straßenrelation.
Die Spuren nur an Kreuzungsbreichen erfassen zu wollen funktioniert nicht, weil die hängen sonst in der Luft und haben keinen Startanknüpfungspunkt ans Straßennetz. Dieser kann wahlweise ein highway=* sein oder, wo schon gemappt, die passenden anderen Spuren.
Hilfe die Welt geht unter…
Wenn der Router aber auf Grund einer Relation weiß, das die zweite Spur in die gleiche Richtung zur gleichen Fahrbahn gehört, wird er sich da seine Berechnung sinnvollerweise verkneifen.
Unter http://forum.openstreetmap.org/viewtopic.php?pid=220989#p220989
habe ich die modifizierten Grundsätze definiert. Dort steht: • lane= wird nur verwendet, wenn es um die detaillierte Erfassung von Spuren geht, die Bestandteil eines highway=* sind, um das spurabhängige routing im Bereich von Kreuzungen, Abzweigungen und Anschlussstellen zu ermöglichen.*
Ich präzisiere das hier weiter, um unnötige Diskussionen wie die letzten sechs posts zu vermeiden: • lane= wird nur verwendet, wenn es um die detaillierte Erfassung von Spuren geht, die Bestandteil eines highway=* sind, um das spurabhängige routing im Bereich von Kreuzungen, Abzweigungen und Anschlussstellen zu ermöglichen, und mehrere mit verschiedenen Richtungsbeschränkungen versehene Spuren je Fahrtrichtung vorhanden sind. *
@ de_muur, viw, Fabi2:
Es geht mir nicht darum, kilometerlange Strecken mit parallelen Spuren ohne Abzweigungen zusätzlich mit lanes zu versehen. Hier reicht das vorhandene Model aus. Der Router nimmt sich die als way abgebildete Straßenmitte und der Anwender ist zufrieden.
Der key lane dient zur Unterscheidung und Detaillierung von highway-Informationen, um Missbrauch des highway-keys in Fällen wie diesem Erwähnten zu verhindern. http://wiki.openstreetmap.org/w/images/8/83/Highway_lanes.png
Der Sinn ist es, dadurch dem router die Möglichkeit zu geben, auf die Auswertung der highway zu verzichten, sobald von einem Knoten an die detaillierten lane-Informationen vorhanden sind. Der Router wertet dann entweder lane oder highway für den Streckenabschnitt , auf dem diese Informationen parallel vorliegen.
Ich mache jetzt mal mein erstes Tagging-Schema fertig und stelle es als als pdf ein. Dann gibt es wieder eine Diskussionsgrundlage und ihr müsst euch nicht im spekulativen Bereich zerfleischen. Ich gebe zu, dass ich durch eventuelle Unklarheiten in Formulierungen Anlass zu den Spekulationen gab und bitte um Verständnis, das noch nicht alles ausgegoren und kristallklar formuliert ist.
Und da Bilder mehr als tausend Worte sagen, kommt dann noch eine grafische Erläuterung auf Basis der bekannten Musterkreuzung. Das dauert aber noch, denn Inkscape ist noch nicht so ganz mein Ding (aber ich mache ja hier auch Gehirn-Jogging )
Also bitte:
Cool bleiben, abwarten und die Pappnasen-Zeit genießen
Macht aber vielleicht erst Sinn, wenn das tagging-Schema ansatzweise steht. Da muss ich mich aber noch etwas schlauer machen. Hat jemand einen Vorschlag, wie das ohne weitere relation zu lösen ist? Ich möchte eigentlich mit Relationen so sparsam wie möglich umgehen.
)