Skip to main content

SQL segmentation

Segmentation creates sections and vertices from the integrated osm2pgsql reference. It is optional and primarily provides a cut network for downstream uses. It should not be described as a complete routing engine or a stable business-attachment system.

When it runs​

The integration service requests a segmentation job after its execution phase. A separate nightly timer also schedules a run. The job evaluates its configuration and reason, so an after-integration invocation in check mode does not publish sections.

The entry point is python/lbt-rebuild-segments.py, with reasons after-integration, nightly or manual. The db_pgr_update setting controls whether the feature is enabled. Consult Installation for service setup and the current environment variables.

How it publishes​

  1. Lock access needed to obtain a consistent reference state.
  2. Construct the network in working tables and check geometries and endpoints.
  3. Lock the publication tables and replace sections and vertices in a transaction.
  4. Update statistics and record the outcome and source integration.

Failures before commit roll back publication. This does not roll back a previously successful OSM integration. The reference may therefore be newer than the most recent successful segmentation.

The supplied algorithm is identified in reports as legacy-sql-isolated-ways-v1, with transactional-replace publication. The implementation handles its section-building rules; geometric line crossings should not be assumed to imply a navigable junction. Inspect the actual source topology and derived data for your use case.

IDs and consumers​

stable_segment_ids=false is intentional: rebuilt segment identifiers are not guaranteed stable between runs. Downstream data must not treat these generated IDs as durable business keys. Preserve appropriate OSM/source information and design reconciliation separately if a future attachment workflow needs it.

Publication can temporarily block readers of the affected tables. Plan heavy consumption and rebuild schedules accordingly. The job can be skipped, busy, checked, successful or failed; a completed process is not always a new publication.

Check-only is a full calculation​

--check-only performs construction and the transactional publication operations, then rolls back. It can take minutes and hold locks; it is not just a lightweight configuration check. Use progress messages to distinguish computation from waiting on another transaction.

Reports contain run ID, reason, counts, algorithm, publication mode, source batch/time and result. The administration monitor exposes this separate history. Review it after an integration and after the nightly run rather than inferring success from the integration service alone.