[PROJ] Static/Dynamic Webmapping Problem version 2.0

[Cameron Shorter]

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:
>    I'm a little nervous that I've overwhelmed people by the number of pages
>    I've used to describe the web-mapping misaligned maps problem.
>
> 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:

**


    *The challenge*

*

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.

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.)

  *

    Web-mapping applications use pre-rendered map tiles to improve
    performance and scalability. This freezes map tiles at a point in time.

  *

    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.

  *

    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 results in misaligned map layers.


To address these challenges we suggest:

  *

    Explaining the web-mapping challenges to facilitate understanding.

  *

    Adopting a static datum for web mapping, probably using the WGS84
    realisations currently in use.

  *

    Extending spatial standards, data types, software, and workflows to
    address time dependence.

This will be achieved most effectively through international collaboration.

*

On 15/7/19 9:17 pm, Martin Desruisseaux wrote:
> Hello Cameron
>
> Le 15/07/2019 à 01:59, Cameron Shorter a écrit :
>
>> * We are currently using the dynamic WGS84 datum as if it were a
>> static datum (locked to a different epoch in different regions).
>> * This appears to be suitable for current web mapping requirements.
>> * Realigning static and dynamic datums (as started by Australia, with
>> others to follow) is tripping a map misalignment problem.
> I'm not sure which "dynamic WGS84 datum" we are talking about. If we are
> talking about EPSG::4326, in my understanding this is now an "ensemble
> datum", i.e. a group of many different WGS84 datum (there is at least 6
> different WGS84 datum today) to be considered as equivalent for
> applications that do not need an accuracy better than a few meters. An
> "ensemble datum" is not the same as a "static datum" in the sense that
> it does not mean "a datum that does not move", but rather "we don't
> really know which datum it is, but we don't need to care if the desired
> accuracy is only a few meters".

Yes Martin, we discuss here: 
https://docs.google.com/document/d/15uBX2qICODRkiHXeksT0zEy6TuysanIxuc4anV0o5F0/edit#

*

Problem 1.1 Non-unique datum:

*

*The WGS84 datum (EPSG::6326) used in web-mapping is not unique; it has 
been updated six times 
<https://confluence.qps.nl/qinsy/en/world-geodetic-system-1984-wgs84-29855173.html>to 
date. Each update (called a realisation) refines the datum’s ellipsoid 
parameters to account for our improved measurements of the earth’s shape 
(which is different to tectonic plate movement).*

On 16/7/19 9:49 am, HIGGINS Matt wrote:
> Re: "Each update (called a realisation) refines the datum’s ellipsoid parameters to account for our improved measurements of the earth’s shape".
>
> That is incorrect, the ellipsoidal parameters for WGS84 have never changed, i.e. the size and shape of the ellipsoid are the same it is how well the position and orientation of the ellipsoid fit the centre of the earth and rotational axis. That is why I chose my original words very carefully.
Thanks Matt, I'll need to dig up your previous suggested wording.


*On 15/7/19 9:17 pm, Martin Desruisseaux wrote:*

> I'm also not sure what me mean by "suitable for current web mapping
> requirements". Do we we mean "an accuracy of a few meters is
> sufficient"? If yes, then this requirement is addressed by above-cited
> "ensemble datum", which is a new concept introduced in ISO 19111:2019.

To date, Australian web-mapping has had all our layers off center by ~ 
1.8 meters. This has been considered okay because layers were 
topologically aligned. We are now about to see map *mis-alignment* of 
1.8 metres in web mapping. We believe this is going to be unacceptable.

Described in more detail here: 
https://docs.google.com/document/d/15uBX2qICODRkiHXeksT0zEy6TuysanIxuc4anV0o5F0/edit#heading=h.bphraumy10yi

*4. Australia’s misaligned web-maps … is an international problem*

**

On 15/7/19 9:17 pm, Martin Desruisseaux wrote:

> Question to techies:
>> * Is it technically possible to create a reference frame realisation
>> (datum) which is fixed to different epochs in different regions?
> One implication of this approach would be that coordinate operations
> would need to identify in which zone (e.g. using a R-Tree) are located
> the coordinate values to transform, which is potentially a costly
> operation. Another issue is that it would introduce discontinuities at
> the frontier between different zones. It is possible that those
> inconvenient would bring bigger problems than the problem we are trying
> to solve.
>
Thanks for your insights Martin, understanding the implications of this 
question is likely to be very important for our decisions moving forward.


-- 
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20190716/fc37d4e4/attachment-0001.html>