Add "epoch" field to optionally specify the coordinate epoch for a dynamic CRS

[jorisvandenbossche]

See first bullet point from #35 (and the following discussion).

This borrows a bit of text from https://gdal.org/user/coordinate_epoch.html (cc @rouault)

[cholmes]

Looks good. Though does 4326 need an epoch? If so we should add what people should put for the epoch if they are using our crs recommendation for interoperability.

[jorisvandenbossche]

Though does 4326 need an epoch? If so we should add what people should put for the epoch

I don't think we can "recommend" a value for the epoch, since that depends on your data.
We might want to add to the recommendation about EPSG:4326, that if you use EPSG:4326, it it also recommended to specify the epoch (although I don't know how important this is in this case, since EPSG:4326 has a low accuracy anyway).

(in general we might want to reconsider the recommendation of EPSG:4326 as I mentioned in #35 (the second bullet point), but let's leave that discussion for in the issue)

[rouault]

Though does 4326 need an epoch?

that's a question that could bring geodesists to disagree for hours.
Strictly speaking EPSG:4326 relies on the EPSG:6326 datum ensemble (https://epsg.org/datum_6326/World-Geodetic-System-1984-ensemble.html), that has an intrinsic inaccuracy of 2 meters, due to the oldest realizations like Transit being quite different from the latest ones, that disagree between them only at the centimer level. So for such a vaguely qualified object, a coordinate epoch doesn't make much sense.
However ... in many cases people may use the vague EPSG:4326 instead of using one of the latest realizations of WGS 84 or ITRFxxxx, but for a number of reasons (like people only knowing EPSG:4326 and freaking out when they see something different) they use EPSG:4326 instead of the proper code. In that case, qualifying the CRS with the epoch could be useful for later processing, where people would say "oh, they actually meant ITRF2014@2022.3".
There are even cases for a CRS/datum that is generally considered static (and for which a coordinate epoch normally doesn't make sense, ), like NAD83(2011), where adding a coordinate epoch might be useful, since there are high precision deformation models that can be used.

[cholmes]

Gotcha, those explanations make sense. And yeah, I was thinking something like 'if you use 4326 then do X for epoch', but if it doesn't really matter then that seems fine to not.

(in general we might want to reconsider the recommendation of EPSG:4326 as I mentioned in #35 (the second bullet point), but let's leave that discussion for in the issue)

Let's actually break that out into its own issue. I've been having doubts about it as well.