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

Re: Static/Dynamic Webmapping Problem version 2.0

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

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

Totally fair, and now I understand what you mean.

I was separating in my mind, but not saying it, the intrinsic quality of
the datum, and accuracy issues surrounding coordinates obtained in that
datum.  I now realize that there is effectively no path to access WGS84
at a precise level because nobody publishes WGS84 coordinates of CORS
stations, etc.  That explains the "outside DOD" comment too.

Agreed that precise use of GPS is invariably in some other datum.  At
least these days IGSxx ITRFxx and WGS84(recent) are all basically the
same.

I have a hard time finding clear statements about WAAS, but it seems to
be defined to be some ITRF, last I was able to find it.   I had wondered
if it would be in NAD83, given the FAA.   So I now expect to get the
same coordinates out of nav-grade GPS with waas and without (modulo
errors of course).
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

[PROJ] Fwd: Re: Static/Dynamic Webmapping Problem version 2.0

support-2
In reply to this post by Cameron Shorter
Hello,

we use a very simple approach to handle plate shiftings related to
whatever datums:

We simply add always a date with the point coordinates. Additionally we
have the datum reference also stored (or use wgs84 always when storing).
So if there is any need to shift the point later related to the date
when it was defined and when it is later referenced we can do it (the
program does it). As said by storing the date with the coordinates and
datum takes care of any later shifts.

Basically this is exatly the same as creating a new datum (ex. GDA2020)
every now and then but it is much more accurate also since it is
accurate to a day and not just some time year 2020.

Regards. Janne.

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

Cameron Shorter kirjoitti 2019-07-12 15:32:

> 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:
>
https://docs.google.com/document/d/1A4Q8-863fKQ-BJzh0ruz7bKvk3itiy8LmmWrwUR1J9g/edit#heading=h.nn4r38g65fhf

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