[PROJ] OGC blog post summarising Web-mapping misalignment problem
Greg Troxel
gdt at lexort.com
Wed Aug 21 17:35:18 PDT 2019
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.
More information about the PROJ
mailing list