[PROJ] Static/Dynamic Webmapping Problem version 2.0

[Greg Troxel]

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.