Skip to main content

Change and validation lifecycle

Three distinct records describe a change: its ingested OSM version, the human review decisions and the integration execution. Do not collapse them into one “validated” flag.

From a diff to a decision​

Ingestion stores old/new information and an OSC fragment for an object version. For ways and relations, geometry can change because a member changes, not only because the parent's own tag list changes. Relation contexts preserve dependencies needed later.

The application's queries combine the change, object-group rules, business-group rights and territory. Tag differences and od_changed_geom determine review obligations. A user can complete one part while other groups still need to act.

The schema includes the status labels tovalidate, waiting, toedit, valid, invalid and integrated. These database labels do not imply six buttons or a user-operated “defer” workflow. Use the current application's decisions and status logic rather than manually assigning intermediate states.

Approval and integration​

valid identifies an approved candidate; it does not prove its dependencies are usable or its geometry is published. The integration planner evaluates:

  • the exact typed/versioned root and reference baseline;
  • required nodes, ways and relation members;
  • whether a dependency needs review, is refused or has no monitored change;
  • reverse impacts on parents, including deletions;
  • conflicts between roots that require incompatible versions or contents.

A version with no monitored change can be included as a dependency only after the other consistency checks. A diagnostic unmonitored decision alone is not permission to append it independently.

Finalisation and recovery​

The executor rechecks prepared work before append and verifies the resulting reference before business finalisation. It records which roots and decisions were integrated. Counts of validation rows may differ from root and primitive counts.

If append may have happened but finalisation is not confirmed, needs_review prevents blind automatic replay. Inspection and recovery must establish the database state first. This is separate from an ordinary pending review or a refused dependency.

See Integration for the operational sequence and Typed identities for the keys to preserve throughout it.

Decision precedence and automatic validation​

Only active manual object groups with review rights create review obligations. Membership is evaluated against both old and new tags; actual tag changes and od_changed_geom determine whether review is needed. This policy is global, not limited to the signed-in user.

An active automatic group or an automatically approved contributor makes a sheet eligible for automatic validation, but never bypasses manual obligations. A partial review does not approve the whole object: a pending sheet with a matching manual review obligation remains pending. Explicit refusals and waiting decisions, including partial ones, are preserved. An indeterminate rule never permits automatic approval.

The pipeline and integration preparer share this evaluation. A dependency without manual obligations can be included with reason unmonitored, without waiting for the next automatic-validation pass. Version, dependency and impact checks still apply. An inactive or automatic group never overrides another active manual group.

OSM tags and cartographic output​

Ingestion reads reference tags and metadata from typed middle tables osm_nodes, osm_ways, osm_rels (middle format 2). Rendered tables osm_point, osm_line, osm_polygon provide published geometries, not reference tags.

source and note remain comparable even when the style excludes them from rendering: they are not falsely added when already present in the primitive. The way_area generated by osm2pgsql no longer enters tag differences. A real upstream tag is preserved even when its name resembles metadata. No admin exclusion list needs synchronising with the style.

Middle-table IDs are positive and scoped by type. In pgsql output tables, a way uses its positive ID and a relation its negative ID; both signs must never be queried together.