Performances liées à des géométries complexes

[bruhnild]

Problème :

Certaines géométries trop complexes provoquent un ralentissement significatif de l'API de Geotrek-admin. Cela se manifeste par des problèmes d'affichage, notamment pour ce site outdoor : Barthes de la Nivelle

• Sur le portail rando Nature64, l'affichage est impossible.
• Dans Geotrek-admin, le chargement est extrêmement lent.

Solutions envisageables :

1. Simplification des géométries en base de données
   Mettre en place une fonction trigger pour appliquer une simplification automatique des géométries avant leur insertion en base de données.

   • Avantage : Réduit la complexité directement en base, ce qui améliore les performances globales.
   • Inconvénient : La géométrie initiale, précise, n'est pas conservée en base.

2. Simplification des géométries côté front
   Appliquer une simplification des géométries au moment de leur affichage dans l'interface utilisateur (portail rando et Geotrek-admin).

   • Avantage : Les données précises restent stockées en base.
   • Inconvénient : Solution potentiellement plus complexe à développer et à maintenir ?

[camillemonchicourt]

Ce que l'on voit à l'écran n'est qu'une seule géométrie ?

Dans le module Outdoor, on a implémenté le fait qu'un site pouvait être une collection de plusieurs géométries, mais de mon côté je n'avais pas bien compris ni demandé cela, et je ne suis pas certain que cela soit une bonne chose ou vraiment utile ?
Un point, une ligne ou un polygone classique c'est suffisant, non ?
Ensuite si besoin de détailler, on fait des sous-sites et des parcours. J'avais plutôt ça en tête, mais peut-être que les GeometryCollection sont utiles et essentielles ?

En tout cas, que cela soit pour les sites Outdoor ou les randos, je ne suis pas favorables à les simplifier géométriquement avant de les intégrer dans la BDD. Il faut en garder et stocker la géométries d'origine précise. Pour avoir la donnée précise, pour les calculs d'intersection, etc...
Je ne pense pas non plus que c'est au front de simplifier les géométries.

Par contre, je serai très favorable à renvoyer dans l'API des géométries simplifiées (stockées dans la BDD pour des questions de performance ou simplifiées à la volée pour plus de souplesse).
Souvent dans Geotrek-rando ou d'autres usages, une géométrie simplifiée est suffisante pour la page de recherche par exemple.

[marcantoinedupre]

En tout cas, que cela soit pour les sites Outdoor ou les randos, je ne suis pas favorables à les simplifier géométriquement avant de les intégrer dans la BDD. Il faut en garder et stocker la géométries d'origine précise. Pour avoir la donnée précise, pour les calculs d'intersection, etc...

À mon avis ces problèmes de lenteur sont précisément dus aux calculs d'intersection avec une géométrie complexe (celle-ci est composée de beaucoup de positions apparemment). Actuellement les intersections sont calculés à chaque demande de page pour GTA et une seule fois pour l'API (grâce au cache API) jusqu'à la prochaine modification.

Une autre solution plus lourde à mettre en oeuvre serait de faire les intersections à la modification de la donnée dans GTA, dans des tâches asynchrones. Et de stocker les liens de proximité dans la BDD.

• Côté GTA il y aurait donc potentiellement les informations sur les contenus proches qui ne seraient pas affichés immédiatement. Mais on aurait des spinners/placeholders et la page pourrait rester fonctionnelle contrairement à aujourd'hui.
• Côté GTR/API on dirait bye-bye 🤞 aux problèmes de performances.

Il faudrait vérifier que c'est bien l'étape de calcul des intersections qui est responsable de ce problème.

[camillemonchicourt]

Ah oui si le soucis ne sont pas l'affichage des géométries complexes, mais les intersections géographiques à la volée avec d'autres objets, alors cela serait intéressant de stocker celles-ci.
A mon souvenir, initialement dans la V1 de Geotrek-admin, on stockait les intersections des événements topologiques avec les communes et autres zonages.
Sujet aussi évoqué dans d'autres contextes comme #3243.

Mais bon, ça ferait pas mal de stockage et de triggers (car il ne faut pas dépendre uniquement de l'applicatif pour ces stockages d'intersections calculées si on modifie ou insère des données directement dans la BDD).

[submarcos]

Alors je confirme que dans le cas présent ce n'est pas l'API mais le calcul pour récupérer les objets liés le pb. l'API répond dans des temps tout à fait acceptable de l'ordre de dizaines de ms. Après, comme évoqué précédemment sur les performances en général, tous les objets non liés topologiquement (dont site, contenus touristiques, ou instances sans segmentation dynamiques) sont très sensibles à la complexité des géométries.
Dans ce cas le simple fait d'afficher la page détail de l'admin déclenche énormément de calculs complexes.
Ceci dit, un des prochains développements réalisés sur les perfs permettra de ne déclencher ces calculs que lorsqu'on souhaite afficher les infos des objets liés, ce qui résoudra le problème en grosse partie.