Perte des couleurs de taxons et du filtre ad hoc en 2.7.0

[xavyeah39]

Version de l'application

Version d'Occtax-mobile affectée par le bug : 2.7.0
Version de GeoNature utilisée : 2.14.2
Version de Taxhub utilisée : 1.14.1

Description du bug et comportement attendu

Je viens de tester la màj en 2.7.0.
Malgré le fait que le paramètre code_area_type soit bien renseigné dans settings.json et le fait que la synchro s'effectue sans problème en récupèrant bien les unités géographiques, les couleurs des taxons et le filtre ad hoc ("selon la durée d'observation") ne sont plus présents dans l'appli à l'étape de saisie du taxon.

J'ia rétrogradé ensuite en 2.6.2 (en supprimant cache et données au préalable) et là, ça refonctionne bien.
Semble donc bien lié aux évolutions de la 2.7.0.

Merci de vos retours !

[camillemonchicourt]

OK, à creuser car on a tout testé avant de sortir la 2.7.0 dont les couleurs de taxons et cela fonctionnait.

[sgrimault]

Bonjour @xavyeah39,
Serait il possible de partager les unités géographiques en question (fichier geojson) ?

[xavyeah39]

Bien sûr @sgrimault !
Voici le fichier geojson.
Merci,

[sgrimault]

@xavyeah39,

Pour ma part le fichier geojson est correcte. Pourrais-je avoir les logs qui trace le scénario suivant :

• démarrer un nouveau relevé
• sur la carte, afficher les unités géographiques et placer le marqueur sur une unité géographique pour la "sélectionner"
• arriver à l'étape du choix des taxons
• arrêter la saisie et récupérer le fichier de log correspondant

[xavyeah39]

Du coup j'ai refais la manip et je comprend d'où vient le soucis :
Après la mises à jour en 2.7, les fonds de cartes et les mailles ne sont plus cochés à l'étape carte.
Lors de mes précédents tests, j'ai surement coché seulement un fond de carte mais sans vérifier que la couches des mailles était visible/cochée avant de localiser l'observation et de passer à l'étape des taxons.

Du coup, si on s'assure que la couche des mailles est bien visible lors de la saisie sur la carte, la coloration des taxons et le filtre ad-hoc fonctionne !

Ne serait'il pas judicieux que la fonctionnalité de coloration des taxons soit décorrelée de l'affichage et gérer seulement par la présence du paramètre "code_area_type" (couche visible ou pas) ?
Ou bien permettre de configurer les couches actives/visibles par défaut dans les paramètres layers du fichier settings.json ?

Merci et désolé pour le dérangement donc...

[camillemonchicourt]

Oula oui, ce n'est pas normal ça.
Les couleurs de taxons devraient être remontés dans tous les cas dans la liste des taxons, peu importe si la couche est affichée ou non dans l'étape précédente de la carte.

[camillemonchicourt]

Et oui, les couches additionnelles, notamment celle des unités géographiques devrait s'afficher par défaut à chaque fois.
Éventuellement pouvoir le préciser dans la doc, mais ça devrait être le comportement de base.

[gildeluermoz]

Je n'ai pas le temps de tester mais il me semble que le comportement que décrit @xavyeah39 n'est pas nouveau sur la 2.7.0. De mémoire (floue), il me semble que c'était aussi le cas sur les versions précédentes. A tester.

[DonovanMaillard]

Comme Gil, ça me rappelle quelque chose sur la 2.6...

Pour les couches additionnelles, je ne pense pas qu'il faille tout afficher. Dans un certain nombre de cas ce n'est pas souhaitable (on a les znieff, les reserves, les rnr etc chez nous qu'on affiche ou non selon nos prestations). Mais on peut imagine un paramètre dans la conf de chaque couche pour choisir de la masque ou non par défaut, ca serait le plus générique/simple.

[sgrimault]

Pour afficher les "couleurs" des taxons, il faut au préalable charger la couche des unités géographiques puis poser un marqueur de position sur une géométrie (polygone) de cette couche dont son identifiant sert de "filtre" afin de remonter les données relatives (les "couleurs") des taxons correspondant.
Ce fonctionnement a toujours été ainsi, c'est à partir d'une géométrie de la couche sélectionnée (poser un marqueur dessus, marque cette sélection) que l'on peut récupérer les "couleurs" des taxons.

Après, pour faciliter la saisie, on pourrait ajouter une option au niveau des couches pour indiquer si on souhaite que cette couche soit affichée ou non par défaut.

[camillemonchicourt]

OK OK, je n'ai pas souvenir qu'il fallait aller afficher manuellement la couche des unités géographiques à chaque fois dans les premières versions.
C'est sur que si c'est le cas désormais, de nombreux utilisateurs passent à côté des couleurs de taxons...

Il faudrait dans ce cas vraiment pouvoir l'afficher toujours par défaut, sinon la fonctionnalité de couleurs de taxons perd pas mal de son intérêt.

Merci pour ces précisions.

[DonovanMaillard]

Je ne sais pas s'il suffit d'afficher par défaut la couche qui est liée aux couleurs.

Je serais d'avis à vraiment dissocier les deux :

• D'un coté, on a une couche qui sert aux couleurs (déjà défini dans la conf), avec laquelle on fera les intersections dans tous les cas, affichée ou non. On récupère et on affiche la couleur en question.
• De l'autre, on choisit d'afficher ou non telle et telle couche sur la carto au moment de la saisie.

Le fait de devoir faire apparaitre les mailles sur un écran (étape carte) pour ensuite avoir une info sur un autre écran (choix du taxon) n'est pas très intuitif :/

Je n'ai pas souvenir qu'il fallait sélectionner à la main la couche d'intersection pour avoir les couleurs sur les "vieilles" versions, on faisait la saisie avec les unités géographiques affichées dans tous les cas et les couleurs associées.

[gildeluermoz]

Je dirais qu'il faut décoreller 2 sujets qui me semble être différents à propos de la couche qui sert pour le calcul des couleurs :

• afficher la couche
• utiliser telle ou telle couche

Il n'est pas forcement souhaitable / utile que cette couche soit affichée pour être utilisée. On voit bien que ça crée de la confusion, y compris chez les administrateurs GN les plus expérimentés :). Par contre, à partir du moment où la fonctionnalité de coloration des taxons est utilisée, il faut que l'appli connaisse la couche à utiliser (qu'elle soit affichée ou pas).

Comme il y a aujourd'hui un paramètre code_area_type qui désigne coté BDD dans le ref_geo la couche utilisée pour cette fonctionnalité, je propose un paramètre "area_layer_name" (ou autre) qui désigne la couche embarquée que l'appli doit utiliser.
Ensuite qu'on affiche cette couche ou pas, qu'on affiche telle ou telle autre couche en même temps ou pas, ne devrait pas interférer avec la fonctionnalité de coloration des taxons. L'appli utilise dans tous les contextes la couche désignée par le paramètre "area_layer_name". Si ce param est absent ou si la couche qu'il désigne n'est pas présent sur le terminal, la fonctionnalité n'est pas activé.

[camillemonchicourt]

Oui d'accord avec @DonovanMaillard.
Dans tous les cas, pour moi il faut clairement distinguer la couche vecteur des unités géographiques, des couches additionnelles qu'on veut proposer en affichage pour info.

Elles n'ont pas le même rôle et on n'attend pas la même chose de ces couches.

• Pour la couche des unités géographiques, il nous faut un id_area dans la couche collant à celui renvoyé par GeoNature. On veut l'utiliser dans tous les cas si elle est existe pour renvoyer les couleurs de taxons.
• Pour les autres couches, on veut uniquement les afficher sur la carte (affichée ou non par défaut), on n'a pas besoin qu'elles contiennent de données attributaire

Donc il faudrait certainement ajouter dans la conf des couches vecteurs :

• un paramètre "geographical_unities: true/false"
• un paramètre "default_display: true/false"

[gildeluermoz]

Pour aller plus loin dans de future version, on pourrait imaginer un simple paramètre d'activation true/false de cette fonctionnalité et une route dans GeoNature qui sert la couche en Geojson lors de la synchronisation. Il n'y aurait ainsi plus besoin de la préparer avec les bons id correspondants aux id_area de la couche dans le ref_geo, plus besoin de la charger manuellement sur le terminal, de la nommer et de l'identifier, plus de confusion pour les utilisateurs qui peuvent ne pas avoir le bon comportement pour bénéficier de la fonctionnalité. Plus besoin non plus des param code_area_type, area_observation_duration, c'est GeoNature qui défini ça et l'appli utilise ce qui est servi par l'API de GN.
Aujourdhui code_area_type et area_observation_duration peut être différent de ce qui est calculé par la vue dédiée dans GN.

[gildeluermoz]

un paramètre "geographical_unities: true/false"

Il y a trop de risque de mettre 2 couches à true avec ce mécanisme. Je sortirais la désignation de la couche à utiliser de la section "layer", voir de la section "map" car cette fonctionnalité, comme le dit Donovan, se manifeste lors de l'affichage des taxons et n'intervient pas dans le comportement de la carte.

un paramètre "default_display: true/false"

Ca oui.

[gildeluermoz]

Bon, globalement tout le monde est d'accord en même temps. C'est bô !

[camillemonchicourt]

OK pour qu'on définisse le nom de la couche utilisée pour les unités géographiques dans le fichier de config de Occtax-mobile, plutôt qu'en faire un paramètre "geographical_unities: true/false" dans les couches additionnelles.

[sgrimault]

Je suis plus d'avis de @gildeluermoz, où si on veut décorréler le filtre des "couleurs" des taxons de l'affichage des unités géographiques, il faudrait que ça soit porté par les APIs de GeoNature. Ainsi les couches vectorielles ne serviront qu'à l'affichage et à rien d'autre (avec éventuellement un paramètre optionnel pour indiquer si on souhaite l'afficher ou non par défaut).

La partie afficher les "couleurs" des taxons fonctionne uniquement avec les données issues de GeoNature (les données géographiques pour le calcul de l'intersection à partir du marqueur de position) avec les identifiants des géométries pour appliquer le filtre par "couleur".

[camillemonchicourt]

OK tout passer par l'API de GeoNature, je vois pas bien ce que cela impliquerait.
On pourrait carrément imaginer que quand on localise une obs sur la carte, ça interroge dynamiquement l'API de GeoNature et en lui envoyant le XY et que celle-ci renvoie la couleur des taxons de la zone dynamiquement.
Mais ça voudrait dire que l'on ferait des appels dynamiques à l'API et donc qu'on n'en serait dépendant, ainsi que du réseau, donc les couleurs de taxons ne seraient plus fonctionnelles en hors-ligne. Pourquoi pas, c'est acceptable, mais un gros changement et un gros développement.

Par contre, si il s'agit de récupérer la couche des unités géographiques une seule fois et en interrogeant l'API, alors ça c'est déjà possible, car on dispose du code_area et il suffit alors d'interroger cette route : https://demo.geonature.fr/geonature/api/geo/areas?type_code=M10&format=geojson

---

En tout cas, cela n'explique pas pourquoi précédemment les couleurs de taxons fonctionnaient par défaut, car la couche en question était chargée et affichée par défaut, alors que maintenant elle ne l'est plus et on n'a donc plus de couleurs de taxons, sauf si l'utilisateur va afficher manuellement la couche, ce que très peu font ? Et ça c'est un changement/régression très embêtant.

[sgrimault]

Oui, l'idée est que la synchronisation des données récupère aussi tout ce qui concerne les "couleurs" des taxons, couche des unités géographique comprise. C'est l'application qui fera les calculs d'intersection pour déterminer l'identifiant de la géométrie "sélectionnée" qui servira de filtre pour récupérer les "couleurs" des taxons. C'est déjà fait actuellement mais directement depuis la couche géographique affichée sur la carte.
Et cette route existe déjà pour la couche des unités géographiques (https://demo.geonature.fr/geonature/api/geo/areas?type_code=M10&format=geojson).

Il y a eu des changements sur la gestion et l'affichage des fonds géographiques et le fait que les couches vectorielles ne soient pas affichées par défaut a provoqué cet effet de bord...

Je vais rajouter une option au niveau des couches pour indiquer si on souhaite que celle-ci soit affichée ou non par défaut.

[camillemonchicourt]

OK, oui déjà ajouter ce paramètre serait vraiment important pour retrouver un usage fonctionnel des couleurs de taxons.

[DonovanMaillard]

et une route dans GeoNature qui sert la couche en Geojson lors de la synchronisation

Ca serait une très bonne chose mais il y a des questions à se poser comme on l'a fait pour les taxons. Quand charge-t-on cette couche, à quelle fréquence, juste un différentiel ou un annule et remplace ?

Mais ça voudrait dire que l'on ferait des appels dynamiques à l'API et donc qu'on n'en serait dépendant, ainsi que du réseau, donc les couleurs de taxons ne seraient plus fonctionnelles en hors-ligne.

Je l'avais proposé il y a quelques mois, ça me semblait pas trop mal et Théo je crois avait réagi aussi. Ca impliquerait d'avoir un message explicite pour indiquer qu'on a pas pu récupérer les infos en ligne. On en avait parlé pour le faire au meme titre que les profils, qui pourraient être interrogés en ligne de la même manière. Mais le fait d'avoir les couleurs uniquement en ligne peut être un peu déroutant en particulier quand on travaille sur des zones totalement hors réseau.

A la limite, déjà charger la couche depuis l'API de GN à partir du code du type, ça facilite le déploiement de l'appli, et ca permet un fonctionnement hors ligne qu'on aura peut-être pas sur les profils si on implémente les profils un jour avec un appel dynamique.

Pour la route et le chargement de couches par l'API. (je vais mélanger des sujets, désolé, mais ca s'y prête bien). Il faut :

• Que la couche entités géographiques puisse malgré tout etre affichée ou non, même si à coté de ca elle a été chargée en base depuis l'API et qu'elle sert aux intersections, il faut pouvoir la cocher si on veut
• On peut imaginer aussi un paramètre dans le quel on liste des "types_code" pour que toute couche du référentiel géographique puisse-t-être chargée sans passer par un fichier sur le terminal selon la configuration settings_occtax sur le serveur.
• Il faudra clarifier la synchro de ces infos : a priori le mieux sera de les charger en même temps que les infos liées à la coloration, ca assure aussi l'intégrité entre ces couleurs et la couche géo qui va avec

[gildeluermoz]

Par contre, si il s'agit de récupérer la couche des unités géographiques une seule fois et en interrogeant l'API, alors ça c'est déjà possible, car on dispose du code_area et il suffit alors d'interroger cette route : https://demo.geonature.fr/geonature/api/geo/areas?type_code=M10&format=geojson

En faisant un petit tour technique, la vue gn_synthese.v_color_taxon_area travaille avec des id_area. Actuellement le fichier geojson ou wkt qu'il faut préparer et poser sur le terminal doit donc comporter un champ id dans les properties de chaque unité geographique et ce champ id doit contenir l' id_area correspondant.

{"type": "Feature", "properties": {"id": 661178}, "geometry": {"type":"MultiPolygon","coordinates":[[[[4.879103323,44.761175685],[....

Il faudrait donc compléter la route de l'api que cite @camillemonchicourt car elle comporte uniquement le code_area et pas le id_area. A voir si renommer id_area en id pour une rétrocompatibilité ou si le laisser en id_area et modifier l'app androïd.

La table gn_commons.t_parameters comporte un enregistrement occtaxmobile_area_type qui comporte le type_code pour définir la couche à utiliser pour la coloration taxonomique. Je propose de retirer ce paramètre du fichier settings.json et d'utiliser celui de la base, notamment afin déviter des incohérences et ce doublonnage de configuration.

Je suis de l'avis de @sgrimault pour dissocier la fonctionnalité d'affichage des couches et celle de la coloration. L'affichage est géré à partir de couches posées sur le terminal et déclarées dans le settings.json (couleurs, comportement, affichage par défaut). Eventuellement, comme le propose @DonovanMaillard, mais c'est un autre sujet, en appelant des couches du ref_geo.
La coloration, elle, est activée ou pas dans le settings.json et la base geonature + l'api comporte tout ce qui faut pour retourner les données nécessaires à son fonctionnement autonome sur le mobile. La config de cette fonctionnalité se ferait donc uniquement coté GeoNature. Il y a une autre raison à celà. Aujourd'hui l'utilisateur peut mettre cette couche geojson où il veut et plutôt avec les fichiers mbtiles s'il en utilise. Si l'appli doit écrire ce fichier sur le terminal, elle n'aura pas forcement les droits pour le mettre avec les mbtiles. Donc autant que les couches à afficher soient celles que l'utilisateur mets sur son terminal et que la couche geosjon soit une couche indépendante et dédié uniquement à la coloration (avec un nom et un emplacement unique et identifié par l'app Androïd)

Je ne suis pas d'accord avec une coloration dépendante de l'api. Je vois ça comme une régression et ça pose le souci de fonctionnement hétérogéne évoqué (un coup ça marche un coup ça marche pas selon si réseau ou pas et l'utilisateur va pas trop comprendre). Normalement si geonature est capable de servir le fichier geojson de la couche + le contenu de la vue gn_synthese.v_color_taxon_area l'appli est capable de faire la coloration taxonomique de manière autonome.

Quand charge-t-on cette couche, à quelle fréquence, juste un différentiel ou un annule et remplace ?

Dans ref_geo.l_areas, il y a un champ meta_update_date, tant que cette date est antérieure à la date du fichier qui est sur le terminal, le fichier est réputé à jour. Il faut le remplacer seulement si un SELECT max(meta_update_date) FROM ref_geo.l_areas WHERE id_type = macouche; est plus récente que celle du fichier sur le terminal. Je dirais annule et remplace car ce sera très très peu fréquent de modifier ce type de couche. Et d'ailleurs, actuellement, si elle change et que le fichier geojson n'est pas regénéré et redeployé sur toute la flotte mobile de l'instance, il y a incohérence entre ce que renvoie la vue gn_synthese.v_color_taxon_area et la couche en place dans le terminal.

[sgrimault]

OK, oui déjà ajouter ce paramètre serait vraiment important pour retrouver un usage fonctionnel des couleurs de taxons.

C'est déjà en cours :)
Je vous tiens au courant.

Pour information, suite aux problèmes liés à l'affichage des couches vectorielles sur la carte (même avec des petites couches comportant peu de données), je suis en train de préparer une mise à jour de l'application de démonstration du module "maps" afin de pouvoir faire des tests plus aisément de votre coté. Cette application peut par exemple charger dynamiquement des configurations sous forme de fichier json que l'on peut choisir via une modale ("picker").

[camillemonchicourt]

Oui il y a 3 niveaux différents :

1. Permettre d'afficher la couches des UG par défaut pour fixer régression. @sgrimault est dessus, merci !
   Super aussi pour les développements pour corriger les lenteurs de chargement des couches GeoJSON (discuté dans un autre ticket)
2. Récupérer la couche des UG depuis l'API et non plus avec un fichier GeoJSON un peu fragile, en s'appuyant sur la route https://demo.geonature.fr/geonature/api/geo/areas?type_code=M10&format=geojson (qui contient bien les id_area donc OK en l'état à priori). Je ne vois pas pourquoi il faudrait la resynchroniser régulièrement. Les mailles dans la BDD GeoNature ne changent peu ou pas. Mais il faudrait en effet un mécanisme minimal si on doit faire évoluer le ref_geo, ou passer sur un autre type de zonages... Évolution moyenne à discuter, chiffrer, financer si elle apporte un réel gain. Certainement à discuter dans un ticket dédié.
3. Revoir complètement le mécanisme de récupération des couleurs de taxons. Gros sujet conséquent qui mériterait un ticket dédié.
   Je suis d'accord avec @gildeluermoz que ça serait vraiment dommage de ne plus en disposer quand on est hors-ligne, mais cela pourrait se discuter pour 2 raisons comme évoque @DonovanMaillard :
   • Réduire pas mal la synchro des données car récupérer régulièrement toutes les couleurs de taxons de toutes les area peut devenir assez lourd et long.
   • Ouvrir d'autres usages comme le fait de disposer aussi des profils de taxons quand on saisit une obs et donc contextualiser l'obs ou vérifier une possible erreur. Si on veut ajouter ça, on ne va pas encore s'embarquer tout ça en synchro, mais on pourrait considérer que c'est une fonctionnalité bonus dont on dispose seulement si on a du réseau, ce qui est de plus en plus le cas...

Mais là déjà c'est super si le niveau 1 est traité pour régler le sujet initial de ce ticket.

[DonovanMaillard]

Sur le point 3, je vois davantage les profils comme un bonus. Mais ça ne justifie pas forcément de régresser sur les couleurs en les traitant uniquement online

A noter que la synchronisation se fait maintenant en tâche de fond sans bloquer la saisie. Ça n'est pas si gênant que ça soit synchronise périodiquement, de même que la couche geojson qui correspond pour assurer l'intégrité

[camillemonchicourt]

Les couches vectorielles sont affichées par défaut dans la 2.7.1, avec l'ajout du paramètre shown_by_default permettant d'activer leur affichage par défaut ou non.