Centralizzazione dei dati dello shapefile nel database


13

Ho centinaia di shapefile di vari progetti GIS diversi che voglio iniziare a consolidare in una singola piattaforma di database, attualmente sto provando questo con Postgres / PostGIS.

Quasi nessuno dei dati è standardizzato, il che significa che sono molti degli stessi tipi di dati , ma i nomi / tipi di attributo particolari non corrispondono.

Dove dovrei iniziare ad affrontare questo? Devo sviluppare un modello standard per migrare prima ogni file di forma (ad es. Hydro_line, transport_line, Hydro_poly standard, ecc.)?

Un'alternativa è importare ogni singolo file di forma in Postgres singolarmente, quindi ogni shp diventa una tabella nel database, ma non ne sono sicuro in termini di prestazioni e organizzazione. Sembra un po 'come ritardare l'inevitabile ...

Qualche consiglio su come affrontare questo compito scoraggiante?

Risposte:


7

Dai un'occhiata ai software ETL spaziali (Estrai - Trasforma - Carica), che sono dedicati a tali compiti. Il più noto è FME di Safe, ma ora sono disponibili alcune alternative open source (parziali), come SDI (Spatial Data Integrator) e GeoKettle .


2
Ho chiesto un confronto in una domanda precedente, quindi se segui questa strada, ti preghiamo di scrivere. gis.stackexchange.com/questions/5049/spatial-etl-comparisons
RyanKDalton

Ho preso una versione di prova di FME e ho installato sia SDI che GeoKettle. Li proverò e vedrò se riesco a dare un senso a loro. FME sembra una soluzione da zuppa a noci, ma prima dovrò superare la curva di apprendimento :).
Colemanm,

1
@ colemanm- Che cosa hai fatto su questo? Quale prodotto hai trovato più utile?
RyanKDalton,

6

ciao

Prima lo importerei su PostGIS. Esistono strumenti per caricare più forme su singole tabelle. L'estensione dello sputo di QGIS è una. Il nuovo shp2pgsql grafico nel trunk PostGIS o nei binari sperimentali è un'altra alternativa. Oppure potresti semplicemente scrivere uno script batch con shp2pgsql.

Vorrei iniziare da lì, importare tutto in uno schema chiamato originale o qualcosa del genere. Quindi da ciò strutturerei i dati. Fusione insieme nelle tabelle ove opportuno e così via.

La cosa bella di farlo in questo modo è che se salvi tutte le domande che usi per fare quelle trasformazioni hai una grande documentazione sulla storia dei tuoi dati. È anche molto facile rifarlo se necessario. Una volta che sei pronto con il tuo lavoro di organizzazione, scarichi un backup del tuo schema "originale" e lo metti da qualche parte.

Penso che questo sia un modo strutturato e pulito di farlo. E come detto prima, otterrai una documentazione molto solida su quale campo ha cambiato nome in quale nuovo nome, e quali tabelle originali vengono unite in quella nuova grande e così via.

In FME e software del genere puoi ovviamente salvare anche ciò che hai fatto, ma oltre ad essere molto lento rispetto alle query del database interno, non è quel modo universale di documentare ciò che viene fatto come sql-query. Saranno utilizzabili e leggibili finché ci saranno file di testo e database relazionali.

Uso per finire con file di testo che assomigliano a:

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

e così via. Questo salvato come file di testo ha un grande valore dopo alcuni anni.

Saluti Nicklas


1
+1 Penso che questo sia un ottimo approccio. Tutto è fatto in Postgres, molto trasparente e facilmente riproducibile se necessario.
underdark

1
non è una buona raccomandazione per i GIS basati sull'ESRI. L'open source "solo" sarebbe accettabile. ESRI ha molte più dipendenze che non sarebbero accessibili con questo metodo. la connessione diretta a Postgis non è consentita senza interoperabilità, server gis o arcsde.
Brad Nesom,

2
@ Brad Hmm, mi chiedo se questo sia un argomento prima di fare le cose in un modo trasparente riproducibile e veloce o un argomento contro essere bloccati mettendo sde tra me e i miei dati ... ;-)
Nicklas Avén

1
@Brad: colemanm non ha menzionato ESRI, quindi la risposta sembra essere buona.
underdark

Ho fatto un lavoro simile a questo con ESRI Sde featureclasses e SQL Server 2008 (con geometria nativa): ho creato prima la featureclass, quindi caricata con una serie di istruzioni insert. IIRC, alla fine ho dovuto esportare la featureclass in una nuova featureclass perché non riuscivo a generare correttamente nuovi objectid. una volta che l'ho fatto, affari come al solito.
Jay Cummins,

4

Il mio suggerimento sarebbe di selezionare 2-5 dei livelli di dati utilizzati più pesanti (shapefile) e migrarli in un rdbms.
Indagare e implementare workflow per tali dati. Abituarsi alle limitazioni e ai requisiti dei dati basati su file rdbms.

Le limitazioni includono: esportazione richiesta, area di atterraggio, coordsys, tipo di file per la collaborazione.

Ci sono molti vantaggi in ciò che stai proponendo.
Nota a margine: (mio nonno ha detto ai miei genitori di spendere 6 mesi alla ricerca di una casa prima di acquistare) considera che stai cercando una casa (a lungo termine) per i tuoi dati, non vuoi pagare per qualcosa di 30 anni da adesso che non mi piace.

La mia raccomandazione sarebbe quella di scrivere (digitale o analogico) un elenco ad albero delle tue fonti di dati e visualizzarle in un quadro generale, questo dovrebbe consentire di organizzare i dati in raggruppamenti più concisi.

Ci sono metodi all'interno di arcgis (il mio presupposto: non hai specificato il tuo sistema preferito) per integrare dati disparati.

Potresti provare alcune di queste informazioni se sei interessato ad apprendere buone pratiche di progettazione ...

panoramica della progettazione del geodatabase
geodatabase documentaion
Esistono anche simili similitudini per l'arco 10.
Centro risorse
arc10 geodatabase

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.