Poświęcamy ogrom godzin na mapowanie na kompie stacjonarnym rysując miliony nudów.
Jednak często jeden obiekt (nawet punktowy) jest bardzo istotny czy dla nawigacji czy dla zaprezentowania bogactwa regionu jednak wątpliwości co do tego obiektu można zweryfikować tylko w terenie.
Od dawna zauważam niezrozumienie problemu, a każde narzędzie ma inną filozofię i wg mnie nie koncentruje się nad tym co najważniejsze.
Generalnie apki i edytory nie nadają się do rysowania skomplikowanych kształtów, bo precyzja rysowania palcem na małym ekranie podczas ruchu, nie pozwala rysować sensownie.
Tagowanie jest rozbudowywane i wielopoziomowe więc trudno aby edytor pod androidem pozwolił wykorzystać cała paletę tagów jakimi operują edytory stacjonarne.
Dlatego każde narzędzie stara się przyspieszyć proces wyszukiwania tagu stosując podpowiedzi albo ograniczony zestaw tagów lub koncentruje się na jednej kategorii obiektów.
Mamy tu 3 problemy.
Zdolność precyzyjnego kreślenia.
Znajomość palety tagów.
Skrócenie wybierania tagów w szablonach.
Kolejna kategoria narzędzi uwzględnia fakt, że w ruchu nie możemy grzebać w apce czy to jadąc rowerem czy autem, bo to grozi wypadkiem.
Nie ma apek sterowanych głosem zatem takie narzędzie koncentruje się na jednej kategorii np. zbieranie adresów.
Takie narzędzia pozwalają jednym kliknięciem w ekran dodawać notatki głosowe, które są geolokalizowane albo miejscem puknięcia w ekran albo miejscem przebywania (znacznika GPS). Zamiast dyktafonu można nagrywać geolokalizowane filmiki i zdjęcia.
Przykładowo Osmand geolokalizuje te 3 rodzaje notatek.
Pomijam tu kwestie czy geolokalizacja jest dodawana do pliku aby różne programy mogły to odczytać.Generalnie nie potrzeba do tego jakiegoś programu tylko wystarczy tracker zapisujący ścieżkę GPS i należy tylko zsynchronizować czyli ustawić te same czasy zegara na dodatkowych urządzeniach jak dyktafony, aparaty, kamery.
Tu np. JOSM ma funkcje przypisania takich zdjęć i filmów do konkretnego miejsca na śladzie na podstawie znaczników czasu.
Zdaje się jest też możliwość wprowadzania przesunięcia czasu gdybyśmy zapomnieli o synchronizacji przed wyjazdem.
To jest dobra metoda, bo pozwala zapisać duże ilości danychgdy np. jedziemy drogą główną i co 50 m podajemy jakość dróg leśnych idących poprzecznie w las.
Zatem te narzedzia są uniwersalne, bo zwalniają z zastanawiania się nad tagami gdy co kilka sekund mijamy nowe obiekty.Pozwala to pracować i zaawansowanym maperom jak i tym nie znającym tagów.
Ci niekumaci mogą takie swoje notatki zamienić na notatki widoczne na stronie głównej osm.org.
Ponieważ nie ma dobrych map topograficznych jest sporo zamieszania gdy mijamy obiekty nie renderujące się na popularnych mapach.Mocno to irytuje i zmusza do częstego zatrzymywania się i sprawdzania czy obiekt jest już w bazie czy nie, co zwykle sprowadza się do niepotrzebnego ponownego opisywania obiektu bo to szybsze niż edycja.Gorzej gdy z braku czasu i nagromadzenia obiektów średniej wagi rezygnujemy z opisywania szczegółowego, czy sprawdzenia czy nie brakuje istotnego tagu.Np. mijamy pomnik przyrody i nie wiemy, że brakuje gatunku drzewa czy obwodu.
Można by wymienić wiele filozofii tworzenia narzędzi a autorzy apek tworzą coś uniwersalnego co usunie ich największe problemy.To powoduje, że maperzy naciskają aby poszerzać funkcje i z czasem robi się kombajn.
Przy ostatniej apce opisywanej na forum wypłynęły ważne kwestie, które z czasem stają się coraz bliższe rozwiązania. Czyli czy apka ma być offline czy online.
Jeśli online to wystarczy Vespucci, którym podglądamy wszystkie obiekty i wszystkie tagi, oraz możemy podłożyć dowolnego WMSa np orto.
Jeśli offline to sprawa się komplikuje tzn. jakiej mapy ma narzędzie użyć.
Mamy mieć mapy inne dla każdej apki?
Jak zgrać ograniczony obszar przed wyjazdem aby mieć aktualne dane?
Metoda pośrednia to użycie starej mapy np. z osmanda i dogrania do tego warstwy z błędami przygotowywanej przed wyjazdem.
I właśnie tu zauważam największe braki czyli drzemiące możliwości w tworzeniu idealnego narzedzia dopasowanego indywidualnie do każdego mapera a nie wymagające kombajnu
Sam niedawno odkryłem, że w JOSM można sobie opracować własny styl lub kilka styli tak aby JOSM graficznie pokazywał brakujące dane co bardzo usprawniło mi mapowanie .Zrobiłem sobie takie style do budynków oraz do area:highway.Trochę trudniej będzie zrobić dobry styl do 3D bo tam tagów wiele i rozmaitych kombinacji jeszcze więcej zatem trzeba się dobrze zastanowić jak wizualizować braki aby nie dostać oczopląsu.
Dobra apka/nakładka bezwarunkowo powinna importować wszystkie fixme, bo fixme zawierają zwykle rzeczy których nie można wygooglać.
I teraz należy się zastanowić jak umieszczać i wizualizować braki, które mogą być zawarte w notatkach, note, description itd.
Stawiam tezę, że lepiej nie tracić czasu na uzupełnianie braków a skupić się na sprawdzaniu rzeczy istotnych np fixme.
Adresy we wsi łańcuchowej da się odnaleźć w oparciu o adresy istniejące po sąsiedzku. Brak adresów na domach oddalonych od wsi widać na mapie i takie braki są dotkliwe.
Natomiast nie jest normalna sytuacja gdy maperzy latami przejeżdżają koło fixme i tego nie weryfikują.Nie jest normalne, że pomijają obiekty myśląc, że są w bazie dobrze otagowane a tylko się nie renderują.
Co jest potrzebne aby zrobić najprostszą apkę zapisująca notatkę we właściwej geolokalizacji?
Ponoć to banał, bo bo odpada cały interfejs a kilku kolegów już pisało lub zamierzało tworzyć apki.
Co jest potrzebne aby zaimportować np. overpassem obiekty jakie chcemy sprawdzić?
Prawdopodobnie to pikuś w porównaniu ze stworzeniem własnego stylu i wygenerowanie mapy.
Dziwne, że przez tyle lat nikt nie próbował uczyć maperów jak tworzyć nakładki np do osmanda dzięki którym wizualizuje się braki.
Tu ciekawy trend opisywany w ostatnich dniach, że program analizuje dane i podpowiada gdzie ewentualnie coś brakuje. Taki łatwy przykład to dziury w numeracji adresowej.
Możemy sobie wyobrazić apkę do mapy wektorowej, w której ustawimy filtr wyszukujący brakujący tag albo podbijający obiekt tzn. interesujące nas obiekty wyświetli na mniejszym zoomie.
Myślę, że koledzy wskażą więcej przykładów o czym apka powinna alarmować.
Aby nie przegapić ważnych braków (co mi się zdarza) apka mogłaby alarmować dźwiękiem gdy np. w promieniu "xxx m " jest jakiś bug.
Zatem dziwi że skoro program już zaczyna myśleć za nas i przeprowadza analizy, to dlaczego tak trudno zwizualizować to co od lat prosi się o weryfikację?
Gdyby koncentrować się fixme i podobnych to dodawalibyśmy do mapy nasze wątpliwości dużo częściej bo dziś wydaje się nam z ISOK_Cień że jest np mostek to go rysujemy bo jest 90-99% prawdopodobieństwo że jest przeprawa. Zmieniłoby się rozwiązywanie dziwnych notatek bo dziś fałszywymi notatkami można wiele namieszać, bo nawet nie ma kontaktu z autorem aby sprawdzić czy aby krzywo nie puknął w ekran
Istnienie apki z widocznymi wątpliwościami pozwoliłoby wciągnąć do współpracy różne środowiska czy to ludzi biegających i fotografujących czy tez przewodników PTTK itp.
Ci ludzie nie chcą mapować ale mogliby się chwalić znajomością terenu.Ludzi razi byk na mapie i chcą rywalizować na ilość poprawionych błędów.
Taka “mapa negatywna” czyli prośba o konkretną krótką pomoc np. na wykopie mogłaby zrobić więcej niż żmudne mapowanie 100x większej ilości danych.
Prosty przykład, mamy np. wykazy zabytków a w majątkach nie zawsze każdy budynek jest zabytkiem a i łatwo pomylić folwarki w wielkich łańcuchowych wsiach.Wiemy, że gdzieś w pobliżu jest np. pomnik w lesie ale boimy się go zmapować w złym miejscu.
Skoro dotąd tak oczywisty brak sensownych narzędzi nie był dyskutowany, to nie wiem czy ta dyskusja pozwoli opisać jak powinna wyglądać prosta ale niezastąpiona apka.
Zatem może zacząć od rzeczy najprostszych, które być może nie wymagają apki.
Jak osoba nie będąca informatykiem ma pobrać fixme i dodać je np. do osmanda i to tak aby opis fixme był widoczny?
Streszczając to to co najważniejsze dla OSM (czyli wątpliwości) nie jest obsługiwane i przez to nie jest weryfikowane i dopiero po powrocie z wyjazdu plujemy w sobie w brodę, że kolejny raz czegoś nie zweryfikowaliśmy.
Tak się możemy bawić latami.
Być może z powodu braku wizualizacji braków i wątpliwości, nie jest rozwijany tak ważny tag jak fixme aby odróżnić np. fixme=continue od fixme=Sprawdź czy odbudowano most po powodzi.
Liczę na propozycje co minimum apka mieć musi.
Może powinna pokazać braki open_hours a dla ważnych obiektów kiedy OH było aktualizowane np. nie dalej niż rok.
Brakuje też opcji “pukania w POI” dla potwierdzania, że dalej istnieją.