Forum QGIS

Pełna wersja: układy współrzędnych
Aktualnie przeglądasz uproszczoną wersję forum. Kliknij tutaj, by zobaczyć wersję z pełnym formatowaniem.
witam,
chciałbym się zapytać dlaczego w QGIS dla ukladu EPSG 31467 parametry różnią się od tych ze strony spatialreference.org (http://www.spatialreference.org/ref/epsg/31467/). Testując te dwa parametry (warstwa punktowa) na niewielkim obszarze miejskim różnica w położeniu punktów dochodzi do 4 m.
Które z odwzorowań jest więc właściwe?

QGIS - EPSG 31467
+proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +ellps=bessel +towgs84=582,105,414,1.04,0.35,-3.08,8.3 +units=m +no_defs

spatialreference.org - EPSG 31467
+proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +ellps=bessel +datum=potsdam +units=m +no_defs
P.S.
Ten sam problem występuje dla układu EPSG 3044
Poprawne są obydwa, tylko QGIS (i chyba większość programów korzystających z biblioteki PROJ.4) wymaga podania parametrów transformacji do WGS84. W drugim wariancie one są zastąpione nazwą datum, która QGISowi niewiele mówi. Dlatego rozbieżność może pochodzić stąd, że w drugim wypadku program nie przenosi współrzędnych z Bessela na docelową elipsoidę. Tak myślę, choć to obszerny temat i nie wszystkie tajniki standardu epsg i jego implementacji są mi znane Smile
witam,
mimo wszystko wciąż pozostaje problem, który z powyższych parametrów jest właściwy. Dane punktowe produkowane przez ArcGIS w układzie EPSG 31467 i dane obrobione przy użyciu parametrów spatialreference.org - EPSG 31467 pasują idealnie. Natomiast dane z parametrami użytymi w QGIS niestety nie pokrywają sie z reszta, i to już w niewielkiej skali.
Musiałbym znać więcej szczegółów, z czego produkowane w Arcu, w czym i w jaki sposób obrobione oraz po jakich działaniach się nie pokrywają. Żeby odrzucić ewentualne błędy pochodzące z wcześniejszej obróbki, najlepiej wziąć jeden punkt o znanych współrzędnych w WGS84 i jeśli po przetransformowaniu w Arcu i QGISie do 31467 będzie miał różne współrzędne, to ewidentnie jeden z nich popełnia tu błąd (albo obaj, bo definicje układów wbrew pozorom ciągle są poprawiane). Jeśli można ten punkt zlokalizować na "bezstronnej" i wiarygodnej mapie (np. papierowej) to idealnie. Jeśli nie, to można spróbować ręcznie policzyć właściwe współrzędne (o ile wzory są dostępne).

Na szybko sprawdziłem, że QGIS 1.9.90 z bibliotekami GDAL 1.9.0 i proj 4.7.0 punkt 0,0 (WGS) przelicza w 31467 jako:
y= -408,2277
x= 2494057,5847

Jeśli zamiast parametru +towgs84 dam +datum=potsdam, to wynik różni się o ok. 16 metrów:
y= -418,1747
x= 2494044,1897

Jeśli nie dam ani +towgs84, ani +datum, to przesunięcie jest kilkusetmetrowe, a zerowy y wskazuje, że w ogóle nie nastąpiło przeniesienie z elipsoidy WGS na Bessela (zero zostało zerem):
y= 0
x= 2494067,4758

Pocieszający jest fakt, że parametr +datum został uwzględniony. We wcześniejszym mailu błędnie napisałem, że QGIS go zignoruje, bo tak zdaje się było przy wcześniejszych wersjach, ale teraz straciłem pewność, bo bibliotekę proj.4 (która odpowiada za transformacje) mam dość starą. Jeśli jednak

Wygląda więc na to, że błędny jest jeden z parametrów +towgs84. Albo ten z biblioteki GDAL, którym posługuje się QGIS, albo ten zaszyty w bibliotece PROJ jako Poczdam. Temu drugiemu bym mniej ufał, tym bardziej, że różni się w wersji 4.7 i 4.8 biblioteki ( http://trac.osgeo.org/proj/ticket/115 ). Wersja QGISa jest stosunkowo najświeższa.

Krótko mówiąc: zapis na Spatialreference daje programowi swobodę interpretacji Poczdamu. QGIS użyje do tego biblioteki PROJ, która zachowa się różnie w wersji 4.7 i 4.8. Jak definicją posługuje się Arc, nie wiem. Natomiast te wymuszone na sztywno parametry towgs84 QGISa są zaczerpnięte z najświeższej wersji biblioteki GDAL (nawet, jeśli zainstalowana wersja GDAL jest starsza). Nie oznacza to oczywiście, że na 100% są dobre...

Niestety nie używałem tego układu i nie znam jego kruczków ani żadnych referencyjnych map zrobionych w nim, które dałoby się użyć do testu.