[PROJ] [EXTERNAL] Re: package 'geosphere' -- transforming spherical-based geographic coordinates to WGS84

Wed Apr 22 12:08:40 PDT 2020

22 April 2020

Hi Even,

First, a belated thank you for your clear explanation last week, basically informing me that: Since my "+proj=longlat +ellps=sphere +no_defs" string did not contain any datum "qualifier", PROJ didn't attempt to do any change of coordinate.

Your explanation raised a lot of discussion and debate among myself and colleagues regarding 2 map projections that we commonly use in our science.

Both projections have EPSG codes (3408 and 3411):
_____________________________________________________

3408 # NSIDC EASE-Grid North
+proj=laea +lat_0=90 +lon_0=0 +x_0=0 +y_0=0 +a=6371228 +b=6371228 +units=m +no_defs

3411 # NSIDC Sea Ice Polar Stereographic North
+proj=stere +lat_0=90 +lat_ts=70 +lon_0=-45 +k=1 +x_0=0 +y_0=0 +a=6378273 +b=6356889.449 +units=m +no_defs
_____________________________________________________

One projection (3408) is on a sphere, the other (3411) on an ellipsoid, and both EPSG definitions have "+no_defs" --- i.e., neither contains a datum "qualifier".

Question:  While Program R will transform coordinates from either of these 2 EPSG map projections to the other, is it correct to do so in the absence of "datum qualifier"?
Akin to the "+towgs84=0,0,0," parameter, is a different +toXYZ=a,b,c, required to correctly transform between these map projections?

Thank you, and please forgive my naivety.

David

________________________________
From: Even Rouault <even.rouault at spatialys.com>
Sent: Friday, April 17, 2020 11:45
To: proj at lists.osgeo.org <proj at lists.osgeo.org>
Cc: Douglas, David C <ddouglas at usgs.gov>; Fischbach, Anthony S <afischbach at usgs.gov>; r.hijmans at gmail.com <r.hijmans at gmail.com>
Subject: [EXTERNAL] Re: [PROJ] package 'geosphere' -- transforming spherical-based geographic coordinates to WGS84

Douglas,

> Can someone show me what I'm doing wrong, or misunderstanding?

Your "+proj=longlat +ellps=sphere +no_defs" string doesn't contain any datum "qualifier", so PROJ doesn't attempt to do any change of coordinate. This is a behaviour that has existed since PROJ 4.6 if I remember well, and that has been kept during PROJ 6 overhaul.

If you add +towgs84=0,0,0, you will see a change in latitude values.

$ echo "2 49" | cs2cs +proj=longlat +ellps=sphere +to +init=epsg:4326

2dE 49dN 0.000

$ echo "2 49" | src/cs2cs +proj=longlat +ellps=sphere +towgs84=0,0,0 +to +init=epsg:4326

2dE 49d11'25.117"N 0.000

The details of the transformations can also be shown with PROJ >= 6 with:

$ projinfo -s "+proj=longlat +ellps=sphere +type=crs" -t EPSG:4326 -o PROJ

Candidate operations found: 1

-------------------------------------

Operation No. 1:

unknown id, Ballpark geographic offset from unknown to WGS 84, unknown accuracy, World, has ballpark transformation

PROJ string:

+proj=axisswap +order=2,1

vs

$ projinfo -s "+proj=longlat +ellps=sphere +towgs84=0,0,0 +type=crs" -t EPSG:4326 -o PROJ

Candidate operations found: 1

-------------------------------------

Operation No. 1:

unknown id, Transformation from unknown to WGS84, unknown accuracy, unknown domain of validity

PROJ string:

+proj=pipeline +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=push +v_3 +step +proj=cart +ellps=sphere +step +inv +proj=cart +ellps=WGS84 +step +proj=pop +v_3 +step +proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1

Even

--

Spatialys - Geospatial professional services

http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20200422/6d1cac48/attachment.html>