Centralizacja danych plików shapefile w bazie danych

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?

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 .

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

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