Dlaczego QGIS nie wykrywa CRS z pliku .prj?

9

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.

haff
źródło
Czy możesz dodać polecenie ogr2ogr?
alphabetasoup
Czy możesz również opublikować zawartość plików .prj i .qpj?
mkennedy
1
Mogą istnieć ograniczone możliwości tego „WGS84 Web Mercator Projection on Auxiliary Sphere” en.wikipedia.org/wiki/Web_Mercator .. W przeciwieństwie do elipsoidalnego Mercatora i sferycznego Mercatora, Web Mercator nie jest całkiem zgodny ze względu na użycie elipsoidalne współrzędne geograficzne układu odniesienia względem rzutu sferycznego.
huckfinn
@huckfinn W swoim skrypcie zmieniłem wszystkie EPSG: 3857 na EPSG: 2163 i mój problem został już rozwiązany. Nadal nie jestem pewien, dlaczego tak się dzieje, ponieważ wszystkie siatki są wyświetlane poprawnie po załadowaniu z tabel postgreSQL z EPSG: 3857. Dzięki za wskazówkę.
haff

Odpowiedzi:

4

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.

AndreJ
źródło
Dobrze wiedzieć. Dzięki za odpowiedź. Zauważyłem jednak, że kiedy eksportuję plik kształtu za pomocą EPSG 2163 przy użyciu ogr2ogr, nie ma utworzonego pliku .qpj, ale QGIS nadal go poprawnie odczytuje. Więc zakładam, że QGIS będzie czytać informacje z .prj przy braku .qpj. Również projekcje płaszczyzny stanu będą działały świetnie, jeśli działają tylko w jednym stanie, ale moje skrypty pobierają kody hrabstw z wielu stanów, więc w moim przypadku płaszczyzna stanu nie byłaby praktyczna.
haff 10.03.16
1
QGIS zwykle działa dobrze z plikiem .prj, ale nie z plikami rzutowanymi World Merctaor, które pochodzą z innego oprogramowania. Najlepiej dopasowany CRS zawsze zależy od wielkości obszaru badań. EPSG 2163 powinien być odpowiedni do twojego zadania.
AndreJ