Course · ← 0003 Systematic vs Sporadic · 0005 Publishing the Map →

Lesson 0004 · ~14 minutes

Time and Mutation

The parcel is not a stable entity, "current" is not a state, and the row you are about to UPDATE is evidence in a future court case. LADM's answer, and what it costs you.

Why land systems break on time

Ordinary business systems keep the current state and treat history as an audit log — nice to have, rarely queried. Land administration inverts that. Who owned this parcel in 2019 is not an audit question; it is the ordinary business of the registry, because rights are asserted retrospectively, disputes are about the past, and a certificate issued years ago must still be reconcilable with the record.

So LADM makes versioning structural rather than optional: all objects inherit from VersionedObject, an abstract class giving them a lifespan, so that the contents of the database can be reconstructed as they were at any historical moment.1

VersionedObject  (abstract — nearly everything inherits it)
  beginLifespanVersion   when this version entered the database
  endLifespanVersion     when it was superseded  (null = current)

Edition II adds real-world time alongside system time:
  beginRealWorldLifespanVersion / endRealWorldLifespanVersion / acceptance

Two clocks, not one. System time = when the database believed it. Real-world time = when it was actually true. LADM Edition II supports intervals for both — a bi-temporal model.1

The one idea to keep

A deed signed in March and lodged in September is true from March, known from September. One timestamp cannot express that, and the gap is exactly where fraud, backdating and honest clerical delay live. Bi-temporal is not academic — it is why "we recorded it late" and "we changed our mind" stay distinguishable forever.

Practically: never update in place, never delete. Close the old version by stamping endLifespanVersion, insert the new one. Every "current" query becomes WHERE endLifespanVersion IS NULL, and every historical query is the same query with a date. Retrofitting this later means rewriting every table and every query you own — which is why it belongs in the first migration, not the second phase.

Mutation: the parcel is not forever

A mutation is a change to the cadastral fabric itself — subdivision, merger, boundary correction. This is where naive models break, because they assume the parcel is a durable entity with a stable identifier that things hang off. It is not. A parcel has a lifespan, ends, and has successors.

MutationSpatial effectLegal effect
SubdivisionOne spatial unit ends; two or more beginRights must be redistributed onto the new BAUnits — and encumbrances follow the land
MergerSeveral end; one beginsOnly clean if the rights are identical on all of them; otherwise it cannot proceed
Boundary correctionGeometry replaced by a better observationNone. Rights are untouched
Transfer / saleNone. Geometry untouchedOld right ends, new right begins, new party

Read the bottom two rows together, because they are the payoff of the LA_BAUnit seam from lesson 0001: geometry can change without touching rights, and rights can change without touching geometry. If your schema hangs ownership directly off the parcel row, both of those become destructive rewrites.

Mutations and general boundaries

Now fold in lesson 0002. Under general boundaries, a "boundary correction" is not a rare event — it is the normal path of incremental improvement, as better imagery or a real survey arrives for parcels that warrant it. So the boundary-correction row in that table is the one your system will execute most often, and it must be cheap, non-destructive, and must never disturb rights.

That means each geometry version carries its own provenance — capture method, accuracy class, source, date — so that when two observations disagree you can decide which wins on recorded grounds rather than on which arrived last.


Drill 1 — What must change?

For each event: does the spatial side change, the legal side, or both?

Drill 2 — Recall


Your primary source

"Bi-temporal foundation for LADM v2: fusing event- and state-based modelling of land administration data" — van Oosterom & Lemmen et al., Land Use Policy. The reasoning behind the two clocks, by the people who put them in the standard:
sciencedirect.com/science/article/pii/S0264837720325849

For the practitioner view of the same material, the FIG Working Week 2023 paper by Lemmen & van Oosterom is free: TS03I (PDF).

Ask your teacher. Strong next questions: "show me these tables in PostGIS", "how do I index a bi-temporal table so current-state queries stay fast?", "what does a mutation look like as an API call?"