Modèle de données et identités typées
Les SQL livrés avec la version installée constituent la définition de référence du schéma. Cette page explique les principales familles de tables ; elle ne remplace pas un script de migration.
Ne jamais identifier un objet par son seul numéro
Les identifiants OSM sont uniques à l'intérieur d'un type de primitive. Utilisez (element, id) pour un objet et (element, id, version) pour une version examinée. node/123/4 et way/123/4 sont par exemple des identités sans rapport.
Conservez le type dans les API, clés React, sélections, jointures, validations, traitements qualité et exports externes. Préservez la précision entière des identifiants. Un identifiant de changeset est encore une autre identité et ne remplace pas celui d'un objet.
Les tables publiées par osm2pgsql utilisent des conventions, notamment des identifiants négatifs pour les relations. Ce sont des conventions de stockage, pas une identité typée universelle. Les tables primitives et les membres des relations restent la référence des dépendances structurelles.
Principales familles
| Tables | Fonction |
|---|---|
public.users, accounts, sessions, verification_token | Données de l'adaptateur d'authentification |
lbt_userrole, lbt_user_userrole | Rôles applicatifs |
lbt_businessgroup, lbt_user_businessgroup | Équipes et appartenances |
lbt_footprint, lbt_user_footprint | Emprises et attributions |
lbt_theme, lbt_objectgroup, lbt_objectgroup_tag | Populations thématiques |
lbt_right, lbt_right_tag | Responsabilités de vérification géométrie/tags |
lbt_osmdiff, lbt_osmdiff_history, lbt_osmdiff_footprint | Changements, historique et liens territoriaux |
lbt_validation, lbt_status, lbt_state | Décisions et classifications du workflow |
lbt_quality_rule_instance, lbt_quality_rule_instance_businessgroup, lbt_quality_processed_items | Règles, attributions aux équipes et signalements traités |
lbt_relation_context | Dépendances primitives conservées pour traiter les relations |
lbt_repl_queue, lbt_repl_state | File de réplication et progression |
lbt_integration_batch, lbt_integration_batch_object, lbt_integration_execution, lbt_integration_root_cursor | Lots, objets retenus, exécutions et parcours équitable des racines |
lbt_segmentation_run | Calculs et publications du réseau dérivé |
lbt_user_preferences, lbt_notification_state | Préférences persistantes et relevés acquittés |
lbt_user_notification_email, lbt_smtp_settings, lbt_email_subscription, lbt_email_subscription_footprint, lbt_email_digest, lbt_email_digest_worker, lbt_email_digest_recovery | Adresses, SMTP, abonnements et suivi des envois |
lbt_setting, lbt_tile, lbt_wms, lbt_wmts | Paramètres et fonds de carte |
Sauf préfixe contraire, les tables applicatives sont dans lebontag dans l'installation par défaut.
Référence et tables dérivées
Avec le préfixe par défaut, osm_nodes, osm_ways et osm_rels contiennent les structures primitives utilisées par osm2pgsql. osm_point, osm_line, osm_polygon et osm_roads fournissent les géométries publiées. Une relation ne possède pas nécessairement de géométrie publiée ; un même objet peut aussi produire plusieurs lignes de sortie.
Le schéma de découpage optionnel contient pgr_ways et pgr_ways_vertices avec le préfixe configuré. Ces tables dérivent du référentiel, sans constituer une source OSM indépendante.
Installation et migrations
Une installation neuve utilise sql/lebontag_v2.sql. Une installation existante utilise les migrations successives indiquées dans Mise à jour. N'exécutez pas le script d'installation neuve sur un schéma de production existant. Respectez les consignes de rechargement lorsque vous quittez un ancien modèle de validation non typée.