[PROJ] Static/Dynamic Webmapping Problem version 2.0
nick_mein at trimble.com
Mon Jul 15 19:05:12 PDT 2019
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
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
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.
On Tue, 16 Jul 2019 at 00:04, Greg Troxel <gdt at lexort.com> 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
> PROJ at lists.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the PROJ