Perché QGIS non rileva CRS dal file .prj?


9

Ho un numero di griglie esagonali da 1 km che coprono varie contee degli Stati Uniti in un database postgreSQL / postGIS. Ogni griglia ha il CRS EPSG: 3857 e il livello delle contee ha EPSG: 3857. Quando si visualizzano le griglie con le contee in QGIS, tutto sembra grandioso.

Ma ... per condividere queste griglie con i colleghi, ho dovuto esportarle in shapefile usando ogr2ogr. Visualizzandoli in QGIS, ogni griglia sembra spostarsi di circa 20 km circa e QGIS imposta automaticamente il CRS su EPSG: 3395 (che non è il CRS del progetto).

Quando esporto le tabelle postGIS come shapefile da QGIS , il file .prj ha lo stesso aspetto dei file shape esportati da ogr2ogr , ma le tabelle esportate postGIS vengono visualizzate correttamente. Ho notato che QGIS crea un file .qpj durante l'esportazione di file di forma da QGIS , quindi sono giunto alla conclusione che QGIS sta ignorando il .prj e cerca invece un .qpj. Perché non riesce a leggere il .prj senza un .qpj? Altri shapefile (come quelli del censimento degli Stati Uniti) non hanno un .qpj ma QGIS li visualizza correttamente.

Ho trovato una soluzione alternativa salvando un default.qpj e creando un nuovo .qpj da questo per ogni file che esporta usando ogr2ogr, ma questo sembra disordinato e ovviamente non riproducibile in quanto funziona solo per EPSG: 3857.

Sidenote: sto usando QGIS 2.0.1.

MODIFICARE:

Ecco il comando ogr2ogr che ho usato:

ogr2ogr -f "ESRI Shapefile" /home/matt/data/hex_grid_1 PG:'dbname=mydb user=matt' hex_grid_1

Contenuti del .prj:

PROJCS [ "WGS_84_Pseudo_Mercator", GEOGCS [ "GCS_WGS_1984", DATUM [ "D_WGS_1984", SPHEROID [ "WGS_1984", 6378137,298.257223563]], PRIMEM [ "Greenwich", 0], unità [ "Degree", ,017453292519943295]], PROIEZIONE [ "Mercator"], PARAMETRO [ "central_meridian", 0], PARAMETRO [ "false_easting", 0], PARAMETRO [ "false_northing", 0], UNIT [ "Meter", 1], PARAMETRO [ "standard_parallel_1", 0,0] ]

Contenuto di .qpj:

PROJCS ["WGS 84 / Pseudo-Mercator", GEOGCS ["WGS 84", DATUM ["WGS_1984", SPHEROID ["WGS 84", 6378137,298.257223563, AUTHORITY ["EPSG", "7030"]], AUTHORITY [" EPSG", "6326"]], PRIMEM [ "Greenwich", 0, l'autorità [ "EPSG", "8901"]], unità [ "grado", ,0174532925199433, Autorità [ "EPSG", "9122"]], l'autorità [ "EPSG", "4326"]], PROIEZIONE [ "Mercator_1SP"], PARAMETRO [ "central_meridian", 0], PARAMETRO [ "scale_factor", 1], PARAMETRO [ "false_easting", 0], PARAMETRO [ "false_northing" , 0], UNIT [ "meter", 1, l'autorità [ "EPSG", "9001"]], AXIS [ "X", EST], AXIS [ "Y", NORD], ESTENSIONE [ "Proj4", "+ proj = merc + a = 6378137 + b = 6378137 + lat_ts = 0.0 + lon_0 = 0.0 + x_0 = 0.0 + y_0 = 0 + k = 1.0 + unità = m + nadgrids = @ null + wktext + no_defs "], AUTHORITY [" EPSG "," 3857 "]]

MODIFICA :

Il problema è stato risolto convertendo l'EPSG: 3857 in EPSG: 2163 in tutti i miei script. Non sono ancora sicuro di quale sia il problema, poiché le griglie sono state visualizzate correttamente in QGIS quando originariamente caricate da una tabella postgreSQL (con EPSG: 3857).

La mia soluzione alternativa si è rivelata rozza come pensavo, dato che il mio collega non è stato in grado di utilizzare il file in ArcGIS, che non ha letto correttamente il .prj o il .qpj.


Puoi aggiungere il comando ogr2ogr?
alphabetasoup

Puoi pubblicare anche i contenuti dei file .prj e .qpj?
mkennedy

1
Potrebbero esserci capacità limitate su quella "Proiezione del mercatore Web WGS84 su una sfera ausiliaria" en.wikipedia.org/wiki/Web_Mercator .. A differenza del mercatore ellissoidale e del mercatore sferico, il mercatore web non è del tutto conforme a causa del suo uso dell'ellissoide coordinate geografiche di riferimento rispetto a una proiezione sferica.
Huckfinn,

@huckfinn Ho cambiato tutti gli EPSG: 3857 in EPSG: 2163 nella mia sceneggiatura e il mio problema è ora risolto. Non sono ancora sicuro del perché, dato che tutte le griglie sono visualizzate correttamente quando caricate dalle tabelle postgreSQL con EPSG: 3857. Grazie per il consiglio.
haff

Risposte:


4

La EPSG:3857definizione è un trucco sporco per ottenere la proiezione che Google ha inventato nel moderno software GIS. È una combinazione di sfera ed ellissoide che non viene utilizzata dalle proiezioni "normali". Sfortunatamente, ogni software utilizza un altro modo per adattarlo.

QGIS utilizza il file .qpj, ARCGIS il WKT nel file .prj e GDAL la definizione proj.4. Il file .qpj incorpora la definizione di proj.4 nella definizione di WKT.

Il modo più sicuro per affrontare tali problemi è evitare Google Mercator. Puoi usare meglio il tuo aereo di stato locale, UTM o alcune proiezioni di Lambert o Albers in tutto il continente.


Buono a sapersi. Grazie per la tua risposta. Ho notato tuttavia che quando esporto un file di forma con EPSG 2163 utilizzando ogr2ogr, non viene creato alcun file .qpj, ma QGIS lo legge ancora correttamente. Quindi suppongo che QGIS leggerà le informazioni da un .prj in assenza di un .qpj. Inoltre, le proiezioni sul piano di stato funzioneranno alla grande se funzionano solo in uno stato, ma i miei script prendono codici fips di contea da molti stati, quindi un piano di stato non sarebbe pratico nel mio caso.
Haff

1
QGIS di solito funziona bene con il file .prj, ma non con i file proiettati da World Merctaor che provengono da altri software. Il CRS più adatto dipende sempre dalla dimensione dell'area di studio. EPSG 2163 dovrebbe andare bene per il tuo compito.
AndreJ,
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.