Closed heidivanparys closed 3 years ago
When GeoPackage is used as the format for the bulk download, the gpkg_contents.last_change
column could be used (so one date per table/view):
The
last_change
SHOULD contain the timestamp of when the content in the referenced table was last updated, in ISO8601 format. Note that since it is not practical to ensure that this value is maintained properly in all cases, this value should be treated as informative.Requirement 15
Values of the
gpkg_contents
tablelast_change
column SHALL be in ISO 8601 [I29] format containing a complete date plus UTC hours, minutes, seconds and a decimal fraction of a second, with a 'Z' ('zulu') suffix indicating UTC. The ISO8601 format is as defined by the strftime function '%Y-%m-%dT%H:%M:%fZ' format string applied to the current time.
Anyway, this issue hasn't received any comments, and as I opened it myself, I'll allow myself to close it now 🙂.
This issue addresses one of the topics discussed in #22 .
When offering a bulk download that is updated using a different update cycle than the data served by the API (see one possible architecture at https://github.com/INSPIRE-MIF/gp-ogc-api-features/issues/22#issuecomment-573599964 , that distribution of the data set has a different date of modification then the distribution served by the
/collections/...
requests.In order to comply with https://eur-lex.europa.eu/eli/reg/2010/1089/2014-12-31 :
So preparing an updated bulk download every day, every week or every month would be ok, and probably sufficient for quite some users.
Question: how can/should these different dates of modification be documented?