Ich weiß zwar nicht, ob das geht, aber es würde doch Sinn machen, als DB-externes Tool http://map.comlu.com/ , welches sich ja schon um vorhandene und falsche turn-restrictions kümmert, um eine Anzeige der Kreuzungen/Verzweigungen ohne turn-restrictions zu erweitern.
Im ersten Schritt wäre da sicher die Beschränkung auf junctions an oder zwischen primary und secondary sinvoll, damit die Karte nicht überflutet wird. Bei diesen wirken sich falsche routing-Anweisungen ggf. mit kilometerweiten Umwegen aus. Bei tertiary und darunter sind es eher kleine Umwege, falls turn:lanes überhaupt existieren, und motorway und trunk dürften wohl fast vollständig mit restrictions oder turn:lanes erfasst sein.
Wer kennt http://www.openstreetmap.org/user/Zartbitter, den Schaffer der restriction-map, und könnte den mal fragen? Ansonsten mache ich es heute abend.
Ich begrüße den Vorschlag von hudygurdyman. Idealerweise könnte man auf der Karte des Benutzers Zartbitter in dem nach Klick erscheinenden Popup jeweils direkt mit nur einem Klick die Kreuzung als “Standard” markieren. Der Rest (Upload des Tags in die OSM-Datenbank) würde idealerweise automatisiert im Hintergrund (als Changeset zusammengefasst) geschehen. Dies würde es natürlich notwendig machen, dass die Karte die OSM-Benutzerdaten erhält. Oder geht so etwas auch elegant á la single-sign-on?
Ich!
Die Karte arbeitet aber ohne eigene DB, die Daten werden per Overpass geholt und im Browser analysiert. Ein Check auf Kreuzungen, Beinahe-Kreuzungen, Überschneidungen ohne Schnittpunkt und was einem sonst noch so einfallen könnte ist damit nicht in (von mir) vertretbarem Aufwand machbar. Eine direkte Edit-Funktion würde ich auch ablehnen. Aber wenn sich das einer antun will: Die Sourcen sind in der Seite, auf Anfrage gibt es die auch als Archiv.
Aber warum eigentlich das ganze?
Um eine Garantie abgeben zu können?
Das können wir aber nicht, egal, was für Tags und Mechanismen wir uns einfallen lassen.
Das “System Realität” ist mit dem “System OSM” nur locker über uns Mapper gekoppelt. Ein Tag für eine beliebige Vollständigkeit einzuführen, bedeutet nicht, damit etwas garantieren zu können. Es bedeutet nur, dass da noch ein Tag ist, das man beachten kann, aber nicht muss, das aber ggf. zusätzlich kontrolliert werden muss, eventuell ohne dass die meisten dafür das Wissen haben. Wenn ein Mapper etwas in OSM einträgt, ist es drin. Wenn nicht, dann nicht. Wenn sich in einem System etwas ändert, ändert scih erstmal nichts im anderen System - in beide Richtungen 
Ist eine Kreuzung ohne Linksabbiegeverbot gemappt, würde ich die im Routing auch so bewerten. Tritt ein Fehler auf, d.h. es meldet jemand, man dürfe da nicht links abbiegen, dann muss das eben geprüft und ggf korrigiert werden. Das kann auch bei einer Kreuzung passieren, bei der irgendjemand restriction=no o.ä. gemappt hat - aus gutem Glauben, auf einer Fehlinterpretation basierend, auf alten Informationen aufbauend oder aus der Laune heraus, ein nerviges QA-Tool ruhigzustellen.
Daher glaube ich, so ein “Garantie-Tag” wäre nur eine Leiche im Datenbestand, die nicht das halten kann, was sie verspricht.
Also gehen wir mal davon aus, dass wir derzeit eine Reihe von Kreuzungen haben, die entweder aus Luftbildern erfasst wurden, oder noch zu Zeiten als gar nicht an Abbiegerestrictionen zu denken war. Diese Kreuzungen fallen derzeit keinem auf.
Was marek jetzt gerne hätte wäre eine besondere Aufmerksamkeit für diese Kreuzungen und damit die Mapper auch für Dinge sensibilisieren die vielleicht vor der Haustür noch nicht vollständig sind. Diese Abbiegeverbote sind ja auch relevant für Routingapps.
Schon bei anderen Themen gab es solche Aufrufe/Aktionen bei OSM. Sei es der Import von Buslinien in Köln/Bonn oder von Fialen eines Drogeriemarktes.
Hallo Zartbitter!
Danke erst Mal für Deine hilfreiche Karte. Ich kannte sie leider nicht, informierte auch die polnische Community die sie ebenfalls hilfreich findet.
Vielleicht habe ich ein falsches Wort gewählt. eine Garantie können wir im Leben nur für den Tod und Steuer haben.
Auch das “System Realität” der Kartenhersteller bildet die Realität ab, die man zu dem Zeitpunkt der Datenerhebung erfasst hat.
Es ist also kein Garantie Tag.
Es soll nicht mehr und nicht weniger aussagen als: Ich weiß,es ist eine Standard Kreuzung, alle Manöver sind erlaubt.
Für einen User vor-Ort der die Relationen nicht mag bzw nicht versteht, gerne aber ein Punkt mit Attribut setzt, ist es eine Möglichkeit zu zeigen: “Ich weiß, dass es eine Standard Kreuzung ist.”
Als die OSM entstand, war die Situation anders: Man hat die Gegend erkundet, sammelte Spuren und zeichnete das, was man vor-Ort gesehen hat.
Nun haben wir Bing und Vieles wird aus dem Luftbild gezeichnet. Sehr viele Mapper verzichten leider auf den Tag “source=bing” so dass man nicht mehr feststellen kann, ob die Karte keine Abbiegerelationen hat weil das so ist und es ist ja eine bewusste Entscheidung von einem Mapper, oder haben wir hier mit einem Kartenmaterial zu tun der von einem User abgemalt wurde, von dem zweiten kam zum Beispiel der Name hinzu keiner hat sich aber um die Abbiegerelationen gekümmert.
Grüße,
Marek
Das finde ich auch nicht nur in Ordnung, sondern begrüßenswert. Eine Aktion mit einem QA-Tool, das nicht überprüfte Kreuzungen hervorhebt, wäre eine gute Sache. Was ich aber für falsch halte, ist, diese momentane Überprüfung mit einem Tag in OSM festzuschreiben. Das Tag bleibt und bleibt und bleibt. Da muss dann schon ein ganzes Stadtviertel abgerissen werden, bevor sich wieder jemand um dieses Tag kümmert und damit ist die Aussagekraft des Tags sehr begrenzt.
Da sind wie einer Meinung. Mir ist egal, wie wir zu diesem Ziel kommen solange wir eint geeignete Technik dafür finden.
Nur:wie schaffen wir das?
Nach welchen Kriterien unterscheiden wir zwischen geprüft und ungeprüft?
Ich schlug nur deswegen ein Tagging vor weil ich momentan keine bessere Lösung habe.
Bin aber für alle Schandtaten offen solange sie uns zum Ziel führen
Nach unruhiger Nacht zur Lösung des Problems ein paar Überlegungen:
Sollten wir uns für restriction=no oder sonst irgendeinen tag am Kreuzungs-/Verbindungs-Node entscheiden, gibt es vielleicht doch eine Möglichkeit mit Hilfe von Zartbitters Karte (Danke für deine erläuternden Worte) etwas hin zu bekommen. Eine Routine prüft, wenn der tag restriction=no gesetzt ist, ob einer der dort verbundenen ways turn:lanes-tags enthält oder der node Bestandteil einer relation=restriction als via-node ist. In diesem Fall gibt es eine Fehlermeldung aus, dass restriction=no entfernt werden muss.
Eine andere Variante wäre ein Bot, der in diesen Fällen restriction=no rauswirft.
Des weiteren, kann man davon ausgehen, dass mindestens an Kreuzungen oder Abzweigungen, in die Straßen mit getrennten Fahrbahnen je Richtung einmünden, richtungsbezogene Fahrspuren und Abbiegebeschränkungen am wahrscheinlichsten sind. Deshalb wäre es doch sinnvoll, mindestens diese mit einer Auforderung “Check for turnlanes or restrictions” zu versehen, wenn restrictions=no nicht gesetzt ist und keine ways mit turn:lanes-tags an dem jeweiligen Verbindungs-node liegen oder keine relation=restriction dem jeweiligen Verbindungs-node als via beinhalten. So würden wir QA für die wichtigsten kritischen Kreuzungen weitestgehend möglich machen und alle router hätten was davon.
Leider bin ich des Programmierens unkundig 
edit: Dreckfuhler-Berüchtigung
Beide Überlegungen finde ich super.
Lieber Zartbitter, wäre es machbar?
Viele Grüße,
Marek
Ich finde ebenfalls, dass das (wenn überhaupt) in einem externen QS-Tool mit eigener DB sein sollte.
Ideen hätte ich schon, aber nicht die Resourcen dazu. Vor allem kann ich mir nicht die nötige Zeit nehmen. Aber ich kann meine Ideen ja mal skizzieren:
-
Es muss eine Abfragemöglichkeit für Kreuzungen geben, d.h. ein Programm fragt eine Boundingbox ab und bekommt alle enthaltenen (relvanten) Kreuzungsnodes. Wie das realisierbar ist, ist komplett offen. Ggf. über spatiale DB mit planet-Import, laufender Aktualisierung und vorbereiteten Kreuzungs-Procedures?
-
Diese Nodes werden auf einer Karte visualisiert.
-
Ein User muss sagen können, dass mehrere Nodes nur eine Kreuzung beschreiben. Er kann mehrere Nodes selektieren und zusammenfassen. Denn je nach Mapping kann eine Kreuzung im RL ziemlich viele Way-Way-Kreuzungen in OSM haben (getrennte Ways pro Fahrtrichtung, extra gemappte Abbiegespuren). Diese Zusammenfassung muss extra gespeichert werden (als 1:N-Zuordnung von Kreuzung-Id zu Node-Id außerhalb von OSM).
-
Eine Zusammenfassung von Nodes als einzige Kreuzung ersetzt in der Visualisierung deren Einzelnodes
-
Diese Zusammenfassungen müssen vom User wieder aufgelöst werden können.
-
Ein User kann Nodes oder Kreuzungen (im Sinne von Zusammenfassungen von Nodes) als “vollständig erfasst” markieren. Das muß dann so abgespeichert werden (Node-Ids und Kreuzungs-Id mit Status außerhalb von OSM) => Das ist die Info, die m.k. haben will
-
Die Karte hat getrennte Overlays für unbearbeite Kreuzungen, bearbeitete Kreuzungen und was einem sonst noch so einfällt.
-
Batch-Aktualisierung der außerhalb von OSM gespeicherten Daten: Periodisch müssen markierte Nodes bzw. bei Zusammenfassungen alle zugehörigen Nodes auf Änderung (?) und Löschung geprüft werden. Ggf. muss das “vollständig erfasst”-Merkmal gelöscht werden, so dass die Kreuzung wieder als neu zu prüfend gilt. Ggf. muss auch eine Zusammenfassung von Nodes zu einer Kreuzung automatisch aufgehoben werden. Ziel ist, dass Node-Änderungen (Lage?) oder Node-Löschungen (gemeint ist: die Node ist keine Kreuzungs-Node mehr, ist also aus der Menge der Kreuzungs-Nodes “gelöscht”) dazu führen, dass die Kreuzung wieder als ungeprüft gilt.
So in der Art stelle ich mir in einer Mischung aus Ablauf, Datenhaltung und GUI ein QA-Tool vor, das (wenn es mal laufen sollte) automatisch halbwegs aktuell alle Kreuzungen mit der Info, ob vollständig erfasst oder nicht, in einer eigenen DB hält, auf einer Karte visualisiert und auf Änderungen in den OSM-Daten reagiert.
Grundvoraussetzung ist aber eine Möglichkeit, mit möglichst aktuellen Daten die Kreuzungsnodes geliefert zu bekommen.
Ein Bot ist immer die letzte Möglichkeit. Wenn nicht sogar die allerletzte.
Ist nicht so einfach, da müsste schon beim Holen der Daten per Overpass komplett anders vorgegangen werden, da nur die Ways gelesen werden, die auch member in einer restriction sind. Es wird also nur ein Teil der an einer Kreuzung befindlichen Wege gelesen. Außerdem hätte man gar keine Lösung für Kreuzungen, bei denen eine Abbiegespur als extra way (zu Recht oder auch nicht) gemappt ist.
Hallo Zartbitter, ich denke die Institution mit der ich rede könnte da weiter mit Ressourcen helfen.
Durfte man auf Deinen Rat zählen?
Klug schwätzen kann ich immer
Aber Zeit werde ich nur sehr begrenzt haben.
Na ja, wenn jemand diese Idee umsetzen sollte, dann wird er ja höchsten einige Male mit Dir telefonieren / mailen. Das war´s mal dann.
Genau! Ich empfehle da für den letzten Schritt (Auswertung) die relativ neue Unterstützung von Topologieen in PostGis 2.x Diese Erweiterung ist exakt für so etwas entwickelt worden.
Genau!
Gelb: 3-Way (T-Stücke)
Grün: 4-Way
Blau: 5 und mehr Ways (keine Treffer in diesem Ausschnitt)
Die ist allerdings nur eine kleine Machbarkeitsstudie, da ich mich immer schon mal mit PostGis-Topologien beschäftigen wollte. Damit Ihr mal einen kleinen Eindruck bekommt, wie wenig an Befehlen man dafür benötigt:
set search_path to topology,public;
SELECT DropTopology('streets');
SELECT CreateTopology('streets',find_srid('public', 'ways', 'linestring'), 0.00001);
-- mach lokale kopie der ways.
create table streets.oways as (
select * from ways
where bbox && st_MakeEnvelope(7.06, 50.7, 7.09, 50.75)
and tags->'highway' in('primary','secondary','tertiary')
);
vacuum full analyze streets.oways;
-- Create Collumn topogeom in ways
SELECT AddTopoGeometryColumn('streets', 'streets', 'oways', 'topogeom', 'LINE');
-- packe linestrings rein
UPDATE streets.oways SET topogeom = toTopoGeom(linestring, 'streets', 1);
-- Kreuzungen mit 3 oder mehr Strassen
create or replace view streets.v_crossings(node_id,geom,cnt) as
select node_id,geom,cnt
from (select node_id, n.geom, count(node_id) cnt
from streets.node n, streets.edge_data e
where node_id=start_node
or node_id=end_node
group by node_id) foo
where cnt > 2;
Die ersten Statements sind die Vorbereitung, die nur einmal laufen muß. Die Auswertung ist in den letzten 8 Zeilen. Mehr braucht man nicht.
Das Ganze per QGIS visualisiert - ginge aber auch mit OL&Co.
Gruss
walter
p.s. ich werde das aber wohl nicht zu einem Projekt machen. Zumindest nicht kurzfristig.
Hallo
@Zartbitter:
Getrennte Abbiegespuren (ergeben sich ja oft schon durch Verkehrsinseln) sind in der Regel ein Indiz dafür, dass man an den diversen Kreuzungsknoten nicht überall hin abbiegen darf.
Bei einer Abbiegespur nach rechts, darf man in der Regel nicht mehr nach links zurück in die kreuzende Straße abbiegen. Entsprechend darf man an der Geradeaus-Spur in der Regel nicht mehr nach rechts in die kreuzende Straße abbiegen.
Edbert (EvanE)
Schon klar. In der Regel gilt das. Aber irgendwo lauert bestimmt eine nicht regelkonforme Kreuzung. Und außerdem hat man dabei noch keine Aussage über die restlichen im Routinggraphen möglichen Verbindungen. Die Kreuzung muss also trotzdem überprüft werden, egal ob man für einen Teil der Verbindungen wohlüberlegte Annahmen treffen kann oder nicht.
Für die Überprüfung einer Gesamtkreuzung aus mehreren Kreuzungspunkten hast du natürlich Recht.
Trotzdem sind Kreuzungen aus mehreren Kreuzungspunkten in der Regel so, dass man nicht überall hin abbiegen darf.
Sei es durch Einbahnstraßen z.B. bei getrennten Richtungsfahrbahnen oder durch Abbiegespuren.
Edbert (EvanE)
Das stimmt ja alles, aber ich verstehe nicht, was das damit zu tun hat, ob die Kreuzung geprüft werden muss oder nicht, denn dafür ist es nicht hinreichend: Entweder sind keine Restrictions gemappt, dann muss geprüft werden, welche wirklich vorhanden sind. Sind schon Restictions gemappt, muss geprüft werden, ob sie vollständig und korrekt gemappt sind. Diese Info bringt also keinen Mehrwert.
Erinnert mich an sowas: Autofahrer hat sich verfahren und fragt einen Passanten “Wo bin ich?”. Passant antwortet “In einem Auto”. 
Die Antwort ist korrekt, bringt aber die Problemlösung keinen Schritt weiter
Man sieht einer Kreuzung in den Daten nicht an, ob sie korrekt ist, egal wie detailreich oder simpel sie gemappt ist. Das gilt nicht nur für mehrspurige mit Abbiegespuren, sondern auch für ganz einfache. Ich habe eine T-Kreuzung gemappt, wie sie simpler nicht sein kann, nur darf man aus einem Ast nicht links abbiegen. Sowas erkennt man weder an den Daten noch am Luftbild.
Kurz: Aus den Daten kann man nicht folgern, ob eine Kreuzung korrekt (in Bezug auf Routing) gemappt ist. Deshalb müssen von vornherein alle Kreuzungen geprüft werden, wenn man die Abbiegevorschriften vollständig haben will.
Ich hätte mal eine Verständnissfrage:
http://www.openstreetmap.org/?lat=52.507667&lon=13.450262&zoom=18&layers=M
Kreuzung Warschauer Ecke Revaler Straße von Süden kommend. Es gibt zwar kein Verkehrsschild was das abbiegen verbietet, aber nur zwei Geradeausstreifen so wie einen für Rechtsabbieger
Außerdem ist die Revaler Straße von westen auch noch Einbahnstraße. Muss an solchen Kreuzungen etwas unternommen werden oder sind die so ok?