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
Durch die Umstellung des BRouter-Servers auf (optional) HTTPS hat sich auch die URL für brouter-suspects geändert:
http://brouter.de/brouter/suspects
oder
https://brouter.de/brouter/suspects
Der osmoscope-Link ist unverändert, braucht aber ggf. mal ein “shift-reload”:
Die https-Variante funktioniert hier (noch) nicht.
Neue brouter-suspects gibt’s nach wie vor immer Sonntag vormittags (ab ca 11 Uhr), also auch morgen.
Hallo Arndt,
könntest Du noch eine feste Sortierung für die verschiedenen Layer auf osmoscope einbauen.
Im Augenblick änderst sich die Reihenfolge bei jedem neuen Laden. Das ist etwas lästig.
Grüße
PS:
Einen Layer für alle neuen suspects würde ich ebenfalls begrüßen. Dann bräuchte ich nicht alle nacheinander durchklicken.
Dann begrüss doch “new suspects down to tertiary”, weil “down to” heisst ja alle Kategorien bis runter zu tertiary.
Sortierung verstehe ich auch nicht so ganz. Der zuletzt benutze Layer ist nach Re-Load immer oben, also vielleicht hat sich jemand (also Jochen) dabei was gedacht…
Das erübrigt sich, wenn ich künftig gleich tertiary wähle.
Grüße
Bin bei dem Problem weitergekommen, den suspect-scanner weiter zu entwicklen in Richtung schärfere Trigger und mehr suspects, ohne die laufende QS dadurch zu behindern.
Mir war schon lange klar, dass ich Baustellen nur eher zufällig finde (wenn da auch Sackgassen sind), und dass ich “destination” Sperren bisher ignoriert habe.
Den Scannner diesbezüglich zu ändern war nicht das Problem, aber ich muss auch verhindern, dass die vielen zusätzlichen suspects alles überfluten.
Die Lösung sind “multiple challenges”
Steigt man also wie bisher ein über:
https://brouter.de/brouter/suspects
dann sieht es aus wie gewohnt.
Steigt man ein über:
https://brouter.de/brouter/suspects/strict
dann sieht man den erweiterten Set, der mehr Baustellen und die Anlieger-Sperren beinhaltet.
Prinzipiell kann ich da beliebig viele “challenges” einsetzen und das Verfahren ist auch noch nicht zuende gedacht. Vielleicht sollte ich das kleiner schneiden und z.B. eine challenge nur für Anlieger-Sperren einsetzen.
Und eine für Turn-Restrictions mit inkonsistenter Geometrie, und eine für “oneway=yes, backward:lanes=xy” etc…
wollte es nur einfach schonmal zeigen und freu mich über Anregungen