I've recently worked in adding coordinate epoch support for dynamic CRS for various geospatial raster and vector formats handled by GDAL in https://github.com/OSGeo/gdal/pull/3827 and https://github.com/rouault/gdal/blob/coordinate_epoch/gdal/doc/source/user/coordinate_epoch.rst
There's an intro about dynamic CRS in https://docs.opengeospatial.org/as/18-005r4/18-005r4.html#74, and a whole PDF about it in https://www.iogp.org/bookstore/product/geomatics-guidance-note-25-dynamic-versus-static-crss-and-use-of-the-itrf/ (gratis once subscribed)
So the question is: what about Spatialite ?
has a pending enhancement to add an "epoch" DOUBLE column to its
gpkg_spatial_ref_sys table. See
is also discussed for PostGIS in
-- http://www.spatialys.com My software is free, but my time generally not.
That's a workable plan although I'm a bit sad that the solutions for GeoPackage (new column in gpkg_spatial_ref_sys), PostGIS (not adopted yet, but perhaps an extra column in a feature table) and Spatialite (new geometry types) diverge.
A few observations:
- what about rasters... ? Having the epoch in spatial_ref_sys
would make it also immediately available to raster.
- I'd suggest perhaps the new geometry types, if that's what is
adopted, to have provision for future extensions. Like have in the
header a sequence of (extension_code, length_of_extension) (could
be one byte each, preceded by a byte giving the number of tuples),
where extension_code here would COORDINATE_EPOCH=1 and
length_of_extension=sizeof(double)=8). That way backward and
forward compatibility would be ensured.
- I don't think you can get rid of spatial_ref_sys as a table. We'll still want people to be able to store their custom CRS with their own WKT
You received this message because you are subscribed to the Google Groups "SpatiaLite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spatialite-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/spatialite-users/984934da-4246-4bab-a56f-c5690aff5200n%40googlegroups.com.
Amendment regarding my suggestion of the sequence of
(extension_code, length_of_extension): I'd suggest for
length_of_extension to use a variable-size integer scheme (so
0-127 would fit in one byte, 128-16383 in 2 bytes, etc.) to allow
potential large extensions.
To view this discussion on the web visit https://groups.google.com/d/msgid/spatialite-users/6596b678-1312-126f-c159-387f45ffbaba%40spatialys.com.
- PROS: directly incorporating the Epoch definition inside eachsingle Geometry allows for storing data collected in differentepochs into the same DB Table, which appears to be a highlydesirable feature.