[Dutch] epsg:28992 in QGIS

[b.j.kobben op utwente.nl]

He Richard,


Even snel reactie vanuit thuis (met zonder naslagwerken):

De 3e datumtransformatie
  
+towgs84=565.2369,50.0087,465.658,-0.406857330322398,0.350732676542563,-1.8
703473836068,4.0812
is volgens mij de meest accurate, die heb ik ook in mijn Proj4
hulpbestanden staan (die ik oa voor ArcGIS, PostGIS en zo nog wat meer
gebruik), en die ik denk ik uit de officiele papieren heb gehaald (het NCG
boekje over ETRS89, RD en NAP en hun onderlinge relatie).

Ik zie trouwens niet de keuze in datumshifts die je beschrijft (gebruik
QGIS 2.0.1 op MacOSX). Ik begrijp ook niet waar die vandaan komt,
aangezien normaliter als je de proj4text gebruikt, die al aangeeft wat de
datumshift naar WGS84 is (de +towgs84 string).

Ik heb ooit met QGIS 1.8 wat tests gedaan met de daarin uitgevoerde
omzetting van RD naar WGS84, en die was prima, zie bijvoorbeeld
bijgevoegde screendump waar de nauwkeurigheid van AGRS refstation
Apeldoorn zo'n 4,5cm is. Dus als je nog kan achterhalen hoe het in 1.8
ging (geen keuze van transforms) en dat kan herhalen, zit je wel goed...

Let wel: omzetten naar 3857, de roemruchte "google mercator" zou wel weer
aanvullende onnauwkeurigheden kunnen introduceren, aangezien deze
'Mercator-op-een-bol" mathematisch twijfelachtig is (zie bv
http://www.iter.dk/post/2008/05/SphericalWeb-Mercator-EPSG-code-3785.aspx).
 Maar dan hebben we het toch op zijn slechts om enkele tientallen meters
afwijkingen op onze breedte (maar misschien wel honderden meters als je
noordelijker komt).

Wellicht dat ik in de kerstavakantie ineens inspiratie krijg om eea in een
blog te zetten, maar reken nergens op;-)

groetjes,
Barend



On 14-12-13 15:49, "Richard Duivenvoorde" <rdmailings at duif.net> wrote:

>Hi Barend of andere crs-guru's,
>
>in testing/master van de huidige testing/master QGIS wordt, als je
>vanuit epsg:28992 iets transformeert naar bijvoorbeeld epsg:3857,
>gevraagd welke datum je wilt gebruiken daarvoor.
>Zie deze screenshot:
>
>http://www.flickr.com/photos/97361298@N07/11367487623/
>
>(om te zien: laad een nl shape (wordt dan epsg:28992 project), en voeg
>dan Google-streets laag toe met OpenLayers plugin (wordt dan een
>epgs:3857 project))
>
>volgens mij komen die datums uit de srs.db, die weer gegegenereerd wordt
>uit de officiele epgs-mdb.
>
>Als ik epsg:28992 opzoek in QGIS, en de proj string bekijk:
>
>+proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889
>+k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel
>+towgs84=565.417,50.3319,465.552,-0.398957,0.343988,-1.8774,4.0725
>+units=m +no_defs
>
>lijkt het alsof QGIS standaard de derde datum uit de screenshot gebruikt:
>
>565.417,50.3319,465.552,-0.398957,0.343988,-1.8774,4.0725
>
>'Vroeger' moest je zelf een proj string aanmaken, zie bv
>
>http://www.qgis.nl/2011/12/05/epsg28992-of-rijksdriehoekstelsel-verschuivi
>ng/
>
>daar gebruikte ik:
>
>+proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889
>+k=0.999908 +x_0=155000 +y_0=463000 +ellps=bessel +units=m
>+towgs84=565.2369,50.0087,465.658,-0.406857330322398,0.350732676542563,-1.
>8703473836068,4.0812
>+no_defs no_defs
>
>weer andere waarden....
>
>Vragen:
>
>1) is het ok, als ik die derde datum gebruik en 'm door QGiS laat
>'herinneren'.
>2) wat is het probleem van evt de verkeerde gekozen te hebben?
>
>Nog mooier zou het zijn als iemand die hier een helder verhaaltje over
>zou kunnen schrijven dit eens bv zou doen in een blogpost op bv qgis.nl
>(reply even naar mij voor een inlog)
>
>Vr Groet,
>
>Richard Duivenvoorde
>
>ps ik ben me bewust van het werk van ... om een correctiegrid te kunnen
>gebruiken in proj. Maar even los daarvan.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Difference in QGIS.png
Type: image/png
Size: 113099 bytes
Desc: Difference in QGIS.png
URL: <http://lists.osgeo.org/pipermail/dutch/attachments/20131214/f031e672/attachment-0001.png>