Feature request: add 'changelog' metadata field (date and description)

[billgeo]

Is your feature request related to a problem? Please describe.

So that I can understand the changes that have occurred to the dataset over time, as a Data User, I want to see basic changelog for the dataset/collection (date and description).

Describe the solution you'd like

Add a mandatory linz:changelog metadata field to the collection metadata, only add data and description in the first instance.

Location: collection top level field metadata
Name: linz:changelog
Description:

Contains a log of changes that have occurred within the data collection. The date should correspond to the 'dataset version' and 'dataset updated' dates stored elsewhere. The description should be a concise summary of changes.

Optional/Required: "Required"
Restrictions: An object that must have
'date' (UTC datetime),
'description' (string)

Changelog history should ideally be ordered newest to oldest. Suggestion is to use a list of json objects to structure this data.

Example

Date: 2020-04-22T02:17:24.900422Z
Description:  "Replaced tile BG37_5000_1009 to include nodata region.

A LDS customer noticed that tile BG37_5000_1009 had black regions on the outer edges of the image. The tile was reprocessed using GDAL to set the black regions to a nodata value to match the other tiles nodata values within the dataset.

Refer to issue https://jira.linz.govt.nz/browse/TODATA-654"

Describe alternatives you've considered

Additional context

[l0b0]

What does "non-legacy" mean in this case? If it's not something which we're currently enforcing in the schema we should just make this field optional in this issue.

[billgeo]

Yes. I think 'legacy' means some dataset that is old and doesn't have any changelog information and may only ever have one version. So yes, should be optional in the JSON schema I think.

[billgeo]

Maybe in the description it might make more sense to say 'Required for new datasets'

[l0b0]

Maybe in the description it might make more sense to say 'Required for new datasets'

Isn't that tautological, since only new datasets will be referring to the latest version of the LINZ extension?

[l0b0]

I presume this is meant to be used for non-atomic updates. For example, we don't want a changelog entry per file, but rather a semantically related change like re-aligning some geospatial reference across all assets or adding a field to all relevant metadata files. Do we want some guidelines along that line, to make sure we don't get spammed with changelog entries?

[l0b0]

Do we need some guidelines on the value for date? As a programmer, I envision a process like this one:

1. Someone discovers a change is needed (new data arrives, old data needs to be corrected, or something else).
2. Someone initiates the change process. This could take anything from minutes to months.
3. Eventually someone commits/pushes/saves the final change to the assets and metadata.

I would expect that the date value corresponds to the time of either #3 above or some time after that when someone updates the date value. What do you think?

[l0b0]

Should message maybe be description? I get connotations of sending this to someone if it's called "message", but that might just be me :).

[billgeo]

Should message maybe be description

Yes. I think that's consistent iwth other stac metadata. Let's propose that.

[billgeo]

Victor suggests creating a new extension for this and making mandatory in LINZ extension.

Victor is saying this is quite straight forward but may inlcude changes from feedback and rebasing etc.

[m-mohr]

fyi: I like the general idea of making a changelog avaialble and could also see this being part of the version extension, although IMHO a changelog may only need to be linked to and not be part of the JSON file itself. So adding a rel type for changelogs might be they way I'd propose it in the version extension.

Edit: See stac-extensions/version#6