Architecture and data flow
LeBonTag combines a Next.js web application, PostgreSQL/PostGIS, Python data jobs and osm2pgsql. The browser presents maps through OpenLayers/rlayers. Authentication, administrative configuration and business decisions live alongside the application data in PostgreSQL.
Data flow
The initial PBF establishes the baseline. Its state/sequence and the chosen replication stream must correspond. The pipeline then downloads and ingests successive diffs into the change workflow. It does not blindly publish every incoming change into the validated reference.
Responsibilities
| Component | Responsibility |
|---|---|
| Web application | Authentication, scoped queries, review decisions, preferences and monitoring |
| Replication pipeline | Fetching, queueing and ingesting OSM changes with progress tracking |
| Integration runner | Selecting approved roots, resolving dependencies, checking the target, invoking append and finalising decisions |
| osm2pgsql | Maintaining primitive middle tables and published reference geometries |
| Segmentation job | Deriving and transactionally replacing sections/vertices from the reference |
| Email worker | Preparing eligible summaries and tracking delivery outcomes |
| Cleaning job | Applying the implemented retention rules to supported caches/metadata |
Persistence and boundaries
The application's lebontag schema holds configuration, changes, decisions and journals. Authentication uses its adapter tables. The reference schema defaults to osm2pgsql; the derived schema commonly uses osm2pgrouting. Configured schema/prefix values must agree with imports and jobs.
An osm2pgsql append and the application's finalisation are not a single PostgreSQL transaction controlled by the web application. This is why execution journals, verification and needs_review exist. Segmentation is another independent publication, with its own source marker and result.
The reference can feed external GIS workflows. Segmentation is optional; consumers needing only reference geometries do not require the derived tables. Current segmentation identifiers are not stable business attachment identifiers.
Runtime
Native deployment uses the documented systemd services under the dedicated operating-system account. npm is still used for dependency installation and builds; it is not a replacement for service supervision. Docker uses the Compose deployment described in its own guide, not systemd inside application containers.
See Data model, Integration, Segmentation and Operations.