Post by Even RouaultRegarding KML and GeoJSON and OGC:CRS84 (or EPSG:4326 since they are
the same thing, except axis order), that's a good and hard
question. Actually that extends to *any* CRS built on top of them,
like all the EPSG:32[6|7][01-60] UTM CRS, and that's probably for
those later than things are the most problematic since there's no EPSG
code for a UTM WGS 84 (G1762) CRS. I guess people would potentially
want to attach a coordinate epoch to them, and have a
(non-encoded-in-the-format) convention that they actually mean WGS 84
(G1762) (or possibly an earlier realization. The datum ensemble
I think the real problem here is that the EPSG authority is not defining
the things that need to be defined, perhaps mostly because of a valid
concern about an exploding list. (And partly because of the decision to
put datum and projection both in a codepoint, leading to the need for D
x P codes.)
Given the problem, at least until there is a solution to all instances
of it, I think it's far more reasonable to say that "WGS84" means
"WGS84(G1762)" (at the moment) when being read or written and to treat it
that way, placing the fuzz from the almost entirely theoretical
possibility that there is any data in WGS84(TRANSIT) onto the data and
away from the datum, and thus not harming everybody else.
Ideally, all standards that reference WGS84 would be fixed (GPX,
GeoJSON, TMS, geo: URIs) but until that happens it's the best way to
deal that I can think of. Essentially, it's fixing them from the
outside by declaring that they mean the most recently realization.
So here's a challenge: Does anyone have data stored in a dataset labeled
WGS84 where that data is *actually in WGS84(TRANSIT)*? Does anyone know
of the existence of such data? Has anyone even heard a rumor that
someone else has that data? If so, please describe the expected error
of the data, and how it is used in a proj/gdal/etc. pipeline and what
problems would occur from it being treated as WGS84(G1762) when being read.
Keep in mind that for someone to have such data, it has to be from a
non-differential navigation solution and will thus be subject to SA and
have a 100m expected error. (I have seen such data from 1992 and it
really is that bad.)
Post by Even Rouaultreality of WGS 84 is really due to Transit which differs significantly
from later realizations, which are pretty consistent between them
within a few centimers) . So I wouldn't forbid such uses (I actually
got private feedback that some people would even want to store
coordinate epoch for CRS that aren't considered by EPSG as dynamic
CRS, but which, for advanced uses, can still have things like
deformation models, like NAD83(2011) that is used for most people as a
static CRS, but is more a snapshot of a dynamic CRS with a
conventional reference epoch of 2010.0).
I haven't been saying that that I know of, but indeed NAD83(2011)
appears to me to be no longer a static datum, when looked at closely
enough.
Post by Even RouaultThat said, I'll probably drop the commit for KML as it is clearly a
hack, but I think support for GeoJSON, which is cleaner, could still
be useful at some point as it is widely used as an exchange
format. But I'll defer for GeoJSON until we see if the /OGC Features/
and /Geometries JSON/ SWG comes with something regarding this.
As I see it, GeoJSON is two different formats. One is the format GDAL
(and qgis) read and write, which does have an attached CRS. Then
there's the one standardized by IETF which made the decision to not
include CRS and label it WGS84. It seems the open geo world has
rejected that IETF decision and been happily reading and writing CRS.
I have been using GeoJSON to write data (that lives in a geopackage) as
NAD83(2011) and also as ITF2014 (as a proxy for WGS84(G1762) to avoid
incorrect null transforms), and that's been working fine, modulo the
WGS84 confusion. So "GeoJSON is intrinsically low accuracy" is
incorrect. Perhaps "GeoJSON without an expressed CRS is interpreted as
WGS84 which is a mess at the moment, at least in the open source
world". But GeoJSON with a CRS does not in my view have any increased
problems compared to other formats.
As for opt in, I don't see the logic, if we have a notion now that a
dynamic CRS without an epoch will omit it and a dynamic CRS with an
explictly-set epoch will include it. I think it's better for people to
maybe run into an issue that to have it silently dropped. And, it seems
that the likely handling is for it to be ignored on reading, which is
functionally like omitting it on write.