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.
“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…
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.
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?
“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…
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…
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.
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