Template - Visualisation des données

Gaetanbrl commented 7 months ago

Cas d'usage

En tant qu'utilisateur Je souhaite pouvoir voir des informations attributaires et des graphiques, Afin d'avoir une vue statistique et factuelle sur la parcelle sélectionnée

Présentation

Lorsqu'un utilisateur clique sur une parcelle, il est nécessaire d'obtenir au moins ces informations :

Description de la parcelle (id, type de culture via #7 )
Dataviz de "contextualisation statistique" qui permet de superposer la chronique d'un capteur de l'année en cours avec des statistiques de moyennes, variance, min, max préalablement spécifiées

Les statistiques doivent être spécifiées et définies à l'avance par l'équipe projet

En option : Pouvoir afficher pour une année, le type de culture de la parcelle pour cette année (fourni par le RPG via la culture principale déclarée)

Description fonctionnelle

L'utilisateur clique sur une parcelle du RPG et visualise le panel (template) mviewer. Le template associé doit permettre d'afficher ces informations de manière ergonomique.

Description technique

Les statistiques seront fournies par le service API GeoSAS de l'INRAE. Ce service est actuellement interne mais doit être publié pour pouvoir être utilisé.

En entrée, c'est l'ID d'un things qui permettra de récupérer les données utiles au statistiques par le service.

A partir d'une requête indiquant les opérations statistiques à réaliser, Il permettra de :

retourner un HTML contenant le graphique déjà générer
retourner un JSON contenant les série de données à utiliser pour créer un graphique en javascript dans le template (e.g via Plotly)

Il reste à définir comment l'API ou via quel autre service récupérer les informations de la culture principale pour une année donnée (voir avec https://api.gouv.fr/les-api/api_carto_rpg).

Tâches

[x] Accès au service GeoSAS
[ ] Partage à JDev du contenu du graphique et template
[ ] Maquette du template
[ ] Graphique de l'indicateur sur un an superposé avec des statistiques divers (mean, max, min...)
[ ] Représentation du RPG pour chaque année

hsquividant commented 6 months ago

Compte tenu des problèmes de fiabilité, de performance et de méthode de l'API RPG de l'IGN, nous proposons d'utiliser l'API stats-ogc développée et déployée par GéoSAS en version Béta. Cette même API fournira également les données statistiques de l'humidité de surface (mean, max, min).

URL : https://api.geosas.fr/stats-ogc/
Standard : API OGC Processes
API Doc : https://api.geosas.fr/stats-ogc/openapi?f=html

hsquividant commented 6 months ago

Exemple d'utilisation de l'API stats-ogc pour la partie statistique avec une sortie au format HTML :

URL : https://api.geosas.fr/stats-ogc/processes/sta-aggregate/execution
Méthode : POST

Entrée :

{
"inputs": {
"aggregation": "mean",
"echelle": "year",
"format": "html",
"url_sensorthings": "https://frost.geosas.fr/bosco/v1.0/Datastreams(3)",
"year_etude": 2021
}
}

Sortie : https://api.geosas.fr/stats-ogc/static/tmp/240228_164555525004.html

Gaetanbrl commented 6 months ago

Merci @hsquividant c'est en effet plus simple avec un exemple 👍

hsquividant commented 6 months ago

Exemple d'utilisation de l'API stats-ogc pour la partie statistique avec une sortie au format JSON :

URL : https://api.geosas.fr/stats-ogc/processes/sta-aggregate/execution
Méthode : POST

Entrée :

{
"inputs": {
"aggregation": "mean",
"echelle": "year",
"format": "json",
"url_sensorthings": "https://frost.geosas.fr/bosco/v1.0/Datastreams(3)",
"year_etude": 2021
}
}

Sortie :

{
"response": {
"unite": "Percentage",
"mois": [
  1,
  2,
  3,
  4,
  5,
  6,
  7,
  8,
  9,
  10,
  11,
  12
],
"quartile_25": [
  21.5,
  21.9,
  15.4,
  13.6,
  10.7,
  22.8,
  14.7,
  18,
  21.1,
  18.700000000000003,
  22,
  22.6
],
"quartile_75": [
  27.700000000000003,
  28.9,
  24.95,
  23.6,
  27.2,
  28.4,
  26.299999999999997,
  26.2,
  27.4,
  30.1,
  29.6,
  30.4
],
"mediane": [
  22.8,
  24.6,
  22.200000000000003,
  17.8,
  22.8,
  27.8,
  19.5,
  22.8,
  25.6,
  26,
  25.4,
  28.4
],
"mediane_annee_cible": [
  25,
  23,
  24.6,
  15,
  6.8999999999999995,
  6.8,
  18,
  22.6,
  23,
  25.2,
  33
],
"annee cible": 2021,
"date minimum comparaison": 2017,
"date maximum comparaison": 2022,
"datas_name": "Soil moisture, parcel n° 6",
"datas_description": "Humidity of first soil layer (5-10 cm), parcel n° 6"
}
}

hsquividant commented 6 months ago

Exemple d'utilisation de l'API stats-ogc pour la partie RPG, la sortie est au format CoverageJSON (OGC)

URL : https://api.geosas.fr/stats-ogc/processes/edr-aggregate/execution
Méthode : POST

Entrée : il faudra récupérer la géométrie de la parcelle sélectionnée et l'intégrer au JSON

{
"inputs": {
"aggregation": "mode",
"datetime": "2017-01-01/2022-01-01",
"geometry": {
  "crs": {
    "properties": {
      "name": "urn:ogc:def:crs:EPSG::2154"
    },
    "type": "name"
  },
  "features": [
    {
      "geometry": {
        "coordinates": [
          [
            [
              165189.86264997642,
              6799939.058717679
            ],
            [
              165189.86264997642,
              6800198.385465654
            ],
            [
              165371.39137355742,
              6800198.385465654
            ],
            [
              165371.39137355742,
              6799939.058717679
            ],
            [
              165189.86264997642,
              6799939.058717679
            ]
          ]
        ],
        "type": "Polygon"
      },
      "properties": {},
      "type": "Feature"
    }
  ],
  "name": "parcel",
  "type": "FeatureCollection"
},
"url_edr": "https://api.geosas.fr/edr/collections/RPG-Raster"
}
}

Sortie : edr-aggregate.json

Le format CoverageJSON est un peu "tordu" et complexe à interpréter. Je tente une explication...

L'objet "t.values" contient les années du RPG présentes dans la base :

  "t": {"values": [
              "2017-01-01T00-00-00Z",
              "2018-01-01T00-00-00Z",
              "2019-01-01T00-00-00Z",
              "2020-01-01T00-00-00Z",
              "2021-01-01T00-00-00Z",
              "2022-01-01T00-00-00Z"
        ]}

L'objet "ranges.code_groupe.values" contient les codes des cultures des différentes années dans le même ordre que le tableau "t".

 "ranges": {
    "code_groupe": {
      "type": "NdArray",
      "dataType": "float32",
      "axisNames": [
        "t"
      ],
      "shape": [
        5
      ],
      "values": [
        2,
        1,
        2,
        1,
        2,
        1
      ]
    }
  }

L'objet "categoryEncoding" contient l'ID de chaque culture sous la forme d'une URI.

       "categoryEncoding": {
        "http://opendata.inrae.fr/thesaurusINRAE/c_24452": 1,
        "http://opendata.inrae.fr/thesaurusINRAE/c_25193": 2,
        ...
       }

L'objet "parameters.code_groupe.observedProperty.categories.label.fr" contient le nom de la culture, idem pour la couleur avec "preferredColor", utile si on décide d'afficher une légende, le tout étant indexé par le champ "id", identique au 3.


"parameters": {
    "code_groupe": {
      "type": "Parameter",
      "description": "Code du groupe de la culture principale de la parcelle",
      "unit": {
        "label": "Groupe de culture",
        "symbol": {
          "type": "",
          "value": ""
        }
      },
      "observedProperty": {
        "categories": [
          {
            "description": {
              "fr": "Groupe de culture du blé tendre du Registre Parcellaire Graphique"
            },
            "id": "http://opendata.inrae.fr/thesaurusINRAE/c_24452",
            "label": {
              "en": "Soft wheat",
              "fr": "Blé tendre"
            },
            "preferredColor": "#ffff90"
          },
          {
            "description": {
              "fr": "Groupe de culture du maïs grain et ensilage du Registre Parcellaire Graphique"
            },
            "id": "http://opendata.inrae.fr/thesaurusINRAE/c_25193",
            "label": {
              "en": "Corn",
              "fr": "Maïs grain et ensilage"
            },
            "preferredColor": "#00ff00"
          },
         ...


Pour notre parcelle, ça donnerait : 
| Année | Culture | Couleur |
| --- | --- | --- |
| 2017 | Maïs grain et ensilage | #00ff00 |
| 2018 | Blé tendre | #ffff90 |
| 2019 | Maïs grain et ensilage | #00ff00 |
| 2020 | Blé tendre | #ffff90 |
| 2021 | Maïs grain et ensilage | #00ff00 |
| 2022 | Blé tendre | #ffff90 |

Voili, voilà, mais est-ce bien clair que tout cela ?!

Gaetanbrl commented 6 months ago

Voili, voilà, mais est-ce bien clair que tout cela ?!

Merci pour ces compléments, je prend connaissance des détails et je te redis

Gaetanbrl commented 6 months ago

Voili, voilà, mais est-ce bien clair que tout cela ?!

Ca me semble relativement clair. J'ai testé l'appel avec postman et je vois bien un retour. Le JSON a envoyé n'est pas super pratique à faire mais ce n'est pas forcément compliqué.

Si j'ai bien compris, en l'état à partir de la réponse d'appel, pour obtenir ton tableau, il faut suivre ces étapes :

Appel POST
Lecture JSON
Lecture des années disponibles via <Array> response.domain.axes.t
Lecture des numéros de type de culture (en suivant l'ordre / index des années) via <Array>response.range.code_group.values
Lecture de l'URL derrière le numéro de type de culture via <Array>response.parameters.code_categoryEncoding
Lecture des infos à afficher sur la culture via une recherche par URL de type de culture dans <Array>response.parameters.observedProperty.categories

Dans l'idée, il serait donc bien de traiter le retour afin d'avoir un objet qui dispose des infos comme dans le tableau :


{
  cultures: [{
      year: string,
      id: string,
      type: number,
      color: string,
      description: {
        fr: string,
        en: string
      },
      label: {
        fr: string,
        label: string
      }
    }
  }]
}

Gaetanbrl commented 6 months ago

Je pense que pour la partie interrogation du service stats-ogc dans ce mviewer, un plugin serait la bonne solution pour éviter d'avoir un code spécifique dans mviewer (qui serait dans tous les cas refusé) et pour éviter d'avoir un template mustache trop lourd.

t-loree commented 6 months ago

Oui ça serait une bonne idée vu que le service stats-ogc utilise un standard OGC : API OGC Processes

Gaetanbrl commented 2 months ago

Sujet couvert face au besoin. Des issues seront ré ouvertes selon les anomalies ou évolutions. Je clos ce ticket.

geosas / bosco