6

was Du da angeschaut hast ist die Prüfung “germany_etr”, etr= “effective turn restrictions”, und davon die “watchlist”, das sind suspects, die als “fixed” markiert sind, aber vom Sachverhalt her noch bestehen.

Nur ist der Sachverhalt “effective turn restriction” ja per Definition kein Fehler, sondern heisst einfach nur, dass da eine TR ist, die eine Wirkung hat, und in der Regel die gewünschte.

Auf die Watchlist gekommen ist das Ding typischerweie dadurch, dass ich die (gesamte) Kreuzung gepüft habe, dabei irgendwas anderes gefunden und bereinigt, und dann auf “fixed” gesetzt habe (statt false-positive, was ja eigentlich richtig wäre), eben damit die Kreuzung irgendwann nochmal auftaucht und ich meine gemachte Änderung reviewen kann.

Also alles erklärbar, aber der Workflow ist halt komplex und erkläungsbedürftig, und trotzdem noch nicht komplex genug… Da bräuchte man noch teminierte Wiedervorlagen, statistische Löschungen von false-positives … und natürlich diese exklusive Reservierbarkeit von Analyse-Polygonen, die ich mir ja eigentlich schon vergenommen hatte.

Aber dann kommt man wieder zu dem Punkt, der mir ja jetzt oft genug gesagt wurde und absolut Sinn macht: die Generierung der Suspects und das Issue-Tracking-Framework sollten einfach zwei verschiedene Dinge sein und jeder Schuster bei seinen Leisten bleiben. Ich denke weiter drüber nach und schau mir auch die anderen Issue-Tracker an.