OSM to nie mapa tylko baza danych. Jako laika dziwią mnie rozmaite ograniczenia obsługi baz danych na przykładzie OSM.
Utrudnia nam to pracę, bo np.mamy ograniczenia w przeglądaniu historii zmian, np. niedawno wprowadzono możliwość zachowania historii ze starego obiektu na wybranej części obiektu podzielonego.Tu nie będę opisywał wszystkich perturbacji ale gdy np. mała cząstka starego obiektu trafia do kosza to wraz z historią całości.
Niektóre nawet nieduże obiekty mają w historii ponad setkę zmian, a że taką historię OSM zachowuje tzn. że nie ma ograniczeń co do pamięci na dyskach.
Jeden z przykładów to ograniczenie JOSM, który nie pokazuje historii zmian relacji. Koledzy którzy monitorują pracę innych, zapewne wymieniliby długą listę utrudnień.
Pomyślałem sobie, że skoro tak trudno monitorować, szczególnie obiekty usunięte, to można by stworzyć drugą bazę OSM takie OSM-Retro, gdzie jak do kosza zamiast w nicość, trafiałyby usunięte elementy.
Ale przecież taka baza nie jest potrzebna, bo jeśli znamy ID obiektu to historię możemy pobrać z OSM.
Dlaczego zatem tak trudno stworzyć narzędzia (ogólnodostępne) aby w formie tabel np. po odpytaniu overpassem do zawężonego obszaru, można było monitorować i filtrować dane czy to usunięte czy zmodyfikowane?
Jedna z możliwości to akceptowanie takich zmian. Nie koniecznie moderacja lub moderacja ograniczona do nowicjuszy (już takie propozycje padały), ale podgląd czyli ułatwienie monitorowania.
Zmiany nowicjusza tak jak dziś trafiałyby od razu do renderingu, ale można by po zauważeniu dziwnych działań przeglądnąć zmiany wstecz na dłuższym odcinku niż jeden dzień/tydzień.
Filtry mogłyby być połączone z systemem komentarzy, tzn jeśli zobaczyłbym, że jakiś user ma wiele zaaprobowanych zmian (pozytywów) to gdy user wszedłby na mój obszar zainteresowania. nie musiałbym sprawdzać jego historii dokonań ani monitorować bieżącej pracy.
Maper z dużą historią dokonań czyli doświadczony, w praktyce nie podlega sprawdzaniu, bo zakładamy, że gdyby robił głupoty to by dawno były wychwycone. Ale maper z niewielką praktyką czy z długą przerwą, czasem jedzie na jakimś “koniku” do czasu aż ktoś zauważy i udzieli mu rad.
Była forsowana zasada, że nowi jeśli coś skasują, to mają się przyznać a nie uciekać, ale to nie działa
Problem będzie narastał w miarę kompletności danych, bo nie jesteśmy wstanie spamiętać co zmapowaliśmy, a gdy wydaje się nam, że coś zniknęło to sprawdzanie “co, jak i kiedy” jest pracochłonne, a często niemożliwe.
Zatem mam pytanie do biegłych w bazach danych, czy to naprawdę niemożliwe aby w prosty sposób pobierać dane skasowane?
Czy JOSM nie mógłby ich pobierać jako niezależną warstwę?
Czy nie dałoby się np. 5 ostatnich modyfikacji pobrać do 5 rożnych warstw aby ten sam obiekt zwizualizować ze wszystkimi nodami i ich poprzednią geolokalizacją? Dzięki przezroczystości warstw szybko można by ustalić jaki problem maper chciał usunąć gdy ciął jakiś obiekt lub przesuwał.
Zamiast rewertować całe changesety można by poprzednią wersje obiektu wysłać na serwer a skasować obecną, co wyeliminowałoby stratę czasu na ponowne wrysowywanie.
Gdyby odfiltrować do jednego usera czy zakresu dat, szybko można by wyłapać, że ktoś pracuje na kiepskim podkładzie.
Coś takiego chyba jest możliwe np. JOSM pozwala po ściągnięciu konkretnego changeseta wysłać na serwer pojedynczy obiekt ale brakuje mi funkcjonalności przeglądnięcia zmian jakieś miejscowości w ciągu np. miesiąca (wszystkich maperów lub z krótkim stażem) aby było coś więcej widać niż tylko białe plamy po obiektach jakie zniknęły.
Tu właśnie kłania się to czego nie rozumiem, dlaczego po podzieleniu way, nowy odcinek nie może pozostawić autorstwa pierwotnego autora, co ułatwiłoby filtrowanie np. tylko nowych obiektów. Wygląda to na zwalnianie dysków z historii choć przecież dane co do autora i changeseta to nic w stosunku do danych każdego noda, które zostają na obu obiektach po podzieleniu.
Przykładowo wizualizacja marimilla ostm, nie pozwala rzutem oka sprawdzić czy niebieskie way są nowe czy tylko podzielone. Marimil potrafi wszystko, więc jeśli tak zrobił tzn że nie da się?
Podobny problem to modyfikacje czyli u marimila “zielone”.
Czy nie dałoby się wizualizować czy poprawiono geometrię czy też tagowanie?
Przykładowo czy dodano tagi, czy też kasowano lub modyfikowano istniejące, co już jest podejrzane.
Czy przesunięto cały obiekt czy tylko część nodów? Czy przesunięcie całego obiektu jest w ramach różnic podkładów (np 3 m) czy też przesunięcie jest duże
Czy obiekt niedawno dodany lub modyfikowany został przesunięty, czy też obiekt stary, czyli że mógł być rysowany do biga?
Propozycji monitowania byłoby zapewne wiele, ale chyba zgodzimy się, że najtrudniej zobaczyć to co skasowano.
Ograniczeniem bazy danych nazywam fakt, że np.do obiektu skasowanego nie można dodać tagów, że dokonano moderacji i zaakceptowano skasowanie. Oczywiscie z map obiekt znikałby bez moderacji. Wtedy spece z jakiejś dziedziny mogliby moderować parki krajobrazowe, granice administracyjne itd. a nie przeglądać wszystkiego na małym obszarze, bo to syzyfowa robota polegająca na przeglądaniu dobrych zmian zamiast tylko podejrzanych.
Marzy mi się automat strażnikujący, że został skasowany jakiś obiekt, a w odpowiednim promieniu od skasowanego nie powstał nowy z identycznymi tagami i zbliżonymi rozmiarami np. w ramach tego samego changeseta. Prosty algorytm mógłby też dzielić liczbę dodanych nodów przez nowego mapera, przez liczbę kasowanych obiektów, co oznaczałoby, że maper z dużym wkładem mógłby kasować więcej bez podnoszenia alarmu.
Najprostsza wizualizacja to taka pokazująca skasowane obiekty mające więcej niż 8-10 nodów co pozwoliłby wyłapać skasowanie lasów czy skomplikowanych budynków.Obszary skasowane na skutek łączenia dwóch w jeden, nie powinny być wizualizowane jako skasowane lecz jako modyfikowane, ale to może być trudne.
A mówiąc żartem mapa ze skasowanymi obiektami miałaby większą oglądalność niż ta z istniejącymi.