Zarządzasz dużą ilością danych geoprzestrzennych? [Zamknięte]

Jak zarządzasz danymi geoprzestrzennymi? Mam terabajty danych rozproszone w setkach zestawów danych i mam rozwiązanie ad-hoc, które używa dowiązań symbolicznych w ramach projektów, które odsyłają do katalogu archiwum opartego na nazwie domeny dla każdego zestawu danych. Działa to głównie, ale ma swoje własne problemy.

Chciałbym również dowiedzieć się, czy ktoś zarządza swoimi danymi geoprzestrzennymi w systemie kontroli wersji; Obecnie używam jednego do mojego kodu i małych zestawów danych, ale nie do pełnych zestawów danych.

Myślę, że podstawową / oczywistą odpowiedzią byłoby użycie przestrzennej bazy danych (PostGIS, Oracle, SDE, MSSQL Spatial itp.) W połączeniu z serwerem metadanych, takim jak GeoPortal esri lub aplikacja GeoNetwork typu open source, i ogólnie myślę, że jest to ogólnie najlepszym rozwiązaniem. Jednak prawdopodobnie zawsze będziesz potrzebować migawek / gałęzi / tagów opartych na projekcie. Niektóre z bardziej zaawansowanych baz danych mają sposoby zarządzania nimi, ale generalnie nie są wcale takie łatwe w obsłudze / zarządzaniu.

W przypadku rzeczy, które przechowujesz poza bazą danych (duże obrazy, pliki oparte na projektach), myślę, że kluczem jest spójna konwencja nazewnictwa i ponownie rejestr metadanych (nawet coś mniej zaawansowanego technologicznie, jak arkusz kalkulacyjny), który pozwala ci je śledzić i upewnij się, że są one odpowiednio zarządzane. Na przykład w przypadku plików opartych na projekcie może to oznaczać ich usunięcie, gdy nakazuje to polityka zarządzania rekordami, lub przeniesienie ich do centralnego repozytorium po zakończeniu projektu.

Widziałem jednak kilka ciekawych rozwiązań ...

Kiedy Ministerstwo Środowiska BC działało poza zasięgiem informacji Arc / Info, mieli naprawdę fajny proces synchronizacji oparty na rsync. Relacje, które znajdowały się pod kontrolą centralną, były wypychane do regionów co noc, a dane regionalne były wypychane z powrotem. Ten transfer różnicowy na poziomie bloku działał naprawdę dobrze, nawet w przypadku ponad 56 000 łączy. Były podobne procesy replikacji baz danych atrybutów opartych na Oracle, ale nie sądzę, aby były one zwykle zbyt dobre w przypadku połączeń telefonicznych :)

Moje obecne miejsce pracy wykorzystuje podobne rozwiązanie hybrydowe. Każdy zestaw danych ma swoją wiarygodną kopię (niektóre w Oracle, inne w MapInfo, inne w osobistych geobazach) i są one krzyżowo przesyłane ETL co noc przy użyciu FME. Jest jednak dość duży narzut, jeśli chodzi o konserwację; wysiłek stworzenia nowego zbioru danych i zapewnienia widoczności organizacyjnej jest znacznie wyższy niż powinien. Jesteśmy w trakcie przeglądu mającego na celu znalezienie sposobu konsolidacji, aby uniknąć tego narzutu.

Metadane są tutaj zdecydowanie najważniejszą kwestią. Jeśli metadane odpowiadają komu, kiedy, dlaczego, gdzie jest to dopuszczalny rekord metadanych.

Mając doświadczenie w pracy w dużych firmach z zaledwie kilkoma użytkownikami GIS (około 30) mieliśmy poważne problemy z kontrolą danych, zwłaszcza wersji i uprawnień. Jedną ze stron można rozwiązać za pomocą obszernego dokumentowania danych (metadanych), a pozostałe problemy można najprawdopodobniej rozwiązać za pomocą centralnego repozytorium, w którym świeci PostGIS.

GeoNetwork to dobry początek do obsługi problemów z metadanymi. Rozwiązanie centralnego repozytorium jest bardziej skomplikowane, ponieważ zaprojektowanie / utrzymanie bazy danych może wymagać specjalistycznej osoby.

Skomplikowanym problemem jest to, kto będzie odpowiedzialny za kontrolę jakości tych zestawów danych i ich metadanych. Chociaż procesy sterowane komputerowo działają świetnie, nie mogą być tak rygorystyczne, jak dobry menedżer danych / administrator danych, który został stworzony w tej firmie, w której pracowałem. Teraz jest ktoś wyłącznie do przeglądania / zatwierdzania metadanych i organizowania danych geoprzestrzennych, które nie są scentralizowane w DBMS.

Korzystaliśmy z systemu plików zorganizowanego hierarchicznie według: - zasięgu geograficznego (kraju lub kontynentu) - dostawcy danych, licencjodawcy - domeny / zestawu danych - daty / wersji

Następnie mamy politykę oddzielania danych źródłowych (w tym samym formacie, który znajdował się na dowolnej płycie CD / DVD, którą otrzymaliśmy od dostawcy) od wszelkich zbiorów danych, które wyprodukowaliśmy w naszej firmie.

System plików naprawdę ułatwia przyjmowanie danych od klienta, a także pozwala na pewną elastyczność w zakresie fizycznego przechowywania - przechowujemy nasze archiwa na większych, wolniejszych dyskach i mamy specjalne serwery plików (transparentnie połączone z hierarchią) dla częściej używane zestawy danych.

Aby ułatwić zarządzanie w ramach projektów, używamy dowiązań symbolicznych. Trzymamy nasze wektory w bazie danych (Oracle) i sprawiamy, że regułą jest posiadanie co najmniej jednej instancji bazy danych na klienta (i kilku użytkowników / schematów dla projektów). Jednak nie trzymaliśmy wielu rastrów w bazie danych, ponieważ zajmują zbyt dużo miejsca, nawet poza jedną. Ponadto chcemy, aby nasze instancje bazy danych były jak najlżejsze.

I tak, mamy kogoś odpowiedzialnego za „nadzorowanie” całej sprawy, więc nie robi się to zbyt bałagan.

Największym problemem, jaki mamy obecnie w związku z tą konfiguracją, jest brak ładnego interfejsu użytkownika, który pomógłby nam w lepszym przeglądzie całej sprawy, a ponadto planowaliśmy dołączyć do niej pamięć metadanych. Nadal rozważamy nasze opcje tutaj.

Używamy kontroli wersji dla naszego kodu i używaliśmy go do dokumentów, ale okazuje się, że kontrola wersji nie jest tak naprawdę stworzona dla dużych zestawów danych, szczególnie jeśli są to głównie pliki binarne, więc nie polecam tego , z wyjątkiem sytuacji, gdy masz do czynienia z GML lub czymś podobnym do tekstu (problemy obejmują ogromne obciążenie na dysku po stronie serwera, a także awarie klientów podczas sprawdzania ogromnych repozytoriów).

Jak powiedział @JasonBirch, kontrola wersji to ogromny problem.

Odkryliśmy również, że odpowiedni przepływ pracy jest niezwykle ważny. Na przykład, gdy zbieramy dane pól, zwykle korzystamy z tymczasowych baz danych, w których dane pól można poddać kontroli jakości przed scaleniem z głównym zestawem danych. Jednak w zależności od tego, ile danych należy poddać kontroli jakości, zawsze spowoduje to pewne obciążenie.

Ponadto, jeśli jeszcze go nie widziałeś, polecam przyjrzeć się ebookowi Geo-komunikacji i projektowania informacji autorstwa Larsa Brodersena, przynajmniej na temat tego, co ma do powiedzenia na temat modelowania danych.

Postgres do końca, jak powiedzieli inni, jednak jeśli chcesz zachować jego przenośność i łatwość przenoszenia, zawsze możesz skorzystać z SQLite + rozszerzenia Spatialite.

Nie jest tak łatwy w użyciu jak Postgres pod względem narzędzi zarządzania, ale QGis MOŻE bez żadnych problemów bezpośrednio komunikować się z bazą danych GIS z obsługą przestrzenną.

Właściwie używam SQLite + Spatialite do tworzenia kopii zapasowych, mam działającą w tle usługę Windows (napisaną na zamówienie), która monitoruje moją instancję PGSql i dubluje moje dane GIS w różnych bazach SQLite DB, które znajdują się na zewnętrznych dyskach USB.

Jeszcze jedna wskazówka z PG, użyj schematów

Wielu ludzi, których znam, po prostu upuszcza wszystko na „publiczny” i załatwia sprawę, ale jeśli odpowiednio uporządkujesz swoją bazę danych, robi to różnicę.

Na przykład moja baza danych „Ordnance_Survey” zawiera schematy dla VectormapDistrict VectormapLocal Topo50 LookupGrids CodePointWithPolygons CodePointOpen

gdzie przechowuję wszystkie powiązane dane.

W międzyczasie wszystkie tabele metadanych, takie jak kolumny geometrii itp., Działają tylko publicznie, rozszerzenie Postgis jest również włączone tylko w schemacie publicznym, ale jest dostępne z wszystkich innych używanych schematów.

Jak wspomniano w poprzednim poście, przestrzenne bazy danych i serwer metadanych są standardową konfiguracją. Myślę, że jedną z kluczowych rzeczy do zapamiętania jest to, że „jeden rozmiar nie pasuje do wszystkich”. Otrzymasz dane, które najlepiej pasują do Oracle, serwerów plików, SQL Server i innych. Próbowałem odrzucić wszystkie potrzeby dotyczące danych w jednym rozwiązaniu i zwykle się to nie udaje.

Oczekuj zastosowania różnych rozwiązań, które pasują do danych i zaplanuj je. W tym miejscu naprawdę pojawia się Geo-portal (serwer metadanych).

Muszę zgodzić się z „George” powyżej, że metadane powinny odgrywać dużą rolę w zarządzaniu danymi geoprzestrzennymi. Naprawdę w przypadku wszelkich danych cyfrowych metadane są kluczowe - pomyśl o fotografie, który próbuje zarządzać swoimi cyfrowymi zdjęciami bez odpowiednich metadanych. Życie staje się o wiele łatwiejsze, jeśli oznaczasz rzeczy religijnie i masz dobre oprogramowanie, które może wykorzystywać dane. Teraz pierwotne pytanie dotyczące „zarządzania danymi geoprzestrzennymi” jest dość szerokie - mogą to być formaty danych do przechowywania, konwencje nazewnictwa, hierarchia zestawów danych i funkcji, role edycyjne i uprawnienia itp. Itp.

Wzorzec przechowywania danych geoprzestrzennych zależy od tego, w jaki sposób chcesz zapytać / co chcesz z tym zrobić. Oto niektóre narzędzia, które możesz rozważyć:

Postgres + PostGIS: Obsługuje indeksy geoprzestrzenne i wszelkiego rodzaju zapytania, jakie możesz sobie wyobrazić. Aby zarządzać terabajtami danych, musisz zastosować sharding, optymalizację zapytań itp. Jeśli obciążenie zapisu jest duże, nie poleciłbym tego.

MongoDB: obsługuje duże ilości danych. Idealne do prostego przechowywania, wyszukiwania i ograniczonych zapytań geoprzestrzennych.

Przechowywanie plików: Jeśli naprawdę jesteś tylko systemem archiwalnym i używasz tylko części danych do tworzenia zapytań, przechowywanie danych jako plików może być opłacalne. Wymagania dotyczące kontroli wersji mogą być z tego zadowolone.

Redis: Możesz połączyć dowolną z powyższych opcji z obsługą Redis Geo, aby przechowywać w redis niewielką ilość „gorących” danych, do których musisz często uzyskiwać dostęp. Pomyśl o tym jak o swojej pamięci podręcznej.