Wygląda dobrze, nie znalazłem żadnego błędu.
Są jakieś ograniczenia co do odległości przejść od siebie? Tutaj np. wykryte przejścia, ale na drugim pasie już nie: Node: 4464489698 | OpenStreetMap, Node: 4464489187 | OpenStreetMap
Wygląda dobrze, nie znalazłem żadnego błędu.
Są jakieś ograniczenia co do odległości przejść od siebie? Tutaj np. wykryte przejścia, ale na drugim pasie już nie: Node: 4464489698 | OpenStreetMap, Node: 4464489187 | OpenStreetMap
Rzeczywiście! Good catch.
Wyglada na to że tutaj botowi zapomniało się dodać crossing=uncontrolled?
W przypadkach kiedy mamy osobno rozrysowany chodnik jednak dobrze było łączyć z tym chodnikiem. Tak zaznaczone pasy są bezużyteczne
Zastanawiające, że bot wychwicił te pasy, a tych na drodze obok (wyglądających identycznie) już nie
Znowy przejście bez uncontrolled? Tak ma być?
Tak na szybko, nie przeglądałem każdego punktu.
W pełni popieram. Oprócz kwestii zgodności z OSM to jest kwestia bezpieczeństwa pieszych i lepiej przyjąć wersję bardziej zachowawczą.
Po prostu nie był na 99.5% pewien więc nie dodał
Zrobimy map roulette na to
Chyba naprawiłem już ten issue, będzie w kolejnym zestawie wiadomo.
Przygotowałem kolejny zestaw, zidentyfikowałem kilka rzeczy wymagających poprawy i zaraz je streszczę: Changeset: 139268999 | OpenStreetMap Zacznę od najbardziej znacznych problemów, do tych najmniej.
Tutaj na prawdę nie wiem co się zadziało, nie ma tam żadnych oznak przejścia ani nic kompletnie. Poprawa: dodam więcej danych treningowych z crossing=unmarked (choć już takie są).
Node: 3525740865 | OpenStreetMap
Tutaj wymyśliło sobie AI, że linia zatrzymania to przejście. Poprawa: dodam więcej danych treningowych pasów z drogi, może node z highway=traffic_signals.
Node: 2251316050 | OpenStreetMap
Oczywiste jest, że muszę włożyć trochę więcej pracy w algorytm wyszukiwania duplikatów. Często na segregated=*, linia przejścia poprowadzona jest poza przejściem.
Node: 11079362531 | OpenStreetMap
Node: 11079362512 | OpenStreetMap
Node: 11079362506 | OpenStreetMap
Node: 11079353402 | OpenStreetMap
Testowo odpaliłem oznaczanie traffic signals (dodałem więcej danych treningowych), ale oczywiste jest, że ta część nadal nie jest w akceptowalnym stanie.
Node: 11079353402 | OpenStreetMap
A teraz dobre wiadomośći,
Node: 11079362515 | OpenStreetMap
Node: 1602458333 | OpenStreetMap
Podsumowując, wygląda na to, że projekt wypali tylko wymaga jeszcze trochę uwagi. Szczęśliwie, są to relatywnie proste błędy i nie będzie z nimi większych problemów.
Nowa deduplikacja będzie hybrydowa. Poprzednio był sprawdzany prosty zasięg (czerwony kolor, 4.5m), teraz dodałem sprawdzanie przedniego i tylnego stożka z większym zasięgiem (niebieski kolor, 15m).
Ciekawe czy łapanie ławek, koszy czy latarni by działało.
Może znajdowanie placów zabaw, nawet i do ręcznej weryfikacji.
Powiem tak, tak zbudowaną aplikację (kod opublikuję wkrótce) można bardzo łatwo przerobić pod innego typu problemy bez większego problemu. Najlepiej tylko jakby dany obiekt był widoczny na standardowym orto (mała rozdzielczość) jeśli chcemy szukać na całej Polsce, można szukać obiektów na high res orto ale to już będzie ograniczone obszarowo bardzo. Na tą chwilę tylko uznałem że przejścia będą idealne na start i są też dosyć ważne.
Na prawdę super pracuje się na OSM bo znajdywanie danych do trenowania to pestka. A jakieś algorytmiczne zachowanie też bardzo prosto się dodaje bo OSM jest dosyć mocno przewidywalne (w zasadach mapowania).
Tak z ciekawostki pokaże co widzi mniej więcej AI do klasyfikacji rodzaju przejścia. Po lewo obraz przed przetworzeniem, a po prawo, po. Zastosowałem zestaw filtrów które usuwają niepotrzebny szum i uwydatniają kontrast w okolicach pasów oraz je dodatkowo wyostrzają. Taki prosty zabieg bardzo pomaga w osiągnięciu przez AI dobrych rezultatów.
Trochę przeraża mnie skuteczność tych rozwiązań. Ciekawe co takie Google potrafi mając Street View i inne dane.
To tylko dowodzi, że wielkie korporacje niekoniecznie mają przewagę jeśli chodzi o mapowanie z AI, jeśli jeden programista sam jest w stanie zrobić dużo lepsze rozwiązanie.
Grunt to podejście do tematu znając kontekst OSM oraz lokalne źródła danych. Czy w MS albo FB ktoś wpadłby na to, aby np. budynki nie trasować z OSM, a po prostu importować z rządowej bazy danych, z tym że zaprzęgając AI do weryfikacji?
Place zabaw są w BDOT10k. Mógłbym przygotować zestaw danych do weryfikacji z podziałem na np. powiaty. Format mógłby być np. GeoJSON. Geometria nie jest idealna, ale jest niezła. Mogę zdeduplikować z już otagowanymi w OSM
Jak chcesz możemy we 2 przerobić automatyczne budynki na automatyczne place zabaw. Deduplikacja i tak musiałaby być wykonana tuż przed dodaniem bo inaczej nie ma gwarancji że ktoś po prostu nie doda tego placu później. Na tą chwilę przydałby się jedynie ten json/geojson no i przygotowanie danych do ai, jeśli chcesz mogę ci dać dane do apki i pomożesz w klasyfikacji zdjęć. Fajnie jakby ten geojson był też automatyczny aby w przyszłości sam się aktualizował.
Wykonałem kolejny test: Changeset: 139318941 | OpenStreetMap
Przytrafił się jeden bubel:
Node: 11081921266 | OpenStreetMap
Wygląda na jakiś traffic_calming, dodam danych treningowych z tej kategorii.
Ok, jestem za
Myślę, że najpierw warto to przemyśleć/przedyskutować.
BDOT10k jest dostępne jako matrioszka-zip:
Po rozpakowaniu całość ma 250GB.
@tomczk może tutaj pewnie więcej podpowiedzieć z doświadczenia z https://budynki.openstreetmap.org.pl/
Polecam dokument https://www.wodgik.katowice.pl/www/pobierz/VADEMECUM_UZYTKOWNIKA_BDOT10k.pdf
Place zabaw można znaleźć w warstwie BUSP
(budowla sportowa), konkretnie BUSP06
: plac gier i zabaw. Otagowane też RODZAJ=placGierIZabaw
.
Dla Polski pliki BUSP mają 39MB w sumie.
Mogę przetworzyć te dane i dostarczyć w wybranym formacie.
Zgadzam się, że dobrze to zautomatyzować i deduplikować przed dodaniem.
Jedną opcją jest pobieranie całości np. raz na dobę, wypakowanie i przetworzenie. Dużo miejsca, ale od razu są dane do innych projektów.
Alternatywą jest rozpakowanie zipa w pamięci i pominięcie niepotrzebnych danych.
Mogę pomóc w klasyfikacji zdjęć.
Częściowo już dodawałem place zabaw na podstawie BDOT10k w Changeset: 139172847 | OpenStreetMap
Poza leisure=playground można znaleźć też leisure=fitness_station oraz landuse=recreation_ground.
W przypadku Warszawy dużo placów zabaw nieotagowanych jest na terenie:
Potencjalne można dawać access
, ale w przypadku dodawania automatycznego ten tag pominąłbym.
Potencjalnym follow-upem jest dodawanie wyposażenie placu zabaw tagowanego za pomocą tagu playground. Można wyszukiwać na podstawie orto na terenie już otagowanych placów zabaw. Podejrzewam, że przynajmniej kilka rodzajów powinno być łatwo rozpoznawalnych z orto. Podobne zadanie jak rozpoznawanie małej architektury: ławek, leżaków, koszy itd.
Bardziej raz na miesiąc :D. Czy to jest aż tak często aktualizowane? Może po prostu użyjemy geoportoalowego WMSa który jest do publicznego użytku?
Nie trzeba by się bawić w te całe aktualizowanie, a kod na pobieranie z WMS jest już praktycznie gotowy.
Potencjalnie. Ale na tą chwilę takie coś byłoby ograniczone zasięgowo bo to trochę roboty a będzie wymagało high res orto, które nie jest dostępne w całej Polsce.
Proszę - przenieście nowe tematy do innego wątku. Łatwiej będzie znaleźć i zorientować się w temacie. Ewentualnie jeden zbiorczy: “Pomysły na krabowanie” - i jak coś się wykrystalizuje to zakładać osobny, dotyczący już głębszych przemyśleń na nowy temat.
Kolejny test: Changeset: 139352469 | OpenStreetMap
Znacznie zoptymalizowałem całą aplikację, przejście całej Polski na 1 serwerze to będzie czas około 60 dni. Aplikacja ma już się ku ukończeniu .
Zidentyifkowałem błąd który sprawiał niepoprawne przyłączanie do pobliskiego node:
Node: 5161323471 | OpenStreetMap
Node: 4268771856 | OpenStreetMap
Cały czas AI ma zwidy więc znowu dodam więcej danych, a jeśli i to tym razem nie pomoże to zwiększę granicę “pewności”.
Node: 11083819109 | OpenStreetMap
Node: 11083819157 | OpenStreetMap
Node: 1113694497 | OpenStreetMap
Node: 1728784882 | OpenStreetMap
Node: 9111799340 | OpenStreetMap
Node: 11081921266 | OpenStreetMap