Wird sowas nicht schon durch OSMI abgedeckt?
http://tools.geofabrik.de/osmi/?view=areas&lon=8.95517&lat=48.66815&zoom=11&opacity=0.80&overlays=duplicate_node,single_node_in_way,duplicate_segment,way_in_multiple_rings,intersection,intersecting_segments,ring_not_closed,touching_rings,role_should_be_inner,role_should_be_outer,inner_with_same_tags
Was ?
Nächste Runde…
weil der osm-planet seit 2 Wochen klemmt, habe ich die Liste der “suspects” (im Sinne von offenen Enden für >= secondary) auf Basis des germany-extracts (geofabrik) refreshed.
Das auf einem extrakt zu rechnen hat den Nachteil, dass dabei zusätzlich offene Enden entstehen an der Grenze des extrakt-polygons. Die liegen aber alle im Ausland.
Also in der folgenden Liste die ausländischen suspects nicht weiter betrachten:
http://brouter.de:443/brouter/suspects
da ist ein Rechteck im Westen Deutschlands (von 48/7 bis 55/10 ) flächendeckend bearbeitet. Der wilde Osten fängt aber schon am 10. Längengrad an. Und im äussersten Süden <48 Grad sind auch noch issues.
Es gab in der Vorgängerliste eine Klasse von Fehlern mit Turn-Restrictions, bei dem das from-Member den via-Node bicht beinhaltet - das war ein Fehler in brouter, weil diese TRs sind ja definitiv kaputt - solche DInger sollten jetzt nicht mehr dabei sein.
Was noch bisschen blöd ist, dass Knoten-Fehler oft 3-mal erscheinen, für den Knoten selbst und die beidern blockierten Wege.
Beim Thema cycle_barrier oder lift_gate auf >=secondary glaube ich mittlerweile auch, dass man diesen Krieg nicht gewinnen kann, ujnd ich die Routing-Regel anpassen muss. Noch sind diese Dinger aber in der Liste.
Also, wer will noch mal, wer hat nich nicht? Mit paar Mitmachern ist die Liste bald leer.
Wie beschrieben ist da eine Abfrage drin, ob vor “mark as false positive” mindestens 5 Routing Requests in der Gegend gemacht wurden. War es das?
Danke an alle Mitkämpfer
o.k. geht besser, jetzt mit der administrativen Grenze für Deutschland gefiltert.
http://brouter.de:443/brouter/suspects
Und auch nurnoch 300 suspects übrig…
Hallo,
Zwei kleine, einfach zu implementierende Usability-Verbesserungsvorschläge hätte ich noch:
-
Bei den Links zu osm.org kannst du auch einen Marker setzen, hier ein Beispiel: http://www.openstreetmap.org/?mlat=49.86300&mlon=7.80429#map=19/49.86300/7.80429&layers=N
-
Du könntest einen Link ergänzen, der die Stelle im JOSM (über Remote-Control) öffnet. Das wäre dann z.B. http://osmose.openstreetmap.fr/de/josm_proxy?load_and_zoom?left=8.394656699999999&bottom=48.7741227&right=8.3986567&top=48.778122700000004&select=node1268354443,way111295201
Den Parameter select kannst du weglassen, wenn du keine Node-ID zur Verfügung hast.
Viele Grüße
Michael
Soll man die nach Korrektur confirmen? Ging da irgendwie nicht … Da habe ich bissele gesucht, bis ich die Ursache fand in einer restriction: no statt only bei straight_on …
Das sieht nach Unfall bei Inspector-Korrektur aus, aber das sollte sich ein chroniklesegewandterer anschauen, was da hingehört …
ja bitte. “mark as confirmed” und dann “mark as fixed”
fuer “mark as a confirmed issue” fordert er nur einen Routing-Request in der Gegend, aber ganz ohne da Routing-Versuche gemacht zu haben, kommt eine Fehlermeldung.
Das soll ein Spamschutz sein, oder auch ein Schutz vor Such-Index-Robotern, die ja theoreitsch bei so einer einfachen HTML-ANwendung alle suspects verschwinden lassen können…
Erledigt ( siehe http://brouter.de:443/brouter/suspects )
Mit JOSM hast Du mich fast erwischt, hab’ JOSM bisher nicht verwendet, aber ich hab’s hingekriegt und es funktioniert tatsächlich mit remote control. Hab versucht, den Zoom ähnlich einzustellen wie in dem BRouter-Web view.
Danke für die Tipps,
Gruss, Arndt
Hi Peter!
Deine 1) ist definitiv ein Fehler!
Wie ich die Situation deute ist die alte B311 einer Umgehung gewichen. Damit vierliert sie aber auch die Eigenschaft als highway=primary! Und das ref=B 311 dürfte auch nicht mehr korrekt sein. Wenn du diese beiden Punkte korrigierst, wird der Fehler auch aus der Liste verschwinden.
Zur 2) hätte ich die Frage, wie lange diese Baustelle existiert, und wer sich um die aktualität der Daten in dem Bereich kümmert!
Viele Grüße,
hsimpson
Zu 1.) Die Ortsumgehung von Unlingen (neue B 311) ist seit einigen Wochen auf einer Teilstrecke in Betrieb. Der Rest soll Mitte kommender Woche fertiggestellt und freigegeben werden. Dann wird auch die alte B 311 auf 3,5 m verschmälert und als Feldweg dienen. Ich werde mir das mal in den nächsten Tagen vor Ort ansehen und danach OSM aktualisieren.
Zu 2.) Die L 280 ist (fast) fertig und soll am kommenden Montag für den Verkehr freigegeben werden. Das schaue ich mit vorraussichtlich am Sonntag mal an.
Grüße aus Oberschwaben
Peter
Geht nicht.
*marking confirmed requires at least 2 recent nearby waypoints from BRouter-Web, found: 0 *
Bei mir gleicher Fehler.
Die Liste ist jetzt erstmal leer (bis auf so einen TR-verkorsten Anschluss in Pirna, der mir zu schwierig ist)
Lessons learned:
BRouter macht bei den access-tags für die Autoprofile eine positive Prüfung (access ?= |yes|permissive|designated|destination )
Das ist deswegen gut, weil ein Routingfehler, der in eine Sackgasse führt als sehr viel schwerwiegender empfunden wird als einer, der einfach nur nicht den besten Weg gefunden hat (und nur darum gehts ja hier in diesem Thread)
Es ist aber auch schwierig, von access=Kraftverkehr, allowed, yes|no|yes, request, etc war alles dabei.
Speziell die falschen lane-taggings (access=yes|no|yes) sind von der Menge her ein echtes Problem.
Die impliziten Sperren speziell bei barrier=lift_gate|cycle_barrier auch.
Ansonsten waren es (nach meiner Fehler-Korrektur in BRouter) nur relativ wenig TR-Fehler.
Relativ viele unvollständig zurueckgebaute Sperren. Irgendwo ein Ministueck wird da übersehen. Ich hab den Eindruck gewonnen, dass die visuelle Prüfung von temporären Sperren ziemlich gut funktioniert. Also wenn da eine Baustelle auf der Karte klar ersichtlich ist, dann ist die auch fast immer richtig. Wenn aber jemand eine Baustelle irgendwo nur funktional abgebildet hat, durch einen Sperrknoten oder eine unsichtbare Wegsperre (z.B. vehicle=no), dann setzt die schnell mal Staub an.
3 Fälle hatte ich, wo Landesstrassen nur für Land- oder Forstwirtschaft freigegeben sind,
In einem Fall war das aus Medienberichten als Sperre wegen Strassenzustand ersichtlich. In zwei Fällen habe ich das korrigiert: Beim Flugplatz Finow und bei der L2055 von Ascherode nach Wulfingerode. Bei letzterem gab’s Protest und Revert. Das Sperr-Schild in Ascherode ist in Mappilary zu sehen, in den Esri-Bildern aber auch mehrere Kfz auf dem angeblichen Feldweg. Und die Kollegen bei Guugel interessieren sich auch nicht für die Sperre. Würde ja gerne mal vorbeifahren um das zu verstehen…
Der Scanner läuft jetzt cron-gesteuert immer Sonntag morgens auf dem Geofabrik-Gemrnay-Extrakt, der eine erstaunlich kurze Latenz zu haben scheint. So kann man relativ zeitnah noch Korrekturen machen, bevor am Montag Morgen der Snapshot für den Planet-Dump gemacht wird (der dann Donnerstags bei BRouter ankommt).
PS: @geofabrik: ihr habt bestimmt auch einen Planet-Dump mit kürzerer Latenz und weniger Störungen als den offiziellen 
was aber wohl nur heisst, dass dieses Sieb dafür nicht geeignet ist.
Hab’ einen anderen Test gebaut, der nach TR-Fehlern fischen soll. Was er tatsächlich macht ist, die TRs zu suchen, die tatsächlich eine Wirkung haben. Dass sind natürlich die guten. Aber keine Wirkung ohne Nebenwirkung, also vermutet man in dieser Liste eben auch die Fehler.
Allerdings muss man viele Kreuzungen testen, um einen Fehler zu finden, die false-positive-Rate ist also ziemlich hoch (>95%)
Was man aber dann findet ist sowas hier (die hab ich aber alle schon bearbeitet!):
Nicht immer ist die angezeigte TR dann auch der Fehler. Gibt da auch komplexere Wechselwirkungen.
hab diese Liste der TR-Kanditaten jetzt einfach mal in die “suspect” Liste eingespeist, auch wenn der Name “suapect” hier eigentlich nicht passt. Sollte eher heissen: “wirksame TR, die es sich lohnt zu testen”
Zurück zu den Sackgassen-Fehlern, jetzt mit mehr Länder-Poygonen, und mit einer “Max-Prio Logik”
http://brouter.de:443/brouter/suspects
Die funktioniert so: solange es noch suspects gibt bzgl. motorway, dann werden nur diese angezeigt.
Dann trunk, dann primary … bis runter zu tertiary.
Die Liste für Deutschland ist zwar eigentlich leer, aber jetzt werden tertiary-suspects angezeigt. MAcht aber nicht wirklich SPass, die durchzuschauen, weil da ist die false-positive Rate viel höher als bei secondary.
Ich werde die Länder-Liste noch ergänzen - mich aber nicht inhaltlich mit den !=germany suspects beschäftigen.
Die Prüfung auf Routing-Versuche in BRouter-Web als Vorraussetzung für die Markierung als false-positive und confirmed habe ich beibehalten, auch wenn es hier mehrere Nachfragen gab, die zeigten, dass das nicht immer verständlich ist. Es ist einfach ein gewisser Aufwand, siede suspects zu gewinnen, also muss es auch ein gewisser Aufwand sein, sie weg-zu-kicken. Denn eine false-positive-Markierung bleibt für immer stehen, da sollte die Stelle eben auch wirkich geprüft sein.
Was mache ich, wenn es sich um eine Baustelle - wie hier - handelt:
- http://brouter.de/brouter-web/#zoom=18&lat=48.15207&lon=9.476566&layer=OpenStreetMap&lonlats=9.476566,48.15207&profile=car-eco-de
- http://brouter.de/brouter-web/#zoom=18&lat=48.151886&lon=9.47684&layer=OpenStreetMap&lonlats=9.47684,48.151886&profile=car-eco-de
Die Brücke über den Donau-Hochwasserkanal wurde abgerissen und derzeit neu erstellt. Fertigstellung voraussichtlich bis Ende 2017.
Grüße aus Oberschwaben
Peter
Wenn die Baustelle nachvollziehbar dokumentiert ist (und offensichtlich betreut):
→ false positive
Wenn es sich um eine Karteileiche handeln könnte, man es aber nicht verifizieren kann:
→ Als Kartenfehler in OSM erfassen → confirmed → fixed
Die Fixes-Issues kommen irgendwann wieder (wenn der Sachverhalt weiter besteht)
Die false-positives verschwinden fuer immer.
Erledigt
Wäre es für Dich möglich die Liste der Kandidaten in csv-Format für JOSM mit Opendata-Plugin zum Download anzubieten?
http://wiki.openstreetmap.org/wiki/JOSM/Plugins/OpenData#Tabular_files_.28CSV.2C_XLS.2C_ODS.29
Die Datei würde etwa so aussehen, natürlich mit mehr Datensätzen.
"longitude";"latitude";"note"
5.944088;50.99417
8.527084;49.369169;"confirmed 1 days ago"
Die kann man bei JOSM in eine Ebene laden und mit dem passenden Hintergrund hat man dann einen visuellen Überblick.
technisch möglich schon, dem prozess täts aber nicht gut tun.
hab jetzt schon das problem, dass es wohl einige Leute gibt, die die Dinger bearbeiten, der Status-Feedback dann aber ausbleibt.
Das machts den Kollegen nicht leichter, die den selben suspect auch nochmal prüfen und garnichts mehr verstehen, weil’s schon bearbeitet ist, und dann verlieren die die Lust.
Also bitte: Fehler beheben ist toll, aber false-positive oder fixed-markierungen machen ist noch toller…
Hab’ ja jetzt (im Hinblick auf die Erweiterung auf ganz Europa) bisschen gegengesteuert durch die Max-Prio-Logik: solange eine Hirarchie-Ebene nicht komplett “weg-markiert” ist, ist die nächste einfach nicht zu sehen…
Hab’ übrigens (dem Karlsruhe Hack Weekend sei dank) auch Fortschritte beim BRouter-Karten-Refresh gemacht: der läuft jetzt diff-basiert und damit zuverlässiger und mit deutlich kürzerer Latenz. Hab’s jetzt so eingestellt, dass immer Sonntag morgens die BRouter Datenfiles “frisch” sind (mit map-snapshot date ca Samstag 24 Uhr) und auch die suspect-liste.