WikiArbor aka WikiDrzewia

I am now preparing a proof-of-concept installation for communities who want to monitor trees in their area.
The direct need that made me work on it is the situation now common in Poland, where local authorities, together with developers, cut down an enormous number of trees without or clearly against the consent of local communities.
All hints and helping hands/minds welcome.
#trees #protection #community #federated #power
More: lemmy.ml/post/63657

*WikiArbor / Wikidrzewia - Lemmy*
> Lemmy
lemmy.ml friendica.wprzemianie.pl/displ

@petros można wprowadzać drzewa do OSM, to może być dobry start 🤔

@kuba
Jestem ostatnim, który by zabraniał komukolwiek wprowadzać drzewa do OSM. Go ahead.

@petros spoko, wprowadzam od dawna i tak :D

Zastanawiam się jakich funkcjonalności ten projekt potrzebuje, których jeszcze nie ma w OSM?

@kuba
Zgaduje, że jest to ukryte pytanie.
Odpowiadam:
1. OSM nie zapewnia lokalnej (społecznościowej) kontroli nad danymi
2. OSM jest nieodporny na ataki -- wystarczy skuteczny atak na jeden punkt struktury, żeby obezwładnić całość.
3. OSM nie zapewnia komunikacji zwrotnej (monitoringu społecznościowego) ani kanałów komunikacji na poziomie społeczności i między społecznościami.

OSM jest znakomitą platformą do prezentacji danych i mam nadzieję to wykorzystać. Zakładam, że można będzie automatyczne przesyłać dane geolokacyjne (z linkiem zwrotnym) z systemu rozproszonego do OSM. Ale na tym użyteczność OSM się kończy.
Follow

@petros 1. jak rozumiesz "społecznościową kontrolę nad danymi"?

2. Na jakie ataki jest podatny OSM i jak chciałbyś zapobiegać podobnym atakom w alternatywnym rozwiązaniu?

3. Możesz podać przykład tego, co masz na myśli przez "monitoring społeczny"? Co do kanałów komunikacji - zgoda. Chociaż to można załatwić kanałem na Matrixie, chociaż to dla wielu może być zniechęcające.

· · Web · 2 · 0 · 0

@petros Trudno też mi nie zwrócić uwagi, że skoro już i tak projekt będzie zbierać dane o drzewach, to mega warto zapisywać je w OSM ;)

Myśle, że OSM może sie tu dobrze sprawdzić chociażby z uwagi na to, że każde drzewo tam wprowadzone ma już swoje id i można je opatrzać dużą ilością metadanych

@kuba
1. Dane wprowadzane przez lokalna społeczność pozostają pod fizyczną kontrolą społeczności -- tak samo, jak np. posty na **lokalnej** instancji mastodona.
W projekcie jest to realizowane poprzez sprzętowy "społecznościowy węzeł danych", oczywiście z zachowaniem backupów i mozliwością mirrorowania w dowolnym miejscu sieci.

2. Single point of failure:
The Openstreetmap Foundation is incorporated as a company limited by guarantee, registered in England and Wales at the UK Companies House.
Company Registration Number: 05912761
Address of Registered Office: Openstreetmap Foundation, St John’s Innovation Centre, Cowley Road, Cambridge, CB4 0WS, United Kingdom .

Wrażliwy na ataki polityczne, prawne, administracyjne i niejawne operacje służb.

W momencie, kiedy dane źródłowe przechowywane są w rozproszonych społecznościach, konieczna byłaby seria ataków na każdą gminę/organizację z osobna. Podnosi to znacznie koszty takiego ataku. A jednocześnie społeczności, których nie zaatakowano, nadal korzystaja z pełnej funkcjonalnosci na swoim terenie.

3. Idę sobie parkiem i widze moje ulubione drzewo nagle pomalowane pomarańczowym sprayem. Wyciągam smartfon, loguję się na stronę tego drzewa i wysyłam zdjęcie z ewentualnym komentarzem głosowym. Trafia ono do skrzynki modelatorskiej węzła, gdzie podejmowane są działania zgodnie z procedurą.
@petros @kuba
Ad .1 Od razu robię zatrzeżenie, że odniosę się tylko do danych, których przechowywanie w OSM ma sens, bo są reprezentacją obektywnych faktów nt cech fizycznie istniejacych obiektów, i to faktów , które są w miarę niezmienne w czasie.
Biorąc w/w pod uwagę skoro takie dane potencjalnie sa interesujące dla bliżej nieokreslonej liczby ludzi do bliżej nieokreślonej liczby zastosowań to powinniśmy je zbierać i udostęþniać w sposób ktory maksymalizuje ich dostępność w sensie zarówno łatwości pobrania/wyszukania/połączenia z innymi danymi jak w sensie bezpieczęństwa przechowywania (że np nie znikną bo projekt "zdechnie" z jakichklwiek przyczyn).
Zdecentralizowane przechowywanie danych ma tu sens o ile jesteśmy w stanie zapewnić, że np właśnie nie znikną bo ktoś straci zapał czas i poprostu wyłączy serwer ze swoją częscią danych a żaden mechanizm nie zapewni ,że są zreplikowane i niebęda służyć dalej już bez kontroli właściela serwera. Dlatego nie rozumiem co rozumiesz przez "fizyczna kontrola społeczności".
Poza tym jest inny problem - jak mamy ustalić zasady "podział tortu" w przypadku danych, które są "przywiązane" geograficznie ? Jeżeli ktoś postawi serwer (zakłądamy że jako część federacji) i ogłosi, że u niego to wszystkie zagrożone drzewa z Warszawy bedą to co ma zrobić ktoś, kto tez chce postawić serwer ale tylko dla Moktowa ? Dublowanie danych w dwóch róznych miejscach oznacza ni mniej ni wiecej niż dublowanie czyjejś pracy i konkurencję zamiast współpracy. A jeżeli chcesz technicznie wyeliminować dublowanie tych samych danych to kończymy w miejscu gdzie jednak musi być jakieś wspólne repozytorium z którym wszystkie dane synchronizujemy.

Ad 2. "Single point of failure" Fundacja OSM po pierwsze nie jest żadną korporacją pod prywatną kontrolą. Członkostwo z prawem głosu kosztuje 15funtów/ rok ew. 42dni aktywnego mapowania w ciągu ostatnich 365 dni. Po drugie - Fundacja OSM nie zarządza/finansuje niczego więcej niż tylko serwerów na ktorych jest główna baza OSM ale ta baza służy w praktyce tylko do wprowadzania danych i generowania "delt" do zasilania replik, które są zdecentralizowane - każdy może postawić swoją. Wszystkie mapy które są renderowane w necie sa geerowane z takich własnie replik. I drugi stopień decentralizacji - serwery cache - nawet mapa osm.org ktora pokazuje na żywo to co ktoś wprowadził do bazy jest renderowana wprawdzie centralnie ale każde zapytanie do osm.org jest prekierowywane do serwera cache najblizej odbiorcy danych. A serwery cache są utrzymywane lokalnie. Każdy może taki postawić - właśnie w tej chwili by sie przydał dla Polski bo nie ma a Polska generuje znacząca część ruchu z Europy (jakieś 300Mbit/s).

3. Twój scenariusz nie stoi w żadnej sprzeczności ze wspolnym zródłem danych. Dokładnie tak działają wszystkie aplikacje oparte na danych z OSM. To co da się przechować jako wspólne dane jest w OSM a to czego sie nie da jest w lokalnym serwisie. Trzeba tylko zdefiniować co to znaczy "strona tego drzewa" w kontekcie tego co wyżej czyli że np dwa wężły federacji , ktora ten system tworzy będa chciały sie zajmować tym samym obszarem. Jeśli wszystkie dane będą przechowywane tak ,że oba wezły moga je czytać i modyfikować to OK. Ale jeśli nie to mamy problem. Jak widzisz tutaj kwestię prawa węzła do edycji danej lokalizacji ew jak widzisz prawa węzła do edycji danych innego węzła ?
Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!