Découpage d'un tronçon : topologies dupliquées / notées comme `deleted` / géométries 2d supprimées

[justinefricou]

Le bug remonté à l’origine était le non-affichage des positions des lames sur la carte, dans la vue liste.

Après investigation il s’est avéré que le problème d’affichage provenait d’une incohérence dans les données des topologies stockées en base. Cette incohérence est due à un bug dans les triggers SQL lors de l’ajout d’un tronçon.

Une première investigation a conduit aux résultats présentés ci-dessous.

Flot d’exécution conduisant au bug

Voici une partie du déroulé des triggers qui conduit au problème remonté. Une investigation plus poussée serait nécessaire pour déterminer la source exacte du bug lors de l’ajout du tronçon.

1. On ajoute un tronçon qui touche deux autres tronçons (pas sur leurs extrémités) : un trigger lance l’exécution de paths_topology_intersect_split qui va couper les deux tronçons existants en deux.

2. Dans cette fonction, pour couper un tronçon en deux sous-tronçons :

   • On réduit sa géométrie pour qu’elle corresponde à celle du 1er sous-tronçon.
   • On duplique le tronçon en un nouveau tronçon dont la géométrie correspond à celle du 2e sous-tronçon.
   • On ajuste les path aggregations des topologies liées au tronçon originel, pour qu’elles correspondent aux nouvelles géométries des sous-tronçons.
     C’est de cette étape que provient le bug. Certaines path aggregations sont créées ou modifiées de manière erronée (associée au mauvais tronçon et/ou à la mauvaise fraction de départ ou arrivée).
     Il reste à déterminer pourquoi.

3. A la fin de paths_topology_intersect_split, on supprime des path aggregations qui ne sont plus d’actualité suite aux modifications dans les tronçons. Cette suppression se fait en fonction du tronçon lié et des positions de départ et arrivée. Hors, c’est précisément les données associées de manière erronée à l’étape précédente. Certaines path aggregations sont donc supprimées alors qu’elles ne devraient pas l’être, et inversement. Cette suppression intervient ici :
   

   Geotrek-admin/geotrek/core/templates/core/sql/post_50_paths_split.sql

   Lines 426 to 428 in 5f8c704

   	DELETE FROM core_pathaggregation et WHERE et.path_id = path.id
   	AND id = ANY(existing_et)
   	AND (least(start_position, end_position) > b OR greatest(start_position, end_position) < a);

4. Ces suppressions déclenchent des triggers qui lancent l’exécution des fonctions suivantes :

   • ft_topologies_paths_geometry : fait passer geom_need_update à True pour chaque ligne
   • ft_topologies_paths_geometry_statement : on boucle sur les topologies dont geom_need_update est à True pour appeler update_geometry_of_topology sur chacune d'elles

5. Dans update_geometry_of_topology, on passe les colonnes deleted à True et geom à NULL quand la topologie n’est plus liée à aucun tronçon via des path aggregations (t_count = 0). Pour certaines topologies, toutes leurs paths aggregations ont été supprimées de manière erronée. Ce traitement est donc exécuté sur ces topologies alors qu’il ne devrait pas l’être :
   

   Geotrek-admin/geotrek/core/templates/core/sql/post_20_topologies.sql

   Lines 79 to 81 in 5f8c704

   	IF t_count = 0 THEN
   	-- No more paths, close this topology
   	UPDATE core_topology SET deleted = true, geom = NULL, "length" = 0 WHERE id = topology_id;

   
   Ainsi, les topologies ne sont pas supprimées de la base de données, mais notées comme deleted : elles n’apparaissent donc plus dans l’interface.
   Note : on se retrouve également avec plusieurs path aggregations pour une même topologie ponctuelle ayant un offset non nul, alors qu’il ne devrait y en avoir qu’une

6. Dans le cas des signalétiques, celles notées comme deleted de cette manière ont donc des lames avec un deleted à False. Sur la vue liste des lames, on tente d’afficher la position de la lame, qui correspond à celle de la signalétique. Hors, sa geom est NULL, ce qui lève une erreur : aucune position n’est alors affichée sur la carte.

Comparaison de deux cas proches, avec et sans bug

En tentant de reproduire le bug avec deux bases de données dont la seule différence est la présence ou non d'une topologie ponctuelle spécifique, on a deux cas :

• un cas où on reproduit le bug : la topologie n'est pas présente
• un cas où on ne reproduit pas : la topologie est présente

Cela laisse à penser que le bug peut provenir, par exemple, du nombre de topologies traitées par tronçon, de leur ordre de traitement, etc.

Le but est d’analyser deux exécutions avec des différences les plus minimes possibles, afin de déterminer lesquelles sont normales et lesquelles sont liées au bug.

Analyse des path aggregations supprimées / conservées

Pour rappel, cette section analyse le comportement à cet endroit du code :

Geotrek-admin/geotrek/core/templates/core/sql/post_50_paths_split.sql

Lines 426 to 428 in 5f8c704

	DELETE FROM core_pathaggregation et WHERE et.path_id = path.id
	AND id = ANY(existing_et)
	AND (least(start_position, end_position) > b OR greatest(start_position, end_position) < a);

NEW correspond au tronçon qui a été rajouté manuellement, et path correspond à un des tronçons étant coupé en deux (celui auquel est rattachée la signalétique posant problème).

En comparant, avant toute suppression, les path aggregations liées aux tronçons impactés par l'ajout (c’est-à-dire les tronçons préexistants, le tronçon créé qui va déclencher les triggers, et les deux tronçons qui seront créés via la découpe des deux tronçons préexistants) dans les cas buggé/non-buggé, on s'apperçoit de plusieurs choses :

• certaines topologies sont associées au mauvais tronçon et aux mauvaises positions de départ et d’arrivée (start_pos et end_pos)
• certaines sont associées au bon tronçon mais aux mauvaises positions
• certaines sont associées au mauvais tronçon mais aux bonnes positions

A cet endroit du code, on doit supprimer les path aggregations qui :

• ne touchent pas le premier intervalle sur intersections_on_current. Dans les deux cas (avec et sans bug), lors de la suppression on a bien les mêmes valeurs pour intersections_on_current et pour l'intervalle utilisé
• étaient liées au tronçon path (attention, pas NEW) avant son traitement (contenu de existing_et).
  -> A faire : déterminer si le contenu de existing_et est correct dans le cas buggé

On a donc une suppression qui se fait sur un jeu de données a priori erronées (topologies liées au mauvais tronçon/sur la mauvaise position), avec des conditions dont la validité reste à déterminer (contenu de existing_et).

Deuxième comparaison entres les cas buggé/non-buggé : les path aggregations supprimées et restantes. On observe également des différences :

• Cas buggé :

  • 5 agrégations supprimées :
    • id=425740, topo_object_id=262911, path_id=9682, start_position=0.924699668093843, end_position=0.924699668093843, order=35
    • id=425741, topo_object_id=262911, path_id=9682, start_position=0.924699668093843, end_position=1, order=36
    • id=529294, topo_object_id=338176, path_id=9682, start_position=1, end_position=0.24518393077929404, order=14
    • id=529295, topo_object_id=338176, path_id=9682, start_position=0.24518393077929404, end_position=0.24518393077929404, order=15
    • id=431326, topo_object_id=337541, path_id=9682, start_position=0.4207541435333057, end_position=0.4207541435333057, order=0
  • 6 agrégations restantes :
    • id=442331, topo_object_id=338178, path_id=9682, start_pos=1, end_pos=0
    • id=425739, topo_object_id=262911, path_id=9682, start_pos=0, end_pos=0.924699668093843
    • id=444398, topo_object_id=338240, path_id=9682, start_pos=0, end_pos=1
    • id=529296, topo_object_id=338176, path_id=9682, start_pos=0.24518393077929404, end_pos=0
    • id=522174, topo_object_id=343546, path_id=9682, start_pos=1, end_pos=0
    • id=530082, topo_object_id=328566, path_id=9682, start_pos=0, end_pos=0

• Cas non-buggé :

  • 6 agrégations supprimées :
    • id=425740, topo_object_id=262911, path_id=9682, start_position=0.924699668093843, end_position=0.924699668093843, order=35
    • id=425741, topo_object_id=262911, path_id=9682, start_position=0.924699668093843, end_position=1, order=36
    • id=529294, topo_object_id=338176, path_id=9682, start_position=1, end_position=0.24518393077929404, order=14
    • id=529295, topo_object_id=338176, path_id=9682, start_position=0.24518393077929404, end_position=0.24518393077929404, order=15
    • id=420569, topo_object_id=328569, path_id=9682, start_position=0.580280821607769, end_position=0.580280821607769, order=0
    • id=442471, topo_object_id=338208, path_id=9682, start_position=0.5955594603545296, end_position=0.5955594603545296, order=0
  • 10 agrégations restantes :
    • id=442331, topo_object_id=338178, path_id=9682, start_pos=1, end_pos=0
    • id=425739, topo_object_id=262911, path_id=9682, start_pos=0, end_pos=0.924699668093843
    • id=444398, topo_object_id=338240, path_id=9682, start_pos=0, end_pos=1
    • id=529296, topo_object_id=338176, path_id=9682, start_pos=0.24518393077929404, end_pos=0
    • id=522174, topo_object_id=343546, path_id=9682, start_pos=1, end_pos=0
    • id=431326, topo_object_id=337541, path_id=9682, start_pos=0.0973067911163345, end_pos=0.0973067911163345
    • id=530081, topo_object_id=328566, path_id=9682, start_pos=0, end_pos=0
    • id=530089, topo_object_id=337559, path_id=9682, start_pos=1, end_pos=1
    • id=530091, topo_object_id=337560, path_id=9682, start_pos=1, end_pos=1
    • id=530093, topo_object_id=343067, path_id=9682, start_pos=1, end_pos=1

Pistes et prochaines étapes proposées

Avec les évolutions à venir concernant la segmentation dynamique/le référencement linéaire (#4982), il est possible que ces erreurs deviennent moins critiques à moyen terme :

• Avec le découplage/recouplage, les linéaires cassés seront identifiables et réparables
• Si à terme les ponctuels ne sont plus des topologies, il n'y aura plus de problème pour les géométries de type Point. Il reste à déterminer dans les prochaines semaines si cette option sera retenue.

Dans tous les cas, ces évolutions ne seront disponibles qu'à moyen terme.
Si la résolution du bug remonté (problème d'affichage des lames), mais surtout du bug sous-jacent qui est plus critique (passage de certaines topologies à deleted + suppression de leur géométrie 2d) est urgente, il est donc possible de pousser l'analyse pour comprendre d'où provient le bug dans paths_topology_intersect_split.

Dans ce cas de figure, voici les prochaines étapes proposées :

• Poursuivre la comparaison des path aggregations avant/après suppression dans les deux cas (bug/sans bug)
• Déterminer si le problème vient seulement des path aggregations étant modifiées ou créées de manière erronée, ou si la valeur de existing_et est également incorrecte
• En plus de comparer le cas buggé avec celui non buggé, comparer le cas non buggé avec un autre cas proche non buggé, afin de déterminer quelles différences sont dues au bug et lesquelles sont simplement dues à la différence dans le nombre de topologies existantes

[camillemonchicourt]

OK merci pour cette investigation et cette synthèse précise et complète.
Dans tous les cas, il serait utile de fixer le(s) soucis identifié, même si il devient critique.
A voir en effet quand et comment.