Routing / Spurmapping

Fabi2 · 2012-02-15 23:35:41

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:

width=*
maxspeed=*
surface=*
forward=yes/no (die entsprechende Fahrtrichtung ist (nicht) erlaubt)
backward=yes/no
left=yes/no (man darf (nicht) nach links fahren (Sperrlinien/-flächen, Fußweg, Straßengraben, Überholverbot, etc.))
right=yes/no

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.

Last edited by Fabi2 (2012-02-15 23:39:39)

hurdygurdyman · 2012-02-16 08:52:40

Ich fange mal hinten an:

de_muur wrote:

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

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.

de_muur wrote:

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.

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.

de_muur wrote:

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.

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.

de_muur wrote:

Desweiteren kommt dabei Murks raus, wenn man ausserhalb einer Kreuzung auf die andere Strassenseite will.

Da verstehe ich leider nicht, wie du das im Zusammenhang mit dem Vorschlag meinst

Last edited by hurdygurdyman (2012-02-16 08:53:39)

de_muur · 2012-02-16 13:19:11

hurdygurdyman wrote:

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.

Aber ich verschwende meine Zeit, indem ich dir antworte. Selbst schuld.

de_muur wrote:
Desweiteren kommt dabei Murks raus, wenn man ausserhalb einer Kreuzung auf die andere Strassenseite will.
Da verstehe ich leider nicht, wie du das im Zusammenhang mit dem Vorschlag meinst

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.

Gruss
Torsten

viw · 2012-02-16 13:43:12

de_muur wrote:

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.
Gruss
Torsten

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.

hurdygurdyman · 2012-02-16 13:49:11

de_muur wrote:

Aber ich verschwende meine Zeit, indem ich dir antworte. Selbst schuld.

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.

de_muur wrote:

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.

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.

Last edited by hurdygurdyman (2012-02-16 13:55:35)

de_muur · 2012-02-16 17:23:32

hurdygurdyman wrote:

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.

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

Gruss
Torsten

viw · 2012-02-16 17:37:53

de_muur wrote:

hurdygurdyman wrote:
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.
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.)
Gruss
Torsten

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?

hurdygurdyman · 2012-02-16 18:51:47

de_muur wrote:

hurdygurdyman wrote:
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.
Nein, wie kommst du jetzt darauf?
...

Deine Aussage

de_muur wrote:

Und das funktioniert halt nicht, wenn man auf den anderen Strassenseite ein Ziel ansteuern will,

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.

Last edited by hurdygurdyman (2012-02-16 18:52:07)

de_muur · 2012-02-16 21:11:05

hurdygurdyman wrote:

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.

Gruss
Torsten

viw · 2012-02-16 21:19:15

de_muur wrote:

hurdygurdyman wrote:
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.
Gruss
Torsten

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.

de_muur · 2012-02-16 21:38:11

viw wrote:

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.

Gruss
Torsten

Fabi2 · 2012-02-16 23:00:03

aighes wrote:

hurdygurdyman wrote:
Den Einwand von de_muur "Die absolute Pest fuer bestehendes Routing ist es nämlich, wenn jeweils eigenstaendige Linien erfasst werden." verstehe ich nicht, da mir Erfahrungswerte fehlen.
Router basteln sich aus den Daten einen Routinggraph für eine Straße, der alle Infos enthalten sollte. Daraus kann er dann das Gewicht des Weges ermitteln. Gliedert man Wege zu weit auf, gehen manche Infos unweigerlich verloren, wenn man sie nicht doppelt einträgt. Ebenso verkompliziert sich der Routinggraph natürlich ordentlich.

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.

Fabi2 · 2012-02-16 23:14:50

de_muur wrote:

viw wrote:
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.
[...]
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.

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.

Fabi2 · 2012-02-17 00:57:58

flaimo wrote:

wieso nicht lanes gleich als eigenständige ways mappen? http://wiki.openstreetmap.org/w/images/ … _lanes.png
ist genauso kompliziert, dafür aber exakter.

+1
Problem verstanden!

chris66 wrote:

Weil der Routinggraph schlicht und einfach falsch ist. Du kannst in der Realität mit Deinem Fahrzeug beliebig die
Spuren wechseln (zumindest bei gestrichelter Linie), der Router kann das nicht, er ist auf der Spur gefangen.

Der Router kann aus den Daten auch garantiert nicht die Anzahl der ingesamt vorhandenen Spuren auf der Straße ermitteln oder was?

chris66 wrote:

Nun kommt hinzu, dass GPS nur begrenzte Genauigkeit hat, und somit die Gefahr groß ist, dass er die
falsche Spur trifft. Des weiteren wird die Komplexität der Daten und damit die Fehlerquote erhöht.

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.

EvanE wrote:

flaimo wrote:
wieso nicht lanes gleich als eigenständige ways mappen? http://wiki.openstreetmap.org/w/images/ … _lanes.png
ist genauso kompliziert, dafür aber exakter.
Weil in deinem Beispiel zwei wesentliche Dinge fehlen:
- ca. 30 - 50 turn restrictions müssten noch ergänzt werden.
==> wesentlich komplexer
- wo darf man die Spuren wechseln und wo nicht?
Erhöht ebenfalls die Komplexität.

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.

railrun wrote:

Die "Jede-Spur-als-eigener-Highway-eintragen-Seuche" greift langsam um sich...

Hilfe die Welt geht unter...

railrun wrote:

Sind 2 Städte zum Beispiel über eine Schnellstraße mit jeweils 2 Spuren in jeder Richtung verbunden (also sind 4 Straßen eingetragen). Beim Routen würde dann versucht werden, die kürzeste Verbindung zwischen beiden Städten zu finden. Somit wird erst geprüft, wie weit die Strecke über die eine Spur ist und dann die andere. Die Kürzere der beiden Spuren wäre dann die Strecke, über die du geführt wirst. (Die anderen 2 Spuren werden nicht beachtet, da sie ja in die Gegenrichtung führen)
=> Es müssen 2 statt einer Berechnung angestellt werden. Ich hoffe wir reden hier nicht aneinander vorbei

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.

hurdygurdyman · 2012-02-17 04:28:51

de_muur wrote:

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

Unter http://forum.openstreetmap.org/viewtopi … 89#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/ … _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

Last edited by hurdygurdyman (2012-02-17 08:20:00)

hurdygurdyman · 2012-02-17 08:30:03

Mein Lösungsansatz zum lane-tagging ist fertig und hier abgelegt:
http://wiki.openstreetmap.org/wiki/File … ansatz.pdf
Gedanken,Vorschläge und Wünsche dazu nehme ich gern entgegen.

Also: Feuer frei (aber bitte nichts verbrennen)

chris66 · 2012-02-17 09:56:59

hurdygurdyman wrote:

um Missbrauch des highway-keys in Fällen wie diesem Erwähnten zu verhindern. http://wiki.openstreetmap.org/w/images/ … _lanes.png

Das ist übrigens eine super Beispiel-Kreuzung.

Nehmen wir einen Autofahrer, der von "unten-links" geradeaus nach "oben-rechts" will und sich auf der rechten
Spur befindet. Wenn ich's richtig sehe, dürfen Busse auf der Spur gerade fahren, während Autos
rechts abbiegen müssen. Der Autofahrer muss also eine Spur nach links. Im Routinggraph geht dass nur wenn
er im Bereich der Kreuzungsfläche einmal 90 Grad links und dann 90 Grad rechts abbiegt.

hurdygurdyman · 2012-02-17 10:38:13

chris66 wrote:

Das ist übrigens eine super Beispiel-Kreuzung.
...

Das habe ich mir auch schon gedacht. Ich würde die gerne mal als Beispiel für lane-tagging verwenden, wenn die Grundsätze dafür klar sind.
Es wäre aber sehr aufwändig, diese grafisch nachzubilden
Wo ist diese Stelle und kann ich bing einfach als Hintergrund für eine Foliensammlung zum Thema verwenden, wenn ich die Quelle angebe?

Last edited by hurdygurdyman (2012-02-17 11:05:21)

errt · 2012-02-17 12:11:13

hurdygurdyman wrote:

Mein Lösungsansatz zum lane-tagging ist fertig und hier abgelegt:
http://wiki.openstreetmap.org/wiki/File … ansatz.pdf
Gedanken,Vorschläge und Wünsche dazu nehme ich gern entgegen.
Also: Feuer frei (aber bitte nichts verbrennen)

Unten steht, footway und cycleway bleiben unberücksichtigt, oben gibt es aber einen Ausnahme von oneway=yes für lane=footway. Passt finde ich nicht ganz zusammen. Außerdem frage ich mich, ob es mehr straßenbegleitende Fahrradwege (solche würde man ja dann wohl mit lane=cycleway darstellen) gibt, die oneway=yes sind oder oneway no. Da sollte man einen vernünftigen Standard wählen.

Die Beschränkung auf Kreuzungssituationen ist zwar nett gedacht, aber IMO unrealistisch. Wenn es ein vernünftiges Schema gibt, wird es auch an gerader Strecke eingesetzt werden. Aber ich sehe da auch kein Problem, da ja die bisherige highway Struktur erhalten bleibt, ist es doch auch nicht schädlich, wenn die lane Informationen auch an gerader Strecke vorliegen.

Ansonsten erstmal Zustimmung, gefällt mir.

hurdygurdyman · 2012-02-17 12:29:49

errt wrote:

Unten steht, footway und cycleway bleiben unberücksichtigt, oben gibt es aber einen Ausnahme von oneway=yes für lane=footway. Passt finde ich nicht ganz zusammen. Außerdem frage ich mich, ob es mehr straßenbegleitende Fahrradwege (solche würde man ja dann wohl mit lane=cycleway darstellen) gibt, die oneway=yes sind oder oneway no. Da sollte man einen vernünftigen Standard wählen.
Die Beschränkung auf Kreuzungssituationen ist zwar nett gedacht, aber IMO unrealistisch. Wenn es ein vernünftiges Schema gibt, wird es auch an gerader Strecke eingesetzt werden. Aber ich sehe da auch kein Problem, da ja die bisherige highway Struktur erhalten bleibt, ist es doch auch nicht schädlich, wenn die lane Informationen auch an gerader Strecke vorliegen.
Ansonsten erstmal Zustimmung, gefällt mir.

Beim footway habe ich schon weiter gedacht. Taggen sol ja schon möglich sein. ich werde das konkreter fassen, indem ich den Fokus im ersten Schritt auf "spurabhängiges routing für motorisierten Verkehr" ändere.
cycleway werde ich im Auge behalten und deine Bemerkungen berücksichtigen.
Das Schema wird imo primär an komplexen Kreuzungen benötigt. Natürlich können Mikromapper das dann auch woanders verwenden. Dazu muss es nur entsprechend angelegt werden.

Deine Zustimmung ermutigt mich zum Weitermachen. Danke.

Last edited by hurdygurdyman (2012-02-17 12:30:35)

hurdygurdyman · 2012-02-17 13:26:24

Ich habe mittlerweile hier eine Version 0.2 hochgeladen.
http://wiki.openstreetmap.org/wiki/File … ansatz.pdf
direkt ins Dokument:
http://wiki.openstreetmap.org/w/images/ … ansatz.pdf
Einige Textverbesserungen und genauere Formulierungen wurden eingefügt und das Dokument bekommt jetzt eine Versionsnummer mit Datum, damit alle, die lieber Ausdrucke lesen, die Aktualität ihres Papiers vergleichen können.

Hilfääh!!
Irgendwie hat das Aktualisieren in einigen Versuchen nicht nach meinen Wünschen geklappt, weshalb einiges an Müll unter dem Link liegt. Wie kriege ich alte Uploads gelöscht ? Eigentlich will ich auch im interesse des Speicherplatzes dort nur die aktuellste Variante vorhalten.

Last edited by hurdygurdyman (2012-02-17 13:30:26)

Tordanik · 2012-02-17 14:41:37

hurdygurdyman wrote:

Wie kriege ich alte Uploads gelöscht ? Eigentlich will ich auch im interesse des Speicherplatzes dort nur die aktuellste Variante vorhalten.

Gar nicht. In einem Wiki kann man keine Versionen löschen, das ist Teil des Konzepts.

Man kann die ganze Datei mit allen Versionen von einem Admin "löschen" lassen und dann mit einer neuen Versionsgeschichte neu anfangen. Speicherplatz spart man aber auch so nicht - die Versionen bleiben für Admins trotzdem einsehbar.

Wenn du Dateien sowieso nur selber bearbeiten willst und Wert darauf legst, selbst entscheiden zu können, was gespeichert bleibt, dann ist eigener Webspace, ein öffentlicher Dropbox-Ordner o.ä. wohl die bessere Wahl.

Mein Lösungsansatz zum lane-tagging ist fertig und hier abgelegt

Zum Thema selbst. Dein Lösungsansatz leidet unter demselben Dilemma wie alle Spuren-Als-Ways-Ansätze:

Wenn man die Ways einfach nur ohne Relationen nebeneinander liegen hat, sind die Daten für die maschinelle Auswertung schwer zu nutzen. Wenn man hinggen fordert, dass die Spur-Ways mit Relationen zusammengefasst werden, ist das Bearbeiten nicht mehr so einfach.

Ich befürchte, die Attraktivität dieses Ansatzes beruht zu einem großen Teil darauf, dass die Bedeutung von nebeneinander verlaufenden lane-Ways für den menschlichen Betrachter intuitiv verständlich ist, was über die mangelnde Auswertbarkeit hinwegtäuscht.

Fabi2 · 2012-02-17 20:41:19

Tordanik wrote:

Wenn man die Ways einfach nur ohne Relationen nebeneinander liegen hat, sind die Daten für die maschinelle Auswertung schwer zu nutzen. Wenn man hinggen fordert, dass die Spur-Ways mit Relationen zusammengefasst werden, ist das Bearbeiten nicht mehr so einfach.
Ich befürchte, die Attraktivität dieses Ansatzes beruht zu einem großen Teil darauf, dass die Bedeutung von nebeneinander verlaufenden lane-Ways für den menschlichen Betrachter intuitiv verständlich ist, was über die mangelnde Auswertbarkeit hinwegtäuscht.

Wie gesagt da erstellt man dann eine abstrakte Straßenrelation über die Einzelspuren und das Problem ist auch nicht mehr größer, als das Problem der nicht per gemeinsamen Knotenpunkt verbundenen Wege jetzt schon. Wichtig aus dem Vorschlag ist eigentlich nur die Information, das die Art des Gesamtweges mit an die Einzelspuren muß, was dann auf Kosten von mehr Redundanz und evtl. Widersprüchen eine Relation für den highway=* einspart, so dam man nur noch die für die Gesamtstraße (highway + sidewalks, etc.) braucht.

hurdygurdyman · 2012-02-18 08:09:24

Fabi2 wrote:

Tordanik wrote:
Wenn man die Ways einfach nur ohne Relationen nebeneinander liegen hat, sind die Daten für die maschinelle Auswertung schwer zu nutzen. Wenn man hinggen fordert, dass die Spur-Ways mit Relationen zusammengefasst werden, ist das Bearbeiten nicht mehr so einfach.
Ich befürchte, die Attraktivität dieses Ansatzes beruht zu einem großen Teil darauf, dass die Bedeutung von nebeneinander verlaufenden lane-Ways für den menschlichen Betrachter intuitiv verständlich ist, was über die mangelnde Auswertbarkeit hinwegtäuscht.
Wie gesagt da erstellt man dann eine abstrakte Straßenrelation über die Einzelspuren und das Problem ist auch nicht mehr größer, als das Problem der nicht per gemeinsamen Knotenpunkt verbundenen Wege jetzt schon. Wichtig aus dem Vorschlag ist eigentlich nur die Information, das die Art des Gesamtweges mit an die Einzelspuren muß, was dann auf Kosten von mehr Redundanz und evtl. Widersprüchen eine Relation für den highway=* einspart, so dam man nur noch die für die Gesamtstraße (highway + sidewalks, etc.) braucht.

Somit sind wir wieder beim Grundproblem angelangt
- Einerseits soll das Schema ohne Tools umsetzbar und für den Mapper einfach und nachvollziehbar sein.
- Andereseits bietet die Relation eine bessere Maschinenlesbarkeit und mindert die Gefahr von Redundanzen, fordert aber vom Mapper ein gewisses Maß an Abstraktionsvermögen oder ein Eingabetool.
- Was beim rendern schön aussieht, muss für den router nicht unbedingt sinnvoll sein und umgekehrt.

Die bisherigen Ansätze scheiterten auch in dieser Diskussionrunde genau an diesen Problemen. Das kann auch meinem Ansatz passieren, der eher auf die optischen Fähigkeiten des Mappers aufbaut.
Wir können nicht das eine wollen ohne auf das andere zu verzichten. Ich sehe da wenigstens keinen Weg.
Wir brauchen den engagierten Laien zum Erfassen mit einfachen Mitteln. Aber wir brauchen auch eine Datenbank zur professionellen Auswertung. Beides gleichzeitig wird mit dem OSM-Datenmodell immer schwieriger, wenn nicht sogar unmöglich

Ich will noch gar nicht daran denken, was mit meinem Ansatz passiert, wenn Brücken ins Spiel kommen. Bei railway und separated cycleway ist da die renderer-Fraktion schon höchst unzufrieden. Wie wollen wir die Realität darstellen, wenn wir in diesen Fällen viele Brücken statt einer real existierenden zeigen ?
Aber jetzt hier bitte keine OT-Brückendiskussion einbauen.

Last edited by hurdygurdyman (2012-02-18 08:15:47)

Netzwolf · 2012-02-18 10:31:30

Nahmd,

hurdygurdyman wrote:

Aber jetzt hier bitte keine OT-Brückendiskussion einbauen.

Ich bin ja artig.

Gruß Wolf

Announcement

#226 2012-02-15 23:35:41

Re: Routing / Spurmapping

#227 2012-02-16 08:52:40

Re: Routing / Spurmapping

#228 2012-02-16 13:19:11

Re: Routing / Spurmapping

#229 2012-02-16 13:43:12

Re: Routing / Spurmapping

#230 2012-02-16 13:49:11

Re: Routing / Spurmapping

#231 2012-02-16 17:23:32

Re: Routing / Spurmapping

#232 2012-02-16 17:37:53

Re: Routing / Spurmapping

#233 2012-02-16 18:51:47

Re: Routing / Spurmapping

#234 2012-02-16 21:11:05

Re: Routing / Spurmapping

#235 2012-02-16 21:19:15

Re: Routing / Spurmapping

#236 2012-02-16 21:38:11

Re: Routing / Spurmapping

#237 2012-02-16 23:00:03

Re: Routing / Spurmapping

#238 2012-02-16 23:14:50

Re: Routing / Spurmapping

#239 2012-02-17 00:57:58

Re: Routing / Spurmapping

#240 2012-02-17 04:28:51

Re: Routing / Spurmapping

#241 2012-02-17 08:30:03

Re: Routing / Spurmapping

#242 2012-02-17 09:56:59

Re: Routing / Spurmapping

#243 2012-02-17 10:38:13

Re: Routing / Spurmapping

#244 2012-02-17 12:11:13

Re: Routing / Spurmapping

#245 2012-02-17 12:29:49

Re: Routing / Spurmapping

#246 2012-02-17 13:26:24

Re: Routing / Spurmapping

#247 2012-02-17 14:41:37

Re: Routing / Spurmapping

#248 2012-02-17 20:41:19

Re: Routing / Spurmapping

#249 2012-02-18 08:09:24

Re: Routing / Spurmapping

#250 2012-02-18 10:31:30

Re: Routing / Spurmapping

Board footer