[Proj] EPSG CS not supported, but the epsg file contains the correct definition
SAEZ Laurent - SG/SPSSI/CPII/DOM/ETER
Laurent.Saez at developpement-durable.gouv.fr
Fri Oct 8 10:53:54 PDT 2010
Thanks for your replies,
I know that "The difference between the WGS84 ellipsoid and the GRS80
ellipsoid is less than 0.001 meters". Even it is worst than that, the
difference is about 0.0001 meters !
But a maximum interoperable I have to offer my layers in a maximum CRS.
Frank, I have replace pcs.csv and gcs.csv with yours without success.
I have the same issue with Mayotte (EPSG:4471).
I think I have find what is going on... Axis order changes in WMS 1.3.0
acording to epsg specifications.
In WMS 1.1.1 axis order is X,Y (long,lat).
In WMS 1.3.0 axis order must follow the authority specifications. EPSG
follows ISO6709, so order is lat,long (Y,X).
It's so funny, isn't it !
But I don't understand why some requests works and some not with
MapServer 5.6.5.
WMS 1.1.1/GetMap requests work fine (but MapInfo® 8.5 requests WMS
1.3.0) with my new codes (EPSG:4559 and EPSG:4471) and axis order X,Y
(long,lat).
WMS 1.3.0/GetMap requests work fine with "old codes" like EPSG:32738
(WGS84 - UTM38S) and with wrong axis order (X,Y instead of Y,X)!
Example (image OK) :
http://mypath/mapserv
?VERSION=1.3.0
&REQUEST=GetMap
&LAYERS=fonds
&STYLES=
&CRS=EPSG:32738
&BBOX=513042.913690223,8595410.58010215,513509.488298022,8595664.36844427
&WIDTH=956
&HEIGHT=520
&FORMAT=image/jpeg
&BGCOLOR=0xFFFFFF
&EXCEPTIONS=XML
If I change axis order with EPSG32738, white image is rendered.
WMS 1.3.0/GetMap requests work fine only with "new codes" like EPSG:4471
(GRS80- UTM38S) AND with axis order Y,X (lat,long) !
Example (image OK) :
http://mypath/mapserv
?VERSION=1.3.0
&REQUEST=GetMap
&LAYERS=fonds
&STYLES=
&CRS=EPSG:4471
&BBOX=8595410.58010215,513042.913690223,8595664.36844427,513509.488298022
&WIDTH=956
&HEIGHT=520
&FORMAT=image/jpeg
&BGCOLOR=0xFFFFFF
&EXCEPTIONS=XML
THE QUESTION is : why MapServer understands differently WMS 1.3.0 GetMap
requests with old and new codes ?
It's strange but it is !
Thanks for all
Laurent
Le 07/10/2010 19:00, > proj-request at lists.maptools.org (par Internet,
dépôt proj-bounces at lists.maptools.org) a écrit :
> Send Proj mailing list submissions to
> proj at lists.maptools.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.maptools.org/mailman/listinfo/proj
> or, via email, send a message with subject or body 'help' to
> proj-request at lists.maptools.org
>
> You can reach the person managing the list at
> proj-owner at lists.maptools.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Proj digest..."
>
>
> Today's Topics:
>
> 1. EPSG CS not supported, but the epsg file contains the correct
> definition (SAEZ Laurent - SG/SPSSI/CPII/DOM/ETER)
> 2. Re: EPSG CS not supported, but the epsg file contains the
> correct definition (Clifford J Mugnier)
> 3. Re: EPSG CS not supported, but the epsg file contains the
> correct definition (Frank Warmerdam)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 07 Oct 2010 18:29:41 +0200
> From: "SAEZ Laurent - SG/SPSSI/CPII/DOM/ETER"
> <Laurent.Saez at developpement-durable.gouv.fr>
> Subject: [Proj] EPSG CS not supported, but the epsg file contains the
> correct definition
> To: proj at lists.maptools.org
> Message-ID: <4CADF575.6050401 at developpement-durable.gouv.fr>
> Content-Type: text/plain; charset=ISO-8859-15; format=flowed
>
> Hi all,
>
> I have to add support for new CRS in my mapfiles.
>
> New EPSG code, 4559 (Projected CRS for French Antilles - Guadeloupe and
> Martinique) replaces 2989.
> The ellipsoide is the only thing different (GRS80 instead of WGS84).
>
> So I add the EPSG:4559 definition in my epsg file.
> <4559> +proj=utm +zone=20 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
> +no_defs <>
>
> I use MapServer 5.6.5 with proj 4.7.0 (on Debian 64bits).
>
> When I call a GetMap using EPSG:4559 the image rendered is "wrong".
> EPSG:4559 and EPSG:2989 are almost identical and the images should be
> approximately similar.
> So, I test my EPSG code with testepsg.
>
> If I don't specify the epsg file location ('/opt/mapserver/bin/testepsg'
> EPSG:4559), I have :
> "ERROR 6: EPSG PCS/GCS code 4559 not found in EPSG support files. Is
> this a valid
> EPSG coordinate system?
> ERROR 1: Error occured translating EPSG:4559."
>
> If I specify the file location ('/opt/mapserver/bin/testepsg'
> '/opt/mapserver/share/proj/epsg' EPSG:4559) :
> "Validate Succeeds.
> WKT[/opt/mapserver/share/proj/epsg] =
> PROJCS["unnamed",
> GEOGCS["GRS 1980(IUGG, 1980)",
> DATUM["unknown",
> SPHEROID["GRS80",6378137,298.257222101],
> TOWGS84[0,0,0,0,0,0,0]],
> PRIMEM["paris",2.3372291666985],
> ...
> ...
> ...
> UNIT["Meter",1],
> PARAMETER["standard_parallel_1",46.8]]
> PROJ.4 rendering of [/opt/mapserver/share/proj/epsg] = +proj=lcc
> +lat_1=46.8 +lat_0=46.8 +lon_0=2.33722917 +k_0=0.99987742 +x_0=600000
> +y_0=2200000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +pm=2.3372291666985
> +units=m +no_defs
>
> ERROR 6: EPSG PCS/GCS code 4559 not found in EPSG support files. Is
> this a valid
> EPSG coordinate system?
> ERROR 1: Error occured translating EPSG:4559."
>
> I use to add EPSG codes in my mapfiles. It's the first time I have this
> problem.
>
> It seems that sometimes it is not sufficient to add a definition in the
> file EPSG...
> I have read this thread ("Unsupported SRS but available in epsg file") :
> http://www.mail-archive.com/gdal-dev@lists.osgeo.org/msg04926.html
>
> My GDAL_DATA environnement variable is well defined. I tried to add the
> definition in cubewerx_extra.wkt without success.
> Any idea ?
>
> I send this message on this list but I can't know what application is at
> issue: GDAL or PROJ?
>
> NB: I apologize for my bad English.
>
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 7 Oct 2010 11:32:44 -0500
> From: "Clifford J Mugnier" <cjmce at lsu.edu>
> Subject: Re: [Proj] EPSG CS not supported, but the epsg file contains
> the correct definition
> To: "PROJ.4 and general Projections Discussions"
> <proj at lists.maptools.org>
> Message-ID:
> <B597ADFC46B67741B18EA6AA13613FF7026A6555 at email002.lsu.edu>
> Content-Type: text/plain; charset="iso-8859-1"
>
> The difference between the WGS84 ellipsoid and the GRS80 ellipsoid is less than 0.001 meters, and that is only for the semi-minor axis (b). Consider them identical for all practical purposes.
>
> Clifford J. Mugnier, C.P., C.M.S.
> Chief of Geodesy,
> Center for GeoInformatics
> Department of Civil Engineering
> Patrick F. Taylor Hall 3223A
> LOUISIANA STATE UNIVERSITY
> Baton Rouge, LA 70803
> Voice and Facsimile: (225) 578-8536 [Academic]
> Voice and Facsimile: (225) 578-4578 [Research]
> Cell: (225) 238-8975 [Academic & Research]
> Honorary Life Member of the
> Louisiana Society of Professional Surveyors
> Fellow Emeritus of the ASPRS
> Member of the Americas Petroleum Survey Group
>
>
> ________________________________
>
> From: proj-bounces at lists.maptools.org on behalf of SAEZ Laurent - SG/SPSSI/CPII/DOM/ETER
> Sent: Thu 07-Oct-10 11:29
> To: proj at lists.maptools.org
> Subject: [Proj] EPSG CS not supported,but the epsg file contains the correct definition
>
>
>
> Hi all,
>
> I have to add support for new CRS in my mapfiles.
>
> New EPSG code, 4559 (Projected CRS for French Antilles - Guadeloupe and
> Martinique) replaces 2989.
> The ellipsoide is the only thing different (GRS80 instead of WGS84).
>
> So I add the EPSG:4559 definition in my epsg file.
> <4559> +proj=utm +zone=20 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
> +no_defs <>
>
> I use MapServer 5.6.5 with proj 4.7.0 (on Debian 64bits).
>
> When I call a GetMap using EPSG:4559 the image rendered is "wrong".
> EPSG:4559 and EPSG:2989 are almost identical and the images should be
> approximately similar.
> So, I test my EPSG code with testepsg.
>
> If I don't specify the epsg file location ('/opt/mapserver/bin/testepsg'
> EPSG:4559), I have :
> "ERROR 6: EPSG PCS/GCS code 4559 not found in EPSG support files. Is
> this a valid
> EPSG coordinate system?
> ERROR 1: Error occured translating EPSG:4559."
>
> If I specify the file location ('/opt/mapserver/bin/testepsg'
> '/opt/mapserver/share/proj/epsg' EPSG:4559) :
> "Validate Succeeds.
> WKT[/opt/mapserver/share/proj/epsg] =
> PROJCS["unnamed",
> GEOGCS["GRS 1980(IUGG, 1980)",
> DATUM["unknown",
> SPHEROID["GRS80",6378137,298.257222101],
> TOWGS84[0,0,0,0,0,0,0]],
> PRIMEM["paris",2.3372291666985],
> ...
> ...
> ...
> UNIT["Meter",1],
> PARAMETER["standard_parallel_1",46.8]]
> PROJ.4 rendering of [/opt/mapserver/share/proj/epsg] = +proj=lcc
> +lat_1=46.8 +lat_0=46.8 +lon_0=2.33722917 +k_0=0.99987742 +x_0=600000
> +y_0=2200000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +pm=2.3372291666985
> +units=m +no_defs
>
> ERROR 6: EPSG PCS/GCS code 4559 not found in EPSG support files. Is
> this a valid
> EPSG coordinate system?
> ERROR 1: Error occured translating EPSG:4559."
>
> I use to add EPSG codes in my mapfiles. It's the first time I have this
> problem.
>
> It seems that sometimes it is not sufficient to add a definition in the
> file EPSG...
> I have read this thread ("Unsupported SRS but available in epsg file") :
> http://www.mail-archive.com/gdal-dev@lists.osgeo.org/msg04926.html
>
> My GDAL_DATA environnement variable is well defined. I tried to add the
> definition in cubewerx_extra.wkt without success.
> Any idea ?
>
> I send this message on this list but I can't know what application is at
> issue: GDAL or PROJ?
>
> NB: I apologize for my bad English.
>
>
>
>
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.maptools.org/pipermail/proj/attachments/20101007/dcdc60e1/attachment-0001.htm
>
> ------------------------------
>
> Message: 3
> Date: Thu, 07 Oct 2010 12:49:51 -0400
> From: Frank Warmerdam <warmerdam at pobox.com>
> Subject: Re: [Proj] EPSG CS not supported, but the epsg file contains
> the correct definition
> To: "PROJ.4 and general Projections Discussions"
> <proj at lists.maptools.org>
> Message-ID: <4CADFA2F.6060302 at pobox.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> SAEZ Laurent - SG/SPSSI/CPII/DOM/ETER wrote:
>
>> When I call a GetMap using EPSG:4559 the image rendered is "wrong".
>> EPSG:4559 and EPSG:2989 are almost identical and the images should be
>> approximately similar.
>> So, I test my EPSG code with testepsg.
>>
>> If I don't specify the epsg file location ('/opt/mapserver/bin/testepsg'
>> EPSG:4559), I have :
>> "ERROR 6: EPSG PCS/GCS code 4559 not found in EPSG support files. Is
>> this a valid
>> EPSG coordinate system?
>>
>
> Laurent,
>
> PROJ.4 looks up epsg definitions from the epsg init file.
>
> GDAL normally looks them up in the gcs.csv and pcs.csv files
> though it does have fallback logic to look in the PROJ.4 epsg
> init file. So the error you see is "testepsg" (from GDAL) not
> finding the coordinate system in the pcs.csv file and not able
> to find the epsg init file because it is in an usual place.
>
>
>> It seems that sometimes it is not sufficient to add a definition in the
>> file EPSG...
>> I have read this thread ("Unsupported SRS but available in epsg file") :
>> http://www.mail-archive.com/gdal-dev@lists.osgeo.org/msg04926.html
>>
>> My GDAL_DATA environnement variable is well defined. I tried to add the
>> definition in cubewerx_extra.wkt without success.
>> Any idea ?
>>
>> I send this message on this list but I can't know what application is at
>> issue: GDAL or PROJ?
>>
>
> At the start you mentioned that the GetMap result is wrong. How wrong is it?
> Just off by a bit or things in completely unrelated places or missing?
>
> Mostly MapServer uses the PROJ.4 epsg init file, so I'm surprised your
> change didn't work. There are a few places that might actually ask
> GDAL/OGR for the definition in which case it would be important either
> for GDAL/OGR to also be able to find the epsg init file, or for you to
> add the definitions to pcs.csv and gcs.csv which might be messy. I'm
> not sure what is going wrong.
>
> To give you the option, the pcs.csv and gcs.csv definitions are:
>
> pcs.csv
> 4559,"RRAF 1991 / UTM zone
> 20N",9001,4558,16020,9807,1,0,4400,8801,0,9102,8802,-63,9102,8805,0.9996,9201,8806,500000,9001,8807,0,9001,,,,,,
>
> gcs.csv
> 4558,RRAF 1991,1047,Reseau de Reference des Antilles Francaises
> 1991,1047,9122,7019,8901,1,0,6422,4560,0,9603,0,0,0,,,,
>
> the latest gcs.csv and pcs.csv files from GDAL trunk have these
> and should be safe to superinpose on older versions of GDAL.
>
> http://svn.osgeo.org/gdal/trunk/gdal/data
>
> Best regards,
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20101008/6eaf5cc2/attachment.html>
More information about the Proj
mailing list