Metadata for uploaded collection

Lorsqu'on upload une collection local, seules les métadonnées de cette collection sont visibles sur le browser THEIA-MTD. Il faudrait générer automatiquement les méta des assets à l'instar de stacflow. Exemple pas de métadonnées dans ressources (type d'asset, projection, imagerie matricielle, ...).

En détaillant le script de création de ma collection j'ai typé les assets et ca a réglé le problème d'affichage sur le browser. Par contre, il n'y a pas d'échelle de visualisation, dû au fait sûrement que les statistiques n'ont pas été calculée pour les méta.

mentioned in issue #1

oui la visu est assez basique, ça fait un simple étalement min-max quand les stats sont calculées, sinon 0-1000 par défaut je crois.

après, concernant cette issue, on pourrait faire

• proj: systématique (surtout que depuis pystac 1.12.0 les champs pour proj ont changés ! par ex. epsg -> code)
• raster, si pas déjà appliqué
• timestamps avec published = datetime.now()

Par contre, je n'ai pas envie qu'on se retrouve à faire la maintenance de moulte application d'extension, ce n'est pas le job de theia-dumper, mais plutôt de la personne qui crée son catalogue. Si on se met à appliquer tout plein d'extensions, le risque c'est que les gens pensent qu'on le fait à leur place.

Oui je pense que proj et raster sont nécessaires pour l'affichage du cog. Je suis entrain d'étudier ton code dans stacflow (stac.py:StacObjectManager) pour réappliquer les extensions.

mentioned in merge request !19 (merged)

marked this issue as related to #1

@remi.cresson @pablo.boizeau Afin de générer les COG, j'ai dû rajouter une dépendance sur rasterio. Mais rasterio dépend également de GDAL. Du coup la phase de test (https://forgemia.inra.fr/cdos-pub/theia-dumper/-/jobs/1266013) plante car GDAL n'est pas installé sur le runner. Pouvez-vous configurer le runner avec GDAL ?

@loic.lozach rasterio ne dépend plus d'une installation de GDAL (les binaires de GDAL sont inclus dans la wheel de rasterio).

Par contre depuis python3.11 il faut installer libexpat1, tu peux le faire avec apt dans l'image docker des tests

@remi.cresson j'ai un dilemme sur l'architecture de mon code concernant l'application des scales/offsets. Pour le moment, je les appliques aux cog nouvellement créés, mais en cas de non overwrite, ca ne sera pas reporté dans les métadonnées, car j'ai modifié pour générer l'extension raster, sur le fichier source (comme on en a discuté). Donc pour suivre la même logique, il faudrait que j'applique les scales/offsets sur les fichiers sources. Ce qui pose je pense un problème de fournir un code qui modifie le fichier source.

Ceci remet en cause la fonctionnalité scales/offsets, est-ce qu'on l'abandonne pour ne générer que les cog (en temporaire ou en persistence) et charge à l'utilisateur de formater ses données sources comme il veut ?

Oui, tu as raison: il ne faut pas modifier le fichier source.

En principe, lors de la conversion du COG, tout cela est conservé:

• scales
• offsets
• nodatas

Si l'utilisateur n'a pas mis de scale/offset, on n'en met pas.

Moi je suis pour enlever purement et simplement la possiblité de theia-dumper de spécifier scale/offset: c'est à l'utilisateur de le faire en amont sur sa donnée.

Sinon on va se retrouver à "faire son boulot", comme je le craignais (cf #14 (comment 383208)):

Par contre, je n'ai pas envie qu'on se retrouve à faire la maintenance de moulte application d'extension, ce n'est pas le job de theia-dumper, mais plutôt de la personne qui crée son catalogue. Si on se met à appliquer tout plein d'extensions, le risque c'est que les gens pensent qu'on le fait à leur place.

Ok c'est parti!

mentioned in commit d38fd53f

closed with merge request !19 (merged)