Bulk download and date of modification for (frequently changing) datasets

[heidivanparys]

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 #22 (comment) , 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 :

Article 8

Updates

1. Member States shall make available updates of data on a regular basis.

2. All updates shall be made at the latest 6 months after the change was applied in the source data set, unless a different period is specified for a specific spatial data theme in the Annexes.

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?

[heidivanparys]

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 table last_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 🙂.