<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">I'll take the liberty of responding to a couple of Greg's (excellent) points:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><span class="gmail_default"></span>> 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></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">All of Australia is moving at approximately 7cm/year relative to the ITRF.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><span class="gmail_default"></span>> "misaligned" is an odd word, because I'm not sure what is misaligned to<br>> what. If you mean multiple map layers, because one is epoch 2010.0 and<br>> one ecpoh 2014.0, then I can see the point. But again, what are the<br>> velocities, and what is the resulting position error?<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The example that Cameron is using is GDA94 -> GDA2020. The shift is around 1.8m.</div><div class="gmail_default" style="font-size:small"><a href="http://www.ga.gov.au/scientific-topics/positioning-navigation/geodesy/datums-projections/gda2020">http://www.ga.gov.au/scientific-topics/positioning-navigation/geodesy/datums-projections/gda2020</a> </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The situation will be similar (for different reasons) when the USA moves to NSRS 2022. The horizontal shift will be around 1.5m.<br></div><div class="gmail_default" style="font-size:small"><a href="https://www.ngs.noaa.gov/datums/newdatums/WhatToExpect.shtml">https://www.ngs.noaa.gov/datums/newdatums/WhatToExpect.shtml</a> </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"> <span class="gmail_default"></span>> It seems obvious as new WGS84 realizations happen<br></div>> over time that the database/projection should be interpreted as the<br>> recent one, for people that care about meter-level accuracy.<br></div><div><br></div><div><div class="gmail_default" style="font-size:small">Interesting comment. To me, "high precision" means cm level, or better, which is why I've been saying that there is no such thing as a precise WGS84 coordinate (unless perhaps you are working for the US military). Although the basic requirements are the same - any spatial dataset should include meta-data that (correctly) identifies the reference frame, the epoch, and the precision of the data.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Regards,</div><div class="gmail_default" style="font-size:small">Nick</div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 17 Jul 2019 at 07:40, Cameron Shorter <<a href="mailto:cameron.shorter@gmail.com">cameron.shorter@gmail.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">Hi Greg,<br>
<br>
I can see that you have put quite a bit of effort into thinking about <br>
the questions below. Could I ask for another 15 mins of your time to <br>
read the 8 page position paper? I think half your questions are answered <br>
in the doc.<br>
<br>
You are asking understandably questions which I feel is really <br>
important, and I hope you can help with that. Please login before adding <br>
comments so we know who said what. Comments are welcome, but please <br>
don't use track changes in the text (as the doc becomes hard to read).<br>
<br>
<a href="https://docs.google.com/document/d/15uBX2qICODRkiHXeksT0zEy6TuysanIxuc4anV0o5F0/edit#" rel="noreferrer" target="_blank">https://docs.google.com/document/d/15uBX2qICODRkiHXeksT0zEy6TuysanIxuc4anV0o5F0/edit#</a><br>
<br>
Cheers, Cameron<br>
<br>
On 17/7/19 12:22 am, Greg Troxel wrote:<br>
> Cameron Shorter <<a href="mailto:cameron.shorter@gmail.com" target="_blank">cameron.shorter@gmail.com</a>> writes:<br>
><br>
>> Thanks for feedback so far. I'm aggregating answers into one email,<br>
>> and copying your comments into the master working doc here:<br>
>> <a href="https://docs.google.com/document/d/15uBX2qICODRkiHXeksT0zEy6TuysanIxuc4anV0o5F0/edit#" rel="noreferrer" target="_blank">https://docs.google.com/document/d/15uBX2qICODRkiHXeksT0zEy6TuysanIxuc4anV0o5F0/edit#</a><br>
>><br>
>> On 15/7/19 9:58 pm, Greg Troxel wrote:<br>
>>> It might also help to have your notes in plain text and actually send<br>
>>> them to the list, after editing for minimum length<br>
>> Greg, you are asking good questions, but it would be bad manners for<br>
>> me dump my long, half baked paper onto this list. Instead I'll copy<br>
>> the introduction, and hopefully you might be tempted to read the<br>
>> details in doc reference above:<br>
> I would suggest that you first write something that presumes the<br>
> appropriate background and is as short as possible. Explaining it to<br>
> people who don't understand surveuying/geodesy is much harder of course.<br>
><br>
>> Increasing demands for location accuracy has exposed design flaws in<br>
>> current “good-enough” approaches to web-mapping. Prior implementations<br>
>> haven’t accounted for tectonic plate shifts, resulting in systematic<br>
>> metre-level inaccuracies which are increasing over time.<br>
> This is not about web mapping. I think you are conflating issues with<br>
> fuzzy or old datum use with web presentation.<br>
><br>
><br>
>> The problem we’ve inherited is that a dynamicdatum is being used as if<br>
>> it were static. (Think of a datum as a mathematical model and<br>
>> associated coordinate system for the earth.)<br>
> So this is a clue that you are writing for a different audience than I<br>
> suggest. I realize that may be your end goal, but I think you should<br>
> have the professional audience crisp version peer reviewed first.<br>
><br>
>> Web-mapping applications use pre-rendered map tiles to improve<br>
>> performance and scalability. This freezes map tiles at a point in time.<br>
> Yes, but typically the underlying databases are updated and tiles are<br>
> rebuilt. In openstreetmap my impression is that tiles rarely get to be<br>
> 30 days old.<br>
><br>
> Are you really talking about station velocities that are so large that a<br>
> tile from even a year ago has a big enough shift to be perceptible at<br>
> z19? z20? I have not done the math, but this seems hard to believe.<br>
><br>
> At z19 (mid latitude) on a normal computer, it seems that 20m is about<br>
> 100 pixels (very roughly). So that's 20 cm/pixel. How far apart do<br>
> epochs needto be for trouble? (Note that I'm assuming all the data has<br>
> been transformed into the same datum.)<br>
><br>
>> To facilitate interoperability, implementers have selected a<br>
>> defacto-standard map projection of WGS84 Web Mercatorwhich is<br>
>> <<a href="https://www.epsg-registry.org/report.htm?type=selection&entity=urn:ogc:def:crs:EPSG::3857&reportDetail=short&style=urn:uuid:report-style:default-with-code&style_name=OGP%20Default%20With%20Code&title=EPSG:3857" rel="noreferrer" target="_blank">https://www.epsg-registry.org/report.htm?type=selection&entity=urn:ogc:def:crs:EPSG::3857&reportDetail=short&style=urn:uuid:report-style:default-with-code&style_name=OGP%20Default%20With%20Code&title=EPSG:3857</a>>based<br>
>> on the WGS84 datum.<br>
> Yes, but the notion of which WGS84 has been fuzzy, because it has not<br>
<span class="gmail_default" style="font-size:small"></span>> been that important. It seems obvious as new WGS84 realizations happen<br>
> over time that the database/projection should be interpreted as the<br>
> recent one, for people that care about meter-level accuracy.<br>
><br>
>> However the WGS84 datum is dynamic (time dependant),meaning that a<br>
>> feature’s coordinates change over time as the tectonic plates drift<br>
>> across the earth.<br>
<span class="gmail_default" style="font-size:small"></span>> 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>
> much higher?<br>
><br>
>> This results in misaligned map layers.<br>
<span class="gmail_default" style="font-size:small"></span>> "misaligned" is an odd word, because I'm not sure what is misaligned to<br>
> what. If you mean multiple map layers, because one is epoch 2010.0 and<br>
> one ecpoh 2014.0, then I can see the point. But again, what are the<br>
> velocities, and what is the resulting position error? How does that<br>
> compare to the uncertainties in the positions in the first place?<br>
><br>
>> Adopting a static datum for web mapping, probably using the WGS84<br>
>> realisations currently in use.<br>
> If you mean, "for web mapping, specify that we use some recent flavor of<br>
> WGS84 (or ITRFXxx?), and some epoch", I can see the point, but who is it<br>
> you want to adopt? And, how is that epoch going to be chosen, and when<br>
> will it be updated?<br>
><br>
><br>
><br>
> Please note that I'm not saying that epochs can be ignored always. In<br>
> the glorious future, the type used for positions will have velocities<br>
> and an epoch. But I am having a hard time seeing this as a web mapping<br>
> problem now.<br>
<br>
-- <br>
Cameron Shorter<br>
Technology Demystifier<br>
Open Technologies and Geospatial Consultant<br>
<br>
M +61 (0) 419 142 254<br>
<br>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div></div>