[PROJ] Vertical Transformations?

[Clifford J Mugnier]

VERTCON is a "snapshot" of the differences between NGVD29 and NAVD88 as they existed in 1992.  Any subsequent vertical crustal movement since 1992 is not modeled in the data grids.  The results for major portions of Louisiana (subsidence) and the Midwest (glacial rebound & uplift) will be in error by a number of feet.  The errors will increase as time passes since the data grids will not be updated.  A similar conundrum will occur to a lesser magnitude (at first) with the new vertical datum to be published in 2022.  Someday, they may publish a VTDP (Vertical Time Dependent Positioning) model that might be "reliable."  So far, it's just a dream.  Clicking that mouse button will give you an answer, but it may be far from reality!


Clifford J. Mugnier, c.p., c.m.s.

Chief of Geodesy

LSU Center for GeoInformatics (ERAD 266)

Dept. of Civil Engineering (P.F. Taylor 3531)

LOUISIANA STATE UNIVERSITY

Baton Rouge, LA  70803

Academic: (225) 578-8536

Research: (225) 578-4578

Cell:             (225) 328-8975

honorary lifetime member, lsps

fellow emeritus, asprs

member, apsg


________________________________
From: PROJ <proj-bounces at lists.osgeo.org> on behalf of Greg Troxel <gdt at lexort.com>
Sent: Wednesday, February 20, 2019 10:52 AM
To: Even Rouault
Cc: proj at lists.osgeo.org
Subject: Re: [PROJ] Vertical Transformations?

Even Rouault <even.rouault at spatialys.com> writes:

>> I wonder if transformations that need grid files for correct behavior
>> should fail rather than skip the transformation, at least by default.
>
> That's a complex topic. There is no "correct" behavior per-se. All
> transformations are approximations, so it is a matter of how accurate your
> needs are.

That's strictly true, but my understanding is there is a broad consensus
that VERTCON is the appropriate conversion for the general problem.

> In the above example if you're fine with ~ 1 metre vertical accuracy,
> you don't need the VERTCON grids.

Agreed that if you are ok with ~1m, you can assume they are the same and
not convert.  That more or less applies to all horizontal datum
conversions, with differing acceptable errors.  With NAD27, the errors
are so large that I suspect almost everyone would prefer an error to
assuming equivalence to ITRFxx, once they understood.

> The EPSG database can also reference some grids that can not necessarily
> easily be found, are not free, or have no known conversion to a PROJ
> recognized format.

So there is no real way for most people to convert to/from those datums.
That's too bad, and I agree those situations are intractable and proj
declining to convert them is not necessarily helpful.

> Selection of a given transformation pipeline among all possible also involve a
> number of arbitrary decisions (some transformations might have intersecting
> area of validity). Playing with the new projinfo utility to list available
> coordinate operations can show the complexity of this...

I realize this is all infinitely complicated.

In this case, my concern is that there is a consensus method to go
between NGVD29 and NAVD88, that I think almost everyone would agree is
the standard approach.  People who install proj but not optional
gridfiles will silently get a much coarser approximation.

So I would like to see the transform from NGVD29/NAVD88 error out when
the VERTCON grid file can't be opened, perhaps with some configuration
to say that it should assume 0 instead.  I think it's better to fail
during what I see as a misconfiguration than to fall back to a cruder
approximation.

Perhaps the evnironment variable "PROJ_NGVD29_COARSE" should be needed,
and this hint can be returned as the error from attempting to use the
gridfile.

I have ensured that the pkgsrc package for proj installs all of the
ok-licensed grid files, so it doesn't matter much to me personally.  I
see there are a lot more now, but it still seems best to include them in
the package.

I am assuming almost all use of proj other than by the developers is via
packaging systems.

It would be interesting to hear what other packagers do in terms of
grids (included, separate packages, not packaged, ?).
_______________________________________________
PROJ mailing list
PROJ at lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/proj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20190220/97347b1e/attachment.html>