Wandalizmy w OSM i im zapobieganie

miklobit1 · 2013-10-14T10:50:10.000Z

serekmedia:

miklobit - to nie wymaga 3 baz, baza byłaby tylko jedna == stable, pozostałe dane to suma stable+testing lub stable+testing+live.

Być może (bo też nie chcę wchodzić w szczegóły systemu którego dobrze nie znam) jedna baza byłaby wystarczająca.
Natomiast wymaga to zmian w całym procesie - od zapisu danych po ich czytanie.
Rozmnożenie danych (choć jest nieefektywne i zajmuje zasoby) upraszcza jednak realizację całego pomysłu i co najważniejsze - pozwala zrobić ( choćby dla testu ) wersjonowanie dla wybranego podzbioru, czyli baza live zostaje bez zmian tak jak teraz (cała planeta) , a do test i stable ciągniemy n.p. tylko dane dla Polski.

serekmedia · 2013-10-14T16:48:07.000Z

Tzn spójność danych jest tu kluczowa, a uzyskanie tego na kilku bazach byłoby “średnie”. Tak pomału analizując to chyba na dodawane nody i linie wystarczyłyby dodatkowe tablice w modelu live i testing, a obecny stan tablic pozostawić jako stable (w domniemaniu że większość narzędzi obecnych na rynku używać będzie stable do pracy produkcyjnej). Pozwoliłoby to zachować kompatybilność wsteczną z nimi, a budując odpowiednie widoki można by wyjmować dane z testing i live.
Niestety tu się łatwe rzeczy kończą, ponieważ w tym momencie chengeset może być zapisany, albo robi konflikt. W projektowanym modelu dochodzi konflikt ‘wsteczny’ czyli mamy stable->changeset i na to wchodzi wchodzi następny changeset (modyfikujący poprzedni) i teraz chcemy usunąć ten ze środka, to co zrobić z tym “wyżej”? Możemy poinformować usera o “problemie” że jego dane mogą zostać usunięte jeśli changeset ze środka też zostanie skasowany - ale to trochę chore. Dobrze byłoby podczas edycji widzieć które nody/poly/tagi nie są jeszcze zaakceptowane, aby ich unikać lub robić modyfikacje z głową - albo zapisujemy nowy changeset obejmujący cały poprzedni i swoje zmiany i przesuwamy datę jego akceptacji na max naszego statusu - w ten sposób możemy np przenieść changeset nowicjusza od razu do testing (zrobiony przez, zaakceptowany przez). Niestety istnieje niebezpieczeństwo że na obszarze o częstej edycji changeset mógłby nigdy nie zostać zaakceptowany bo w kółko ktoś by go modyfikował
Czyli w skrócie mamy bazę stable + bazę changesetów - pobieramy obszar do edycji - dostajemy bbox stable+dane z changesetów które obejmuje, zapisując swój kasuje się poprzedni, a nasz zawiera komplet i nową datę wejścia do stable (należy też zachować dane o autorach odpowiednio). Dostajemy więc w kolejce testing spójną serię niezależnych changesetów które czekają na potencjalne błędy, ale które bezkonfliktowo można wgrać do stable. Można też pomyśleć o awaryjnym wgraniu do stable, np serią kilku “podpisów” zaawansowanych userów np.
Z resztą podobnie jest z akceptacją pakietów w debianie - przechodzi wyżej jeśli przez ileś tam czasu nie znaleziono/nie zgłoszono w nim błędu.

miklobit1 · 2013-10-14T18:14:53.000Z

To jeszcze inny wariant jest możliwy:
( cały czas biorę pod uwagę jedynie pomysły, które są możliwe do przetestowania w skali lokalnej oraz takie które nie wymagają zgrzebania tego co działą w tej chwili )
baza live jako jedyna baza na której są możliwe bezpośrednie edycje przez userów.
Test zasilany diffami z bazy live ( a stable z testa ), z tym, że changesety “zwykłego” usera wchodzą z opóźnieniem n dni
a edycje “naprawcze” power userów mogą być puszczone szybciej (i wtedy automat musiałby okreslać dla danego obiektu sposób scalenia zmian z “normalną” edycją )
Oczywisćie nie mam pewności czy ta koncepcja w szczegółach trzyma się kupy w przypadku bazy OSM, ale dokładnie tak działa wersjonowanie zmian w dużych systemach (typu ERP).
Czyli test i stable (tzw baza “produkcyjna”) są zamknięte do bezpośredniej modyfikacji a szybka ścieżka przepuszczenia zmian od live do test/stable jest zarezerwowana dla wybranych osób które na 100% wiedzą co robią i wykorzystaują uprawnienia tylko dla celów naprawczych

serekmedia · 2013-10-15T07:53:18.000Z

Dobry pomysł! Taki automat robiący zbiorcze changesety można by napisać, działałby z opóźnieniem to raz, dwa kompletował by zależności między nimi i je kolejkował poza bazą główną. Jak changeset osiągnie “stabilność” ze wszystkimi zależnościami to byłby dodawany do bazy. Myślę że byłby to fajny ficzer np osmosisa - no i mniej by rozpychał tabele pg na replice.
Co więcej nie wymaga zmian w projekcie, a umożliwia utrzymanie stabilnej bazy od strony użytkownika danych. Po stronie użytkownika też pozostaje kwestia odsunięcia czasu stabilizacji dla userów (zna przecież listę userów ich “datę urodzenia” w systemie i ilość edycji).

postworek · 2013-10-15T10:33:44.000Z

Litości… po co wprowadzać opóźnienie, skoro już teraz pojawiają się pytania “gdzie moje zmiany, czemu się nie renderują?” przy kilkuminutowym opóźnieniu. A wy chcecie to opóźniać np. o tydzień! Moim zdaniem zmiany powinny być widoczne od razu, nawet szybciej niż dzisiaj. Jakiekolwiek opóźnienie lub moderacja (“ty nowy, to najwyżej możesz sklepik osiedlowy dodać, ale wiejską drogę już nie”).
Rozwiązaniem jest blokowanie rzeczy “niezmiennych” - jak relacje głównych dróg, obszary administracyjne itd., a nie wprowadzanie opóźnienień.

panrudzki · 2013-10-15T10:37:47.000Z

postworek:

Rozwiązaniem jest blokowanie rzeczy “niezmiennych” - jak relacje głównych dróg, obszary administracyjne itd., a nie wprowadzanie opóźnienień.

Nie ma rzeczy niezmiennych…

Drogi główne też się zmieniają.

Ja jako wciąż jeszcze początkujący użytkownik mogę podpisać się dwoma rękoma pod tym, że możliwość szybkiego startu była dla mnie głównym czynnikiem, który “zaraził” mnie OSM. Nie wolno tego niszczyć!

Co natomiast robić z sabotażystami? Chyba nie ma innego wyjścia niż jakiś dobry mechanizm back-upów, aby dało się łatwo i szybko odtworzyć to, co zostałoby zniszczone.

miklobit1 · 2013-10-15T10:51:44.000Z

Podane koncepcje nie mają żadnego związku z opóźnianiem wizualizacji zmian.
Baza “live” i jej domyślny render byłyby aktualizowane tak jak do tej pory .
Natomiast każdy , kto chce mieć stabline i bardziej wiarygodne dane mógłby mieć wybór czy pobiera eksport (lub zasila się diff’ami ) z bazy live czy z wersji odstanych i odfiltrowanych.
Dane offline do nawigacji i tak są generowane w cyklach co najwyżej tygodniowych a mało kto aktualizuje mapy co tydzień.
Tak więc ew. realizacja w/w projektu byłaby tylko i wyłącznie wartością dodaną która niczego nie psuje ani nikogo nie zmusza do korzystania z tych wersji danych

Zibior2 · 2013-10-25T21:12:48.000Z

A ja mam jeszcze inny pomysł. Chodzi o poprawę kontaktu z resztą mapującej społeczności. Teraz zdarza się tak, że mapujący nawet nie są świadomi tego, że ktoś do nich pisze. Czasem bywa tak, że ludzi mi odpisują w tonie “przepraszam, ale nie zauważyłem maila, bo rzadko zaglądam na tę skrzynkę” nawet po pół roku od wysłania maila! (rekordzista odpisał po roku).
Może problem wydaje się banalny, ale jest kilku taki userów (np. rosomak, blackstarr, wfl, koreb), którzy zupełnie nie odpisują na wysyłane maile i nawet nie wiadomo, czy po prostu nie chce im się odpisać czy może nie otrzymują tych wiadomości, bo przy rejestracji podali spamowy adres e-mail, na który nie zaglądają.

Rozwiązanie jest dosyć proste - powinna być blokada wysłania zmian na serwer (a ściślej: utworzenia nowego changesetu) dopóki w skrzynce odbiorczej OSM jest chociaż jedna nieprzeczytana wiadomość.

Marku, rzuć tym pomysłem na forum niemieckim, ciekaw jestem jaki będzie odzew

ppece · 2013-10-25T21:26:53.000Z

Zbigniew_Czernik:

A ja mam jeszcze inny pomysł. Chodzi o poprawę kontaktu z resztą mapującej społeczności. Teraz zdarza się tak, że mapujący nawet nie są świadomi tego, że ktoś do nich pisze. Czasem bywa tak, że ludzi mi odpisują w tonie “przepraszam, ale nie zauważyłem maila, bo rzadko zaglądam na tę skrzynkę” nawet po pół roku od wysłania maila! (rekordzista odpisał po roku).
Może problem wydaje się banalny, ale jest kilku taki userów (np. rosomak, blackstarr, wfl, koreb), którzy zupełnie nie odpisują na wysyłane maile i nawet nie wiadomo czy po prostu nie chce im się odpisać czy może nie otrzymują tych wiadomości.

Rozwiązanie jest dosyć proste - powinna być blokada wysłania zmian na serwer dopóki w skrzynce odbiorczej OSM jest chociaż jedna nieprzeczytana wiadomość.

E tam, to nie przejdzie. Takie coś ogranicza z założenia nieograniczony dostęp do danych. Przecież dlatego użytkownicy wybierają OSM ponad konkurencję, by mogli skupić się na mapowaniu, a nie jakimś tam czasochłonnym czytaniu korespondencji - nie mogliby od razu wysłać, a zatem i zobaczyć swoich zmian

jerrystef · 2013-10-25T21:35:08.000Z

a ja uważam, że taka blokada - nie odczytasz maila nie edytujesz - jest jak najbardziej prawidłowa.

Polimerek · 2013-10-25T21:56:54.000Z

jerrystef:

a ja uważam, że taka blokada - nie odczytasz maila nie edytujesz - jest jak najbardziej prawidłowa.

No nie wiem - są userzy “samotnicy”, którzy odwalają kupę roboty a nie mają ochoty na jakiekolwiek kontakty z innymi mapowiczami. W Wikipedii też występuje takie zjawisko - pamiętam jednego usera, który pisał świetne artykuły o kolejnictwie i nigdy nikomu nie odpisał na żaden mail ani wpis na stronie dyskusyjnej - jakbyśmy go zablokowali to by nie było wielu dobrych artykułów. IMHO sam fakt nieodpowiadania nie powinien być przesłanką do blokowania - jedyną przesłanką powinno być uporczywe wandalizowanie czy też systematycznie nie trzymanie się ustalonych reguł mapowania.

Zibior2 · 2013-10-25T22:10:19.000Z

@Polimerek: mam wrażenie, że nie zrozumiałeś o co mi chodzi. Nie chodzi mi o blokowanie kogoś za brak odpowiedzi, lecz o zmuszenie usera do przeczytania tego, co inni mapowicze mają mu do powiedzenia. No bo powiedzmy sobie szczerze - w jaki inny sposób można zakomunikować userowi, że robi coś źle? Ciągle go rewertując? Może tego nie zauważyć, poza tym szkoda marnować czyjąś pracę.

jerrystef · 2013-10-26T06:58:31.000Z

myślę że Polimerek nie do końca mnie zrozumiałeś. Nie odczytasz maila- nie edytujesz dalej nie jest blokadą ale wyraźnym przesłaniem informacji - przecież w jakiś sposób trzeba też zachować swoją pracę, bo hipotetycznie napracowałeś się mocno rysując… a ktoś dokonuje mocnych korekt i usunięć - co wtedy - piszesz do gościa, który okazuje się samotnikiem - i ma gdzieś jakiekolwiek wiadomości. Jakie kroki podejmiesz? Pewnie będziesz chciał aby ktoś dokonał rewertu zmian, ale czy nie szkoda czasu na kolejne cofanie zmian. Myślę że Zbigniew to co proponuje jest racjonalne.

serekmedia · 2013-10-26T09:44:27.000Z

Zbigniew_Czernik:

No bo powiedzmy sobie szczerze - w jaki inny sposób można zakomunikować userowi, że robi coś źle? Ciągle go rewertując? Może tego nie zauważyć, poza tym szkoda marnować czyjąś pracę.

Narysować mu autostradą pod domem treść wiadomości

RitterR · 2013-10-26T10:22:55.000Z

Może nie blokujmy na wszystkie wiadomości w skrzynce, ale na wiadomości zawierające określone treści/znaczniki.
Na podstawie tego znacznika przy logowaniu lub zapisywaniu zmian system wyświetlał by odpowiedni komunikat lub dodatkowo treść wiadomości.

Ustalić kilka typów błędów i zasady z nimi związane. Dodatkowo logikę ich obsługi przez system. Zbyszek ma tu z pewnością duże doświadczenie z takimi userami.

Dodanie tagu ręcznie lub wybierając z listy do wiadomości wysyłanej przez osobę zgłaszającą uwagi.

blocked=info - drobne błędy i uwagi; nie trzeba odpowiedzieć na wiadomość; można zapisywać zmiany.
np. “Użytkownik xyz znalazł w twoim zestawie zmian 12345 błędnie tagowanie. Szczegóły w wiadomości”

blocked=warning - większe błędy: niestyki, bylejakie odwzorowania, błędne modyfikacje; trzeba odpowiedzieć na wiadomość aby można było zapisywać zmiany
Np. “Użytkownik xyz znalazł w twoim zestawie zmian 12345 poważne błędy. Szczegóły w wiadomości. Dalsza edycja wymaga odpowiedzi na wskazana wiadomość”

blocked=wandal - Jak ktoś ewidentnie psuje mapy czy kasuje dane; trzeba odpowiedzieć na wiadomość aby można było zapisywać zmiany; Użytkownik z takim oznakowaniem był by monitorowany prze OSM, tzn. jego modyfikacje były by gdzieś rozgłaszane aby osoby dbające o porządek na mapie miały ich na uwadze. Duża ilość wiadomości z takim znacznikiem blokowała by konto na dłużej, aby zniechęcić do dalszej bezmyślnej zabawy.
Np. “Użytkownik xyz wskazał twój zestaw zmian 12345 jako wandalizm. Szczegóły w wiadomości. Dalsza edycja wymaga odpowiedzi na wskazana wiadomość. Szanuj pracę innych osób”

Zibior2 · 2013-10-26T10:34:32.000Z

@Ritter: ale czy wejście na skrzynkę osm to naprawdę aż tyle zachodu, żeby tak komplikować sprawę i bawić się w jakieś “określone treści/znaczniki”? Wydaje mi się, że nie…

koszatek · 2013-10-26T11:18:16.000Z

Mnie trochę brakuje jakiegoś wygodnego systemu komunikacji z innymi autorami od razu na poziomie JOSMa i innych edytorów. Chodzi o coś takiego: edytuję jakiś obszar, widzę “dziwny” obiekt, to zaznaczam, klikam/naciskam jakiś klawisz, wyskakuje okienko typu “send comment to author(s)”, wpisuję tam “skąd to wziąłeś?”, taki message idzie do autora jako konkretnie otagowana wiadomość prywatna i on może ją odczytać tak jak zwykły PM albo wyskakuje mu okienko w JOSM. JOSM może sam na starcie a potem co jakiś czas sprawdzać czy są nowe w taki sposób otagowane wiadomości i pokazywać okienko i wymuszać jakąś reakcję (choćby to miało być kliknięcie guzika “mam to w d***”).

Polimerek · 2013-10-26T19:08:01.000Z

koszatek:

Mnie trochę brakuje jakiegoś wygodnego systemu komunikacji z innymi autorami od razu na poziomie JOSMa i innych edytorów. Chodzi o coś takiego: edytuję jakiś obszar, widzę “dziwny” obiekt, to zaznaczam, klikam/naciskam jakiś klawisz, wyskakuje okienko typu “send comment to author(s)”, wpisuję tam “skąd to wziąłeś?”, taki message idzie do autora jako konkretnie otagowana wiadomość prywatna i on może ją odczytać tak jak zwykły PM albo wyskakuje mu okienko w JOSM. JOSM może sam na starcie a potem co jakiś czas sprawdzać czy są nowe w taki sposób otagowane wiadomości i pokazywać okienko i wymuszać jakąś reakcję (choćby to miało być kliknięcie guzika “mam to w d***”).

No to fakt - ja też na początku czułem brak narzędzi komunikacji z innymi userami. JOSM-em mogę edytować miesiącami i nie wiedzieć o tym, że ktoś tam coś napisał do mnie przez mechanizmy wysyłania komunikatów na stronie OSM., bo tam w sumie w ogóle nie muszę zaglądać a w programie pocztowym wysyłać automatycznie wszystkie komunikaty ze strony OSM do spamu, ew. mieć w koncie podane konto e-mail, do którego w ogóle nie zaglądam… Ale raczej zamiast blokady userów za to, że nie odpiszą, czy nie zaznaczą, że przeczytali komunikat - powinien być wdrożony jakiś system powiadamiania, który na pewno dotrze do każdego, kto edytuje mapę, niezależnie od narzędzia jakim to robi. Ale to pewnie powinno być wszyte w API OSM - wtedy JOSM i inne narzędzie pewnie mogły by te mechanizm zaimplementować łatwo. Np przy wysyłce, API w komunikacie akceptacji zmian dołączało by drugi komunikat, "masz X wiadomości nieprzeczytanych - z likniem do kilknięcia na stronę usera w serwisie OSM. Większość by tam zajrzała choćby przez ciekawość.

Zibior2 · 2013-10-27T10:17:52.000Z

Polimerek:

Ale to pewnie powinno być wszyte w API OSM - wtedy JOSM i inne narzędzie pewnie mogły by te mechanizm zaimplementować łatwo.

Zgadza się. Tylko ja patrzę realnie i nie liczyłbym na zmianę czegokolwiek w API, a dorobienie takiej blokady, o której mówię, byłoby łatwiejsze do zakodowania niż zmienianie API.

Mateusz_Konieczny · 2013-10-28T11:38:34.000Z

Zbigniew_Czernik:

Polimerek:

Ale to pewnie powinno być wszyte w API OSM - wtedy JOSM i inne narzędzie pewnie mogły by te mechanizm zaimplementować łatwo.

Zgadza się. Tylko ja patrzę realnie i nie liczyłbym na zmianę czegokolwiek w API, a dorobienie takiej blokady, o której mówię, byłoby łatwiejsze do zakodowania niż zmienianie API.

Szczerze wątpię by to prawda była. Mam nadzieję że w tym momencie można to zrobić, nie mam czasu się tym zająć więc puściłem FR dla JSOM - http://josm.openstreetmap.de/ticket/9234#ticket

PS

Ops, JOSM.