Ne pas synchroniser les taxons à chaque synchro

[TheoLechemia]

Type d'amélioration Perfomances

Proposition Je teste la possibilité de mettre tout taxref dans l'appli.. En enlevant tous les synonymes et en mettant uniquement les taxons de métropole on est à 143 000 taxons. ça ne me parait pas énorme donc je me dis que ça pourrait être un gros plus dans un le cas d'une utilisation plus grand public de l'appli. Je sais qu'il y a une volonté de pouvoir charger plusieurs liste de taxons (en lien avec les JDD) dans les tuyaux, du coup ça va un peu dans le même sens, on va avoir une multiplication du nombre de taxons. Je ne sais pas encore quelle est la meilleur solution, mais il me paraîtrait judicieux de dissocier la synchronisation montante (j'envoie une obs) et la synchronisation descendante (ou je récupère mes référentiels). Notamment la taxonomie, qui à priori n'évolue pas rapidement. Synchronisation plus périodique ? Bouton pour synchroniser uniquement la taxonomie ?

[sgrimault]

Il y a déjà une notion de synchronisation périodique partielle (cf. https://github.com/PnX-SI/gn_mobile_core/tree/develop/datasync#parameters-description) via les paramètres sync_periodicity_data et sync_periodicity_data_essential où sync_periodicity_data_essential ne synchronise pas les données relatives liées aux taxons potentiellement très volumineuses.

Quant à la synchronisation des relevée, elle reste dissociée de la synchronisation des données locales, elle est juste lancée en même temps au démarrage de l'application si les conditions sont réunies (accès réseau notamment).

[DonovanMaillard]

Bonjour,

Je sais qu'il y a une volonté de pouvoir charger plusieurs liste de taxons (en lien avec les JDD) dans les tuyaux, du coup ça va un peu dans le même sens, on va avoir une multiplication du nombre de taxons.

Ce qu'on prévoit de mettre en place cette année est la logique suivante, et elle permettra sans soucis un déploiement avec des listes sur mesure et des listes associées aux différents jeux de données, donc possiblement tout le taxref tel que tu l'as filtré pour du grand public @TheoLechemia :

1. L'administrateur définit une liste de taxons par défaut pour occtax mobile, et la déclare dans le fichier de configuration d'occtax-mobile
2. L'application Occtax-mobile authentifie son utilisateur, puis récupère les métadonnées : donc les jeux de données et leurs listes de taxons correspondant
3. Occtax-mobile interroge TaxHub et récupère (sur une nouvelle route) tous les taxons appartenant soit à la liste par défaut, soit à une liste associée à l'un des JDD accessibles à l'utilisateur, ainsi que la ou les listes auxquelles appartiennent chaque taxon
4. Si l'utilisateur saisit dans un jeu de donnée associé à une liste, alors les taxons proposés sont ceux de la liste en question. Si l'utilisateur saisit dans un jeu de donnée sans liste, alors on lui propose la liste de saisie occtax-mobile par défaut.

De cette manière :

• L'administrateur peut adapter les taxons proposés par défaut à ses utilisateurs (dans une asso papillons, on ne veut pas forcement de tout le taxref par défaut par exemple)
• Les taxons saisissables sur le mobile sont cohérents avec les taxons ouverts à la saisie pour un JDD sur le web
• Le mobile dispose d'une base de nom qui compile toute ses listes de taxons, et selon le JDD choisi il applique un filtre sur telle ou telle liste
• On peut charger tout le taxref par défaut si on a envie.

Il faudra qu'on revoit ce point que tu soulignes @sgrimault , j'avais retenu que les données essentielles intégraient les taxons, les nomenclatures, les datasets etc. Et que seules les données géographiques étaient "non essentielles". Le fonctionnement ci-dessus impliquera que JDD et taxons soient synchronisés en même temps, mais en effet pas forcément à chaque "post" des données saisies, et pas forcement que quand on récupère les données géographiques. A réfléchir quand on arrivera sur cette fonctionnalité...

[TheoLechemia]

Merci pour ces éclaircissement. Au vu de mes tests il y a toujours quelquechose que je ne comprend pas. Dans notre config on a mis ça :

    "sync_periodicity_data_essential": "7d",
    "sync_periodicity_data": "50m"

Quand je saisi une observation puis que je la synchronise, la synchro me retélécharge toute la liste taxo et les unité géographique. Est-ce que cette config fait référence à une synchro en tâche de fond ? En tout cas je réitère ce que je disais à la base dans ce ticket : je trouve ça dommage de tout retélécharger quand je veux juste envoyer une observations. ça devient inopérant quand on a une liste conséquence de taxon ou des unités géographiques fines. Pour moi il faudrait deux boutons :

• synchroniser les référentiels (qui peut être lancé en tache de fond eventuellement, en suivant les paramètres ci-dessus)
• envoyer mes observations

[DonovanMaillard]

Pour moi il faudrait deux boutons :

* synchroniser les référentiels (qui peut être lancé en tache de fond eventuellement, en suivant les paramètres ci-dessus)

* envoyer mes observations

En fait ça fait 3.... un pour les données obligatoire (taxons, datasets, nomenclatures etc), un pour les unités géographiques bien plus lourdes, et un pour poster ses relevés terminés. A voir comment on peut faire ça sans avoir 50 boutons... Dans l'idée, on pourrait avoir un bouton avec une icone "upload" qui ne sert qu'à poster ses relevés. Puis une page de synchro, qui propose un déclenchement manuel des synchro plus complètes (qui continuetn à se lancer automatiquement si et seulement si le délai indiqué dans la conf est dépassé).

[gildeluermoz]

QQ remarques et propositions

• Faut se mettre à la place de l'utilisateur qui ne maîtrise absolument rien de toutes ces subtilités. Ça doit rester simple et intuitif pour lui. Ça doit aussi rester juste sans qu'il ne se pose de question (à savoir s'il n'a pas oublié de faire un truc par ex.) Les couleurs des taxons, par exemple, doivent être à jour après que l'utilisateur a poussé ses obs (donc synchro des couleurs des taxons par unité après chaque synchro des nouvelles observations) S'il y a complexité, ça doit plutôt se faire en arrière plan.

Idéalement la synchro doit être rapide. En l'état à chaque synchro, tout est rechargé en mode supprimer remplacer, donc de manière un peu brute. Forcément s'il y a beaucoup de donnée, c'est long à chaque synchro.

Proposition. Pourquoi ne pas charger une fois pour toute (à l'install) ce qui ne changera pas. Je pense à tout taxref (nomenclatures ?); du moins une vue, présentant tous les cd_nom et les champs utiles pour le mobile et qui peuple une table taxref sur le mobile. Libre à chacun de personnaliser cette vue, sachant qu'il peut éventuellement être possible de rafraîchir ce contenu plutôt lourd, par une action disponible dans un menu pas forcément exposé directement à l'utilisateur par un bouton. Toutes les infos utiles de tout taxref étant dispo dans le mobile, les échanges avec la base GN devraient pouvoir être allégés. Voir les perfs du mobile pour construire des listes à partir de données présentent dans plusieurs tables et potentiellement grandes.

Autre piste, versionner ce qui peut l'être. Comme cette vue taxref ou tout autre donnée qui bouge peu (liste de taxons, observateurs, nomenclatures, JDD, ...) Et ne déclencher leur maj qu'en cas de nouvelle version disponible. A voir si versionnement manuel ou automatique (utilisation des dates).

Le serveur pourrait par exemple produire des fichiers json versionnés chaque fois que modification de listes, observateurs, taxons, nomenclatures, JDD, correspondances JDDs-listes, etc. L'API expose ces fichiers avec leur version. Et le mobile ne charge ce fichier que si la version dont il dispose est en retard. Seul ce qui doit être personnalisé par utilisateur ne pourrait pas vraiment répondre à cette logique.

Faisabilité technique à creuser.

[sgrimault]

Bonjour,

Je rejoins l'avis de @gildeluermoz concernant le "versioning" (ou l'horodatage des données éligibles à la synchronisation), sachant que c'était déjà un sujet qui a été évoqué il y a quelque temps.

Concernant la synchronisation, les attributs sync_periodicity_data et sync_periodicity_data_essential sont facultatifs et concernent uniquement la synchronisation des données issues de GeoNature (observateurs, taxonomie, taxon, données relatives aux taxons, etc., cf. documentation à ce sujet). Ça veut dire que par défaut, c'est une synchronisation manuelle des données à faire par l'utilisateur via le bouton "Synchronize" situé sur l'écran d'accueil. Ce bouton lance deux opérations en parallèle, la synchronisation complète des données issues de GeoNature et la synchronisation des éventuels relevés prêts à être synchronisés.

L'application garde localement la date de dernière synchronisation des données (pour notamment notifier l'utilisateur de la "fraicheur" des données présentes localement). Si on ajoute coté GeoNature deux attributs permettant de connaitre la date de création et de modification sur chaque objet éligible à la synchronisation (Observateurs, taxons, etc.) et qu'il est possible de filtrer ces objets lors des appels aux routes pour la synchronisation des données en fixant la date de dernière modification, alors on aura le workflow suivant :

• Premier lancement de l'application : aucune synchronisation de faite, aucune données présentes localement : lancement automatique d'une synchronisation complète après la configuration et authentification (on ne précise pas le filtre par date de dernière modification)
• Si la synchronisation se termine avec succès, l'application met à jour la date de dernière synchronisation.
• Lors de la prochaine synchronisation (en automatique ou non), l'application précise à partir de quand elle souhaite récupérer les données "fraiches" coté GeoNature. On aura donc une synchronisation plus rapide car moins de données à traitées
• Si la synchronisation échoue pour x raisons (perte de réseau), la date de dernière synchronisation n'est pas mis à jour et l'application repartira de là où la synchronisation a réussi dernièrement lors de la prochaine synchronisation.

Le bouton "Synchronize" peut garder son fonctionnement actuel avec la synchronisation fonctionnant avec le principe décrit ci-dessus en adressant tous les usages possibles (avec ou sans synchronisation automatique), avec une petite amélioration à prévoir, calquée sur le fonctionnement de la synchronisation des données : Sous forme de "worker" (tache de fond dédiée, avec les mêmes règles en prérequis : réseau disponible, niveau de batterie ok, etc.).

[DonovanMaillard]

Bilan :

Les développements sont en cours avec le résultat attendu suivant :

• La synchronisation "montante" (les relevés saisis vers le serveur) sera indépendante de la synchronisation "descendante" (serveur vers mobile : nomenclatures, utilisateurs etc).
• La synchronisation montante (le post des données) sera déclenché manuellement par l'utilisateur
• La synchronisation descendant se fera périodiquement et en tâche de fond, sans que l'utilisateur n'ait à s'en soucier (il pourra quand même forcer la synchro depuis le menu contextuel de l'application)
• Les taxons seront synchronisés différemment : on chargera tout le taxref d'un coup, et l'appli ne chargera que les taxons nécessaires à la saisie en fonction des listes de taxons disponibles : comme sur la version web d'occtax

En clair, les données seront réparties en 3 blocs (contre 2 aujourd'hui) :

• des données obligatoires : nomenclatures, observateurs, jeux de données, correspondances entre taxons et listes etc : rafraichis en arrière-plan et périodiquement selon le paramètre sync_periodicity_data_essentiel
• des données facultatives : couleurs des taxons, et par la suite éventuellement profils d'espèces (#196 ), rafraichies en arrière-plan et périodiquement par le paramètre sync_periodicity_data
• les données taxonomiques: chargées selon une date butoire fixée avec le paramètre sync_taxa_date : si la dernière synchronisation des données est plus récente que le paramètre (installation récente, synchronisation forcée etc), on ne fait rien. Si la dernière synchro est antérieure, alors on recharge tout le taxref. Lorsqu'il fait une mise à jour de son taxref coté serveur, l'administrateur devra donc penser à actualiser ce paramètre pour forcer tous ses terminaux mobiles à se synchroniser.

[camillemonchicourt]

Dans la version 2.6.0, la synchronisation des relevés vers GeoNature a été dissociée de la mise à jour des données de référence depuis GeoNature (nomenclatures, JDD, taxons, couleurs des unités géographiques, observateurs). La synchro des relevés est faite uniquement à la demande de l'utilisateur, avec un bouton ENVOYER dédié :

La mise à jour des données de référence est faite automatiquement tous les 7 jours (par défaut, modifiable), ou lancé par l'utilisateur si il le souhaité dans le nouveau menu latéral :

La mise à jour des données de référence est faite dans un traitement parallèle, pour ne pas empêcher la saisie, le temps qu'elle soit terminée.

Lors du premier lancement, une première synchronisation des données de référence est lancée automatiquement, et il n'est pas possible de créer un relevé tant que cette première synchro n'est pas terminée.

---

Reste à voir pour faire évoluer la mise à jour des taxons, pour pouvoir synchroniser tout Taxref, nécessaire aux évolutions à venir de liste des taxons par JDD.

[camillemonchicourt]

Ajout d'une route renvoyant la version de Taxref et de sa date de dernière mise à jour : https://github.com/PnX-SI/TaxHub/issues/394.

Exemple : https://demo.geonature.fr/taxhub/api/taxref/version

Il faut donc ajouter un paramètre côté mobile pour pouvoir indiquer la date de dernière mise à jour de Taxref et la comparer avec la date dans la propriété update_date de la route taxhub/api/taxref/version, pour relancer ou non la mise à jour de Taxref.

[sgrimault]

@camillemonchicourt,

Cela concerne aussi bien les taxons (GET -> /api/taxref/allnamebylist/{taxref_list_id}) que les données relatives aux taxons (GET -> /api/synthese/color_taxon) ?

[camillemonchicourt]

C'est seulement pour la liste des taxons, qui ne bouge qu'une fois par an (à peu prêt) quand on met à jour la version de Taxref.

Les couleurs de taxon peuvent changer très régulièrement dès qu'il y a de nouvelles observations quelque part.

Mais ça me soulève une question. Désormais on va récupérer une liste de taxons bien plus conséquente, en récupérant tout Taxref localement. Mais il ne faut pas que cela alourdisse la quantité d'infos de couleurs de taxons par unité géographique. Je ne crois pas que ça soit le cas, car celle-ci se fait sur un id_liste de taxon si je me souviens bien. Mais à vérifier. Et voir si il n'y a pas d'effet de bord.

PS : D'ailleurs, j'ai dit une bêtise, pas besoin d'un paramètre coté mobile pour stocker la date de mise à jour. Il faut stocker localement côté mobile la date de dernière mise à jour de la liste des taxons et la comparer à la propriété update_date de la route taxhub/api/taxref/version.

[sgrimault]

Merci pour ton retour, j'avais un petit doute si ça pouvait couvrir les données relatives de chaque taxon. Je vais pouvoir implémenter cette première partie en attendant l'histoire du filtre sur les listes de taxons.