<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><span class="gmail_default">></span>> To me, "high precision" means cm level, or better, which is why I've<br>>> been saying that there is no such thing as a precise WGS84 coordinate<br>>> (unless perhaps you are working for the US military).<br><br>> I don't follow the reference to being part of the military but perhaps<br>> there is non-public data.<br><br>> The US NGS seems to publish coordinates for CORS in IGS08 epcoh 2005.0<br>>and NAD83(2011) epoch 2010.0.  As far as I can tell WGS84(G1762), IGS08<br></div><div class="gmail_default" style="font-size:small">>and ITRF08 are essentially the same.</div><br></div><div dir="ltr"><div class="gmail_default" style="font-size:small">Maybe I'm being a bit pedantic here. But the trouble is that a coordinate that is described as being "WGS84" is generally either not precise (because it is derived from broadcast orbits), or not WGS84 (because it is actually some in some national datum that some piece of software decided was equivalent to WGS84). So yes, if your precise point positioning service gives you a ISG08 coordinate, that is essentially the same as a WGS84(G1762) or ITRF08 or ITRF14 coordinate. But calling it "WGS84" doesn't seem to help anyone.</div><div class="gmail_default" style="font-size:small"> </div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 18 Jul 2019 at 06:26, Greg Troxel <<a href="mailto:gdt@lexort.com" target="_blank">gdt@lexort.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Nick Mein <<a href="mailto:nick_mein@trimble.com" target="_blank">nick_mein@trimble.com</a>> writes:<br>
<br>
>> This would be a really good place to insert the velocity of typical<br>
>> stations in your country in the latest WGS84 realization.  Or perhaps<br>
>> the 90th percentile of velocity.   Are you talking 1 cm/year, or is it<br>
><br>
> All of Australia is moving at approximately 7cm/year relative to the ITRF.<br>
<br>
Thanks - that's certainly a lot faster than my ground is moving.  Trying<br>
to ground this in acceptable accuracies and fitness for use of data, it<br>
feels like 5 years of fuzz is not a big deal (35cm) for anything called<br>
"web mapping", as opposed to "GNSS vectors used for geodetic surveying".<br>
<br>
> The example that Cameron is using is GDA94 -> GDA2020. The shift is around<br>
> 1.8m.<br>
> <a href="http://www.ga.gov.au/scientific-topics/positioning-navigation/geodesy/datums-projections/gda2020" rel="noreferrer" target="_blank">http://www.ga.gov.au/scientific-topics/positioning-navigation/geodesy/datums-projections/gda2020</a><br>
<br>
I see - a shift between two datums that are each nominally fixed to the<br>
plate.<br>
<br>
So I think dealing with this is first a basic issue of having datum<br>
metadata carried alongside coordinates, and everybody has to get that<br>
right if either:<br>
<br>
  they are not using essentially WGS84, or<br>
  they care about 2m<br>
<br>
Then some subset have to carry epoch of data as well; presumably that's<br>
people who aspire to cm-level accuracy and people with data in a frame<br>
with a significant velocity relative to the plate containing the object<br>
(where significant perhaps means an error of velocity*10y makes them<br>
unhappy).<br>
<br>
(In the US, we've largely forgotten NAD27, but the shift in coordinates<br>
from NAD27 to NAD83 is on the order of 40m, at least in New England.<br>
That was not reasonably ignorable even back in 1990.)<br>
<br>
OSM doesn't handle this; when importing data from state GIS agencies, we<br>
transform from NAD83 to WGS84 (not sure how well) and then it's just<br>
stored.  But if we are sub-meter, we're pretty happy.<br>
<br>
> The situation will be similar (for different reasons) when the USA moves to<br>
> NSRS 2022. The horizontal shift will be around 1.5m.<br>
> <a href="https://www.ngs.noaa.gov/datums/newdatums/WhatToExpect.shtml" rel="noreferrer" target="_blank">https://www.ngs.noaa.gov/datums/newdatums/WhatToExpect.shtml</a><br>
<br>
Thanks for the link; I've downloaded the 3 documents for reading.<br>
<br>
>> It seems obvious as new WGS84 realizations happen over time that the<br>
>> database/projection should be interpreted as the recent one, for<br>
>> people that care about meter-level accuracy.<br>
><br>
> Interesting comment<br>
<br>
Perhaps a bit strong on my end, but I was thinking about the<br>
Openstreetmap database, which has always had the notion of "coordinates<br>
of objects are in WGS84".  That seemed like a good choice in 2004, and<br>
my ipmression is that successive realizations of WGS84 are ever closer<br>
to the successive ITRFxx realizations.  Also that the differences in<br>
successive realizations are reasonably small compared to the accuracy<br>
achievable with non-differential GPS.  So were I to try to put accurate<br>
(cm level) coordinates in the OSM database for a point, I'd be trying to<br>
use the most recent WGS84 realization expecting to to more or less be<br>
equal to a recent ITRF.  Looking this up, it seems WGS84(G1762) is more<br>
or less ITRF2008 epoch 2005.0.<br>
<br>
Taking a coordinate from the db, I'd treat it as being from the latest<br>
WGS84, but with an unknown accuracy, perhaps from somebody eyeballing<br>
the map and drawing things, and additionally from fuzz between the older<br>
revisions and the current.<br>
<br>
OSM has not yet grappled with the concept of mapped objects having<br>
velocities relative to WGS84(Gwwww)/ITRFyyyy.<br>
<br>
> To me, "high precision" means cm level, or better, which is why I've<br>
> been saying that there is no such thing as a precise WGS84 coordinate<br>
> (unless perhaps you are working for the US military).<br>
<br>
I don't follow the reference to being part of the military but perhaps<br>
there is non-public data.<br>
<br>
The US NGS seems to publish coordinates for CORS in IGS08 epcoh 2005.0<br>
and NAD83(2011) epoch 2010.0.  As far as I can tell WGS84(G1762), IGS08<br>
<span class="gmail_default" style="font-size:small"></span>and ITRF08 are essentially the same.<br>
<br>
> Although the basic requirements are the same - any spatial dataset<br>
> should include meta-data that (correctly) identifies the reference<br>
> frame, the epoch, and the precision of the data.<br>
<br>
Sure.  But that becomes per-object data in a dataset of mixed origin<br>
(which is where my head is because of OSM), and I suspect one then runs<br>
into missing software support.<br>
<br>
Trying to get back to point for proj, then, I guess the question is what<br>
operations do people need to do are missing or awkward.  One thing I<br>
wonder about based on your metadata comments and my reaction is the<br>
notion of<br>
<br>
  T=createtransform(src_datum, src_epoch, dst_datum, dst_epoch)<br>
  apply_transform(T, vector_of_points[lat, lon, ellipsoidal_height])<br>
<br>
versus the notion that the point object (rather than the transform) has<br>
an epoch, to end up with something that feels like<br>
<br>
  T=createtransform(src_datum, dst_datum, dst_epoch)<br>
  apply_transform(T, vector_of_points[lat, lon, ellipsoidal_height, epoch])<br>
<br>
Probably that's too messy to contemplate for now, without a clear enough<br>
need.<br>
</blockquote></div></div>