Come utilizzare PostGIS per gestire complessi flussi di lavoro di geoprocessing?

12

La nostra organizzazione sta valutando di spostare il flusso di lavoro di geoprocessing su PostGIS. Attualmente stiamo utilizzando ArcGIS, con una pletora di strumenti Python personalizzati utilizzati in ModelBuilder. Stiamo trasferendo la maggior parte dei nostri dati in PostGIS per essere consumati da una varietà di app e ora stiamo chiedendo se sia logico eseguire anche lì l'elaborazione dei dati.

Elaboriamo i dati per essere compatibili con il nostro software. Un cliente acquista il nostro software, ci fornisce i propri dati e lo elaboriamo per essere ottimizzato per l'uso nel nostro software. Ciò richiede che creiamo una varietà di strumenti per gestire le diverse qualità dei dati di input. Non possiamo aspettarci di ricevere dati in un particolare formato o schema, quindi costruiamo strumenti per mappare i campi di input ai campi di output, analizzare singoli campi in più campi, unire più set di dati, ecc. Eseguiamo anche join spaziali, intersezioni, taglia spazi bianchi e concatena i campi e molte altre operazioni comuni. PostGIS sembra perfettamente in grado di soddisfare tutte le nostre esigenze di elaborazione.

Per quelli di voi che usano PostGIS per l'elaborazione dei dati, avete qualche consiglio per l'organizzazione, strumenti da usare, ecc.?

lo usi insieme all'elaborazione python di QGIS?
le persone utilizzano un ORM Python per l'elaborazione non web? Sono stato incline a utilizzare GeoDjango poiché ha un ORM Python per PostGIS. Il nostro test iniziale sull'utilizzo di PostGIS per elaborare i dati ha molti blocchi di testo SQL di grandi dimensioni nel codice Python e stiamo pensando che GeoDjango ORM potrebbe aiutare a creare codice più gestibile e leggibile. C'è anche il GeoAlchemy ORM che interagisce in modo simile con PostGIS e non sembra essere specifico del web come Django.

Non ho sentito parlare di persone che usano PostGIS per fare geoprocessing tanto quanto vedo persone che usano QGIS o ArcGIS, quindi voglio sapere se si tratta di un'alternativa comparabile.

— conciatore
fonte

1

Tutto il tuo processo è "backend"? Non sono un utente Django o GeoDjango, ma penso a quei prodotti solo per lo sviluppo di siti Web (e più problemi di quanti ne valgano, IMHO). Perché non solo un mucchio di script shell o python eseguiti dalla riga di comando (Unix ovviamente) o periodicamente tramite "cron"? (Meno clickey-clickey è sempre meglio nella mia mente.) Probabilmente vorrai organizzarli sistematicamente, almeno per flusso di dati in entrata. Inoltre, Postgis può probabilmente tagliare e tagliare i dati senza QGIS: quali tipi specifici di operazioni hai in mente?

— Forkandwait

1

Sì, la nostra elaborazione è backend. Tuttavia, alla fine avremo una mappa Web OpenLayers per consentire ai clienti di visualizzare e modificare i propri dati. Potremmo usare Django per gli account utente e amministratore dell'app. In tal caso, ho pensato che potrebbe essere un altro motivo per esaminare GeoDjango per l'elaborazione, anche se Django è stato creato principalmente per i siti Web. Questa elaborazione su larga scala con presentazione di Django suggerisce che Django non è solo per i siti Web: slideshare.net/dibau_naum_h/large-scale-processing-with-django

— Tanner

1

Per il lavoro di backend, userei PostGIS, un po 'di ogr2ogr, un linguaggio di scripting (Python, Ruby, Tcl, qualunque cosa) e una riga di comando unix. Eviterei di provare a mescolare Django in questo, tranne per mantenere il database il più compatibile possibile con esso. Quindi, mettici un front-end se ne hai bisogno. La mia regola è: meno clickey = più produttivo (anche se gli analisti GIS si sentono più a loro agio con la merda clickey-clickey ... intendo "interfacce intuitive").

— Forkandwait

Per quanto riguarda la slide - sembra follemente complicato e forse appropriato se stai tassando la tua potenza di elaborazione cercando di tenere il passo, ma per il resto da incubo da gestire.

— Forkandwait

1

Un paio di domande etl generiche che potresti trovare utili: " Confronti spaziali ETL " e " Esistono alternative sicure per me? "

— RyanKDalton

8

Mi piace molto usare PostGIS per scopi di geoprocessing.

Le mie due principali risonanze sono:

1) Spesso è molto più veloce eseguire attività complesse nel database perché si ottiene l'aiuto del pianificatore di query per eseguire le operazioni nel giusto ordine.

2) Basta salvare le righe sql che hai usato in un file di testo e hai un'ottima documentazione di ciò che hai fatto.

Il mio flusso di lavoro, se le attività comportano molti "passaggi" possono essere qualcosa del tipo:
1- Costruisci parti della query o tutte in base alla natura dell'attività
2- Verifica la query su una piccola parte del set di dati per vedere come funziona
3- Effettuare alcune modifiche se necessario
4- Eseguire la query sull'intero set di dati
5- Salvare le righe in un file di testo con alcune note.
Tutto questo è spesso veloce quanto l'avvio di ArcGIS e attendere una licenza dal server delle licenze.

— Nicklas Avén
fonte

5

Usiamo PostGIS e un qualche tipo di ambiente di programmazione Python per un numero di servizi Web di geoprocessing di produzione che abbiamo sviluppato; nessun reclamo!

GeoDjango è un'ottima scelta se lavori principalmente (o esclusivamente) con funzionalità per un'applicazione web. Non supporta il tipo di dati raster di PostGIS Raster o PostGIS 2.0. Ora arriva nativamente con l'ultima versione di Django. Puoi compensare la mancanza di supporto raster e robustezza generale utilizzando query SQL non elaborate personalizzate in Django.

Per applicazioni di geoprocessing più solide, e in particolare se stai cercando di utilizzare un modello relazionale ad oggetti, prova GeoAlchemy2. La libreria GeoAlchemy originale, che estende SQLAlchemy, fornisce supporto per i dati delle funzionalità; GeoAlchemy2 lo estende fornendo supporto (limitato) per il nuovo tipo di dati raster in PostGIS 2.0.

E poi, ci sono sempre i collegamenti Python per GDAL e OGR!

— Artù
fonte

YMMV, ma trovo che le librerie relazionali ad oggetti non aggiungano davvero nulla al semplice vecchio SQL. Come ho detto in un altro commento, sarebbe molto interessante ascoltare i dettagli.

— Forkandwait

4

Posso descrivere un caso di studio: un servizio web per la generazione di input raster per un modello di erosione post-incendio. Fondamentalmente, un certo numero di raster deve essere un sottoinsieme e aggiunto l'uno all'altro. Ho selezionato GeoAlchemy2 (GA2) per l'interfaccia con PostGIS, dove sono memorizzati i dati. Usando GA2, posso creare query PostGIS compatte e riutilizzabili. Una query crea un prodotto "copertura del suolo bruciato" (una riclassificazione di una copertura del suolo, sottoinsieme). Questo prodotto è necessario da solo per alcuni modelli, ma viene anche aggiunto a un altro raster, uno strato di terreno, per produrre un terzo prodotto di output. GA2 mi permette di mixare, abbinare e serializzare in Python.

— Arthur,

3

Per quanto possibile, è difficile immaginare che si vorrebbe fare molto geoprocessing all'interno di un motore di database o di un framework web. Ti consiglio di guardare le librerie di codice sottostanti - geos, proj.4 e gdal. Ci sono associazioni o librerie Python per tutti e tre. Un'altra opzione da esaminare è il plug-in geoprocess Sextante per QGIS, in quanto consente la creazione di modelli / flussi di lavoro.

Alcuni altri pensieri:

Non escludere l'uso di PostGIS. Offre buone capacità di archiviazione e server ed espone alcune funzionalità geos e proj.4 tramite SQL. Funziona bene anche con gli altri strumenti citati: Django, QGIS e Python.

Oltre al possibile utilizzo del suddetto plugin Sextante, QGIS è ottimo per la visualizzazione, ha alcuni strumenti per lavorare con Postgres e include anche una console Python.

Se stai cercando ORM e desideri un front-end Web, Django lo farà. Se non ti dispiace un'interfaccia tutt'altro che sexy, le pagine di amministrazione ti daranno un'interfaccia CRUD con relativamente poco sforzo, persino l'editing della geometria se usi GeoDjango.

— Scro
fonte

2

Anche se sarei d'accordo sul fatto che uno non userebbe un framework web per fare il geoprocessing, non sono fortemente d'accordo sul fatto che non si userebbe PostGIS (o un altro motore di database) per fare il geoprocessing. Abbiamo bisogno di specifiche per andare avanti nella discussione, ma eseguo un'enorme quantità di divisione / taglio della geometria e analisi point-in-poly usando PostGIS e SQL.

— Forkandwait

2

@forkandwait Oh, sono d'accordo con te su PostGIS. Tuttavia, ho avuto l'impressione che utilizzino un numero di piccoli script che potrebbero essere collegati in modo diverso per ciascun progetto. Il mio obiettivo era di indurli a studiare le librerie sottostanti in modo che potessero scegliere quale ambiente funzionasse meglio.

— Scro

3

Dai un'occhiata a ETL , in particolare FME per operazioni spaziali (o GeoKettle open source ).

Mi piace molto usare FME, in quanto crea un flusso di lavoro visivo e puoi separare la logica per operazioni spaziali, join, fusioni ... tutto e puoi lavorare con formati non di database e database diversi ... Puoi fare molto, facile e veloce. Se hai esperienza con il modellista, lo raccoglierai rapidamente, inoltre c'è molta documentazione online.

L'unico svantaggio di FME è che costa denaro. Ma penso che ne valga la pena.

Un'alternativa all'utilizzo di FME è probabilmente GDAL e OGR insieme a forse Python per legarlo insieme. O, come dici tu, facendo tutto in PostgreSQL. Penso che un ETL abbia un ruolo importante nella lotta ai dati spaziali, e fa molto che non puoi fare solo nel tuo database.

Non l'ho usato, ma GeoServer fornisce un'implementazione di WPS , non l'ho usato, ma altri potrebbero commentare come questo potrebbe esserti utile?

Non posso commentare l'utilizzo di GeoDjango, ma ho pensato che fosse più un CMS, come un front-end per la visualizzazione dei dati.

— Alex Leith
fonte