Centralizacja danych plików shapefile w bazie danych


13

Mam setki plików shapefile z różnych projektów GIS, które chcę rozpocząć konsolidacji w jednej platformie bazy danych, obecnie próbuję tego w Postgres / PostGIS.

Prawie żadne dane nie są znormalizowane - co oznacza, że ​​jest to wiele takich samych typów danych , ale poszczególne nazwy / typy atrybutów nie pasują.

Gdzie mam zacząć to rozwiązywać? Czy powinienem opracować standardowy model do migracji każdego pliku kształtu do pierwszego (np. Hydro_line, transport_line, standardy Hydro_poly itp.)?

Alternatywą jest po prostu zaimportowanie każdego pliku shapefile indywidualnie do Postgres, więc każdy shp staje się tabelą w bazie danych, ale nie jestem tego pewien pod względem wydajności i organizacji. Czuje się jak opóźnienie nieuniknionego ...

Wszelkie porady dotyczące radzenia sobie z tym trudnym zadaniem?

Odpowiedzi:


7

Rzuć okiem na oprogramowanie Spatial ETL (Extract - Transform - Load), dedykowane są do takich zadań. Najbardziej znany jest FME z Safe, ale obecnie dostępne są niektóre (częściowe) alternatywy open source, takie jak SDI (Spatial Data Integrator) i GeoKettle .


2
Poprosiłem o porównanie w poprzednim pytaniu, więc jeśli wybierzesz tę trasę, napisz. gis.stackexchange.com/questions/5049/spatial-etl-comparisons
RyanKDalton

Wziąłem próbną wersję FME i zainstalowałem zarówno SDI, jak i GeoKettle. Wypróbuję je i zobaczę, czy mogę je zrozumieć. FME wygląda jak rozwiązanie zupy na orzechy, ale najpierw muszę przejść przez krzywą uczenia się :).
colemanm

1
@ colemanm- Co skończyłeś na tym? Który produkt uważasz za najbardziej przydatny?
RyanKDalton

6

Halo

Najpierw zaimportuję go do PostGIS. Istnieją narzędzia do ładowania wielu kształtów do poszczególnych tabel. Rozszerzenie rożna QGIS to jedno. Nowa grafika shp2pgsql w paczce PostGIS lub eksperymentalnych plikach binarnych to kolejna alternatywa. Lub możesz po prostu napisać skrypt wsadowy za pomocą shp2pgsql.

Zacznę od tego, zaimportuję wszystko do schematu o nazwie oryginał lub coś w tym rodzaju. Następnie uporządkuję dane. Łączenie ze sobą w tabelach, gdzie jest to odpowiednie i tak dalej.

Zaletą robienia tego w ten sposób jest to, że jeśli zapiszesz wszystkie zapytania używane do tych transformacji, masz świetną dokumentację dotyczącą historii twoich danych. W razie potrzeby bardzo łatwo jest go ponownie wykonać. Gdy będziesz gotowy do pracy organizacyjnej, zrzuć kopię zapasową „oryginalnego” schematu i gdzieś odłóż.

Myślę, że jest to uporządkowany i czysty sposób na zrobienie tego. I jak powiedziano wcześniej, otrzymasz bardzo solidną dokumentację tego, które pole zmieniło nazwę na jaką nową nazwę, i jakie oryginalne tabele są scalone w tę dużą nową i tak dalej.

W FME i takim oprogramowaniu możesz oczywiście również zapisać to, co zrobiłeś, ale poza tym, że jest bardzo powolny w porównaniu do wewnętrznych zapytań do bazy danych, nie jest to uniwersalny sposób dokumentowania tego, co się robi jako zapytania SQL. Będą one użyteczne i czytelne, dopóki będą dostępne pliki tekstowe i relacyjne bazy danych.

Skończyłem z plikami tekstowymi wyglądającymi jak:

-- A query to merge all roads in Norway

Create table road_tables.all_roads as
SELECT id as roadid, status, the_geom from original.big_roads
union all
SELECT rid as roadid, condition as status, the_geom from original.small_roads;

i tak dalej. Ten zapisany jako plik tekstowy ma wielką wartość po kilku latach.

Pozdrawiam Nicklas


1
+1 Myślę, że to bardzo dobre podejście. Wszystko odbywa się w Postgres, bardzo przejrzyste i łatwe do odtworzenia w razie potrzeby.
podmroku

1
niezbyt dobra rekomendacja dla GIS opartych na ESRI. Dopuszczalne byłoby „tylko” oprogramowanie typu open source. ESRI ma wiele innych zależności, które nie byłyby dostępne za pomocą tej metody. bezpośrednie połączenie z Postgis nie jest dozwolone bez interopa, serwera gis lub arcsde.
Brad Nesom,

2
@Brad Hmm, zastanawiam się, czy to argument, który robi aginst, robiąc rzeczy w przejrzysty, odtwarzalny i szybki sposób, czy argument przeciwko zablokowaniu przez umieszczenie sde między mną a moimi danymi ... ;-)
Nicklas Avén

1
@Brad: colemanm nie wspomniał o ESRI, więc odpowiedź wydaje się być dobra.
podmroku

Podobną pracę wykonałem z klasami ESRI Sde i SQL Server 2008 (w / natywną geometrią) - najpierw utworzyłem klasę funkcji, a następnie załadowałem serią instrukcji wstawiania. IIRC, musiałem wyeksportować klasę obiektów na końcu do nowej klasy obiektów, ponieważ nie mogłem poprawnie wygenerować nowych obiektów. raz to zrobię, jak zwykle.
Jay Cummins,

4

Moją propozycją byłoby wybranie 2-5 z częściej używanych warstw danych (plików kształtów) i migracja ich do rdbms.
Zbadaj i zaimplementuj przepływy pracy dla tych danych. Przyzwyczajenie się do ograniczeń i wymagań rdbms vs. danych opartych na plikach.

Ograniczenia obejmują: wymagany eksport, strefa lądowania, coordsys, typ pliku do współpracy.

Proponujesz wiele korzyści.
Na stronie UWAGA: (Mój dziadek powiedział moim rodzicom, aby spędzili 6 miesięcy na szukaniu domu przed zakupem) Uważasz, że szukasz domu (długoterminowego) dla swoich danych, nie chcesz płacić za coś za 30 lat, od kiedy nie lubię

Zalecam zapisanie (cyfrowej lub analogowej) drzewiastej listy źródeł danych i wyświetlenie ich na dużym obrazie, co powinno pozwolić na uporządkowanie danych w bardziej zwięzłe grupy.

Istnieją metody wewnątrz arcgis (moje założenie: nie określiłeś preferowanego systemu) do integracji różnych danych.

Możesz spróbować tych informacji, jeśli chcesz poznać dobre praktyki projektowania ...

przegląd projektu
geobazy dokumentacja geobazy Dokumentacja
Istnieje również podobne łącza do łuku 10.
Centrum zasobów
arc10 geobaza

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.