Pourquoi QGIS ne détecte-t-il pas CRS à partir du fichier .prj?

J'ai un certain nombre de grilles hexagonales de 1 km qui couvrent divers comtés aux États-Unis dans une base de données postgreSQL / postGIS. Chaque grille a le CRS EPSG: 3857, et la couche comtés a EPSG: 3857. Lorsque vous affichez les grilles avec les comtés dans QGIS, tout semble superbe.

Mais ... afin de partager ces grilles avec des collègues, j'ai dû les exporter vers des fichiers de formes à l'aide d'ogr2ogr. En les visualisant dans QGIS, chaque grille semble décalée d'environ 20 km environ, et QGIS définit automatiquement le CRS sur EPSG: 3395 (qui n'est pas le projet CRS).

Lorsque j'exporte les tables postGIS en tant que fichiers de formes à partir de QGIS , le fichier .prj ressemble exactement aux fichiers de formes exportés par ogr2ogr , mais les tables exportées postGIS s'affichent correctement. J'ai remarqué que QGIS crée un fichier .qpj lors de l'exportation de fichiers de formes à partir de QGIS , donc je suis arrivé à la conclusion que QGIS ignore le .prj et recherche un .qpj à la place. Pourquoi ne peut-il pas lire le .prj sans .qpj? D'autres fichiers de formes (tels que ceux du recensement américain) n'ont pas de .qpj mais QGIS les affiche correctement.

J'ai trouvé une solution de contournement en enregistrant un fichier default.qpj et en créant un nouveau .qpj à partir de cela pour chaque fichier exporté à l'aide d'ogr2ogr, mais cela semble compliqué et évidemment pas reproductible car cela ne fonctionne que pour EPSG: 3857.

Sidenote: J'utilise QGIS 2.0.1.

ÉDITER:

Voici la commande ogr2ogr que j'ai utilisée:

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

Contenu du .prj:

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

Contenu du .qpj:

PROJETS ["WGS 84 / Pseudo-Mercator", GEOGCS ["WGS 84", DATUM ["WGS_1984", SPHEROID ["WGS 84", 6378137, 298.257223563, AUTORITÉ ["EPSG", "7030"]], AUTORITÉ [" EPSG "," 6326 "]], PRIMEM [" Greenwich ", 0, AUTORITÉ [" EPSG "," 8901 "]], UNITÉ [" degré ", 0,0174532925199433, AUTORITÉ [" EPSG "," 9122 "]], AUTORITÉ ["EPSG", "4326"]], PROJECTION ["Mercator_1SP"], PARAMETER ["central_meridian", 0], PARAMETER ["scale_factor", 1], PARAMETER ["false_easting", 0], PARAMETER ["false_northing" , 0], UNITÉ ["mètre", 1, AUTORITÉ ["EPSG", "9001"]], AXE ["X", EST], AXE ["Y", NORD], 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 + unités = m + nadgrids = @ null + wktext + no_defs "], AUTORITÉ [" EPSG "," 3857 "]]

MODIFIER :

Le problème a été résolu en convertissant les EPSG: 3857 en EPSG: 2163 dans tous mes scripts. Je ne sais toujours pas quel est le problème, car les grilles s'affichent correctement dans QGIS lors du chargement initial à partir d'une table postgreSQL (avec EPSG: 3857).

Ma solution de contournement s'est avérée grossière comme je le pensais, car mon collègue n'a pas pu utiliser le fichier dans ArcGIS, qui n'a pas lu correctement le .prj ou le .qpj.

— haff
source

Pouvez-vous ajouter la commande ogr2ogr?

— alphabetasoup

Pouvez-vous également publier le contenu des fichiers .prj et .qpj?

— mkennedy

Peut être il y a des capacités limitées sur ce « WGS84 Web Mercator Projection sur une sphère auxiliaire » en.wikipedia.org/wiki/Web_Mercator ..Unlike la ellipsoïdale Mercator et Mercator sphérique, le Mercator Web est pas tout à fait conforme en raison de son utilisation de ellipsoïdale coordonnées géographiques de référence contre une projection sphérique.

— huckfinn

@huckfinn J'ai changé tous les EPSG: 3857 en EPSG: 2163 dans mon script et mon problème est maintenant résolu. Je ne sais toujours pas pourquoi c'est parce que les grilles s'affichent toutes correctement lorsqu'elles sont chargées à partir des tables postgreSQL avec EPSG: 3857. Merci pour le conseil.

— haff

La EPSG:3857définition est un hack sale pour obtenir la projection que Google a inventée dans un logiciel SIG moderne. C'est une combinaison de sphère et d'ellipsoïde qui n'est pas utilisée par les projections "normales". Malheureusement, chaque logiciel utilise une autre façon de l'adapter.

QGIS utilise le fichier .qpj, ARCGIS le WKT dans le fichier .prj et GDAL la définition proj.4. Le fichier .qpj incorpore la définition proj.4 dans la définition WKT.

Le moyen le plus sûr de résoudre ces problèmes est d'éviter Google Mercator. Vous pouvez mieux utiliser votre plan d'État local, UTM ou certaines projections continentales de Lambert ou Albers.

— AndreJ
source

Bon à savoir. Merci pour votre réponse. J'ai cependant remarqué que lorsque j'exporte un fichier de forme avec EPSG 2163 à l'aide d'ogr2ogr, aucun .qpj n'est créé, mais QGIS le lit toujours correctement. Je suppose donc que QGIS lira les informations d'un .prj en l'absence d'un .qpj. De plus, les projections de plans d'État fonctionneront très bien si elles ne fonctionnent que dans un seul État, mais mes scripts prennent les codes fips de comté de nombreux États, donc un plan d'État ne serait pas pratique dans mon cas.

— haff

QGIS fonctionne généralement bien avec le fichier .prj, mais pas avec les fichiers projetés de World Merctaor provenant d'autres logiciels. Le SRC le mieux adapté dépend toujours de la taille de la zone d'étude. EPSG 2163 devrait convenir à votre tâche.

— AndreJ