E4 ยท Publication Volume 26
3D Formats and Web Delivery
glTF, VTK formats, tiles, compression and metadata
Learning objectives
- Explain the decision and evidence boundary for glTF, VTK formats, tiles, compression and metadata.
- Select and implement the relevant representation or algorithm without hidden coordinate, support or topology assumptions.
- Separate exact predicates, approximation error, source uncertainty and visual delivery.
- Produce a representation-to-format delivery matrix with round-trip and metadata tests from synthetic evidence.
The lesson is complete only when the learner can defend the representation, transform, predicates, tests and release decision. A visually clean map or 3D scene without executable invariants and provenance remains unverified.
This is a general, institution-neutral tutorial with no relationship to any company or individual. All coordinates, geometries, grids, points, surfaces, volumes, attributes and review events in the lesson are synthetic and must not be used for an operational decision.
Decision context
The decision is which encoding and delivery architecture preserve the required representation at each system boundary. An analytical master, interchange package, archive and web-rendering derivative have different goals. File extension alone does not declare coordinate reference, scientific support, topology quality, attribute meaning or lineage. The decision record maps object type, scale, update pattern, random-access need, compression, browser or analytical consumer, metadata channel, validation tool and expected information loss to one or more explicit derivatives.
Write the intended use, consequence of error, required evidence, spatial support and release authority before selecting a representation or transformation. Fitness is evaluated against a versioned contract and use, not attached permanently to a file extension.
Core concept
A runtime scene format efficiently packages meshes, materials, nodes and transforms, but geoscience metadata and global coordinate references may require a companion manifest or extension policy. A hierarchical tile set organises massive content by spatial bounds and geometric error, often referencing runtime assets. Scientific data formats distinguish structured grids, polygonal data and unstructured cells and may support parallel pieces. Raster and point-cloud containers have their own transforms, scales and hierarchy conventions. No single format is the authoritative answer for every representation and task.
Keep received evidence, accepted analytical views and derived representations as distinct objects. This allows corrected evidence, a changed transform or a new level of detail to generate a new result without rewriting history. Every coordinate and primitive therefore answers both a spatial question and a provenance question.
Algorithm and data model
Define an authoritative object manifest before encoding. It records object and version identity, representation class, coordinate and vertical references, units, local-origin transform, primitive and attribute associations, missing states, bounds, source lineage, licence or access constraints, checksums and derivative purpose. The export stage converts coordinates and attributes, creates buffers or chunks, builds hierarchy, applies compression and emits format validation. The import test reconstructs a canonical object and compares it with the pre-export canonical representation rather than only reopening the file in the same writer.
Define parsing, semantic validation, canonicalisation, indexing, exact or approximate calculation, quality evaluation and encoding as separate stages. Each stage emits structured output and does not depend on interface state, file order, graphics-driver behaviour or undocumented defaults.
Constraints and invariants
| Invariant | Executable or review test | | --- | --- | | Format choice follows representation and boundary requirements recorded in a matrix. | Reject or quarantine the exact affected object and preserve the received representation. | | Coordinate transforms, metadata and attribute association survive delivery. | Evaluate this condition before creating a derived geometry, grid, surface or volume. | | Round-trip validation compares canonical objects across independent stages. | Record the predicate, tolerance policy, observed values and coordinate frame. | | Delivery derivatives never replace authoritative analytical or received evidence. | Make every repair a new version and rerun all dependent golden cases. |
An invariant must survive import, transformation, processing, export and rerun. A failed hard invariant produces no apparently valid substitute. Diagnostics remain visible with predicate, threshold, coordinate frame, scope and evidence, and require a reviewed rule before they can trigger repair.
Quantitative reasoning
For every derivative report source and output primitive counts, attribute counts and types, bounds residuals, coordinate displacement, topology changes, missing-state changes, uncompressed and compressed bytes, hierarchy nodes, byte ranges tested and decode time on a fixed fixture. Exact fields compare exactly; floating coordinates compare under the representation-specific quantisation bound; categorical and identifier arrays require zero disagreement. For a hierarchy, verify parent bounds conservatively contain child bounds and stored geometric error is non-increasing under refinement. Test missing external buffers, wrong byte order, unsupported extensions, shifted local origin and random range reads.
Every metric includes units, support, numerator and denominator where applicable, exclusions, comparison policy and evaluation version. Aggregate metrics are stratified when pooling can hide local geometry failure. A performance gain cannot overrule invalid topology, missing reference metadata or broken lineage.
Evidence and uncertainty
Keep acquisition uncertainty, interpretation uncertainty, discretisation error, numeric round-off and delivery error separate. Increasing coordinate digits or triangle count does not improve the original evidence. A sampled surface may be smooth and watertight while remaining poorly constrained between observations. Report uncertainty in the quantity and support to which it belongs.
Build an evidence packet containing immutable received objects, semantic declarations, validation findings, transform inputs and outputs, measured errors, test results, reviewer decisions and fingerprints. Contradictory evidence remains available. When a required reference, topology state or classification cannot be resolved, return unknown, conflict or blocked rather than inventing geometry.
Interfaces and storage
Interfaces transmit identity, coordinate reference, units, axis order, support, topology expectations, attribute association, null state, version and lineage beside coordinates. Structured errors identify the object, primitive, predicate, observed value, expected condition and rule. An interface that carries vertices but drops the transform or face orientation has not preserved the object.
Store authoritative received evidence separately from reproducible analytical derivatives and disposable delivery artefacts. Indexes, caches, pyramids and render meshes improve access but cannot become the only copy of source attributes or coordinate metadata. Round-trip tests verify identity, precision, topology, ordering, missingness and association after encoding changes.
Governance and review
Assign responsibilities to roles rather than named organisations or people: evidence custodian, representation author, algorithm maintainer, independent validator and release reviewer. A role may propose a repair but cannot erase the received geometry. Transform, predicate and tolerance changes are versioned and evaluated against fixed regression fixtures before release.
Exceptions are explicit decisions with scope, rationale, evidence, approving role, affected versions and review trigger. They never turn invalid topology into valid topology by label. The host website has no ownership or scientific-authority role in this workflow; it only delivers the tutorial.
Integration checkpoint
Read the figure as a reasoning map from preserved evidence through declared support and coordinates, controlled transformation, validation and scoped release. Each arrow represents a declared relationship. Integrate a representation-to-format delivery matrix with round-trip and metadata tests into SYN-SPATIAL, rerun earlier fixtures and record every changed assumption.
Synthetic worked example
SYN-SPATIAL exports its validated base mesh to a scientific exchange object and a separate web derivative. The web derivative subtracts a local origin, quantises positions and packages two levels in a tile hierarchy; its manifest preserves the world transform, source mesh version and measured 1.2 mm maximum displacement. A round-trip test confirms face and identifier counts but detects that one exporter dropped a per-face class attribute. That derivative is rejected even though it renders correctly. The scientific object remains the analytical derivative and the web asset remains disposable.
- Preserve the received object and state the intended decision without repair.
- Resolve identity, reference, units, support, topology and evidence eligibility.
- Run the versioned transform or predicate while retaining intermediate diagnostics.
- Issue accept, reject or quarantine and show how an independent reviewer reproduces it.
Practice task
Implement the chapter artefact against a synthetic fixture containing one normal case, one boundary case, one invalid case and one unresolved-evidence case. Preserve the received fixture. Produce canonical input, validation findings, derivative output, processing manifest, measured error and a short release decision.
Acceptance criteria:
- Every required identity, coordinate reference, unit, support and convention is explicit.
- The implementation is deterministic under stable ordering and the declared numerical policy.
- No repair overwrites received evidence or converts unknown into a guessed value.
- All hard failures block the affected derivative and remain machine-readable.
- A second implementation or reviewer can reproduce the result from the package alone.
Submit a representation-to-format delivery matrix with round-trip and metadata tests, golden and adversarial fixtures, exact findings, measured error and a limitations note. A screenshot is not sufficient evidence because it does not identify input versions, transforms, algorithms or rule configuration.
Common failure modes
- Choosing a format from extension popularity before defining requirements.
- Embedding local coordinates without preserving the world transform.
- Accepting an export because it renders while attributes were dropped.
- Using the same writer and reader as the only round-trip test.
These failures share a pattern: implicit convenience is substituted for evidence. Diagnose the earliest boundary where the assumption entered, restore the source statement, make the transform or predicate explicit, rerun all dependent derivatives and supersede rather than overwrite the affected release.
Review questions
- Why do analytical, archival and web derivatives need different decisions?
- Which metadata must accompany a local-origin render asset?
- What should a canonical round-trip comparison measure?
- Why can a correctly rendered derivative still fail?
For every answer, identify the governing invariant, evidence needed to evaluate it, numerical or semantic policy involved and correct behaviour when the condition fails.
Sources and further reading
- Khronos glTF 2.0.1 specification, defining a vendor-neutral runtime format for transmitting 3D scenes and models.
- OGC 3D Tiles 1.1, defining hierarchical spatial organisation and streaming of massive 3D geospatial content.
- VTK file-format documentation, describing structured, unstructured, polygonal and image-data encodings.
- OGC GeoTIFF 1.1, specifying raster-to-model transformations and coordinate-reference metadata in TIFF.
- ASPRS LAS 1.4 R15 specification, defining point records, scale and offset, classification, returns and coordinate encoding.
- COPC 1.0 specification, defining range-readable LAZ point data organised in a clustered octree.
- ISO 19157-1:2023 geographic data quality, providing a framework for describing and evaluating geographic-data quality.