Hi Sean,
Hi Even, Howard:
I'm inclined to approve, but I feel like there should be more
discussion, not just among PROJ developers and developers of cutting
edge formats. We should work to draw a wider group in on this.
Various OGC standard working groups are aware of that topic since this
was raised I think in a plenary meeting more than one year ago. I see
that in Testbed 17 the working group on the "OGC Features and Geometry
JSON" (the "extension" of GeoJSON) is aware of that, but has not
proposed any solution. I've just pointed them to my proposal.
Howard, are you suggesting that there should be a configuration option
to opt in to this new feature?
A surprise 1-2 meter shift is going to break builds and applications,
I agree. I think a lot of us are tolerating inaccuracy due to using
time-varying CRS but are going to be caught out by changes in the
actual numbers.
The mere introduction of this new capability isn't going to change any
behavior. It is only going to change behavior if people do add a
coordinate epoch in their datasets, and in that case, one can expect
them to want more accurate coordinate transformations. That said adding
a config option in the OGRProjCT class to ignore the coordinate epoch is
trivial...
Now that I think about it, I think the RFC should say more about what
it will do for the ensemble OGC:CRS84.
I'm not sure what kind of transformations will be possible when
operating on the WGS 84 ensemble. Within what is available strictly
speaking in EPSG, probably none. But we have had repeated discussions on
the PROJ mailing list regarding this, and potentially one option could
be to consider that a "recent" coordinate epoch on WGS 84 would mean
that people actually use the latest WGS 84 realization, WGS 84 (G1762)
currently, and so use transformations available from/to that
realization. But nothing regarding this has been implemented yet. To get
a time-dependent transformation, you need to specify a non-ensemble datum.
To me, it seems that the parameterization or description of coordinate
epochs in OGC 19-005r4 is a bit sketchy.
Could you precise ?
Even, are you saying that coordinate shifts in PROJ are entirely
functions of the datetime delta since the coordinate epoch?
Currently what is available in PROJ for transformations between a
dynamic CRS and a static CRS is mostly through using 15-parameter
Helmert transformation:
https://proj.org/operations/transformations/helmert.html (*). Those
Helmert transformations can have non-time dependent components (the
"classic" 7-parameter transformtion, ala TOWGS84) + a time-dependant
component that is generally a rotation in spherical coordinates w.r.t
Earth centre and of an amplitude proportional to (coordinate_epoch -
central_epoch) where central_epoch is a constant of the transformation
(e.g the GDA2020 to ITRF2014 transformation uses central_epoch=2020.0).
But they are not "entirely functions of the datetime delta", since the
value of the longitude, latitude, ellipsoidal height of the coordinate
has also an influence on the result (not completely sure to understand
your question).
To be complete on the topic, there are a few esoteric cases where
https://proj.org/operations/transformations/deformation.html grids are
used, and the amplitude of the correction is also proportional to
(coordinate_epoch - central_epoch), but this is specific to a NKG
(Nordic countries) CRS code
And there's the very particular case of transformations between ITRF96
and NZGD2000 (New Zealand) which uses a more complex deformation model
(https://proj.org/operations/transformations/defmodel.html), where the
time parameter can decide if corrections related to earthquakes are
applied depending on the location and if you're before or after the date
of the earthquake.
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
