<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Just a few things to note from my perspective but certainly not
"official" from the US National Geodetic Survey (NGS). Probably
more information than you want to know but I believe it can be
helpful to have a general skepticism in transformations and vertical
transformations in particular. I also apologize since this email
got quite lengthy.
<br>
<br>
Vertical datums in the US have inherent errors that cause
uncertainty in places due to systematic errors or incorrect
assumptions. Here is a little information about the historical
US vertical datums and Ill note the future datum should be far more
accurate since it will be derived primarily through terrestrial,
aerial and satellite gravity measurements.
<br>
<br>
NGVD29 used 26 tide gauges across North America as constraints and
made the assumption that sea level was the same in all places, which
we now know is not the case. This caused inherent errors in the
middle of the country where data was made to "fit" through least
squares adjustments causing inaccurate heights due to the assumption
that all tide gauges were a height of 0.
<br>
<br>
NAVD88 tried to rectify this by only using one tide gauge as a
constraint. This caused the systematic errors in the leveling to
propagate across the country. Today people get NAVD88 heights by
tying into bench marks that have NAVD88 heights on them which allows
for them to get consistent heights in NAVD88 and is precise and
provides repeatable heights, but precision is not accuracy as we are
seeing while planning for the new datum in 2022.
<br>
<br>
Here at NGS we are working on a new datum and you can see the
systematic errors from NAVD88 in <a moz-do-not-send="true"
href="ftp://ftp.ngs.noaa.gov/dist/bshaw/Approximate_Vertical_Change_2022_sm.png">this
map</a> that shows the estimated change that will occur from
NAVD88 to the new Geopotential Datum (Vertical Datum). Its called
"Geopotential" since it will be developed primarily through gravity
and not hundreds of thousands of kilometers of leveling like past
vertical datums.
<br>
<br>
A note on transformations in general is you should understand that
almost all transformations are often termed mapping grade which is
fine for GIS but not for geodetic coordinates. You should also
understand the uncertainties of the datums being used. For instance
if you are using WGS84 coordinates you should understand that just
by using that datum you are introducing 3-5 meters of uncertainty in
the horizontal coordinates, I'm not sure about vertically.
Geodetically the best rule of thumb for having the most accurate
coordinates is to preserve your original observations and process
them in the datum of choice. That is not always possible since you
may not be the person/group collecting the data but it is something
to keep in mind.
<br>
<br>
A closing note on accuracies as mentioned below by Kristian is that
not all people report accuracies in the same way. Even here at NGS
there are different products that report in different measures. Some
report at the one sigma level (standard deviation, square root of
variance) also described as having 68% confidence in the value.
Others report at the two sigma level (variance, std dev squared)
which is often termed having 95% confidence in the value. So I
would encourage you to know what sigma is used to report the
accuracy and also understand this may just be the accuracy estimated
in the datum which doesnt necessarily account for the uncertainty in
the datum itself.
<br>
<br>
Cheers
<br>
Brian
<br>
<br>
<div class="moz-cite-prefix">On 11/27/2019 3:18 AM, Kristian Evers
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:f778ba428bdd434eaf29bc152da583b7@sdfe.dk">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">The algorithm currently is rather
simple: just add the (in)accuracies of each step. I do have some vague
remembering from univ that this was not always the "right" thing to do from a
math point of view. I guess sometimes perhaps taking the max() would be more
appropriate. But given that we can potentially mix uncomparable things,
probably not that a big deal...
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Yeah, this can definitely be improved but it's a simple and effective solution that
doesn't promise too much which is always better that saying that accuracy is
better than it really is. I think this could be a fun topic to have a workshop on
at the OSGeo code sprint in the spring.
/Kristian
-----Original Message-----
From: Even Rouault <a class="moz-txt-link-rfc2396E" href="mailto:even.rouault@spatialys.com"><even.rouault@spatialys.com></a>
Sent: 27. november 2019 01:06
To: <a class="moz-txt-link-abbreviated" href="mailto:proj@lists.osgeo.org">proj@lists.osgeo.org</a>
Cc: Nyall Dawson <a class="moz-txt-link-rfc2396E" href="mailto:nyall.dawson@gmail.com"><nyall.dawson@gmail.com></a>; Kristian Evers <a class="moz-txt-link-rfc2396E" href="mailto:kreve@sdfe.dk"><kreve@sdfe.dk></a>
Subject: Re: [PROJ] "Trustworthiness" of vertical transformations
On mercredi 27 novembre 2019 09:34:33 CET Nyall Dawson wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Tue, 26 Nov 2019 at 20:52, Kristian Evers <a class="moz-txt-link-rfc2396E" href="mailto:kreve@sdfe.dk"><kreve@sdfe.dk></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">You can get the transformation accuracy using the API function
proj_coordoperation_get_accuracy(). I think it would be cool if
information about transformation accuracy where readily available in
software like QGIS (nudge, nudge :-))
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I should mention that the information about accuracy should be taken with a
grain of salt for several reasons:
- the EPSG guidance note 7-1 [1] underlines that the exact definition of
accuracy varies according to geodetic agencies
- in a number of situations, PROJ will have to synthetize the resulting
accuracy when chaining several steps. The algorithm currently is rather
simple: just add the (in)accuracies of each step. I do have some vague
remembering from univ that this was not always the "right" thing to do from a
math point of view. I guess sometimes perhaps taking the max() would be more
appropriate. But given that we can potentially mix uncomparable things,
probably not that a big deal...
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">That's where I'm coming from now... I'm just wondering if and how we
should expose vertical transformation functionality. Do you have any
ideas on what functionality you would expect an end-user application
to expose for vertical transformations?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Depends on the use cases. If you want to aggregate point cloud datasets that
are referenced against several vertical CRS into a single dataset, you will
probably want to convert them into a single Geographic CRS (ITRF2014, WGS84
G1762) or a single CompoundCRS appropriate for the area of study so that they
can be stashed together.
Even
[1] <a class="moz-txt-link-freetext" href="http://www.epsg.org/Portals/0/373-07-1.pdf">http://www.epsg.org/Portals/0/373-07-1.pdf</a> , §6.5.4.1 Coordinate Operation
accuracy
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
*************************************
Brian Shaw
Geodesist
NOAA/NOS/National Geodetic Survey
Phone # 240-533-9522</pre>
</body>
</html>