Jak radzić sobie z wersjonowaniem w OpenStreetMap?

Już wcześniej pojawił się temat zarządzania danymi geoprzestrzennymi w bardziej ogólnym sensie . Wspomniany został także temat wersjonowania, ale tak naprawdę nie został poruszony.

Tradycyjne gromadzenie i obsługa danych geoprzestrzennych wymaga wewnętrznego zarządzania wersjami, ponieważ baza danych jest aktualizowana tylko z poziomu organizacji. Nie dzieje się tak w geobazach typu crowdsourcing, takich jak OpenStreetMap. Tam każdy może przyjść i dodać, zmodyfikować lub usunąć obiekty. W OpenStreetMap jest to traktowane w sposób podstawowy: każdy obiekt ma liczbę całkowitą wersji i tylko obiekt o najwyższej wersji jest widoczny w bazie danych na żywo. Baza danych wykorzystuje optymistyczne blokowanie, więc użytkownicy muszą rozwiązać wszystkie konflikty, które występują podczas ręcznego przesyłania danych.

Wszystko to działa dość dobrze, o ile wkład ludzi za pośrednictwem edytorów ( JOSM , Potlatch ) jest jedynym sposobem wkładu - ale tak nie jest. Coraz częściej odbywa się import otwartych danych sektora publicznego. Powodują to bardziej złożone problemy z wersjonowaniem. Rozważ następujący scenariusz:

1. Obiekt budynku jest importowany z otwartego zestawu danych sektora publicznego
2. Budynek otrzymuje modyfikacje od ludzi (atrybuty, geometria lub oba)
3. Nowa wersja danych sektora publicznego staje się dostępna i jest importowana.

Obecnie w kroku 3. wkład człowieka zostałby utracony, chyba że każdy budynek, który otrzymał modyfikacje społeczności, zostanie ręcznie połączony z nowym importem.

Jak OpenStreetMap radzi sobie z tą sytuacją? Czy musimy przyjrzeć się rozproszonej kontroli wersji podczas opracowywania oprogramowania? W jaki sposób można dostosować metody DVC do obsługi rozproszonego zarządzania danymi przestrzennymi?

Marzyłem o kimś, kto zaimplementuje nieniszczącą edycję danych GIS. Jest intensywnie obliczeniowy, ale nie powinien być trudnym wdrożeniem w RDBMS.

Zacznij od migawki danych. Wszelkie zmiany są zapisywane jako zmiany, oryginalne dane pozostają niezmienione. W twoim przykładzie budynki pochodzą początkowo z danych sektora publicznego. Gdy użytkownik dokonuje edycji, zmiana lub różnica są zapisywane w osobnej tabeli. Gdy ktoś wyświetli tę funkcję, otrzymuje oryginał oraz wszelkie zastosowane zmiany. Kolejne edycje to obliczona różnica między nowym kształtem elementu a oryginałem oraz wszystkimi poprzednimi edycjami.

Daje to możliwość cofnięcia na poziomie drobnoziarnistym. Zasadniczo działa kontrola wersji. Dobrym przykładem nieniszczącej edycji jest Aperture firmy Apple. Zaimportowane obrazy cyfrowe w aperturze nie są modyfikowane bezpośrednio. Zmiany poziomów, wyostrzanie, rozmycie itp. Są zapisywane jako zmiany i stosowane w locie podczas pracy z obrazem. Każda zmiana może zostać natychmiast usunięta.

Oczywiście, zrobiłbyś migawki DB do dystrybucji i wykorzystania w środowiskach produkcyjnych. Byłoby to tylko do programowania i edycji.

Spójrz na Versioning PostGIS , pgVersion i Post Facto, aby znaleźć pomysły i możliwe rozwiązania. Są to systemy kontroli wersji zaimplementowane w bazach danych PostgreSQL.

OSM używa Postgres i Postgis, który przechowuje migawkę bazy danych.

Aby zaimplementować to na własnym serwerze i bazie danych

http://wiki.openstreetmap.org/wiki/Databases#Choice_of_DBMS

Baza danych (plantet.osm) jest aktualizowana co tydzień http://wiki.openstreetmap.org/wiki/Planet_dump

Osmoza jest przyzwyczajona„zawiera komponenty do odczytu z bazy danych i pliku, komponenty do zapisu do bazy danych i pliku, komponenty do wyprowadzania i stosowania zestawów zmian do źródeł danych”

http://wiki.openstreetmap.org/wiki/Osmosis

Changsets: http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage#Changeset_Derivation_and_Merging

Myślałem o tym problemie i miałem pomysł, ale go nie testowałem. To może zadziałać:

Użyj systemu kontroli wersji, takiego jak Mercurial lub Git. Mercurial będzie łatwiejszy, ponieważ pozwala łatwo tworzyć anonimowe gałęzie.

Teraz, od wstępnej wersji, uruchom gałąź publicznego importu zestawu danych. Będą więc 2 oddziały:

1. mainline (OSM)
2. publiczny zestaw danych X

Importu z publicznego zestawu danych należy dokonać w oddziale 2, a następnie scalić w oddziale OSM.

Twój scenariusz może działać w ten sposób:

• obiekt nie istniał
• następnie jest importowany i łączony w oddziale 1
• następnie jest modyfikowany w linii głównej, w tym w geometrii
• jest ponownie importowany do oddziału 2
• po scaleniu w oddziale 1, tylko dane, które zostały zaktualizowane w oddziale 2, zostaną zaktualizowane w oddziale 1

Może to wymagać podziału danych na wiele plików, po jednym na obiekt i prawdopodobnie do formatu takiego jak json, aby VCS mógł łatwo poradzić sobie ze zmianami oddzielnych atrybutów.

{
     id: 1357
     lat: 1,
     lon: 2,
     tags: {
          'building': 'entrance'
     }
     type: 'node',
}
{
     nodes: [
         1357,
         2468
     ],
     tags: {
         building: 'yes',
     }
     type: 'way',
}

Wiem, że dzielenie informacji na miliard plików to za dużo dla każdego systemu. Zamiast tego należy użyć rdzenia VCS, a dane OSM powinny zostać przetworzone i wprowadzone do VCS w formie umożliwiającej aktualizację. (Lub system plików można wyśmiewać).

Nie mogę zagwarantować, że to zadziała.