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@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/mapserver-users
_______________________________________________
mapserver-users mailing list
mapserver-users@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/mapserver-users
