QS Fernwegenetz

After more investigation i reverted all 33 user changesets, it was all just “proposed” roads, nothing to do with reality.

Das Thema beschäftigt mich weiterhin, sowohl die Reviews der deutschen suspects, also auch die Weiterentwicklung des scanners und des suspect-managers. Will daher nochmal berichten (immer in der hoffnung auf Feedback):

“Hide for”

gibt jetzt auch den Pfad “confirmed->hide for” um suspects für einen gewissen Zeitraum zu unterdrücken. Aus eine Wieder-Vorlage Funktion, und das braucht man für Baustellen.

“Who-Did-It”

hab’ noch einen Link ergänzt auf (Simon’s) “who-did-it” Das machts manchmal wirklich leichter, den verantwortkichen CS zu finden. Aber insgesamt trau ich dem Tool noch nicht ganz, es zeigt einfach nicht alle Changests gemaess Filter an. Z.B. müsste doch eine Suche “abrensch” und “eternity” alle meine CS zeigen - tut’s aber nicht.

“Destination”

meine Versuche, dass Thema “destination” access mit rein zu nehmen, hab’ ich erstmal auf Eis gelegt. Das würde aber Sinn machen, das ist viel Zeugs und vieles ist dabei konzeptionell noch unklar

“Polygon Management”

ich scanne jetzt gemischt, täglich auf Basis Europa Extrakt und wöchentlich für Indien. Gab ein paar Probleme, dabei noch die archivierung und das Expiry von fixed-Markierungen konsistent zu halten, aber die sollten behoven sein. Gefallen tut mir das ganze Polygon-Mangement aber immer weniger. Z.B. habe ich für UK die nächst kleinere Admin-Ebene genommen, einfach weil mich ein Schotte danach gefragt hat. Das ist natürlich völlig willkürlich.

Was ich brauche ist eine Lösung die so aussieht wie beim Walter ( https://wambachers-osm.website/boundaries/ ), wo man sich einfach baumartig durch die Admin-Levels klicken kann und dann nur die suspects für das gewählte Polygon sieht, und einen täglichen Scan für die ganze Welt. Vielleicht wird’s ja was auf dem nächsten Hackweekend in Karlsruhe…

Who dit it von Simon zeigt meines Wissens nur Objekte mit Nodes an, wo Nodes neu angelegt oder verschoben wurden. Wenn lediglich Tags verändert werden, werden diese Nodes nicht angezeigt.

Ich verwende zusätzlich Latest Changes (https://tyrasd.github.io/latest-changes/#12/48.1459/9.6113) von tyrasd . Hier werden auch Änderungen von Tags angezeigt.

Grüße aus Oberschwaben

Eventuell wäre noch eine Abfage dieser Art zu einem Suspect hilfreich (Beispiel Suspect):


(
  /* node(around:1,{{center}})->.n; */
  node(around:1,51.474849,-0.040697)->.n;
  way(bn.n);
  rel(bn.n:"via")[type=restriction];
);
out meta;
>;
out skel qt;

http://overpass-turbo.eu/s/BB2

Die Abfrage sucht Knoten im Umkreis von 1m zur Koordinate und lädt alle Wege mit dem Knoten und Abbiegerelationen mit dem Knoten als “via”. Die Suspect-Koordinaten sind wohl eine Nachkommastelle gerundet, sonst könnte man auch exakt mit “around:0” suchen.

Als Link:
https://overpass-turbo.eu/?Q=(node(around%3A1%2C%7B%7Bcenter%7D%7D)-%3E.n%3Bway(bn.n)%3Brel(bn.n%3A%22via%22)%5Btype%3Drestriction%5D%3B)%3Bout%20meta%3B%3E%3Bout%20skel%20qt%3B&C=51.474849;-0.040697;18&R

Gruß,
Norbert

Danke Euch, hab’ den who-did-it link durch lastest-changes ersetzt, und die zusätzliche Overpass-Abfrage ergaenzt (“node-context”). Nebenbei hat Norbert dann auch die Frage beantwortet, wie man Overpass-Links dazu bringt, das Query sofort auszuführen.

Wie gut diese Node-Context Abfrage in den schwierigen Fällen funktioniert, wo Node-Dubletten beteiligt sind oder die Linien von Landnutzungs-Polygonen überlagert sind weiss ich aber noch nicht…

Die Abfrage ist schon noch ausbaufähig:

  • Linien könnte man z.B. mit “way(bn.n)[highway];” weiter einschränken
  • mit “date” den Stand zum Zeitpunkt der Prüfung abfragen
  • die 1m Umkreis in “around:1” habe ich eher willkürlich gewählt, könnte man bei sechs Nachkommastellen weiter eingrenzen auf 0.111, wenn ich das richtig sehe:
    https://wiki.openstreetmap.org/wiki/DE:Genauigkeit_von_Koordinaten

Jetzt den ganzen Planeten und mit allen level 2 + level 4 Admin-Polygonen:

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

Es lassen sich jetzt also z.B. auch die deutschen Bundesländer abfragen.

Es bleibt aber jetzt erstmal wieder bei dem wöchentlichen Scan (mit neuen Suspects Sonntag morgens).

Ich selbst werde mich bei den Reviews für Deuschland weitgehend zurückziehen und zeitnah nurnoch Hessen anschauen, den Rest allenfalls kurz vor dem nächsten Map-Snapshot (Samstag abends um 21 Uhr).

neue Runde…

vergangene Woche wurden tatsächlich in ganz Deutschland diese suspects gesichtet, aber nur in Baden-Württemberg hat das mit der Status-Verwaltung auch reibungslos funktioniert. Wirklich hilfreich sind solche Reviews aber nur, wenn dann auch der suspect-status angepasst wird, weil sonst kommt noch jemand, schaut sich das wieder an und verliert die Lust, weil der auslösende Sachverhalt nicht mehr sichtbar ist.

Ausserdem sieht man nur alle suspects, wenn man auch den status anpasst, weil solange da noch z.B. ein “primary” suspect steht, sind “secondary” und “tertiary” verdeckt.

Also einfach:

  • “mark as false positive” klicken, wenn es sich nicht um Issue handelt

  • “mark as a confirmed issue” klicken in den ander Fällen und dann

    • “mark as fixed” - wenn Du den Fehler behoben hast
    • “hide for…” wenn es z.B. eine Baustelle ist, oder Du einen CS-Kommentar oder eine Note erstellt hast

In folgenden Bundesländern gibts aktuell noch offene suspects:

http://brouter.de:443/brouter/suspects/Germany/LowerSaxony/all

und deutschsprachigen Nachbarländern mal auf den “new” Filter begrenzt:

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

(edit: Liste verkürzt)

Ich hab es für Meck-Pomm versucht.
Erster Eintrag: War tatsächlich ein Stück der letzte Woche eröffneten Ortsumgehung von Plau an See noch nicht aktiviert. Habe den link zu JOSM genutzt, mir das Problem angesehen und beseitigt. Auf “mark as confirmed issue” geklickt, bekomme folgende Antwort “marking confirmed requires at least 2 recent nearby waypoints from BRouter-Web, found: 0
Kann dies aber nicht als “mark as fixed” kennzeichnen, weil das auf der website nicht hochkommt.
Wie nun weiter?

Du musst den Link zu “Open in BRouter-Web” nutzen und mindestens ein Test-Routing dort machen (=2 Weg-Punkte im Umkreis von 3km). Dazu dort auf das Stift-Symbol klicken (“draw route”) und den zweiten Wegpunkt setzen (der erste wurde automatisch auf den suspect node gesetzt). Weitere Test-Routings dann durch Verschieben einer der beiden Wegpunkte.

Für false-positive Markierungen werden 4 Test-Routings erwartet (=8 Wegpunkte).

Könntest du das vielleicht in die Seite so einbauen, dass jemand, der sich nicht täglich damit beschäftigt, intuitiv damit umgehen kann?
Ich habe jetzt mal versucht, dort zu routen, aber Brouter akzeptiert meine Änderung nicht. OSMAND+ mit stündlichen updates lässt das routing zu. Nach wie viel Zeit kann man mit einem Ergebnis rechnen?

Die Datengrundlage wird nur einmal pro Woche neu berechnet. Neue Daten immer Sonntag morgens mit Map-Snapshot Time Samstag abend, 21 Uhr.

Eine aktive Nachkontrolle sieht der Suspect-Manager nicht vor, ich weiss nicht ob sowas sinnvoll wäre (Geht aber natürlich ganz klassisch anhand der eigenen Changeset-History)

Es ist so gedacht, dass nach “mark fixed” das Tracking der Issues beendet ist. Sollte doch noch was fehlen, kommen die ja von selber wieder.

Ich hab’ auf dem Rückweg von Dresden drüber nachgedacht, wie BRouter-Suspects und Osmoscope doch eine Symbiose hinkriegen, auch wenn das bzgl. der Anforderungen an den Issue-Tracking-Prozess noch nicht passt.

Deswegen kann man aktuell statt der klassischen Listendarstellung:

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

auch eine Kartensicht auf Basis von Osmoscope verwenden:

http://brouter.de/osmoscope

Diese Sicht zeigt allerdings nur “neue” und “confirmed” Suspects, das sind weltweit jede Woche etwa 2000. Für alle 300.000 suspects ohne diese Bedingung wäre das Verfahren mit der (globalen) GeoJSON-Datei nicht geeignet, und die Alternative mit den Vektor-Tiles war auf die schnelle nicht möglich.

Da wirkt ein Patch auf OsmoScope, der im wesentlichen den Inhalt des rechten Panels ersetzt, und das verweist dann einfach auf die Seite von BRouter-Web zur Zustandsverwaltung.

Also kein grosser Hack, aber doch schön anzuschauen, auch weil man leicht sioeht, welche Gegenden gerade “HOT” sind oder welche Länder am Ende eines Zyklus (also Samstagabend) keine Issues mehr haben.

Vielleicht taugt das ja als Appetizer, und wer dann mehr will und auch den hoistorischen Bestand an suspects durchschauen, der muss dann eben auf die Listendrsteloung wechseln.

Ich hab trotz kaum übersehbarer Warnungen in der Osmoscope-Doku bisher nichts für den “CORS” Header gemacht, mit meinen Browsern bisher aber auch kein Problem gesehen. Das ist zwar kein richtiges “cross-origin”, sondern nur ein Wechselim Port zum selben Host, aber bei BRouter-Web hatte ikonor glaubich ähnlich Probleme mit Safari, also da könnte es noch Probleme geben, bitte dann kurz Feedback.

Hab das grad mal probiert und ich sehe in den Layern nichts. Vielleicht gibts ja keine Probleme.

Mit dem CORS wirst Du nur dann Probleme haben, wenn Du die Layer von einer anderen Osmoscope-Instanz laden willst, also wenn Du bei http://osmoscope.openstreetmap.de/ Deine Layer-URL konfigurierst, dann gibts einen Fehler. Solange Deine Layer eh nur mit Deiner gepatchten Version vom Osmoscope laufen, ist das egal, aber mittelfristig wäre es natürlich schön, wenn das auch in anderen Osmoscope-Instanzen läuft.

War wohl eine zeitliche Koinzidenz, hatte gerade zu der Zeit an den Layern geschraubt ( =mehr Layer mit verschiedenen Filtern). Müsste wieder gehen, aber ggf. Browser-Cache leeren, hab’ das caching nicht so ganz verstanden.

Jopp, tut jetzt. Ich habe mal ein Issue aufgemacht zur Frage, ob man die Selection-Box flexibler machen kann: https://github.com/joto/osmoscope/issues/27

Hallo Arndt,

auf http://brouter.de/osmoscope/#map=19/9.79447/48.09965&l=http://brouter.de/osmoscope/active_deferred.json werden 2 “Active deferred suspects” angezeigt. Dort ist eine länger andauernde Baustelle, die ich im Auge habe.
Wie kann ich diese auf “Active false positives” setzen.

Fragende Grüße

“Active deferred” heisst: vorgesehen für Wiedervorlage und wurde im letzten Scan wieder detektiert.

Das ist hier vollkommen richtig, fast alle Wiedervorlagen sind Baustellen, für die ich (oder ein anderer Bearbeiter der Suspect-Liste) einen Zeitraum abgeschätzt habe.

Der einzige Fehler hier ist, dass das Wiedervorlagedatum auf “in 9 Tagen” steht, obwohl an dm gesperrten Objekt “Anfang September” steht. Das liegt einfach daran, dass das Tool nur maximal 6 Monate erlaubt und ich das vor einem halben Jahr dann eben auf 6 Monate gesetzt habe.

Idealerweise sitzt das Wiedervorlagedatum etwas hinter dem geschätzten Freigabedatum, dann sieht man die Dinger in der Regel nicht mehr Wieder und hat keine Arbeit damit.

Mit Hacker-Methoden lässt sich das Wiedervorlagedatum solcher supects aber ändern, wenn man in der Url hinter der langen Zahl (=suspect-id) noch “/fixed/140” setzt. das habe ich gerade gemacht und jetzt haben sie Wiedervorlage in 140 Tagen (=Ende September).

Das beste und coolste wäre natürlich, wenn Du ganz Baden-Würtemberg + Bayern “ins Auge nehmen” würdest, dann müsste ich das nicht mehr machen. Ich bearbeite die neuen Suspects dieser beiden Länder für heute erstmal nicht…

Gruss, Arndt

Ganz Baden-Würtemberg + Bayern: das kann ich Dir jetzt nicht versprechen, Oberschwaben aber gerne.

Dazu bräuchte ich aber zuerst mal eine Anleitung in Deutsch!

Fragende Grüße

mark as confirmed issue → hide for 6 months

Bei sowas schreibe ich einen CS-Kommentar. Weil dieser Mapper hat unter einem irreführenden CS-Kommentar eine Strasse gesperrt, ohne das zu dokumentieren und ohne den Zeitraum abzuschätzen. Also ganz freundlich nach Grund und Zeitraum nachfragen → suspect auf “fixed” setzen. Ist das suspect dann nächste Woche wieder da und der CS-Kommentar nicht beantwortet → revert des Änderungssatzes.

Wenn Du einen CS-Kommentar oder eine Note erstellt hast:“fixed”. Sollte der Sachverhalt eine Woche später noch bestehen, ist er dann wieder in der Liste.