Wandalizmy w OSM i im zapobieganie

postworek · 2013-10-09 13:24:43

Moderacja na wikipedii zaczęła się od zablokowania edycji wybranych haseł (np. kontrowersyjnych). Może jest to jakaś metoda. Przebieg dróg czy ich kategoria nie zmienia się z dnia na dzień i kilka osób (moderatorów) w zupełności jest w stanie to ogarnać. Na pewno nie można moderować nowych użytkowników, bo to tylko wzbudzi ich frustrację. Jedni biorą się za edycję przebiegu autostrady (tego powinno się zabronić) inni dodają tracki w lesie (jak się pomylą, to ktoś kiedyś poprawi). Nie można ich wrzucać do jednego worka "nowicjuszy", bo osm zostanie z samą elitą, ale bez danych, bo nie będzie miał ich kto wprowadzać.

serekmedia · 2013-10-09 15:31:17

OMG! Raz Benek - sorry ale w połowie wymiękłem
Dwa - nie sugeruję moderacji! Proszę nie nazywajcie tego moderacją. Kafelki nadal powinny renderować się z bazy LIVE - a nawet szybciej niż teraz, tak aby szło widzieć swoje zmiany JUŻ. Jak ktoś potrzebuje kafelków stable to prosimy pod inny url.
Ja sugeruję tylko izolację danych - bufor czasowy - czas na stabilizację tych danych. Ktoś jak potrzebuje danych stabilnych - z gwarancją że nie trafi tam most ze Świnoujścia do Ysta - ma mapę stabilną lub testing - no z tygodniowym/dniowym opóźnieniem - ale nieraz ważna jest nawet pobieżna moderacja kluczowej sieci dróg/wód/granic niż bazowanie na "piaskownicy".
Też dałeś dobry przykład - dla testu poustawiałeś sobie pudełka z różnymi tagami aby zoabczyć co i jak i spoko, masz kilka dni aby to posprzątać i nie trafi to w ogóle do danych stable ani testing jak jesteś nowicjuszem!
Ja nie mówię że to rozwiąże problemu małych uliczek w małym miasteczku - tego nic nie rozwiąże do póki nie będziemy mieli po 2 maperów na miasto i trzeciego arbitra dla nich Natomiast rozwiąże problemy powiedzmy globalne: trwałość relacji podziału administracyjnego czy szkieletu dróg do DW włącznie - a te 2 elementy to baza mapy.

Mateusz Konieczny · 2013-10-09 15:43:03

Co do JOSM - jeśli zgłosi się im dobry pomysł to zazwyczaj go użyją (moje zgłoszenia, część już zrealizowana: http://josm.openstreetmap.de/query?repo … ulwersator). JOSM już teraz próbuje wykrywać ewidentnie błędne edycje, więc na http://josm.openstreetmap.de/newticket można zgłaszać sytuacje gdzie tego brakuje (tak przy okazji: tam angielskiego używają).

Last edited by Bulwersator (2013-10-09 15:43:23)

Wojciech Brzeziński · 2013-10-09 18:11:37

benek wrote:

Nikomu się nie chce korzystać z tak oczywistych narzędzi pokazujących błędy oczywiste.
Głównie chodzi o brak czasu

Używam keepright-a z uporem maniaka.
Generalnie zgadzam się z twoimi wypowiedziami, chociaż jednak nawigację uznaję za główny cel OSM (przynajmniej na teraz).
Że też chciało Ci się tyle pisać, a mi czytać

Polimerek · 2013-10-13 10:58:03

zVID wrote:

Pomysł Zbyszka na moderację prac początkujących jest chyba najlepszym co można zrobić. Obawiam się jednak, że obecnie mamy chyba za mało społeczników o wystarczająco dużym doświadczeniu w mapowaniu i dysponujących odpowiednio dużym zasobem czasu by podołali w miarę szybkim przeglądaniu zmian. Podniosą się zarzuty o opóźnieniu w czasie od wprowadzenia zmian a ich zaistnieniem. Ale innego wyjścia chyba nie ma.

W Wikipedii też jest ciągły lag z zatwierdzaniem zmian w artykułach mających wersje przejrzane. Niektóre zmiany czekają nawet do dwóch tygodni. Z tymże w OSM - to by był dodatkowy problem z ciągłością bazy. W Wikipedii treść jest jednoznacznie podzielona na poszczególne artykuły, także czekające do zatwierdzenia zmiany w jednym artykule nie wpływają w żaden sposób na inne. W OSM by był problem polegający na tym, że trzeba by rozwiązać jakoś konflikty edycyjne z niezatwierdzonymi zmianami - gdy jakieś zmiany newbie czekają na przejrzenie - a ktoś nie-newbie w tym czasie zaczyna w tym obszarze edytować. Wtedy musiałby być mechanizm, który by informował o oczekujących na zatwierdzenie zmianach i edytor "nie-newbie" miałby opcję - albo zatwierdzić przed swoją edycją zmiany newbie, albo je zrewertować... + jest jeszcze kwestia nakładających się kolejnych zmian, kolejnych newbie na tych samych obiektach - czy drugi newbie miałby pracować na wersji przejrzanej, czy na przerobionej przez poprzedniego newbie? I do tego jeszcze newbie w Wikipedii może szybko zobaczyć efekt swojej pracy klikając na zakładkę "wersja robocza" - w OSM by była kwestia tego, czy standardowy render mapy miałaby być w dwóch wersjach? Sprawdzonej i roboczej ? Podjerzewam, że to by oznaczało podwójne obciążenie serwera renderującego.

W Wikipedii jest też tak, że newbie dostaje uprawnienia redaktora - czyli osobnika, którego edycje same się zatwierdzają i który ma prawo moderować edycje newbie - z automatu - po miesiącu działalności i wykonaniu co najmniej 100 poprawnych edycji.

Mnie jako niedawnemu stosunkowo jeszcze newbie w OSM - brakowało klawisza "podglądu". W Wikipedii przed zapisaniem artykułu można obejrzeć jak będzie wyglądał artykuł po własnych zmianach - natomiast w OSM - trzeba wysłać changeset i potem trochę poczekać aż się zrenderuje, żeby zobaczyć czy się coś nie poknociło...

miklobit · 2013-10-13 20:28:34

Polimerek wrote:

Mnie jako niedawnemu stosunkowo jeszcze newbie w OSM - brakowało klawisza "podglądu". W Wikipedii przed zapisaniem artykułu można obejrzeć jak będzie wyglądał artykuł po własnych zmianach - natomiast w OSM - trzeba wysłać changeset i potem trochę poczekać aż się zrenderuje, żeby zobaczyć czy się coś nie poknociło...

W JOSM przecież mamy style wyświetlania - przed wyslaniem danych można zobaczyć efekt praktycznie zgodny z renderem standardowego mapnika.

Z przytoczonych tutaj pomysłów najlepiej/najprosciej/najskuteczniej wygląda koncepcja trzech baz (stable/testing/live).
Wlaściwie nie wymaga żadnych zmian w projekcie - potrzebne sa jedynie (choć można powiedzieć, że aż...) zasoby w postaci serwera na dwie kopie bazy (+ renderowanie przynajmniej testowej) oraz jakiś model przenoszenia zmian oraz dostępu do serwera testowego.
W pierwszym przypadku pytanie czy wystarczy założenie, że testing = live - n (n= wymagana liczba dni od ostatniej modyfikacji obiektu ),
w drugim dosyć oczywistym wydaje się przyjęcie, że moderacja danych na testowym powinna być zarezerwowana dla jakieś węższej grupy power-userów.

serekmedia · 2013-10-14 10:41:31

miklobit - to nie wymaga 3 baz, baza byłaby tylko jedna == stable, pozostałe dane to suma stable+testing lub stable+testing+live.
W testing wpadają zmiany od razu od zaawansowanych userów (ale w tych edycjach też mogą być błędy, dlatego odestęp czasowy do stable).
Zmiany są takie:
live - służy do edycji, przygotowań, ćwiczeń, wiele wybacza, można użyć na kilka minut/godzin jako piaskownicy itd. zmiany są przenoszone do testing po akceptacji lub po czasie - to pozwala na przejrzenie danych i ewentualnie rewertowanie czy poprawki jak coś nie pasuje, raczej nie wskazana do użytku produkcyjnego.
testing - to baza dla doświadczonych edytorów, można z niej korzystać produkcyjnie mają szybkie edycje i szybkie zmiany w bazie, ale również tu mogą pojawić się błędy.
stable - automatycznie przenosi się tu testing, ale z opóźnieniem pozwalającym wyeliminować błędy również zaawansowanych userów. Głównie przeznaczona na pracę wymagającą okresowych przetwarzań, np do budowy tablic routingu czy wyjmowania okresowego konkretnych warstw odpowiednio odpornych na błędy itd - czyli procesów replikacyjnych, przetwarzania, budowy danych offline, stabilnych kafelków, warstw zależnych od OSM (np u mnie traffic) itd.

Co do zmian to zapewne wymaga to niestety odpowiednich blokad nodów itd. Nie pisałem że będzie to łatwe i eliminacja konfliktów będzie trudna. Ja nie znam na tyle OSM od środka abym mógł zaproponować jakieś rozsądne rozwiązanie techniczne tego problemu. Niestety changeset jest zależny od poprzednich edycji i tu jest główny problem. Może rozwiązaniem byłby podział changesetów sztywną siatką geograficzną, aby wyeliminować część konfliktów - niestety wprowadzi problemy edycyjne. Myślę że tu liderzy IT projektu najwięcej by mogli powiedzieć co jest możliwe a co nie. Można budować drzewo zależności między changesetami i je rewertować kaskadowo gdy stanowią problem - a podczas zapisu changesetu informować że modyfikujemy niezatwierdzone dane.

miklobit · 2013-10-14 11:50:10

serekmedia wrote:

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.

Last edited by miklobit (2013-10-14 11:51:38)

serekmedia · 2013-10-14 17:48:07

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.

Last edited by serekmedia (2013-10-14 17:50:36)

miklobit · 2013-10-14 19:14:53

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-15 08:53:18

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

Last edited by serekmedia (2013-10-15 08:56:20)

postworek · 2013-10-15 11:33:44

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-15 11:37:47

postworek wrote:

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.

miklobit · 2013-10-15 11:51:44

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

Last edited by miklobit (2013-10-15 11:52:18)

Zibior2 · 2013-10-25 22:12:48

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-25 22:26:53

Zbigniew_Czernik wrote:

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

Last edited by ppece (2013-10-25 22:27:34)

jerrystef · 2013-10-25 22:35:08

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

Polimerek · 2013-10-25 22:56:54

jerrystef wrote:

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-25 23:10:19

@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-26 07:58:31

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-26 10:44:27

Zbigniew_Czernik wrote:

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-26 11:22:55

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-26 11:34:32

@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-26 12:18:16

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-26 20:08:01

koszatek wrote:

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ść.

Announcement

#76 2013-10-09 13:24:43

Re: Wandalizmy w OSM i im zapobieganie

#77 2013-10-09 15:31:17

Re: Wandalizmy w OSM i im zapobieganie

#78 2013-10-09 15:43:03

Re: Wandalizmy w OSM i im zapobieganie

#79 2013-10-09 18:11:37

Re: Wandalizmy w OSM i im zapobieganie

#80 2013-10-13 10:58:03

Re: Wandalizmy w OSM i im zapobieganie

#81 2013-10-13 20:28:34

Re: Wandalizmy w OSM i im zapobieganie

#82 2013-10-14 10:41:31

Re: Wandalizmy w OSM i im zapobieganie

#83 2013-10-14 11:50:10

Re: Wandalizmy w OSM i im zapobieganie

#84 2013-10-14 17:48:07

Re: Wandalizmy w OSM i im zapobieganie

#85 2013-10-14 19:14:53

Re: Wandalizmy w OSM i im zapobieganie

#86 2013-10-15 08:53:18

Re: Wandalizmy w OSM i im zapobieganie

#87 2013-10-15 11:33:44

Re: Wandalizmy w OSM i im zapobieganie

#88 2013-10-15 11:37:47

Re: Wandalizmy w OSM i im zapobieganie

#89 2013-10-15 11:51:44

Re: Wandalizmy w OSM i im zapobieganie

#90 2013-10-25 22:12:48

Re: Wandalizmy w OSM i im zapobieganie

#91 2013-10-25 22:26:53

Re: Wandalizmy w OSM i im zapobieganie

#92 2013-10-25 22:35:08

Re: Wandalizmy w OSM i im zapobieganie

#93 2013-10-25 22:56:54

Re: Wandalizmy w OSM i im zapobieganie

#94 2013-10-25 23:10:19

Re: Wandalizmy w OSM i im zapobieganie

#95 2013-10-26 07:58:31

Re: Wandalizmy w OSM i im zapobieganie

#96 2013-10-26 10:44:27

Re: Wandalizmy w OSM i im zapobieganie

#97 2013-10-26 11:22:55

Re: Wandalizmy w OSM i im zapobieganie

#98 2013-10-26 11:34:32

Re: Wandalizmy w OSM i im zapobieganie

#99 2013-10-26 12:18:16

Re: Wandalizmy w OSM i im zapobieganie

#100 2013-10-26 20:08:01

Re: Wandalizmy w OSM i im zapobieganie

Board footer