Bagaimana cara menggunakan PostGIS untuk menangani alur kerja geoproses yang kompleks?

12

Organisasi kami sedang mempertimbangkan untuk memindahkan alur kerja geoproses kami ke PostGIS. Kami saat ini menggunakan ArcGIS, dengan sejumlah besar alat Python khusus yang digunakan dalam ModelBuilder. Kami memindahkan sebagian besar data kami ke PostGIS untuk dikonsumsi oleh berbagai aplikasi, dan sekarang kami bertanya apakah masuk akal untuk melakukan pemrosesan data di sana juga.

Kami memproses data agar kompatibel dengan perangkat lunak kami. Pelanggan membeli perangkat lunak kami, memberi kami data mereka, dan kami memprosesnya agar dioptimalkan untuk digunakan dalam perangkat lunak kami. Ini mengharuskan kami untuk membangun berbagai alat untuk menangani berbagai kualitas data input. Kami tidak dapat mengharapkan untuk menerima data dalam format atau skema tertentu, jadi kami membangun alat untuk memetakan bidang input ke bidang output, memilah bidang tunggal ke dalam beberapa bidang, menggabungkan beberapa kumpulan data, dll. Kami juga melakukan penggabungan spasial, persimpangan, trim spasi putih dan bidang gabungan, dan banyak operasi umum lainnya. PostGIS tampaknya sangat mampu melakukan semua kebutuhan pemrosesan kami.

Bagi Anda yang menggunakan PostGIS untuk melakukan pemrosesan data Anda, apakah Anda punya saran untuk organisasi, alat untuk digunakan, dll?

  • apakah Anda menggunakannya bersamaan dengan pemrosesan python QGIS?
  • orang menggunakan Python ORM untuk pemrosesan non-web? Saya telah condong ke arah menggunakan GeoDjango karena memiliki ORM Python untuk PostGIS. Tes awal kami menggunakan PostGIS untuk memproses data memiliki banyak blok teks SQL besar dalam kode Python dan kami berpikir bahwa GeoDjango ORM dapat membantu menciptakan kode yang lebih mudah dikelola dan dibaca. Ada juga GeoAlchemy ORM yang berinteraksi mirip dengan PostGIS, dan tampaknya tidak se-spesifik web seperti Django.

Saya belum pernah mendengar orang menggunakan PostGIS untuk melakukan geoproses seperti yang saya lihat orang menggunakan QGIS atau ArcGIS, jadi saya ingin tahu apakah ini merupakan alternatif yang sebanding.

python postgis geoprocessing geodjango geoalchemy Penyamak
sumber
1
Apakah semua proses Anda "backend"? Saya bukan pengguna Django atau GeoDjango, tapi saya pikir produk-produk itu hanya untuk mengembangkan situs web (dan lebih banyak masalah daripada nilainya, IMHO). Mengapa tidak hanya sekelompok skrip shell atau python dijalankan pada baris perintah (Unix tentu saja) atau secara berkala melalui "cron"? (Lebih sedikit clickey-clickey selalu lebih baik di pikiran saya.) Anda mungkin ingin mengatur ini secara sistematis, setidaknya dengan aliran data yang masuk. Selain itu, Postgis mungkin dapat mengiris dan memotong data Anda tanpa QGIS - jenis operasi apa yang Anda pikirkan?
forkandunggu
1
Ya, pemrosesan kami adalah backend. Namun, pada akhirnya kami akan memiliki peta web OpenLayers bagi pelanggan untuk melihat dan mengedit data mereka. Kami mungkin menggunakan Django untuk pengguna aplikasi dan akun admin. Jika demikian, saya pikir itu mungkin menjadi alasan lain untuk melihat GeoDjango untuk diproses, meskipun Django dibangun terutama untuk situs web. Presentasi Skala Besar dengan presentasi Django ini menunjukkan bahwa Django tidak hanya untuk situs web: slideshare.net/dibau_naum_h/large-scale-processing-with-django
Tanner
1
Untuk pekerjaan backend, saya akan menggunakan PostGIS, sedikit ogr2ogr, bahasa scripting (Python, Ruby, Tcl, apa pun), dan baris perintah unix. Saya akan menghindari mencoba mencampur Django ke dalam itu kecuali untuk menjaga database Anda serapat mungkin dengannya. Kemudian, letakkan ujung depan di atasnya jika Anda membutuhkannya. Aturan saya adalah: kurang clickey = lebih produktif (meskipun analis GIS merasa lebih nyaman dengan clickey-clickey omong kosong ... maksud saya "antarmuka intuitif").
forkandunggu
Mengenai slideshare - yang terlihat sangat rumit, dan mungkin sesuai jika Anda mengenakan pajak kekuatan pemrosesan Anda mencoba untuk mengikutinya, tetapi sebaliknya mimpi buruk untuk dikelola.
forkandunggu
1
Beberapa pertanyaan umum etl yang mungkin Anda temukan membantu: " Perbandingan ETL spasial " dan " Apakah ada alternatif aman untuk saya? "
RyanKDalton

Jawaban:

8

Saya sangat suka menggunakan PostGIS untuk keperluan geoproses.

Dua resons utama saya adalah:

1) Sering kali jauh lebih cepat untuk melakukan tugas-tugas kompleks dalam database karena Anda mendapatkan bantuan dari perencana kueri untuk melakukan hal-hal dalam urutan yang benar.

2) Cukup simpan baris sql yang Anda gunakan dalam file teks dan Anda memiliki dokumentasi yang sangat baik tentang apa yang telah Anda lakukan.

Alur kerja saya, jika tugas melibatkan banyak "langkah" digunakan untuk menjadi sesuatu seperti:
1- Membangun bagian dari permintaan atau semuanya tergantung pada sifat tugas
2- Uji tes permintaan pada sebagian kecil dari dataset untuk lihat bagaimana kinerjanya
3- Lakukan penyesuaian jika perlu
4- Jalankan kueri pada seluruh dataset
5- Simpan baris dalam file teks dengan beberapa catatan.
Semua ini sering tentang memulai ArcGIS dan menunggu lisensi dari server lisensi.

Nicklas Avén
sumber
5

Kami menggunakan PostGIS dan semacam lingkungan pemrograman Python untuk sejumlah layanan web geoproses produksi yang kami kembangkan; Tidak ada komplain!

GeoDjango adalah pilihan tepat jika Anda bekerja sebagian besar (atau secara eksklusif) dengan fitur untuk aplikasi web. Itu tidak mendukung tipe data raster PostGIS atau PostGIS 2.0. Itu datang secara native dengan versi terbaru Django, sekarang. Anda dapat menebus kurangnya dukungan raster dan ketahanan keseluruhan dengan menggunakan custom, query SQL mentah di Django.

Untuk aplikasi geoproses yang lebih kuat, dan khususnya jika Anda ingin menggunakan model objek-relasional, cobalah GeoAlchemy2. Pustaka GeoAlchemy asli, yang memperluas SQLAlchemy, menyediakan dukungan untuk data fitur; GeoAlchemy2 memperluasnya dengan menyediakan (terbatas) dukungan untuk tipe data raster baru di PostGIS 2.0.

Dan kemudian, selalu ada binding Python untuk GDAL dan OGR!

Arthur
sumber
YMMV, tapi saya menemukan perpustakaan objek-relasional tidak benar-benar menambahkan apa pun ke SQL lama biasa. Seperti yang saya katakan di komentar lain, akan sangat menarik untuk mendengar secara spesifik.
forkandunggu
4
Saya dapat menggambarkan studi kasus: layanan web untuk menghasilkan input raster untuk model erosi pasca-kebakaran. Pada dasarnya, sejumlah raster harus diatur ulang dan ditambahkan satu sama lain. Saya memilih GeoAlchemy2 (GA2) untuk berinteraksi dengan PostGIS, tempat data disimpan. Menggunakan GA2, saya bisa membuat pertanyaan PostGIS yang ringkas dan dapat digunakan kembali. Satu permintaan menciptakan produk "tutupan lahan terbakar" (reklasifikasi tutupan lahan, subset). Produk ini diperlukan sendiri untuk beberapa pemodelan, tetapi juga ditambahkan ke raster lain, lapisan tanah, untuk menghasilkan produk keluaran ketiga. GA2 memungkinkan saya mencampur, mencocokkan, dan membuat serial dengan Python.
Arthur
3

Meskipun mungkin, sulit untuk membayangkan bahwa Anda ingin melakukan banyak geoproses di dalam mesin basis data atau kerangka kerja web. Saya sarankan Anda melihat pustaka kode yang mendasarinya - geos, proj.4, dan gdal. Ada binding Python atau perpustakaan untuk ketiganya. Opsi lain untuk melihat adalah plugin geoproses Sextante untuk QGIS, karena memungkinkan pengembangan model / alur kerja.

Beberapa pemikiran lain:

Jangan mengesampingkan penggunaan PostGIS. Ini memberikan penyimpanan yang baik dan kemampuan server, dan memperlihatkan beberapa fungsi geo dan proj.4 melalui SQL. Ini juga bermain bagus dengan alat-alat lain yang disebutkan: Django, QGIS, dan Python.

Selain kemungkinan penggunaan plugin Sextante tersebut di atas, QGIS baik untuk visualisasi, memiliki beberapa alat untuk bekerja dengan postgres, dan juga termasuk konsol Python.

Jika Anda mencari ORM dan menginginkan ujung depan web, Django akan melakukannya. Jika Anda tidak keberatan dengan antarmuka yang kurang seksi, halaman admin akan memberi Anda antarmuka CRUD dengan sedikit usaha - bahkan pengeditan geometri jika Anda menggunakan GeoDjango.

Scro
sumber
2
Walaupun saya akan setuju bahwa seseorang tidak akan menggunakan kerangka kerja web untuk melakukan geoprocessing, saya sangat tidak setuju bahwa seseorang tidak akan menggunakan PostGIS (atau mesin database lain) untuk melakukan geoprocessing. Kita perlu spesifik untuk bergerak maju dalam diskusi, tetapi saya melakukan sejumlah besar geometri mengiris / dicing dan analisis point-in-poly menggunakan PostGIS dan SQL.
forkandunggu
2
@forkandunggu Oh, saya setuju dengan Anda di PostGIS. Namun, saya mendapat kesan bahwa mereka menggunakan sejumlah skrip kecil yang mereka dapat rantai berbeda untuk setiap proyek. Tujuan saya adalah membuat mereka menyelidiki perpustakaan yang mendasarinya sehingga mereka dapat memilih lingkungan mana yang paling berhasil.
Scro
3

Lihatlah ETL , khususnya, FME untuk operasi spasial (atau GeoKettle open source ).

Saya sangat suka menggunakan FME, karena menciptakan alur kerja visual, dan Anda dapat memisahkan logika untuk operasi spasial, bergabung, menggabungkan ... semuanya, dan Anda dapat bekerja dengan format non-basis data, dan berbagai basis data ... Anda dapat lakukan banyak, dan mudah, dan cepat. Jika Anda memiliki pengalaman dengan pembuat model, Anda akan mengambilnya dengan cepat, plus ada banyak dokumentasi online.

Satu-satunya kelemahan FME adalah membutuhkan biaya. Tapi saya pikir itu sepadan.

Alternatif untuk menggunakan FME mungkin adalah GDAL dan OGR bersama dengan mungkin Python untuk menyatukannya. Atau, seperti yang Anda katakan, melakukan semuanya di PostgreSQL. Saya pikir ETL memiliki peran yang kuat dalam perselisihan data spasial, dan itu banyak yang tidak bisa Anda lakukan hanya dalam database Anda.

Saya belum pernah menggunakannya, tetapi GeoServer menyediakan implementasi WPS , saya belum pernah menggunakan ini, tetapi orang lain mungkin berkomentar bagaimana ini bisa bermanfaat bagi Anda?

Saya tidak bisa mengomentari menggunakan GeoDjango, tapi saya pikir itu lebih merupakan CMS, seperti front-end untuk melihat data.

Alex Leith
sumber