Come hai scoperto per tentativi ed errori, c'erano pochi problemi fastidiosi che dovevi risolvere, l'ultimo dei quali è stato risolto usando l' argomento -nlt GEOMETRY
* di ogr2ogr .
* Nota la raccomandazione nel commento di @ LeeHachadoorian che -nlt PROMOTE_TO_MULTI
verrà utilizzata come soluzione predefinita, piuttosto che nlt GEOMETRY
, poiché la prima promuove le migliori pratiche oltre ai benefici accessori.
Autorizzazioni utente e messaggi di errore
Innanzitutto, ogr2ogr non è stato in grado di aprire il tuo file di forma e ti sei reso conto che i problemi con le autorizzazioni stavano effettivamente interessando l'utente del sistema operativo che accedeva al tuo file di forma. Ma c'è una lezione importante qui per gli altri, in particolare, il messaggio di errore di ogr2ogr su questo punto era fuorviante! In effetti, uno dei primi commentatori ha ritenuto che il tuo file di forma non fosse valido e, devo ammettere, la mia prima ipotesi era che probabilmente c'era un errore / errore di battitura nel percorso / nome file o che potrebbe esserci stato un carattere non convenzionale nel percorso del file, come un spazio: stava rompendo la capacità di ogr2ogr di indicare lo shapefile. Come hai scoperto, in realtà era solo un problema con le autorizzazioni utente. Poiché il messaggio di errore crea un'aringa rossa, questa è una possibilità che gli altri devono tenere nella parte posteriore delle loro menti. :)
Privilegi utente SQL e errori misteriosi
Sarei rimasto sconcertato dal tuo secondo errore per un po ', ma testando il tuo utente SQL con una diversa utility di importazione (shp2pgsql), che era intelligente, hai ricevuto un messaggio di errore più preciso e hai dato al tuo utente SQL i privilegi necessari sul spatial_ref_sys
tavolo. Pertanto, qualcuno che ha difficoltà a far funzionare correttamente le proprie istruzioni di importazione ogr2ogr dovrebbe assicurarsi che il proprio utente SQL disponga di privilegi sufficienti sia sul database stesso che sulla tabella 'spatial_ref_sys'.
Tipi di geometria mista e migliori pratiche
L'ultimo ostacolo che hai incontrato sembra correlato al fatto che gli shapefile consentono a geometrie sia singole che multipart di coesistere nello stesso set di dati / file. È considerato una cattiva pratica mescolare i tipi di geometria nella stessa tabella, anche per singoli / multipart dello stesso tipo di funzione e, per impostazione predefinita, i lettori open source nella toolchain cercheranno di proteggerti dal mescolare i tipi di geometria. Fortunatamente, però, ti offrono alcune opzioni. Inizialmente ho raccomandato di impostare l' argomento -nlt GEOMETRY
* sull'istruzione ogr2ogr, che ti ha permesso di importare il tuo set di dati poligonali nonostante la convenzione più libera di ESRI. Tuttavia, ciò significa che probabilmente hai geometrie sia a parte singola che a più parti nella tua tabella, e ciò potrebbe creare altri mal di testa per il tuo futuro!
Vale la pena ricordare che ogr2ogr ha un'altra -nlt
opzione da considerare, vale a dire PROMOTE_TO_MULTI
. Per citare la documentazione ..
A partire da GDAL 1.10, PROMOTE_TO_MULTI può essere utilizzato per promuovere automaticamente livelli che mescolano poligono o multipoligoni in multipoligoni e livelli che mescolano linestring o multilinestring in multilinestring. Può essere utile durante la conversione di shapefile in PostGIS e altri driver di destinazione che implementano controlli rigorosi per i tipi di geometria.
In altre parole, se si utilizza il PROMOTE_TO_MULTI
flag, TUTTE le funzioni verranno convertite in funzioni in più parti, anche quando sono costituite da una singola parte. Come notato da @LeeHachadoorian nei commenti - e sono sicuro che la maggior parte sarebbe d'accordo - ti consigliamo di preferire PROMOTE_TO_MULTI
la GEOMETRY
bandiera più sciolta , poiché è conforme alle migliori pratiche, unificando le geometrie delle caratteristiche nella tua tabella. Fondamentalmente, qualsiasi codice che scrivi dovrebbe aspettarsi solo geometrie multipart. Certo, questo può essere più pulito e semplificare parte dello sviluppo.
Consigli generici per qualcuno che ha problemi con l'importazione da SHP a POST
- Assicurati che i tuoi percorsi non contengano caratteri funky e che non ci siano errori di battitura o errori di ortografia nel percorso o nel nome file
- Come scoperto da @utente1919, assicurati che l'utente del tuo sistema operativo disponga di privilegi sufficienti per accedere allo shapefile! Come hanno dimostrato, può essere utile provare ad aprire lo shapefile in un altro software, come QGIS, se funziona in un software, non è corrotto e dovrebbe funzionare in altri software.
Innanzitutto, considera di eseguire il comando ogr2ogr sudo
per escludere i problemi di autorizzazione fino a quando non sai per certo che lo script funziona come previsto.
- Inoltre, come realizzato da @ user1919, assicurati che l'utente SQL disponga di privilegi sufficienti sia sul database targetizzato dallo script, sia sulla
spatial_ref_sys
tabella.
Ancora una volta, inizialmente, considera l'utilizzo del superutente PostGRESql qui per escludere problemi di privilegi SQL fino a quando lo script non funziona. Se lo script funziona con il superutente quindi non riesce con un utente di automazione preferito, sai che il problema è legato all'utente SQL e non ai tuoi dati o al tuo ambiente (installazione gdal / ogr, ecc.)
Prova a impostare la -nlt
bandiera su PROMOTE_TO_MULTI
o GEOMETRY
. Poiché gli shapefile consentono una convenzione di tipo di funzionalità più flessibile, a volte è necessario indicare alle utility open source di essere più accomodanti :)
Se stai importando a PostgreSQL o MySQL, provare a impostare -lco PRECISION=no
..fair avvertimento, non esattamente a capire che cosa questa tesi fa, ma ecco quello che ho vissuto .. Come sapete, gli shapefile includono spesso le SHAPE_LENGTH
e SHAPE_AREA
campi, ed io ho notato a volte quando si verificano errori misteriosi, se elimino quei campi posso ottenere l'importazione corretta dei dati. Tuttavia, se uso -lco PRECISION=no
, posso ottenere i dati da importare senza dover eliminare quei campi. La mia raccomandazione è di utilizzare questo parametro come passaggio per la risoluzione dei problemi, ma per capire quale problema sta veramente risolvendo prima di accettare l'importazione in una soluzione di produzione.
Infine, se si utilizza MySQL, tenere presente che alcune geometrie di funzionalità molto grandi potrebbero offendere il max_allowed_packet
parametro di MySQL . Puoi leggere ulteriori informazioni al riguardo nella documentazione per il driver MySQL. Ma la soluzione è quella di modificare la configurazione di MySQL per consentire un valore superiore a quello predefinito.
Esempio di comando di importazione da SHP a PostGIS per ogr2ogr
Per il bene di tutti i neofiti che possono vagare qui, questo è l'aspetto della maggior parte delle mie importazioni da SHP a Post usando ogr2ogr. Nota che racchiudo i percorsi / nomi dei file tra virgolette, questo protegge da spazi, caratteri strani e interruzioni di riga attraverso il terminale. Inoltre ho incluso la maggior parte degli argomenti discussi sopra, oltre alle sostituzioni per il campo del nome della geometria, il Campo FID e il nome del livello:
ogr2ogr -f "PostgreSQL" "PG:host=127.0.0.1 user=myuser dbname=mydb password=mypassw0rd" "C:/path/to/some_shapefile.shp" -lco GEOMETRY_NAME=the_geom -lco FID=gid -lco PRECISION=no -nlt PROMOTE_TO_MULTI -nln new_layername -overwrite