Data model and typed identities
The SQL files shipped with the installed version are the authoritative schema definition. This page explains the main table families; it is not a replacement migration script.
Never identify an object by numeric ID alone
OSM identifiers are unique within a primitive type. Use (element, id) for an object and (element, id, version) for a reviewed version. For example, node/123/4 and way/123/4 are unrelated identities.
Carry the type through API payloads, React keys, selections, joins, validation rows, quality processing and external exports. Keep IDs in a representation that preserves their integer precision. A changeset ID is yet another identity and must not be used as an object ID.
Rendered osm2pgsql tables use conventions such as negative IDs for relations. These are storage conventions, not a universal typed identity. Primitive tables and relation members remain the source for structural dependencies.
Main families
| Tables | Purpose |
|---|---|
public.users, accounts, sessions, verification_token | Authentication adapter data |
lbt_userrole, lbt_user_userrole | Application roles |
lbt_businessgroup, lbt_user_businessgroup | Teams and memberships |
lbt_footprint, lbt_user_footprint | Territories and assignments |
lbt_theme, lbt_objectgroup, lbt_objectgroup_tag | Thematic populations |
lbt_right, lbt_right_tag | Geometry/tag review responsibilities |
lbt_osmdiff, lbt_osmdiff_history, lbt_osmdiff_footprint | Changes, history and territorial links |
lbt_validation, lbt_status, lbt_state | Decisions and workflow classifications |
lbt_quality_rule_instance, lbt_quality_rule_instance_businessgroup, lbt_quality_processed_items | Rule definitions, team assignments and processed findings |
lbt_relation_context | Captured primitive dependencies for relation processing |
lbt_repl_queue, lbt_repl_state | Replication queue and progress |
lbt_integration_batch, lbt_integration_batch_object, lbt_integration_execution, lbt_integration_root_cursor | Prepared work, retained objects, execution tracking and fair root selection |
lbt_segmentation_run | Derived-network calculations and publication results |
lbt_user_preferences, lbt_notification_state | Persistent preferences and acknowledged reports |
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 | Notification addresses, SMTP, subscriptions and delivery tracking |
lbt_setting, lbt_tile, lbt_wms, lbt_wmts | Instance settings and backgrounds |
Unless prefixed otherwise, these application tables are in lebontag in the default installation.
Reference versus derived tables
With the default prefix, osm_nodes, osm_ways and osm_rels contain primitive structures used by osm2pgsql. osm_point, osm_line, osm_polygon and osm_roads provide rendered output. A relation need not have a rendered geometry; one object can also have several output rows.
The optional segmentation schema contains pgr_ways and pgr_ways_vertices with the configured prefix. They are derived from the reference, not an independent authoritative OSM source.
Installation and upgrades
A fresh installation uses sql/lebontag_v2.sql. An existing installation uses the sequential version migrations specified by Upgrade. Do not run the fresh-install script over an existing production schema. Follow that guide's data-reload requirements when moving from an older untyped validation model.