LiDAR deliverables are designed by survey teams for survey use. They land at the GIS team and an invisible integration step begins — reprojection, schema mapping, attribute renaming, tile-mosaic reassembly, classification re-coding. The gap is where days of in-house effort disappear. The fix is a deliverable designed for ingestion, not just for capture.
If you've ever received a clean LiDAR delivery from a survey contractor and then watched it sit for two weeks while the GIS team worked out how to ingest it, you've met the survey-to-GIS handoff problem. The deliverable is technically correct. The accuracy is fine. The QA pack passes review. The point cloud opens in any LAS viewer. None of that helps the GIS team load it cleanly into the corporate ArcGIS Enterprise environment, the QGIS-based asset management workflow, or the FME-driven ingestion pipeline that feeds the warehouse.
The gap isn't usually about data quality. It's about fit-for-ingestion. Survey deliverables are designed for survey workflows; GIS workflows have different conventions, different tooling assumptions and different metadata expectations. The deliverable that doesn't account for that gap creates a second, undocumented project on the GIS team's side.
This article is the bridge. What the GIS team actually needs to receive, the decisions worth making early between survey and GIS, and the manifest content that turns a handover into a workflow.
Three platforms cover most of the corporate / consulting GIS market in Australia: ArcGIS (Esri), QGIS (open source) and FME (Safe Software for integration). Each consumes LiDAR slightly differently.
Native LAS / LAZ ingestion via the LAS Dataset (.lasd) container or directly into a Mosaic Dataset. ArcGIS Pro 3.x reads LAS 1.0 through 1.4 natively but the LAS Dataset is most robust when all tiles are in a single LAS version with a consistent point record format (PDR). Mixing PDR 6 tiles with PDR 1 tiles in the same dataset forces reformatting.
DTM ingestion: GeoTIFF preferred (native rendering, metadata-rich, supports overviews/pyramids for fast display). ASCII grid (.asc, .txt) works but is slow. ESRI Grid (.adf) is legacy but still consumed.
Contour and breakline integration: shapefile for simple cases, file geodatabase (.gdb) feature class for anything the GIS team will edit, LandXML for handoff to civil engineering teams using Civil 3D.
Coordinate system: ArcGIS reads .prj sidecar files but prefers explicit EPSG codes (e.g., EPSG:7855 for GDA2020 MGA Zone 55). Datum mis-declaration is the single largest source of integration friction.
Native LAS / LAZ through PDAL. Tiled deliveries work well via a virtual layer (VRT) referencing the tile set. QGIS prefers consistent LAS versions across tiles but handles mixed versions better than ArcGIS.
DTM: GeoTIFF first preference; ASCII grids workable. QGIS handles raster reprojection on-the-fly cleanly, so projection mismatches are less catastrophic than in ArcGIS workflows.
Vector deliverables: shapefile and GeoPackage (.gpkg) both well-supported; GeoPackage preferred for multi-layer deliverables (single file, schema-aware, SQLite-backed).
Coordinate system declaration: QGIS prefers EPSG codes in the .prj sidecar; missing .prj files prompt the user to specify the CRS, which often gets wrong on first guess.
Used for production ingestion pipelines feeding corporate data warehouses, asset management systems (Maximo, IBM Cognos), and analytics platforms. FME reads everything; what matters is consistency across tiles and predictable schema.
The pain point for FME workflows isn't reading the data — it's the schema variance. A deliverable where half the tiles have a "Classification" attribute and half have "Class" causes the FME workflow to fail or silently drop data. Schema consistency across the entire deliverable is the make-or-break for production pipelines.
Four format decisions worth agreeing between the survey contractor and the consuming GIS team before capture, not at delivery:
LAS 1.4 with PDR 6 (or 7 if you need RGB encoded alongside the point) is the modern default. PDR 6 stores extended classification (256 classes vs 32 in PDR 0-5) and the extended return number field needed for sensors that capture more than 7 returns per pulse.
GIS teams running older ArcGIS versions (10.x rather than Pro 3.x) may need LAS 1.2 with PDR 1 for full tool compatibility. Worth confirming before the contractor delivers LAS 1.4 only to discover the downstream environment can't ingest it.
(See LAS/LAZ format article for the deeper version/PDR breakdown.)
LAZ (compressed) reduces file size by 5-10× with no information loss. Every major LiDAR tool reads LAZ natively. The few exceptions: some legacy ESRI Grid tools, some custom FME readers configured for LAS-only. Confirm LAZ support across the consuming pipeline before assuming.
For deliverables that will be stored long-term in archive systems, LAZ is the default. For deliverables that will be edited in-place by classification tools, some teams prefer LAS uncompressed (faster random access; matters for very large editing sessions).
500 m × 500 m grid aligned to MGA coordinates (so tile boundaries fall on round-1000 m coordinate values) is a common compromise — small enough to load in memory on modest hardware, large enough that tile-count overhead doesn't dominate. 1 km × 1 km is the alternative for projects on more capable infrastructure.
The grid alignment matters because it allows downstream mosaic operations to be deterministic. A tile structure that's "approximately 500 m" but not aligned to a fixed grid produces inconsistent overlap regions and unpredictable mosaic seams.
(See tile structures article for the full tile-design discussion.)
Coordinate-based filenames (tile_E_300000_N_6190000.laz)
are the GIS team's preferred convention. They sort
deterministically, embed the tile's lower-left corner
coordinate, and are robust to subset extraction
(extracting tiles overlapping a project area is a
single filter on filename).
Sequential numbering (tile_001.laz, tile_002.laz)
works but loses the spatial reference; locating a tile
by area requires a separate lookup table.
Mixed conventions across a single delivery
(East_North for some tiles, tileNNN for others)
break tile-management scripts. Pick one and stay
consistent.
The single largest source of integration friction is coordinate system mis-declaration. Three layers to get right:
Horizontal datum and projection. GDA2020 MGA Zone NN (where NN is the relevant zone) is the modern Australian standard. EPSG codes: 7854 (Zone 54), 7855 (Zone 55), 7856 (Zone 56). Older GDA94 projects use EPSG codes 28354/28355/28356. Mixing GDA94 and GDA2020 within a delivery causes ~1.8 m offsets that aren't visible until aerial overlay.
Vertical datum. AHD (Australian Height Datum) is the engineering convention; ellipsoidal heights are the GNSS-native form. Deliverables should state the vertical datum explicitly; AHD is assumed but ellipsoidal-height deliveries occasionally arrive with no flag, generating systematic 20-30 m offsets vs expectations.
Coordinate system declaration mechanism. EPSG code in the LAS header (the Variable Length Records section) is the most robust. PRJ sidecar file is the fallback. Metadata in a separate document only is fragile — gets lost in handoff. Best practice: all three.
(The AHD / GDA2020 article covers the datum story in detail.)
LAS / LAZ files carry per-point attributes beyond the xyz coordinate. Three attribute groups worth agreeing on:
ASPRS standard classes (0-22 base, plus reserved 23-63 and user-definable 64-255) are the convention. The default set most GIS teams expect:
Project-specific classes (e.g., 18 = bridge deck, 19 = high noise, 64-65 = utility infrastructure subclasses) should be documented in the manifest. Without documentation, the GIS team has to reverse-engineer the classification by sampling and visual inspection.
Number of returns per pulse, return number within pulse, and intensity (or reflectance for radiometrically- calibrated sensors) are the standard return attributes. Most GIS workflows use these for canopy structure analysis, biomass estimation and built-environment filtering. All should be preserved through processing — some operators strip return information during ground extraction, which removes downstream analytical capability.
Less commonly used but worth preserving: scan angle (per-point degrees from nadir) and point source ID (flight line index). Both enable post-delivery diagnostic analysis when issues surface. Some deliverables drop these to reduce file size; the storage savings are small (~5-10%) and the diagnostic loss is permanent.
The single document that separates a clean handover from a slow integration is the manifest. Its job: give the GIS team everything they need to load and use the deliverable without having to ask the survey team.
A minimum-viable manifest covers:
Project metadata — project name, client reference, capture dates, capture method (LiDAR vs hybrid), sensor model.
Datum and projection — horizontal datum and EPSG, vertical datum, units, geoid model if applicable.
Tile structure — tile size, grid alignment, naming convention, total tile count, project area covered.
Deliverable inventory — every file delivered, with its path, format, version, size and SHA-256 checksum.
Classification scheme — every class number used, with its meaning and the rule that generated it.
Attribute schema — every per-point or per-feature attribute, with its data type and units.
Accuracy summary — RMSE achieved, checkpoint count and distribution, residuals stratified by cover class.
Known limitations — any areas of lower quality (sparse density, marginal classification, hydro- enforcement scope), capture conditions affecting deliverable quality.
Processing chain — software versions, processing parameters, manual edits applied.
Re-use guidance — recommended use cases and explicit non-use cases (e.g., "this DTM is suitable for 0.5 m contour generation; not suitable for floodplain modelling without re-processing for hydro- enforcement at structures").
The manifest format matters less than its presence — JSON (machine-readable, suitable for FME ingestion), PDF (human-readable, suitable for archive) and a short README.md (human-readable, suitable for git-tracked workflows) are all reasonable. The best deliveries include all three.
Eight specific patterns that cause GIS-team integration friction in our experience:
1. EPSG code missing from LAS header. Forces the GIS team to declare the CRS in their tool; first guess is often wrong. Fix: encode EPSG in LAS header VLR.
2. Datum drift between tiles. Some tiles in GDA2020, some in GDA94, manifest declares one. Fix: single datum across the entire deliverable, declared consistently.
3. Vertical datum unflagged. AHD assumed, ellipsoidal delivered. Fix: explicit vertical datum declaration in manifest and in LAS header.
4. Classification non-standard without documentation. Operator uses class 17 for vegetation (vs ASPRS class 4/5) without flagging. Fix: ASPRS-standard classes unless contractually agreed otherwise; document any deviations.
5. Filename inconsistency mid-deliverable. Tile naming convention shifts halfway through the project. Fix: single convention, enforced at processing.
6. Missing manifest checksums. GIS team can't verify file integrity after transfer. Fix: SHA-256 checksum per file in manifest.
7. DTM raster CRS mismatch with point cloud. Point cloud in MGA Zone 55, DTM accidentally exported in MGA Zone 56. Fix: production-pipeline CRS consistency checks before delivery.
8. Deliverable bundle structure undocumented. GIS team receives ZIP with no folder structure description. Fix: manifest documents folder layout; consistent folder structure across deliveries.
The handoff goes both ways. Five questions the survey team should ask the consuming GIS team before finalising the deliverable:
"What's your ingestion pipeline?" — ArcGIS Pro manual, QGIS / PDAL scripted, FME production workflow, custom Python? Each has different format sensitivities.
"What's your target CRS?" — confirm horizontal and vertical datum, particularly if the project area spans zone boundaries.
"What attribute schema does your existing data use?" — match the new delivery to existing conventions where possible to minimise re-mapping.
"What naming convention does your archive require?" — many corporate environments have filename rules that override survey defaults.
"What's your tile size preference?" — 500 m vs 1 km vs other; usually driven by infrastructure capacity.
Five emails before capture saves five days of rework after delivery.
Survey deliverables are designed for survey workflows; GIS workflows have different conventions. The gap is where integration friction lives. Bridge it deliberately by agreeing four things between survey and GIS teams before capture: LAS version and PDR, compression, tile structure, naming convention.
Coordinate system declaration is the single largest friction source — horizontal datum (GDA2020 MGA Zone NN with EPSG code), vertical datum (AHD vs ellipsoidal), and the mechanism (LAS header VLR preferred, PRJ sidecar fallback, document third).
Attribute schemas matter — ASPRS classification standards, full return information preserved, scan angle and source ID retained.
The manifest is the deliverable that separates clean handover from slow integration: project metadata, datum/projection, tile structure, inventory with checksums, classification scheme, attribute schema, accuracy summary, limitations, processing chain, re-use guidance.
Eight common integration-friction patterns are all preventable with discipline at processing-time.
Five emails between survey and GIS teams before capture saves five days after delivery.
If you're scoping a project where the deliverable will land at an internal GIS team, we'll structure the format choices, manifest content and attribute schema in collaboration with them rather than to a default. The pre-capture conversation saves the post-delivery rework — happy to include your GIS team in the scoping call.
The deeper version / PDR / compression decisions that this article references — useful background for survey teams scoping deliverables for GIS handoff.
Tile design choices that determine how the GIS team's mosaic and ingestion workflows behave — the structural complement to this attribute-and-handoff piece.