[PROJ] Bug in unit conversion using cs2cs and transformations from registries?

[Even Rouault]

Hi,

> I apologize if this problem is known or if I don't use the command cs2cs
> correctly. I have experimented a unit conversion problem when transforming
> coordinates from WGS84 geographic coordinate system to NTF geographic
> (Paris meridian) coordinate system using cs2cs.
> 
> Using cs2cs:
> ------------
> version 7.1.0
> - $ echo 43.97942110 5.77338693  0.0 | cs2cs EPSG:4326 IGNF:NTFP  -f %.8f
> Result: 3.43669113    43.97940959 0.00000000
> The right result (IGN code) is: 3.81854570 48.86601066
> Here the angle unit conversion is missing. Indeed:
> echo 3.43669113      43.97940959 | cct -d 10 +proj=unitconvert +xy_in=deg
> +xy_out=grad Result: 3.8185457000  48.8660106556           inf          
> inf

For a geographic CRS, cs2cs will always output (and expect input) geographic coordinates in 
decimal degrees, whatever the unit of the coordinate system. This is a legacy behaviour, from 
a time where CRS definitions in catalogs didn't include the unit.

> PS: using cs2cs in version 6.3.2, I have also faced coordinate order
> problem. But I guess it is a known result The cs2cs command does not
> recognize the coordinate order:
> - $ echo 43.97942110 5.77338693 0.0 | cs2cs +init=EPSG:4326 +to
> +init=IGNF:NTFP  -f %.8f Result: 41.64152849     5.77099039 0.00000000
> This is the wrong result. When putting the longitude first:

Yes, here this is another behaviour when using +init=EPSG:XXX or +init=IGNF:XXXX you use 
the legacy behaviour that wasn't compliant with the axis order of the authority, and assumed 
longitude, latitude for geographic CRS. When using EPSG:XXXX or IGNF:XXXX instead, the 
axis order is respected.

Perhaps for the EPSG:XXX or IGNF:XXXX syntax we should also use the unit of the coordinate 
systems instead of always degrees, but this mostly affects only those NTF based systems...

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20200804/e7a9ce38/attachment.html>