[mapserver-users] Coordinates shifted for EPSG:28992

[Jeff McKenna]

Hi Just,

Since you're offering, please also try:

- MapServer 7.6.1, GDAL 2.4.4, PROJ 5.2.0 (be careful with PROJ 5.0.0 as 
there was a major issue with the Google Mercator, which is fixed for the 
5.2.0 release).  This is the stable architecture that MS4W/Windows users 
seem to be very happy with (sometimes user-demand is very different than 
my bleeding-edge FOSS4G-style ha).

- MapServer-master, GDAL-master, PROJ-master, Curl-7.72.0, SQLite 3.33.0 
(for bleeding edge go for it all ha, and let us know the results)

Thanks for testing! :)

-jeff


-- 
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/



On 2020-09-17 4:20 p.m., Just van den Broecke wrote:
> 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
>>
> 
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-users