Warum erkennt QGIS CRS nicht aus der PRJ-Datei?

Ich habe eine Anzahl von 1 km großen sechseckigen Gittern, die verschiedene Grafschaften in den Vereinigten Staaten in einer postgreSQL / postGIS-Datenbank abdecken. Jedes Gitter hat das CRS-EPSG: 3857 und die Grafschaftsschicht hat das EPSG: 3857. Wenn Sie die Raster mit den Landkreisen in QGIS anzeigen, sieht alles großartig aus.

Aber ... um diese Gitter mit Kollegen zu teilen, musste ich sie mit ogr2ogr in Shapefiles exportieren. Wenn Sie diese in QGIS anzeigen, sieht jedes Raster etwa 20 km nach oben verschoben aus, und QGIS setzt das CRS automatisch auf EPSG: 3395 (was nicht das Projekt-CRS ist).

Wenn ich die postGIS - Daten - Tabellen als Shape - Dateien exportieren von QGIS , die .prj - Datei sieht genau die gleichen wie die ogr2ogr exportiert Shape - Dateien , aber die postGIS - Daten exportierten Tabellen werden korrekt angezeigt. Ich habe festgestellt, dass QGIS beim Exportieren von Shapefiles aus QGIS eine .qpj-Datei erstellt. Daher bin ich zu dem Schluss gekommen, dass QGIS die .prj-Datei ignoriert und stattdessen nach einer .qpj-Datei sucht. Warum kann es die .prj nicht ohne .qpj lesen? Andere Shapefiles (wie die aus der US-Volkszählung) haben keine .qpj, aber QGIS zeigt diese korrekt an.

Ich habe eine Problemumgehung gefunden, indem ich eine default.qpj gespeichert und daraus eine neue .qpj für jede Datei erstellt habe, die mit ogr2ogr exportiert wird. Dies scheint jedoch chaotisch und offensichtlich nicht reproduzierbar zu sein, da es nur für EPSG: 3857 funktioniert.

Nebenbemerkung: Ich verwende QGIS 2.0.1.

BEARBEITEN:

Hier ist der Befehl ogr2ogr, den ich verwendet habe:

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

Inhalt der .prj:

PROJCS ["WGS_84_Pseudo_Mercator", GEOGCS ["GCS_WGS_1984", DATUM ["D_WGS_1984", SPHEROID ["WGS_1984", 6378137,298.257223563]], PRIMEM ["Greenwich", 0], UNIT ["Mercator"], PARAMETER ["central_meridian", 0], PARAMETER ["false_easting", 0], PARAMETER ["false_northing", 0], UNIT ["Meter", 1], PARAMETER ["standard_parallel_1", 0.0] ]]

Inhalt der .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, AUTHORITY [" EPSG "," 8901 "]], UNIT [" Degree ", 0.0174532925199433, AUTHORITY [" EPSG "," 9122 "], AUTHORITY ["EPSG", "4326"]], PROJECTION ["Mercator_1SP"], PARAMETER ["central_meridian", 0], PARAMETER ["scale_factor", 1], PARAMETER ["false_easting", 0], PARAMETER ["false_northing" , 0], UNIT ["meter", 1, AUTHORITY ["EPSG", "9001"]], AXIS ["X", EAST], AXIS ["Y", NORTH], EXTENSION ["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 + Einheiten = m + Nadgrids = @ null + wktext + no_defs "], AUTHORITY [" EPSG "," 3857 "]]

EDIT :

Das Problem wurde gelöst, indem die EPSG: 3857 in allen meinen Skripten in EPSG: 2163 konvertiert wurden. Ich bin mir immer noch nicht sicher, wo das Problem liegt, da die Gitter in QGIS korrekt angezeigt wurden, als sie ursprünglich aus einer postgreSQL-Tabelle geladen wurden (mit EPSG: 3857).

Meine Problemumgehung erwies sich als grob, da ich dachte, dass dies der Fall war, da mein Kollege die Datei in ArcGIS nicht verwenden konnte, da die .prj- oder die .qpj-Datei nicht richtig gelesen wurde.

— haff
quelle

Können Sie den Befehl ogr2ogr hinzufügen?

— Alphabetasoup

Können Sie auch den Inhalt der .prj- und .qpj-Dateien veröffentlichen?

— Mkennedy

Da sein kann begrenzt Fähigkeiten auf dieser „WGS84 Web Mercator - Projektion auf einer Auxiliary Sphere“ sind en.wikipedia.org/wiki/Web_Mercator ..Unlike die Ellipsoid - Mercator und sphärische Mercator, ist die Web Mercator nicht ganz konform aufgrund seiner Verwendung von elliptischen datumsgeografische Koordinaten gegen eine sphärische Projektion.

— Huckfinn

@huckfinn Ich habe alle EPSG: 3857 in EPSG: 2163 in meinem Skript geändert und mein Problem ist jetzt gelöst. Ich bin mir immer noch nicht sicher, warum dies so ist, da die Gitter beim Laden aus den postgreSQL-Tabellen mit EPSG: 3857 alle korrekt angezeigt werden. Danke für den Tipp.

— Haff

Die EPSG:3857Definition ist ein schmutziger Hack, um die von Google erfundene Projektion in moderne GIS-Software zu bekommen. Es ist eine Kombination aus Kugel und Ellipsoid, die von "normalen" Projektionen nicht verwendet wird. Leider verwendet jede Software eine andere Methode, um sie anzupassen.

QGIS verwendet die .qpj-Datei, ARCGIS die WKT in der .prj-Datei und GDAL die proj.4-Definition. Die .qpj-Datei enthält die proj.4-Definition in der WKT-Definition.

Der sicherste Weg, um mit solchen Problemen umzugehen, besteht darin, Google Mercator zu vermeiden. Sie können besser Ihr lokales State Plane, UTM oder einige kontinentweite Lambert- oder Albers-Projektionen verwenden.

— AndreJ
quelle

Gut zu wissen. Danke für deine Antwort. Ich habe jedoch festgestellt, dass beim Exportieren einer Formdatei mit EPSG 2163 mit ogr2ogr keine .qpj erstellt wird, QGIS sie jedoch weiterhin ordnungsgemäß liest. Ich gehe also davon aus, dass QGIS Informationen von einem .prj liest, wenn kein .qpj vorhanden ist. Projektionen von Staatsebenen funktionieren auch hervorragend, wenn sie nur in einem Staat ausgeführt werden, aber meine Skripte verwenden County-Fips-Codes aus vielen Staaten, sodass eine Staatsebene in meinem Fall nicht praktikabel wäre.

— Haff

QGIS funktioniert normalerweise einwandfrei mit der PRJ-Datei, jedoch nicht mit World Merctaor-Projektionsdateien, die von anderer Software stammen. Das am besten geeignete CRS hängt immer von der Größe des Untersuchungsgebiets ab. EPSG 2163 sollte für Ihre Aufgabe in Ordnung sein.

— AndreJ