Coastal Survey Automation

Architecture

Un seul projet Python 3, environ 9 400 lignes, sans aucune dépendance tierce à l'exécution. La géométrie et les calculs de coordonnées sont écrits à la main sur des dataclasses immuables (Point2D/3D, Vector2D, ReferenceLine, KP/Offset). Le cœur est une classe CoordinateSystem qui convertit des Easting/Northing en un système de référence linéaire le long de la ligne d'axe de chaque épi (projection sur un vecteur d'axe normalisé et sa perpendiculaire) et inversement, en remplacement d'un ancien jeu de fonctions éparses conservées en wrappers dépréciés. Les entrées-sorties sont un lecteur et un écrivain par format de relevé (TRK, TRS, PTS, LIS, LOG, CSV, PLI) sous un package io/. Les six étapes de traitement vivent dans generators/ (sur une classe Generator commune qui résout l'arborescence du projet) et dans des modules use_case/ autonomes, chacun avec son cli, sa config et son main. run.py est un registre de use cases : ajouter une étape fait environ cinq lignes et le menu interactif et l'aide en sont générés. Tout ce qui est propre au projet (les neuf couches de classes d'enrochement, la config d'emprunt d'extrémités entre couches avec KP exclus par relation, les règles de suppression de points d'axe, toutes les tolérances d'appariement) est dans des modules config/. Les chemins basculent selon l'OS (lecteur réseau Z: sous Windows, chemin POSIX sous Linux). Une couche de logging maison écrit un journal d'exécution horodaté par use case. La dernière étape est un classeur Excel piloté par environ 1 300 lignes de VBA qui importe les CSV générés, construit une feuille par couche avec IDs de points, séparateurs de sections et un bloc de contrôle, et insère une image de vue en plan.

Défis d’ingénierie

• Système de référence linéaire par épi : chaque ouvrage a sa propre ligne d'axe (lue depuis un fichier de jeu de lignes, avec un repli en dur), et chaque point a besoin de sa distance le long de l'axe et de son écart signé. C'est fait avec un vecteur d'axe normalisé et sa perpendiculaire, avec un contrôle aller-retour (E/N vers KP/offset puis retour) pour attraper une ligne de référence fausse avant qu'elle ne corrompe toute une feuille.
• Points d'axe manquants : les profils découpés ne portent pas toujours un point exactement sur l'axe aux sections attendues par la feuille. Là où un point manque et où il y a du relevé des deux côtés, l'outil en crée un, avec une profondeur interpolée par la distance entre les points gauche et droite les plus proches ; là où un côté manque, il laisse le trou plutôt que de deviner.
• Affecter les points de log à un épi et à une couche : les logs des engins sont un flux plat de coordonnées. Chaque point est transformé dans le système linéaire, testé contre les points de design dans des tolérances de KP, d'offset et de profondeur, et routé vers l'épi et la couche auxquels il appartient.
• Ordonner les points géographiquement pour la feuille : les points de l'axe principal sont triés par KP puis offset, et les semis des musoirs sont ajoutés dans un ordre gauche-centre-droite configuré, pour que la feuille se lise le long de l'ouvrage comme un inspecteur le parcourt.

Décisions techniques

• Pas de librairie tierce : la géométrie est simple et la cible de déploiement est un poste survey verrouillé sur un lecteur réseau. Écrire à la main les calculs vectoriels et les parsers a gardé l'outil sous forme d'un seul dossier copiable, sans rien à installer.
• Réutiliser la commande de découpe de profils du logiciel de relevé (gentrk) plutôt que de réimplémenter l'interpolation de surface : c'est le comportement de référence auquel l'équipe fait déjà confiance, et l'appeler en sous-processus était plus rapide et moins risqué que de le reconstruire.
• Toutes les règles métier en configuration, pas dans le code : classes d'enrochement, emprunt d'extrémités entre couches, KP exclus et tolérances changent d'un projet et d'une campagne de relevé à l'autre. Les garder dans des modules config/ fait d'un changement de règle une simple édition de donnée.
• Excel/VBA pour le dernier maillon : le livrable est une feuille formatée dans laquelle l'équipe survey travaille déjà. Générer les données en CSV et laisser une macro assembler le classeur a gardé la sortie dans leur outil au lieu d'en imposer un nouveau.
• Registre de use cases dans run.py : le pipeline a grandi étape par étape (logs, fusion, profils, semis de points, CSV, PLI). Un registre a fait de chaque étape un module autonome et du menu quelque chose d'auto-généré.