[PROJ] OGC blog post summarising Web-mapping misalignment problem

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

[PROJ] OGC blog post summarising Web-mapping misalignment problem

Cameron Shorter
Proj folks,
A bit of an update. A few of us have been refining our thinking and description of the web-mapping misalignment problem. Scott from the OGC has noted the importance of this topic and invited us to raise the topics at the next OGC Technical Committee meeting at Banff (9 Sept). (Getting approval to travel to the event is becoming trickier than we'd expected.)

The OGC has published a blog post from us summarising the issues:

And we are working on a more detailed discussion paper which we plan to socialise within a week or two.

Cheers, 
--
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: OGC blog post summarising Web-mapping misalignment problem

Greg Troxel-2
Earlier I had a lot of comments; this is far easier to really
understand, so to the extent I was at all helpful (unclear :-) thanks
for listening.

I find the term "misalignment" to be not helpful.  While I understand
what's going on and what you are struggling with, "misalignment" is
conceptually fuzzy on what's actually incorrect.

As I see it, this could point to a root cause a bit more clearly:

  "WGS84" means an ensemble and thus has intrisically limited accuracy
  (of a few meters, avoiding the details)

  using an ensemble as a pivot datum is not a good thing to do (if you
  care about accuracy)

  people treat WGS84 as a low accuracy frame on one hand, and on the
  other hand get upset when their results show the several meter fuzz
  that this datum ensemble is expected to have

(This in addition to coordinates not having velocities, or tiles having
epochs, etc, but my sense is that most of the current pain is from the
null transforms to an ensemble - perhaps I got that wrong.)

Overall, I think your listed options 3/4 to stop using the WGS84 datum
ensemble are necessary long term.

The option "in AU, decide that among the multiple values of WGS84, we
not only mean an old one, but we mean coordinates from a specific epoch,
to sort of make a plate-fixed" is interesting.  That seems to make yet
another variant that isn't any of the actual WGS84 realizations, if I
followed correctly.

It would seem cleaner for the future to declare that AU webmaps are in
GDA2020 at some epoch, and transform the older data.

It would seem useful to add some metadata API call in TMS that returns a
datum object (including epoch).  That seems to be your last option, but
just making that information available over the web API seems not so
hard and could be quite useful.
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: OGC blog post summarising Web-mapping misalignment problem

Roger Oberholtzer-2
In reply to this post by Cameron Shorter
On Thu, Aug 22, 2019 at 12:51 AM Cameron Shorter
<[hidden email]> wrote:
>
> Proj folks,
> A bit of an update. A few of us have been refining our thinking and description of the web-mapping misalignment problem. Scott from the OGC has noted the importance of this topic and invited us to raise the topics at the next OGC Technical Committee meeting at Banff (9 Sept). (Getting approval to travel to the event is becoming trickier than we'd expected.)
>
> The OGC has published a blog post from us summarising the issues:
> https://www.opengeospatial.org/blog/3045

I have a question about the WGS84 datum ensemble in regards to GNSS
receivers. When providing WGS84 locations, how would I know which
WGS84 variant is being supplied? Is the receiver involved in this? Or
is it the satellites that control this? Is it enough to know the date
of the measurement? Or must one track more to know which WGS84 variant
is provided?





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

Re: OGC blog post summarising Web-mapping misalignment problem

Nick Mein
Hi Roger,

The answer is ... it depends.

If you are using autonomous positions then the positions will be in the reference frame of the satellite orbits. Currently WGS84(G1762) for GPS. But the precision that you are going to get is a couple of meters at best, so the difference between different realizations of WGS84 is fairly much irrelevant. The epoch may be relevant , if the data is still going to be of interest in a couple of decades time.

If you are using a correction service, then you will need to check with your service provider to find out the reference frame of the positions that your receiver is giving you. It could be ITRFxxxx, it could be a local reference frame such as GDA2020 or NAD83. (For what it is worth - there are proposals to add reference frame information to NTRIP and/or RTCM, but currently there is no way to tell without checking with your provider.)

Regards,
Nick.

On Thu, 22 Aug 2019 at 18:30, Roger Oberholtzer <[hidden email]> wrote:
On Thu, Aug 22, 2019 at 12:51 AM Cameron Shorter
<[hidden email]> wrote:
>
> Proj folks,
> A bit of an update. A few of us have been refining our thinking and description of the web-mapping misalignment problem. Scott from the OGC has noted the importance of this topic and invited us to raise the topics at the next OGC Technical Committee meeting at Banff (9 Sept). (Getting approval to travel to the event is becoming trickier than we'd expected.)
>
> The OGC has published a blog post from us summarising the issues:
> https://www.opengeospatial.org/blog/3045

I have a question about the WGS84 datum ensemble in regards to GNSS
receivers. When providing WGS84 locations, how would I know which
WGS84 variant is being supplied? Is the receiver involved in this? Or
is it the satellites that control this? Is it enough to know the date
of the measurement? Or must one track more to know which WGS84 variant
is provided?





--
Roger Oberholtzer
_______________________________________________
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: OGC blog post summarising Web-mapping misalignment problem

J Luis
Hello, with the risk of going a bit off topic I have another question about the different WGS84, which is: why are they different?

They all use the same ellipsoid, right? So the difference is in the origin of the referencing system? And if yes, why does it change in the several WGS84 realizations?

Thanks

J Luis

Sent from my iDedo

No dia 22/08/2019, às 14:01, Nick Mein <[hidden email]> escreveu:

Hi Roger,

The answer is ... it depends.

If you are using autonomous positions then the positions will be in the reference frame of the satellite orbits. Currently WGS84(G1762) for GPS. But the precision that you are going to get is a couple of meters at best, so the difference between different realizations of WGS84 is fairly much irrelevant. The epoch may be relevant , if the data is still going to be of interest in a couple of decades time.

If you are using a correction service, then you will need to check with your service provider to find out the reference frame of the positions that your receiver is giving you. It could be ITRFxxxx, it could be a local reference frame such as GDA2020 or NAD83. (For what it is worth - there are proposals to add reference frame information to NTRIP and/or RTCM, but currently there is no way to tell without checking with your provider.)

Regards,
Nick.

On Thu, 22 Aug 2019 at 18:30, Roger Oberholtzer <[hidden email]> wrote:
On Thu, Aug 22, 2019 at 12:51 AM Cameron Shorter
<[hidden email]> wrote:
>
> Proj folks,
> A bit of an update. A few of us have been refining our thinking and description of the web-mapping misalignment problem. Scott from the OGC has noted the importance of this topic and invited us to raise the topics at the next OGC Technical Committee meeting at Banff (9 Sept). (Getting approval to travel to the event is becoming trickier than we'd expected.)
>
> The OGC has published a blog post from us summarising the issues:
> https://www.opengeospatial.org/blog/3045

I have a question about the WGS84 datum ensemble in regards to GNSS
receivers. When providing WGS84 locations, how would I know which
WGS84 variant is being supplied? Is the receiver involved in this? Or
is it the satellites that control this? Is it enough to know the date
of the measurement? Or must one track more to know which WGS84 variant
is provided?





--
Roger Oberholtzer
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
_______________________________________________
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: OGC blog post summarising Web-mapping misalignment problem

Nick Mein
Hi Joaquim,

A non-geodesist, layman's answer from me: New realizations include new data, and maintain/improve coincidence with the ITRF. See, eg, http://www.unoosa.org/documents/pdf/icg/2018/icg13/wgd/wgd_12.pdfftp://ftp.nga.mil/pub2/gps/sat_out/SteveM/NGA_ICG11_2Nov.pdf

Regards,
Nick.

On Thu, 22 Aug 2019 at 20:58, Joaquim Luis <[hidden email]> wrote:
Hello, with the risk of going a bit off topic I have another question about the different WGS84, which is: why are they different?

They all use the same ellipsoid, right? So the difference is in the origin of the referencing system? And if yes, why does it change in the several WGS84 realizations?

Thanks

J Luis

Sent from my iDedo

No dia 22/08/2019, às 14:01, Nick Mein <[hidden email]> escreveu:

Hi Roger,

The answer is ... it depends.

If you are using autonomous positions then the positions will be in the reference frame of the satellite orbits. Currently WGS84(G1762) for GPS. But the precision that you are going to get is a couple of meters at best, so the difference between different realizations of WGS84 is fairly much irrelevant. The epoch may be relevant , if the data is still going to be of interest in a couple of decades time.

If you are using a correction service, then you will need to check with your service provider to find out the reference frame of the positions that your receiver is giving you. It could be ITRFxxxx, it could be a local reference frame such as GDA2020 or NAD83. (For what it is worth - there are proposals to add reference frame information to NTRIP and/or RTCM, but currently there is no way to tell without checking with your provider.)

Regards,
Nick.

On Thu, 22 Aug 2019 at 18:30, Roger Oberholtzer <[hidden email]> wrote:
On Thu, Aug 22, 2019 at 12:51 AM Cameron Shorter
<[hidden email]> wrote:
>
> Proj folks,
> A bit of an update. A few of us have been refining our thinking and description of the web-mapping misalignment problem. Scott from the OGC has noted the importance of this topic and invited us to raise the topics at the next OGC Technical Committee meeting at Banff (9 Sept). (Getting approval to travel to the event is becoming trickier than we'd expected.)
>
> The OGC has published a blog post from us summarising the issues:
> https://www.opengeospatial.org/blog/3045

I have a question about the WGS84 datum ensemble in regards to GNSS
receivers. When providing WGS84 locations, how would I know which
WGS84 variant is being supplied? Is the receiver involved in this? Or
is it the satellites that control this? Is it enough to know the date
of the measurement? Or must one track more to know which WGS84 variant
is provided?





--
Roger Oberholtzer
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
_______________________________________________
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: OGC blog post summarising Web-mapping misalignment problem

J Luis
Thanks Nick, learned a bit more.

Joaquim

Sent from my iDedo

No dia 22/08/2019, às 17:00, Nick Mein <[hidden email]> escreveu:

Hi Joaquim,

A non-geodesist, layman's answer from me: New realizations include new data, and maintain/improve coincidence with the ITRF. See, eg, http://www.unoosa.org/documents/pdf/icg/2018/icg13/wgd/wgd_12.pdfftp://ftp.nga.mil/pub2/gps/sat_out/SteveM/NGA_ICG11_2Nov.pdf

Regards,
Nick.

On Thu, 22 Aug 2019 at 20:58, Joaquim Luis <[hidden email]> wrote:
Hello, with the risk of going a bit off topic I have another question about the different WGS84, which is: why are they different?

They all use the same ellipsoid, right? So the difference is in the origin of the referencing system? And if yes, why does it change in the several WGS84 realizations?

Thanks

J Luis

Sent from my iDedo

No dia 22/08/2019, às 14:01, Nick Mein <[hidden email]> escreveu:

Hi Roger,

The answer is ... it depends.

If you are using autonomous positions then the positions will be in the reference frame of the satellite orbits. Currently WGS84(G1762) for GPS. But the precision that you are going to get is a couple of meters at best, so the difference between different realizations of WGS84 is fairly much irrelevant. The epoch may be relevant , if the data is still going to be of interest in a couple of decades time.

If you are using a correction service, then you will need to check with your service provider to find out the reference frame of the positions that your receiver is giving you. It could be ITRFxxxx, it could be a local reference frame such as GDA2020 or NAD83. (For what it is worth - there are proposals to add reference frame information to NTRIP and/or RTCM, but currently there is no way to tell without checking with your provider.)

Regards,
Nick.

On Thu, 22 Aug 2019 at 18:30, Roger Oberholtzer <[hidden email]> wrote:
On Thu, Aug 22, 2019 at 12:51 AM Cameron Shorter
<[hidden email]> wrote:
>
> Proj folks,
> A bit of an update. A few of us have been refining our thinking and description of the web-mapping misalignment problem. Scott from the OGC has noted the importance of this topic and invited us to raise the topics at the next OGC Technical Committee meeting at Banff (9 Sept). (Getting approval to travel to the event is becoming trickier than we'd expected.)
>
> The OGC has published a blog post from us summarising the issues:
> https://www.opengeospatial.org/blog/3045

I have a question about the WGS84 datum ensemble in regards to GNSS
receivers. When providing WGS84 locations, how would I know which
WGS84 variant is being supplied? Is the receiver involved in this? Or
is it the satellites that control this? Is it enough to know the date
of the measurement? Or must one track more to know which WGS84 variant
is provided?





--
Roger Oberholtzer
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
_______________________________________________
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: OGC blog post summarising Web-mapping misalignment problem

Martin Desruisseaux-3
In reply to this post by J Luis
Le 22/08/2019 à 10:58, Joaquim Luis a écrit :

> Hello, with the risk of going a bit off topic I have another question
> about the different WGS84, which is: why are they different? They all
> use the same ellipsoid, right? So the difference is in the origin of
> the referencing system? And if yes, why does it change in the several
> WGS84 realizations?
>
The origin move slightly between realizations. But in addition of that
translation, the axes may also have a slight rotation and a slight scale
factor (I did not verified if it was the case for WGS84 realizations).
Those changes exist both because of improvement in the accuracy of the
measurements used for defining the WGS 84 reference frame, but also
because datum defined by satellites have their origin at the center of
mass of Earth and that center of mass moves continuously (because of
plates tectonic, convection movements in Earth mantle, etc.).

I think that users looking for stability should use the reference frame
defined by their country instead than any satellite-based datum. For
example for locating points in Australia, use the CRS defined by
Australian mapping agency. National CRS are defined respective to the
continental plate where the country is located. Even if they define a
relationship between national CRS and satellites-based CRS, they take in
account that their continental plate does not move in the same way than
the Earth center of mass and they provide more accurate transformations
between old and new CRS than if we were using the satellite-based CRS. I
would suggest to reserve the use of satellite-based CRS like WGS84 to
the cases where data are already in that CRS anyway (e.g. GPS data), or
span a geographic area too wide for being expressed with a national CRS.

    Martin


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

Re: OGC blog post summarising Web-mapping misalignment problem

Duncan Agnew
I can only speak to ITRF, but the changes in this come mostly from there being longer time series and more stations. Motion
of the Earth's center of mass is at the sub-cm level--and at this level there are actual motions of the ground that enter in, from
loading by water changes, or by postglacial rebound. That said, if your country is all on one plate, and your national authority
has defined a CRS moving with that plate (a plate-fixed system) then that is probably the one to use, since it maximizes the future
relevance of a value that doesn't include an epoch.

Duncan Agnew

On Thu, Aug 22, 2019 at 5:23 AM Martin Desruisseaux <[hidden email]> wrote:
Le 22/08/2019 à 10:58, Joaquim Luis a écrit :

> Hello, with the risk of going a bit off topic I have another question
> about the different WGS84, which is: why are they different? They all
> use the same ellipsoid, right? So the difference is in the origin of
> the referencing system? And if yes, why does it change in the several
> WGS84 realizations?
>
The origin move slightly between realizations. But in addition of that
translation, the axes may also have a slight rotation and a slight scale
factor (I did not verified if it was the case for WGS84 realizations).
Those changes exist both because of improvement in the accuracy of the
measurements used for defining the WGS 84 reference frame, but also
because datum defined by satellites have their origin at the center of
mass of Earth and that center of mass moves continuously (because of
plates tectonic, convection movements in Earth mantle, etc.).

I think that users looking for stability should use the reference frame
defined by their country instead than any satellite-based datum. For
example for locating points in Australia, use the CRS defined by
Australian mapping agency. National CRS are defined respective to the
continental plate where the country is located. Even if they define a
relationship between national CRS and satellites-based CRS, they take in
account that their continental plate does not move in the same way than
the Earth center of mass and they provide more accurate transformations
between old and new CRS than if we were using the satellite-based CRS. I
would suggest to reserve the use of satellite-based CRS like WGS84 to
the cases where data are already in that CRS anyway (e.g. GPS data), or
span a geographic area too wide for being expressed with a national CRS.

    Martin


_______________________________________________
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: OGC blog post summarising Web-mapping misalignment problem

J Luis
I learned recently that Earth center of mass changes seasonally due to water accumulation in plants of northern hemisphere at spring. This change is detectable by altimeter satellites. 

Sent from my iDedo

No dia 22/08/2019, às 20:16, Duncan Agnew <[hidden email]> escreveu:

I can only speak to ITRF, but the changes in this come mostly from there being longer time series and more stations. Motion
of the Earth's center of mass is at the sub-cm level--and at this level there are actual motions of the ground that enter in, from
loading by water changes, or by postglacial rebound. That said, if your country is all on one plate, and your national authority
has defined a CRS moving with that plate (a plate-fixed system) then that is probably the one to use, since it maximizes the future
relevance of a value that doesn't include an epoch.

Duncan Agnew

On Thu, Aug 22, 2019 at 5:23 AM Martin Desruisseaux <[hidden email]> wrote:
Le 22/08/2019 à 10:58, Joaquim Luis a écrit :

> Hello, with the risk of going a bit off topic I have another question
> about the different WGS84, which is: why are they different? They all
> use the same ellipsoid, right? So the difference is in the origin of
> the referencing system? And if yes, why does it change in the several
> WGS84 realizations?
>
The origin move slightly between realizations. But in addition of that
translation, the axes may also have a slight rotation and a slight scale
factor (I did not verified if it was the case for WGS84 realizations).
Those changes exist both because of improvement in the accuracy of the
measurements used for defining the WGS 84 reference frame, but also
because datum defined by satellites have their origin at the center of
mass of Earth and that center of mass moves continuously (because of
plates tectonic, convection movements in Earth mantle, etc.).

I think that users looking for stability should use the reference frame
defined by their country instead than any satellite-based datum. For
example for locating points in Australia, use the CRS defined by
Australian mapping agency. National CRS are defined respective to the
continental plate where the country is located. Even if they define a
relationship between national CRS and satellites-based CRS, they take in
account that their continental plate does not move in the same way than
the Earth center of mass and they provide more accurate transformations
between old and new CRS than if we were using the satellite-based CRS. I
would suggest to reserve the use of satellite-based CRS like WGS84 to
the cases where data are already in that CRS anyway (e.g. GPS data), or
span a geographic area too wide for being expressed with a national CRS.

    Martin


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
_______________________________________________
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: OGC blog post summarising Web-mapping misalignment problem

Roger Oberholtzer-2
In reply to this post by Duncan Agnew
On Thu, Aug 22, 2019 at 3:23 PM Duncan Agnew <[hidden email]> wrote:
>
> I can only speak to ITRF, but the changes in this come mostly from there being longer time series and more stations. Motion
> of the Earth's center of mass is at the sub-cm level--and at this level there are actual motions of the ground that enter in, from
> loading by water changes, or by postglacial rebound. That said, if your country is all on one plate, and your national authority
> has defined a CRS moving with that plate (a plate-fixed system) then that is probably the one to use, since it maximizes the future
> relevance of a value that doesn't include an epoch.

But I'm still not 100% clear how to define my source WGS84 lat/longs
from my GNSS receiver when doing this. How best to know which WGS84 to
use? The local CRS cannot know this. Or so it seems to me.


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

Re: OGC blog post summarising Web-mapping misalignment problem

support-2
In reply to this post by Cameron Shorter

Hello,


in the name of simplicity I would suggest storing and referencing data to "what the most simple GPS (GNSS) receiver gives" if possible ... and without any additional datum or ellipsoid or time (outside GMT(UTC) or geoid transformations. Since GPS receivers usually give accurate time and (temporary) coordinate information BUT often cannot even calculate the geoid correctly (so better to use the reference ellipsoid instead). So anything too complicated from the GPS receiver is out of the question ... and would also slow down the process needlessly when recording lot of points.


And since that would be the preferred way to store data ... and what also could stay reasonably accurate at least year or two everywhere on the planet (forgetting the time) which usually suits most needs. And then the rest of the complexity built on that and starting from there.


If one needs to know wehere the point really was since it is now maybe 50 years since it was measured he would then do some more (but minimal) complicated calculations.


A good real life example of that would be:

- the beginning of some Australian runway was recorded "here" (coordinates and time using some simple GPS receiver) 50 years ago [additionally maybe its length, direction and slope]

- where it is now (coordinates directly usable with some simple GPS receiver .. so to be able to ask "where should I go now to find the same spot")

- most simple and fastest calculation possible


Janne.


------------------------------------------------ 


Cameron Shorter kirjoitti 2019-08-22 00:50:

Proj folks,
A bit of an update. A few of us have been refining our thinking and description of the web-mapping misalignment problem. Scott from the OGC has noted the importance of this topic and invited us to raise the topics at the next OGC Technical Committee meeting at Banff (9 Sept). (Getting approval to travel to the event is becoming trickier than we'd expected.)
 
The OGC has published a blog post from us summarising the issues:
 
And we are working on a more detailed discussion paper which we plan to socialise within a week or two.
 
Cheers, 
--
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


--
MNS Support
NNS Master Navigator Software
Copyright © Sapper Oy
www.mnspoint.com
[hidden email]

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

Re: OGC blog post summarising Web-mapping misalignment problem

Cameron Shorter

Hi Janne,

Thanks for your suggestions. As I understand it, you are suggesting take the simple approach, which is "near enough" and don't worry about accounting for tectonic plate movement. This is the approach that has been used in web-mapping to date. In Australia, we are discovering that that this approach is not "good enough" anymore. Australia is on the fastest moving tectonic plate, moving at 7cm per year, a point on our national static datum (from 1994) is ~ 1.8 out from to where a GPS receiver says it should be. This inaccuracy is not good enough for many of modern mapping's emerging use cases. Hence this week's conversations at the OGC technical committee meeting will be around options for improving accuracy.

Thanks again, Cameron

On 6/9/19 10:44 pm, [hidden email] wrote:

Hello,

in the name of simplicity I would suggest storing and referencing data to "what the most simple GPS (GNSS) receiver gives" if possible ... and without any additional datum or ellipsoid or time (outside GMT(UTC) or geoid transformations. Since GPS receivers usually give accurate time and (temporary) coordinate information BUT often cannot even calculate the geoid correctly (so better to use the reference ellipsoid instead). So anything too complicated from the GPS receiver is out of the question ... and would also slow down the process needlessly when recording lot of points.

And since that would be the preferred way to store data ... and what also could stay reasonably accurate at least year or two everywhere on the planet (forgetting the time) which usually suits most needs. And then the rest of the complexity built on that and starting from there.

If one needs to know wehere the point really was since it is now maybe 50 years since it was measured he would then do some more (but minimal) complicated calculations.

A good real life example of that would be:

- the beginning of some Australian runway was recorded "here" (coordinates and time using some simple GPS receiver) 50 years ago [additionally maybe its length, direction and slope]

- where it is now (coordinates directly usable with some simple GPS receiver .. so to be able to ask "where should I go now to find the same spot")

- most simple and fastest calculation possible

Janne.

------------------------------------------------ 

Cameron Shorter kirjoitti 2019-08-22 00:50:

Proj folks,
A bit of an update. A few of us have been refining our thinking and description of the web-mapping misalignment problem. Scott from the OGC has noted the importance of this topic and invited us to raise the topics at the next OGC Technical Committee meeting at Banff (9 Sept). (Getting approval to travel to the event is becoming trickier than we'd expected.)
 
The OGC has published a blog post from us summarising the issues:
 
And we are working on a more detailed discussion paper which we plan to socialise within a week or two.
 
Cheers, 
--
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant
 
M +61 (0) 419 142 254


--
MNS Support
NNS Master Navigator Software
Copyright © Sapper Oy
www.mnspoint.com
[hidden email]
-- 
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