Das gibt es in Celle auch. Hier sichtbar: Die komisch gestrichelte Spur in der Mitte ist für beide Richtungen eine Linksabbiegerspur.
Es gibt in Deutschland nicht nur Abbiegespuren, sondern in Berlin auch geradeausspuren, welche Vormittags in die Stadt und abendes wieder aus der Stadt führen. Gekennzeichnet wird das durch sogenannte Dauerlichtzeichen.
Genauso ein Problem wie bei temporären Geschwindigkeitsbeschränkungen, die mit maxspeed=signals getaggt werden, aber dann natürlich keinen Informationsgehalt haben.
Ich würde vorschlagen, alle Anforderungen einmal aufzulisten.
Dann sollten wir verschiedene Proposals bewerten mit Vor-Nachteilen, bzw. ob alle Anforderungen erfüllt sind.
lanes:backward=4 + lanes:forward=4 ist auf jeden Fall zu wenig, da nicht klar ist, welche Spuren vorwärts gehen.
lanes=bbbfff|bf wäre besser, hier ist die Sperrlinie erkennbar und auch die abgesetzten Spuren.
lanes=bbaff könnte für eine Alternate-Spur stehen, die in beiden Richtungen befahrbar ist.
lanes=bbtff wäre dann eine timely-alternate Spur, die zeitabhängig umgeschaltet wird.
lanes:car=bbbfff|xx könnte Autospuren kennzeichnen,
lanes:tram=xxxxxx|bf wäre für die Straßenbahn.
Bevor wir zu viele Sonderzeichen wie \ | / usw definieren,
sollte ein Programmierer eines Renderers sein Statement abgeben,
ob hier Probleme bei der Auswertung zu erwarten sind.
Also fangen wir einfach mal mit den Anforderungen an.
Für jede Spur sollte klar sein:
*) in welche Richtung die Spur führt: forward, backward, Abbiegespur in beide Richtungen benutzbar, zeitabhängige Umschaltung
*) wer die spur benutzen darf (bicycle, car, tram, psv, taxi, …)
*) Abgrenzung zu Nachbarspuren: Sperrlinie, Sperrlinie von links/rechts überfahrbar, …
Walter
Es wäre schön, wenn auch der Seitenstreifen berücksichtigt werden könnte: Zum Einen ist er auf Landstraßen für Fahrradfahrer interessant (bzw. auch das Nichtvorhandensein), zum Anderen wird er machmal auf Autobahnen zur Benutzung freigegeben (temporärer Standstreifen).
Es wäre schön, wenn auch der Seitenstreifen berücksichtigt werden könnte: Zum Einen ist er auf Landstraßen für Fahrradfahrer interessant (bzw. auch das Nichtvorhandensein), zum Anderen wird er machmal auf Autobahnen zur Benutzung freigegeben (temporärer Standstreifen).
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
Es gibt in Deutschland nicht nur Abbiegespuren, sondern in Berlin auch geradeausspuren, welche Vormittags in die Stadt und abendes wieder aus der Stadt führen. Gekennzeichnet wird das durch sogenannte Dauerlichtzeichen.
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.
Es wäre schön, wenn auch der Seitenstreifen berücksichtigt werden könnte
Was ist das genau?
faellt mir da spontan auch noch ein Parkstreifen ein.
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
Ich würde vorschlagen, alle Anforderungen einmal aufzulisten.
[…]
Also fangen wir einfach mal mit den Anforderungen an.Für jede Spur sollte klar sein:
*) in welche Richtung die Spur führt: forward, backward, Abbiegespur in beide Richtungen benutzbar, zeitabhängige Umschaltung
*) wer die spur benutzen darf (bicycle, car, tram, psv, taxi, …)
*) Abgrenzung zu Nachbarspuren: Sperrlinie, Sperrlinie von links/rechts überfahrbar, …
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.
lanes=bbbfff|bf wäre besser, hier ist die Sperrlinie erkennbar und auch die abgesetzten Spuren.
lanes=bbaff könnte für eine Alternate-Spur stehen, die in beiden Richtungen befahrbar ist.
lanes=bbtff wäre dann eine timely-alternate Spur, die zeitabhängig umgeschaltet wird.lanes:car=bbbfff|xx könnte Autospuren kennzeichnen,
lanes:tram=xxxxxx|bf wäre für die Straßenbahn.
Ich glaub, mit 1 Buchstabe pro Spur kommen wir nicht durch. Darum hab ich die Leitlinien in meinem Vorschlag explizit als Beistriche vorgesehen.
Bevor wir zu viele Sonderzeichen wie \ | / usw definieren,
sollte ein Programmierer eines Renderers sein Statement abgeben,
ob hier Probleme bei der Auswertung zu erwarten sind.
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.
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…
+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.
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.
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.
- 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.
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.
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.
Die Probleme mit Monstertags verstehe ich. Daher mal hier meine Variante des Vorschlags:
- Spuren
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
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.
- “Any tags you like”
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.
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.
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.
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.
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::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?
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.
Weiter gehts mit dem lustigen Brainstorming zum Thema Spurmapping (aus der Mailing-List):
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 SpurverlaufWer 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 besserDas 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?group=gmane.comp.gis.openstreetmap.region.de&article=91206
Weiter gehts mit dem lustigen Brainstorming zum Thema Spurmapping (aus der Mailing-List):
Hast du einen Link zum Archiv der Maillist?!
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_tagging_comparison
Wenn ja, könnt ihr gerne eure Vorschläge ergänzen.
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.
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