Wdrażasz system kontroli wersji danych geoprzestrzennych? [Zamknięte]

Nie dlatego, że potrzebuję natychmiastowej odpowiedzi tutaj, ale ostatnio widziałem wysiłki, aby wprowadzić koncepcję „(rozproszonych) systemów kontroli wersji” dla danych geograficznych. Niektóre przykłady (które znam) to trzy oficjalne dokumenty z OpenGeo ( 1 , 2 i 3 ) oraz projekt „ Geosynkronisering (geosyncronization)” norweskich dostawców oprogramowania GIS i norweskiej agencji mapującej. Znalazłem też rozproszoną wersję danych geoprzestrzennych? , który wspomina o GeoGit (przez OpenGeo) i zastosowanie kontroli wersji do modeli ArcGIS ModelBuilder? o kontroli wersji w ArcGIS.

Jako programista wiem (przynajmniej na tyle, aby móc z nich korzystać), jak działają systemy kontroli wersji kodu źródłowego (takie jak SVN i Git), a moje doświadczenie w geomatyce mówi mi, że istnieją pewne wyjątkowe wyzwania związane z danymi geograficznymi, które sprawiają, że podejście nie do końca podobne do sposobu obsługi kodu źródłowego (który jest w zasadzie tekstem).

Jakie wyzwania wiążą się z (d) VCS w odniesieniu do danych geograficznych, w jaki sposób je rozwiązalibyście, czy są nam potrzebne i czy istnieją inne próby rozwiązania tych problemów niż te, o których wspomniałem?

Wiem, że białe księgi OpenGeo odpowiedzą na niektóre z moich pytań, ale tak naprawdę chcę uzyskać bardziej „pedagogiczną” odpowiedź w stylu „powiedz mi, jakbym miał 10 lat”, tak że Mogę skierować ludzi do doskonałego wyjaśnienia wyzwań i rozwiązań, jakie dane geograficzne wnoszą do mieszanki.

Mam nadzieję, że ktoś z pewnym wglądem poświęci trochę czasu na przemyślenie tej kwestii, ponieważ powiedziałem, że obecnie nie szukam rozwiązania konkretnego problemu, ale ten temat mnie interesuje.

Aktualnie pracujemy nad całkowitym przeprojektowaniem naszych geobastorów. Muszę powiedzieć, że ich ewolucja trwała do tej pory ponad 20 lat. Zidentyfikowaliśmy następujące kluczowe cechy w zarządzaniu danymi geoprzestrzennymi:

• jednoczesna edycja
• uprawnienia do odczytu lub zapisu części danych
• gorąca aktualizacja podczas uruchamiania usług opartych na danych (Transakcje i paradygmat ACID)
• schemat wewnętrzny i zewnętrzny (modyfikacja schematu wewnętrznego nie powinna wpływać na usługi)
• możliwość przechowywania i dostępu do dużych ilości danych (terabajtów rastra i setek gigabajtów danych wektorowych)
• spójność danych między różnymi warstwami (każda działka należy do dzielnicy itp.)

Oceniliśmy następujące podejścia, oto co mogę o nich powiedzieć:

1. ESRI Enterprise Geodatabase(ArcGIS 10.1); prawie tak samo jak wcześniej (SDE), ale z szerokim wykorzystaniem funkcji kontroli wersji do obsługi transakcji. Ale to po prostu tak naprawdę nie jest geobazą korporacyjną, moim zdaniem SDE działa tylko w grupie roboczej jako serwer geodanych, gdzie ludzie pracują od 8:00 do 20:00, a następnie możesz przejść w tryb offline do zadań konserwacyjnych, zatwierdzanie transakcji (uzgadnianie wersji i wysyłanie w mowie ESRI), replikacja itp. Jeśli budujesz usługi na podstawie tych danych, musisz obsłużyć tymczasową bazę danych (tam, gdzie jest wykonywana praca) replikowaną produkcyjną bazę danych. To prawie tak samo, jak kompilacja / test i wdrożenie w programowaniu. Chociaż bogaty w funkcje pakiet, który dostarcza ESRI, jest całkiem niezły, brakuje mu jednak elastyczności (zmiany schematu lub zadania konserwacji podczas pracy ludzi, na przykład tworzenie indeksu).

2. Pliki płaskie i system kontroli wersjiwybieramy Git (nie wiedziałem, że jest już GeoGit). O tak, niektórzy z moich znajomych i ja również wywodzimy się z inżynierii oprogramowania. Wszystko może być takie proste. Myślę, że to jest jego problem: to jak mechanik samochodowy budujący samochód. Utrzymanie go dla niego będzie proste, ale prowadzenie samochodu będzie denerwujące, a patrzenie na niego cholernie brzydkie. Wydaje mi się, że ma też kilka poważnych wad: jak kontrolować wersję Rasterdataset 2 TeraByte (lub nawet więcej, binarnie)? A w jakim formacie? Dane wektorowe mogą być łatwo kontrolowane pod względem wersji, jeśli używasz formatów tekstowych (na przykład GML), ale wtedy też ciężko jest pracować z zestawem danych o miliardach wierszy. Nadal nie jestem pewien, czy możemy skutecznie zarządzać uprawnieniami użytkowników, ponieważ nie wszyscy powinni mieć możliwość edytowania, a nawet przeglądania wszystkiego. A jak scalić zestaw danych wektorowych, który był intensywnie edytowany przez 4 użytkowników jednocześnie? Przynajmniej musisz być prawdziwym informatykiem / programistą, aby robić to wszystko skutecznie ... nasi użytkownicy GIS są planistami, ankieterami, geologami i tak dalej. Problem polega na tym, że myślą o liniach wersji, tak jak robią to programiści, lub używają rozgałęzień tak, jak powinny. Niemniej jednak myślenie o magazynach danych jako wspólnych repozytoriach jest interesującym pomysłem.

3. Płaska baza danych jako prosty pojemnik. To samo co SDE, ale bez SDE. Wciąż trudne w utrzymaniu, ponieważ tak naprawdę nie korzystasz z zalet, jakie oferuje RDBMS. Tak, bardzo łatwo jest po prostu załadować wszystko do bazy danych, ale to wcale nie jest zarządzanie danymi.

4. Bigdata i NoSQL . Te same problemy, co płaskie pliki i płaskie tabele. Moim zdaniem prosty interfejs API systemu plików do użytku w sieci. Tak, działa dobrze w Internecie i tak, łatwo jest po prostu wrzucić dokumenty, ale myślę, że jeśli chcę przeprowadzić analizę danych przestrzennych na terabajtach danych (być może rastrowych), chcę, aby nie była serializowana i deserializowana przez interfejs HTTP.

AKTUALIZACJA 2018: Oto wiele nowych rzeczy tworzących duży rozmach. By wymienić tylko kilka:

• Magazyn w chmurze i HDFS
• Python / shapely / Dask Stack

• Apache Spark

  • GeoMesa / GeoWave dla danych wektorowych
  • GeoTrellis dla danych rastrowych

• i wiele więcej

  5. Kompleksowe klasyczne modelowanie baz danych(z RDBMS). Główny problem polega na tym, że trudno jest po prostu upuścić dane w dowolnym miejscu i mieć nadzieję, że będzie to odpowiadało każdej przyszłej potrzebie. Ale jeśli poświęcisz trochę czasu na określenie solidnego modelu danych (OSM również to zrobił) w bazie danych, będziesz w stanie wykorzystać wszystkie jego zalety. Możemy edytować i aktualizować dane w transakcjach rozproszonych, możemy również modyfikować ich główny schemat, podczas gdy usługi nadal polegają na zewnętrznych schematach tych samych danych, możemy je zachować, możemy sprawdzić jego spójność, możemy zezwolić i odmówić uprawnień, jesteśmy jesteśmy w stanie przechowywać bardzo duże ilości danych, a my wciąż możemy uzyskiwać do nich szybki dostęp, jesteśmy w stanie budować historycznie modelowane dane i uruchamiać je w sposób przejrzysty i tak dalej. Ponieważ używamy serwera SQL, wciąż brakuje nam natywnego typu rastrowego, ale inni dostawcy baz danych już to oferują.

Cóż, myślę, że relacyjny model bazy danych po prostu wstał w świecie przestrzennym z typami danych przestrzennych w ciągu ostatnich kilku lat (wcześniej tam, gdzie były pojemniki BLOB) i nadal jest najbardziej elastyczną i profesjonalną formą przechowywania danych. Nie oznacza to, że nie należy go uzupełniać metodami VCS ani NoSQL, ale widzę, że takie podejścia są bardziej prawdopodobne jako forma dystrybucji danych w grupach użytkowników niż jako forma profesjonalnego scentralizowanego zarządzania danymi przestrzennymi. Również OSM scentralizował wiele zadań, których tłum po prostu nie może dostarczyć, takich jak import dużych ilości danych (większość danych OSM w Austrii została zaimportowana w ciągu jednego dnia, a nie crowdsourcing) i generowanie kafelków. Część współpracy (pozyskiwania tłumu) jest rzeczywiście bardzo ważna, ale to tylko połowa jej działalności.

Myślę, że muszę to przeformułować i podać więcej faktów. Na takie pytanie trudno jest odpowiedzieć wyczerpująco w ciągu kilku godzin, postaram się poprawić jakość mojej odpowiedzi w ciągu następnych dni