A survey point, scan, terrain surface, or elevation model can carry coordinates and still leave the recipient unsure what those values mean. Provenance connects a delivered spatial dataset to its source, reference system, control, collection, processing, and quality evidence.
A provenance request is different from choosing a CRS operation. The georeferencing article describes the operation that relates frames. This article identifies the source and measurement records a recipient needs to interpret the input and understand where its quality claims came from.
Build a provenance inventory
Link each record to the specific delivered dataset, version, or model component. A conceptual inventory can include:
| Record | Questions for the handoff |
|---|---|
| Source identity and state | What survey, scan, terrain, control network, or elevation product is the input? Who supplied it? Which file, issue, extent, and collection state does the record describe? |
| Horizontal reference | Which CRS, datum realization, coordinate axes, units, and coordinate epoch apply? Is the epoch a coordinate reference time or an acquisition date? |
| Vertical reference | Are heights ellipsoidal or orthometric, or expressed in a project-local reference? Which vertical CRS, datum/geoid model, units, and direction convention apply? |
| Control | Which points or marks were used to establish, calibrate, adjust, register, or process the delivered data? How are their identities connected to reports and source data? |
| Independent checkpoints | Which separate points or observations were used to evaluate results? Identify their reference, independence from processing control, coverage, and reported measures. |
| Acquisition and processing | What collection method, date, instruments, software and versions, registration/adjustment steps, filtering, classification, or surface-generation process materially affects interpretation? |
| Quality evidence | What quantity was reported, for which data and area, by which method and comparison set? Is it an operation’s stated accuracy, a control residual, an independent checkpoint statistic, or a local geometric fit? |
| Traceability | Where are source files, reports, point identifiers, transformation records, and derived outputs linked? Which items are unavailable or intentionally omitted? |
| Future use | Does the recipient need raw observations to reprocess or independently inspect the result, or are processed coordinates and reports sufficient for the stated task? |
These are questions to resolve with the data owner and responsible project authority. They are not a universal required package. Request raw observations when a future task, audit, or reprocessing need justifies them; do not assume every BIM handoff needs them.
Keep control separate from checking
Control points help establish or adjust a survey or spatial product. Independent checkpoints are separate observations used to evaluate a result. The exact methods vary, but the records should not be merged under a generic “survey accuracy” label. State which points influenced processing, which were held for checking, and how the reported statistic was computed.
The 2025 USGS 3DEP Lidar Base Specification illustrates a program-specific distinction. Its deliverable requirements call for a survey report that identifies control points used in calibration/processing and checkpoints used for validation, along with reference information and other project reports. The specification applies to its own lidar products and contracts. It is not a default BIM requirement, universal tolerance, or evidence that any delivered model meets a project criterion.
Describe vertical meaning and time explicitly
A horizontal coordinate label does not explain elevation. State whether a value is ellipsoidal height, an orthometric height tied to a vertical datum/geoid model, or a project-local height. Record the units and the source of any conversion. If the reference system is dynamic, identify the coordinate epoch separately from the survey or scan acquisition date.
Do not infer a vertical reference from the fact that a model appears at the expected height. The source and processing history must say which vertical convention was used, and the recipient must determine whether it matches the project requirement.
Interpret quality fields in context
A field named “accuracy,” a percentage, or a small geometric residual is not self-explanatory. Record the measure, its unit, direction/component, population and spatial coverage, comparison source, calculation method, and whether it is stated, estimated, or independently measured.
IFC’s survey-area property set includes expected and obtained accuracy-quality percentage fields. Those fields do not, by themselves, define a positional error statistic, a per-object tolerance, or a project pass/fail threshold. A scan-to-IFC study that reports point-to-surface fit can describe geometric agreement within that study; it does not independently establish the reconstructed model’s absolute georeferencing accuracy.
NGS GVX 1.0 is a proposed format example for describing GNSS vector records. Its proposal status does not establish general adoption, a BIM mapping, or recipient support. Use a format-specific record only when the handoff calls for it, and state its exact status and scope.
Separate provenance from acceptance
The provenance inventory lets a recipient understand the origin and limits of the spatial inputs. It does not establish that the BIM model, scan, or survey meets a contract. Acceptance needs a declared task, independent evidence, a comparison method, and project-specific criteria. The portal’s validation coverage owns those checks.
For the coordinate operation, see georeferencing. For stored point, raster, vector, and tile context, see geospatial reference-data contracts. For a requirement artifact such as IDS, see BIM information requirements.