Modification non voulue des topologies

[jeromesourdin]

Bonjour,
Nous rencontrons des modifications non souhaités sur les topologies des itinéraires.
Nous avons en base un réseau de tronçons assez dense, et l'ors de modification des données attributaires, il arrive que la topologie de l'itinéraire soit modifiée sans que nous l'ayons demandé...
C'est particulièrement pénalisant sur les grands itinéraires.

[camillemonchicourt]

Les itinéraires (ainsi que la plupart des autre objets relatifs aux tronçons comme les interventions, les statuts, les aménagaments, les sentiers...) sont gérés en segmentation dynamique : https://geotrek.readthedocs.io/en/master/user-manual.html#edition-d-un-objet.
Leur géométrie est gérée et stockée relativement aux tronçons sur lesquels ils s'appuient, sous la forme d'une succession ordonnée d'évenements sur les tronçons qu'ils utilisent.

Cela a plusieurs avantages, dont le fait que quand on modifie de tronçons, l'ensemble des objets qui y sont liés restent automatiquement cohérents avec le tracé des tronçons sur lesquels ils s'appuient.

Mais c'est en même temps complexe, car tous les objets sont dépendants des tronçons.

Il y a 2 cas qui peuvent poser soucis :

1. Je supprime un tronçon utilisé par un itinéraire. Dans ce cas, cela créé un "trou" dans les tronçons utilisés par l'itinéraire et celui-ci est donc automatiquement et directement cassé. Il faut recréé un tronçon pour "reboucher" ce "trou" et reprendre l'itinéraire pour qu'il utilise ce nouveau tronçon. Idem si je modifie un tronçon utilisé par un itinéraire et que je modifie une de ses extrémités qui créerait une discontinuité dans l'itinéraire utilisant ce tronçon
2. J'ai créé un itinéraire utilisant plusieurs tronçons. J'ajoute un tronçon venant intersecter un des tronçons utilisés par l'itinéraire. Cela ne casse pas l'itinéraire en question car le cas est normalement géré de recalculer automatiquement les évènements sur les tronçons formant l'itinéraire. Par contre, quand j'ouvre en modification l'itinéraire, son tracé est recalculé automatiquement et dynamiquement en fonction des évènements sur les tronçons qu'il utilise. Le fait d'avoir ajouté un nouveau tronçon peut alors amener à calculer un parcours différent si un chemin plus court entre les points intermédiaires est alors calculé du fait de l'ajout de nouveaux tronçons. A ce moment-là, même si je ne modifie que les attributs de l'itinéraire, c'est le nouveau tracé qui va être enregistré.

De ce que je comprends, c'est le cas 2 que tu évoques ici. Il est assez logique et n'est pas vraiment un bug, même si ce comportement n'est pas souhaitable. A voir quelles évolutions pourraient être envisagées pour améliorer ce point ?

[gutard]

De ce que je comprends, c'est le cas 2 que tu évoques ici.

C'est ça.

Il est assez logique et n'est pas vraiment un bug

Ce n'est pas un bug d'implémentation. Mais ça peut être considéré comme un bug de conception.

même si ce comportement n'est pas souhaitable.

Il ne l'est clairement pas. Personne ne s'attend à ce que le tracé soit modifié silencieusement quand on va éditer une donnée attributaire.

A voir quelles évolutions pourraient être envisagées pour améliorer ce point ?

L'idée est que, au moment de l'édition, l'algorithme de routage rajoute automatiquement les points de passages nécessaires pour que le tracé soit conservé.

Algo empirique : pour chaque portion entre points de départ/arrivée/passage, on compare l'ancienne route avec la nouvelle (plus court chemin en tenant compte des tronçons ajoutés entre temps). On part du début et on trouve le point d'intersection A à partir duquel les deux routes divergent. On fait la même chose pour le point B en partant de la fin. Ensuite, on place un point de passage obligatoire au milieu du tronçon du milieu entre A et B. Et on recommence au début tant que les deux routes ne sont pas identiques.

[camillemonchicourt]

Oui c'est en effet pas souhaitable.
OK intéressant comme piste d'amélioration, solution de ce problème.
Merci.

[jeromesourdin]

Une remarque @camillemonchicourt :

De ce que je comprends, c'est le cas 2 que tu évoques ici.

Oui et non. Nous avons remarqué que s'il y a deux tronçons proches (qui se rejoignent), il arrive que le phénomène se produise. Cela à l'air aléatoire...

Une question @gutard :

L'idée est que, au moment de l'édition, l'algorithme de routage rajoute automatiquement les points de passages nécessaires pour que le tracé soit conservé.

Cela ne risque pas de dégrader les temps de réponses ? L'affichage est déjà long pour les grands itinéraires, cela serait embêtant de l'alourdir plus...

[gutard]

Cela ne risque pas de dégrader les temps de réponses

Je ne pense pas. En tout cas ça dépendra de l'ampleur des changements du réseau sur le tracé.

[JoelAtche]

Bonjour, je me permet de confirmer que ce problème est bien conséquent sur notre Geotrek PNR des Grands Causses et de l' Aubrac, depuis que nous avons ajouté de nombreux tronçons de route pour le cyclo notamment, ou des pistes en parallèle de monotrace pour le Gravel par exemple. Nous avons eu plusieurs itinéraire impacté, j'ai du demandé aux nombreux contributeurs d'être très vigilant lors de modification! En attendant que l'on puisse financer cette amélioration imaginé par Gaël, j'ai conseillé aux utilisateurs de rajouter manuellement de nombreux point de passage obligatoire sur les nouveaux itinéraires, et sur les existant déjà publiés de télécharger le GPX du circuit avant de rentrer en modification, pour contrôler le tracé avant de sauvegarder!!!

[gutard]

On a détecté un autre problème qui casse les topologies. Lors du découpage d'un tronçon, les agrégations sont dupliquées, mais les deux conservent leur numéro d'ordre en commun alors qu'il faudrait tout renuméroter. Du coup, il y a une chance sur deux pour que l'ordre ne soit pas respecter ce qui casse la topologie. Nous somme en train d'y travailler mais le sujet est assez complexe et il est bien moins confortable de travailler sur les triggers en PL/pgSQL que sur le code en Python.

[jeromesourdin]

il est bien moins confortable de travailler sur les triggers en PL/pgSQL que sur le code en Python.

Ça, je comprends !!!

[camillemonchicourt]

Dans certains cas, quand les topologies des randos cassent, la rando devient un point. Pour identifier celles-ci :

SELECT id, st_geometrytype(geom) FROM core_topology
WHERE kind='TREK' AND st_geometrytype(geom)='ST_Point';

[JeanLenormand]

Bonjour,

Lors du déploiement de la https://viacolumbani.com/ nous avons aussi rencontré ce délicat problème.

Sur certains itinéraires parents aux distances conséquentes, lors de l'ouverture de la fiche d'un itinéraire (dont le tracé a déjà été réalisé en amont), après chargement du tracé, celui-ci est modifié. Ces modifications d'itinéraires apparaissaient généralement toujours au même endroit, avec un ou plusieurs points de passage obligatoire (points jaunes) qui disparaissaient ou les points de départ/arrivée qui étaient modifiés de quelques centaines de mètres.
A chaque édition des données attributaires d'un itinéraire, il fallait donc aussi revoir le tracé... Et je ne pense pas que cela était dû à d'éventuelles modifications de tronçons.

Je viens de faire part de l'ouverture de ce ticket au responsable du projet. En fonction des solutions trouvées, nous verrons s'il nous est possible de participer à ce correctif. D'ici là, si je peux aider le groupe de travail, en réalisant des tests précis par exemple, je reste disponible.

[AudreyRemy]

Bonjour,
Nous rencontrons le même problème dans le 64. Pour le moment la bdd ne contient que les itinéraires départementaux mais les PLR vont être intégrés. De nombreux tronçons vont donc être créés et croiser des tronçons existants. Dès les premiers tests de création de tronçons pour l'implantation d'un PLR nous avons constaté la modification silencieuse de certains itinéraires.
J'ai bien noté la solution temporaire des points passages.
Merci et bonne journée

[jeromesourdin]

Quelques test ce matin !
Je confirme ce qu'a constater @amandine-sahl : quand le profile altimétrique est cassé, la geom du trek est multilinestring. Le trek n'apparait pas pour autant dans les topologies invalides (Peut-être une amélioration a prévoir du filtre des topologies invalides).

[camillemonchicourt]

Une analyse complémentaire du sujet est lancé.

• Synthèse de la première analyse : https://geotrek.ecrins-parcnational.fr/ressources/gt/12-topologies/2021-10-22-MakinaCorpus-CD22-Analyse.pdf
• Dossier de ressources : https://geotrek.ecrins-parcnational.fr/ressources/gt/12-topologies/
• Suivi du projet : https://github.com/GeotrekCE/Geotrek-admin/projects/5
• Echanges et compléments sur la liste de diffusion : https://groups.google.com/g/geotrek-fr/c/QUktGK2HFek

[camillemonchicourt]

Les 2 jours d'analyse complémentaire ont permis de préciser les soucis rencontrés, et identifier des pistes de correction : https://geotrek.ecrins-parcnational.fr/ressources/gt/12-topologies/2021-11-18-MakinaCorpus-PNC-Analyse.pdf

[camillemonchicourt]

Parmi les pistes pour limiter le soucis lié au fait que lorsque l'on modifie un itinéraire (ou autre objet topologique linéaire) et que des tronçons ont été ajoutés entre temps, créant un chemin plus court différent qui modifie le tracé de l'itinéraire quand on modifie et enregistre celui-ci, une améliorations proposée est "Lors d’une modification, afficher la géométrie originale pour que l’utilisateur soit averti d’un éventuel changement à la sauvegarde (prévention modification non souhaitée)".

Cela serait utilise et intéressant, mais j'ai pensé à une amélioration complémentaire.

Le soucis se produit surtout quand on veut juste modifier quelques infos attributaires d'un itinéraire et que cela modifie son tracé à l'insu de l'utilisateur car un chemin plus court a été trouvé au chargement du tracé de l'itinéraire.

Ma proposition serait donc que quand on passe en modification d'un objet, on ne soit pas directement en modification de sa géométrie. En ouvrant le formulaire, la partie carte serait en mode consultation, on n'afficherait donc que l'objet à partir de son champs "geom".
Ainsi l'utilisateur pourrait uniquement modifier les attributs sans risque sur la géométrie de l'objet.
L'utilisateur pourrait choisir de passer la géométrie en mode modification. C'est seulement là que la géométrie se chargerait à partir de la topologie et que l'utilisateur pourrait la modifier.
Dans ce cas là, la possibilité d'afficher en parallèle la géométrie précédente de l'objet (son champs "geom") serait utile pour qu'il voit si le tracé est différent.

[JoelAtche]

Je valide à 100% ta solution Camille, elle a l'avantage de correspondre à 95% des cas sur mon territoire où ce sont les OT qui veulent juste changer des infos attributaires et pas la géométrie de l'itinéraire.

[jeromesourdin]

Si je ne m'abuse, cette solution a déjà été évoqué, et, toujours si je ne m'abuse, la topologie n'est pas modifiée si seule les données attributaires sont modifiées. A confirmer par un expert ;)

[camillemonchicourt]

Les points 3.1 (Add filter valid geometries on topologies) et 3.3.1 (Add setting ALLOW_PATH_DELETION_TOPOLOGY which protect or not against deletion of path with topologies linked to it) ont été intégrés dans la version 2.84.0 de Geotrek-admin.

• Le premier point concerne l'ajout d'un filtre "Géométrie valide" en plus du filtre "Topologie valide" existant

3.1 Problème avec le filtre

Le filtre servant à identifier les topologies cassées n’indique pas forcément les géométries invalides.
En effet, il se peut que les topologies soient dites « cassées » sans altérer la géométrie finale. Par exemple si un tronçon B découpe un tronçon A parcouru par un itinéraire, les deux tronçons A et A’ porteront le même ordre dans l’agrégation de l’itinéraire. La topologie sera considérée comme cassée. Or, il s’agit apparemment du comportement historique de Geotrek. Tant que le bon ordre est remonté dans la requête SQL (partie aléatoire du problème), la géométrie n’est pas altérée.
Solution court terme : différencier les deux filtres

• 1 pour les problèmes topologiques (ordre non respecté, trou)
• 1 autre pour les géométrie cassées (linéaires différents de LineString (cas MultiLinestring et Point) → important pour savoir si un itinéraire publié est cassé

• Le deuxième point concernant l'ajout du paramètre ALLOW_PATH_DELETION_TOPOLOGY (à true) par défaut permettant de bloquer la suppression d'un tronçon utilisé par une topologie (itinéraire, POI, intervention, signalétique...), en passant le paramètre à false (au niveau de l'interface mais aussi de la base de données)

[LePetitTim]

Les problèmes sont lié à #1348

[LePetitTim]

La solution finalement proposé pour resoudre les problèmes d'ordre des topologies est une nouvelle commande qui sera lancé régulièrement pour reordonner tous les PathAggregations pour éviter d'avoir des topologies dont la geometrie est un MultilineString.

Elle utilise ft_smartMakeline qui est la fonction permettant de retrouver une lignestring à partir des PathAggregations. Elle peut trouver même lorsque l'ordre n'est pas bon.

Il ne marche pas dans tous les cas, lorsque la géometrie est cassé (manque de pathaggregation | pathaggregation dont l'ordre ne permet pas de retrouver ...)

Il restera à corriger :

• La possibilité de créer des topologies sous forme de multilinestring (deserializer + js).
• La transformation des Lignes en point lorsqu'un point de passage se trouve sur la fin ou le debut du tronçon découpé.
• Corriger à la source les problèmes de reordonnement

#3296

[camillemonchicourt]

La commande reorder_topologies a été intégrée dans la version 2.90.0 de Geotrek-admin et documentée (https://geotrek.readthedocs.io/en/2.90.1/install/import.html#reorder-topologies).

Je l'ai testée sur le serveur de DEMO.

Avant de la lancer le filtre "Topologie valide" me renvoyait 22 randos non valides. Après lancement de la commande, il n'en renvoyait plus que 7 randos non valides.

En effet les 7 randos qu'il n'a pas pu corriger sont celles qui ont aussi leur géométrie non valide.

La commande a renvoyé :

~$ sudo geotrek reorder_topologies
Read env configuration from /opt/geotrek-admin/lib/python3.6/site-packages/geotrek/settings/env_prod.py
Read custom configuration from /opt/geotrek-admin/var/conf/custom.py
51 topologies has beeen updated
Topologies with errors :
TREK id: 989
LANDEDGE id: 968
TREK id: 957
TRAIL id: 958
TREK id: 712
TREK id: 469
TREK id: 798
TREK id: 797
TREK id: 1021
TREK id: 452

Un élément qui me semble bizarre est que quand je relance la commande plusieurs fois de suites, il me ré-indique à chaque fois qu'il a update une topologie :

1 topologies has beeen updated

Sans avoir rien changé, il ne devrait pas en remettre une à jour à chaque fois.

Je ne l'ai pas encore lancé en production, car je ne sais pas si cela peut avoir des effets de bord sur certains objets ? Les supprimer ? Les dépublier ?

PS : Le message de la commande ("51 topologies has beeen updated") devrait être changé en "51 topologies have been updated".

[jeromesourdin]

Pour ma part, j'ai testé sur une copie de notre serveur de production, et plus de 3700 topologie ont été mise à jour !
Y a-t-il un log qui conserve les id et type des éléments corrigés ?

Les premiers tests sur les trek sont concluants

	Modification	Visualisation
Avant
Après

On voit qu'avant le passage de la procédure l'itinéraire affiché n'est pas le même qu'en modification, alors qu'une fois la procédure passée, l'itinéraire en modification est conforme à la visualisation ! C'est de bon augure !

Nous poursuivons les tests...

[LePetitTim]

Y a-t-il un log qui conserve les id et type des éléments corrigés ?

Il y a un log si tu mets -v 1 dans tes options à la commande

Un élément qui me semble bizarre est que quand je relance la commande plusieurs fois de suites, il me ré-indique à chaque fois qu'il a update une topologie :

1 topologies has beeen updated

Sans avoir rien changé, il ne devrait pas en remettre une à jour à chaque fois.

On a remarqué le problème. Je pense pas que ca pose problème, mais ca reste étrange. Ca doit arriver lorsque tu as 2 paths aggregations qui passent dans le meme ordre.

Les 2 pathaggregations representent la meme chose.

[camillemonchicourt]

OK merci pour ces retours.

[thomasmagninfeysot]

Salut à tous, petit retour de mon côté, idem après avoir résolu mes erreurs topologiques, j'ai toujours 265 topologies qui sont updatées à chaque fois que je lance la commande.

[justinefricou]

Bonjour,

Suite à plusieurs tests de découpage de tronçons parcourus par des itinéraires, il apparaît que la topologie est mise à jour correctement seulement si :

• la direction de l’itinéraire est opposée à celle des tronçons qu’il parcourt ;
• le tronçon que parcourt l’itinéraire n’a qu’un seul point d’intersection avec le tronçon nouvellement créé (en somme, le tronçon est coupé seulement en deux).

Quelques exemples dans ce PDF :

modifications-de-topologies-lors-du-decoupage-de-troncons.pdf

[camillemonchicourt]

Merci pour ces tests et retours qui donnent des indications précieuses sur les cas qui posent soucis en terme de découpage des tronçons.

Concernant le sujet central et initial de ce ticket (modifications non voulues des topologies quand on modifie une topologie après avoir ajouté des tronçons qui créé des chemins plus courts) a été corrigé dans le cadre du gros travail de @justinefricou sur le déplacement du calcul du routing (chemin le plus court) côté serveur (backend).
Celui-ci est détaillé et bien documenté (avec des documents complets sur les gains de performance) ici : #4286