Allgemein sollte auch eine Erfassung des Typs der Spur moeglich sein, durch eine Beschreibung der Erlaubten Nutzung alleine ist das nicht gegeben. Neben dem Beispiel des Seitenstreifens (Standspur) faellt mir da spontan auch noch ein Parkstreifen ein.
Gruss
Torsten
Ok, neuer Wert “sig”:
lanes=S,sig,s für 3 Spuren mit mittlerer richtungswechselnd
So eine Spur zählt dann für die anderen Tags als in beiden Richtungen in Fahrtrichtung befahrbar, darf aber von einem Spurenassistenten nicht angeordnet werden.
Was ist das genau?
Ok, kleines p haben wir schon für Fußgänger vergeben, haben wir noch großes P:
lanes=P,s,P60 für Parkstreifen parallel zum Fahrbahnrand, Gradausspur, Parkstreifen für Schrägparken 70° (Winkel von Wayrichtung im Uhrzeigersinn gemessen).
Für Tageszeitenabhängige Parkstreifen könnte man die Syntax weiter erweitern, z.B.:
lanes=s,s,s[7-18:30]+P[18:30-7] für 3-spurige Einbahn mit zeitabhängigem Parkverbot am rechten Streifen.
In den Klammern die Syntax von opening hours.
viw’s Frontalcrashspur könnte man damit bei fixen Zeiten auch so taggen:
lanes=S,S[0-12]+s[12-24],s
Zu den Anforderungen siehe auch meinen Beitrag #82.
Wer die Spur benutzen darf, kann nicht komplett durch Tags definiert werden, sondern da ist eine Mindestintelligenz (bzw. StVO-Kenntnis) der Router gefragt. Siehe Fußgänger, die dürfen auf der Fahrbahn gehen, wenn kein Gehsteig vorhanden ist und die Straße keine Autostraße oder Autobahn ist. Aber auf den inneren Spuren dürfen sie nicht gehen. Außer um die Straße zu queren. Wenn man das alles in Tags berücksichtigen wollte, würde man verrückt werden.
Ich glaub, mit 1 Buchstabe pro Spur kommen wir nicht durch. Darum hab ich die Leitlinien in meinem Vorschlag explizit als Beistriche vorgesehen.
Bin zwar kein Programmierer eines Renderers, aber Programmierer. Nein, keine Probleme zu erwarten. Sogar ausgefallene Zeichen wie ↔, 
, 
, 
, 
, 
usw. sind erlaubt, aber auf die würde ich verzichten, weil die schwerer einzugeben sind und vielleicht noch nicht überall richtig angezeigt werden.
Da stellen sich mir bloß 2 Fragen:
Wir können hier so ein Schema noch 10 Seiten weiter diskutieren, und dann eine Lösung haben, die alles erdenkliche abdeckt. Bloß es versteht dann keiner mehr. Es gab ja anfangs schon den Einwand, keine Abkürzungen zu verwenden. Andererseits sollen die Tags auch nicht zu lang werden…
lanes=s,s,s[7-18:30]+P[18:30-7] versteht kein Mensch auf den ersten Blick. Alles grafisch in JOSM einzutragen ist ja schön, aber es gibt ja auch noch Potlatch…
Wenn man so ein Schema zum Proposal bringt, wird jeder, der das liest und nicht hier an der Diskussion teilgenommen hat, dagegen stimmen…
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. Und wenn das noch nicht alles kann, muss man das Tag halt erweitern. 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.
+1
Schreib den Scheiss aus, von den Abkuerzungen hat niemand etwas. Normalerweise sollte die Eingabe ueber einen passenden Editor stattfinden. Dem ist es egal, ob er abgekuerzte oder ausgeschriebene Tags erzeugt. Aber es wird immer wieder Faelle geben, wo man es mit der XML-Datei zu tun hat (z.B. wenn man einen Fehler sucht), und dann sind solche Abkuerzungen das letzte, was man lesen moechte.
Man sollte sicherlich nicht zu viel in einzelne Tags reinquetschen, aber man sollte sich Gedanken daruerber machen, was in ein Tag mit rein muss und was besser in einem anderen Tag (welchem?) erfasst werden sollte. Insofern ist schon gar nicht schlecht, dass hier von allen Seiten Sonderfaelle eingeworfen werden.
Gruss
Torsten
Wie wollt ihr dann Fahrverbote für Spuren mappen? Da fielen mir zum Beispiel Dinge ein wie Mindesgeschwindigkeiten Lkw Überholverbote und sowas.
Und dann finde ich es auch besser wenn verschiedene Tags verwendet werden. Damit haben wir nämlich die Möglichkeit erst das Allgemeine und später die Details zu erfassen. Wenn alles in einem steht, dann wird das nicht nur ewig lang, was andere Programme vor Herausforderungen, sondern es müssen auch gleich alle Details erfasst werden. Was wiederum sehr abschreckend wird.
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.
Dasselbe gilt für Tramspuren und, obwohl ich es selbst in die Diskussion geworfen habe, wohl auch für Übergänge zwischen Spuren. Ich finde es schon wichtig, dass das Proposal flexibel genug ist, dass solche Dinge in Zukunft dargestellt werden können. Aber die Tags dafür müssen nicht alle schon im ersten Proposal enthalten sein.
Die Probleme mit Monstertags verstehe ich. Daher mal hier meine Variante des Vorschlags:
In lanes nur die Basisfunktion reinpacken, was man also auf jeden Fall wird erfassen wollen: Richtungen und Verkehrsmittelart (ohne Angabe generische "Auto"spur). Also etwa so:
lanes = s+r , s | s , bus
Sinnvoll erscheint mir die Verwendung von Trennzeichen (i.d.R. Kommas), weil dadurch problemlos neue Spurarten erfunden werden können, auch mit mehr als einem Buchstaben.
Außerdem finde ich sinnvoll, einen einzigen Richtungstrenner (das |) zu erlauben. Damit spart man sich nämlich bei einem Großteil der Straßen die Angabe der Fahrtrichtungen: Bei Rechtsverkehr gilt für Spuren links vom Richtungstrenner “backward”, rechts vom Richtungstrenner “forward”.
Nur bei ungewöhnlichen Sortierungen, oder Vorhandensein von in beide Richtungen nutzbaren oder alternierenden Spuren, würde man ein lanes:direction mit kommaseparierten Richtungsangaben für die einzelnen Spuren ergänzen.
Spurtrenner in ein eigenes Tag, statt die verschiedenen Arten als Symbole abbilden zu wollen. Außerdem als Wörter ausschreiben, weil es da zu viele denkbare Varianten gibt.
Meist sollte hier schon ein einzelnes separator = continuous / dashed / … reichen - das bezeichnet dann die Trennung zwischen den Fahrtrichtungen (das | im lanes-Tag).
Bei Bedarf kann aber hier natürlich auch wieder eine komplette Liste, also ein
lane_separators = guard_rail , dashed , continuous , dased , guard_rail
oder so stehen.
Beliebige sonstige Tags können über
lanes:Schlüssel = Wert1, Wert2, Wert3, …
bzw.
lane_separators:Schlüssel = Wert1, Wert2, Wert3, …
an die Spuren und Spurtrenner gehängt werden. Das können existierende Schlüssel sein - minspeed, surface, width. Es können auch für Spuren neu erfundene sein - “in dieser Spur verläuft eine Tram-Schiene” oder so. Aber diese Neuerfindungen muss man m.E. noch nicht gleich alle fertig mitliefern.
Wichtig finde ich, dass man auch nur das taggen muss, was man will. Den einen interessieren die Spuren, den nächsten die Radwege usw.
Also:
lanes: s+r, s | s, bus… wie tordanik beschrieb.
Beschreibt nur die Strasse selber.
cycleway:…
gibt schon links/rechts der Strasse inkl. Fahrtrichtung her.
footway:… gleiches Schema wie cycleway. (Hier kommen auch die Breiten und andere Eigenschaften rein.)
parkstreifen:… gibts noch nix? Oder hab ich nicht gefunden. Wenn nicht, sollte das geschaffen/erweitert werden, um auch links/rechts der Strasse, längs/quer, 60 Grad; Breite usw. eintragen zu können.
Und dann ein Tag, welches die Reihenfolge der Fahrbahnen festlegt, falls vom Standard abweichend.
Sowas wie:
path:order=footway,cycleway,parking box,street,parking box,cycleway,footway
Was auch default für Strassen innerorts wäre. Allerdings ist das nur die Reihenfolge für getaggte Wege. Gibts kein footway:…-Tag, hat die Strasse keinen Footway, auch wenn path:order eine mögliche Reihenfolge festlegt.
So kann jeder Taggen, was er will, ohne ein anderes Tag anfassen zu müssen, und es muss nix ein 2. mal getaggt werden, was bereits getaggt/tagbar ist.
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 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.
Walter
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.
Die Ührzeiten sind ein Ausnahmefall, die kommen normal nicht vor und dann ist es einfacher zu verstehen.
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.
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.
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.
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::opening_hours=*) haben auch ihre Nachteile. Da können wir drüber diskutieren.
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?
Wenn’s eine Tabelle wird, dann vielleicht besser auf einer Wiki-Seite. Bin gern dabei.
Wobei einige hier geäußerte Kriterien (Einfachkeit, Verständlichkeit, Fehleranfälligkeit) schwer messbar sein werden.
Weiter gehts mit dem lustigen Brainstorming zum Thema Spurmapping (aus der Mailing-List):
Edit: http://news.gmane.org/find-root.php?group=gmane.comp.gis.openstreetmap.region.de&article=91206
Hast du einen Link zum Archiv der Maillist?!
Etwa wie hier?
http://wiki.openstreetmap.org/wiki/Lane_tagging_comparison
Wenn ja, könnt ihr gerne eure Vorschläge ergänzen.
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.
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.
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
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.
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.
Das ist der Grund, warum ich zum Spurmapping überhaupt meinen Senf abgebe. Einen persönlichen Bedarf hab ich nicht.
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.
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.
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.
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.
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.
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
Den Vorschlag insgesamt finde ich verständlich, er wäre auch technisch umsetzbar. Zu einigen Aspekten habe ich trotzdem Kritik, teils auch Verbesserungsvorschläge.
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.
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.
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.
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.
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.
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.
Die Bezeichner sind mir bislang voellig egal, entscheidender ist es, erstmal eine Struktur fuer das Spurmapping auszuarbeiten.
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.
Das halte ich fuer die schlechteste aller moeglichen Loesungen.
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