Nie lepiej pod edycją skomentować?
1 Like
Przygotowałem sobie środowisko do łatwego klasyfikowania zdjęć - CVAT. I teraz dodawanie nowych danych idzie dosyć sprawnie. Dodaję trochę więcej danych z oceny 25-75% tak aby dodać informacji tam gdzie aktualny model nie jest pewny. I wtedy może uda zwiększyć % importowanych budynków 
.
Ogólnie tak przygotowaną podstawę będzie można bardzo łatwo przerobić pod inne projekty importu. Jeśli wszystko dobrze wypali 
.
1 Like
Po dzisiejszych zmianach, algorytm jest teraz wstanie importować ~55% budynków (vs. poprzednie ~48%) zachowując ten sam poziom błędu (0.3%). Wersja aplikacji to 1.3.
True Negatives: 164
[
] False Positives: 2
False Negatives: 349
[
] True Positives: 638
Nie poradził sobie z:
Po raz pierwszy, większość dodanych budynków z regionu znalazła się w ocenie >90% niż >80%.
90%, 18 - Changeset: 138782391 | OpenStreetMap
80%, 9 - Changeset: 138782393 | OpenStreetMap
Poprzednie wersje nie były w stanie osiągnąć tak wysokiej pewności dla większości budynków. Oznacza to także mniejszą ilość budynków do moderacji - gdy będziemy skupiać się głównie na >80%.
Z ciekawości sprawdziłem też statystykę dla ustawienia minimalnej pewności na 90%.
Algorytm nie popełnił wtedy żadnego błędu ale ilość dodanych budynków spadła z 55% na 35%.
Doszedłem do wniosku, że tutaj aż prosi się o zastosowanie sieci neuronowej, więc tak zrobiłem. Program jest teraz w stanie importować ~70% budynków (vs. poprzednie ~55%) zachowując ten sam poziom błędu (0.3%). Wersja aplikacji to 2.0.
Z ciekawostki, całkowity % nadających się budynku do importu to około 85%, bazując na zebranych przeze mnie ręcznych danych. 70%/85%=82% - daje lepsze zrozumienie jakości modelu.
Podaje statystyki dla pewności 99.5% ponieważ przy 99.7% (na której operuje) nie wyskoczył żaden false-positive, dane są takie same jak poprzednio:
True Negatives: 87
[] False Positives: 1
False Negatives: 83
[] True Positives: 418
Nie poradził sobie z:
Model został zoptymalizowany pod kątem działania wyłącznie na procesorze - nie wymaga on karty graficznej. Pełne przetworzenie (w tym pobranie danych z Geoportalu - co trwa najdłużej) trwa tylko 600ms. Poprzednio czas ten wynosił ponad 5 sekund.
Jako podstawę modelu wykorzystałem MobileNetV3Large który został wytrenowany na danych imagenet i specjalizuje się właśnie - wysoką wydajnością na procesorze. Tylko wystarczyło go dostosować do naszego problemu i danych.
Tak przygotowany workflow będzie można bardzo prosto dostosować do innych problemów na OpenStreetMap - może automatyczne dodawanie przejść dla pieszych? Ale to już temat na inny wątek .
Zestawy zmian:
>99.9%: Changeset: 138858441 | OpenStreetMap
>99.5%: Changeset: 138858443 | OpenStreetMap
A tutaj kilka bardzo ciężkich przypadków, z którymi zwykły algorytm by sobie nie poradził. Dobrze ukazują one wzrost umiejętności w tej wersji:
4 Likes
Zestawy zmian bota powinny linkować do dokumentacji na Wiki.
Nie musi być aż tak nalinkowane jak w np. Changeset: 138715539 | OpenStreetMap ale jakiś link umożliwiającą łatwą weryfikacje koniecznie powinien być. Choćby w opisie zmian.
1 Like
Uzupełniłem wiki a link będzie dodany w tagu:
website:import=https://wiki.openstreetmap.org/wiki/BDOT10k_buildings_import
Bo niczego lepszego nie wymyśłiłem, raczej będzie okej.
Na tę chwilę proponowałbym wyszukiwanie brakujących przejść. W dalszym etapie możemy pomyśleć o automatycznym dodawania
Jasne, taki pomysł dałem ale do realizacji jego to może z 1-2 miesiące, ale to i tak bez żadnej gwarancji.
Zwiększyłem prędkość importu z 500 do 1000 dziennie, ponieważ wygląda na to, że błędów jako takich nie ma
1 Like
Skoro to jest import tylko budynków z BDOT, to proponuję napisać o tym wprost w source.
Czyli zmienić source=www.geoportal.gov.pl na source:building=BDOT10k
source=www.geoportal.gov.pl po ewentualnych paru późniejszych edycjach na budynku przestaje mieć sens.
2 Likes
Ten source jest wykorzystywany przez https://budynki.openstreetmap.org.pl
https://github.com/openstreetmap-polska/gugik2osm/blob/0bdf50e647ff6025102a8fdae2a84aa88c6cb564/app/common/objects/buildings.py#L25
Raczej bym nie zmieniał, bo ciężej będzie wyfiltrować budynki z tego źródła.
Czuję, że dodanie ekstra source:building=BDOT10k to już sporo, ale może to jest opcja?
Cieżej nie będzie, bo już teraz to się słabo do tego nadaje. Identycznie to ja mogę sobie oznaczyć źródła czegokolwiek, co ściągnę z geoportalu. Np. drogę zmapowaną z orto.
Ja uważam że skoro tak zostało już zaimportowane sporo budynków (nie tylko przez bota ale ogólnie) to więcej zamieszania wprowadzi tylko ta zmiana. Można powiedzieć że zrobił się z tego taki mały standard i w sumie budynek który ma taki source, najpewniej pochodzi z BDOT.
Precyzyjniejsze wskazanie źródła i czego ono dotyczy nie może wprowadzić większego zamieszania.
To jest w końcu tag informacyjny. Jeśli jego zmiana nie jest możliwa, to mam pytanie - do jakiej innej funkcji on został przewidziany?
2 Likes
Chyba strona budynki jest największym blockerem. Jest ona dosyć użyteczna w Polsce.
W jaki sposób ta blokada miałaby działać?
Jeśli widzę obiekt z source=www.geoportal.gov.pl, to dlaczego miałbym to kojarzyć ze stroną do importów budynków?
Jest nawet gorzej. Po wejściu na stronę podaną w source, czyli www.geoportal.gov.pl i wyświetleniu mapki mogę ujrzeć budynki. Te zaimportowane? Nie.To będą budynki z EGiB, a nie BDOT10k.
Ten source jest tak nieprecyzyjny, że aż wprowadza w błąd.
Chyba lepiej będzie kontynuować tutaj
Ale dlaczego brak zmiany tam blokuje zmianę w twoim bocie?
2 Likes
Nie blokuje, tylko uważam że będzie to bardziej łatka niż naprawienie problemu u źródła. Kiedy rozwiążemy go poprawnie, to będzie to automatycznie dotyczyć wszystkich, i przyszłych aplikacji. Naprawa po stronie aplikacji jest tylko jednorazowa.
1 Like