Temat dla AI na poszukiwanie nie wprowadzonej infry rowerowej: łatwo znaleźć po znakach P-23 (rowerek). Raczej widoczne na orcie. Potrzebna tylko analiza, czy w sąsiedztwie wykrytego miejsca jest już otagowane coś rowerowe. Jeżeli nie, to AI zgłasza miejsce dla użytkowników dla zweryfikowania i wprowadzenia z orty.
Podobne zadanie jest na osmose ale tam dane pobierane są z mapillary i działa to od dość różnie.
Kolejny test:
Trafiły się jedynie 2 buble rozpoznawcze ale nie znalazłem już żadnych błędów w logice złączeniowej.
Node: 11085645081 | OpenStreetMap
Node: 1558354242 | OpenStreetMap
Myśle, że można spokojnie wprowadzić warunek zeby nie dodawał przejść na rondach (tag junction=roundabout), raczej nie spotkałem się z sytuacją w Polsce żeby na rondzie było przejście
Dobry pomysł! Postaram się jednak jeszcze usprawnić AI bo najlepiej byłoby naprawić problem u źródła
Zgadzam się, że będzie to rzadki przypadek.
Kontrprzykład (Plac Grunwaldzki w Szczecinie):
Źródło: Plac Grunwaldzki w Szczecinie – Wikipedia, wolna encyklopedia
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.
Masz własny czy https://overpass-turbo.eu/ ?
Oficjalny miewa różne opóźnienia.
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
.