Method versions

Every scientific method OpenLiDARViewer runs is identified by a stable id@version so a result can name the exact algorithmic path behind it, and a later release can improve one method without changing the meaning of the others. The authoritative catalogue is docs/science/METHOD_REGISTRY.md and its runtime companion src/science/methodRegistry.ts.

Contour Studio geometry (v0.5.9)

The Contour Studio geometry products carry these method ids on the product and in the exported vector attributes (method_id, method_version):

• olv.contour.analytical@1 — exact isolines of the terrain grid (marching squares, cell-centre registration). No smoothing or displacement.
• olv.contour.generalize@1 — the shipped cartographic generalization: simplification at a bounded per-purpose tolerance (each Contour Studio purpose maps to a tolerance in grid cells) followed by Chaikin corner-cutting. This is the id stamped on every generalized Contour Studio export.
• olv.contour.generalize.dp@1 — a Douglas–Peucker variant with a fixed tolerance, available in the geometry-product library.
• olv.contour.generalize.terrain-adaptive@1 — a per-feature variant that scales tolerance by support, confidence, closure, and length within a bounded band, available in the library but NOT on the shipped export path.

These ids are stamped by the geometry-product builders. Routing them through the canonical ScientificAnalysisRecord (which validates ids against the method registry) is part of the export wiring and is registered there when an exporter emits the record.

Stability rule

An id is stable; a behavioural change bumps the @version. A number produced by id@N must not silently change meaning under the same id and version. When a method changes, its entry in docs/science/METHOD_REGISTRY.md and the version stamp move together.

Method registry

src/science/methodRegistry.ts is the single catalogue of the scientific methods OpenLiDARViewer runs. Every algorithm that produces a reported number has one stable identifier and an integer version, so provenance and reports can name the exact method and revision behind a figure and a reader can trace it to the paper that specifies it.

Identifier and versioning rules

• Id form: olv.<area>.<method> (e.g. olv.validation.spatial-block). The id never changes once published.
• Version: an integer, bumped only when the method's behaviour changes in a way that could move its numbers (a new threshold, a corrected estimator, a different formula). A pure refactor that leaves the output identical does not bump it.
• Tag form: id@version, e.g. olv.validation.spatial-block@2.
• Citations are never fabricated. An internal composition with no single source paper says so.

Registered methods

Id	Ver	Method	Citation
olv.ground.smrf	1	SMRF ground extraction	Pingel, Clarke & McBride (2013)
olv.terrain.slope-horn	1	Horn slope & aspect	Horn (1981)
olv.terrain.vrm	1	Vector Ruggedness Measure	Sappington et al. (2007)
olv.terrain.tpi	1	Topographic Position Index	Weiss (2001)
olv.dtm.idw-fill	1	DTM raster + IDW void fill	internal (standard IDW)
olv.validation.holdout-rmse	2	Hold-out vertical accuracy (classify-inside-fold)	ASPRS (2014) formulas, hold-out basis
olv.validation.spatial-block	2	Spatial-block cross-validation	Roberts et al. (2017)
olv.validation.reliability-wilson	1	Measured-cell reliability	Wilson (1927)
olv.registration.icp-planar	1	Planar rigid ICP	Besl & McKay (1992); Umeyama (1991)
olv.volume.stockpile	1	Stockpile cut-fill volume ±1σ	internal (prismatic cut-fill)

Honesty boundary

Registering a method names the algorithm; it does not upgrade the evidence behind its output. The hold-out vertical accuracy uses the ASPRS 2014 formulas on internally withheld points, not independent survey checkpoints, and the evidence registry still governs whether any product may be presented as validated. See docs/validation/ and the evidence model.