[Proj] PROJ 4.6.0 beta1 Release

[Frank Warmerdam]

support.mn at elisanet.fi wrote:
>> Now, if pj_datum_transform() (called pj_transform()) is called, and
>> either of the coordinate system lacks datum information it will apply no
>> datum shift at all.  The lat/long coordinates will be taken from one
>> and applied on the other with alteration.
> 
> Do I now interprete this correctly so, that if there is now datum given, 
> the datum will be floating? Taking the datum of any other datum that it 
 > is compared to?

Janne,

Loosely speaking, yes, you are interpreting it correctly.

If either coordinate system passed to pj_transform() lacks a datum
definition then it will be assumed that it's datum effectively
matches the other.

> What happens with the spherical projections? Robinson and similar?

The same.

Though the other aspect that I did was to decouple the the datum/ellipsoid
logic for datum shifting from the ellipsoid parameters used for internal
projection calculations.

In the past "cs2cs +proj=robin +datum=WGS84 +to +proj=latlong +datum=WGS84"
would result in the robinson's ellipsoid getting changed from WGS84 to
a sphere because robinson is a spherical only projection.  And then
pj_datum_transform() would try to convert from the sphere to the ellipsoid.

Now, the code distinguishes between the ellipsoid that was declared by the
user for a coordinate system (ie. WGS84 above) and the ellipsoid that gets
used internally for projection calculation purposes.  The datum logic only
looks at the declared ellipsoid now, not the internal one used for
calculations.  This is accomplished by stashing the original "a" and "es"
parameters in the new fields "a_orig" and "es_orig" and using these values
strategically.

So, you could now do something like:

   cs2cs +proj=robin +datum=WGS84 +to +proj=utm +zone=11 +datum=NAD27

and internally PROJ would reproject the robinson coordinates using a sphere,
but then it would do the WGS84 to NAD27 datum shift before projecting into
UTM 11.  That is, if you do declare a non-spherical ellipsoid (via a
+datum declaration) for a projection it won't be "messed up" by the internal
use of a sphere.

Actually, a better demonstration of the above would be:

   cs2cs +proj=robin +datum=GGRS87 +to +proj=latlong +datum=WGS84

The important distinction is that GGRS87 expands to
"+towgs84=-199.87,74.79,246.62 +ellps=GRS80".  The towgs84
shift is applied in geocentric space, but it is very important
which ellipsoid is used to get to geocentric space.  In the "old"
approach the sphere used for robinson would have been used for
the conversion to geocentric.  Now, GRS80 would be used for the
calculation avoiding a huge unexpected sphere related shift in latitude.

> If I take coordinates from Robinson projection and apply them to "tmerc"
> and the "tmerc" has datum defined, but the "robin" not. This should then
> yield zero shift?

There would be no datum shift, right.  So now:

  cs2cs +proj=robin +ellps=sphere +to +proj=utm +zone=11 +datum=WGS84

would be equivelent to:

  invproj +proj=robin +ellps=sphere | proj +proj=utm +zone=11 +ellps=WGS84

> How about if they have both defined datums and ellipses and they are
> exactly the same? Will there be a shift or not?

There will be no datum shift applied, even if one of the projections
is spherical and than converts the ellipse internally to a sphere.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org