PostGIS, karmaşık coğrafi işleme iş akışlarını işlemek için nasıl kullanılır?

12

Kuruluşumuz coğrafi işleme iş akışımızı PostGIS'e taşımayı düşünüyor. Şu anda ArcGIS'i, ModelBuilder'da kullanılan çok sayıda özel Python aracıyla kullanıyoruz. Verilerimizin çoğunu çeşitli uygulamalar tarafından tüketilmek üzere PostGIS'e taşıyoruz ve şimdi de orada veri işlemeyi gerçekleştirmenin de mantıklı olup olmadığını soruyoruz.

Verileri yazılımımızla uyumlu olacak şekilde işleriz. Bir müşteri yazılımımızı satın alır, bize verilerini verir ve yazılımımızda kullanılmak üzere optimize edilmek üzere işleriz. Bu, çeşitli girdi verilerinin niteliklerini ele almak için çeşitli araçlar geliştirmemizi gerektirir. Belirli bir biçimde veya şemada veri almayı bekleyemeyiz, bu nedenle girdi alanlarını çıktı alanlarıyla eşleştirmek, tek alanları birden çok alana ayrıştırmak, birden çok veri kümesini birleştirmek vb. İçin araçlar geliştiririz. alanları ve diğer birçok ortak işlemi birleştirin. PostGIS, tüm işleme ihtiyaçlarımızı mükemmel bir şekilde yerine getirebilir.

Veri işlemenizi yapmak için PostGIS kullananlarınız için kuruluş, kullanım araçları vb. Konusunda herhangi bir tavsiyeniz var mı?

QGIS python işleme ile birlikte kullanıyor musunuz?
olmayan işlemler için Python ORM kullanıyorlar mı? PostGIS için bir Python ORM olduğundan GeoDjango kullanmaya doğru eğildim. Verileri işlemek için PostGIS kullanma ilk testimizde Python kodunda birçok büyük SQL metin bloğu vardır ve GeoDjango ORM'nin daha yönetilebilir ve okunabilir kod oluşturmaya yardımcı olabileceğini düşünüyoruz. PostGIS ile benzer şekilde etkileşime giren ve Django kadar web'e özgü görünmeyen GeoAlchemy ORM de var .

QGIS veya ArcGIS kullanan insanları gördüğüm kadar PostGIS kullanan insanları duymadım, bu yüzden karşılaştırılabilir bir alternatif olup olmadığını bilmek istiyorum.

— tabakçı
kaynak

1

Tüm süreçleriniz "arka uç" mu? Ben bir Django veya GeoDjango kullanıcısı değilim, ama sadece web siteleri geliştirmek için bu ürünleri düşünüyorum (ve değer daha fazla sorun, IMHO). Neden sadece bir grup kabuk veya python betiği (tabii ki Unix) komut satırında veya periyodik olarak "cron" üzerinden çalıştırılmıyor? (Daha az clickey-clickey bence her zaman daha iyidir.) Muhtemelen bunları, en azından gelen veri akışıyla sistematik olarak düzenlemek istersiniz. Ayrıca, Postgis muhtemelen verilerinizi QGIS olmadan dilimleyebilir ve kesebilir - aklınızda hangi belirli işlem türleri var?

— forkandwait

1

Evet, bizim işleme backend olduğunu. Ancak, sonunda müşterilerinin verilerini görüntülemesi ve düzenlemesi için bir OpenLayers web haritasına sahip olacağız. Uygulamanın kullanıcı ve yönetici hesapları için Django kullanabiliriz. Eğer öyleyse, Django öncelikle web siteleri için inşa edilmiş olsa da, işlem için GeoDjango'ya bakmak için başka bir neden olabileceğini düşündüm. Django ile yapılan bu Büyük Ölçekli İşlem, Django'nun sadece web siteleri için olmadığını ileri sürmektedir: slideshare.net/dibau_naum_h/large-scale-processing-with-django

— Tanner

1

Arka uç çalışması için PostGIS, biraz ogr2ogr, bir komut dosyası dili (Python, Ruby, Tcl, neyse) ve bir unix komut satırı kullanacağım. Ben veritabanını onunla mümkün olduğunca uyumlu tutmak dışında içine Django karıştırmaya çalışırken önlemek istiyorum. Daha sonra ihtiyacınız varsa üzerine bir ön uç koyun. Benim kuralım: daha az clickey = daha üretken (CBS analistleri clickey-clickey saçmalıklarıyla daha rahat hissetmelerine rağmen ... "sezgisel arayüzler" demek istiyorum).

— forkandwait

Slayt paylaşımına gelince - bu son derece karmaşık görünüyor ve belki de işlem gücünüzü korumaya çalışırken vergilendiriyorsanız, ancak aksi takdirde yönetmeye kabus iseniz uygun olabilir.

— forkandwait

1

Yararlı bulabileceğiniz birkaç genel etl sorusu: " Uzamsal ETL karşılaştırmaları " ve " Güvenli fme alternatifleri var mı? "

— RyanKDalton

8

PostGIS'i coğrafi işleme amaçları için kullanmayı seviyorum.

İki ana rezonum:

1) Veritabanında karmaşık görevler yapmak genellikle çok daha hızlıdır, çünkü sorgu planlamacısından işleri doğru sırada yapmak için yardım alırsınız.

2) Bir metin dosyasında kullandığınız sql satırlarını kaydedin ve yaptığınız şey hakkında çok iyi bir belgeleriniz var.

Benim iş akışı, görevleri "adımlar" çok içeriyorsa gibi bir şey kullanın:
1- Sorgunun bölümlerini veya tümünü görevin yapısına bağlı olarak oluşturmak
2- Sorgu için veri kümesinin küçük bir bölümünde sınayın nasıl çalıştığını görün
3- Gerekirse biraz ince ayar yapın
4- Tüm veri kümesinde sorguyu çalıştırın
5- Satırları bazı notlarla bir metin dosyasına kaydedin.
Bütün bunlar genellikle ArcGIS'i başlatmak kadar hızlıdır ve lisans sunucusundan bir lisans beklemektedir.

— Nicklas Avén
kaynak

5

Geliştirdiğimiz çok sayıda üretim coğrafi işleme web hizmeti için PostGIS ve bir çeşit Python programlama ortamı kullanıyoruz; şikayet yok!

GeoDjango, bir web uygulamasının özellikleriyle çoğunlukla (veya yalnızca) çalışıyorsanız mükemmel bir seçimdir. PostGIS Raster veya PostGIS 2.0'ın raster veri türünü desteklemez. Şimdi, Django'nun en son sürümü ile yerel olarak geliyor . Django'da özel, ham SQL sorguları kullanarak raster desteği ve genel sağlamlık eksikliğini telafi edebilirsiniz.

Daha sağlam coğrafi işleme uygulamaları için ve özellikle nesne ile ilişkisel bir model kullanmak istiyorsanız GeoAlchemy2'yi deneyin. SQLAlchemy'yi genişleten orijinal GeoAlchemy kütüphanesi, özellik verileri için destek sağlar; GeoAlchemy2 , PostGIS 2.0'daki yeni tarama veri türü için (sınırlı) destek sağlayarak bunu genişletir .

Ve sonra, GDAL ve OGR için her zaman Python bağları var!

— Arthur
kaynak

YMMV, ancak nesne-ilişkisel kütüphanelerin eski SQL'e gerçekten bir şey eklemediğini görüyorum. Başka bir yorumda söylediğim gibi, ayrıntıları duymak en ilginç olurdu.

— forkandwait

4

Bir vaka çalışmasını tanımlayabilirim: yangın sonrası erozyon modeli için raster girdileri oluşturmak için bir web hizmeti. Temel olarak, bir dizi raster alt kümeye eklenmeli ve birbirine eklenmelidir. Verilerin depolandığı PostGIS ile arayüz oluşturmak için GeoAlchemy2'yi (GA2) seçtim. GA2'yi kullanarak kompakt, yeniden kullanılabilir PostGIS sorguları oluşturabilirim. Bir sorguda "yanmış arazi örtüsü" ürünü (arazi örtüsü, altkümesi yeniden sınıfı) oluşturulur. Bu ürün bazı modelleme için kendi başına gereklidir, ancak üçüncü bir çıktı ürünü üretmek için başka bir raster olan bir toprak katmanına da eklenir. GA2, Python'da karıştırmamıza, eşleştirmemize ve serileştirmeme izin veriyor.

— Arthur

3

Mümkün olsa da, bir veritabanı motorunun veya web çerçevesinin içinde çok fazla coğrafi işlem yapmak istediğinizi hayal etmek zor. Coğrafi, proj.4 ve gdal gibi temel kod kitaplıklarına bakmanızı öneririm. Her üçü için de Python bağları veya kütüphaneleri vardır. İncelenecek diğer bir seçenek de, model / iş akışı oluşturmaya izin verdiği için QGIS için Sextante geoprocess eklentisidir.

Başka düşünceler:

PostGIS kullanımını göz ardı etmeyin. İyi depolama ve sunucu yetenekleri sağlar ve SQL üzerinden bazı coğrafi ve proj.4 işlevlerini sunar. Bahsedilen diğer araçlarla da iyi oynuyor: Django, QGIS ve Python.

Yukarıda sözü edilen Sextante eklentisinin olası kullanımının yanı sıra, QGIS görselleştirme için iyidir, postgres ile çalışmak için bazı araçlara sahiptir ve ayrıca bir Python konsolu içerir.

ORM arıyorsanız ve bir web kullanıcı arabirimi istiyorsanız, Django bunu yapacaktır. Seksi olmayan bir arayüze aldırmazsanız, yönetici sayfaları size nispeten az çaba harcayan bir CRUD arayüzü verecektir - GeoDjango kullanıyorsanız geometri düzenleme bile.

— SCRO
kaynak

2

Biri coğrafi işlem yapmak için bir web çerçeve kullanmayacağını kabul ederken, bir kişinin coğrafi işlem yapmak için PostGIS (veya başka bir veritabanı motoru) kullanmayacağına kesinlikle katılmıyorum. Tartışmada ilerlemek için spesifikasyonlara ihtiyacımız var, ancak PostGIS ve SQL kullanarak çok sayıda geometri dilimleme / küp şeklinde kesme ve poli-in-point analizi yapıyorum.

— forkandwait

2

@forkandwait Oh, PostGIS konusunda sana katılıyorum. Ancak, her proje için farklı şekilde zincirleyebilecekleri küçük komut dosyaları kullandıkları izlenimini edindim. Amacım, hangi ortamın en iyi sonucu verdiğini seçebilmeleri için temeldeki kütüphaneleri araştırmalarını sağlamaktı.

— Scro

3

Bir göz atın ETL , özellikle FME mekansal operasyonlar (veya açık kaynak için GeoKettle ).

Görsel bir iş akışı oluşturduğu için FME kullanmayı gerçekten seviyorum ve mekansal işlemler, birleşmeler, birleştirmeler için her şeyi ayırabilirsiniz ... her şey ve veritabanı olmayan biçimlerle ve farklı veritabanlarıyla çalışabilirsiniz ... çok ve kolay ve hızlı yapın. Model oluşturucu ile deneyiminiz varsa, hızlı bir şekilde alacaksınız ve ayrıca çevrimiçi olarak çok sayıda belge var.

FME'nin tek dezavantajı paraya mal olmasıdır. Ama bence buna değer.

FME kullanmanın bir alternatifi, muhtemelen bağlamak için Python ile birlikte muhtemelen GDAL ve OGR'dir. Ya da, dediğin gibi, hepsini PostgreSQL'de yapıyor. Bence bir ETL uzamsal veri karmaşasında güçlü bir role sahiptir ve sadece veritabanınızda yapamayacağınız çok şey yapar.

Kullanmadım, ancak GeoServer bir WPS uygulaması sağlıyor , bunu kullanmadım, ancak diğerleri bunun sizin için nasıl yararlı olabileceği konusunda yorum yapabilir mi?

GeoDjango kullanarak yorum yapamam, ama veri görüntülemek için bir ön uç gibi, daha fazla bir CMS olduğunu düşündüm.

— Alex Leith
kaynak