A point cloud, elevation raster, vector service, or tiled scene can appear beside a BIM model while using a different coordinate frame or metadata contract. Before treating the inputs as aligned, identify where each dataset stores its coordinates, CRS, transforms, height meaning, and source state.
The examples below show different interpretation problems. They are not a complete format catalogue, and they do not establish that a particular CAD/BIM application reads, transforms, or preserves any of them.
Compare the spatial contracts
| Input | Where location may be described | What the handoff should identify | A misleading shortcut |
|---|---|---|---|
| Point cloud, LAS 1.4-R13 | Integer point coordinates plus per-axis scale and offset in the LAS header; CRS information in records whose form depends on point data record type. | LAS revision, point record type, scale/offset, CRS encoding and definition, axes/units, vertical context, and any external registration or survey record. | Assuming the integer values are map coordinates, or that one CRS-record convention applies to every point record type. |
| Raster or elevation, GeoTIFF 1.1 | A raster-to-model relationship from tiepoints and scale parameters or a model transformation, separate from the model CRS definition. Pixel-is-area and pixel-is-point use different anchoring. | GeoTIFF revision, raster type, transformation tags, CRS, axis order, pixel/value units, and the vertical reference for elevation values. | Treating the upper-left pixel, pixel center, CRS, and elevation datum as one implicit setting. |
| Vector feature, JSON-FG 1.0 | The GeoJSON-compatible geometry member is distinct from the place member, which can carry geometry in another declared CRS; coordRefSys scope matters. | Whether the feature uses geometry or place, the CRS declaration and scope, any coordinate epoch, fallback geometry, and the exact response or file profile. | Applying the place CRS to the geometry member, or assuming a fallback geometry carries the same detail or meaning. |
| Vector feature, GeoPackage | Geometry is stored in the package with CRS metadata; the optional WKT CRS extension can carry a coordinate epoch. | Package and extension version, CRS metadata actually present, epoch if supplied, geometry table and source state. | Assuming an optional extension is present or that its metadata proves a receiver used the declared CRS. |
| Tiled 3D scene, 3D Tiles | A tileset and its tiles may define global context and nested local-to-parent transforms. The published 1.0 and 1.1 editions are distinct. | Tileset/specification version, CRS metadata, hierarchy, transform chain, content’s own coordinate convention, and any viewer-only placement. | Treating a tile’s local coordinates or displayed position as the BIM project’s coordinates. |
LAS 1.4-R13 uses integer storage values reconstructed with scale and offset. Its CRS representation differs by point data record type: the older record types and newer record types do not share one universal CRS-record rule. Record the version and record type before interpreting a point cloud. This is a storage contract, not a registration or accuracy statement.
GeoTIFF separates the raster-to-model transformation from the model CRS. Its pixel model distinguishes area cells from point samples, which changes how a tiepoint is interpreted. For an elevation raster, also identify the vertical reference and value units; the horizontal CRS alone does not explain height.
JSON-FG separates its geometry member from its place member. The place member supports CRS-aware geometry, while coordRefSys declarations apply to place rather than the GeoJSON geometry member. If both are supplied, treat the geometry as a defined fallback with its own limitations; do not assume both are identical in geometry, detail, or coordinate system.
For 3D Tiles, the parent-child hierarchy can carry local-to-parent transforms. The 1.0 and 1.1 specifications must remain version-labeled. A tile transform chain, an embedded content coordinate convention, and the BIM model’s project placement are separate relationships.
Assemble a reference-data inventory
For every input used as model context, record:
- the dataset name, owner, version or issue, extent, and file/service identifier;
- the exact format and edition, profile, point-record type, or service response context;
- whether CRS, axes, units, vertical datum, epoch, and extent are in the payload, metadata, service response, or a sidecar;
- any stored-coordinate scale and offset, raster-to-model transform, tile/grid address, or local-to-parent frame chain;
- how the input relates to the BIM model’s local/project frames;
- the coordinate operation and resources required if reprojection or datum transformation is performed;
- any viewer-only placement or undocumented assumption;
- the source/control and processing records needed to interpret the measurements; and
- what remains unknown or is intentionally omitted.
Keep encoded information separate from an operation applied by a client. A CRS label does not perform reprojection. A local-to-parent tile transform does not by itself connect the scene to the BIM project’s control. A raster pixel transform does not select a vertical datum. The georeferencing article covers operation declaration; survey provenance covers source and control records.
State the permitted use and loss
A reference input may be sufficient for visual context without being suitable for measurement, design, or acceptance. State whether it is for display, design coordination, quantitative analysis, or another task, and identify the data quality and coordinate evidence that task requires. A rendered overlay is evidence of a display result in that viewer context; it does not alone prove that the payload was transformed correctly or that the BIM model and reference data share an accepted coordinate contract.
Exact receiver behavior and named ingestion routes belong to the portal’s route coverage. Project comparison and acceptance belong to its validation coverage.