You are not logged in.

#101 2012-01-22 18:17:17

Flacus
Member
Registered: 2009-05-16
Posts: 93
Website

Re: Routing / Spurmapping

Denk bitte auch einen Schritt weiter.

-- Darstellung in den Karten
-- Integration in JOSM und anderen Editorn
-- Wie können GPS-Geräte von den Daten profitiern
-- Kontakt zu den Autoren von zB MKGMAP bzgl. Umsetzung.

Die schönsten Ideen nutzen sonst leider sehr wenig.

Offline

#102 2012-01-22 18:25:41

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Routing / Spurmapping

Flacus wrote:

Denk bitte auch einen Schritt weiter.

-- Darstellung in den Karten
-- Integration in JOSM und anderen Editorn
-- Wie können GPS-Geräte von den Daten profitiern
-- Kontakt zu den Autoren von zB MKGMAP bzgl. Umsetzung.

Die schönsten Ideen nutzen sonst leider sehr wenig.

Du hast das sehr schön geschrieben. Aber Umsetzung in der Karte ist gar nicht gewünscht. Sonst könnte man die Spuren ja auch malen und müsste nicht so einen Haufen Tags erfinden.
Integration in Josm ist kein Problem. Dafür gibts ja die Vorlagen. Vielleicht macht das später jemand noch grafisch.
GPS Geräte könnten aus den Daten den Spurassitenten erstellen. Das erfordert aber eine Anpassung der Software nicht des Taggings.
Ich denke MKGMAP entwickelt sich recht schnell, so denn nur bekannt ist wie Garmin das speichert. Inzwischen wurde sogar eine Lösung für den Adressindex gefunden. Also hier ist eher die Vorstufe zu wissen in welcher Art braucht Garmin das Zeugs, nicht wie müssen wir MKGAM füttern.

Offline

#103 2012-01-22 18:48:11

fkv
Member
From: Wien
Registered: 2010-08-12
Posts: 760
Website

Re: Routing / Spurmapping

things-change wrote:

lanes=s,s,s[7-18:30]+P[18:30-7] versteht kein Mensch auf den ersten Blick.

Die Ührzeiten sind ein Ausnahmefall, die kommen normal nicht vor und dann ist es einfacher zu verstehen.

Muss das Tag denn alles abbilden, was andere Tags bereits abbilden/können/könnten? Muss man Parkstreifen längs, quer, 60° in einem lanes Tag unterbringen? Dafür gibts doch ein Tag.

So, welchen? De_muur hat sie sich ins Schema gewünscht, und da sind sie. Ich denke, sie gehören wirklich rein, da sie für grafische Darstellungen nützilch sind.

Natürlich kann man sie aus dem Schema raus halten und einiges andere auch. Aber dann kommt man später drauf, dass man dies und das doch braucht, und so muss man andauernd nachbessern.

Ebenso Fuß- und Radwege. Das in ihren eigenen Tags zu belassen, würde auch Punkt 1 entschärfen. Ausserdem wären das ja auch doppelte Informationen, macht ja auch keinen Sinn.

Die eigenen Tags für straßenbegleitende Fuß- und Radwege, also v.a. cycleway=*, sind dann halt Altlasten, die aus Kompatibitätsgründen noch eine Weile mitgeschleppt werden müssen. Das lässt sich nicht verhindern. Diese Tags lassen sich nicht vernünftig "aufpäppeln", das fängt schon damit an, dass nicht definiert ist, in welcher Abfolge die Radwege, Fußwege, Leitschienen usw. nebeneinander liegen.

de_muur wrote:

Schreib den Scheiss aus, von den Abkuerzungen hat niemand etwas.

Von Tagwerten, wo man im Eingabefeld herumscrollen muss, hat auch keiner was. Und das auf unzählige verschiedene Tags aufzuteilen ist auch nicht besser. Die Abkürzungen muss man zwar beim ersten Mal nachschlagen, aber von da an sind sie viel übersichtlicher als lange Würste. Ich denke, dass die Regel Großbuchstabe=Gegenverkehr leicht zu merken ist.

Tordanik wrote:

Das halte ich für einen berechtigten Einwand. Man verzettelt sich leicht, wenn man alle Probleme auf einmal lösen möchte. Probleme wie zeitabhängige Werte haben wir auch für Attribute von Wegen noch nicht gelöst - das ist letztendlich ein separates Thema und sollte besser erst einmal außen vor bleiben.

In diesem Fall geht es aber um die Spurendefinition und da sind Zeitabhängigkeiten etwas ganz Wesentliches. In diesem Thread haben wir herausgefunden, dass wir das brauchen, also wieso sollen wir diese Erkenntnis jetzt nicht nutzen? Wenn wir die Lösung auf die lange Bank schieben, wird sie auch nicht einfacher werden. Von selbst hat sich noch nie etwas gelöst.

Ich hab die Lösung vorgeschlagen, die ich für die praktikabelste halte. Andere (wie lanes:opening_hours=* oder lanes:<nr>:opening_hours=*) haben auch ihre Nachteile. Da können wir drüber diskutieren.

lane_separators = guard_rail , dashed , continuous , dased , guard_rail

Ich finde das fehleranfälliger als die gemeinsame Definition mit den Spuren, da man sich leicht um eine Stelle vertun kann. Außerdem ist das ziemlich viel Schreibarbeit. Du hast dich in deinem Beispiel selber vertippt ("dased"), also was meinst du, was für eine Datenqualität dann im Echtbetrieb rauskommt?

Walter Schlögl wrote:

Bevor aus diesen Ideen hier das nächste Proposal entsteht würde ich vorschlagen, die verschiedenen Ansätze in einer Tabelle zusammenzufassen.
Jede Anforderung oder Spurkonstellation wird in einer eigenen Zeile dargestellt, für jeden der in Frage kommenden Ansätze kann dann eine Spalte ergänzt werden.

Wenn's eine Tabelle wird, dann vielleicht besser auf einer Wiki-Seite. Bin gern dabei.

Wenn ein Ansatz bestimmte Anforderungen nicht oder nur unzureichend erfüllen kann, dann fällt er heraus oder wird überarbeitet und somit bleibt automatisch der beste übrig.

Wobei einige hier geäußerte Kriterien (Einfachkeit, Verständlichkeit, Fehleranfälligkeit) schwer messbar sein werden.

Offline

#104 2012-01-22 19:06:09

chris66
Member
From: Germany
Registered: 2009-05-24
Posts: 9,822

Re: Routing / Spurmapping

Weiter gehts mit dem lustigen Brainstorming zum Thema Spurmapping (aus der Mailing-List):

Stefan wrote:

Moin,

ich habe mal eine Idee zum Einzelspurmapping ausprobiert:

Alle bisherigen highways bleiben erhalten. Die Straßensegmente, für die
eine Einzelspurdarstellung existiert, erhalten zusätzlich das Tag
detail_exists=yes .

Fahrspuren werden einzeln als way mit "detail=lane" erfasst. Sie können
sich aufspalten oder zusammenlaufen, kreuzen sich aber ohne gemeinsamen
Punkt. Abbiegespuren oder Geradeausspuren mit Fahrbahnpfeil erhalten ein Zusatztag (lane=right_turn, lane=straight_on etc.)

Ways mit "detail=lane_change" etwa senkrecht zur Fahrtrichtung beschreiben mögliche Spurwechsel. Sie sind mindestens am Beginn einer
Abbiegespur, an der letzten Wechselmöglichkeit vor einer Verzweigung
(oft die Haltelinie einer Kreuzung), an ersten und letzten Wechselpunkt einer Beschleunigungsspur und dem Übergang vom highway ohne Einzelspur zum way mit "detail=lane" nötig.

Ampeln und Stopschilder werden als Punkt auf den Einzelspuren erfasst.

Zum Test habe ich zwei Stellen mit diesem Schema erstellt:
[1]: eine einfache Einmündung mit Abbiegespuren
[2]: eine große Kreuzung mit komplexem Spurverlauf

Wer Interesse hat, kann sich die Ausschnitte in seinen Lieblingseditor
laden und dort ansehen. Bitte nichts verändern!

Solch ein Modell hat verschiedene Vor- und Nachteile:

+ Das Konzept ist kompatibel zu bisherigen Daten und Anwendungen
+ Die Regeln sind leicht erlernbar und mit jedem Editor umsetzbar
+ Es sind keine zusätzlichen Relationen nötig
+ Der Verlauf von Abbiegespuren auf komplexen Kreuzungen ist
  geometrisch richtig darstellbar
+ Ampeln und Stopschilder, die vor der Kreuzung stehen, lassen sich
  korrekt einer Fahrtrichtung zuordnen
+ Beschränkungen für einzelne Fahrspuren sind einfach möglich
  (Busspur, maxspeed nur für Abbieger, etc.)
+ Aus dem Modell lassen sich je nach Anforderung und Zoomlevel
  verschiedene Kartendarstellungen erzeugen:
  * nur highway (wie bisher)
  * Hybriddarstellung mit mit Einzelspuren als Underlay oder Overlay
  * nur als Detailkarte
+ Ein Fahrspurassistent ist damit einfach möglich. Ein einfacher
  Routingalgorithmus muss nur auf ways mit detail=lane und
  detail=lane_change arbeiten und highways mit detail_exists=yes
  ignorieren

- Die Doppelerfassung von Straßen als Grob- und Detailstruktur passt
  nicht zum üblichen OSM-Schema
- Für Einzelspurerfassung sind gute Luftbilder nötig
- Für längere Strecken ist das Modell zu aufwändig, Zusatztags am
  highway sind dort besser

Das Modell ist nur grob formuliert, für Sonderfälle (Kreisverkehr, Richtungspfeil halb-rechts, etc.) sind Erweiterungen nötig. Die Tagnamen
sind spontan ausgedacht und nicht ausgereift. Eine Nummerierung der
Abbiegespuren ("left_1/2", "left_2/2", ...) fehlt noch.

Ich sehe dies nur als Konzeptstudie, um die Einzelspurerfassung als
way zu diskutieren. Vielleicht haben einige Interesse sich das Konzept
anzusehen und es weiterzuentwickeln.

Viele Grüße
Stephan

[1] http://osm.org/go/0HsYpFYlR--
[2] http://osm.org/go/0HsPVeHXn-

Edit: http://news.gmane.org/find-root.php?gro … icle=91206

Last edited by chris66 (2012-01-22 19:15:20)


Mapper aus dem Münsterland.

Offline

#105 2012-01-22 19:09:57

railrun
Member
From: Dresden
Registered: 2009-10-19
Posts: 214
Website

Re: Routing / Spurmapping

chris66 wrote:

Weiter gehts mit dem lustigen Brainstorming zum Thema Spurmapping (aus der Mailing-List):

Hast du einen Link zum Archiv der Maillist?!


VG
Martin

Offline

#106 2012-01-22 19:17:26

Tordanik
Moderator
From: Germany
Registered: 2008-06-17
Posts: 2,534
Website

Re: Routing / Spurmapping

Walter Schlögl wrote:

Bevor aus diesen Ideen hier das nächste Proposal entsteht würde ich vorschlagen, die verschiedenen Ansätze in einer Tabelle zusammenzufassen.

Etwa wie hier?
http://wiki.openstreetmap.org/wiki/Lane … comparison
Wenn ja, könnt ihr gerne eure Vorschläge ergänzen.

fkv wrote:

In diesem Fall geht es aber um die Spurendefinition und da sind Zeitabhängigkeiten etwas ganz Wesentliches. In diesem Thread haben wir herausgefunden, dass wir das brauchen, also wieso sollen wir diese Erkenntnis jetzt nicht nutzen? Wenn wir die Lösung auf die lange Bank schieben, wird sie auch nicht einfacher werden. Von selbst hat sich noch nie etwas gelöst.

Warum sollten wir die Erkenntnis jetzt nicht nutzen? Weil wir dann ein Zwanzig-Seiten-Proposal bekommen. Wahrscheinliche Resultate: Während wir noch über die Details diskutieren, hat sich ein Proposal mit weniger Weitblick schon als Standard etabliert und unsere Ideen sind für die Tonne. Oder falls wir unser Rundum-Sorglos-Paket wider Erwarten halbwegs zügig fertig bekommen: Kein Mensch liest es, die Leute setzen ihr "I oppose this proposal. Too complex!" darunter und vergessen die Idee wieder.

Die Lösung wird nicht einfacher, wenn wir sie auf die lange Bank schieben. Wenn das Basis-Proposal entsprechend gestaltet ist, wird sie aber auch nicht schwerer. Und je eher man vorzeigbare Zwischenresultate hat, desto besser.

Ich finde das fehleranfälliger als die gemeinsame Definition mit den Spuren, da man sich leicht um eine Stelle vertun kann. Außerdem ist das ziemlich viel Schreibarbeit. Du hast dich in deinem Beispiel selber vertippt ("dased"), also was meinst du, was für eine Datenqualität dann im Echtbetrieb rauskommt?

Siehst du: Du konntest erkennen, dass ich mich vertippt habe, und könntest es jetzt problemlos korrigieren.

Könntest du ohne Ortskenntnis wissen, dass ich versehentlich statt einem Groß- einen Kleinbuchstaben getippt habe? Ich denke mal nicht.


OSM in 3D: OSM2World

Offline

#107 2012-01-22 21:58:52

Walter Schlögl
Member
Registered: 2009-10-20
Posts: 605

Re: Routing / Spurmapping

Hallo Tordanik,

ich denke, auf der Basis von deiner comparison Seite kommen wir rascher weiter, da man die verschiedenen Alternativen optimal vergleichen kann.
Es gilt nun auch abzustimmen, was wir erfassen wollen und was nicht, damit sich die Komplexität erkennen und auch entsprechend begrenzen lässt.

Walter

Offline

#108 2012-01-22 22:47:48

fkv
Member
From: Wien
Registered: 2010-08-12
Posts: 760
Website

Re: Routing / Spurmapping

Tordanik wrote:
Walter Schlögl wrote:

Bevor aus diesen Ideen hier das nächste Proposal entsteht würde ich vorschlagen, die verschiedenen Ansätze in einer Tabelle zusammenzufassen.

Etwa wie hier?
http://wiki.openstreetmap.org/wiki/Lane … comparison
Wenn ja, könnt ihr gerne eure Vorschläge ergänzen.

Ja, so in der Art. Aber die Beispiele sind unglücklich gewählt. Im 2.Bsp. sieht man nicht, wie die Spuren in den Anschlusstraßen weitergehen; und im unteren Bildteil steht was auf den roten Spuren, das ich nicht lesen kann. Im 1. Bsp. sieht man überhaupt nur eine Tafel.  Im 3. Bsp. ist unklar, welcher Bereich gemeint ist.

Warum sollten wir die Erkenntnis jetzt nicht nutzen? Weil wir dann ein Zwanzig-Seiten-Proposal bekommen.

Na, so lang ist das nicht. Höchstens die Beispiele. Vielleicht sollte man die dann auf eine extra Seite stellen, damit das Proposal nicht so kompliziert aussieht.

Wahrscheinliche Resultate: Während wir noch über die Details diskutieren, hat sich ein Proposal mit weniger Weitblick schon als Standard etabliert und unsere Ideen sind für die Tonne.

Das ist der Grund, warum ich zum Spurmapping überhaupt meinen Senf abgebe. Einen persönlichen Bedarf hab ich nicht.

Oder falls wir unser Rundum-Sorglos-Paket wider Erwarten halbwegs zügig fertig bekommen: Kein Mensch liest es, die Leute setzen ihr "I oppose this proposal. Too complex!" darunter und vergessen die Idee wieder.

Bestimmt nicht alle. Jedes neue Proposal versucht Unzulänglichkeiten der vorigen Proposals zu lösen. Ich finde auch gar nicht so wichtig, dass ein Proposal angenommen wird. Wichtiger ist, dass die Konzepte bekannt werden.

Einen Bedarf für ein approved proposal sehe ich in den nächsten Jahren sowieso nicht. Weder sind die Anwendungen reif dafür, noch der Datenbestand. Es fehlen noch so viele Straßennamen und Hausnummern, wozu sollen wir und bei so einem löchrigen Erfassungsgrad schon mit Spurmapping das Leben schwer machen. Das bringt einstweilen nur einen Wartungsaufwand und noch keinen Nutzen für Anwender.

Könntest du ohne Ortskenntnis wissen, dass ich versehentlich statt einem Groß- einen Kleinbuchstaben getippt habe? Ich denke mal nicht.

Also gehen wir mal davon aus, dass das Gebiet von Bing&Co noch vernachlässigt wird. In meinem Vorschlag macht der Unterschied die Fahrtrichtung aus (ausg. p und P). Die ist bei dir in einem anderen Tag definiert, und zwar dadurch, ob (bei Rechtsverkehr) die Anzahl verbleibender "|" gerade oder ungerade ist. Das kann ich ohne Ortskenntnis genausowenig überprüfen.

Offline

#109 2012-01-22 23:29:26

Tordanik
Moderator
From: Germany
Registered: 2008-06-17
Posts: 2,534
Website

Re: Routing / Spurmapping

fkv wrote:

Im 2.Bsp. sieht man nicht, wie die Spuren in den Anschlusstraßen weitergehen; und im unteren Bildteil steht was auf den roten Spuren, das ich nicht lesen kann. Im 1. Bsp. sieht man überhaupt nur eine Tafel.  Im 3. Bsp. ist unklar, welcher Bereich gemeint ist.

Beim 3. Beispiel werde ich mit einem eigenen Foto abhelfen, sobald ich dort mal vorbeikomme. Die anderen sind nicht auf meinem Mist gewachsen, sondern aus dem aktuell in der Abstimmung befindlichen "Turn Lanes"-Proposal.

Du kannst gerne bessere Beispiele suchen. Die Tafel hat aber den Zweck, dass man zumindest mal die Grundidee der Proposals versteht, ohne dass man gleich mit schecht erkennbaren Luftbildern oder Detailproblemen kämpft.

Einen Bedarf für ein approved proposal sehe ich in den nächsten Jahren sowieso nicht. Weder sind die Anwendungen reif dafür, noch der Datenbestand. Es fehlen noch so viele Straßennamen und Hausnummern, wozu sollen wir und bei so einem löchrigen Erfassungsgrad schon mit Spurmapping das Leben schwer machen. Das bringt einstweilen nur einen Wartungsaufwand und noch keinen Nutzen für Anwender.

Der Bedarf nach einem Taggingschema, das zumindest klarer Favorit ist, entsteht dadurch, dass der Programmieraufwand für Anwendungen und Editor-Tools hoch ist. Wenn ich mir nicht halbwegs sicher bin, dass ich aufs richtige Pferd setze, stecke ich ungern so viel Arbeit in die Entwicklung.

Das ist nicht wie bei einfacheren Tags, wo man eben im Renderstil bla=blubb durch foo=bar ersetzen muss, sobald es sich die Mapper mal wieder anders überlegen. Wenn ich ein Programm für Spurlisten mit Kommatrennern schreibe und es malen plötzlich alle lieber separate Ways für die Spuren, kann ich meinen bis dahin geschriebenen Programmcode wegschmeißen.

Um eine gewisse Basis zu haben, auf der man aufsetzen kann, braucht man halt ein fertiges, möglichst populäres Kern-Proposal. Welche Attribute es genau für einen Parkstreifen gibt, muss man dazu hingegen nicht wissen.

Könntest du ohne Ortskenntnis wissen, dass ich versehentlich statt einem Groß- einen Kleinbuchstaben getippt habe? Ich denke mal nicht.

Also gehen wir mal davon aus, dass das Gebiet von Bing&Co noch vernachlässigt wird. In meinem Vorschlag macht der Unterschied die Fahrtrichtung aus (ausg. p und P). Die ist bei dir in einem anderen Tag definiert, und zwar dadurch, ob (bei Rechtsverkehr) die Anzahl verbleibender "|" gerade oder ungerade ist. Das kann ich ohne Ortskenntnis genausowenig überprüfen.

Ich halte einen Fehler bei Groß- und Kleinschreibung z.B. für einen sehr wahrscheinlichen Tippfehler, und deshalb ist es problematisch, dass er schwer zu finden ist. Auch andere Fehler sind schwer zu finden, nur denke ich, dass die eben nicht ebenso häufig vorkommen werden. Aber ok, das ist teils Spekulation.

Generell finde ich halt die Lesbarkeit wichtiger als schnelles Schreiben, denn für's Schreiben will man sowieso Editorunterstützung.


OSM in 3D: OSM2World

Offline

#110 2012-01-23 09:30:46

de_muur
Member
Registered: 2008-08-14
Posts: 833

Re: Routing / Spurmapping

Moin,

anstatt einzelner Anmerkungen will ich nun mal sehen, ob aus meinen Vorstellungen zum Thema ein halbwegs geschlossenes Konzept wird. Zum Gorssteil werde ich hier der Einfachheit halber deutsche Begriffe benutzen, mir geht es erstmal um die Struktur und nicht um die Bezeichner.

A) Den Ansatz, die verschiedenen Spuren als Liste zu erfassen, finde ich gar nicht schlecht. Als wichtigstes sollte man da dann erstmal erfassen, was da ueberhaupt ist. Das koennte dann z.B. so aussehen:
lanes=Fussweg;Radweg;Fahrbahn;Fahrbahn;Fahrbahn;Fuss_Und_Radweg
In Richtung des Weges werden von links nach rechts die verschiedenen Verkehrsflaechen erfasst, die zu diesem Weg gehoeren.
Im Unterschied zum bisherigen lanes=x werden hier nicht nur die KFZ-Spuren auf der Fahrbahn erfasst, sondern auch Fuss- und Radwege, Parkstreifen, Standspuren usw.
Detailfragen waeren dann noch, ob man Abbiegespuren anders bezeichnen sollte als normale Fahrspuren (ich denke schon, zumindest bei Beschleunigungsstreifen und Ausfaedelspuren scheint mir das angebracht), und ob Fahrspuren fuer besondere Nutzung (Busspur, Fahrradspur) ein eigenen Namen bekommen sollten, oder ob das durch Access-Tags erfasst werden sollte (ich denke, auch hier macht ein eigener Name die Sache uebersichtlicher).
Als Trennzeichen in der Liste habe ich hier das Semikolon gewaehlt. Das Komma schient mir ungeeignet, da es innerhalb eines Listenelementes gebraucht werden kann, wenn da mehrere Werte aufgezaehlt werden muessen (z.B. Fahrbahn und gleichzeitig Strassenbahn).

B) Alle weiteren Eigenschaften werden dann ueber lanes:Bezeichner erfasst. Das koennen einmal die ganz normalen Bezeichner sein, die auch jetzt schon fuer Highways definiert sind (surface, access, maxspeed usw.) oder aber das sind speziell fuer das Spurmapping eingefuehrte Kategorien. (Wir wollen ja einen Mehrwert durch das Spurmapping haben).

C) In der physikalischen Beschreibung der Strasse ist der zweite Schritt dann, die Abgrenzung zwischen den Spuren zu erfassen. Ich hatte erst ueberlegt, ob auch die Trennelemente mit in die Spurliste sollten, aber ich denke, dass man die besser als separate Liste erfasst, z.B.:
lanes:separation=nichts;Bordstein;Durchgezogene_Linie;Gestrichelte_Linie;Bordstein
Diese Liste hat per Definition ein Element weniger als die lanes-Liste, alle anderen Listen dagegen muessen genauso viel Elemente haben.

D) Wenn man das Konzept der von links nach rechts aufgezaehlten, verschiedenen Spuren akzeptiert hat, d.h. es existiert eine lanes=...;...;... Liste, so hat man fuer die weitere, deteillierte Erfassung zwei Moeglichkeiten: Entweder man erfasst auch die anderen Elemente ueber vollstaendige Listen, oder aber man erfasst die Listenpositionen einzeln. Definition: die Spur links hat die Nummer 1, die Spurtrennung hat die gleiche Nummer wie die Spur links von ihr,
So koennte obiges Beispiel z.B. so weiter gehen, dass man die Oberflache der Spuren erfassen will. Angenommen der Fuss- und Radweg waere nicht befestigt, dann koennte man entweder
lanes:surface=paved;paved;paved;paved;paved;unpaved
oder
lanes:surface:6=unpaved
setzen.

E) Die Richtung der Fahrspuren sollte nicht kryptisch irgendwo mit untergeschoben werden, sondern als eigenes Tag erfasst werden. Z.B.:
lanes:direction=beide;beide;rueckwaerts;vorwaerts;vorwaerts;beide
Damit hat man keine Probleme mit Rechts- und links-Verkehr und kann auf die selbe Art auch abweichende Richtungen fuer einzelne Ferkehrsteilnehmer erfassen, z.B.
ueber lanes:direction:bicycle:6=vorwaerts (oder von mir aus auch lanes:bicycle:direction:6=vorwaerts)

F) Das Spurmapping macht ja erst richtig Sinn, wenn man auch erfasst, wohin eine Spur im naechsten Abschnitt weiter fuehrt. Fuer das Beispiel nehmen wir mal an, dass der Weg mit seiner Spitze auf eine Kreuzung zeigt, auf der von links eine Strasse einmuendet. Mit
lanes:continuation:4=links
kann man erfassen, dass man von der mittleren Fahrspur aus nur nach links abbiegen darf.
lanes:continuation:3=links,forwaerts
gibt an, dass man in diese Spur (Gegenrichtung) sowohl von links als auch von vorne (Richtung des OSM-Weges) gelangen kann.
lanes:continuation ist eine Kurzschreibweise fuer lanes:continuation:forward, denn es kann auch notwendig sein, die Fortsetzung in der anderen Richtung mit lanes:continuation:backward zu erfassen. Die Erfassung des Uebergangs von einem Weg zum naechsten ueber continuation:forward oder continuation:backward kann ueberbestimmt sein, man muss ja aber nur so weit die Werte setzen wie noetig (bei Korrekter erfassung sollten sich allerdings keine Widersprueche ergeben.)
Statt der OSM-Wegrichtung koennte man die Fortsetzung auch ueber die Fahrtrichtung einer Spur erfassen. Dann hat man aber das Durcheinander, dass fuer einzelne Spuren des Weges die Fortsetzung sich auf unterschiedliche Wege bezieht. Und bei Spuren, die in beide Richtungen benutzt werden duerfen, haette man ein Definitionsproblem.

G) Wenn auch die angrenzenden Strassen spurgenau erfasst worden sind, dann kann auch die Fortsetzung spurgenau erfasst werden. So beschreibt z.B.
lanes:continuation:3=links:2,forwaerts:3
dass sich die dritte Spur des Weges nach links in die zweite Spur und in Wegrichtung in die dritte Spur fortsetzt.
(Natuerlich kann man alle Fortsetzungen eines Weges auch in einer Liste erfassen
lanes:continuation=links:1,links:4,forwaerts:1;links:1,links:4,forwaerts:2; usw.
Oder Sonderfaelle, wo fuer einzelne Ferkehrsteilnehmer auf einer Spur andere Regeln gelten als fuer den Rest lanes:continuation:foot:6=...)

H) Wenn man die Konzepte aus C) und D) kombiniert, dann kann man auf diese Weise auch Strassenraender erfassen. Z.B. wuerde
lanes:separation:0=Baumreihe
und
lanes:separation:6=Baumreihe
aus obigem Beispiel eine Allee machen.

Das Konzept bietet dem Mapper also jede Menge Freiraum, was und wie genau er alles erfassen will. Hauptsache ist erstmal die Erfassung der einzelnen Spuren unter A), der Rest laesst sich dann in bester OSM-Tradition beliebig verfeinern.

Soweit scheint mir erstmal alles ganz stimmig. Ein Problem habe ich z.Z. noch damit, wie man die Uebergaenge von einem Weg in den anderen an den Kreuzungspunkten weitere Charakterisieren kann. Obiges Konzept beschreibt bislang nur, dass man von einer Spur der einen Strasse in eine Spur einer anderen Strasse wechseln kann. Es fehlt aber noch die Beschreibung, ob man dabei ueber eine Ampel kommt, einen Zebrastreifen hat, indirekt abbiegen muss (Fussgaenger) und ob man z.B. erst geradeaus und dann links oder erst links und dann geradeaus gehen muss.

Ist mein Vorschlag verstaendlich? Was meint ihr dazu?

Gruss
Torsten

Offline

#111 2012-01-24 07:36:30

Tordanik
Moderator
From: Germany
Registered: 2008-06-17
Posts: 2,534
Website

Re: Routing / Spurmapping

de_muur wrote:

Ist mein Vorschlag verstaendlich? Was meint ihr dazu?

Den Vorschlag insgesamt finde ich verständlich, er wäre auch technisch umsetzbar. Zu einigen Aspekten habe ich trotzdem Kritik, teils auch Verbesserungsvorschläge.


lanes:continuation:3=links,forwaerts
gibt an, dass man in diese Spur (Gegenrichtung) sowohl von links als auch von vorne (Richtung des OSM-Weges) gelangen kann.

Ich fange hiermit an, weil das mein größter Kritikpunkt ist: Die Angabe, woher man in diese Spur gelangen kann, finde ich hochgradig verwirrend.

Die Information, dass eine Spur z.B. eine reine Linksabbiegerspur ist, sollte am Way selbst vorliegen. Es wäre unzumutbar, dazu alle Spuren aller anderen Ways einer Kreuzung prüfen zu müssen!

Dein Konzept ließe sich dadurch retten, die continuation bei Spuren mit definierter Fahrtrichtung immer in Fahrtrichtung anzugeben - für die Gegenrichtung also immer mit lanes:continuation:backward zu arbeiten. Dann wäre eine Linksabbiegerspur in Gegenrichtung mit lanes:continuation:backward:1 = left eingetragen, was ich als angemessen verständlich empfinde.

Dann würde ich aber auch die Möglichkeit streichen, das "forward" wegzulassen. Wenn man routinemäßig auch backward verwendet, ergibt der Sonderstatus für forward ja keinen Sinn mehr.


lanes

Du bist nicht der erste in diesem Thread, der lanes=* als Key nutzt. Ich halte das aber für einen unnötigen Konflikt mit der bisherigen Verwendung von lanes=* für die Anzahl der (Fahrbahn-)Spuren. Das lässt sich durch Wahl eines anderen Schlüssels - lanes:layout, lanes:type, lanes:class oder was auch immer - problemlos vermeiden.


lanes:surface:6=unpaved

Mit Schlüsseln wie "lanes:surface:6" wird ohne Not der Vorteil aufgegeben, nur eine feste Anzahl Schlüssel zu haben, was sich Anwender z.B. beim Import in Datenbanken oft wünschen.

Am einfachsten für die Auswertung und auch in Editoren & co fände ich, Leerstellen in der Liste zu erlauben. Als z.B.:
lanes:surface = ;;;;;unpaved
Das würde sich fast von selbst programmieren.

Wenn das wegen der Lesbarkeit nicht gefällt, würde ich subjektiv ein
lanes:surface = 6:unpaved
bevorzugen.


Die Richtung der Fahrspuren sollte nicht kryptisch irgendwo mit untergeschoben werden, sondern als eigenes Tag erfasst werden.

Da muss klar sein, dass diese Verschönerung der Tags (der Verzicht auf ein spezielles Richtungstrennzeichen wie das | in meinem Post) dadurch erkauft wird, dass für die große Mehrheit der "normalen" Straßen ohne ungewöhnliche Verteilung der Fahrtrichtungen ein Zusatztag nötig wird. Dazu kommt noch, dass du die Information über "Linksabbiegerspur" etc. in ein Sondertag auslagerst. Das ist zwar schön aufgeräumt, aber führt insgesamt zu 3 Tags statt 1 Tag als Mindestausstattung einer so getaggten Straße.

Ich verstehe den Reiz einer Lösung ohne Ausnahmen und Abkürzungen, es würde sogar die Auswertung und die Unterstützung in Editoren erleichtern, aber man zahlt einen gewissen Preis dafür.


OSM in 3D: OSM2World

Offline

#112 2012-01-24 10:55:27

de_muur
Member
Registered: 2008-08-14
Posts: 833

Re: Routing / Spurmapping

Tordanik wrote:

lanes:continuation:3=links,forwaerts
gibt an, dass man in diese Spur (Gegenrichtung) sowohl von links als auch von vorne (Richtung des OSM-Weges) gelangen kann.

Ich fange hiermit an, weil das mein größter Kritikpunkt ist: Die Angabe, woher man in diese Spur gelangen kann, finde ich hochgradig verwirrend.

An der Stelle hatte ich auch lange ueberlegt, aber ich denke doch, dass ein Tagging der fahrtrichtungsbezogenen Fortsetzung noch verwirrender ist, da man dann in EINER Liste die Angaben fuer ZWEI raeumlich getrennte Wegenden vermischt.

Die Information, dass eine Spur z.B. eine reine Linksabbiegerspur ist, sollte am Way selbst vorliegen. Es wäre unzumutbar, dazu alle Spuren aller anderen Ways einer Kreuzung prüfen zu müssen!

Laut meinem Vorschlag ist das ja auch nicht zwingend gefordert, dass man das so erfasst. Letztendlich stossen an einem Kreuzungspunkt ja mehrere Wegenden aneinander, und man muss per Tagging erfassen, wie sich die einzelnen Spuren ueber die Kreuzungen hinweg miteinander verbinden. Von der Intuition her ist es sicherlich am einfachsten, wenn man fuer jede auf die Kreuzung hinfuehrende Spur angibt, wie diese hinter der Kreuzung weiter geht. Der Vollstaendigkeit halber muss aber auch definiert sein, wie entsprechenden Tags fuer die anderen Spuren zu setzen sind. Das heisst ja aber nicht, dass man die aber auch mit angeben muss, denn letztendlich wird dadurch ja das System ueberbestimmt.
Spaetestens wenn man die Fusswege mit einbezieht, hat sich das mit der definierten Fahrtrichtung der einzelnen Spuren sowieso erledigt.

Du bist nicht der erste in diesem Thread, der lanes=* als Key nutzt. Ich halte das aber für einen unnötigen Konflikt mit der bisherigen Verwendung von lanes=* für die Anzahl der (Fahrbahn-)Spuren. Das lässt sich durch Wahl eines anderen Schlüssels - lanes:layout, lanes:type, lanes:class oder was auch immer - problemlos vermeiden.

Die Bezeichner sind mir bislang voellig egal, entscheidender ist es, erstmal eine Struktur fuer das Spurmapping auszuarbeiten.


Mit Schlüsseln wie "lanes:surface:6" wird ohne Not der Vorteil aufgegeben, nur eine feste Anzahl Schlüssel zu haben, was sich Anwender z.B. beim Import in Datenbanken oft wünschen.

Am einfachsten für die Auswertung und auch in Editoren & co fände ich, Leerstellen in der Liste zu erlauben. Als z.B.:
lanes:surface = ;;;;;unpaved
Das würde sich fast von selbst programmieren.

Im Prinzip wuerde beides gehen. Die erste Variante waere m.E. einfacher (per Hand) zu editieren und auch besser zu lesen, die zweite Variante waere vielleicht einfacher auszuwerten. Letzteres wuerde ich allerdings nicht ueberbewerten, denn ohne viel Aufwand koennte ein Praeprozessor die eine Notation in die andere umwandeln.

Wenn das wegen der Lesbarkeit nicht gefällt, würde ich subjektiv ein
lanes:surface = 6:unpaved
bevorzugen.

Das halte ich fuer die schlechteste aller moeglichen Loesungen.

Da muss klar sein, dass diese Verschönerung der Tags (der Verzicht auf ein spezielles Richtungstrennzeichen wie das | in meinem Post) dadurch erkauft wird, dass für die große Mehrheit der "normalen" Straßen ohne ungewöhnliche Verteilung der Fahrtrichtungen ein Zusatztag nötig wird. Dazu kommt noch, dass du die Information über "Linksabbiegerspur" etc. in ein Sondertag auslagerst. Das ist zwar schön aufgeräumt, aber führt insgesamt zu 3 Tags statt 1 Tag als Mindestausstattung einer so getaggten Straße.

Ist der haeufigste Fall wirklich die Linksabbiegespur? Ist nicht der Fall viel haeufiger, wo eine Strasse ohne bauliche Veraenderung fortgefuehrt wird und man einfach nur beschreiben muss, wie die Strasse aussieht? Im Normalfall braucht man sich um das Verbinden der Spuren eigentlich gar nicht kuemmern, ich wuerde mal schaetzen, dass man bei ueber 90% der Verbindungspunkte ohne weitere Angaben allein mit Default-Werten klar kommt. Die Zusatztags sind doch erst in den Sonderfaellen nötig, wo man es mit komplizierteren Kreuzungsstrukturen zu tun hat.

Gruss
Torsten

Offline

#113 2012-01-24 12:52:40

fkv
Member
From: Wien
Registered: 2010-08-12
Posts: 760
Website

Re: Routing / Spurmapping

Tordanik wrote:

Ich halte einen Fehler bei Groß- und Kleinschreibung z.B. für einen sehr wahrscheinlichen Tippfehler, und deshalb ist es problematisch, dass er schwer zu finden ist. Auch andere Fehler sind schwer zu finden, nur denke ich, dass die eben nicht ebenso häufig vorkommen werden. Aber ok, das ist teils Spekulation.

Generell finde ich halt die Lesbarkeit wichtiger als schnelles Schreiben, denn für's Schreiben will man sowieso Editorunterstützung.

Editorunterstützung ist ok, aber ich will auch die Möglichkeit haben, ohne großen Aufwand alles selber einzugeben. Merkaartor unterstützt praktisch nur manuelles Tagging, denn er ist ein Editor für Leute, die verstehen möchten, was sie tun, und gern die volle Kontrolle haben.

Wieso längere Tags lesbarer sein sollen, kann ich nicht nachvollziehen. Klar, unter einem ausgeschriebenen Wort kann man sich leichter was vorstellen als unter einem Buchstaben. Aber sobald die Kette länger wird, ist sie nicht mehr überschaubar. Da spielen dann die Kürzel ihre Stärke aus. Das ist überall so: Wenn ich sage, ich habe zwei Kinder, dann schreibe ich "zwei" aus. Doch kein Mathematiker wird "Quadratwürzel aus fünfhundertsiebenunddreißig" ausschreiben, dafür benutzt man Ziffern und Symbole. Anderes Beispiel: Adenin und Guanin sind kurze Wörter, die kann man leicht ausschreiben. Aber wenn du eine längere DNA-Sequenz angeben willst, wirst du sie mit A und G abkürzen.

Was nun die Groß- und Kleinschreibung betrifft, ja, da passieren viele Fehler, aus Schlampigkeit, weil es meistens nicht nötig ist dabei auzupassen. Wo es aber nötig ist, wird man schon aufpassen. Und wenn man die Fahrtrichtung auf andere Weise taggt, kann sich man genauso irren.

de_muur wrote:

Als Trennzeichen in der Liste habe ich hier das Semikolon gewaehlt. Das Komma schient mir ungeeignet, da es innerhalb eines Listenelementes gebraucht werden kann, wenn da mehrere Werte aufgezaehlt werden muessen (z.B. Fahrbahn und gleichzeitig Strassenbahn).

Die kannst du auch mit anderen Zeichen trennen, z.B. + oder =. Strichpunkt als Trennzeichen sehe ich als Tabu, da der Strichpunkt normalerweise unabhängige Werte trennt (amenity=restaurant;cafe oder information=board;map), deren Reihenfolge nicht definiert ist und wo gilt: key=value1;value=2 <=> key=value1 + key=value2. Würde ich einen Renderer schreiben, dann würde ich im ersten Schritt alle Tags an Strichpunkten zerlegen und alle doppelten Werte wegwerfen. Damit wären die Spurtags schon kaputt, d.h. man müsste extra für die (d.h. hartkodiert) schon in diesem Schritt eine Ausnahme machen.

Tordanik wrote:

Mit Schlüsseln wie "lanes:surface:6" wird ohne Not der Vorteil aufgegeben, nur eine feste Anzahl Schlüssel zu haben, was sich Anwender z.B. beim Import in Datenbanken oft wünschen.

Eine feste Anzahl Schlüssel in OSM kann es nie geben, da täglich neue erfunden werden. Fix ist nur die Anzahl Schlüssel in der Zieldatenbank. Die müssen kein 1:1 Abbild der Schlüssel in OSM sein. Für lanes:surface:<spurnummer>=<wert> kann man die Tabelle in der Zieldatenbank wie folgt designen:
Tabelle Spursurface
  Feld Way_ID (PK)
  Feld Spurnummer (PK)
  Feld Wert

Ich sehe da überhaupt kein Problem. Letztlich muss bei einem Import sowieso diese Tabelle herauskommen, denn mit Trennzeichen zusammengestückelte Werte wird man in einer relationalen Datenbank nach Möglichkeit vermeiden (erste Normalform).

Ich denke, dass wir für spurbezogene Tags 2 Schreibweisen zulassen sollten:
1.) Kurzschreibweise mit Kommas: lanes:minspeed=60,80,100,100,80,60
2.) Schreibweise für einzelne Spuren: lanes:6:surface=unpaved
   ...damit man sich bei lanes:surface=,,,,,unpaved nicht um ein oder zwei Kommas verzählt.

Die Spurnummer setze ich gleich hinter "lanes:", damit sie an einer fixen Stelle steht. Denn
   lanes:6:maxspeed=100
   lanes:6:maxspeed:hgv=80
finde ich übersichtlicher als
   lanes:maxspeed:6=100
   lanes:maxspeed:hgv:6=100

Offline

#114 2012-01-24 17:02:12

de_muur
Member
Registered: 2008-08-14
Posts: 833

Re: Routing / Spurmapping

fkv wrote:

Wieso längere Tags lesbarer sein sollen, kann ich nicht nachvollziehen. Klar, unter einem ausgeschriebenen Wort kann man sich leichter was vorstellen als unter einem Buchstaben. Aber sobald die Kette länger wird, ist sie nicht mehr überschaubar. Da spielen dann die Kürzel ihre Stärke aus. Das ist überall so: Wenn ich sage, ich habe zwei Kinder, dann schreibe ich "zwei" aus. Doch kein Mathematiker wird "Quadratwürzel aus fünfhundertsiebenunddreißig" ausschreiben, dafür benutzt man Ziffern und Symbole. Anderes Beispiel: Adenin und Guanin sind kurze Wörter, die kann man leicht ausschreiben. Aber wenn du eine längere DNA-Sequenz angeben willst, wirst du sie mit A und G abkürzen.

Solche "Abkuerzungen" funktionieren aber nur, wenn man fest definierte, abgeschlossene Alphabete hat. Wie du spaeter ja aber selber anfeuhrts, ist OSM so aufgebaut, dass Schluessel und Werte beliebig wachsen koennen. Das vetraegt sich mit Abkuerzungen gar nicht. Und zum Glueck sind Abkuerzungen bei OSM ja auch alles andere als ueblich, selbst die Boolean-Werte yes und no werden ja standardmaesisg ausgeschrieben. Da sollte wir jetzt mit dieser Unsitte bestimmt nicht anfangen.

Die kannst du auch mit anderen Zeichen trennen, z.B. + oder =. Strichpunkt als Trennzeichen sehe ich als Tabu, da der Strichpunkt normalerweise unabhängige Werte trennt (amenity=restaurant;cafe oder information=board;map), deren Reihenfolge nicht definiert ist und wo gilt: key=value1;value=2 <=> key=value1 + key=value2.

Genau das meinte ich, nur hatte ich die Zeichen verwechselt :-(

Um so entscheidender ist es, dass man da nicht noch verschiedene Bedeutungen mit rein kodiert.

Vieleicht waere der Strich | ein guter Kandidat, um die einzelnen Spuren zu trennen?

Ich denke, dass wir für spurbezogene Tags 2 Schreibweisen zulassen sollten:
1.) Kurzschreibweise mit Kommas: lanes:minspeed=60,80,100,100,80,60
2.) Schreibweise für einzelne Spuren: lanes:6:surface=unpaved
   ...damit man sich bei lanes:surface=,,,,,unpaved nicht um ein oder zwei Kommas verzählt.

Ganz meine Meinung.

Die Spurnummer setze ich gleich hinter "lanes:", damit sie an einer fixen Stelle steht. Denn
   lanes:6:maxspeed=100
   lanes:6:maxspeed:hgv=80
finde ich übersichtlicher als
   lanes:maxspeed:6=100
   lanes:maxspeed:hgv:6=100

Im Prinzip koennte ich mit beiden Leben. Bei einer Abstimmung wuerde ich allerdings die zweite Variante bevorzugen, um die Aehnlichkeit von
lanes:maxspeed=10,20,30
und
lanes:maxspeed:3=30
zu betonen.

Aber das sind Syntax-Kleinigkeiten. Interessanter ist erstmal, wie man ein Spur-Mapping ueberhaupt aufziehen will.

Gruss
Torsten

Offline

#115 2012-01-24 17:18:33

GeoCounter
Member
Registered: 2010-06-05
Posts: 79

Re: Routing / Spurmapping

fkv wrote:

Die Spurnummer setze ich gleich hinter "lanes:", damit sie an einer fixen Stelle steht. Denn
   lanes:6:maxspeed=100
   lanes:6:maxspeed:hgv=80
finde ich übersichtlicher als
   lanes:maxspeed:6=100
   lanes:maxspeed:hgv:6=100

Ich finde das schreit dann geradezu nach
   lanes[6]:maxspeed=100
   lanes[6]:maxspeed:hgv=80
Dann wäre sogar
   lanes[5;6]:maxspeed=100
   lanes[6]:maxspeed:hgv=80
denkbar.

Offline

#116 2012-01-24 21:13:56

fkv
Member
From: Wien
Registered: 2010-08-12
Posts: 760
Website

Re: Routing / Spurmapping

Tordanik wrote:

http://wiki.openstreetmap.org/wiki/Lane … comparison
Wenn ja, könnt ihr gerne eure Vorschläge ergänzen.

Ok, meiner ist "Alternative B".

BTW: Was heißt Sperrfläche auf Englisch? (Steht nicht mal im Langenscheidt-Wälzer.)

de_muur wrote:

Solche "Abkuerzungen" funktionieren aber nur, wenn man fest definierte, abgeschlossene Alphabete hat. Wie du spaeter ja aber selber anfeuhrts, ist OSM so aufgebaut, dass Schluessel und Werte beliebig wachsen koennen. Das vetraegt sich mit Abkuerzungen gar nicht.

Ob man "slightleft" abkürzt oder ausschreibt, ein lexikalisches Token ist es so oder so. Entweder der Parser kennt es, dann kann er was damit anfangen, oder er kennt es nicht, dann kann er nichts damit anfangen. Auf die Erweiterbarkeit hat das Abkürzen also keinen Einfluss.

GeoCounter wrote:

Ich finde das schreit dann geradezu nach
   lanes[6]:maxspeed=100
   lanes[6]:maxspeed:hgv=80
Dann wäre sogar
   lanes[5;6]:maxspeed=100
   lanes[6]:maxspeed:hgv=80
denkbar.

Mir persönlich wär's recht, aber diese Schreibweise wäre in OSM neu.

Offline

#117 2012-01-24 21:58:02

de_muur
Member
Registered: 2008-08-14
Posts: 833

Re: Routing / Spurmapping

fkv wrote:

Ob man "slightleft" abkürzt oder ausschreibt, ein lexikalisches Token ist es so oder so. Entweder der Parser kennt es, dann kann er was damit anfangen, oder er kennt es nicht, dann kann er nichts damit anfangen.

Klar ist das mit den Abkuerzungen dem Parser egal (solange es eindeutig ist). Es geht dabei allein um die Lesbarkeit fuer den Mapper. Schau dir doch mal mit einem Meter Abstand auf der Uebersichtsseite Alternative B Example 2 an. Das versteht doch kein (menschliches) Schwein mehr, einschliesslich des Mappers selber auch nur 3 Minuten nach dem Eintragen.
Und erzaehl mir nicht, dass das Tagging des Beispiel dank der Abkuerzungen schoen uebersichtlich waere  ;-)

Gruss
Torsten

Offline

#118 2012-01-24 22:40:54

Walter Schlögl
Member
Registered: 2009-10-20
Posts: 605

Re: Routing / Spurmapping

Alternative 3 ist auch drinnen.

Hallo fkv,

du solltest bei deiner Alternative nicht lanes=* verwenden, das ist bereits 2249668x anderweitig genutzt.
Es spricht sicher nichts dagegen, lanes:layout nochmals zu nehmen, oder auch einfach etwas anderes.

Walter

Offline

#119 2012-01-24 22:41:16

fkv
Member
From: Wien
Registered: 2010-08-12
Posts: 760
Website

Re: Routing / Spurmapping

@de_muur: Dann lass mal deine Variante sehen.

Im Vergleich zu den linken Spalten sieht Alternative B in Example 2 natürlich kompliziert aus, weil die nur die Hälfte der Informationen enthalten.

@Walter: lanes=* hab ich vom Vorgängerproposal übernommen. Natürlich kann man es auch lanes:layout nennen, aber ich spare mir gern Schreibarbeit. Dass lanes=<Zahl> schon oft vorkommt, stört nicht. Ich nehme an, dass Anwendungen diesen Tag bisher sowieso ignoriert haben, da sich mit der Gesamtspurenzahl nicht viel anfangen lässt. Und zukünftige Anwendungen können leicht erkennen, ob der Wert nur eine Zahl enthält oder was anderes.

Last edited by fkv (2012-01-24 22:50:52)

Offline

#120 2012-01-25 05:40:16

Tordanik
Moderator
From: Germany
Registered: 2008-06-17
Posts: 2,534
Website

Re: Routing / Spurmapping

de_muur wrote:

Die Information, dass eine Spur z.B. eine reine Linksabbiegerspur ist, sollte am Way selbst vorliegen. Es wäre unzumutbar, dazu alle Spuren aller anderen Ways einer Kreuzung prüfen zu müssen!

Laut meinem Vorschlag ist das ja auch nicht zwingend gefordert, dass man das so erfasst. Letztendlich stossen an einem Kreuzungspunkt ja mehrere Wegenden aneinander, und man muss per Tagging erfassen, wie sich die einzelnen Spuren ueber die Kreuzungen hinweg miteinander verbinden. Von der Intuition her ist es sicherlich am einfachsten, wenn man fuer jede auf die Kreuzung hinfuehrende Spur angibt, wie diese hinter der Kreuzung weiter geht.

Eben, es ist unter Zuhilfenahme der Fahrtrichtung intuitiver. Und ich würde deshalb noch weiter gehen und ein solches Mapping nicht nur erlauben, sondern es direkt zur Vorgabe machen, dass die Fortsetzung in (einer der) Fahrtrichtung(en) anzugeben ist.

Die Regel sähe dann so aus:
* lanes:continuation:forward/backward gibt an, wohin man gelangt, wenn man sich auf der Spur in/entgegen Wegrichtung bewegt
* bei Spuren für beide Richtungen kann man eins weglassen, wenn das Ziel in der einen Richtung mit der Herkunft bei der anderen Richtung übereinstimmt.

Dazu auch mal eine Detailfrage: Wie handhabst du mit deinem Vorschlag Spuren, bei denen mein Zusatz "wenn das Ziel in der einen Richtung mit der Herkunft bei der anderen Richtung übereinstimmt" nicht gilt? Also z.B. eine "two-way left turn lane" für Linksabbieger in beide Richtungen? Skizze siehe unteres Diagramm http://www.mto.gov.on.ca/english/dandv/ … .6.5.shtml hier.

Wenn man sich - wie ich hier vorschlage - darauf festlegt, die Fahrtrichtung als Kriterium ins Tagging einzubeziehen, dann wird man dort einfach ...:forward und ...:backward passend für die jeweilige Fahrtrichtung setzen.

Ist der haeufigste Fall wirklich die Linksabbiegespur? Ist nicht der Fall viel haeufiger, wo eine Strasse ohne bauliche Veraenderung fortgefuehrt wird und man einfach nur beschreiben muss, wie die Strasse aussieht?

Die Linksabbiegespur ist nicht der häufigste Fall, aber insgesamt gesehen doch allgegenwärtig. Es sollte schon eine Möglichkeit geben, eine Spur als Linksabbiegerspur zu markieren. (Das ist nicht dasselbe wie ein "left" bei der Continuation, denn eine Linksabbiegerspur beginnt schon ein ganzes Stück vor der Kreuzung und ist auch dann eine Linksabbiegerspur, wenn man den Way in ihrem Verlauf auftrennen muss.) Das fehlt in deinem Vorschlag leider noch.

Wenn das wegen der Lesbarkeit nicht gefällt, würde ich subjektiv ein
lanes:surface = 6:unpaved
bevorzugen.

Das halte ich fuer die schlechteste aller moeglichen Loesungen.

Darf man fragen warum? Ich finde es ähnlich gut lesbar wie deinen Vorschlag, aber es vermeidet gleichzeitig das leidige Thema Zahlen in Schlüsseln.

fkv wrote:

Eine feste Anzahl Schlüssel in OSM kann es nie geben, da täglich neue erfunden werden

Es ist normalerweise aber möglich, eine endliche Liste von Schlüsseln zu erstellen, die für die eigene Anwendung relevant sind. Das erleichtert z.B. die Erstellung von Filtern.

Editorunterstützung ist ok, aber ich will auch die Möglichkeit haben, ohne großen Aufwand alles selber einzugeben.

Und dann schlägst du so was vor?

lanes=c.l+s,s,s+r,r||N.N,C<kerb>p

Vielleicht ist das auch wieder eine Geschmacksfrage, aber das finde ich schwer zu lesen, schwer zu schreiben und schwer zu parsen. Ohne Editorunterstützung fasse ich diesen Wert nicht mal mit der Kneifzange an. wink


OSM in 3D: OSM2World

Offline

#121 2012-01-25 08:21:51

fkv
Member
From: Wien
Registered: 2010-08-12
Posts: 760
Website

Re: Routing / Spurmapping

Tordanik wrote:

* lanes:continuation:forward/backward gibt an, wohin man gelangt, wenn man sich auf der Spur in/entgegen Wegrichtung bewegt

Das ist das, was ich lane_matching genannt habe, weil mir kein besserer Keyname eingefallen ist. Vielleicht ist ...continuation besser, keine Ahnung.

Wenn das wegen der Lesbarkeit nicht gefällt, würde ich subjektiv ein
lanes:surface = 6:unpaved
bevorzugen.

Das halte ich fuer die schlechteste aller moeglichen Loesungen.

Darf man fragen warum? Ich finde es ähnlich gut lesbar wie deinen Vorschlag, aber es vermeidet gleichzeitig das leidige Thema Zahlen in Schlüsseln.

Indem ein Teil des Schlüssels in den Wert verschoben wird. Genauso könnte man lanes=surface:6:unpaved draus machen.

Es ist normalerweise aber möglich, eine endliche Liste von Schlüsseln zu erstellen, die für die eigene Anwendung relevant sind. Das erleichtert z.B. die Erstellung von Filtern.

Wir leben im 3. Jahrtausend. Heute gibt es regular expressions.

Und dann schlägst du so was vor?

lanes=c.l+s,s,s+r,r||N.N,C<kerb>p

Vielleicht ist das auch wieder eine Geschmacksfrage, aber das finde ich schwer zu lesen, schwer zu schreiben und schwer zu parsen. Ohne Editorunterstützung fasse ich diesen Wert nicht mal mit der Kneifzange an. wink

Wenn du die Doku (http://wiki.openstreetmap.org/wiki/User … ping_draft) anschaust, geht das schon. Dafür, was in dem Wert alles drinsteckt, ist er doch relativ übersichtlich. Wenn man das anders macht, wird es noch komplizierter.

eine "two-way left turn lane" für Linksabbieger in beide Richtungen? Skizze siehe unteres Diagramm http://www.mto.gov.on.ca/english/dandv/ … .6.5.shtml hier.

Fein, das werde ich gleich in die Vergleichsseite einbauen. EDIT: Doch noch nicht, weil in dem Beispiel keine Kreuzung ist und weil mir die Regeln noch nicht ganz klar sind. Verstehe ich das richtig, dass eine center turn lane für Linksabbieger von beiden Seiten eine Abbiegespur ist, zugleich für Linksabbieger von der Querstraße so eine Art Beschleunigungsstreifen?

Last edited by fkv (2012-01-25 08:59:26)

Offline

#122 2012-01-25 08:46:56

de_muur
Member
Registered: 2008-08-14
Posts: 833

Re: Routing / Spurmapping

Tordanik wrote:

Eben, es ist unter Zuhilfenahme der Fahrtrichtung intuitiver. Und ich würde deshalb noch weiter gehen und ein solches Mapping nicht nur erlauben, sondern es direkt zur Vorgabe machen, dass die Fortsetzung in (einer der) Fahrtrichtung(en) anzugeben ist.

Die Regel sähe dann so aus:
* lanes:continuation:forward/backward gibt an, wohin man gelangt, wenn man sich auf der Spur in/entgegen Wegrichtung bewegt
* bei Spuren für beide Richtungen kann man eins weglassen, wenn das Ziel in der einen Richtung mit der Herkunft bei der anderen Richtung übereinstimmt.

Meinst du beim ersten Punkt in der Regel jetzt "Wegrichtung" oder "Fahrtrichtung"?

Das Problem bei der Fahrtrichtung ist halt die vollstaendige Listendarstellung lanes:continutaion:forward=left|straight|straight|right
Bei den Spuren mit lanes:direction=forward wird hier die Kreuzung an dem einen Ende des Weges beschrieben, bei den Spuren mit lanes:direction=backward wird hier eine ganz andere Kreuzung am anderen Ende des Weges beschrieben.
Diese Vermischung halte ich fuer ziemlich verwirrend. Mir schient es da sinnvoller zu sein, dass man unter EINEM Schluessel die Verbindungen der Spuren an EINEM Ende des Weges sammelt.

Vielleicht waere als Schluessel lanes:connection passender, da dieser Begriff bezgl. der Richtung neutraler ist. Es wird einfach angegeben, wie eine Spur an diesem Kreuzungspunkt mit den anderen Richtungen verbunden ist.

Dazu auch mal eine Detailfrage: Wie handhabst du mit deinem Vorschlag Spuren, bei denen mein Zusatz "wenn das Ziel in der einen Richtung mit der Herkunft bei der anderen Richtung übereinstimmt" nicht gilt? Also z.B. eine "two-way left turn lane" für Linksabbieger in beide Richtungen? Skizze siehe unteres Diagramm http://www.mto.gov.on.ca/english/dandv/ … .6.5.shtml hier.

Ich muss gestehen, dass ich weder deinen Zusatz noch das Beispiel in deinem Link wirklich verstehe.

Nach meinem Konzept sollte in einem Schlüssel erfasst werden, wie die jewielige Spur an einem Knotenpunkt mit den angrenzenden Wegen verbunden ist. Das wird ueber den entsprechenden Wert abgebildet, wobei auch eine Liste von Werten moeglich ist.
Die gaengigsten Werte duerften straight, left und right sein dazu kommt sicherlich noch ein Wert fürs Wenden u_turn oder backward vielleicht sowie Zwischenwerte fuer kompliziertere Kreuzungstopologien wie slight_left oder sharp_right und vielleicht braucht man auch noch ein up oder down, wobei solche vertikalen Wegtrennungen eigentlich immer auch in der Ebene beschrieben werden koennen.

Bei naeheren ueberlegen habe ich deine Frage jetzt, glaube ich, doch verstanden. Meinst du: Wie wuerde mein Konzept es abbilden, wenn die Verbindungen zwischen den Spuren nicht symmetrisch sind? D.h. solche Faelle, wo eine Spur in beide Richtungen befahrbar ist, sie ueber die Kreuzung aber mit Spuren verbunden ist, die nur in eine Richtung befahren werden darf.
Bei meinem Konzept wuerde sich daraus ergeben, dass lanes:connection:forward des eines Weges nicht genau dem lanes:connection:backward entspricht. Da hatte ich bisher noch nicht drueber nachgedacht, scheint mir aber letztendlich kein Problem zu sein, denn am Ende sollte sich ja trotzdem ein widerspruchsfreies Gesamtbild ergeben.

Die Linksabbiegespur ist nicht der häufigste Fall, aber insgesamt gesehen doch allgegenwärtig. Es sollte schon eine Möglichkeit geben, eine Spur als Linksabbiegerspur zu markieren. (Das ist nicht dasselbe wie ein "left" bei der Continuation, denn eine Linksabbiegerspur beginnt schon ein ganzes Stück vor der Kreuzung und ist auch dann eine Linksabbiegerspur, wenn man den Way in ihrem Verlauf auftrennen muss.) Das fehlt in deinem Vorschlag leider noch.

Das ist die von mir noch offen gelassene Frage, ob man bei der Bezeichnung der einzelnen Spuren zwischen Abbiegespur und "normaler" Fahrspur unterscheiden muss oder nicht. Fuer das Routing (im Sinne von: Bestimmung der optimalen Spur) oder für eine schoene Kartendarstellung braucht man das eigentlich nicht. Aber fuer die Sprachausgabe koennte das hilfreich sein. Oder verwirrt diese Zusatzinformation eher? Ich habe weiss es nicht. Ab wann ist eine "normale" Fahrspur eine Abbiegespur? Sobald da Pfeile aufgemalt sind, schaetze ich mal.

Wenn das wegen der Lesbarkeit nicht gefällt, würde ich subjektiv ein
lanes:surface = 6:unpaved
bevorzugen.

Das halte ich fuer die schlechteste aller moeglichen Loesungen.

Darf man fragen warum? Ich finde es ähnlich gut lesbar wie deinen Vorschlag, aber es vermeidet gleichzeitig das leidige Thema Zahlen in Schlüsseln.

Weil dabei Schluessel und Wert vermischt werden. Bei dieser Loesung muss man auch die rechte Seite der Gleichung auswerten, ehe man entscheiden kann, ob das Tag fuer einen von Belang ist oder nicht.

Bezueglich der Zahlen in Schluesseln sehe ich nicht so das grosse Problem. Klar, die Auswerteprogramme muessen eine Nummer schlauer werden, wenn sie diese Informationen auswerten wollen. Das gilt aber auch fuer die angedachte Listendarstellung auf der rechten Seite des Gleichheitszeichens. Das Spurmapping stellt nun mal hoehere Anforderungen an die Auswertung, liefert aber dafuer zusaetzliche Informationen, die bislang nicht erfasst werden koennen.

Mit dem lanes=* stimme ich mit fkv ueberein. Es besteht keine Gefahr, dass lanes=* und lanes=<Zahl> bei der Auswertung verwechselt werden. Und ich sehe keinen Sinn darin, fuer einen Weg die Beschreibung von lanes=<Zahl> und lanes:layout=* parallel vorzusehen/zuzulassen. Das wuerde nur zusaetzliche Komplikationen mit sich bringen.

@fkv: Ja, ich sollte wohl mein Konzept auch als Variante in die Uebersicht mit aufnehmen. Allerdings habe ich damit zwei Probleme: Zum einen legt das fuer meinen Geschmack den Schwerpunkt zu sehr auf die Syntax, welche ich als eher zweitrangig ansehe. Zum anderen sind die Beispiele so unvollstaendig, dass die konzeptionellen Unterschiede zwischen den einzelnen Varianten gar nicht klar werden. Solange z.B. nicht der OSM-Weg-Graph fuer die Beispiele mit angegeben wird, kann man einen Unterschied zwischen einer Erfassung enstprechend der Wegrichtung und einer Erfassung entsprechend der Fahrtrichung gar nicht erkennen.

Gruss
Torsten

Offline

#123 2012-01-27 12:56:00

de_muur
Member
Registered: 2008-08-14
Posts: 833

Re: Routing / Spurmapping

Tordanik wrote:

http://wiki.openstreetmap.org/wiki/Lane … comparison
Wenn ja, könnt ihr gerne eure Vorschläge ergänzen.

Ich habe meinen Vorschlag mal praezisiert und dann als Alternative E in die Tabelle aufgenommen. Das faellt bei den Beispielen aber echt schwer. Denn das Verfahren soll ja auch das detailierte Mapping erlauben, nur leider kann man halt die Details auf den Photos nicht erkennen. Entweder man faengt dann an zu raten, oder man kann kaum was als Beispiel erfassen.

Gruss
Torsten

Offline

#124 2012-01-29 03:09:44

flaimo
Member
From: Austria
Registered: 2009-10-15
Posts: 169
Website

Re: Routing / Spurmapping

wieso nicht lanes gleich als eigenständige ways mappen? http://wiki.openstreetmap.org/w/images/ … _lanes.png

ist genauso kompliziert, dafür aber exakter.

Offline

#125 2012-01-29 05:52:01

EvanE
Member
Registered: 2009-11-30
Posts: 5,716

Re: Routing / Spurmapping

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.

Ganz nebenbei, wer soll so etwas noch in Ordnung halten?
Edit: Abbiegen auf eine reine Busspur ist irgendwie auch nicht optimal oder so vorgesehen.

Edbert (EvanE)

Last edited by EvanE (2012-01-29 05:54:00)

Offline

Board footer

Powered by FluxBB