Normale Kreuzungen

Ich würde hier ganz einfach beim Routing die Verbote oder detailliertere Information an einem Punkt vorziehen falls eine allgemeine Information dort vorliegt.
Eine solche Funktion in der Navigationssoftware ist ja schnell eingebaut.

Für Routing gibt es erst Mal keine Vorteile. Für Qualitätssicherung schon. Man kann auch ein Tool schreiben in dem man sofort sieht, ob diese Information vorhanden ist, oder nicht.

Vorschlag:
restriction=no kommt an den Kreuzungs-node. Sobald an der Kreuzung eine relation=restriction angelegt wird, benötigt diese den node für “via”. Das beißt sich mit restriction=no und josm oder QA können meckern.
Und dann wäre sicher auch ein Tool machbar, das nach dem Alter des keys restriction=no sucht und um Prüfung bittet, wenn das Setzen älter als ein Jahr wäre. Auch ein “restriction_check=dd.mm.jjjj” wäre denkbar. Dann müsste beim Prüfen nur das Datum aktualisiert werden.

Also ich sehe in der Neueinführung einer derartigen expliziten Kennzeichnung von Kreuzungen einen nicht gerechtfertigten Aufwand gegenüber dem erzielten Nutzen. Wie viele Kreuzungsknoten gibt es wohl? Und wie viele davon ohne Restriktioinen bräuchten eigentlich eine? Willst alle überprüfen (lassen)? Um entsprechenden Nutzen daraus zu ziehen, müßte erst sichergestellt sein, dass die Kennzeichnung möglichst flächendeckend umgesetzt ist. Und Glaubst Du, eine explizite Kennzeichnung ist zuverlässiger als die implizite durch das Fehlen der Kennzeichnung. Glaubst Du, jemand, der Abbiegespuren ohne irgendwelche bauliche Trennung anlegt, ohne die daraus folgenden Abbiegebeschränkungen anzulegen, macht sich Gedanken darüber, den restriction=no tag von einem Kreuzungsknoten zu entfernen?

Bevor man eine neue Baustelle aufmacht, sollte man den Aufwand lieber in die Korrektur fehlerhafter und Erfassung offensichtlich fehlender Restriktionen stecken. Das bringt meiner Ansicht nach mehr für die Zuverlässigkeit der Routingdaten. keepright oder http://map.comlu.com/?zoom=14&lat=50.1274&lon=8.70014&layer=Mapquest%20Open&overlays=FTT bieten gute Ansatzpunkte dazu.

Und man sollte nicht die Illusion vermitteln, eine 100% korrekte Datenbasis für das Routen bereitstellen und garantieren zu können, schon gar nicht unter den Bedingungen von OSM, wo im Prinzip jeder machen kann was er will.

Viele Grüße
Franz

Hallo Franz,
die Bedenken sind natürlich richtig und berechtigt. Wir haben Fehler. Wir haben unerfahrene Mapper. Die Karte wird mit der Zeit komplexer und für Newbies nicht leicht zu verstehen.
Keiner von uns einzeln kann wissen, ob´s angenommen wird. Wahrscheinlich nur von Einigen, der viele Leute in OSM haben unterschiedliche Meinungen was in OSM hineingehört und was nicht.
Die Tatsache, dass viele Sachen in OSM unfertig, fehlerhaft, unvollständig sind ist aber kein Grund um nicht nach vorne zu blicken.

Das Projekt lebt immer davon, dass neue Ideen kommen. Und es ist nicht so dass neue Ideen bei uns es leicht haben.

Das liefern auch die kommerziellen Anbieter nicht.
Stell Dir vor eine Zukunft in der Du in dem Auto ein Tool hast, mit dem man automatisch die Attributtierung der Kreuzungen hinkriegt, indem man eine Strecke einfach fährt.
Waze hat das vorgemacht. Nun gehört Waze dem Google. Aber die Technik ist trivial und nicht patentierbar.

Was spricht dafür die OSB Datenbank oder etwas ähnliches zu verwenden?
Für jede Kreuzung ohne Abbiegerelationen einen Bug und dann können die der Reihe nach geschlossen werden. Oder umgedreht.
Wenn sich die Kreuzung ändert wird der Bug wieder neu erstellt. So kannst du immer den genauen Stand ablesen, brauchst keine zusätzlichen Tags nur Mapper die es abarbeiten.

Ich sehe ihn sehr wohl. Denn eine Kennzeichnung etwa mit restrition=no sagt, dass hier jemand vor Ort geprüft hat, ob Abbiegebeschränkungen bestehen und dabei zu einem negativen Ergebnis kam. Für mich ist das eine wichtige Verbesserung der Datenqualität. Und wenn dieser thread einige Mapper bewegt, die Kreuzungen und Abzweigungen ihrer Gegend mal auf Abbiegebeschränkungen zu überprüfen, ist das ein Gewinn für OSM. Ich fange dann mal an.

edit:
Dies ist einer der wenigen Fälle, bei denen für mich value “no” wirklich Sinn macht, weil es eigentlich die positive Aussage “Abbiegen von jeder in jede Straße möglich” enthält.

#25:
Gute Idee viw!
Schöne Grüße,
Marek

Dem mag ich widersprechen. Denn dieser Wert ist einmal gesetzt und dann vergessen! Wenn später jemand diese Kreuzung anfässt wird der Wert nicht automatisch gelöscht. Eine externe Datenbank hätte den Charme das bei Änderungen automatisch der Status verfallen könnte und erneut geprüft werden müsste.

also mit diesem recht unnützen restriction=no kann ich mich auch nicht anfreunden. Wenn sowas denn sein muss, würde ich eher über turn:lanes gehen. Wenn die an die Kreuzung führenden Straßen bspw ein (lanes:forward=1) + turn:lane:forward=left;through;right haben, weiß man auch, dass man in alle Richtungen abbiegen kann und das sich jemand das angeschaut hat. Und das ganze hätte dann noch den praktischen Nutzen, dass das für einen Spurassistenten genutzt werden kann

Es ist richtig SunCobalt. Am liebsten hätte ich auch alles sauber über die Lanes gelöst denn die Lösung ist eindeutig.
Ich denke da aber an die Masse der User die es so einfach brauchen wie es nur geht.
Für viele ist (leider) die Lösung mit lanes zu schwierig bzw langweilig denn es bedeutet viermal die Eintragung relativ langer Strings.
ich würe es tun, Du und vielleicht 20 weitere Turbomapper ja auch. Die Masse eher weniger, solange wir kein Editor haben, der die Sache vereinfacht.
Früher oder später werden wir wohl eine solche Lösung haben und DANN werde ich diese Lösung bevorzugen denn sie ist ja allgemein und deckt alle erdenklichen Fälle ab.

Mit dem recht stupiden restriction=no, kann man hingegen zügig (selbst wenn man ein Wenig schwer von Begriff ist) Kreuzungen taggen von denen man weiß dass sie Standard sind. Sprich (gefühlt) die Mehrheit der Kreuzungen auf der Karte.

Viele Grüße!
Marek

Mein, zugegeben etwas scharfer Senf zu diesem Thema:

Sind schon alle Sackerl-fürs-Gackerl-Spender gemappt?

Das entspricht aber nicht der Wiki, wie ich parallel schon erwähnte http://forum.openstreetmap.org/viewtopic.php?pid=350511#p350511
Da die Spuren nicht entsprechend gekennzeichnet sind, gehört da auch kein "turn:lane:forward=left;through;right " hin. Und was bringt dir ein Spurassistent auf einer Spur für alle Richtungen. Die Information habe ich auch, wenn ich aus der Frontscheibe oder über den Lenker schaue, was dann auch noch den Vorteil hat, dass ich das verkehrsgeschehen vor mir im Auge behalte.

Nö, warum auch? Das hier ist ja nicht die “offene Sackerlkarte” sondern die “offene Straßenkarte” und entsprechend setze ich meine Prioritäten.

OT an:
Und wenn ich mit meinem Hunde eine Runde drehe, weiß ich wo die Dinger stehen oder habe in fremden Terrain ein paar Tüten im Hosensackerl. Glaubt hier etwa jemand, irgendein Hundebesitzer würde seine Spaziergänge in OSM unter Berücksichtigung der Hundekottütenspender am Wegesrand optimieren?
OT aus:

Vergessen muss nicht sein, wenn man wie hier: http://forum.openstreetmap.org/viewtopic.php?id=22010&p=1
von mir vorgeschlagen vorgeht indem die mapping-tools entsprechende Prüfungen und Warnungen ausführen.
Aber ich bestehe nicht auf restriction=no als tag, wenn QA gemäß deinem Vorschlag außerhalb der Datenbank etwa über OSB oder map notes machbar ist und allgemein akzeptiert wird. Ich kenne die junctions, an denen ich das schon gesetzt habe und kann das schnell wieder löschen.

Du gehst davon aus das jeder editor das unterstützt. Nur weil es josm kann macht es aber ID nicht auch. Und jeder neue Editro wird eigene Prioritäten setzen, daher denke ich das der externe Ansatz mit eigener Kontrolle der einzig mögliche ist. Man könnte Editoren dazu weiterentwickeln diese Änderung vielleicht gleich mit zu bestätigen, so dass dann kein neuer Bug entsteht. aber ich würde immer ein false positive einbauen, weil niemand weiß wer der Zuspieler der Daten ist.

Wenn es dann außerhalb der Datenbank und ohne Editoren-Unterstützung sein soll, bitte ich um Vorschläge, wer das wie umsetzen kann und umsetzen wird.

iD kann man bei derartigen Überlegungen getrost außen vor lassen. Erstens richtet er sich ausdrücklich an Anfänger/Unbedarfte, die in der Regel von Abbiegebeschränkungen noch nie gehört haben. Zweitens erlaubt iD gar nicht die Bearbeitung von Relationen (außer Multipolygonen, diese aber auch nur implizit durch einen eigenen Flächentyp). Und drittens haben die Entwickler mehrfach klar gesagt, daß sie ihre Nutzer nicht mit Warnungen behelligen wollen. Wenn sie das schon nicht bei fundamentalen Fehlern oder offensichtlichen Fehlbedienungen tun, dann bei fortgeschrittenen Themen wie dem hier in Rede stehenden (das sowieso nur die Krauts interessiert) erst recht nicht. Egal, wie eine mögliche interne oder externe QS aussehen soll: Unterstützung durch JOSM reicht völlig.

Wenn die Aussage, daß QS-orientierte Metainformationen in der OSM-Datenbank nicht gepflegt werden, noch eines Beweises bedurfte, hier ist einer: http://www.openstreetmap.org/browse/way/25628628
Das Tag “mapping_status = incomplete” ist trotz diverser zwischenzeitlicher Bearbeitungen seit 2008 unverändert. Die Mapper werden es nicht bemerkt haben oder sie konnten nichts damit anfangen, oder sie wußten nicht, was unvollständig sein soll und haben es sicherheitshalber belassen. Um zumindest das letzte Problem zu vermeiden, würde ich dazu raten, falls eine Information “diese Kreuzung hat keine Abbiegebeschränkungen” in der DB hinterlegt werden soll, hierfür ein möglichst “sprechendes” Tag zu verwenden. crossing=regular war viel zu generisch und stand außerdem in Konflikt mit existierenden crossing-Tags, aber auch restriction=no wird der gemeine Mapper nicht verstehen.

Stimmt schon. Wie würdest Du das machen?

Grüße,
Marek

Wenn ich eine bessere Idee hätte, hätte ich sie schon hinausposaunt :wink:
Vielleicht etwas in der Richtung turns_unrestricted=yes oder all_directions_allowed=yes. (Nur als Ansatz zum Weiterdenken - aber eine positive Semantik mit “yes” gefällt mir generell besser.)

Wir haben hier einige schlaue Köpfe. Mal abwarten.
Ich habe schon vor Jahren festgestellt dass einige User hier deutlich bessere Synatax Vorschläge machen als ich. (schluchz) . :wink: