OpenStreetMap Forum

rowers2

Member

Registered: 2015-09-25

Posts: 583

OSM-retro

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.

wmyrda

Member

Registered: 2014-07-07

Posts: 947

Re: OSM-retro

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ł.

Również uważam, że pewna forma umożliwienia pobierania historycznych danych dla zaznaczonego obszaru jako osobną warstwę w JOSM była by wskazana.

A mówiąc żartem mapa ze skasowanymi obiektami miałaby większą oglądalność niż ta z istniejącymi.

Żartem, nie żartem. Jest to dość prawdopodobne

rowers2

Member

Registered: 2015-09-25

Posts: 583

Re: OSM-retro

Skoro były serwisy oferujące na mapie historię zmian ale ograniczoną do 4 lub max. 10 miesięcy, to znaczy, że te  dane nie były wyciągane w locie z bazy osm, a np. wyciągane z diffów i magazynowane na niezależnym serwerze, stąd dostęp do bazy tylko od dnia startu serwisu.
Jeśli zaś były wyciągane w locie przez Overpassa ( tak jak mapy Dotevo), to może ktoś podałby kwerendę do Overpassa na dane skasowane dla bbox-a,  i JOSM by to nie tylko pokazał, ale dał szansę  wysłania do API wybranych obiektów celem reanimacji.

Jeśli zaś trzeba by tworzyć tabele w Postgresie czy innym programie, to chyba marimil takowe tworzy dla wizualizacji, można by tylko poszerzyć je o obiekty skasowane.
Rozumiem, że takie tabele można by czytać  chronologicznie np. dla wybranych województw a stosując np. Excela z filtrami można by przeglądać tylko wybrane kategorie np.  amenity lub dodatkowo je filtrując dla konkretnego value.
Problematyczny jest rozmiar pliku Excela aby przeglądać dane z roku lub dłużej.
Bboxa można by filtrować podając 4 narożniki dla których współrzędne widać w JOSMie w zakładce Obszar Edycji.
Jakkolwiek archiwizowanie ID obiektów i ich tagów byłoby wykonalne, to już współrzędne  nodów wielkich obiektów nadymałoby tabele.
Z pozytywów to skasowany obiekt mógłby pamiętać tylko ostatnią wersję z jej geolokalizacją nodów.Gorzej jeśli ktoś powyginałby obiekt a dopiero w kolejnym changesecie skasował go zupełnie.
Tu też pytanie do fachowców czy OSM pamięta geolokalizację każdej wersji  (raczej musi) więc mając ID powinno się dać dowolną wersję przywrócić.

Jakakolwiek by długa tabela nie była, nie ma sensu tego podglądać przez www czy ciągnąć plik Excela,  więc filtrowanie musiałoby być po stronie serwera.Można by się ograniczyć tylko do skomplikowanych obiektów, czyli relacji czy obiektów mających więcej niż 15 nudów oraz POI przynajmniej tych najczęściej występujących.
Można by też wprowadzić zasadę, że przed skasowaniem należy do obiektu dodać jakiś tag, że kasowanie odbywa się 'przytomnie", a nie przez nieuwagę,to monitorować  można by tylko te obiekty, które skasowano bez stosownej notki.Wtedy bot mógłby alarmować od ręki gdyby jakiś nowicjusz wziął się za kasowanie.
Najwięcej ginie chyba adresów przy kasowaniu wyburzonych budynków ale to chyba nie problem, bo łatwo to odtworzyć z WMSa  gdy nowy budynek zbudują.

Szczególnie warto by monitorować kasowanie takich tagów, które powodują że ich brak ściąga obiekt z renderu aby doświadczeni maperzy przyjrzeli się czy nie można otagować tak aby render wrócił a nie było to "niepoprawne tagowanie pod render".

Choć to OT to dorzucę, że wiele informacji ginie, bo niedoświadczeni maperzy zamiast dać je  do notatek, to zakładają np. node z name,  lub  info dodają do obrysów nie renderujących się jak:   area=yes,  area=private, shop=*   itd.
Tu być może przybędzie ułomnych edytorów jak maps.me, których efekty pracy nie renderujące się trzeba by wyłapywać na bieżąco.

ITO_WORD wizualizuje każdą pierdołę w ok 150 wizualizacjach, a zmiany ma na wizualizacji z ostatnich 7 lub 30 dni. Może to się sprawdza w Afryce ale nie w Europie gdzie wystarczyłoby wizualizować obiekty skasowane. Myślę, że i osmapa mogłaby mieć Delete=max30 dni koloryzowane w zależności od starości, bo monitorowanie codzienne jest irytujące a starsze zmiany choć są wizualizowane to zdaje się bez name usera.
Obiekty krzywo zmodyfikowne wyłapiemy na edytorze i historia podpowie kto mieszał
Przydałby się jakiś styl na JOSMA  kolorujący obiekty, którym zmieniano ostatnio tagi np. 30-60 dni przez innego usera niż my.
Jeden kolorek na tagi ze zmodyfikowanym value, a inny na skasowane key-e.

Prośba o składnię zapytania do funkcji SZUKAJ w JOSM na dane modified przez "innych userów", z zawężeniem czasowym (może timestamp),  z wykorzystaniem takich funkcji jak widoki czy selektor MapCSS, bo jeszcze tego nie ćwiczyłem.

Może coś podobnego na Overapssa w JOSMie, to i odmienne kolorki by się znalazły.
Czy kwerenda przez JOSMA potrafi kolorować obiekty i czy overpass potrafi porównywać dwie wersje tego samego obiektu,czyli czy coś było zmieniane w tagach?

Last edited by rowers2 (2016-07-24 17:50:57)

ndmystko

Member

Registered: 2013-07-15

Posts: 245

Re: OSM-retro

Również uważam, że pewna forma umożliwienia pobierania historycznych danych dla zaznaczonego obszaru jako osobną warstwę w JOSM była by wskazana.

Ja znalazłem taki skrypt do pobierania historycznych danych:

<osm-script date="2015-12-31T07:20:07Z" timeout="900">
  <bbox-query into="_" {{bbox}} />
  <union into="_">
    <recurse from="_" into="_" type="up"/>
	<recurse from="_" into="_" type="down"/>
  </union>
  <print e="" from="_" geometry="skeleton" limit="" mode="meta" n="" order="id" s="" w=""/>
</osm-script>

Wrzuciłem w http://overpass-turbo.eu/ i zadziałało. JOSM zdaje się ma wsparcie dla overpassa, prawda? Nie wiem czy pobrałby do oddzielnej warstwy.