[gdal-dev] Upgrading to GDAL 3.4.2 from 1.10.0 shows different outputs from gdaltransform and corresponding C++ API

[Greg Troxel]

"Fox, Shawn D (US) via gdal-dev" <gdal-dev at lists.osgeo.org> writes:

> I have noticed that from GDAL 1.10 - GDAL 3.1.0 that gdaltransform is
> producing different results for NAD27 GCS to WGS84 GCS
> transformations.  The differences in longitude in the output is more
> significant.  Having tested the differences in feet between the points
> output from each version I can see a difference of ~5 feet primarily
> due to the change in the longitude value.

> Would anyone look at the following results and share your thoughts
> about why the result of this transformation is different in a newer
> version?  Could this be related to the concept of WGS 84 realization
> being different in newer versions of GDAL?  I am also linking GDAL
> 3.4.2 with PROJ 8.1.1 at this time.  These results were produced with
> GDAL 3.4.2, but the same results occur with GDAL 3.1.0 as well.  GDAL
> 3.4.2 is what I am currently trying to upgrade to.  The results from
> the C++ programming API are similar in difference.  I just used
> gdaltransform for the purposes of this message because it was a more
> convenient way of producing something that others might be able to
> reproduce.

You didn't explain

  - When you were using gdal 1.10 (what year was that??), what version
    of proj were you using?

  - What happens when you just use proj, and not gdal?  It's always best
    to simplify the problem.  Include the results of "projinfo".

  - What you get when using NGS's tools, which are more or less the gold
    standard for the right answer.

  - What your approach is to "WGS84", which is an ensemble.  It contains
    members that differ by about 2m, including one that more or less
    matches NAD83(1986) and ones that very closely match recent ITRF.

  - What you are thinking about plate motion -- and if that even makes
    sense given the low accuracy of NAD27.   And after you explain that,
    why you are using WGS84 rather than NAD83(2011) epoch 2010.0.

> GDAL 1.10.0 results
> ./gdaltransform -s_srs NAD27 -t_srs WGS84
>
> -117.258911 32.804191
> -117.25978144845 32.8042393819884 1.32247805595398e-07
>
> GDAL 3.4.2 results
> ./gdaltransform -s_srs NAD27 -t_srs WGS84
> -117.258911 32.804191
> -117.259764476223 32.8042388409449 0

If you are seeing less than 2m difference it's really hard to say either
is wrong, and it's not really a bug that it changed.

  NAD27 is a low-accuracy datum, with internal distortions.

  Generally, there are grid shift files to use with NAD27-NAD83
  conversions because of this.  They are not included in the main proj
  tarball, and are available in various data tarballs and via the net.
  Having them and not having them is quite different.

  proj treats NAD83 to WGS84 as a null transform because WGS84 has a
  member that matches NAD83.  But if you care about 1m, you have to:

    stop using the WGS84 ensemble

    once explicit about which member you mean, perhaps WGS84(G2139), pay
    attention to NAD83 to ITRF transforms.
  
> I have read that the support for specifying epochs related to realizations is not available until GDAL 3.8.0.

And, you aren't specifying them anyway :-)  Your problems are far
greater than epochs, which are only going to make sense once you resolve
the ensemble issues.

And, it's nearly impossible to believe that any data which is originally
in NAD27 is going to have errors that are as low as 2m in the first
place.


> Here are some references I've read so far.
> Transforming between WGS84 Realizations | Journal of Surveying Engineering | Vol 148, No 2 (ascelibrary.org)<https://ascelibrary.org/doi/10.1061/%28ASCE%29SU.1943-5428.0000389>

That's paywalled so not useful to th rest of us :-(

But the point is that it makes senes to transform between data that is
actually in different members of the ensemble, because it was gathered
in those members.

It does not make sense to transform *to* this ensemble, unless you
declare loudly and then act consistently with a belief that 2m of
difference is effectively zero -- in which case you have not presented a
problem.