liste tronquée saisie observation about geonature-citizen HOT 34 OPEN

Bonjour,

Effectivement si je ne dis pas de bêtises voici les étapes :

• La liste taxonomique avec ces taxons est initialisée ici :

  GeoNature-citizen/frontend/src/app/programs/observations/form/form.component.ts

  Line 164 in 2f937ff

  .getProgramTaxonomyList(this.program_id)

• Qui appelle l'API de citizen pour avoir la liste des taxons :

  GeoNature-citizen/frontend/src/app/api/gnc-programs.service.ts

  Lines 169 to 181 in 2f937ff

  	getProgramTaxonomyList(program_id: number): Observable<TaxonomyList> {
  	return this.getAllPrograms().pipe(
  	map((programs) => programs.find((p) => p.id_program == program_id)),
  	mergeMap((program) =>
  	this.http.get<TaxonomyList>(
  	`${this.URL}/taxonomy/lists/${program['taxonomy_list']}/species`
  	)
  	),
  	catchError(
  	this.handleError<TaxonomyList>(`getProgramTaxonomyList`, {})
  	)
  	);
  	}

• Si on regarde cette api (/taxonomy_lists/<id_liste_taxhub>/species/) dans le backend de citizen :
  • elle appelle cette fonction :

    GeoNature-citizen/backend/gncitizen/core/taxonomy/routes.py

    Line 93 in 2f937ff

    r = mkTaxonRepository(id)

  • qui elle même appelle cette fonction :

    GeoNature-citizen/backend/gncitizen/utils/taxonomy.py

    Lines 28 to 41 in 2f937ff

    	def taxhub_rest_get_taxon_list(taxhub_list_id: int) -> Dict:
    	payload = {
    	"existing": "true",
    	"order": "asc",
    	"orderby": "taxref.nom_complet",
    	}
    	res = requests.get(
    	"{}biblistes/taxons/{}".format(TAXHUB_API, taxhub_list_id),
    	params=payload,
    	timeout=1,
    	)
    	logger.debug(f"<taxhub_rest_get_taxon_list> URL {res.url}")
    	res.raise_for_status()
    	return res.json()

  • qui appelle la route de TaxHub : biblistes/taxons/<id_liste>, qui si on regarde le code de TaxHub :
  • il y a bien une limite de 100 par défaut : https://github.com/PnX-SI/TaxHub/blob/df63ea869b6628f7b68741c65d8333a125c68f2d/apptax/taxonomie/routesbiblistes.py#L154-L157
  • Qui peut être surchargée avec une query string : biblistes/taxons/<id_liste>?limit=5000

Éventuelle solution

Je n'ai pas testé mais je pense qu'il faudrait remplacer le dictionnaire payload :

payload = {
        "existing": "true",
        "order": "asc",
        "orderby": "taxref.nom_complet",
        "limit": 5000
    }

C'est un fix rapide pour toi mais à terme il faudrait peut-être le rendre paramétrable.

Je teste ça maintenant

En espérant avoir été clair.

from geonature-citizen.

Comme évoqué, l'idéal serait certainement d'utiliser la route de TaxHub dédiée à la recherche de taxon avec auto-complétion, optimisée en terme de résultat et de pertinence et utilisée dans Occtax.
Cela mériterait un petit développement pour basculer sur cette route correctement.

from geonature-citizen.

Bien vu, Ça semble dû a la pagination de la route de TaxHub.

from geonature-citizen.

Je sais pas quelle route de TaxHub est utilisée mais ça vaut peut-être le coup d'utiliser la même qu'Occtax optimisée pour l'autocompletion avec optimisation des résultats, recherche en français ou nom scientifique etc... ?

from geonature-citizen.

Merci pour vos retours,

Je me réjouis de voir des réponses mais je suis tout de même inquiet. Je suis surpris que malgré la multiplication des atlas de la biodiversité ce problème n'ait pas été signalé.

Je risque d'avoir un problème dans la mesure où notre atlas doit être opérationnel mi-décembre et que ce comportement était totalement inattendu.

Je suis preneur de pistes de travail. J'avoue que les "routes" ne m'évoquent pas grand chose pour l'instant (api ??)

Merci encore pour votre aide.

from geonature-citizen.

A ma connaissance, GeoNature-citizen n'a pour le moment été utilisé que pour des programmes avec des listes de taxons très limitées, ce qui fait que le soucis n'a peut-être pas été identifié.
Le fonctionnement des listes a été évoqué ici : #260 et avait été défini initialement ici : #62

Je ne sais pas exactement où on en est de ces sujets.

A voir quelle route de l'API TaxHub est utilisé, si elle peut être utilisée différemment pour ne pas avoir de limite de nombre de taxons, si il faut faire évoluer la route au niveau de TaxHub, ou si il faut mieux basculer sur une autre route de TaxHub...

from geonature-citizen.

J'ai pas trop le temps de tester sur citizen mais en exécutant ce code Python :

import requests
>>> payload = {
       "existing": "true",
       "order": "asc",
       "orderby": "taxref.nom_complet",
       "limit": 5000
 }
# 100 : id de ma liste taxhub
res = requests.get('http://localhost/taxhub/api/biblistes/taxons/100', params=payload)

J'ai cette requête qui apparaît : GET /api/biblistes/taxons/100?existing=true&order=asc&orderby=taxref.nom_complet&limit=5000

Et j'ai limit : 5000 qui apparait dans la réponse. Donc ça devrait fonctionner 👍

@jonath35, peux-tu me tenir au courant si ça fonctionne chez toi ?

from geonature-citizen.

Bonjour,
Merci beaucoup pour ces retours rapides !
J m etais concentré sur le frontend vendredi matin...

Je test ça dès demain matin et vous tiens au courant.

from geonature-citizen.

Bonjour,

J'ai testé rapidement, mais cela ne semble pas fonctionner. à voir si je m'y prends correctement.
Je ne fait que modifier le fichier sur le serveur avec simplement un redémarrage. J'obtiens notamment :

getProgramTaxonomyList failed: Http failure response for http://xyza/api/taxonomy/lists/10000/species: 502 Proxy Error

from geonature-citizen.

C'est étrange, cela fonctionnait bien avant cette modification ? Car normalement, elle ajoute uniquement un paramètre à la requête taxhub et ne devrait pas faire planter cet appel à l'API citizen.
Le "10000" m'interpelle : est-ce bien l'id de la liste taxhub ?

from geonature-citizen.

Oui c'est bien une liste particulière qui fonctionne bien (dans la limite des 100 premières lignes).

Ce qui me questionne le plus, c'est qu'après avoir constaté cela, j'ai tenté de modifier la limite "en dur" dans le fichier :

/apptax/taxonomie/routesbiblistes.py

avec pour résultat un comportement similaire (erreur).

from geonature-citizen.

Effectivement, c'est étrange.
As tu essayé d'écrire directement cet url dans ton navigateur : /api/biblistes/taxons/10000?existing=true&order=asc&orderby=taxref.nom_complet&limit=5000 ?
Essaie de regarder dans les logs de Taxhub (dans /home/geonatureadmin/taxhub/var/log) pour voir s'il y a des erreurs

from geonature-citizen.

avec l'url : http://xyza/taxhub/api/biblistes/taxons/10000?existing=true&order=asc&orderby=taxref.nom_complet&limit=5000

J'obtiens bien un résultat json avec les 3102 objets

from geonature-citizen.

l'adresse : http://xyza/api/taxonomy/lists/10000/species
retourne cette erreur :

Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request

Reason: Error reading from remote server

from geonature-citizen.

Cela vient donc de Citizen, tu as pu regarder les logs ?

from geonature-citizen.

Bonjour,

Je trouve l'erreur suivante dans /var/log/supervisor/frontend_citizen.log :

getProgramObservations id=6 failed: ErrorEvent is not defined
getProgramTaxonomyList failed: ErrorEvent is not defined
ERROR Error: Cannot find a differ supporting object '[object Object]' of type 'object'. NgFor only supports binding to Iterables such as Arrays.
at NgForOf.ngDoCheck (/home/geonatadmin/gncitizen/frontend/dist/server.js:79399:27)
at checkAndUpdateDirectiveInline (/home/geonatadmin/gncitizen/frontend/dist/server.js:24210:19)
at checkAndUpdateNodeInline (/home/geonatadmin/gncitizen/frontend/dist/server.js:32605:20)
at checkAndUpdateNode (/home/geonatadmin/gncitizen/frontend/dist/server.js:32567:16)
at prodCheckAndUpdateNode (/home/geonatadmin/gncitizen/frontend/dist/server.js:33108:5)
at Object.updateDirectives (/home/geonatadmin/gncitizen/frontend/dist/server.js:342089:2576)
at Object.updateDirectives (/home/geonatadmin/gncitizen/frontend/dist/server.js:32896:72)
at checkAndUpdateView (/home/geonatadmin/gncitizen/frontend/dist/server.js:32549:14)
at callViewAction (/home/geonatadmin/gncitizen/frontend/dist/server.js:32790:21)
at execComponentViewsAction (/home/geonatadmin/gncitizen/frontend/dist/server.js:32732:13)

Elle est présente dans le panneau de debugage du navigateur.

Merci

from geonature-citizen.

Super merci, et as-tu regardé le var/log/gunicorn_gncitizen_errors.log pour voir les erreurs du backend ? Car j'ai l'impression que ça vient de là (car c'est uniquement là que tu as fait la modification normalement ?)

from geonature-citizen.

Merci pour le retour.

Pour le test et l'erreur actuelle, la modification est celle proposée avec le dictionnaire payload (/backend/gncitizen/utils/taxonomy.py)

Par contre je n'ai pas d'erreur backend il me semble. à part un retour"timeout" :

[2021-12-07 09:13:11 +0000] [923] [WARNING] Worker with pid 1976 was terminated due to signal 9
[2021-12-07 09:13:11 +0000] [1988] [INFO] Booting worker with pid: 1988
[2021-12-07 09:13:42 +0000] [923] [CRITICAL] WORKER TIMEOUT (pid:1987)
[2021-12-07 09:13:42 +0000] [923] [CRITICAL] WORKER TIMEOUT (pid:1988)
[2021-12-07 09:13:42 +0000] [1987] [INFO] Worker exiting (pid: 1987)
[2021-12-07 09:13:42 +0000] [1988] [INFO] Worker exiting (pid: 1988)
[2021-12-07 09:13:43 +0000] [1998] [INFO] Booting worker with pid: 1998
[2021-12-07 09:13:43 +0000] [923] [WARNING] Worker with pid 1988 was terminated due to signal 9
[2021-12-07 09:13:43 +0000] [1999] [INFO] Booting worker with pid: 1999
[2021-12-07 09:14:15 +0000] [923] [CRITICAL] WORKER TIMEOUT (pid:1998)
[2021-12-07 09:14:15 +0000] [1998] [INFO] Worker exiting (pid: 1998)
[2021-12-07 09:14:15 +0000] [2009] [INFO] Booting worker with pid: 2009

from geonature-citizen.

Non c'est juste un moyen d'indiquer le type d'une variable en Python. Mais comme il n'y a pas de vérification de type ici, cela ne pose pas de problème.
Ce qui me parait vraiment bizarre, c'est juste en modifiant le dictionnaire payload ça ne marche plus. Peux-tu m'envoyer le fichier taxonomy.py que tu as s'il te plaît ?

from geonature-citizen.

taxonomy_routesbiblistes.zip

C'est dingue de ne même pas pouvoir modifier la valeur 100 dans routesbiblistes.py ..

Merci !

from geonature-citizen.

Merci pour les fichiers. Ils ont l'air bons.
Je ne pense pas que ça vienne de routebiblistes.py car le GET sur http://xyza/taxhub/api/biblistes/taxons/10000?existing=true&order=asc&orderby=taxref.nom_complet&limit=5000 fonctionne.
J'ai du mal à comprendre.

Peut-être, essaie de te mettre en mode dev sur le backend de citizen :

• Soit : poetry run python3 wsgi.py
• Soit :
  • Charger l'environnement virtuel (poetry shell ou source backend/venv/bin/activate)
  • puis : python wsgi.py

Ensuite entre cet URL dans ton navigateur : http://xyza/api/taxonomy/lists/10000/species
Il y aura peut-être des erreurs qui apparaîtront ...

Désolé de ne pas pouvoir t'aider plus...

from geonature-citizen.

Merci pour votre aide,

J'ai stoppé toutes les appli supervisorctl stop all
Lancé uniquement taxhub
puis exécuté le serveur dans le venv

sur l'url xyza/api/taxonomy/lists/10000/species j'obtiens (dans le navigateur) :

{"message": "'<' not supported between instances of 'NoneType' and 'str'"}

En navigant sur la page programme :

ERROR in app: Exception on /api/programs/6/observations [GET]
Traceback (most recent call last):
File "/home/geonatadmin/gncitizen/backend/venv/lib/python3.8/site-packages/flask/app.py", line 2447, in wsgi_app
response = self.full_dispatch_request()
File "/home/geonatadmin/gncitizen/backend/venv/lib/python3.8/site-packages/flask/app.py", line 1952, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/home/geonatadmin/gncitizen/backend/venv/lib/python3.8/site-packages/flask_cors/extension.py", line 165, in wrapped_function
return cors_after_request(app.make_response(f(*args, **kwargs)))
File "/home/geonatadmin/gncitizen/backend/venv/lib/python3.8/site-packages/flask_cors/extension.py", line 165, in wrapped_function
return cors_after_request(app.make_response(f(*args, **kwargs)))
File "/home/geonatadmin/gncitizen/backend/venv/lib/python3.8/site-packages/flask/app.py", line 1821, in handle_user_exception
reraise(exc_type, exc_value, tb)
File "/home/geonatadmin/gncitizen/backend/venv/lib/python3.8/site-packages/flask/_compat.py", line 39, in reraise
raise value
File "/home/geonatadmin/gncitizen/backend/venv/lib/python3.8/site-packages/flask/app.py", line 1950, in full_dispatch_request
rv = self.dispatch_request()
File "/home/geonatadmin/gncitizen/backend/venv/lib/python3.8/site-packages/flask/app.py", line 1936, in dispatch_request
return self.view_functionsrule.endpoint
File "/home/geonatadmin/gncitizen/backend/venv/lib/python3.8/site-packages/utils_flask_sqla/response.py", line 19, in _json_resp
res = fn(*args, **kwargs)
File "/home/geonatadmin/gncitizen/backend/gncitizen/core/observations/routes.py", line 630, in get_program_observations
raise e
File "/home/geonatadmin/gncitizen/backend/gncitizen/core/observations/routes.py", line 552, in get_program_observations
taxon_repository = mkTaxonRepository(taxhub_list_id)
File "/home/geonatadmin/gncitizen/backend/gncitizen/utils/taxonomy.py", line 82, in mkTaxonRepository
return sorted(r, key=lambda item: item["nom_francais"])
TypeError: '<' not supported between instances of 'NoneType' and 'str'
127.0.0.1 - - [07/Dec/2021 14:19:18] "GET /api/programs/6/observations HTTP/1.1" 500

from geonature-citizen.

J'ai obtenu un peu plus de résultat.

il y avait des valeurs nulles dans le champs nom_francais de bib_noms. En effet, j'ai du reprendre une liste basée sur taxref 12 dans une base taxref 14. Cela a visiblement conduit à des valeurs null dans le champs en question et fait planté l'outil.

J'ai pu obtenir un chargement normal avec dans le dictionnaire payload la clé,valeur "limit": 1000
Le chargement est plus long.
Lorsque je passe la valeur à 2000 par exemple, le problème se reproduit.
Est-ce le timeout ?, ou d'autres valeurs incriminées ??

Je vous remercie d'avoir consacré du temps à m'aider.

from geonature-citizen.

Super bien joué !
Merci pour tes retours.

Effectivement peut-être cela vient du timeout ici :

from geonature-citizen.

Le chargement est vraiment très long / trop long je pense pour un usage normal.
J'arrive à un plafond à 1752 lignes. Je n'ai pas trouvé pourquoi ...
Le timeout est en secondes ?

from geonature-citizen.

Ah oui effectivement, très bizarre...
Je n'ai pas l'habitude de faire des listes avec autant de taxons. C'est pour cela que j'aurai du mal à t'aider là dessus.
Oui le timeout est en secondes normalement

from geonature-citizen.

OK je fais une PR dans ce sens

from geonature-citizen.

En effet, il faut limiter au max les surcouches et redondances inutiles.

from geonature-citizen.

Pensez-vous que le travail nécessaire est long ?
"facile" à reprendre dans un serveur en cours d'utilisation ?

Merci !

from geonature-citizen.

J'ai un peu commencé, je vais essayer de continuer cette semaine mais je ne peux rien te garantir...

from geonature-citizen.

Super !
Merci beaucoup en tout cas.
Et effectivement ce sera surement une très bonne chose.
La requête remonte vraiment beaucoup d'informations.

from geonature-citizen.

Après de nouveaux tests, j'ai des résultats différents.
En mode développement
seul taxhub lancé +
source /venv/bin/activate)
python wsgi.py

L'appel api http://xyza/api/taxonomy/lists/10000/species retourne bien les près de 3000lignes demandées (+/-40sec). Aucune erreur n'apparait. Une fois les résultats obtenus, le front, même dans une fenêtre privée ou autre navigateur, se charge sans délais (cache du serveur ?)

Par contre, en redémarrant le fonctionnement normal, le problème réapparait ??
Pour l'instant j'ai eu un fonctionnement "opérationnel" après chargement de 30sec pour 2500lignes...

from geonature-citizen.

Oui, il ne faut vraiment pas un fonctionnement où l'on charge toute la liste, beaucoup trop long.
Mais utiliser une vraie auto-complétion avec la route indiquée par @TheoLechemia, comme dans le module Occtax de GeoNature, présenté ici : https://si.ecrins-parcnational.com/blog/2019-01-fuzzy-search-taxons.html

from geonature-citizen.

Je reviens sur ce premier sujet car un doute m'assaille.

Je ne suis pas sur que la solution de la liste avec autocomplétion résolve réellement le problème.
En effet, l'application présente une liste déroulante à gauche de l'interface "Toutes les espèces" hors cette liste semble alimentée de la même façon que la liste qui pose problème au moment de la saisie d'une observation.

Si c'est le cas, le problème de chargement de l'application délais + bug (deux problèmes en fait) ne sera pas résolu par l'implémentation d'une liste avec autocomplétion.

Si c'est le cas, serait-il possible de tenter de corriger le fonctionnement actuel :
tester la forme du dictionnaire pour éviter le plantage qui se produit lors de l'appel api (résultat de la requête).

ERROR Error: Cannot find a differ supporting object '[object Object]' of type 'object'. NgFor only supports binding to Iterables such as Arrays.

limiter le nombre d'information remontées par cette même requête pour réduire le temps d’exécution

???

Merci d'avance pour vos avis

from geonature-citizen.