[mapserver-users] Coordinates shifted for EPSG:28992

[Just van den Broecke]

Hi Evan,

Thanks for your quick reply! Will try out other combinations of proj and 
MS with custom compiles and let you know here.

I did not quite grasp your last paragraph, but I am no expert in the 
subject. For The Netherlands the expert is Lennard Huisman, formerly 
from Dutch Kadaster. IMHO he donated to proj the most accurate 
transformation with an NTV2 grid for the "real" Dutch coordinate system 
(another EPSG code), which was set out by hand via triangulation. 
Started at the time we were ruled by Napoleon. The Dutch "Kadaster" 
(word derived from French) was then established. So we are thankful in 
return to the French! EPSG:28992 is an approximation for that coord 
system but ok for cm-accuracy. "Amersfoort" is the "center" for The 
Netherlands, think where the triangulation was set out from. For 
EPSG:28992 the x,y 0,0 is still near Paris! Reason, I understood, was 
not to confuse surveyors' hand-written measurements as always y > x 
would prevail.

Best,

Just


On 17-09-20 19:46, Even Rouault wrote:
> Hi Just,
> 
>  > On Ubuntu 20.4 with Proj Rel. 6.3.1, February 10th, 2020 and MapServer
> 
>  > 7.4.3 with Proj, the transformation from EPSG:4326 to EPSG:28992 is
> 
>  > shifted.
> 
>  >
> 
>  > Findings:
> 
>  > - projinfo for EPSG:28992 shows correct proj-string
> 
>  > - cs2cs gives correct results
> 
>  > - when adding the proj-def explicitly to each layer: correct results
> 
>  > - did not occur on older MS+proj.4-versions on Ubuntu 16.
> 
>  >
> 
>  > Looks like a Datum shift problem, shift is around 80m NE, but towgs84 is
> 
>  > in the proj-string from projinfo.
> 
>  >
> 
>  > The proj string is:
> 
>  > <28992> +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 <>
> 
>  >
> 
> Complicated subject, but basically you should try to stick to one of the 
> following combinations:
> 
> - With MapServer 7.4 or 7.6: GDAL 2.x + PROJ 5.x
> 
> - With MapServer >= 7.6: GDAL 3.x + PROJ >= 6.x
> 
> Any other combination will lead to surprising results as you got, 
> although I'm not completely sure why you get yours if projinfo 
> EPSG:28992 includes the +towgs84 string. Well actually, checking the 
> output of projinfo EPSG:28992 with PROJ 6 or 7, it 
> uses+towgs84=565.2369,50.0087,465.658,-0.406857330322398,0.350732676542563,-1.8703473836068,4.0812
> 
> which comes from "Amersfoort to WGS 84 (3)", whereas your above towgs84 
> comes from "Amersfoort to WGS 84 (4)". But from a quick test the 
> difference between both is on the order of 1 cm, not 80m. So it looks 
> more like you don't get any datum shift at all.
> 
> I'd note that with a change I've just queue in
> 
> https://github.com/OSGeo/PROJ/pull/2357 for PROJ 7.2, EPSG:28992 as a 
> PROJ.4 string will no longer include any +towgs84 term, as there are 
> actually 2 candidate transformations EPSG:15934 "Amersfoort to WGS 84 
> (3)" and EPSG:4833 "Amersfoort to WGS 84 (4)", and as they have the same 
> extent and accuracy, a "random" one could be used in theory...
> 
> "Amersfoort to WGS 84 (4)" mentions "Replaces Amersfoort to WGS 84 (3)" 
> in comments, but it is not marked explictly as superseding it, hence 
> PROJ presents both...
> 
> Because I love Dutch people, I've added a change in my pull request so 
> that "Amersfoort to WGS 84 (4)" is now prefered over "Amersfoort to WGS 
> 84 (3)", when presenting results by order of relevance...
> 
> Gosh, I'm confident we'll still have such datum related issues until I'm 
> retired :-)
> 
> Even
> 
> -- 
> 
> Spatialys - Geospatial professional services
> 
> http://www.spatialys.com
>