Kolejny test:
Teraz nie było już żadnych false-positive (również na danych testowych).
Aktualna wersja AI będzie w stanie zaimportować około ~88% wykrytych przejść.
Zdarzyło się 1 nieoptymalne przyłączenie: Node: 5188256013 | OpenStreetMap (jakiś błąd programistyczny, nie AI, już to analizuję).
Myślę, że dzisiaj będzie można odpalić import na jakiejś małej prędkości. Proponuję na start 300 przejść dziennie, a po jakimś czasie zwiększyć jeśli nie będzie żadnych ewidentnych bubli.
Opublikowałem kod:
Na tą chwilę program nie oznacza crossing=uncontrolled/traffc_signals, postanowiłem wyciąć tę część na rzecz kolejnego projektu. Będzie można wtedy na całą Polskę zaktualizować oznaczenia highway=crossing, a funkcjonalność klasyfikacji w tym samym AI co sprawdzanie egzystencji, dodawało trudności w uczeniu i pogarszało wyniki.
Kolejny test:
Znowu nie było żadnych false-positive 
.
Nie było też już żadnych błędów przyłączeniowych.
Aplikacja wydaje się być gotowa na powolne wdrażanie jej.
Wbrew pozorom to nie jest takie rzadkie. Trzeba tylko wiedzieć gdzie szukać. Tutaj przejście na rondzie w Bochni (trzeba przybliżyć żeby zobaczyć znak, nie mogłem złapać kąta)
Tutaj rondo-rynek w Skale (ogólnie rondo-rynki często będą miały przejścia, bo na wysepkę trzeba się jakoś dostać)
Import wystartował, stronka ze szczegółami:
https://wiki.openstreetmap.org/wiki/YOLO_crossings_import
Zmiany wysyłane są z konta NorthCrab_upload | OpenStreetMap.
False positive można zgłaszać tutaj: False positives report · Issue #1 · Zaczero/osm-yolo-crossings · GitHub.
Dwa przejścia z importu w tym samym miejscu:
Zapisałem na Invalid merge report · Issue #2 · Zaczero/osm-yolo-crossings · GitHub, rzeczywiści dziwne, wygląda jakby Overpass w tym czasie się nie zaktualizował? Przyjrzę się temu niebawem.
Miałem kiedyś dopóki się nie wywalił przy aktualizacji, potem zaczęło brakować dysku i tymczasowo wstrzymałem. Tutaj powinna aplikacja sprawdzać opóźnienie czy nie jest za duże - w odpowiedzi overpass jest godzina ostatniej synchronizacji. Tak czy siak, niedługo przywrócę swoją instancję overpass. Aktualnie aplikacja czeka 5 minut po dodaniu bo nie pisałem bardziej zaawansowanej logiki ale może pora to usprawnić. Tam było conajmniej 30 minut desynchronizacji.
Krytyka jednego z wykopowiczów:
Właśnie miałem ten temat poruszyć. Zgodnie z przepisami przejście dla pieszych jest wyznaczone przez znaki pionowe i dodatkowo może przez poziome. Kilka dni temu trafiłem na skrzyżowanie, gdzie są wymalowane (kiedyś) pasy, ale usunięto znaki pionowe. Tak więc formalnie przejścia zostały zlikwidowane, ale po resztkach infrastruktury jeszcze można się ich domyślać. Co wtedy? Zaznaczać, nie zaznaczać, jakiś dodatkowy atrybut? To samo dotyczy niemal wszystkich przejść przez DDRki. Obnaża to niestety jakość polskiego znakowania, ale na to żadnego wpływu tutaj nie mamy.
Przejścia sugerowane powinny być również oznaczone tagiem highway=crossing (+crossing=unmarked chyba najlepiej), a niepełne oznakowanie to chyba właśnie taki przypadek.
BTW: Myślę, że powinien powstać jakiś standard na oznaczanie obiektów zaimportowanych botem, może coś w rodzaju source:bot=<url_do_opisu_bota> - a po weryfikacji przez człowieka usuwać taki tag?
W przypadku kolejnych AI można by uniknąć uczenia na danych z innego AI.
To jest ciężki wybór, ale ja preferowałbym jednak uncontrolled/marked, jeśli są jakieś znaki poziome. Dylemat jest taki, czy trzymać się bliżej klasyfikacji urzędowej, czy tego, co widać w terenie.
Pasy usiłowano usunąć, ale są wciąż widoczne, czy nawet nie usiłowano?
Traktowanie przejść niepoprawnie oznaczonych jako przejścia sugerowane, a po naszemu unmarked, ma kilka zalet - jest w miarę zgodne z przepisami, pozwala odróżnić w OSM od siebie przejścia dla pieszych i przejścia sugerowane, a rodzaj malunków na drodze można oznaczyć w dedykowanym kluczu crossing:markings=*.
Jak jest sama zebra, ale bez znaków pionowych, to trochę nie wiem jak mielibyśmy ją odróżnić od poprawnego przejścia z zebrą i znakami pionowymi, inaczej niż w kluczu crossing=*
Z drugiej strony, ktoś z zewnątrz, nie znający takich ustaleń, nie ma wtedy szans dobrze oznaczyć przejścia z zebrą i bez znaków pionowych posługując się typowymi edytorami 
Ja się dostosuję, jeśli społeczność jakąś wersję przyjmie, ale pewnie nie przyjmie żadnej, a wtedy takie przejścia sugerowane wciąż będą tagowane jako uncontrolled/marked.
Wykop nie chce ze mną gadać, więc tu napiszę: na wrzuconym zdjęciu z Google są same pasy, brak linii zatrzymania dla pojazdów. Na zdjęciu satelitarnym linie zatrzymania już są, czyli coś było zmieniane. Czy są obecnie znaki pionowe - trudno stwierdzić.
Podoba mi się ten pomysł. Można to połączyć ze StreetComplete, żeby pytało o takie rzeczy i po potwierdzeniu wywalało ten tag.
Na granitowej kostce są. To się samo dość szybko usuwa, a frezować nie za bardzo nie można.
Parę false positive’ów:
changeset 144714804 (3/17):
)changeset 144709198 (3/19):
Ewidentnie oszukuje się na strzałkach oznaczających dozwolone kierunki z danego pasa.
Dzięki, zapisałem na GitHub issues.
Aktualny plan jest taki, że kiedy bot skończy pierwszą iterację po Polsce, utworzę nową wersję modelu z poprawkami, i ponowię klasyfikacje na poprzednio wykrytych przejściach. Bot zapisuje wszystkie wykrycia do bazy wewnętrznej dzięki czemu przyszłe iteracje będą znacznie szybsze (nie będzie musiał szukać od zera). Oznacza to, że w nowej wersji bot doda poprzednio niepewne-pominięte przejścia, oraz usunie poprzednio błędnie dodane false-positives.