Dlaczego QGIS nie wykrywa CRS z pliku .prj?

Mam szereg heksagonalnych siatek o długości 1 km, które obejmują różne hrabstwa w Stanach Zjednoczonych w bazie danych postgreSQL / postGIS. Każda siatka ma CRS EPSG: 3857, a warstwa powiatu ma EPSG: 3857. Podczas przeglądania siatek z okręgami w QGIS wszystko wygląda świetnie.

Ale ... aby udostępnić te siatki kolegom, musiałem je wyeksportować do plików kształtów za pomocą ogr2ogr. Przeglądając je w QGIS, każda siatka wygląda na przesuniętą o około 20 km, a QGIS automatycznie ustawia CRS na EPSG: 3395 (co nie jest projektem CRS).

Kiedy eksportuję tabele postGIS jako pliki shapefile z QGIS , plik .prj wygląda dokładnie tak samo jak eksportowane pliki shapefile ogr2ogr , ale tabele eksportowane postGIS są wyświetlane poprawnie. Zauważyłem, że QGIS tworzy plik .qpj podczas eksportowania plików kształtów z QGIS , więc doszedłem do wniosku, że QGIS ignoruje .prj i zamiast tego szuka .qpj. Dlaczego nie może odczytać pliku .prj bez pliku .qpj? Inne pliki kształtów (np. Z amerykańskiego spisu powszechnego) nie mają pliku .qpj, ale QGIS wyświetla je poprawnie.

Wymyśliłem obejście, zapisując plik default.qpj i tworząc z niego nowy plik .qpj dla każdego pliku eksportowanego za pomocą ogr2ogr, ale wydaje się to niechlujne i oczywiście nie do odtworzenia, ponieważ działa tylko dla EPSG: 3857.

Sidenote: Używam QGIS 2.0.1.

EDYTOWAĆ:

Oto polecenie ogr2ogr, którego użyłem:

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

Zawartość pliku .prj:

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

Zawartość pliku .qpj:

PROJCS [„WGS 84 / Pseudo-Mercator”, GEOGCS [„WGS 84”, DATUM [„WGS_1984”, SPHEROID [„WGS 84”, 6378137,298.257223563, AUTORYTET [„EPSG”, „7030”]], ORGAN [” EPSG ”,„ 6326 ”]], PRIMEM [„ Greenwich ”, 0, AUTORYTET [„ EPSG ”,„ 8901 ”]], UNIT [„ stopień ”, 0,0174532925199433, AUTORYTET [„ EPSG ”,„ 9122 ”]], ORGAN [„EPSG”, „4326”]], PROJEKCJA [„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 + jednostki = m + nadgrids = @ null + wktext + no_defs "], AUTHORITY [" EPSG "," 3857 "]]

EDYCJA :

Problem został rozwiązany przez konwersję EPSG: 3857 na EPSG: 2163 we wszystkich moich skryptach. Nadal nie jestem pewien, na czym polega problem, ponieważ siatki wyświetlane poprawnie w QGIS, gdy zostały pierwotnie załadowane z tabeli postgreSQL (z EPSG: 3857).

Moje obejście okazało się prymitywne, tak jak myślałem, ponieważ mój kolega nie mógł użyć pliku w ArcGIS, który nie odczytał poprawnie plików .prj lub .qpj.

EPSG:3857Definicja jest zabrudzony hack, aby uzyskać projekcję że Google wynalazł do nowoczesnego oprogramowania GIS. Jest to połączenie kuli i elipsoidy, które nie jest używane w „normalnych” projekcjach. Niestety, każde oprogramowanie wykorzystuje inny sposób dostosowania.

QGIS używa pliku .qpj, ARCGIS WKT w pliku .prj, a GDAL definicję proj.4. Plik .qpj zawiera definicję proj.4 w definicji WKT.

Najbezpieczniejszym sposobem radzenia sobie z takimi problemami jest unikanie Google Mercator. Możesz lepiej wykorzystać swój lokalny samolot stanowy, UTM lub niektóre kontynentalne projekcje Lambert lub Albers.