ChangeType.update stac_dist/water_and_wetness_10m/water_and_wetness_10m.json

[fairicube-data]

{"filename": "water_and_wetness_10m/water_and_wetness_10m.json", "item_type": "stac_dist", "change_type": "Update", "user": "FAiRICUBE", "data_owner": true}

[KathiSchleidt]

@misev Looks good, but I have an issue with the band definition, currently "definition": "https://land.copernicus.eu/en/technical-library/hrl-water-wetness-2018-user-manual/@@download/file"

The definitionfield should provide a link to the ObservableProperty, only problem is that we don't have such an ObservableProperty available at present. I've now created a request for a FAIRiCUBE Codelist for a Water and Wetness Observable Property entry, once Antonio creates this entry the metadata record here should be updated accordingly.

This will probably be relevant for many of the datasets, please check what Observable Properties we need codelist entries for, propose them as required

[misev]

Ok this will need to be done essentially for all the new catalog entries I've prepared. I wonder if it can be "batched" into a single metadata resource request?

[misev]

Who is supposed to prepare these requests actually? So far I've done them myself and it's been a ton of manual copy-paste work. I had the impression that UC partners were supposed to make these, but the ones I saw (e.g. from WER) were pretty bad quality.

[KathiSchleidt]

@misev I'd feel most confident if we first agreed on what ObservableProperty codelists we need for the various datasets, create the ObservableProperty codelist entries, then update for all datasets. Described in #318

I'm also wondering if we shouldn't provide more detail in the "category_list" attribute under bands. I'm aware that this field has been poorly defined, mostly missing in existing standards. Would it make sense to create a data structure here to provide both the values and their meanings?

[KathiSchleidt]

@misev to your question on who is to prepare these lists, the idea was that UC partners provide as much as they can (please remember that our UC partners are NOT EO experts!), get support from the technical partners where they get lost.

Unfortunately, this process broke several times over the last 2 years due to known reasons, the UC partner finally gave up and shifted to EOX. Thus I'd see it as CU responsibility to re-engage the UC partners, then collaboratively collect all required information. Sorry that the alignment between data requests and UC has gone a bit sideways, I believe you're aware of the reasons (that I may not state here)

[misev]

@misev I'd feel most confident if we first agreed on what ObservableProperty codelists we need for the various datasets, create the ObservableProperty codelist entries, then update for all datasets. Described in #318

Sounds good, I commented there with a table of pending requests for CU datacubes.

I'm also wondering if we shouldn't provide more detail in the "category_list" attribute under bands. I'm aware that this field has been poorly defined, mostly missing in existing standards. Would it make sense to create a data structure here to provide both the values and their meanings?

That would be good, it's more of a question for the catalog developers though I guess, as it depends on whether it can fit such a structure.

[misev]

@misev to your question on who is to prepare these lists, the idea was that UC partners provide as much as they can (please remember that our UC partners are NOT EO experts!), get support from the technical partners where they get lost.

Ok I understand that. The catalog editor interface can definitely be improved to help with this, as it is even for me it was hard to figure out some details let alone non-EO experts. Some short hints/explanations of the fields would be certainly helpful.

[KathiSchleidt]

@misev on "category_list", I had long discussions with Peter on also providing such categorization from within Coverages but failed badly (all my proposals were pushed back, no alternatives provided). While providing in the STAC metadata works (once we get it to work!), I still think that this information should be included in the rangeType when the DataRecord is of type Category

Happy for any and all feedback on the catalog editor (and any other FAIRiCUBE tools you're using!). As I'm not directly involved in this process, only so much feedback I can provide at an abstract level

[misev]

@sonjastndl ok you could just click on "Review changes" -> "Approve" (on the Files changed tab)