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
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:
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.
Ich antworte mal im “richtigen” Thread (sorry, wollt edemn OSMI-Thread nicht kapern):
Alles richtig hier. Die suspects beziehen sich auf das “motor_vehicle=private” an der Kohlenhofstrasse, und ich hatte sie, nachdem Du die Sperre eingetragen hast, auf “Wiedervorlage in 6 Monaten” gesetzt (und davon sind aktuell “DueTime 131 days” übrig). 6 Monate ist einfach das höchste, was das Tool per Click erlaubt, und in so einem Fall, wo ich zwar keinen Zeitraum habe, aber der Impact durch die direkte Umleitung auch nicht gross ist, recherchiere ich nicht, sondern setze einfach auf 6 Monate.
Hallo Arndt,
diesen Hinweis http://brouter.de/osmoscope/#map=19/7.85752/47.99163&l=http://brouter.de/osmoscope/tertiarynew.json / http://brouter.de:443/brouter/suspects/world/all/806841982155069000 halte ich für “false positive”.
Aber schau Dir bitte das auch noch an.
Grüße
Kartäuserstrasse nach links ist ein “dead start”, das hat den suspect generiert.
Grund ist, dass jemand Kartäuserstrasse nach rechts eine Baustelle (bis Oktober) als Einbahnstrasse eingetragen hat. Hab’s deswegen entsprechend auf Wiedervorlage gesetzt (“hide for 6 month”)
Da gibt es ja am nördl. Ende der Mühlenstraße eine TR mit “only_right_turn” vom 26.06.2019. Es ist ja aber nicht so, daß man aus der Mühlenstraße nicht mehr heraus kommt. Man kann rechts abbiegen und kommt dort auch weiter.
Wenn die only_right_turn-TR korrekt und auch nicht nur vorübergehend ist, wäre das doch kein “echter Fehler”, oder?
Was ändert sich, wenn die Einbahnstraße auf dem Teilstück der Kartäuserstraße wieder aufgehoben ist?
Fragende Grüße
“suspect” heisst ja nicht fehler. “dead start” heisst hier, Linker Teil der Karthäuserstrasse kann nur in einer Richtung befahren werden, ist aber nicht als Einbahnstrasse getagged, und das ist einfach das verdächtige Muster. Wenn die Einbahnmarkierung am rechten der der Karthäuserstrasse nicht mehr da ist, dann ist auch der suspect wieder weg (weil dann kann man ja links weiterfahren)
Unschön hier aber klar: die TR ist wahrscheinlich baustellenbedingt, man sieht’ ihr aber nicht an, und sowas bleibt dann gern mal hängen…
O.K., alles klar.
Danke