[PROJ] Static/Dynamic Webmapping Problem version 2.0

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[PROJ] Static/Dynamic Webmapping Problem version 2.0

Cameron Shorter
Hi folks,
I've incorporated a lot of feeback from people on this list, and from the Australian geospatial people and have restarted the Static/Dynamic Webmapping Problem.

Comments are encouraged.

If commenting, please log so we know who says what. Please don't change the text as it quickly becomes difficult to read.

I'm very mindful that this is a challenging problem, requiring collaboration to solve, and we still have quite a bit of work in achieving this.

Doc here:

Original problem statement:
> > Our Australian spatial data users are about to face a systematic mismatch challenge when trying to use multiple static datums (GDA2020, GDA94) with the dynamic datum (WGS84). At the moment, it is government agencies grappling with the problem, but it is about to become a mainstream issue.
Cheers, Cameron


--
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254




_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Static/Dynamic Webmapping Problem version 2.0

Cameron Shorter

On Fri, 12 Jul 2019 at 22:32, Cameron Shorter <[hidden email]> wrote:
Hi folks,
I've incorporated a lot of feeback from people on this list, and from the Australian geospatial people and have restarted the Static/Dynamic Webmapping Problem.

Comments are encouraged.

If commenting, please log so we know who says what. Please don't change the text as it quickly becomes difficult to read.

I'm very mindful that this is a challenging problem, requiring collaboration to solve, and we still have quite a bit of work in achieving this.

Doc here:

Original problem statement:
> > Our Australian spatial data users are about to face a systematic mismatch challenge when trying to use multiple static datums (GDA2020, GDA94) with the dynamic datum (WGS84). At the moment, it is government agencies grappling with the problem, but it is about to become a mainstream issue.
Cheers, Cameron


--
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254





--
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254




_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Static/Dynamic Webmapping Problem version 2.0

Cameron Shorter
In reply to this post by Cameron Shorter
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.

The key message I'm hoping to get feedback on is:

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

Proposed solution:
* Define an EPSG code which describes current practice of a static datum, which is fixed to different epochs in different regions.
* Move to using the new EPSG code in web-mapping.

Question to techies:
* Is it technically possible to create a reference frame realisation (datum) which is fixed to different epochs in different regions? 
 
Warm regards, Cameron

On Fri, 12 Jul 2019 at 22:32, Cameron Shorter <[hidden email]> wrote:
Hi folks,
I've incorporated a lot of feeback from people on this list, and from the Australian geospatial people and have restarted the Static/Dynamic Webmapping Problem.

Comments are encouraged.

If commenting, please log so we know who says what. Please don't change the text as it quickly becomes difficult to read.

I'm very mindful that this is a challenging problem, requiring collaboration to solve, and we still have quite a bit of work in achieving this.

Doc here:

Original problem statement:
> > Our Australian spatial data users are about to face a systematic mismatch challenge when trying to use multiple static datums (GDA2020, GDA94) with the dynamic datum (WGS84). At the moment, it is government agencies grappling with the problem, but it is about to become a mainstream issue.
Cheers, Cameron


--
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254





--
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254




_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Static/Dynamic Webmapping Problem version 2.0

Martin Desruisseaux-3
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".

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.


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

    Regards,

        Martin



_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Static/Dynamic Webmapping Problem version 2.0

Greg Troxel-2
In reply to this post by Cameron Shorter
  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 :-)


I can certainly see the issues of datum epoch in high precision data,
but I'm having a little trouble following the linking of "web mapping"
into this.

Are you saying that the datum labeling is correct in the underlying
data, and the only issue is in sending it across web-type interfaces,
due to lack of codepoints?

Are you expecting coordinates for objects to have velocities as well as
xyz/llh values?

Is this at all related to questions lIke "Openstreetmap says they use
"WGS84" coordinates for objects.  What does that really mean?".  (And
there are similar questions for other databases, with the addition or
"but we can't actually see the underlying data so this is even harder to
talk about".)

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Static/Dynamic Webmapping Problem version 2.0

Nick Mein
Well put Greg.

Cameron is correct that Australia is encountering issues earlier than (most of?) the rest of the world, due to the GDA94 -> GDA2020 datum modernisation program. The USA is going to encounter the same issues with the NSRS 2022 datum modernisation.
But they are not intractable issues. If you have one (high precision) dataset that is GDA94 and another (high precision) dataset is GDA2020 then you can combine them, using one of the transformations published on https://www.icsm.gov.au/datum/gda-transformation-products-and-tools. Since velocities in both GDA94 and GDA2020 are virtually zero, you don't need to know the epoch of measurement.

If you have a dataset that is "WGS84", then who knows what you will get.

Regards,
Nick.

On Tue, 16 Jul 2019 at 00:04, Greg Troxel <[hidden email]> 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 :-)


I can certainly see the issues of datum epoch in high precision data,
but I'm having a little trouble following the linking of "web mapping"
into this.

Are you saying that the datum labeling is correct in the underlying
data, and the only issue is in sending it across web-type interfaces,
due to lack of codepoints?

Are you expecting coordinates for objects to have velocities as well as
xyz/llh values?

Is this at all related to questions lIke "Openstreetmap says they use
"WGS84" coordinates for objects.  What does that really mean?".  (And
there are similar questions for other databases, with the addition or
"but we can't actually see the underlying data so this is even harder to
talk about".)

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Static/Dynamic Webmapping Problem version 2.0

Cameron Shorter
In reply to this post by Martin Desruisseaux-3

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 dynamic datum 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 Mercator which is 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 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

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Static/Dynamic Webmapping Problem version 2.0

Greg Troxel-2
Cameron Shorter <[hidden email]> 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.
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Static/Dynamic Webmapping Problem version 2.0

Cameron Shorter
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 <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Static/Dynamic Webmapping Problem version 2.0

Nick Mein
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.

The situation will be similar (for different reasons) when the USA moves to NSRS 2022. The horizontal shift will be around 1.5m.

 > 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Static/Dynamic Webmapping Problem version 2.0

Greg Troxel-2
Nick Mein <[hidden email]> writes:

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

Thanks - that's certainly a lot faster than my ground is moving.  Trying
to ground this in acceptable accuracies and fitness for use of data, it
feels like 5 years of fuzz is not a big deal (35cm) for anything called
"web mapping", as opposed to "GNSS vectors used for geodetic surveying".

> 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

I see - a shift between two datums that are each nominally fixed to the
plate.

So I think dealing with this is first a basic issue of having datum
metadata carried alongside coordinates, and everybody has to get that
right if either:

  they are not using essentially WGS84, or
  they care about 2m

Then some subset have to carry epoch of data as well; presumably that's
people who aspire to cm-level accuracy and people with data in a frame
with a significant velocity relative to the plate containing the object
(where significant perhaps means an error of velocity*10y makes them
unhappy).

(In the US, we've largely forgotten NAD27, but the shift in coordinates
from NAD27 to NAD83 is on the order of 40m, at least in New England.
That was not reasonably ignorable even back in 1990.)

OSM doesn't handle this; when importing data from state GIS agencies, we
transform from NAD83 to WGS84 (not sure how well) and then it's just
stored.  But if we are sub-meter, we're pretty happy.

> 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

Thanks for the link; I've downloaded the 3 documents for reading.

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

Perhaps a bit strong on my end, but I was thinking about the
Openstreetmap database, which has always had the notion of "coordinates
of objects are in WGS84".  That seemed like a good choice in 2004, and
my ipmression is that successive realizations of WGS84 are ever closer
to the successive ITRFxx realizations.  Also that the differences in
successive realizations are reasonably small compared to the accuracy
achievable with non-differential GPS.  So were I to try to put accurate
(cm level) coordinates in the OSM database for a point, I'd be trying to
use the most recent WGS84 realization expecting to to more or less be
equal to a recent ITRF.  Looking this up, it seems WGS84(G1762) is more
or less ITRF2008 epoch 2005.0.

Taking a coordinate from the db, I'd treat it as being from the latest
WGS84, but with an unknown accuracy, perhaps from somebody eyeballing
the map and drawing things, and additionally from fuzz between the older
revisions and the current.

OSM has not yet grappled with the concept of mapped objects having
velocities relative to WGS84(Gwwww)/ITRFyyyy.

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

I don't follow the reference to being part of the military but perhaps
there is non-public data.

The US NGS seems to publish coordinates for CORS in IGS08 epcoh 2005.0
and NAD83(2011) epoch 2010.0.  As far as I can tell WGS84(G1762), IGS08
and ITRF08 are essentially the same.

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

Sure.  But that becomes per-object data in a dataset of mixed origin
(which is where my head is because of OSM), and I suspect one then runs
into missing software support.

Trying to get back to point for proj, then, I guess the question is what
operations do people need to do are missing or awkward.  One thing I
wonder about based on your metadata comments and my reaction is the
notion of

  T=createtransform(src_datum, src_epoch, dst_datum, dst_epoch)
  apply_transform(T, vector_of_points[lat, lon, ellipsoidal_height])

versus the notion that the point object (rather than the transform) has
an epoch, to end up with something that feels like

  T=createtransform(src_datum, dst_datum, dst_epoch)
  apply_transform(T, vector_of_points[lat, lon, ellipsoidal_height, epoch])

Probably that's too messy to contemplate for now, without a clear enough
need.
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Static/Dynamic Webmapping Problem version 2.0

Duncan Agnew
In reply to this post by Greg Troxel-2
Just to add to this discussion, I note that the NGS HTDP program assumes the following:

WGS84(G730) is equivalent to  ITRF91
WGS84(G873) is equivalent to  ITRF94
WGS84(G1150) is equivalent to  ITRF2000
WGS84(G1674) is equivalent to  ITRF2008

and the transformations between these ITRF's are at the 1-2 cm level at most, and are a few mm for the latest frames. I'd note that the later ITRF frames now all have an epoch and velocities for at least some things: again, not important at the 0.1 m level (and probably the 0.01m level as well.

So the changes in WGS84 are, for just about any application, irrelevant.

The problem is *entirely* that WGS/ITRF is tied to a global everage of plate velocities, not fixed to any plate, so repeated measurements over the same ground point in those systems will show changing coordinates because of motion of whatever plate it is on.

My understanding is that both GDA2020 and GDA94 are "snapshots" of the ITRF, with different transformation parameters to allow for plate motion. So if you start out in 1994 and keep measuring the same point in GDA94, its coordinates will change and get increasingly far from their initial value. In GDA2020 they will also change with time, but instead will approach the GDA94 numbers measured in 1994, until in 2020 they will be the same--but then start diverging again. The point is that the coordinate values measured at a place in 1994, expressed in GDA94, will match the values measured at the same place in 2020 expressed in GDA2020. Neither is plate-fixed.  There will be a time-dependent reference frame known as the Australian Terrestrial Reference Frame (ATRF) that is plate-fixed: in 2020 it will match GDA2020.

I continue to prefer "plate-fixed" to "static" because it is immediately obvious what is meant; "static" clearly means that something doesn't change, but what, the frame or the coordinates of a ground point?

Duncan Agnew

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Static/Dynamic Webmapping Problem version 2.0

Even Rouault-2
In reply to this post by Greg Troxel-2
> Thanks - that's certainly a lot faster than my ground is moving.  Trying
> to ground this in acceptable accuracies and fitness for use of data, it
> feels like 5 years of fuzz is not a big deal (35cm) for anything called
> "web mapping", as opposed to "GNSS vectors used for geodetic surveying".

That's questionable. There are a lot of people doing webmapping with aerial
photographies with < 10cm resolution ...

> Perhaps a bit strong on my end, but I was thinking about the
> Openstreetmap database, which has always had the notion of "coordinates
> of objects are in WGS84".  That seemed like a good choice in 2004, and
> my ipmression is that successive realizations of WGS84 are ever closer
> to the successive ITRFxx realizations.  Also that the differences in
> successive realizations are reasonably small compared to the accuracy
> achievable with non-differential GPS.  So were I to try to put accurate
> (cm level) coordinates in the OSM database for a point, I'd be trying to
> use the most recent WGS84 realization expecting to to more or less be
> equal to a recent ITRF.  Looking this up, it seems WGS84(G1762) is more
> or less ITRF2008 epoch 2005.0.

The issue with OSM is more than you don't have the coordinate epoch specified.
You could use the creation timestampof the object as a hint, but the time
where the object is entered in the database isn't necessary the epoch at which
the coordinate was collected (for example, if you import from another
database, like a cadastre, which was built a few years before)

>
> Trying to get back to point for proj, then, I guess the question is what
> operations do people need to do are missing or awkward.  One thing I
> wonder about based on your metadata comments and my reaction is the
> notion of
>
>   T=createtransform(src_datum, src_epoch, dst_datum, dst_epoch)
>   apply_transform(T, vector_of_points[lat, lon, ellipsoidal_height])
>
> versus the notion that the point object (rather than the transform) has
> an epoch, to end up with something that feels like
>
>   T=createtransform(src_datum, dst_datum, dst_epoch)
>   apply_transform(T, vector_of_points[lat, lon, ellipsoidal_height, epoch])
>
> Probably that's too messy to contemplate for now, without a clear enough
> need.

We discussed about that in:

https://lists.osgeo.org/pipermail/proj/2019-June/008668.html
https://lists.osgeo.org/pipermail/proj/2019-June/008669.html
https://lists.osgeo.org/pipermail/proj/2019-June/008670.html

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Static/Dynamic Webmapping Problem version 2.0

Martin Desruisseaux-3
In reply to this post by Duncan Agnew

I did not yet had the time to follow this thread closely (will try to do later), but I would like to react on some points:

  • In my reading of ISO 19111 §3.1.16 [1], the difference between WGS84 realizations can be close to one meter. Note huge, but not irrelevant neither.
  • ISO 19111 §3.1.62 seems to define a static reference frame as a frame without time evolution, regardless if fixed to the plate or not.
  • In past emails I have seen WGS84 cited as a "dynamic datum". In my understanding, it is rather a "datum ensemble", which is not the same thing.

Useful quote from ISO 19111:

“WGS 84” as an undifferentiated group of realizations including WGS 84 (TRANSIT), WGS 84 (G730), WGS 84 (G873), WGS 84 (G1150), WGS 84 (G1674) and WGS 84 (G1762). At the surface of the Earth these have changed on average by 0.7m between the TRANSIT and G730 realizations, a further 0.2m between G730 and G873, 0.06m between G873 and G1150, 0.2m between G1150 and G1674 and 0.02m between G1674 and G1762).

Regards,

    Martin

[1] http://docs.opengeospatial.org/as/18-005r4/18-005r4.html


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Static/Dynamic Webmapping Problem version 2.0

Even Rouault-2
In reply to this post by Duncan Agnew
> So if you start out in 1994 and keep measuring the same point in GDA94, its
> coordinates will change and get increasingly far from their initial value.

When you say "same point", you mean a point at fixed coordinates in ITRF right
? (so contrary to common langage where when talking about "same point" we
generally think of a point physically attached to the plate (not talking about
region subject to crustal deformation/earthquakes)).

> In GDA2020 they will also change with time, but instead will approach the
> GDA94 numbers measured in 1994, until in 2020 they will be the same--but
> then start diverging again. The point is that the coordinate values
> measured at a place in 1994, expressed in GDA94, will match the values
> measured at the same place in 2020 expressed in GDA2020. Neither is
> plate-fixed.

> There will be a time-dependent reference frame known as the
> Australian Terrestrial Reference Frame (ATRF) that is plate-fixed: in 2020
> it will match GDA2020.

Hum, my understanding of ATRF (based on
http://spatialservices.finance.nsw.gov.au/__data/assets/pdf_file/
0018/217224/2017_Janssen_Position90_GDA2020_AUSGeoid2020_and_ATRF_explained.pdf
) is that it is NOT plate-fixed. It is a realization of ITRF, so it is as
Earth-fixed as ITRF is. Basically coordinates in [hidden email] should be pretty
much the same as if expressed in WGS84(G1762)@yyyy.yy

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Static/Dynamic Webmapping Problem version 2.0

Greg Troxel-2
In reply to this post by Martin Desruisseaux-3
Martin Desruisseaux <[hidden email]> writes:

> I did not yet had the time to follow this thread closely (will try to do
> later), but I would like to react on some points:
>
>   * In my reading of ISO 19111 §3.1.16 [1], the difference between WGS84
>     realizations can be close to one meter. Note huge, but not
>     irrelevant neither.
>   * ISO 19111 §3.1.62 seems to define a static reference frame as a
>     frame without time evolution, regardless if fixed to the plate or not.
>   * In past emails I have seen WGS84 cited as a "dynamic datum". In my
>     understanding, it is rather a "datum ensemble", which is not the
>     same thing.

I think the differing usages stem from there being three interpretations
of an unqualified "WGS84":

   The original, WGS84(TRANSIT)
   The one currently used by GPS, WGS84(G1762)
   A set of all of them, and the notion that one doesn't know which one

It's not useful to argue about which concept the bare word should
properly be bound to, but I think it is a leap to assume that any time
anyone uses the bare word that they are intentionally referring to the
set/ensemble meaning and intending to include WGS84(TRANSIT), superceded
in 1994.

You have succeeded in convincing me that I am not sure what static and
dynamic really mean!

> Useful quote from ISO 19111:
>
>     “WGS 84” as an undifferentiated group of realizations including WGS
>     84 (TRANSIT), WGS 84 (G730), WGS 84 (G873), WGS 84 (G1150), WGS 84
>     (G1674) and WGS 84 (G1762). At the surface of the Earth these have
>     changed on average by 0.7m between the TRANSIT and G730
>     realizations, a further 0.2m between G730 and G873, 0.06m between
>     G873 and G1150, 0.2m between G1150 and G1674 and 0.02m between G1674
>     and G1762).

Thanks for digging that out.  There's a useful chart at

 https://confluence.qps.nl/qinsy/latest/en/world-geodetic-system-1984-wgs84-29855173.html

While it seems pedantically true about WGS84 being a group of datums
with a difference close to a meter, note that WGS 84 (G1150) was
introduced in 1997, and the variations from G1150 on are about 0.22m by
what you quote, and 0.02m from the page I linked.  So if one qualify
WGS84 to "WGS 84 from the last 20 years", the scary large variance is
not so present.  (I agree that without some metadata you can't assume
that, but non-differential positions from pre-1997 GPS are much worse
than 1m anyway, SA and all.)

> [1] http://docs.opengeospatial.org/as/18-005r4/18-005r4.html
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Static/Dynamic Webmapping Problem version 2.0

Duncan Agnew
In reply to this post by Even Rouault-2
No, "same point" means "same monument set in the ground". If I understand things properly, a measurement in 1994
(which is analyzed in IRTF and then converted to GDA94) will have some XYZ value, call it XYZ94. And a measurement
in 2020 (analyzed in ITRF and then converted to GDA2020) will have XYZ numbers that have the same values as XYZ94.
Of course the 2020 data, in GDA94, will show a different coordinate for the point. The equivalence of the numbers is very close
only when data from an epoch is in the reference frame (fixed to ITRF) for that epoch.

You are probably right about ATRF: I just assumed that it would be set up as NGS is setting up the new NA frame: a
frame that moves relative to ITRF so that coordinates of places on the NA plate will, in the NA frame, stay the same, as most surveyors prefer. To get these coordinates out of your data you do need to have the epoch (to use the right parameters
for the moving NA frame)--but so long as you and everyone else does that with their data, everybody will get the same numbers for a given monument, whenever they make the measurement. I would have thought this would be perfect for
Australia, since it doesn't deform hardly at all.


On Wed, Jul 17, 2019 at 12:16 PM Even Rouault <[hidden email]> wrote:
> So if you start out in 1994 and keep measuring the same point in GDA94, its
> coordinates will change and get increasingly far from their initial value.

When you say "same point", you mean a point at fixed coordinates in ITRF right
? (so contrary to common langage where when talking about "same point" we
generally think of a point physically attached to the plate (not talking about
region subject to crustal deformation/earthquakes)).

> In GDA2020 they will also change with time, but instead will approach the
> GDA94 numbers measured in 1994, until in 2020 they will be the same--but
> then start diverging again. The point is that the coordinate values
> measured at a place in 1994, expressed in GDA94, will match the values
> measured at the same place in 2020 expressed in GDA2020. Neither is
> plate-fixed.

> There will be a time-dependent reference frame known as the
> Australian Terrestrial Reference Frame (ATRF) that is plate-fixed: in 2020
> it will match GDA2020.

Hum, my understanding of ATRF (based on
http://spatialservices.finance.nsw.gov.au/__data/assets/pdf_file/
0018/217224/2017_Janssen_Position90_GDA2020_AUSGeoid2020_and_ATRF_explained.pdf

) is that it is NOT plate-fixed. It is a realization of ITRF, so it is as
Earth-fixed as ITRF is. Basically coordinates in [hidden email] should be pretty
much the same as if expressed in WGS84(G1762)@yyyy.yy

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Static/Dynamic Webmapping Problem version 2.0

Even Rouault-2
On mercredi 17 juillet 2019 17:24:49 CEST Duncan Agnew wrote:
> No, "same point" means "same monument set in the ground". If I understand
> things properly, a measurement in 1994
> (which is analyzed in IRTF and then converted to GDA94) will have some XYZ
> value, call it XYZ94. And a measurement
> in 2020 (analyzed in ITRF and then converted to GDA2020) will have XYZ
> numbers that have the same values as XYZ94.

That doesn't make sense to me. There will be a ~1.8 m shift between the
coordinates of the same monument expressed in GDA94 and GDA2020 due to plate
motion between 1994 and 2020. That's the whole point of having GDA2020
"resynchronized" with ITRF@2020.00, or I'm missing something...

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Static/Dynamic Webmapping Problem version 2.0

Scott
On mercredi 17 juillet 2019 17:47:34 Even Rouault <even.rouault at spatialys.com>
wrote:

>That doesn't make sense to me. There will be a ~1.8 m shift between the
>coordinates of the same monument expressed in GDA94 and GDA2020 due to plate
>motion between 1994 and 2020. That's the whole point of having GDA2020
>"resynchronized" with ITRF at 2020.00, or I'm missing something...

Correct - you are not missing something.

See https://www.icsm.gov.au/gda2020 but in particular the 3 minute video embedded in the page - https://vimeo.com/191566518

Scott

________________________________

CONFIDENTIALITY NOTICE AND DISCLAIMER
The information in this transmission may be confidential and/or protected by legal professional privilege, and is intended only for the person or persons to whom it is addressed. If you are not such a person, you are warned that any disclosure, copying or dissemination of the information is unauthorised. If you have received the transmission in error, please immediately contact this office by telephone, fax or email, to inform us of the error and to enable arrangements to be made for the destruction of the transmission, or its return at our cost. No liability is accepted for any unauthorised use of the information contained in this transmission.
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Static/Dynamic Webmapping Problem version 2.0

Nick Mein
In reply to this post by Greg Troxel-2
>> 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).

> I don't follow the reference to being part of the military but perhaps
> there is non-public data.

> The US NGS seems to publish coordinates for CORS in IGS08 epcoh 2005.0
>and NAD83(2011) epoch 2010.0.  As far as I can tell WGS84(G1762), IGS08
>and ITRF08 are essentially the same.

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.


On Thu, 18 Jul 2019 at 06:26, Greg Troxel <[hidden email]> wrote:
Nick Mein <[hidden email]> writes:

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

Thanks - that's certainly a lot faster than my ground is moving.  Trying
to ground this in acceptable accuracies and fitness for use of data, it
feels like 5 years of fuzz is not a big deal (35cm) for anything called
"web mapping", as opposed to "GNSS vectors used for geodetic surveying".

> 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

I see - a shift between two datums that are each nominally fixed to the
plate.

So I think dealing with this is first a basic issue of having datum
metadata carried alongside coordinates, and everybody has to get that
right if either:

  they are not using essentially WGS84, or
  they care about 2m

Then some subset have to carry epoch of data as well; presumably that's
people who aspire to cm-level accuracy and people with data in a frame
with a significant velocity relative to the plate containing the object
(where significant perhaps means an error of velocity*10y makes them
unhappy).

(In the US, we've largely forgotten NAD27, but the shift in coordinates
from NAD27 to NAD83 is on the order of 40m, at least in New England.
That was not reasonably ignorable even back in 1990.)

OSM doesn't handle this; when importing data from state GIS agencies, we
transform from NAD83 to WGS84 (not sure how well) and then it's just
stored.  But if we are sub-meter, we're pretty happy.

> 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

Thanks for the link; I've downloaded the 3 documents for reading.

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

Perhaps a bit strong on my end, but I was thinking about the
Openstreetmap database, which has always had the notion of "coordinates
of objects are in WGS84".  That seemed like a good choice in 2004, and
my ipmression is that successive realizations of WGS84 are ever closer
to the successive ITRFxx realizations.  Also that the differences in
successive realizations are reasonably small compared to the accuracy
achievable with non-differential GPS.  So were I to try to put accurate
(cm level) coordinates in the OSM database for a point, I'd be trying to
use the most recent WGS84 realization expecting to to more or less be
equal to a recent ITRF.  Looking this up, it seems WGS84(G1762) is more
or less ITRF2008 epoch 2005.0.

Taking a coordinate from the db, I'd treat it as being from the latest
WGS84, but with an unknown accuracy, perhaps from somebody eyeballing
the map and drawing things, and additionally from fuzz between the older
revisions and the current.

OSM has not yet grappled with the concept of mapped objects having
velocities relative to WGS84(Gwwww)/ITRFyyyy.

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

I don't follow the reference to being part of the military but perhaps
there is non-public data.

The US NGS seems to publish coordinates for CORS in IGS08 epcoh 2005.0
and NAD83(2011) epoch 2010.0.  As far as I can tell WGS84(G1762), IGS08
and ITRF08 are essentially the same.

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

Sure.  But that becomes per-object data in a dataset of mixed origin
(which is where my head is because of OSM), and I suspect one then runs
into missing software support.

Trying to get back to point for proj, then, I guess the question is what
operations do people need to do are missing or awkward.  One thing I
wonder about based on your metadata comments and my reaction is the
notion of

  T=createtransform(src_datum, src_epoch, dst_datum, dst_epoch)
  apply_transform(T, vector_of_points[lat, lon, ellipsoidal_height])

versus the notion that the point object (rather than the transform) has
an epoch, to end up with something that feels like

  T=createtransform(src_datum, dst_datum, dst_epoch)
  apply_transform(T, vector_of_points[lat, lon, ellipsoidal_height, epoch])

Probably that's too messy to contemplate for now, without a clear enough
need.

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
12