[gdal-dev] Support for coordinate epoch of dynamic CRS
Greg Troxel
gdt at lexort.com
Mon May 10 05:29:19 PDT 2021
Even Rouault <even.rouault at spatialys.com> writes:
> https://github.com/rouault/gdal/blob/coordinate_epoch/gdal/doc/source/user/coordinate_epoch.rst
> The :cpp:func:`OGRSpatialReference::SetCoordinateEpoch` and
> :cpp:func:`OGRSpatialReference::GetCoordinateEpoch` methods can be
> used to set/retrieve a coordinate epoch associated with a
> CRS. Pedantically the coordinate epoch of an observation belongs to
> the observation, and not to the CRS, however it is often more
> practical to bind it to the CRS.
There's a lot behind this and it might be helpful to expand. Suggested
text:
Formally, the coordinate epoch of an observation belongs to the
observation. However, almost all formats do not allow for storing
per-observation epoch, and typical usage is a set of observations with
the same epoch. Therefore we store the epoch as property of the CRS,
and the meaning of this is as if that epoch value were part of every
observation. This choice eases processing, storage and format
complexity for most usage. For now, this means that a dataset where
points have different epochs cannot be handled.
I can imagine a table of point features where points in general have a
different epoch. Probably most people would have the reaction "don't go
there" and I would concur this is best avoided, but it's not clear that
it always will be avoidable. Extending per-point storage from xyz to
xyzt feels like a separate activity.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210510/1dabb41d/attachment.sig>
More information about the gdal-dev
mailing list