Even Rouault <[email protected]> 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.
signature.asc
Description: PGP signature
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
