У меня есть ряд гексагональных сеток длиной 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.
Sidenote: я использую 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]], ПРОЕКТИРОВАНИЕ [ "Меркатора"], параметр [ "central_meridian", 0], параметр [ "false_easting", 0], параметр [ "false_northing", 0], блок [ "Измеритель", 1], параметр [ "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"]], AUTHORITY [" EPSG», "6326"]], PRIMEM [ "Гринвич", 0, ДНУ [ "EPSG", "8901"]], БЛОКА [ "степень", +0,0174532925199433, ДНУ [ "EPSG", "9122"]], АВТОРИТЕТ [ "EPSG", "4326"]], ПРОЕЦИРОВАНИЯ [ "Mercator_1SP"], параметр [ "central_meridian", 0], параметр [ "scale_factor", 1], параметр [ "false_easting", 0], параметр [ "false_northing" , 0], блок [ "метр", 1, ДНУ [ "EPSG", "9001"]], AXIS [ "Х", ИСТ], AXIS [ "Y" СЕВЕР], РАСШИРЕНИЕ [ "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 "]]
РЕДАКТИРОВАТЬ :
Проблема была решена путем преобразования 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 или проекции Ламберта или Альберса по всему континенту.
источник