How to deal with dynamic CRS or CRS with ensemble datums (such as EPSG:4326)?

[jorisvandenbossche]

From #25 (comment). The spec has a required crs field that stores a WKT2:2019 string representation of the Coordinate Reference System.

We currently recommend using EPSG:4326 for the widest interoperability of the written files. However, this is a dynamic CRS, and in addition uses an ensemble datum. See https://gdal.org/user/coordinate_epoch.html for some context. In summary, when using coordinates with a dynamic CRS, you also need to know the point in time of the observation to know the exact location.

Some discussion topics related to this:

• How do we deal with a dynamic CRS? We should probably give the option to include the "coordinate epoch" in the metadata (the point in time at which the coordinate is valid)
  • This coordinate epoch is not part of the actual CRS definition, so I think the most straightforward option is to specify an additional (optional) "epoch" field in the column metadata (next to "crs") that holds the epoch value as a decimal year (eg 2021.3).
  • This means we would only support a constant epoch per file. This is in line with the initial support for other formats in GDAL, and we can always later think about expanding this (eg additional field in the parquet file that has a epoch per geometry, or per vertex)

[paleolimbot]

It's my understanding that there is a place for the coordinate epoch in WKT2:2019 (i.e., by defining a CRS with one of the realizations as the GDAL page described). If that is the case, I would suggest leaving the coordinate epoch representation to the WKT2 representation in the crs field (but that should be checked!). In theory you can also put that in the coordinates themselves (e.g., via an "m" coordinate) and define a spatiotemporal CRS. I'd argue that anybody that cares about sub-meter accuracy will also be using a projected CRS, though.

[jorisvandenbossche]

It's my understanding that there is a place for the coordinate epoch in WKT2:2019 (i.e., by defining a CRS with one of the realizations as the GDAL page described).

My understanding is that WKT:2019 indeed supports this, but not in the CRS representation itself. The example on the GDAL page for FlatGeoBuf shows this (https://gdal.org/user/coordinate_epoch.html#flatgeobuf), and uses the "COORDINATEMETADATA" construct, which consists of the CRS and the EPOCH. See http://docs.opengeospatial.org/is/18-010r7/18-010r7.html#128 for the details.

We can of course relax the "crs" field in our metadata to also allow a CoordinateMetadata WKT string in addition to a CRS WKT string. That would be an alternative option next to adding a separate "epoch" field.
However I don't know how widely spread the support for such WKT strings is (eg I don't directly see support for this in PROJ or pyproj, cc @rouault?), although it might be relatively straightforward to extract the CRS part manually (although at the point it might be easier to just store them separately).

[rouault]

However I don't know how widely spread the support for such WKT strings is (eg I don't directly see support for this in PROJ or pyproj, cc @rouault?)

yes, PROJ doesn't support the COORDINATEMETADATA WKT construct currently. In the OGR FlatGeoBuf driver, we manually parse the COORDINATEMETADATA[] to extract the CRS (and provide it to proj) and the coordinate epoch.

[paleolimbot]

I stand corrected...sorry for the indirection! It seems that there's a better chance it will propagate through an operation if kept in the metadata under epoch since it might get dropped if read into PROJ and then re-rendered as WKT?

[jorisvandenbossche]

In summary, a concrete proposal here would be to add an optional "epoch" field (next to "crs"), that can be used if you have a dynamic CRS to specify the epoch of the data as a decimal year (to follow the ISO spec for how to format that value, see "epoch" entry in the list of definitions at http://docs.opengeospatial.org/is/18-010r7/18-010r7.html#4)

[jorisvandenbossche]

@rouault I think you added the "epoch" field in the GDAL implemention, so I assume you are fine with such a solution?

[jorisvandenbossche]

Opened #49 to add an optional "epoch" field to the spec.

[rouault]

so I assume you are fine with such a solution?

yes, looks good to me

[cholmes]

(moved the original 4326 discussion in this issue description to its own issue in #52. I think all comments have just been about the epoch topic so far)

[Jesus89]

We have merged both #49 and #52. Can we close this one?

[jorisvandenbossche]

With the addition of "epoch", I think this can indeed be closed