Memusatkan data shapefile ke dalam basis data


13

Saya punya ratusan shapefile dari berbagai proyek SIG yang berbeda yang ingin saya mulai konsolidasi ke dalam platform basis data tunggal, saat ini sedang mencoba ini dengan Postgres / PostGIS.

Hampir tidak ada data yang terstandarisasi - artinya banyak tipe data yang sama , tetapi nama / tipe atribut tertentu tidak cocok.

Di mana saya harus mulai menangani ini? Haruskah saya mengembangkan model standar untuk memigrasi setiap shapefile ke yang pertama (mis. Hydro_line, transport_line, standar Hydro_poly, dll)?

Alternatifnya adalah dengan mengimpor setiap shapefile ke Postgres secara individual, sehingga setiap shp menjadi tabel dalam database, tetapi saya tidak yakin tentang ini dalam hal kinerja dan organisasi. Rasanya seperti menunda ...

Adakah saran untuk menangani tugas yang menakutkan ini?

Jawaban:


7

Lihat software Spatial ETL (Extract - Transform - Load), mereka didedikasikan untuk tugas-tugas tersebut. Yang paling dikenal adalah FME dari Safe, tetapi beberapa alternatif open source (parsial) sekarang tersedia, seperti SDI (Spatial Data Integrator) dan GeoKettle .


2
Saya meminta perbandingan dalam pertanyaan sebelumnya, jadi jika Anda memilih rute ini, silakan lakukan penulisan. gis.stackexchange.com/questions/5049/spatial-etl-comparisons
RyanKDalton

Saya meraih versi percobaan FME, dan menginstal SDI dan GeoKettle. Saya akan mencobanya dan melihat apakah saya bisa memahaminya. FME terlihat seperti solusi sup-ke-kacang, tetapi saya harus mengatasi kurva belajar terlebih dahulu :).
colemanm

1
@ colemanm- Apa yang akhirnya Anda lakukan dalam hal ini? Produk mana yang menurut Anda paling berguna?
RyanKDalton

6

Halo

Saya akan mengimpornya ke PostGIS terlebih dahulu. Ada alat untuk memuat beberapa bentuk ke tabel individual. Ekstensi ludah QGIS adalah satu. Shp2pgsql grafis baru di trunk PostGIS atau biner eksperimental adalah alternatif lain. Atau Anda bisa menulis skrip batch dengan shp2pgsql.

Saya akan mulai dari sana, mengimpor semuanya ke skema yang disebut asli atau sesuatu seperti itu. Kemudian dari situ saya akan menyusun data. Menggabungkan bersama dalam tabel mana yang cocok dan sebagainya.

Hal yang menyenangkan tentang melakukannya seperti itu adalah bahwa jika Anda menyimpan semua pertanyaan yang Anda gunakan untuk melakukan transformasi itu, Anda memiliki dokumentasi yang bagus tentang sejarah data Anda. Ini juga sangat mudah untuk diulang jika diperlukan. Setelah Anda siap dengan pekerjaan pengorganisasian, Anda membuang cadangan "asli" skema Anda dan menyimpannya di suatu tempat.

Saya pikir ini adalah cara yang terstruktur dan bersih untuk melakukannya. Dan seperti yang dikatakan sebelumnya, Anda akan mendapatkan dokumentasi yang sangat solid tentang bidang apa yang berubah nama menjadi nama baru apa, dan tabel asli apa yang digabungkan menjadi yang baru dan seterusnya.

Dalam FME dan perangkat lunak seperti itu Anda tentu saja juga dapat menyimpan apa yang telah Anda lakukan, tetapi selain sangat lambat dibandingkan dengan permintaan basis data internal, bukan cara universal mendokumentasikan apa yang dilakukan sebagai sql-queries. Mereka akan dapat digunakan dan dibaca selama ada file teks dan database relasional.

Saya gunakan untuk berakhir dengan file teks terlihat seperti:

-- 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;

dan seterusnya. Ini disimpan sebagai file teks memiliki nilai yang bagus setelah beberapa tahun.

Salam Nicklas


1
+1 Saya pikir ini adalah pendekatan yang sangat bagus. Semuanya dilakukan dalam Postgres, sangat transparan dan mudah diperbanyak jika dibutuhkan.
underdark

1
bukan rekomendasi yang baik untuk GIS berbasis ESRI. Sumber terbuka "hanya" ini akan diterima. ESRI memiliki lebih banyak dependensi yang tidak dapat diakses melalui metode ini. koneksi langsung ke postgis tidak diperbolehkan tanpa interop, server gis, atau arcsde.
Brad Nesom

2
@Brad Hmm, saya bertanya-tanya apakah itu argumen yang melakukan hal-hal dengan cara yang transparan dan dapat direproduksi secara transparan atau argumen agar tidak dikurung dengan menempatkan sde di antara saya dan data saya ... ;-)
Nicklas Avén

1
@Brad: colemanm tidak menyebutkan ESRI, jadi jawabannya sepertinya bagus.
underdark

Saya telah melakukan pekerjaan yang mirip dengan ini dengan ESRI Sde featureseclasses dan SQL Server 2008 (w / native geometry) - Saya membuat fitureclass terlebih dahulu, kemudian memuat dengan serangkaian pernyataan insert. IIRC, saya harus mengekspor featureeclass di akhir ke featureeclass baru karena saya tidak dapat membuat objectid baru dengan benar. setelah saya melakukan itu, bisnis seperti biasa.
Jay Cummins

4

Saran saya adalah memilih 2-5 dari lapisan data yang digunakan lebih berat (shapefile) dan memigrasikannya ke rdbms.
Selidiki dan terapkan alur kerja untuk data tersebut. Membiasakan diri dengan pembatasan dan persyaratan rdbms vs data berbasis file.

Keterbatasan meliputi: diperlukan ekspor, zona pendaratan, coordsys, tipe file untuk kolaborasi.

Ada banyak manfaat untuk apa yang Anda usulkan.
Sisi CATATAN: (Kakek saya mengatakan kepada orang tua saya untuk menghabiskan 6 bulan mencari rumah sebelum membeli) mempertimbangkan Anda mencari rumah (jangka panjang) untuk data Anda, Anda tidak ingin membayar sesuatu 30 tahun dari sekarang setelah Anda tidak suka.

Rekomendasi saya adalah menuliskan (digital atau analog) daftar pohon sumber data Anda dan melihatnya dalam gambar besar, ini akan memungkinkan Anda untuk mengatur data dalam pengelompokan yang lebih ringkas.

Ada beberapa metode dalam arcgis (asumsi saya: Anda belum menentukan sistem pilihan Anda) untuk mengintegrasikan data yang berbeda.

Anda dapat mencoba beberapa informasi ini jika Anda tertarik mempelajari praktik desain yang baik ...

ikhtisar desain
geodatabase dokumen geodatabase
Ada beberapa liinks yang serupa untuk arc 10 juga.
Resource Center
arc10 geodatabase

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.