PROJ 4.6.0 beta1 Release

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

PROJ 4.6.0 beta1 Release

Frank Warmerdam
Folks,

There have been many complaints from folks about pj_datum_transform()
doing "ellipse to ellipse" datum shifts when no datum shift information
is available.  I have come to the, belated, conclusion that the idea will
ill conceived on my part, and I have reversed my approach.

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.

Datum shift information can be specified two ways, a +towgs84 parameter,
or a +nadgrids parameter.  The +datum parameter is basically for named
aliases that expand to +ellps and either +nadgrids or +towgs84 parameters.

This is a major behavior change, and I'd appreciate folks giving some feedback
on the change.  I have prepared a first beta release with this change,
designated 4.6.0 beta1.

This release also includes an upgrade to EPSG 6.14 and a few other relatively
minor bug fixes.

   http://download.osgeo.org/proj/proj-4.6.0b1.tar.gz
   http://download.osgeo.org/proj/proj-4.6.0b1.zip

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

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: PROJ 4.6.0 beta1 Release

Brent Fraser
Frank,

  Sounds like a good idea, but will the API return a code,
or through some other mechanism, indicate that a datum
transformation has not occured?  The application could then
alert the user...

Brent Fraser
GeoAnalytic Inc.
Calgary, Alberta
----- Original Message -----
From: "Frank Warmerdam" <[hidden email]>
To: "PROJ.4 and general Projections Discussions"
<[hidden email]>
Sent: Thursday, November 29, 2007 2:44 PM
Subject: [Proj] PROJ 4.6.0 beta1 Release


> Folks,
>
> There have been many complaints from folks about
pj_datum_transform()
> doing "ellipse to ellipse" datum shifts when no datum
shift information
> is available.  I have come to the, belated, conclusion
that the idea will
> ill conceived on my part, and I have reversed my approach.
>
> 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.
>
> Datum shift information can be specified two ways, a
+towgs84 parameter,
> or a +nadgrids parameter.  The +datum parameter is
basically for named
> aliases that expand to +ellps and either +nadgrids or
+towgs84 parameters.
>
> This is a major behavior change, and I'd appreciate folks
giving some feedback
> on the change.  I have prepared a first beta release with
this change,
> designated 4.6.0 beta1.
>
> This release also includes an upgrade to EPSG 6.14 and a
few other relatively
> minor bug fixes.
>
>    http://download.osgeo.org/proj/proj-4.6.0b1.tar.gz
>    http://download.osgeo.org/proj/proj-4.6.0b1.zip
>
> Best regards,
> --
> ---------------------------------------+------------------
--------------------
> I set the clouds in motion - turn up   | Frank Warmerdam,
[hidden email]
> light and sound - activate the windows |
http://pobox.com/~warmerdam
> and watch the world go round - Rush    | President OSGeo,
http://osgeo.org
>
> _______________________________________________
> Proj mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/proj

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: PROJ 4.6.0 beta1 Release

Frank Warmerdam
Brent Fraser wrote:
> Frank,
>
>   Sounds like a good idea, but will the API return a code,
> or through some other mechanism, indicate that a datum
> transformation has not occured?  The application could then
> alert the user...

Brent,

No, there is no error code of any sort returned.  The intent is
treat the behavior as intentional, not a failure.

There are other failure modes for pj_transform() which will result
in appropriate error information being returned.

It does sometimes disturb me that the transformation sequence is quite
opaque to the application.  There is no real way for it to know what is
happening.

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

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: PROJ 4.6.0 beta1 Release

Greg Troxel
In reply to this post by Frank Warmerdam
  http://download.osgeo.org/proj/proj-4.6.0b1.tar.gz

I built this on NetBSD within the pkgsrc framework (I am the maintainer)
without any issues, and "gmake check" succeeded.

Does this herald a shift in offical distribution site and homepage, or
was this just a convenient place to put the beta tarball?

  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.

I think this is a sensible change, although I certainly can see that it
might surprise someone.
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: PROJ 4.6.0 beta1 Release

Frank Warmerdam
Greg Troxel wrote:
>   http://download.osgeo.org/proj/proj-4.6.0b1.tar.gz
>
> I built this on NetBSD within the pkgsrc framework (I am the maintainer)
> without any issues, and "gmake check" succeeded.
>
> Does this herald a shift in offical distribution site and homepage, or
> was this just a convenient place to put the beta tarball?

Greg,

This is actually the same as ftp://ftp.remotesensing.org/proj.  They
are both served from the same tree.  I just quoted the http "osgeo"
address since the ftp.remotesensing.org address is mostly preserved
for backward compatability.

>   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.
>
> I think this is a sensible change, although I certainly can see that it
> might surprise someone.

Right.  I think it is important to highlight the change in behavior to
the extent practical so people won't be completely blindsided.

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

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: PROJ 4.6.0 beta1 Release

support.mn
In reply to this post by Frank Warmerdam
> 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?

What happens with the spherical projections? Robinson and similar?

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?

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

Regards Janne.

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

AW: PROJ 4.6.0 beta1 Release

Uwe Schmitz-2
In reply to this post by Frank Warmerdam
Frank,

I tested the new version and it seems to me that
grid shifts are ignored now.

E.g. the example from ticket 1531 "Grid shifts give wrong results"
brings now back exactly the input coordinate without
doing any shift.

Regards
Uwe
---------------------------------------------------------
... Uwe Schmitz  Landesvermessungsamt Nordrhein-Westfalen
... Muffendorfer Str. 19 - 21              D - 53177 Bonn
... E-mail:       [hidden email]
... Internet:     http://www.lverma.nrw.de

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: PROJ 4.6.0 beta1 Release

Frank Warmerdam
In reply to this post by support.mn
[hidden email] 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, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: AW: PROJ 4.6.0 beta1 Release

Frank Warmerdam
In reply to this post by Uwe Schmitz-2
[hidden email] wrote:
> Frank,
>
> I tested the new version and it seems to me that
> grid shifts are ignored now.
>
> E.g. the example from ticket 1531 "Grid shifts give wrong results"
> brings now back exactly the input coordinate without
> doing any shift.

Uwe,

I just tried a NAD27 -> NAD83 grid shift like this and it seemed to
be doing something:

warmerda@amd64[73]% cs2cs +proj=utm +zone=11 +datum=NAD27 +to +proj=utm
+zone=11 +datum=NAD83
300000 4000000
300004.77       4000200.77 0.00

Could you be more specific about what you did, and also verify you have
the correct grids findable?  Setting the PROJ_DEBUG environment variable
set to a non-empty value can help determine if grid shift files are
successfully found.

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

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: AW: PROJ 4.6.0 beta1 Release

Frank Warmerdam
Frank Warmerdam wrote:

> [hidden email] wrote:
>> Frank,
>>
>> I tested the new version and it seems to me that grid shifts are
>> ignored now.
>>
>> E.g. the example from ticket 1531 "Grid shifts give wrong results"
>> brings now back exactly the input coordinate without
>> doing any shift.
>
> Uwe,
>
> I just tried a NAD27 -> NAD83 grid shift like this and it seemed to
> be doing something:
>
> warmerda@amd64[73]% cs2cs +proj=utm +zone=11 +datum=NAD27 +to +proj=utm
> +zone=11 +datum=NAD83
> 300000 4000000
> 300004.77       4000200.77 0.00
>
> Could you be more specific about what you did, and also verify you have
> the correct grids findable?  Setting the PROJ_DEBUG environment variable
> set to a non-empty value can help determine if grid shift files are
> successfully found.

Uwe,

Following up on my own message. When I set PROJ_DEBUG I discovered it wasn't
actually finding a grid file, and for that matter I was running the version
the older version of PROJ that I had installed, not my build version!

However, after pointing PROJ_LIB at my actual grid shift files things do
seem to be working:

cs2cs +proj=utm +zone=11 +datum=NAD27 +to +proj=utm +zone=11 +datum=NAD83

pj_open_lib(proj_def.dat): call
fopen(/home/warmerda/bld/share/proj/proj_def.dat) - succeeded
pj_open_lib(proj_def.dat): call
fopen(/home/warmerda/bld/share/proj/proj_def.dat) - succeeded
300000 4000000
pj_open_lib(conus): call fopen(/home/warmerda/bld/share/proj/conus) - succeeded
Ctable Conterminous United States 273x121: LL=(-131,20) UR=(-63,50)
pj_open_lib(alaska): call fopen(/home/warmerda/bld/share/proj/alaska) - succeeded
Ctable Alaska 529x249: LL=(-194,46) UR=(-128,77)
pj_open_lib(ntv2_0.gsb): call fopen(/home/warmerda/bld/share/proj/ntv2_0.gsb) -
failed
pj_open_lib(ntv1_can.dat): call
fopen(/home/warmerda/bld/share/proj/ntv1_can.dat) - succeeded
NTv1 393x177: LL=(-142,40) UR=(-44,84)
pj_open_lib(conus): call fopen(/home/warmerda/bld/share/proj/conus) - succeeded
pj_apply_gridshift(): used Conterminous United States
299919.76       4000197.43 0.00


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

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

AW: PROJ 4.6.0 beta1 Release

Uwe Schmitz-2
In reply to this post by Frank Warmerdam
Frank,

I am using the example from ticket 1531 with a local
(may be this is the problem?) grid file (attached
to the ticket).

The shell script:
export PROJ_DEBUG=1
cs2cs \
      -f "%.12f" \
      +proj=latlong \
      +ellps=bessel \
      +nadgrids=./tstgrid.gsb \
   +to \
      +proj=latlong \
      +ellps=GRS80 \
      <<EOF
7.483333333333E 53.500000000000N
EOF

Output with old version 4.5.0:
pj_open_lib(proj_def.dat): call fopen(/usegiap/schmitz/ent/giapinst/share/proj/proj_def.dat) - succeeded
pj_open_lib(proj_def.dat): call fopen(/usegiap/schmitz/ent/giapinst/share/proj/proj_def.dat) - succeeded
pj_open_lib(./tstgrid.gsb): call fopen(./tstgrid.gsb) - succeeded
NTv2 DHDN90   2x3: LL=(7.33333333,53.4) UR=(7.5,53.6)
NTv2 - loading grid DHDN90  
pj_open_lib(./tstgrid.gsb): call fopen(./tstgrid.gsb) - succeeded
pj_apply_gridshift(): used DHDN90  
7.482506019176 53.498461144236 0.000067942776

And with 4.6.0b1 installed in the same place:
pj_open_lib(proj_def.dat): call fopen(/usegiap/schmitz/ent/giapinst/share/proj/proj_def.dat) - succeeded
pj_open_lib(proj_def.dat): call fopen(/usegiap/schmitz/ent/giapinst/share/proj/proj_def.dat) - succeeded
7.483333333333 53.500000000000 0.000000000000

It seems, that the grid file is ignored.
May be this isn't related directly to your changes?

Regards,
Uwe
---------------------------------------------------------
... Uwe Schmitz  Landesvermessungsamt Nordrhein-Westfalen
... Muffendorfer Str. 19 - 21              D - 53177 Bonn
... E-mail:       [hidden email]
... Internet:     http://www.lverma.nrw.de


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: AW: PROJ 4.6.0 beta1 Release

Frank Warmerdam
[hidden email] wrote:

> Frank,
>
> I am using the example from ticket 1531 with a local
> (may be this is the problem?) grid file (attached
> to the ticket).
>
> The shell script:
> export PROJ_DEBUG=1
> cs2cs \
>       -f "%.12f" \
>       +proj=latlong \
>       +ellps=bessel \
>       +nadgrids=./tstgrid.gsb \
>    +to \
>       +proj=latlong \
>       +ellps=GRS80 \
>       <<EOF
> 7.483333333333E 53.500000000000N
> EOF

Uwe,

But in this case the output coordinate system only has an ellipse, and
no datum definition, so pj_transform() deliberately makes no attempt to
do a datum shift.  This is exactly the sort of case in which the behavior
is intended to change.

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

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

AW: PROJ 4.6.0 beta1 Release

Uwe Schmitz-2
In reply to this post by Frank Warmerdam
Frank,

> [hidden email] wrote:
> > Frank,
> >
> > I am using the example from ticket 1531 with a local
> > (may be this is the problem?) grid file (attached
> > to the ticket).
> >
> > The shell script:
> > export PROJ_DEBUG=1
> > cs2cs \
> >       -f "%.12f" \
> >       +proj=latlong \
> >       +ellps=bessel \
> >       +nadgrids=./tstgrid.gsb \
> >    +to \
> >       +proj=latlong \
> >       +ellps=GRS80 \
> >       <<EOF
> > 7.483333333333E 53.500000000000N
> > EOF
>
> Uwe,
>
> But in this case the output coordinate system only has an ellipse, and
> no datum definition, so pj_transform() deliberately makes no
> attempt to
> do a datum shift.  This is exactly the sort of case in which
> the behavior
> is intended to change.
>

oh yes, my fault! It shows me that I didn't really understand
what I'm doing with PROJ.4 :-)

OK, if I add "+datum=WGS84" to the "+to" part I get the same
result as with V4.5.0 (still wrong in respect of ticket 1531).
Despite that, isn't it true that the grid file contains
datum definition for both (from and to) system? So isn't
it better to assume datum definition for both systems, if
a grid is specified? What also confuses is that the destination
datum isn't really WGS84 in this case, but the slightly
different ETRS89.

Anyhow, I think the change breaks backward compatibility and this
has to be documented very well. All of my old scripts have to
be patched to give the right results.

Another question: When an how do these changes affect GDAL/OGR?

Thanks in advance and best regards
Uwe
---------------------------------------------------------
... Uwe Schmitz  Landesvermessungsamt Nordrhein-Westfalen
... Muffendorfer Str. 19 - 21              D - 53177 Bonn
... E-mail:       [hidden email]
... Internet:     http://www.lverma.nrw.de


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: AW: PROJ 4.6.0 beta1 Release

Frank Warmerdam
[hidden email] wrote:
> oh yes, my fault! It shows me that I didn't really understand
> what I'm doing with PROJ.4 :-)
>
> OK, if I add "+datum=WGS84" to the "+to" part I get the same
> result as with V4.5.0 (still wrong in respect of ticket 1531).
> Despite that, isn't it true that the grid file contains
> datum definition for both (from and to) system?  So isn't
> it better to assume datum definition for both systems, if
> a grid is specified?

Uwe,

PROJ.4 implicitly assumes that datum grids map from the
local datum to WGS84 but the output coordinate system can
be other than WGS84 so I don't agree that the nadgrids
implies the whole transformation.

 > What also confuses is that the destination
> datum isn't really WGS84 in this case, but the slightly
> different ETRS89.

Because the PROJ nadgrids directive does not understand that
there can exist grids going to coordinate systems other than
WGS84 it is necessary to fool it. So you declare your output
coordinate system as +datum=WGS84 but *you* know that you want
to inteprete the output coordinates as ETRS89.

> Anyhow, I think the change breaks backward compatibility and this
> has to be documented very well. All of my old scripts have to
> be patched to give the right results.

Getting to your core problem, I stepped through the code and found
that PROJ is not attempting to apply a bessel to WGS84 ellipsoid
change in your case.   After the gridshift file is applied it
internally updates it's concept of source ellipsoid to be WGS84.

Unfortunately, it uses a WGS84 "es" value that is slightly different
than the one that results from +datum=WGS84 so it thinks the
input and output coordinate system still have different ellipsoids
and it goes through geocentric space to correct this.  I have modified
pj_transform.c to use the same WGS84 es value that is used with
+datum=WGS84 and now this processing is avoided, and your exact expected
output value is produced again.  This change will appear in beta2.

Thanks for highlighting the bug 1531 issue.

> Another question: When an how do these changes affect GDAL/OGR?

GDAL/OGR uses PROJ.4 for transformations and so the change also
applies to GDAL/OGR (and MapServer, GRASS, etc).  For the most
part it should mean people no longer need to be hyper-aware of
the interals of PROJ as things will start to work the way folks
expect.

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

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: PROJ 4.6.0 beta1 Release

rgreenwood
In reply to this post by Frank Warmerdam
On Nov 30, 2007 7:40 AM, Frank Warmerdam <[hidden email]> wrote:

> 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.

For what it's worth, MapInfo does that same thing. This behavior has
caught me off guard a few times, but it's really pretty logical.

Rich

--
Richard Greenwood
[hidden email]
www.greenwoodmap.com
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: PROJ 4.6.0 beta1 Release

Ivan Shmakov
In reply to this post by Frank Warmerdam
        [Apparently this message didn't reached the list, so I'm
        resending it.]

>>>>> Frank Warmerdam <[hidden email]> writes:

[...]

 >> 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.

[...]

 > 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.

        I guess, the command I've suggested half a year ago in [1]:

$ gdalwarp -of HFA \
      -s_srs '+proj=sinu +R=6371007.181 +nadgrids=@null +wktext' \
      -t_srs TARGET-SRS \
      'HDF4_EOS:EOS_GRID:"fpar8.hdf":MOD_Grid_MOD15A2:Fpar_1km' \
      fpar8.hfa

        could now be rewritten as:

$ gdalwarp -of HFA \
      -s_srs '+proj=sinu +R=6371007.181 +datum=WGS84' \
      -t_srs TARGET-SRS \
      'HDF4_EOS:EOS_GRID:"fpar8.hdf":MOD_Grid_MOD15A2:Fpar_1km' \
      fpar8.hfa

        (i. e., the source projection is spherical, but the coordinates
        used are the WGS84 ones)?  If yes, that's good!  May I suggest
        updating [2] then as well?

        Or do I miss something?

[1] http://trac.osgeo.org/gdal/ticket/1239
[2] http://proj.maptools.org/faq.html

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj