Tests traitement dans geoplateforme#

Ce chapitre décrit les différentes étapes nécessaires sur la géoplateforme pour :

  • l’intégration du traitement

  • l’intégration de données pour l’utilisation du traitement

  • l’execution du traitement

Intégraton du traitement#

Si le traitement n’est pas disponible dans le datastore, il est nécessaire de l’ajouter via l’API d’administration puis dans un second temps dans le datastore.

Les chapitres suivants précisent les commandes à envoyer.

Des scripts bash utilisant curl sont en cours de développement pour une intégration via script.

Les scripts doivent être édités pour définir au minimum la variable suivante :

  • API_KEY: clé utilisé pour l’authentification

Les autres variables sont définies avec des valeurs par défaut pour l’utilisation de la sandbox oslandia. Il est nécessaire de les modifier pour l’utilisation d’un autre environnement.

  • BASE_URL : url de l’entrepot pour l’environnement à tester

  • DATASTORE_ID : id de la datastore à utiliser

Ajout traitement dans l’administration#

POST {{baseUrl}}/administrator/processings

Un fichier .json contenant les paramètres de la requête POST est disponible dans le répertoire gitlab orchestrator/processing-creation.json

En retour on peut récupérer l’identifiant du processing créer, que l’on nomme processing-id pour les étapes suivantes.

Cette étape peut être effectuée automatiquement avec le script bash orchestrator/processing_creation.sh

Ajout traitement dans datastore#

Récupération processing déjà présent#

GET {{baseUrl}}/administrator/datastores/:datastore

On récupère la liste des processings déjà présents:

"processings": [
        "af042611-13eb-4a18-8d04-9b7604a031cc",
        "af052611-13eb-4a18-8d04-9b7604a031cc",
        "af062611-13eb-4a18-8d04-9b7604a031cc",
        "af012611-13eb-4a18-8d04-9b7604a031cc",
        "af022611-13eb-4a18-8d04-9b7604a031cc"
    ]

Modification datastore#

On va patcher le datastore pour lui ajouter le nouveau processing.

Note

Il faut absolument avoir récupérer les processings déjà présents ou ils ne seront plus disponible pour le datastore.

PATCH {{baseUrl}}/administrator/datastores/:datastore

En paramètre, on indique la liste des processings déjà présent plus le nouveau processing à intégrer:

"processings": [
        "af042611-13eb-4a18-8d04-9b7604a031cc",
        "af052611-13eb-4a18-8d04-9b7604a031cc",
        "af062611-13eb-4a18-8d04-9b7604a031cc",
        "af012611-13eb-4a18-8d04-9b7604a031cc",
        "af022611-13eb-4a18-8d04-9b7604a031cc",
        "{{processing-id}}"
    ]

Intégration de données pour l’utilisation du traitement#

Le traitement prend en entrée une stored data de type VECTOR-DB contenant une base BDTOPO.

Si aucune base BDTOPO n’est disponible, il faut l’ajouter dans le datastore via les étapes suivantes :

  • Intégration d’une livraison dans l’entrepot

  • Intégration de la livraison en tant que stored data VECTOR-DB

Intégration d’une livraison dans l’entrepot#

Création d’une livraison#

Via Postman on créé une livraison de type VECTOR.

POST {{baseUrl}}/datastores/:datastore/uploads

{
  "description": "vector_montfort_bdtopo",
  "name": "vector_montfort_bdtopo",
  "srs": "EPSG:4326",
  "type": "VECTOR",
  "type_infos": {
  }
}

En retour on va pouvoir récupérer l’identification de la livraison upload-id, qui doit être utilisé pour les requêtes suivantes.

Téléversement de données#

POST {{baseUrl}}/datastores/:datastore/uploads/:upload/data

Dans le Body de la requête, sélectionner le chemin vers le fichier à téléverser:

Selection fichier dans POSTMAN

Fermeture de la livraison#

POST {{baseUrl}}/datastores/:datastore/uploads/:upload/close

Les vérifications sur la livraison sont lancées et la données sera utilisable sur toutes les vérifications sont OK.

Intégration de la livraison en tant que stored data de type VECTOR-DB#

Récupération du traitement vector2db#

GET {{baseUrl}}/datastores/:datastore/processings

On va utiliser l’identifiant du processing vector2db, que l’on nomme processing-id pour la suite.

Création d’une exécution du traitement vector2db#

POST {{baseUrl}}/datastores/:datastore/processings/executions

En paramètre on doit indiquer :

  • le processing utilisé

  • les inputs

  • le nom de la données en sortie

On utilisera le processing sans paramètre spécifique:

{
  "processing": "{{processing-id}}",
  "inputs": {
    "upload": ["{{upload-id}}"],
    "stored_data": []
  },
  "output":{
      "stored_data" : {
          "name" : "vectordb_montfort_bdtopo"
      }
  },
  "parameters":{
  }
}

Voici un exemple du retour de l’API:

{
    "processing": {
        "name": "vector2db",
        "_id": "af012611-13eb-4a18-8d04-9b7604a031cc"
    },
    "status": "CREATED",
    "creation": "2023-06-01T08:09:42.924373900Z",
    "inputs": {
        "upload": [
            {
                "type": "VECTOR",
                "name": "vector_montfort_bdtopo",
                "status": "CLOSED",
                "srs": "EPSG:4326",
                "_id": "629c3e29-c1aa-490e-b915-ce9aadbda3b1"
            }
        ],
        "stored_data": []
    },
    "output": {
        "stored_data": {
            "name": "vectordb_montfort_bdtopo",
            "type": "VECTOR-DB",
            "status": "CREATED",
            "_id": "af1deed5-b61c-4539-b13a-d8e666f30d19"
        }
    },
    "parameters": {},
    "_id": "9abdfedf-18f1-462e-9cda-bf2ef6723925"
}

En retour on va pouvoir récupérer l’identification de l’exécution execution-id dans l’atribut _id, qui doit être utilisé pour les requêtes suivantes. On récupère aussi l’identifiant de la stored data qui sera créé après l’execution ["output"]["stored_data"]["_id"].

Il s’agit de l’identifiant de la stored data en entrée du processing de création de base pivot Road2. Il est nommé stored-data-id dans la suite du document.

Lancement exécution vector2db#

POST {{baseUrl}}/datastores/:datastore/processings/executions/:execution/launch

On indique execution-id dans les variables de chemin pour execution.

A la fin de l’exécution, une stored data de type VECTOR-DB est disponible pour utilisation dans le processing de création de base pivot road2 : vector-db-to-pivot-road2.

Execution du traitement#

Récupération du traitement vector-db-to-pivot-road2#

GET {{baseUrl}}/datastores/:datastore/processings

On va utiliser l’identifiant du processing vector-db-to-pivot-road2, que l’on nomme processing-id pour la suite.

Création d’une exécution du traitement vector-db-to-pivot-road2#

POST {{baseUrl}}/datastores/:datastore/processings/executions

En paramètre on doit indiquer :

  • le processing utilisé

  • les inputs

  • le nom de la données en sortie

On utilisera le processing sans paramètre spécifique, on indique pas de script de conversion ou de bounding box pour la génération:

{
  "processing": "{{processing-id}}",
  "inputs": {
    "upload": [],
    "stored_data": ["{{stored-data-id}}"]
  },
  "output":{
      "stored_data" : {
          "name" : "pivot_montfort_bdtopo"
      }
  },
  "parameters":{
  }
}

Voici un exemple du retour de l’API:

{
    "processing": {
        "name": "vector-db-to-pivot-road2",
        "_id": "d5021fce-ce5e-4270-9679-d9fb66a872d8"
    },
    "status": "CREATED",
    "creation": "2023-06-01T08:32:31.567423959Z",
    "inputs": {
        "upload": [],
        "stored_data": [
            {
                "name": "vectordb_montfort_bdtopo",
                "type": "VECTOR-DB",
                "status": "GENERATED",
                "srs": "EPSG:4326",
                "_id": "af1deed5-b61c-4539-b13a-d8e666f30d19"
            }
        ]
    },
    "output": {
        "stored_data": {
            "name": "pivot_montfort_bdtopo",
            "type": "VECTOR-DB",
            "status": "CREATED",
            "_id": "9a97d4b4-ce22-4516-8fed-c9ce4c8624a0"
        }
    },
    "parameters": {
        "bbox": {
            "west": -180,
            "east": 180,
            "south": -90,
            "north": 90
        },
        "conversion": {
            "name": "bdtopo_v3.3"
        }
    },
    "_id": "b3a56724-1d50-443d-bcdd-253b70233dbf"
}

En retour on va pouvoir récupérer l’identification de l’exécution execution-id dans l’atribut _id, qui doit être utilisé pour les requêtes suivantes. On récupère aussi l’identifiant de la stored data qui sera créé après l’execution ["output"]["stored_data"]["_id"].

Il s’agit de l’identifiant de la stored data en sortie du processing de création de base pivot Road2.

Lancement execution vector-db-to-pivot-road2#

POST {{baseUrl}}/datastores/:datastore/processings/executions/:execution/launch

On indique execution-id dans les variables de chemin pour execution.

Le traitement est lancée dans l’entrepot et si la données en entrée est compatible avec le script de conversion, la base de données pivot Road2 est disponible dans l’entrepot en tant que stored data de type VECTOR-DB