[PROJ] World UTM in a proper datum

[Greg Troxel]

"Lesparre, Jochem" <Jochem.Lesparre at kadaster.nl> writes:

> I think we should consider to NOT solve the inaccurate transformation
> of the ensemble (point 6), because keeping it like this forces people
> to stop using the ensemble label WGS84 for precise applications and
> make them use a precise realisation (e.g. ITRF2014) instead, thus
> solving the main problem completely (point 2, 3, 4, 5). For inaccurate
> applications the label WGS84 for the ensemble is fine, so we do not
> need to make people to change that (point 1).
>
> If we partly solve the inaccuracy of the transformation of the
> ensemble (point 6) in one of the two ways Greg suggests, it will be
> much harder to make people aware of the remaining accuracy problem of
> the ensemble and it will therefore take much longer (if ever) too get
> that solved (point 1, 2, 3, 4, 5, 7).

I think your view is extremely misguided, continuing to cause people to
get inaccurate results as a way to apply pressure to them.  This is
especially true as the people harmed have very little understanding and
even less leverage in fixing the problems.  I wonder if you would take
this approach if you weren't offended by the political point.

So, how about you:

  Raise the issue of WGS48 with the GPX specification, and make a
  concrete proposal to replace it.  Note that "ITRF2014" is not really a
  good answer as this sort of specification has a notion of tracking
  datum families, which for non-specialist use does not seem
  problematic.  (Using a family is problematic; tracking a family is
  different.)  So it's probably more "GPX data data is defined to be in
  the most recent realization of ITRF as [whatever now-its-official
  condition makes sense]", and when this changes, it should be treated
  as a minor error in older data.  Or maybe something else.

  Do the same with TMS.

And let us know how it goes.  I don't mean to be sarcastic; making these
fixes would be a good thing.  But I honestly do not expect that you will
have success.
-------------- 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/20210419/2db1e268/attachment.sig>