Rendre les traitements compatibles avec le visualiseur carte.gouv

[LudivineSchlegel]

Contexte

cartes.gouv.fr est le portail principal d'accès à la Géoplateforme, son entrepôt et son catalogue.

Il prend la suite de la préfiguration que constitue le Géotuileur en étendant ses possibilités d'alimentation aux données vecteur et raster et ses possibilités de diffusion à d'autres flux que les seules tuiles vectorielles.

cartes.gouv.fr d’appuis sur les tag/label sur les entités pour retrouver la source des données, le traitement l'ayant créer, la donnée dérivé ...

Demande

Possibilité de rendre compatible l'utilisation du SDK avec cartes.gouv.fr sans à avoir à ajouté à la main les tags nécessaire.

La compatibilité avec cartes.gouv.fr ne sera pas obligatoire elle sera activée à la demande de l'utilisateur

Développement

activation de la compatibilité

Plusieurs moyen d'activer la compatibilité :

• dans la ligne de commande (--compatibility-cartes)
• dans la configuration (section compatibility_cartes option activate)
• dans le workflow (clef compatibility_cartes à la base du workflow)

action upload / téléversement de fichiers

Correspond à la ligne de commande : python -m sdk_entrepot_gpf upload --file upload_descriptor.json

• tag à ajouter à l'Upload lors de sa création :

  • datasheet_name : nom de la fiche de donnée (information donnée par l'utilisateur, vérifier qu'elle est dans la liste des tags à ajouter)
  • data_upload_path : chemin vers le fichier téléversé (non géré par le SDK)
  • integration_progress : {"send_files_api": "waiting", "wait_checks": "waiting","integration_processing": "waiting"} (valeur à ajouter en dur)
  • integration_current_step : 0 (valeur à ajouter en dur)

• tag à ajouter/modifier lors du début du téléversement des fichiers

  • integration_progress : {"send_files_api": "in_progress", "wait_checks": "waiting","integration_processing": "waiting"} (valeur à ajouter en dur)

• tag à ajouter lors de la fin de téléversement des fichiers + fermeture de l'upload

  • integration_progress : {"send_files_api": "successful", "wait_checks": "in_progress","integration_processing": "waiting"} (valeur à ajouter en dur)
  • integration_current_step : 1 (valeur à ajouter en dur)

• tag à ajouter lors de la fin des vérifications (à adapter si les tests sont bon ou non)

  • integration_progress : {"send_files_api": "successful", "wait_checks": "(successful|failed)","integration_processing": "waiting"} (deux valeurs à ajouter en dur et récupération de la bonne)

Il faudra faire des modifications dans la classe UploadAction fonction run ou sous-fonctions.

action de workflow de type processing-execution

• Tag à ajouter lors de la création d'une processing execution :

  • sur l'upload en entrée
  • integration_progress : {"send_files_api": "successful", "wait_checks": "successful","integration_processing": "in_progress"} (valeur à ajouter en dur)
  • integration_current_step : 2 (valeur à ajouter en dur)
  • proc_int_id : {uuid_processing_execution} (valeur à récupérer : id du processing-execution créé)
  • vectordb_id: {uuid_stored_data_sortie} (valeur à récupérer : id de la stored_data créée)
  • sur la stored_data en entrée
  • aucun tag spécifique
  • sur la stored_data en sortie
  • datasheet_name: nom de la fiche de donnée (information données par l'utilisateur, vérifier qu'elle est dans la liste des tags à ajouter)
  • si stored_data du type VECTOR-DB
    • upload_id: {uuid_upload} (valeur à récupérer : id de la livraison en entrée)
    • proc_int_id: {uuid_processing_execution} (valeur à récupérer : id du processing-execution créé)
  • si stored_data du type ROK4-PYRAMID-VECTOR
    • proc_pyr_creat_id : {uuid_processing_execution} (valeur à récupérer : id du processing-execution créé)
    • vectordb_id : {uuid_stored_data_entree} (valeur à récupérer : id de la stored_data en entrée)
    • is_sample: true ou false : non géré par le SDK.

• tag à rajouter en fin de traitement

  • sur l'upload en entrée (à adapter si les tests sont bon ou non)
  • integration_progress : {"send_files_api": "successful", "wait_checks": "successful","integration_processing": "(successful|failed)"} (deux valeurs à ajouter en dur et récupération de la bonne)

Il faut faire les modifications dans ProcessingExecutionAction (fonction run et sous-fonctions).

action de workflow de type configuration

• ajoute de tag à la création de la configuration :
  • datasheet_name : idem
  • styles : non géré par le SDK

Il faut faire les modifications dans ConfigurationAction (fonction run et sous-fonctions).

Configuration

[compatibility_cartes]
activate=false
upload_creation_integration_progress
upload_creation_integration_current_step
upload_upload_start_integration_progress
upload_upload_end_integration_progress
upload_upload_end_integration_current_step
upload_check_ok_integration_progress
upload_check_ko_integration_progress
execution_start_integration_progress
execution_start_integration_current_step
execution_end_ok_integration_progress
execution_end_ko_integration_progress

[LudivineSchlegel]

@vsasyan-ignf @slafayIGN pouvez vous vérifier ce ticket et le compléter si besoin.

J'ai repris la documentation mais je peux avoir oublier des tag à ajouté.

J'ai notamment des question :

• datasheet_name nom de la fiche de donnée quel est la valeur attendu ?
• data_upload_path chemin vers le fichier téléversé quel est la valeur attendu ? (mis à jour à chaque téléversement de fichier fait ? )
• is_sample comment on sais si c'est un un échantillon ou non ? (sous la responsabilité de l'utilisateur dans le workflow, par défaut à false ?)
• styles comment on passe de la configuration à ce JSON ? valable pour toute les configuration

[ocruze]

Bonjour,

• datasheet_name : sur cartes.gouv.fr, on a une entité imaginaire qui s'appelle la fiche de données qui regroupe des uploads, des stored_data, des config/offering etc. datasheet_name est le nom de cette fiche de données qui est unique dans un datastore.
• data_upload_path : c'est un tag temporaire qui correspond au chemin du fichier téléversé sur le serveur de cartes.gouv.fr. Il n'apparaît pas sur les interfaces. Vous n'en avez probablement pas besoin.
• is_sample : tag optionnel. On le met à "true" quand on exécute le traitement "Calcul de pyramide vecteur" avec le paramètre optionnel area, çàd quand l'utilisateur veut créer la pyramide vecteur sur une zone délimitée.
• styles : notre doc sur ce point était un peu datée. Je viens de la mettre à jour. Finalement, ce n'est pas un json dans un tag de la configuration, mais un annexe à part parce que le contenu est trop grand pour être stocké dans un tag (limité 99 caractères) : https://github.com/IGNF/cartes.gouv.fr/blob/main/docs/developer/entrepot/annexes.md. Mais ce tag est optionnel. Est-ce que vous gérez les fichiers de style ? Si non, vous avez pas besoin de mettre ce tag.

Le reste m'a l'air bon.

[vsasyan-ignf]

Bonjour,

Merci pour les précisions.

La fiche de données est en fait le point d'entrée pour votre application, non ? Je veux dire que c'est ça qui permet à l'utilisateur de retrouver les traitements et les données qu'il manipule.

On va effectivement pas implémenté le data_upload_path et les 3 autres seront sûrement à gérer directement par l'utilisateur car assez spécifiques.

[ocruze]

La fiche de données est en fait le point d'entrée pour votre application, non ?

La fiche de données est un peu comme un dossier qui réunit les uploads, stored_data, config/offering etc. Toutes ces entités sont liées à cette fiche de données par le tag datasheet_name. La création d'une fiche de données débute par l'upload d'un fichier et la création d'une stored_data correspondante.

[LudivineSchlegel]

merci @ocruze

Donc pour résumer :

• datasheet_name : obligatoire mais à gérer par l'utilisateur => on test si il est bien présent
• data_upload_path : on ne gère pas ce tag
• is_sample : on ne gère pas ce tag
• styles : n'est plus utilisé.

Pour le style en annexe j'ai toujours la question du passage de la configuration à ce fichier json. On fait du wmts-tms donc oui on à des fichiers de style à gérer

J'en déduis le style en annexe est uniquement pour les types ayant un style :

• wmts-tms
• wms-vecteur
• wms-raster

(je ne vois pas de style avec le WFS contrairement à la doc pour les style en annexe)

Quel serait le fichier annexe pour les exemple suivants :

WMS-vecteur : (cliquer pour développer/réduite)

```json "used_data": [ { "relations": [ { "name": "transport_par_cable", "style": "uuid_style_1" }, { "name": "voie_ferree_nommee", "style": "uuid_style_2" }, { "name": "equipement_de_transport", "style": "uuid_style_3" }, { "name": "equipement_de_transport", "style": "uuid_style_4" }, { "name": "troncon_de_voie_ferree", "style": "uuid_style_5" } ], "stored_data": "uuid_stored_data_a" }, { "relations": [ { "name": "transport_par_cable", "style": "uuid_style_1" }, { "name": "voie_ferree_nommee", "style": "uuid_style_2" }, { "name": "equipement_de_transport", "style": "uuid_style_3" }, { "name": "equipement_de_transport", "style": "uuid_style_4" }, { "name": "troncon_de_voie_ferree", "style": "uuid_style_5" } ], "stored_data": "uuid_stored_data_b" } ], ```

WMS-raster : (cliquer pour développer/réduite)

```json "styles": [ "uuid_style_1", "uuid_style_2" ], "used_data": [ { "bottom_level": "16", "top_level": "6", "stored_data": "uuid_stored_data_a" }, { "bottom_level": "16", "top_level": "6", "stored_data": "uuid_stored_data_b" } ], ```

WMTS-TMS : (cliquer pour développer/réduite)

```json "styles": [ "uuid_style_1", "uuid_style_2" ], "used_data": [ { "bottom_level": "16", "top_level": "6", "stored_data": "uuid_stored_data_a" }, { "bottom_level": "16", "top_level": "6", "stored_data": "uuid_stored_data_b" } ], ```

[ocruze]

(je ne vois pas de style avec le WFS contrairement à la doc pour les style en annexe)

En fait, on stocke uniquement les styles en annexe qu'on applique côté front. Pour un WFS, il n'y a pas de style au moment de la création de la config, mais pour afficher le flux dans une page web, il faut bien appliquer un style. Donc, c'est dans nos interfaces qu'on permet aux utilisateurs de téléverser des fichiers de styles et ensuite on les stocke en annexe.

Sinon pour la structure,

sur cartes.gouv.fr, pour l'instant on ne fait pas du WMS-RASTER et j'ai jamais manipulé un flux WMS-RASTER donc je ne sais pas trop quoi te dire. Pour WMS-VECTOR, on envoie les fichiers de style non en annexe mais en statique lors de la création de la configuration. Donc il y a rien à faire avec les annexes.

Pour WMTS-TMS, il y a une seule couche, donc la structure json ne dépend pas des relations de la stored_data. C'est un style pour toute la stored_data :

[
    {
        "name": "nom du style",
        "current": true,
        "layers": [
            {
                "annexe_id": "24959eb0-ac20-476a-bc25-2a2e841aa467", <-- annexe qui contient le style mapbox
                "url": "https:\/\/gpf-annex-qua.priv.geopf.fr\/annexes\/cartes-gouv-dev\/style\/63f26133-dffe-4d85-a7b1-3e5cd6b9eaa9.json"
            }
        ]
    },
    {...}
]

Je suis peut-être pas super clair à l'écrit, donc n'hésite pas à me contacter sur Teams, en appel ce sera plus pratique

[vsasyan-ignf]

@LudivineSchlegel fait la modification de ProcesingExecutionAction et @dockingtips fait la modification de UploadAction.