Récupération partielle des taxons #52
Comments
|
Attention l'application Occtax-mobile nécessite à minima TaxHub 1.7.0 ainsi que GeoNature 2.4.0. Mais là ton soucis semble bien du côté de TaxHub. La route récupère les taxons par lot, en utilisant les paramètres Quand tu es passé à TaxHub 1.7.0, as-tu bien appliqué les mises à jour de la BDD et notamment le rafraîchissement de la vue matérialisée Tu peux tester ta route en web aussi pour voir ce qu'elle remonte. Voir PnX-SI/gn_mobile_core#13 |
|
Ok merci pour ta réponse, En effet j'ai bien lancé le script de mise à jour 1.6.5to1.7.0, et je n'ai pas eu d'erreurs particulières. J'ai quand même vérifié pour être sur et ma vue est bien conforme à ce que crée le script d'update vers 1.7.0. La route testée coté web remonte bien mes 6105 noms En revanche sur ces paramètres par défaut, j'ai dans le code partagé ici. Je vais peut être déjà commencé par remonter ces variables pour nous donner du mou. (ha, et j'ai vérifié aussi, je n'ai pas de filtre activé) |
|
Ton URL là est la page web de l'application, pas la route. |
|
Oups mauvais lien, ok merci. Ca laisse quand même penser à un soucis coté mobile à priori, qui ne remonte que 27 noms, ou à un soucis lors de la synchronisation ? |
|
J'ai coupé et relancé l'appli de synchronisation (qui avait bien sa pastille verte tout à l'heure) et elle est en train de récupérer. A priori c'est donc simplement un soucis de synchronisation, connexion perdue, transaction stopée ou autre qui serait à l'origine du soucis... je vous dirai si j'arrive à avoir mes 6105 noms à l'issue de cette synchro, qui effectivement dure plus longtemps Complément : après cette nouvelle synchronisation j'ai 1364 taxons. De nouveau pastille verte, pas possible de relancer une synchro manuellement. Des transactions qui ne se terminent pas quelque part à priori? |
|
La synchronisation des taxons paginée a été réglée au niveau de TaxHub 1.7.2 ainsi que Sync-mobile 0.3. |
|
Bonjour à tous, Nous rencontrons un souci lors de la synchronisation. Nous utilisons la version 1.1.4 de Occtax mobile et la version 1.1.2 pour la synchro. GeoNature est en version 2.5.5 et Taxhub 1.7.3 Des taxons qui étaient auparavant disponible à la saisie mobile (ex : Bouquetin des Alpes, Chamois, Roitelet à triple bandeau, etc) ne sont plus disponible dans Occtax mobile. Or la data synchronisation aboutit (pastille verte).
Dans taxhub, la liste (id=500) contient 11974 noms : https://geonature.mercantour-parcnational.fr/taxhub/#!/listes/500. En BDD, dans la vue v_taxef_all_listes, nous avons également 11974 noms pour la liste 500. Or après avoir lancé une synchronisation, Occtax mobile annonce seulement 8890 taxons trouvés.
La route : https://geonature.mercantour-parcnational.fr/taxhub/api/taxref/allnamebylist/500?limit=20000 remonte 17180 taxons dont les taxons Bouquetin des Alpes, Chamois, Roitelet à triple bandeau qui sont présent. Que conviendrait il de faire pour que nous récupérions l'intégralité des taxons dans Occtax mobile ? PS : j'ai déjà lancé un refresh materialized view sur vm_taxref_list_forautocomplete Merci pour votre aide. |
|
Bonjour,
|
|
Oui c'est surtout la synchronisation des unités géographiques qui est lourde et parfois n'aboutit pas. Des solutions d'amélioration de la synchronisation sont en cours par ailleurs. Pour le problème de Samuel, il y a eu plusieurs échanges sur le sujet. |
Les retours que nous avons des agents sur le processus de synchronisation sont de manière générale négatifs à cause des performances très limitées (durée de la synchro, échec de la synchro et parfois incohérence des données). A titre de comparaison nous avions moins d'échecs de synchronisation avec la version V1 de Geonature mobile. |
|
Il y a 3 pre-release en cours de l'outil Sync-mobile, notamment en lien avec le sujet PnX-SI/gn_mobile_core#34 Un élément identifié est qu'il y a beaucoup d'appels des routes de GeoNature qui sont longs et parfois trop lourds. |
|
Je suis allé regarder de plus près le fichier de log généré sur le smartphone. 04-07 14:56:03.692 10209 10291 I fr.geonature.sync.sync.worker.DataSyncWorker: l Cependant la table data de la BDD SQLite indique l'absence des taxons chamois, bouquetins etc. |
|
En passant le paramètre page_size de 1000 à 10000, j'ai pu récupérer tous les taxons manquants. Occtax mobile annonce 11974 taxons trouvés, identiques à ceux de la liste (id=500) qui contient elle aussi 11974 taxons. C'est bizarre que la synchro passait encore il y a peu avec le paramètre page_size à 1000. Merci ! |
|
Ah OK donc la synchro semblait passer, mais en fait elle ne devait pas aboutir et cela expliquait ton soucis de noms manquants dans la liste ! |
|
Bonjour, Je reviens sur ce ticket car nous rencontrons à nouveau un souci pour des taxons manquants dans Occtax mobile. La synchro passe sans problème semble t'il : 05-25 11:57:03.084 26717 26749 I fr.geonature.sync.sync.worker.DataSyncWorker: l Dans taxhub, la liste (id=500) contient 11974 noms : https://geonature.mercantour-parcnational.fr/taxhub/#!/listes/500. En BDD, dans la vue v_taxef_all_listes, nous avons également 11974 noms pour la liste 500. Or après avoir lancé une synchronisation, Occtax mobile annonce seulement 6688 taxons trouvés et cela se confirme lorsque j'ouvre le fichier data.db stocké sur le téléphone.
|
|
Est-ce que ce n'est pas lié à la différence entre taxon et nom ? Ici seul les taxons sont considérés. |
|
A priori non car habituellement j'ai approximativement 11974 taxons annoncés pour Occtax mobile. Et là après la synchro il manque bien de nombreux taxons. |
|
Je n'avais pas fait attention à la version d'occtax mobile que tu utilises. |
|
@amandine-sahl tu me conseilles d'installer uniquement la dernière version de sync 1.1.7 ? Faudrait il que j'installe également la dernière version de Occtax_mobile ou est ce que cette version 1.1.7 est compatible avec un occtax-mobile 1.1.4 ? |
|
Bonjour, |
|
Je crois qu'on en a discuté ailleurs, mais Occtax-mobile regroupe les noms scientifiques et les noms français en une seule ligne, donc il y a toujours une différence entre le nombre de lignes dans la table et dans la route et dans ce qu'affiche Occtax-mobile. |
|
Non mon problème ne vient pas de là. Il manque des taxons dans la bdd sqlite qui est déposée sur Phone\Android\data\fr.geonature.sync\databases. Pourtant la synchro aboutit. |
|
Les taxons manquants sont présent à la saisie dans Occtax-web |
|
Sans doute à discuter plutôt sur le dépôt de sync ;) Tu es su quelle version de sync? |
|
@DonovanMaillard. Nous sommes sur une version 1.1.2 de sync. J'ai également testé la dernière version 1.1.9 mais j'obtiens le même comportement. Seulement 6688 taxons sur Occtax mobile quand j'ai ai 11975 sur https://geonature.mercantour-parcnational.fr/taxhub/#!/listes/500 |
|
Et tu as quoi comme paramètres pour :
? |
|
Pas très recommandé à priori, mais j'ai "réglé" ou en tous cas contourné, le soucis chez Flavia en mettant un page_size très élevé. Un seul appel suffit par conséquent, et ça fonctionne comme ça. |
|
Ce n'est pas exactement le même soucis mais dans notre cas : Liste avec :
et la table data_taxon contient 8583 données dans la table taxons Exemple avec Rhagadiolus edulis Requête de taxref: Bref je ne comprend pas tout à l'algorithme de récupération des taxons |
|
@samuelpriou, je te laisse clore le ticket :) |
|
@sgrimault il n'y a rien à faire du fait que cela ne fonctionnait pas en aillant des paramètres plus bas qui faisaient alors 2 appels à la route des taxons et ont entraîné une récupération partielle de la liste ? |
|
Oui, le fonctionnement reste très capricieux sur ce point et le nombre d'appels défini ne semble pas avoir le comportement espéré. Il faut y aller à tâton pour trouver les variables qui fonctionnent pour l'instant |
|
Vu avec @samuelpriou, les taxons étaient incomplets car le paramètre |
|
d'une manière générale, est-il pertinent de laisser à l'utilisateur la définition d'un max_retry? Dans la mesure où l'appli gère déjà les choses assez intelligemment en testant les pages completes/incomplètes, les echecs d'appels etc ? Est-ce qu'on pourrait pas avoir simplement le page_size à définir, et que l'appli aille elle-même fixer son max_retry en fonction du nombre de taxons retourné par la route pour éviter ce type de soucis? Pour ma part, la notion d'entrées relatives aux taxons, en dehors des noms eux-mêmes m'échappait totalement. J'arrêtais mon calcul au nombre de taxons renvoyés par l'api. |
|
C'est plus un garde fou pour garantir que la synchronisation s'arrêtera bien. Actuellement le module de synchronisation "navigue" dans la route paginée |
|
D'accord merci. Peux-tu me préciser quelles sont les ressources relatives dont il faut tenir compte dans le calcul en plus du nombre de taxons et où elles se trouvent, pour qu'on puisse le préciser dans la doc? |
|
Les données relatives aux taxons sont les couleurs des taxons pour toutes les unités géographiques. |
|
Ok merci, donc impossible de prévoir facilement le volume que ça représente sur une instance moyenne pour proposer des paramètres par défaut. Dommage ! |
|
Pour simplifier, on pourrait rendre le paramètre Et on part du principe que le comportement coté API restera inchangé :
|
|
Disons qu'il faut à minima le décrire précisément dans la doc et préciser où trouver le nombre de lignes que l'appli mobile a besoin de récupérer pour calculer correctement ces variables, à moins de pouvoir le simplifier effectivement. |
|
OK, pour conclure ce sujet et bien comprendre. |
|
Avant de conclure, j'aimerais ajouter mon grain de sel... J'ai 137 549 lignes dans gn_synthese.v_color_taxon_area (contenant 13517 cd_ref différent) et une liste de 9715 taxons que je souhaite autoriser à la saisie mobile. Bilan :
edit : j'ai pas précisé, je suis en GN 2.6.2 et en sync 1.1.9 et occtax-mobile 1.2.4 |
|
@lepontois Dans votre cas, je testerais avec les paramètres suivants :
|
|
@lepontois pour avoir les logs, voir https://github.com/PnX-SI/gn_mobile_occtax/blob/master/docs/installation-fr.md#logs |
|
Si j'ai bien compris, la synchro s'arrète si 404 lui est retourné. Donc je me suis dit que la valeur de page_max_retry pouvait être grande, ça ne changerait pas grand chose vu qu'il ne ferait pas tous les appels. Est-ce que je fait erreur ? Bref, j'ai quand même remplacé la valeur de page_max_retry par 20. Bilan :
Voici les logcat (merci Camille pour le lien mais la prochaine fois que tu pirates mon cerveau, préviens moi :) ) |
|
@lepontois merci pour les logs. De ce que je peux voir :
On devrait donc avoir en local 13747 taxons et aucune données relatives |
|
Ok, merci pour la traduction. Du coup, j'ai modifié la valeur de occtaxmobile_area_type dans la table gn_commons.t_parameters pour "M1" car c'est l’échelle qui me semble être la plus pertinente (5km c'est trop large ou alors passer à l'échelle communale pour être en correspondance avec les Atlas de la biodiversité communale... J'hésite) La synchro prend à présent 6 minutes (c'est long et pourtant pas avec une connexion trop mauvaise!!) et j'ai :
Voici le logcat de la dernière synchro : |
camillemonchicourt
changed the title
|
Attention, à noter. Au moment de la synchronisation, Sync-mobile se charge de regrouper les noms latins et noms français en une seule ligne. Il est donc normal que le nombre d'objets renvoyés par la route, et le nombre de taxons affiché dans l'application OCctax-mobile soit différent. Les données relatives sont les couleurs de chaque taxons pour chaque unités géographiques (ainsi que le nombre d'observations du taxon dans chaque unité géographique et la date de dernière observation). C'est-à-dire le contenu de la table Suite à ces échanges, il reste un point à vérifier/clarifier : Quand la synchronisation des "données relatives" n'aboutit pas (pour diverses raisons), la synchronisation des taxons qui est faite avant devrait être complète et fonctionnel. Hors il semble y avoir un problème de nombre de taxons synchronisés (ou affichés) quand la synchro des données relatives (moins essentielle) est partielle. Une autre proposition à priori retenue serait de supprimer à terme le paramètre |
|
En regardant les logs, je ne vois pas d'appel à api/taxref/allnamebylist/<id_liste>... est-ce normal ? Également, dans les logs, il ne me semble pas que la synchro des "données relative" n’aboutit pas. Mais je me trompe peut-être. Je suis bien d'accord avec toi pour le retrait de page_max_retry. |
|
Oui, pour le nombre de taxons variable, ça reste inexpliqué en l'état. |
|
Le paramètre |
|
Cette récupération des taxons sera à rediscuter et reprendre plus largement. Il y a peut-être intérêt à ce que la vue de GeoNature renvoie directement une liste de nom qui ne soit pas retravaillée par l'application mobile à terme. Se pose aussi la question d'avoir des listes de taxons différentes selon les jeux de données... c'est complexe pour le mobile,mais ça a été implémenté sur occtax (version web) et il serait incohérent que le fonctionnement ne soit pas le même sur le mobile : on pourrait saisir sur téléphone des taxons qu'on a empêché de saisir sur GeoNature... On s'éloigne peu à peu du soucis qui est à l'origine de ce ticket et qui est globalement réglé/simplifié aujourd'hui, j'ouvre donc un ticket à part sur le dépot gn_mobile_core. |
|
Je me repenche sur le sujet. |
|
Soucis de récupération partielle des taxons corrigé avec la version 1.9.4 de TaxHub : https://github.com/PnX-SI/TaxHub/releases |
Remove mention to `page_max_retry` setting that is no more used
Bonjour,
Je viens de tenter une install de geonature mobile. TaxHub (1.7) et Usershub (2.1.2) sont à jour, GeoNature est dans sa version master actuelle 2.3.2.
Pour info et question :
L'application mobile me remonte bien les JDD, les observateurs, en revanche elle ne récupère que 27 taxons sur 6105 présentes dans ma liste saisie occtax (dont l'identifiant est bien renseigné dans settings_occtax).
Est-ce un bug à rechercher sur l'appli mobile, sur la synchronisation, ou simplement des routes mises à jour dans la prochaine version GeoNature puisque j'ai vu qu'un travail avait été fait là dessus?
Merci !
The text was updated successfully, but these errors were encountered: