[PROJ] Change of datum not working

[Greg Troxel]

Mathieu Poulin <mathieu.poulin at mvtgeosolutions.com> writes:

> When creating a transformation that requires a change of datum, it
> does not work. For instance, going from Geographic coordinates in
> WGS84 to UTM coordinates in NAD83CSRS. It does convert from geographic
> lat,lon to UTM projection easting,northing but the datum remains
> WGS84.

I think you mean "the coordinates are those I'd expect if the datum
transformation did not happen".

This has been discussed a lot.  Briefly, WGS84 is a name for a family of
datums, including WGS84(TRANSIT), the original, and the original is
considered equivalent to NAD83(1986).  And, no one (outside the US DoD)
has high-accuracy coordinates that are truly in a WGS84 realization,
because there is no high-accuracy way to access the datum.  The
high-accuracy techniques (carrier phase vs CORS, RTK) are all relative
to either national static datums, or something in someting like ITRF2014
or IGb14.

There are lots of philosophical points about ensembles but my practical
advice is:

  Surely your data is not actually in WGS84(ensemble).

  Beware that terminology is fuzzy with WGS84 the bare word as to
  whether people/programs mean:
    - the realization currently in use
    - the ensemble
    - the original member of the ensemble

  If your data was obtained from non-differential GPS observations, it
  would be in some specific realization of WGS84, depending on the date.
  If it used WAAS, it would be in the WAAS frame instead and not
  actually in WGS84.

  ITRF2008 is a good proxy for relatively recent WGS84 realizations, and
  I think what WAAS uses.  (ITRF2014 is a good proxy for measuremnets
  since early 2021, in WGS84(G2139), but if you can tell the difference
  beteen actual measurements in ITRF2008 and ITRF2014 please tell us how
  :-))

  Keep in mind that ITRF2008 coordinates of points in Canada have
  non-zero velocities.  So you should be thinking about epoch if you
  want to be cm-level.  If you are trying to avoid the meter-level shift
  and ignoring the ~2-3 cm/year over 10 years, that seems like an
  intermediate reasonable approach.  (FWIW, I deal with coordinates in
  NAD83(2011) epoch 2010.0 obtained via RTK that are accurate at the
  5-10 cm level, but once I move to any dynamic frame things get
  messier.)

  If your data is not accurate at the meter level, I would say it still
  makes sense to transform properly form NAD83 to ITRFfoo to match
  others and handle round-tripping, but the finer points probably don't
  make sense to worry about.

  You said NAD83(CSRS) but didn't mention which of the 7 realizations of
  that you are talking about.  However I'm pretty sure those are
  intended to be static and very close the the US NAD83 realizations,
  and close to each other at more or less the 10 cm level.

and thus my real advice is:

  relabel your "WGS84" data as being ITRF2008.  Perhaps by a transform,
  which will be null, or perhaps just label it that way.

  Then, conversion to NAD83(CSRS) should do the datum transform.

  If you are still getting null transforms, transform to NAD83(CSRS)v7
  instead of the bare CSRS word, which might be an ensesmble, and might
  be the original.



A related issue is that with coordinates in Massachusetts State Plane,
defined in terms of NAD83, converting to ITRF2014 can end up null, but
if I convert first to NAD83(2011), which is a null transform, then the
transform to ITRF2014 happens.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20211126/95a37765/attachment.sig>