QS Fernwegenetz

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 :slight_smile:

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!):

http://brouter.de/brouter-web/#zoom=18&lat=50.314299&lon=8.408588&layer=OpenStreetMap&lonlats=8.408173,50.313486|8.408398,50.31501&nogos=&alternativeidx=0&format=geojson&profile=car-eco

http://brouter.de/brouter-web/#zoom=16&lat=50.21639&lon=8.86644&layer=OpenStreetMap&lonlats=8.868713,50.218491|8.868327,50.213904&nogos=&alternativeidx=0&format=geojson&profile=car-eco

http://brouter.de/brouter-web/#zoom=17&lat=49.559596&lon=8.84601&layer=OpenStreetMap&lonlats=8.846676,49.559119|8.846945,49.561444&nogos=&alternativeidx=0&format=geojson&profile=car-eco

http://brouter.de/brouter-web/#zoom=16&lat=51.64897&lon=8.71043&layer=OpenStreetMap&lonlats=8.717759,51.64564|8.720012,51.651924&nogos=&alternativeidx=0&format=geojson&profile=car-eco

http://brouter.de/brouter-web/#zoom=17&lat=51.741011&lon=8.73222&layer=OpenStreetMap&lonlats=8.730805,51.739194|8.73471,51.740125&nogos=&alternativeidx=0&format=geojson&profile=car-eco

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:

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.

Status-Update hierzu:

das läuft jetzt für Deutschland ziemlich reibungslos, und bis runter zu tertiary ist die Liste leer.
(Der Refresh ist immer Sonntag morgens, mit map-snapshot date Samstag mitternacht)

Als zusätzliches Fehlermuster hatte ich noch ergaenzt den Fall, dass eine Sperre an ein “prioritätsgleiches” Wegstück anschliesst, auch wenn das keine Sackgasse ist, weil an dem sperrenden Knoten eine routbare Ableitung existiert. Diese Muster hatte nochmal einige supects produziert, wenn auch mit mehr fals-positives als bei den Sackgassen.

Das mit den “effective turn restrictions” ist aber noch nicht wieder dabei, ich will diesen FIlter das aber wieder zum Leben erwecken. Kann die aber nicht einfach in eine allgemeine “suspects” liste schreiben, sondern da muss erkennbar sein, um welchen Filter es sicht handelt. Und das Gegenstück zu den “effective turn restrictions” wären ja “sharp angles” als Folge von fehlenden Turn-Restrictions, auch so ein Filter müsste noch dazu.

Ein Problem hab ich jetzt noch mit suspects, die sich ohne vor-ort recherche nicht klären lassen. Die sind ja in der Regel als “fixed” markiert, nachdem ein OSM Fehlerhinweis dazu erfasst wurde. Der Feedback auf diese Hinweise ist zwar erfreulich gut, aber es gibt halt einfach auch welche, die offenbar unbetreut sind. Und diese Dinger hab ich jetzt eine eigene Liste hinzugefügt (“watchlist”):

http://brouter.de:443/brouter/suspects/germany/watchlist

Aus der watchlist herraus kann man die Dinger nur anschauen, aber nicht den Status ändern. In der Regel ist da aber ein OSM Fehlerhinweis in der Nähe, an dem man was dranschreiben kann.

Für die europäischen Nachbarn hat sich aber bisher niemand interessiert. Gibt die suspects immerhin ür 15 Länder:

http://brouter.de:443/brouter/suspects

Vielen Dank an alle, die suspects bearbeitet haben oder auf Fehlerhinweise reagiert.

Wenn ich mir dieses Beispiel eines vom Automaten gemeldeten Fehlers in der Slovakei ansehe, verstehe ich nicht, wo hier ein Fehler sein soll. Wenn man aus dem Bogen (w124081077) von Osten zum Marker kommend nach Norden weiterfahren möchte, gibt es dort weder ein Hindernis noch eine Zugangsbeschränkung auf diesem Weg oder einem Knoten. Dass der Weg (w219773466) von Süden kommend gesperrt ist, gilt doch nur für den Weg und nicht für den gemeinsamen Knoten am nördlichen Ende dieses Wegstücks mit dem Bogen von Osten nach Norden.

Ähnliche Beispiele habe ich auch in anderen Ländern dieser Auswertung gesehen, wo z.B. eine Bus-Spur mit access=bus als eigene Spur von der Autobahn abzweigt, um dann nach der Bushaltestelle wieder auf die Autobahn aufzufahren. Hier zeigt der Marker einen Fehler an dem Knoten an, an dem die Busspur abzweigt.

Ich vermute, dass bei der Auswertung die Zugangsbeschränkungen eines Weges auch auf die Knoten übertragen wurden, was aber, wie in obigen Beispielen erkennbar, falsch ist.

Franz

Der Marker zeigt ein “suspect” an. Ein suspect ist eine Stelle, wo es sich lohnt, mal hinzuschauen, ob das evtl. ein Fehler ist.

Die von Dir gezeigten Beispiele sind also “false-positives”

Was Du beschreibst ist nur die schönere Form von meinem Text oben:

“Als zusätzliches Fehlermuster hatte ich noch ergaenzt den Fall… Diese Muster hatte nochmal einige supects produziert, wenn auch mit mehr false-positives als bei den Sackgassen.”

Die überwiegende Zahl der suspects sind false-positive. 80-90%

Hallo Arndt,
ich habe anfangs Deine suspects-Tabelle nach Treffer in meiner Gegend (Oberschwaben) durchforstet und - soweit möglich - bereinigt. Die Tabelle anhand Koordinaten zu durchsuchen ist doch etwas umständlich, weshalb ich schon einige Zeit dort nicht mehr nachgeschaut habe.

Wenn die Darstellung in einer Karte zu aufwendig ist, wäre es dann vielleicht eine Möglichkeit die Hinweise im OMS-Inspector zu integrieren ?

Grüße
PT-53, brouter-Fan

Jetzt in dem Modus, wo nur wöchentlich neue Kandidaten nachkommen, wäre das für eine einzele Region natürlich auch sehr wenig (aber ich hätte da noch Schweiz und Österreich anzubieten, auch sehr hübsch…)

Das klingt dann mehr nach einem Push-Service, statt aktiv nachzuschauen.

Ich könnte den Scanner für Deutschland täglich laufen lassen und irgendwie einrichten, dass man sich für ein Polygon mit email-Adresse registrieren kann und dann eine email bekommt mit der Kandidatenliste, wenn es neue suspects in dem Polygon gibt.

Kannst Du mir helfen, so ein Polygon für Oberschwaben zu finden? In dem “.poly” Format, so dass osmosis damit filtern kann, z.B. so:

osmosis --read-xml file=suspects.osm --bounding-polygon file=…/polys/Germany.poly --write-xml suspects_germany.osm

Die Europa-Polygone hatte ich mir beim Walter besorgt ( https://wambachers-osm.website/boundaries/ ), aber ich glaube, Regionen gibts da nicht, und beim Format musste ich auch manuell nacharbeiten, damit osmosis damit klar kommt.

Das mit der Integration in andere QS-Tracker scheitert daran, dass die alle kein Life-Cycle-Management haben, aber ohne diese Datenbank der “false-positives”, die mittlerweile 3500 Einträge hat, macht das alles ja keinen Sinn. Also wenn wer einen Vorschlag hat, die Suspects so in einen kartenbasierten Bugtracker einzuspeisen, dass ich den false-positive-feedback bekomme, dann bin ich ganz Ohr.

Gruss, Arndt

Hallo Arndt,

für Oberschwaben gibt es (noch) kein Polygon. Ich kann auch keines anlegen, da ich die genau Abgrenzung nicht kenne.
Ich wohne am Fuße des Bussen, im Landkreis Biberach.

Da ich meine Erkundungen für OSM nur mit dem Rad durchführe, liegt mein Aktionsradius etwa bei 30 bis 40 km rund um den Bussen.
Damit wirst Du aber wahrscheinlich nichts anfangen können, oder ?

Grüße
Peter