Découpage SQL des voies
Le découpage produit des tronçons et sommets à partir du référentiel osm2pgsql intégré. Il est optionnel et fournit surtout un réseau découpé pour les usages aval. Ce n'est ni un moteur d'itinéraires complet ni un système de rattachement métier à identifiants stables.
Déclenchement
Le service d'intégration demande un découpage après sa phase d'exécution. Un timer nocturne distinct planifie également un calcul. Le traitement examine sa configuration et sa raison : un appel après intégration en mode check ne publie pas de tronçons.
L'entrée est python/lbt-rebuild-segments.py, avec les raisons after-integration, nightly ou manual. Le paramètre db_pgr_update active la fonctionnalité. Consultez Installation pour les services et variables en vigueur.
Publication
- Verrouiller les accès nécessaires pour travailler sur un référentiel cohérent.
- Construire le réseau dans des tables de travail et contrôler géométries et extrémités.
- Verrouiller les tables publiées et remplacer tronçons et sommets dans une transaction.
- Actualiser les statistiques et enregistrer résultat et intégration source.
Un échec avant commit annule la publication. Il n'annule pas une intégration OSM déjà réussie. Le référentiel peut donc être plus récent que le dernier découpage publié.
L'algorithme fourni est identifié dans les rapports par legacy-sql-isolated-ways-v1, avec une publication transactional-replace. Ses règles de construction s'appliquent ; un croisement géométrique de lignes ne doit pas être supposé navigable. Examinez la topologie source et les données dérivées pour votre usage.
Identifiants et consommateurs
stable_segment_ids=false est explicite : les identifiants générés ne sont pas garantis stables entre deux calculs. Les applications aval ne doivent pas en faire des clés métier durables. Conservez les informations OSM/source utiles et prévoyez une réconciliation distincte si un futur rattachement le nécessite.
La publication peut bloquer temporairement les lecteurs des tables concernées. Organisez les consommations lourdes et horaires en conséquence. Le traitement peut être ignoré, occupé, contrôlé, réussi ou échoué ; une commande terminée ne signifie pas toujours une nouvelle publication.
Le contrôle réalise le calcul complet
--check-only effectue la construction et les opérations transactionnelles de publication, puis annule. Il peut durer plusieurs minutes et prendre des verrous ; ce n'est pas un simple contrôle de configuration. Les messages de progression permettent de distinguer calcul et attente d'une autre transaction.
Les rapports contiennent identifiant, raison, volumes, algorithme, mode de publication, lot/date source et résultat. Le suivi d'administration expose cet historique distinct. Consultez-le après une intégration et le passage nocturne plutôt que de déduire sa réussite du seul service d'intégration.