Чому QGIS не виявляє CRS з файлу .prj?

У мене є кількість шестикутних сіток на 1 км, які охоплюють різні округи в США у базі даних postgreSQL / postGIS. Кожна сітка має CRS EPSG: 3857, а у графствах графств EPSG: 3857. Під час перегляду сіток з графствами QGIS все виглядає чудово.

Але ... щоб поділитися цими сітками з колегами, мені довелося експортувати їх у формати файлів, використовуючи ogr2ogr. Переглядаючи їх у QGIS, кожна сітка виглядає затягнутою приблизно на 20 км або близько того, і QGIS автоматично встановлює CRS на EPSG: 3395 (що не є проектом CRS).

Коли я експортую таблиці postGIS у вигляді файлів з QGIS , файл .prj виглядає точно так само, як експортовані файли ogr2ogr , але експортовані таблиці postGIS відображаються правильно. Я помітив, що QGIS створює файл .qpj під час експорту форм-файлів з QGIS , тому я прийшов до висновку, що QGIS ігнорує .prj і шукає замість нього .qpj. Чому він не може прочитати .prj без .qpj? Інші файли форм (такі, як американський перепис населення) не мають .qpj, але QGIS відображає їх правильно.

Я придумав рішення, збереживши default.qpj і створивши з цього новий .qpj для кожного файлу, який експортує за допомогою ogr2ogr, але це здається безладним і, очевидно, не відтворюваним, оскільки він працює лише для EPSG: 3857.

Сторінка: Я використовую QGIS 2.0.1.

Редагувати:

Ось команда ogr2ogr, яку я використав:

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

Зміст .prj:

PROJCS [ "WGS_84_Pseudo_Mercator", GEOGCS [ "GCS_WGS_1984", DATUM [ "D_WGS_1984", сфероид [ "WGS_1984", 6378137,298.257223563]], PRIMEM [ "Грінвіч", 0], БЛОК [ "Ступінь", +0,017453292519943295]], ПРОЕКТУВАННЯ ["Mercator"], PARAMETER ["central_meridian", 0], PARAMETER ["false_easting", 0], PARAMETER ["false_northing", 0], UNIT ["Meter", 1], PARAMETER ["standard_parallel_1", 0.0] ]

Зміст .qpj:

PROJCS ["WGS 84 / Pseudo-Mercator", GEOGCS ["WGS 84", DATUM ["WGS_1984", SPHEROID ["WGS 84", 6378137,298.257223563, AUTHORITY ["EPSG", "7030"]], ВЛАДА [" EPSG "," 6326 "]], PRIMEM [" Greenwich ", 0, ORGORITY [" EPSG "," 8901 "]], UNIT [" ступінь ", 0.0174532925199433, ВЛАДА [" EPSG "," 9122 "]), ВЛАДА ["EPSG", "4326"]], ПРОЕКЦІЯ ["Mercator_1SP"], PARAMETER ["центральний_меріан", 0], PARAMETER ["scale_factor", 1], PARAMETER ["false_easting", 0], PARAMETER ["false_northing") , 0], UNIT ["метр", 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 + одиниці = m + надрешітки = @ null + wktext + no_defs "], АВТОРИТЕТ [" EPSG "," 3857 "]]

Редагувати :

Проблему було вирішено шляхом перетворення EPSG: 3857 у EPSG: 2163 у всіх моїх сценаріях. Я все ще не впевнений, у чому проблема, оскільки сітки відображаються правильно в QGIS, коли спочатку завантажувались з таблиці postgreSQL (з EPSG: 3857).

Моє вирішення виявилося грубим, як я вважав це, оскільки мій колега не зміг використати файл в ArcGIS, який неправильно прочитав .prj або .qpj.

EPSG:3857Визначення брудний хак , щоб отримати прогноз , що Google винайшов в сучасне програмне забезпечення ГІС. Це поєднання сфери і еліпсоїда, яке не використовується "нормальними" проекціями. На жаль, кожне програмне забезпечення використовує інший спосіб його адаптації.

QGIS використовує файл .qpj, ARCGIS WKT у файлі .prj і GDAL - визначення proj.4. Файл .qpj включає визначення proj.4 у визначення WKT.

Найбезпечніший спосіб вирішити подібні проблеми - це уникати Google Mercator. Ви можете краще використовувати свій місцевий державний літак, UTM або кілька проекцій Ламберта або Альберса на всій континенті.