Think about decoupling

[gutard]

Problèmes constatés :

• Les modifications du référentiel font souvent perdre la connectivité des tronçons ce qui casse les itinéraire sans prévenir.
• Lorsqu'on modifie un itinéraire pour changer un attribut, on redéclenche un routage sans s'en rendre compte. Si un nouveau tronçon vient raccourcir le trajet entre deux points de passage, le tracé de l'itinéraire est modifié sans qu'on s'en rende compte.
• La modification d'un tronçon modifie la position des ponctuels alors qu'on ne le souhaite généralement pas.
• Le référentiel de tronçon est un pivot qui ne permet pas de lier certaines couches entre elles. Par exemple un POI et une signalétique.
• Au creux d'un patte d'oie, un POI s'accroche uniquement sur l'un ou l'autre des 2 doigts alors qu'il concerne généralement les deux.
• Une modification du tracé peut fausser le statut physique ou foncier qui lui est attaché.
• …

Proposition :

• On conserve le principe du routage. A sa création, toute topologie est forcément couverte par le référentiel.
• Après, création, les topologies sont indépendantes du référentiel et ne sont pas impactées par une modification du référentiel.
• Par contre, lors d'un modification du référentiel, une popup en informe l'utilisateur qu'il existe des topologies qui ne sont plus sur le référentiel.
• Lorsqu'un statut/itinéraire/intervention linéaire n'est plus couvert à 100% par le référentiel, une pastille rouge identifie les couches qui contiennent de telles géométries dans le menu de gauche
• De même pour les éléments dans la vue liste.
• Dans la vue détail, les portions non couvertes par le référentiel apparaissent en rouge.
• La vue modification ne reroute pas automatiquement lors de l'ouverture de la page. Le reroutage n'est déclenché que lorsqu'on ajoute/modifie un point de passage obligatoire et uniquement pour les 2 portions de routage en amont et en aval de ce point.
• Les agrégations sont généralisées sous forme de table d'association. Au lieu de lier des topologies à des tronçons cette table permet de lier n'importe quelle géométrie à n'importe quelle autre. Elle garde le principe d'enregistrer des pk début/fin (mais plutôt en absolu qu'en %) ce qui permet de conserver la notion d'ordre (ex. dans quel ordres sont rencontrés les POI sur un itinéraire).
• La notion de lien entre les couches qui fait la force et l'originalité de Geotrek est donc conservée et même renforcée.
• La table de liaison est maintenue par du code Python. En cas d'import de données directement en SQL, une commande de management Django permet de la remettre à jour.
• En première approche, la table de liaison est alimentée automatiquement par relation géométrique (buffer pour les relations Point/Point et Point/Linestring, et intersection pour le reste).
• La porte reste ouverte pour raffiner cette approche de base : gestion manuelle, plus proche, distance max par routage, etc.

[camillemonchicourt]

Un autre problème majeur du système actuel est qu'il est difficile d'importer donc de partager des objets linéaires comme des itinéraires, des interventions linéaires... entre Geotrek-admin ou avec d'autres outils.

Cependant le point de vigilance majeur est que le système actuel garantit un niveau fort de qualité de la donnée, une cohérence des tronçons et des itinéraires entre eux, permis par la segmentation dynamique (https://makina-corpus.com/blog/metier/2014/la-segmentation-dynamique). L'autre point de vigilance est qu'actuellement le mécanisme est commun et global à Geotrek-admin. Si on change le fonctionnement, cela peut complexifier la compréhension avec des messages à l'utilisateur, et une hétérogénéité des liens et règles entre objets.