[mapserver-users] MapServer calculates wrong WGS84BoundingBox for WCS request using EPSG:28992

Wed May 14 06:43:45 PDT 2014

Hello,
I found some time for further investigations... ;-)

MapServer is definitely using the correct epsg file. If I comment out the 28992 line it fails and if I change the the first basic parameters different BBOX values are appearing for WGSBoundingBox.
However, if I do changes to the towgs parameters or even delete them completly this seemed to be ignored to calculate the WGSBoundingBox in the DescribeCoverage response.
Is there any forward or reverse projection ongoing in the background which is leaving out this parameters?

cheers,
Christian

------------------------------------------------------------
Christian Braun
R+D Engineer
Environmental Modelling, Geocomputation

Tel: +352- 425991-6608
Mobil: +49-179-6845896
Mail: christian.braun at tudor.lu

Resource Centre for Environmental Technologies,
Public Research Centre Henri Tudor,
6A, avenue des Hauts-Fourneaux,
L-4362 Esch-sur-Alzette, Luxembourg

On 14 May 2014, at 11:32, Rahkonen Jukka (Tike) <jukka.rahkonen at mmmtike.fi> wrote:

> Hi,
>  
> Two quick things to try:
> - turn on PROJ_DEBUG http://www.mapserver.org/optimization/debugging.html#step-4-turn-on-proj-debug-optional
> - edit your epsg file and make some changes to the two first parameters of the +towgs84. That should make your map data to slide in S-N and W-E direction once data are reprojected. If this happens you know for sure that the PROJ library that is used is the one you believe.
>  
> If correct PROJ is in use I would then check if there is also errors in the data. Take a sample of data into another projection from WCS and check it. It can be that the error is only in the WGS84 bounding box calculation.
>  
> -Jukka Rahkonen-
>  
> Christian Braun
>  
> Hello,
> ok, maybe I was not clear enough in my description.
> There were several changes in the past to EPSG:28992. The first change was to add some towgs parameters, which you could find in my map file, later there was a revision to the ones you are showing in your definition. Between this two towgs flags there isn't much difference or almost no difference in a final map. But if you leave out the flags at all, you will get errors in your spatial position of a few hundred meters.
>  
> No matter what I set in the epsg file or in the map file as projection parameter of the source data set, MapServer is calculating in the DescribeCoverage an extent that matches very close the values that would have been given back by the old erroneous epsg (the one without towgs flags) definition. You can check that with the online calculator tool quite easily if you try to convert the bounding boxes.
>  
> For me it seems that the projection parameters are read from somewhere else in the system where an old definition is present...
>  
> cheers,
> Christian
>  
> BTW: setting wcs_extent didn't help...
>  
>  
>  
> ------------------------------------------------------------
> Christian Braun
> R+D Engineer
> Environmental Modelling, Geocomputation
>  
> Tel: +352- 425991-6608
> Mobil: +49-179-6845896
> Mail: christian.braun at tudor.lu
> 
> Resource Centre for Environmental Technologies,
> Public Research Centre Henri Tudor,
> 6A, avenue des Hauts-Fourneaux,
> L-4362 Esch-sur-Alzette, Luxembourg
>  
> On 14 May 2014, at 10:49, Rahkonen Jukka (Tike) <jukka.rahkonen at mmmtike.fi> wrote:
> 
> 
> Hi,
>  
> Both my MS4W with Mapserver 6.3-dev and 6.4 on Linux use these definitions
> # Amersfoort / RD New
> <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  <>
>  
> You say that they wrong and +towgs84 parameters in your mapfile are correct? If so, then you can update the values into your epsg file that is in your PROJ_LIB directory. We seem to have PROJ-4.8.0 on Linux.
>  
> I have seen with WMS that supports many projections that extent calculations for different projections are not always reliable. It is more reliable if layer extents are given in the layer metadata. Add “wcs_extent” metadata as shown in http://www.mapserver.org/ogc/wcs_server.html and try if that changes anything.
>  
> -Jukka Rahkonen-
>  
>  
> Christian Braun wrote:
>  
> Dear list members,
> 
> I just discovered that my MapServer installation is calculating a wrong WGS84BoundingBox tag.
> 
> I know that were issues in the past with the definition of EPSG:28992 in which my data is stored. I was checking all epsg files on the system and als set the config flag for PROJ_LIB in the map file. But it seems that MapServer is still ignoring the correct settings for EPSG:28992 and takes the "old" definition without proper proj towgs flags.
> 
> The services are public and you can find below the links [1] to a DescribeCoverage for the WCS I am refering to. ro_dsm_mini is a small layer which I am using for testing. BBOX in 28992 is the correct one of the data source, the corresponding WGS84BoundingBox which is giving back is wrong.
> I am using http://cs2cs.mygeodata.eu for checking.
> 
> I also paste the relevant part of the map file [2].
> 
> 
> Any further help is appreciated.
> Many thanks in advance,
> Christian
> 
> 
> [1]
> http://maps.iguess.tudor.lu/cgi-bin/mapserv?map=/srv/mapserv/MapFiles/RO_localOWS_test.map&SERVICE=WCS&VERSION=1.1.0&REQUEST=DescribeCoverage&COVERAGEID=ro_dsm_mini
> 
> 
> [2]
> MAP
>   NAME "TUDOR_RO_test-environment"
>   EXTENT 65956 431299 93267 451459
>   SIZE 800 600
>   MAXSIZE 50000
>   UNITS METERS
>   SHAPEPATH "/srv/sampleData/"
>   IMAGECOLOR 255 255 255
> 
>   PROJECTION
>     #"+proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +towgs84=565.237,50.0087,465.658,-0.406857,0.350733,-1.87035,4.0812 +units=m +no_defs"
>     "init=epsg:28992"
>   END
> 
>   CONFIG PROJ_LIB "/usr/share/proj/"
>  
>   LAYER # -----------------------------------------------------------------
>     NAME "ro_dsm_mini"
>     TYPE RASTER
>     STATUS ON
>     DATA "ro_dsm_mini.tiff"
>     
>     #PROCESSING "SCALE=AUTO"
>     
>     PROJECTION
>       "+proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +towgs84=565.237,50.0087,465.658,-0.406857,0.350733,-1.87035,4.0812 +units=m +no_defs"  # the projection of the source data set
>       #"init=epsg:28992"
>     END
> 
>     METADATA
>       "ows_title" "DSM subset"
>       "ows_abstract" "This a test data set of Rotterdams DSM subset"
> 
>       "wms_include_items" "value_0"
>       "wms_value_0_alias" "Height"
> 
>       "wcs_label"           "ro_dsm_mini"  ### required
>       "wcs_rangeset_name"   "Range 1"  ### required to support DescribeCoverage request
>       "wcs_rangeset_label"  "My Label" ### required to support DescribeCoverage request
>       "wcs_formats" "img"
>     END
>  
>  
> ------------------------------------------------------------
> Christian Braun
> R+D Engineer
> Environmental Modelling, Geocomputation
>  
> Tel: +352- 425991-6608
> Mobil: +49-179-6845896
> Mail: christian.braun at tudor.lu
> 
> Resource Centre for Environmental Technologies,
> Public Research Centre Henri Tudor,
> 6A, avenue des Hauts-Fourneaux,
> L-4362 Esch-sur-Alzette, Luxembourg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20140514/f8621a19/attachment.htm>