@Gaetanbrl 👍

@hsquividant prêt pour revue -test / merge.

Merci @Gaetanbrl !
Retour sur ces derniers commit :

• Bug : Le paramètre de config "top" s'applique bien aux objets géographiques mais ne s'applique plus aux observations. Ca fonctionnait dans la version n-1. A priori ça re-fonctionne en remplaçant la ligne 168 de sensorFeature.js par :
  this.config.top ? ?$top=${this.config.top} : ""
  Idem à la ligne 178 pour les multidatastreams.
• Bug : Quand plusieurs Things sont superposées, rien ne s'affiche. C'est le cas pour le service Lora de Rennes Métropôle dont nous avons actualisé les coordonnées géo.
• Evolution : La légende s'ouvre bien à la sélection d'une Thing, par contre la fonction de scrolling dans la liste des datastreams n'est pas encore opérationnelle ou développée. Utile quand le nombre de datastreams ratachés à une Thing est important. ex : https://geosas.fr/mviewer-test/?config=/apps/brgm/brgm.xml
• Evolution : Pour éviter d'avoir à créer un template spécifique pour chaque service ST, il serait utile d'en créer un générique (ex: sensor.mst) intégrant un layer.id générique (ex: sensor ou sensorthings).

Merci pour les tests @hsquividant , quand tu parles de la version n-1, tu veux dire à quelle date que je me repère ?

@hsquividant je viens de tester :

Avec GeoSAS, si on clic sur 2 features c'est un peu long mais on a bien les 2 résultats.

Avec LORA j'ai une erreur dans la console, aucune feature ne fonctionne.

Il semble que ce cas de test ne soit pas encore connu :

• Avoir plusieurs features de nom de MultiDatastreams différents (Lora ST1_25, Lora ST1_50, Lora ST1_75) à une même coordonnées
• Clic sur la coordonnées

@hsquividant je ne sais pas quoi afficher dans le custom control et dans le template pour ces types de données (MultiDatastream) qui sont complètements différents des Datastreams.

J'ai trouvé pourquoi on ne voit rien et ajouté un correctif :

Lorsqu'on a plusieurs MultiDatastream, on charge dans le custom control un seul des multidatastream retourné. Donc quand on charge le panel, on a pour notre exemple uniquement une seule feature qui contient des données pour le stream sélectionné (ex: Lora ST1_75).
Les autres features n'ayant pas d'observation pour ce stream, j'avais une erreur non gérée dans le template (bug mineur donc).

Le problème actuel est qu'on ne peut pas choisir un autre des multidatastream parmis les features cliquées aux même coordonnées (parmis notre exemple Lora ST1_25, Lora ST1_50, Lora ST1_75).

Il faudrait donc avoir ce comportement pour les MultiDatastreams :

1. clic sur la coordonnées
2. Récupérer les observations
3. Lister les noms des multidasatreams
4. Charger la liste des noms dans le custom control
5. Afficher la fiche info > seule une des 3 features aura un graphique selon le stream sélectionné par défaut
6. cliquer sur un autre stream
7. recharger le panel > seule une des 3 features aura un graphique selon le stream sélectionné

Vu avec @hsquividant en évolution :

• Utiliser ObservedProperties d'un stream pour afficher la liste du custom control et le vrai nom :

https://sensorthings-wq.brgm-rec.fr/FROST-Server/v1.0/Datastreams(8862231)/ObservedProperty
https://api.geosas.fr/lora/v1.0/MultiDatastreams(1)/ObservedProperties

Pour chaque :

• Clic sur le thing
• Parcourir les streams
• pour chaque streams - Appeler les ObservedProperties (via les requêtes au-dessus) - peupler la liste
• Avoir une liste de valeurs unique des ObservedProperties
• Peupler le custom control avec les valeurs uniques

Attention : la base doit être bien peuplées pour avoir des noms différents et pertinent pour l'utilisateur

Rebase

PR alignée sur la branche develop.

Utiliser ObservedProperties d'un stream pour afficher la liste du custom control et le vrai nom :
Attention : la base doit être bien peuplées pour avoir des noms différents et pertinent pour l'utilisateur

La dernière phrase est encore d'actualité.

Avec le service agri4cast ou geosas LORA, je reproduis bien facilement un cas où la liste des noms uniques est inférieur aux streams récupérés.

Exemple avec GEOSAS et des Datastreams

Je clique sur un objet (things) représenté par un carreau de la couche afin d'obtenir les informations :

https://api.geosas.fr/agri4cast/v1.0/Locations(33)/Things?$select=id,description&$expand=Datastreams($select=name,id),MultiDatastreams($select=name,description,id,unitOfMeasurements)

Jusque là on avait dans la PR actuelle 8 noms différents pour les DataStreams :

En appliquant la méthode du dernier commentaire, on réalise 1 requête ObserverdProperty par stream afin d'avoir le nom avec par exemple pour la temperature min (stream id 251), cette requête qui nous donne le nom "temperature" :

https://api.geosas.fr/agri4cast/v1.0/Datastreams(251)/ObservedProperty

Mais il s'avère que pour ce service, les noms ne sont pas uniques car pour cette location, les streams fournissents une liste de noms uniques suivants (on aura supprimé les valeurs en doublons pour générer cette liste) :

['temperature', 'wind velocity', 'vapour pressure', 'precipitation', 'ETP', 'global radiation']

On voit donc que les 3 temperatures ont le même nom "temperature" pour la partie ObservedProperty.

A voir maintenant pour les MultiDataStreams.

Exemple avec MultiDataStreams LORA

Les locations sont les suivants (12 entités) :
https://api.geosas.fr/lora/v1.0/Locations?$top=200

Si on test l'iot.id 11 pour obtenir les streams avec cette requête :

https://api.geosas.fr/lora/v1.0/Things(11)/MultiDatastreams

On obtiendra 1 seul MultiDatastreams de 3 unités de mesure :

Pour obtenir les noms, j'appel les ObservedProperties :

https://api.geosas.fr/lora/v1.0/MultiDatastreams(11)/ObservedProperties

J'obtiens les noms Battery et Temperature.
Donc on a 2 noms pour le (ST4_75) pour 3 unités de mesure différentes vu ici :

https://api.geosas.fr/lora/v1.0/Things(11)/MultiDatastreams

En l'état pour ce service de multidatastream, on aura seulement 2 noms à rajouter dans le custom control mais 3 types de données. Cette méthode d'appel avec les observedProperties (nom d'ailleurs différent entre datastreams et multidatastreams) me semble donc cohérente seulement avec des données bien saisie en base (c'est à dire 1 dataset du chart = 1 unité de mesure = 1 observedProperty par unité de mesure cliquable dans le custom control comme pour les datastreams).

@hsquividant est-ce correct et est-ce la bonne méthode ?

Cette méthode d'appel avec les observedProperties (nom d'ailleurs différent entre datastreams et multidatastreams) me semble >donc cohérente seulement avec des données bien saisie en base (c'est à dire 1 dataset du chart = 1 unité de mesure = 1 >observedProperty par unité de mesure cliquable dans le custom control comme pour les datastreams).

Pour https://api.geosas.fr/agri4cast/v1.0/ l'observedProperty temperature correspond effectivement à 3 datastreams par thing, il faudra dans ce cas pouvoir mettre dans le plot les trois datastreams si on reste sur l'idée d'@hsquividant.

Une requête de ce type permettra de trouver les bons datastreams (mais ne marche pas sur api.geosas.fr) :
https://geosas.fr/FROST-agri4cast/v1.0/Things(50)/Datastreams?$filter=ObservedProperty/name eq 'temperature'
Un autre exemple : https://sensorthings-wq.brgm-rec.fr/FROST-Server/v1.0/Things(3011)/Datastreams?$filter=ObservedProperty/name eq 'Zinc'
dans cette thing on observe du Zinc (observedProperty) mais avec des origines différentes et chaque datastream correspond a une forme.

Pour les multidatastreams lora n'est pas un bon exemple il ne respecte pas le standard.
https://api.geosas.fr/lora/v1.0/MultiDatastreams(11)/ObservedProperties est une erreur : normalement il y a autant d'observedProperty que de stream et l'ordre des observedProperties doit être le même que celui des streams (tout comme l'ordre des unitOfMeasurements).
Par contre il est possible de rencontrer le même cas de figure que la température d'agri4cast :
multidatastreams [mean,mini,maxi], observedproperties [temperature,temperature,temperature]

Par ailleurs, les observations également ne sont pas standard sur https://api.geosas.fr/lora/v1.0 :
"result": { "Temperature": 2.6, "humidity": 13.592, "Battery": null }
doit être sous cette forme (l'ordre des streams permet de ce repérer) :
"result": [ 2.6, 13.592, "null" ]

Je ne connais pas d'autres services qui proposent des multidatastreams pour que tu puisses faire des tests, quand j'ai le temps je vais en créer un.

Retour de @tom @hsquividant :

On a trouvé un bug dans la partie sensorthing  du mviewer liée au MultiDatastream. Dans le cas où il n'y a pas de MutliDatastream (c'est une option non obligatoire du standard) : le serveur ne renvoie pas cette clé dans le json de réponse et le mviewer ce bloque (le script /js/sensorthings.js).

 
exemple d'un service sans MultiDatastream :
https://api.geosas.fr/bosco/v1.0/Locations(224)/Things?$select=id,name,description&$expand=Datastreams($select=name,description,id,unitOfMeasurement),MultiDatastreams($select=name,description,id,unitOfMeasurements)
exemple d'un service avec MultiDatastreams :
 https://frost.geosas.fr/bosco/v1.0/Locations(224)/Things?$select=id,name,description&$expand=Datastreams($select=name,description,id,unitOfMeasurement),MultiDatastreams($select=name,description,id,unitOfMeasurements)

Suite aux derniers retours du de décembre 2023je propose de :

• créer une issue pour le multidatastream
• corriger les conflits
• merger cette PR
• Corriger l'issue ensuite pour le multidatastream

@hsquividant est-ce que cela te convient ? On aura ainsi une première partie fonctionnelle et native dans le mviewer

la PR a été mise à jour sur la base de la branche develop (latest > v3.10.0)