What Is GIS-Ready Data? How LiDAR Outputs Feed Into Spatial Systems

GIS ready data is spatial data that loads into a GIS environment without transformation, or manual intervention. It uses the correct coordinate reference system, carries a complete attribute schema, and meets the metadata standards your organisation requires. This article explains what makes LiDAR survey outputs becomes GIS ready.

What Is GIS Ready Data?

GIS ready data is spatial data that integrates directly into a GIS environment without requiring manual repair or format conversion. It loads without errors, displays in the correct position, and carries all the attribute information downstream systems expect.

In practice, many datasets that arrive labelled as “GIS ready” are not. They may use the wrong coordinate reference system, carry incomplete attributes, or lack the metadata required for discovery and governance. Consequently, GIS teams spend significant time fixing data before it reaches production.

The Four Pillars of GIS Ready Data

Genuinely GIS ready data satisfies four requirements simultaneously. First, it uses a defined and correct coordinate reference system. Second, it is in a format compatible with the target GIS platform. Third, it carries a complete and correctly typed attribute schema. Fourth, it includes metadata that meets the applicable standard. All four must be present. Missing any one of them creates integration problems downstream.

Furthermore, GIS ready data must be stable under repeated processing. A dataset that loads correctly in one environment but fails in another (due to encoding issues, null geometry, or field name conflicts) is not truly GIS ready. It is merely GIS compatible under specific conditions.

Key GIS Vector Formats

Format selection is one of the first decisions in a GIS data pipeline. Each format carries trade-offs in compatibility, size, and capability. Understanding these trade-offs prevents format-related failures at ingestion.

Format	Best Use	Key Limitation	ArcGIS / QGIS
Shapefile	Legacy system exchange, simple deliverables	10-character field name limit; 2 GB file size cap; no null geometry support	✅ Both
GeoJSON	Web APIs, lightweight exchange, dashboard feeds	WGS84 only by spec; poor performance at large feature counts	✅ Both
File Geodatabase	Enterprise ArcGIS workflows, large datasets, domain support	Esri proprietary; limited open-source read support	✅ ArcGIS native; QGIS read-only
KML / KMZ	Visualisation, Google Earth sharing, stakeholder comms	WGS84 only; no attribute domain support; not suitable for analysis	✅ Both (visualisation only)
GeoPackage	Open standard replacement for shapefile; multi-layer storage	Less widely supported in older enterprise GIS environments	✅ Both — recommended open standard

Why Shapefile Field Name Limits Cause Problems

The shapefile format truncates field names to ten characters. This is a hard limit inherited from dBASE III. Therefore, a field named asset_condition_rating becomes asset_cond — silently, without warning in some tools. As a result, downstream systems that expect the full field name break without an obvious error message.

Moreover, shapefiles cannot store null geometry, a feature with no spatial component is simply dropped. Consequently, assets recorded without coordinates disappear from the dataset entirely. GeoPackage and File Geodatabase both handle these cases correctly. For new projects, GeoPackage is the recommended open-standard alternative.

Coordinate Reference Systems: GDA2020 vs WGS84 and Why the Difference Matters

Datum selection is the single most consequential decision in a spatial data pipeline. A wrong datum does not cause an obvious error. Instead, it silently shifts every feature by a fixed offset, often around 1.8 metres in Australia. This offset is invisible in casual review but breaks precision analysis, infrastructure setout, and council asset registers.

GDA94, GDA2020, and WGS84

GDA94 (Geocentric Datum of Australia 1994) was Australia’s primary horizontal datum for over two decades. However, it was fixed to the position of the Australian tectonic plate in 1994. Because the plate moves approximately 7 centimetres per year north-northeast, GDA94 coordinates now differ from global GPS coordinates by approximately 1.8 metres.

GDA2020 corrects this. It realigns Australian coordinates to the International Terrestrial Reference Frame (ITRF). As a result, GDA2020 and current GPS coordinates agree to within centimetres. The Australian Government mandated GDA2020 as the standard datum for new spatial data from 2020 onwards.

WGS84 is the global datum used by GPS and web mapping platforms. In practice, WGS84 and GDA2020 coordinates are nearly identical. Furthermore, GeoJSON and KML are specified to use WGS84 exclusively. Therefore, data delivered in these formats should be treated as WGS84 regardless of what the source CRS metadata states.

MGA2020

MGA2020 (Map Grid of Australia 2020) is the projected version of GDA2020. It uses the UTM projection divided into zones. Most Australian infrastructure and council asset data should be delivered in the relevant MGA2020 zone. For example, MGA Zone 55 for Sydney and southeast Queensland, MGA Zone 54 for Melbourne and Adelaide.

Practical rule: Always confirm the CRS of incoming LiDAR data before ingestion. In ArcGIS Pro, use Data Management Tools > Projections and Transformations > Define Projection if the CRS is undefined.

Attribute Schema Design for GIS Ready Data

A well-designed attribute schema is what separates GIS ready data from a point cloud dump. The schema defines what information each feature carries, how it is typed, and what values are valid. Poor schema design creates data quality problems that persist for years.

Field Naming Conventions

Field names should be short, descriptive, and consistent across layers. Use underscores rather than spaces or camelCase. Avoid abbreviations unless they are standardised within your organisation. In addition, design field names with the 10-character shapefile limit in mind because data often moves between formats over its lifecycle.

Attribute Domains and Coded Value Lists

Attribute domains constrain what values can be entered in a field. In ArcGIS File Geodatabase and Enterprise Geodatabase, domains enforce data integrity at the schema level. For example, a surface_type field with a domain of {Asphalt, Concrete, Gravel, Unsealed} prevents free-text entry that breaks downstream queries.

However, domain errors are among the most common causes of failed data loads in ArcGIS Enterprise. When incoming data carries values outside the defined domain, for example “asphalt” in lowercase instead of “Asphalt”, the load fails silently or truncates the affected records. Therefore, validate attribute values against all target domains before ingestion.

Recommended attribute fields for LiDAR-derived asset layers

asset_id — unique identifier, text, matches asset register
capture_dt — date of LiDAR capture, date type
source_crs — coordinate reference system of source data, text
accuracy_m — positional accuracy in metres, double
surf_type — coded domain value, text (10 chars max for shapefile compatibility)
cond_grade — condition rating, integer with domain {1, 2, 3, 4, 5}
data_owner — responsible organisation, text
review_yr — next review year, integer

GIS ready data pipeline diagram showing five stages from LiDAR capture through format selection, coordinate system, attribute schema, metadata, and GeoAI delivery — GIS ready data pipeline diagram

Metadata Standards

Metadata is the information that describes a spatial dataset. Without it, a dataset cannot be discovered, evaluated, or governed. Moreover, many Australian government procurement contracts and data sharing agreements require ISO 19115-compliant metadata as a deliverable condition.

ISO 19115: The International Standard

ISO 19115 defines the schema for geographic information metadata. It specifies elements including dataset title, abstract, date of creation, spatial resolution, coordinate reference system, lineage, and contact information. A compliant metadata record allows another organisation to discover the dataset, assess its fitness for purpose, and understand its provenance.

ANZLIC: The Australian and New Zealand Profile

ANZLIC (the Spatial Information Council of Australia and New Zealand) maintains a national metadata profile based on ISO 19115. The ANZLIC profile adds mandatory elements specific to the Australian context such as jurisdiction, custodian organisation, and access constraints under Australian privacy legislation.

In practice, councils and state agencies submitting data to the PSMA (now Geoscape) or the national LOCATION dataset must comply with ANZLIC metadata requirements. Therefore, any LiDAR-derived dataset intended for government spatial infrastructure should carry ANZLIC-compliant metadata from delivery.

Minimum metadata elements for LiDAR-derived GIS datasets

ISO 19115 Required

Dataset title and abstract
Date of creation and publication
Spatial resolution and scale
Coordinate reference system
Lineage statement (capture method)
Point of contact

ANZLIC Additional

Jurisdiction (state / territory / local)
Custodian organisation
Access constraints (public / restricted)
Use limitation statement
Data currency and review date
AGIFT classification (if applicable)

How GeoAI Delivers GIS Ready Data for Industry

Most survey providers deliver a point cloud and consider the job done. GeoAI takes a different approach. Every LiDAR survey output is prepared as GIS ready data. We make sure the correct datum, validated schema, compliant metadata, and formats matched to your environment.

Datum and Coordinate System Alignment

GeoAI delivers all spatial data in GDA2020 and the relevant MGA2020 zone by default. Furthermore, we confirm the target coordinate system with your GIS team before capture. As a result, incoming data aligns immediately with your existing layers with no reprojection required on your side.

Attribute Schema Matched to Your Asset Register

Before each survey, GeoAI reviews your existing GIS schema. We map our output fields directly to your attribute structure. Consequently, field names, data types, and coded domain values match your target geodatabase before the data arrives. This eliminates manual schema mapping and domain validation errors at your end.

ANZLIC-Compliant Metadata Included as Standard

Every GeoAI dataset is delivered with a complete metadata record. This covers all ISO 19115 mandatory elements and the ANZLIC profile additions, including jurisdiction, custodian, access constraints, lineage statement, and data currency. Moreover, metadata is delivered in XML format ready for import into ArcGIS Pro or your state spatial catalogue.

📐

GDA2020

All data delivered in the correct Australian datum

🗂️

Schema Matched

Fields and domains aligned to your asset register

📋

ISO 19115

ANZLIC-compliant metadata included with every dataset

🌐

Multi-Format

GeoPackage, FGDB, LAZ, GeoJSON — your choice

✅

QA Checked

Geometry and domain validation before delivery

Frequently Asked Question

What is the difference between GDA2020 and WGS84?

GDA2020 is the Australian national datum, aligned to the International Terrestrial Reference Frame at the 2020 epoch. WGS84 is the global datum used by GPS and web mapping. At the GDA2020 epoch, the two datums differ by less than a centimetre in Australia. However, GDA94 (the previous Australian datum) differs from WGS84 by approximately 1.8 metres. Therefore, always confirm which Australian datum a dataset uses before loading it into a GDA2020 environment.

What metadata standard do Australian councils require?

Most Australian councils and state agencies require ANZLIC-compliant metadata, which is based on ISO 19115. The ANZLIC profile adds mandatory elements including jurisdiction, custodian organisation, and access constraints under Australian legislation. In practice, the minimum requirement is a complete ISO 19115 record. Councils submitting data to state spatial data catalogues must also satisfy the ANZLIC profile elements. Check with your state spatial authority for the specific metadata template required in your jurisdiction.

How do I load a LiDAR point cloud into QGIS?

QGIS 3.18 and later support point cloud layers natively. Drag a LAZ or LAS file into the QGIS map canvas, or use Layer > Add Layer > Add Point Cloud Layer. QGIS renders point clouds with automatic elevation colouring and supports attribute-based filtering. For large datasets, QGIS uses a streaming renderer that displays the cloud progressively. Furthermore, the PDAL (Point Data Abstraction Library) tools available via the Processing Toolbox allow filtering, clipping, and format conversion within QGIS without external software.

What causes attribute domain errors when loading data into ArcGIS Enterprise?

Domain errors occur when incoming attribute values do not match the coded value list defined in the target geodatabase. Common causes include case differences (“asphalt” vs “Asphalt”), abbreviated values not in the domain list, and numeric codes where the domain expects text descriptions. The ArcGIS Append tool will reject or null affected records without always providing a clear error message. Consequently, validate all incoming attribute values against target domains before ingestion — using FME’s FieldValueMapper or ArcGIS Pro’s Field Calculator to standardise values before the append step.

Related GeoAI Services

For LiDAR-based asset data collection for council road networks, see our Road Asset Management Sydney service. For survey data delivered as verified as-built drawings, visit our As-Built Drawing Survey Sydney page. For further reading on Australian spatial data standards, the ICSM GDA2020 technical manual and the ANZLIC metadata guidelines are the authoritative references.

Category List

Recent Post

What Is GIS-Ready Data? How LiDAR Outputs Feed Into Spatial Systems