[PROJ] Static/Dynamic Webmapping Problem version 2.0

Tue Jul 16 16:34:50 PDT 2019

I'll take the liberty of responding to a couple of Greg's (excellent)
points:

> This would be a really good place to insert the velocity of typical
> stations in your country in the latest WGS84 realization.  Or perhaps
> the 90th percentile of velocity.   Are you talking 1 cm/year, or is it

All of Australia is moving at approximately 7cm/year relative to the ITRF.

> "misaligned" is an odd word, because I'm not sure what is misaligned to
> what.  If you mean multiple map layers, because one  is epoch 2010.0 and
> one ecpoh 2014.0, then I can see the point.  But again, what are the
> velocities, and what is the resulting position error?

The example that Cameron is using is GDA94 -> GDA2020. The shift is around
1.8m.
http://www.ga.gov.au/scientific-topics/positioning-navigation/geodesy/datums-projections/gda2020

The situation will be similar (for different reasons) when the USA moves to
NSRS 2022. The horizontal shift will be around 1.5m.
https://www.ngs.noaa.gov/datums/newdatums/WhatToExpect.shtml

 > It seems obvious as new WGS84 realizations happen
> over time that the database/projection should be interpreted as the
> recent one, for people that care about meter-level accuracy.

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.

Regards,
Nick

On Wed, 17 Jul 2019 at 07:40, Cameron Shorter <cameron.shorter at gmail.com>
wrote:

> Hi Greg,
>
> I can see that you have put quite a bit of effort into thinking about
> the questions below. Could I ask for another 15 mins of your time to
> read the 8 page position paper? I think half your questions are answered
> in the doc.
>
> You are asking understandably questions which I feel is really
> important, and I hope you can help with that. Please login before adding
> comments so we know who said what. Comments are welcome, but please
> don't use track changes in the text (as the doc becomes hard to read).
>
>
> https://docs.google.com/document/d/15uBX2qICODRkiHXeksT0zEy6TuysanIxuc4anV0o5F0/edit#
>
> Cheers, Cameron
>
> On 17/7/19 12:22 am, Greg Troxel wrote:
> > Cameron Shorter <cameron.shorter at gmail.com> writes:
> >
> >> Thanks for feedback so far. I'm aggregating answers into one email,
> >> and copying your comments into the master working doc here:
> >>
> https://docs.google.com/document/d/15uBX2qICODRkiHXeksT0zEy6TuysanIxuc4anV0o5F0/edit#
> >>
> >> On 15/7/19 9:58 pm, Greg Troxel wrote:
> >>> It might also help to have your notes in plain text and actually send
> >>> them to the list, after editing for minimum length
> >> Greg, you are asking good questions, but it would be bad manners for
> >> me dump my long, half baked paper onto this list. Instead I'll copy
> >> the introduction, and hopefully you might be tempted to read the
> >> details in doc reference above:
> > I would suggest that you first write something that presumes the
> > appropriate background and is as short as possible.  Explaining it to
> > people who don't understand surveuying/geodesy is much harder of course.
> >
> >> Increasing demands for location accuracy has exposed design flaws in
> >> current “good-enough” approaches to web-mapping. Prior implementations
> >> haven’t accounted for tectonic plate shifts, resulting in systematic
> >> metre-level inaccuracies which are increasing over time.
> > This is not about web mapping.  I think you are conflating issues with
> > fuzzy or old datum use with web presentation.
> >
> >
> >> The problem we’ve inherited is that a dynamicdatum is being used as if
> >> it were static. (Think of a datum as a mathematical model and
> >> associated coordinate system for the earth.)
> > So this is a clue that you are writing for a different audience than I
> > suggest.  I realize that may be your end goal, but I think you should
> > have the professional audience crisp version peer reviewed first.
> >
> >>     Web-mapping applications use pre-rendered map tiles to improve
> >>     performance and scalability. This freezes map tiles at a point in
> time.
> > Yes, but typically the underlying databases are updated and tiles are
> > rebuilt.  In openstreetmap my impression is that tiles rarely get to be
> > 30 days old.
> >
> > Are you really talking about station velocities that are so large that a
> > tile from even a year ago has a big enough shift to be perceptible at
> > z19?  z20?  I have not done the math, but this seems hard to believe.
> >
> > At z19 (mid latitude) on a normal computer, it seems that 20m is about
> > 100 pixels (very roughly).  So that's 20 cm/pixel.  How far apart do
> > epochs needto be for trouble?  (Note that I'm assuming all the data has
> > been transformed into the same datum.)
> >
> >>   To facilitate interoperability, implementers have selected a
> >>     defacto-standard map projection of WGS84 Web Mercatorwhich is
> >>     <
> 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
> >based
> >>     on the WGS84 datum.
> > Yes, but the notion of which WGS84 has been fuzzy, because it has not
> > been that important.   It seems obvious as new WGS84 realizations happen
> > over time that the database/projection should be interpreted as the
> > recent one, for people that care about meter-level accuracy.
> >
> >>     However the WGS84 datum is dynamic (time dependant),meaning that a
> >>     feature’s coordinates change over time as the tectonic plates drift
> >>     across the earth.
> > This would be a really good place to insert the velocity of typical
> > stations in your country in the latest WGS84 realization.  Or perhaps
> > the 90th percentile of velocity.   Are you talking 1 cm/year, or is it
> > much higher?
> >
> >>     This results in misaligned map layers.
> > "misaligned" is an odd word, because I'm not sure what is misaligned to
> > what.  If you mean multiple map layers, because one  is epoch 2010.0 and
> > one ecpoh 2014.0, then I can see the point.  But again, what are the
> > velocities, and what is the resulting position error?   How does that
> > compare to the uncertainties in the positions in the first place?
> >
> >>     Adopting a static datum for web mapping, probably using the WGS84
> >>     realisations currently in use.
> > If you mean, "for web mapping, specify that we use some recent flavor of
> > WGS84 (or ITRFXxx?), and some epoch", I can see the point, but who is it
> > you want to adopt?   And, how is that epoch going to be chosen, and when
> > will it be updated?
> >
> >
> >
> > Please note that I'm not saying that epochs can be ignored always.  In
> > the glorious future, the type used for positions will have velocities
> > and an epoch.  But I am having a hard time seeing this as a web mapping
> > problem now.
>
> --
> Cameron Shorter
> Technology Demystifier
> Open Technologies and Geospatial Consultant
>
> M +61 (0) 419 142 254
>
> _______________________________________________
> 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/20190717/54f775d5/attachment-0001.html>