Cycle des modifications et validations
Trois informations distinctes décrivent une modification : la version OSM ingérée, les décisions humaines et l'exécution d'intégration. Ne les réduisez pas à un unique indicateur « validé ».
Du diff à la décision
L'ingestion conserve les informations anciennes/nouvelles et un fragment OSC d'une version d'objet. Pour une voie ou une relation, la géométrie peut changer à cause d'un membre, pas seulement des tags du parent. Les contextes de relations conservent les dépendances nécessaires ensuite.
Les requêtes combinent changement, règles de groupes d'objets, droits métier et emprise. Les différences de tags et od_changed_geom déterminent les obligations. Un utilisateur peut terminer sa partie alors que d'autres groupes doivent encore intervenir.
Le schéma comporte les libellés tovalidate, waiting, toedit, valid, invalid et integrated. Ces états ne signifient pas qu'il existe six boutons ni une action utilisateur « reporter ». Utilisez les décisions et la logique d'état de l'application plutôt que d'affecter manuellement un état intermédiaire.
Approbation et intégration
valid désigne un candidat approuvé ; cela ne garantit ni l'utilisabilité de ses dépendances ni la publication de sa géométrie. La préparation examine :
- la racine typée/versionnée exacte et sa référence ;
- les nœuds, voies et membres nécessaires ;
- les dépendances à vérifier, refusées ou sans changement surveillé ;
- les impacts inverses sur les parents, notamment pour les suppressions ;
- les conflits entre racines exigeant des versions ou contenus incompatibles.
Une version sans changement surveillé peut être incluse comme dépendance après les autres contrôles de cohérence. Un diagnostic unmonitored ne constitue pas à lui seul une autorisation d'append indépendant.
Finalisation et reprise
L'exécuteur recontrôle le lot préparé avant l'append et vérifie le référentiel obtenu avant de finaliser les décisions. Il enregistre les racines et validations intégrées. Le nombre de lignes de validation peut différer des nombres de racines et primitives.
Si l'append a pu avoir lieu sans finalisation confirmée, needs_review interdit une relance automatique aveugle. L'inspection et la reprise doivent d'abord établir l'état de la base. C'est distinct d'une simple validation en attente ou d'une dépendance refusée.
Voir Intégration pour le déroulé opérationnel et Identités typées pour les clés à préserver tout au long du traitement.
Priorité des décisions et auto-validation
Seuls les groupes d’objets actifs et manuels ayant des droits de contrôle créent une obligation de revue. L’appartenance est évaluée sur les tags avant et après ; les tags effectivement modifiés et od_changed_geom déterminent si une vérification est nécessaire. La politique est globale, sans filtre lié à l’utilisateur connecté.
Un groupe automatique actif ou un contributeur en auto-validation rend une fiche candidate à l’auto-validation, mais ne permet jamais de contourner une obligation manuelle. Une validation partielle ne vaut pas validation de l’ensemble : tant que la fiche reste à contrôler et qu’un groupe manuel exige un examen, elle reste en attente. Les refus et mises en attente explicites, y compris partiels, sont conservés. Une règle indéterminée ne permet aucune validation automatique.
Le pipeline et le préparateur partagent la même évaluation. Une dépendance sans obligation manuelle peut être incluse avec la raison unmonitored, sans attendre le prochain passage de l’auto-validation. Les contrôles de versions, dépendances et impacts restent obligatoires. Un groupe inactif ou automatique ne neutralise jamais un autre groupe manuel actif.
Tags OSM et sortie cartographique
L’ingestion lit les tags et métadonnées de référence dans les tables intermédiaires typées osm_nodes, osm_ways, osm_rels (middle format 2). Les tables osm_point, osm_line, osm_polygon servent aux géométries publiées, pas à la comparaison des tags.
source et note restent comparables même si le style les exclut du rendu : ils ne sont pas faussement ajoutés s’ils existaient déjà dans la primitive. Le way_area calculé par osm2pgsql n’entre plus dans les différences. Une véritable clé présente dans les tags OSM reste un attribut OSM, même si son nom ressemble à une métadonnée. Il n’y a pas de liste d’exclusion admin à synchroniser avec le style.
Les identifiants des tables intermédiaires sont positifs et propres à chaque type. Dans les sorties pgsql, une way utilise son identifiant positif, une relation son identifiant négatif ; les deux signes ne sont jamais recherchés ensemble.