/
Cadastre and Address Modernisation (CAM)

Cadastre and Address Modernisation (CAM)

Owned by James Wall
Last updated: 06, Apr, 2025
9 min read

What’s happening?

Queensland’s spatial cadastre (land boundary) and location (street) address datasets are changing for the better!

From a planned date of 1 July 2025, the current Digital Cadastral Database (DCDB) and Queensland Address Management Framework (QAMF) systems and datasets will be migrating to entirely new systems and datasets.

The DCDB, where spatial cadastral data is presently managed and maintained, will be replaced by the Queensland Spatial Cadastral Fabric (QSCF) environment.

QAMF, where location addressing data is presently managed and maintained, will be replaced by the Queensland Address & Location Information (QALI) environment.

 

When is it happening?

QSCF and QALI are scheduled to go live by 1 July 2025.

DCDB

The DCDB will enter “hibernation” in mid-May 2025 (date TBA). The following spatial cadastral datasets provided via QSpatial, Open Data Portal, Queensland Globe, Queensland foundation data web service, and other platforms and services will remain available, but will temporarily not be updated from the TBA date:

Once migration of data from DCDB to QSCF is complete, which is currently estimated to take approximately two (2) weeks, updates for these cadastral datasets will resume.

  • Planning Cadastre (PlanningCadastre)

    • PlanningCadastre/AreasOfRegionalInterest

    • PlanningCadastre/CoastalManagement

    • PlanningCadastre/CoordinatedProjects

    • PlanningCadastre/GovernmentLand

    • PlanningCadastre/GovernmentLandSurplus

    • PlanningCadastre/IndigenousLandInterests

    • PlanningCadastre/LandParcelPropertyFramework

    • PlanningCadastre/LandParcelPropertyFramework_TimeAware

    • PlanningCadastre/LandParcelPropertyFrameworkFeature_TimeAware

    • PlanningCadastre/LandParcelTemporal

    • PlanningCadastre/LandParcelTemporalFeature

    • PlanningCadastre/LandUse

    • PlanningCadastre/RegionalPlans

    • PlanningCadastre/ResidentialLandSupply

    • PlanningCadastre/StateDevelopmentAreas

QAMF

Transition from QAMF on 1 July 2025 is anticipated to be seamless. However, the following location addressing datasets provided via QSpatial, Open Data Portal, Queensland Globe, Queensland foundation data web service, and other platforms and services may be temporarily impacted:

Delays to the provision of data and data services are unfortunately unavoidable during transition to new systems. Our teams will be working hard to minimise disruption.

 

What’s the plan?

Migration of spatial cadastral data from the DCDB to QSCF is anticipated to take approximately two (2) weeks, from the currently estimated mid-May (TBA) to end-May.

During migration

Ceasing update activity in the DCDB will allow the most up-to-date data, representing approximately 3 million land parcels across Queensland, to be migrated to QSCF, while reducing the risk of disparity between the old and new systems.

During this time, our cadastral teams will continue to update spatial cadastre data in an “offline” version of QSCF. One migration from DCDB to QSCF is complete, this offline data will be uploaded into the online QSCF, swiftly bringing Queensland’s spatial cadastral data up to date.

After migration

By 1 July 2025, it is expected that QSCF will be fully operational and functioning as the replacement for DCDB.

From the activation date, the legacy DCDB data currently provisioned via the channels and services noted above will be “emulated” from QSCF.

This legacy data emulation will mirror existing datasets as closely as possible, but there are some unavoidable changes to the data schema and data architecture, detailed below. Every effort has been made to ensure that the emulated data is as non-disruptive as possible. Sample emulated datasets will be made available soon.

Future state

New QSCF datasets, with enhanced features and functionality, will be made available by end-2025. Sample datasets will be provided in advance for testing and assessment. More information will be made available soon.

Legacy DCDB emulation will continue to be provisioned for at least 12 months, giving users time to take advantage of QSCF enhancements in their own systems.

Migration of location addressing data from QAMF to QALI is anticipated to be far less disruptive, and is planned to take only 24 hours at most.

The nature of location addressing data means that the new QALI datasets will be functionally identical to existing QAMF datasets, with enhanced features (detailed below) available immediately.

 

What do I need to do?

Interruption to DCDB, anticipated to last for two weeks from mid-May (TBA), will not impact downloads or functionality from current platforms and services (noted above). Spatial cadastral data will remain available but will temporarily not receive updates.

After data migration is complete, updates to existing platforms and services will resume from the QSCF “emulation”. There are some differences in the data schema that you should be aware of - these are listed below. Further technical detail will be made available soon to help ensure a seamless transition from the legacy to the emulated schema.

 

Why is this being done?

The existing DCDB is a custom-built (“bespoke”) technical environment that is over 30 years old, using systems and architectures that are outdated, not fit-for-purpose, and extremely expensive and difficult to support and maintain. Information technology systems fitting these criteria are referred to as “deprecated”.

  • The DCDB is incapable of handling three-dimensional (3D) data, and is extremely limited in its ability to ingest, maintain, and represent the precise, timely and comprehensive spatial cadastral data that our users require.

  • Data generated and provided by Queensland’s surveyors, such as distance and bearing information, which is required by the Survey and Mapping Infrastructure Act 2003 (PDF link), is effectively “lost” in the DCDB, which has no capability to store it.

  • DCDB workflows are entirely manual, with no capacity for automation, and no ability for operators to customise their operating environments.

  • The technology “stack” underpinning the DCDB is no longer supported by vendors, will be completely phased out by Queensland Government by mid-2026.

  • Cumbersome, time-consuming data transfer processes, which shuttle DCDB data to other systems for a variety of purposes, are increasingly prone to failure due to the size and complexity of the dataset.

  • Personnel with the highly specialised skills and experience necessary to operate and maintain the 30-year-old DCDB environment are becoming increasingly rare.

The new QSCF environment is built on a contemporary technical foundation that is widely recognised as the international standard. Queensland Government already makes extensive use of Esri Enterprise systems, and Parcel Fabric is available as part of these system at no additional cost to government. It is fully supported by Esri Inc. and Esri Australia as part of our ongoing Enterprise Agreement (EA).

  • QSCF unlocks full 3D capability, allowing Queensland’s spatial cadastral data to better reflect and represent the real-world.

  • Data generated and provided by surveyors, such as distance and bearing information, will not only be correctly stored by QSCF, but can be used to rapidly improve spatial cadastre accuracy over broad areas using a “least squares adjustment” process.

  • QSCF allows for extensive automation of processes, and individual operators will be able to customise their own workflows and environments to better accommodate their preferred ways of working.

  • QSCF is underpinned by a modern, widely used information architecture and technology stack, fully supported by the vendor.

  • Allows for real-time transfer of data between systems via data streaming - no more overnight transfer of the entire database from one place to another. Instead, only the “deltas” - changes - are shared, saving time and bandwidth, and significantly decreasing risk.

  • Nationally aligned with other jurisdictions and with ICSM’s Cadastre 2034 strategy and 3DCSDM.

  • Standardised technologies that are widely understood, used, and taught.

Like the DCDB, the QAMF location address management and maintenance environment is built on deprecated legacy systems and architectures.

The primary challenge with QAMF is that it is unable to maintain “complex” addressing, in both senses of the word: addresses that are not straightforward (such as a separate address for a granny flat at the rear of a property, where the main house is for the primary occupants and the granny flat is leased to tenants), and addresses for complexes such as gated estates and townhouse complexes, retirement villages, universities, apartment buildings, shopping centres, and so forth.

In essence, the current QAMF environment treats each of these “complexes” as a single address. For example, a residential building of 30 separate apartments will be stored as a single address - 1 Smith Street - as only the parcel of land on which the building sits can be assigned an address.

QALI, again like QSCF, is built on standards-based and, in this case, fully open-source technologies. Open-source minimises the cost and support challenges faced by our other deprecated systems, while standards-based means that data can be rapidly enhanced, updated, and transferred, depending on the needs of our users.

QALI uses contemporary technologies such as semantic data and data streaming to not only ensure its readability and applicability to different use cases, but to make data updates near-instantaneous. Timely and accurate address data is absolutely vital, ensuring the delivery of goods, utilities, and services - most importantly emergency services - to locations.

The new semantic model underpinning QALI also unlocks the ability to easily manage and maintain complex addressing across all dimensions.

 

More information

This page will continue to develop in the coming weeks and months, so check back regularly!

 

Existing Polygon Feature Classes (DCDB)

Emulating Polygon Feature Classes (QSCF)

Existing Polygon Feature Classes (DCDB)

Emulating Polygon Feature Classes (QSCF)

1 create table if not exists prop.qld_cadastre_dcdb (
2 lot varchar(5) null,
3 plan varchar(10) null,
4 lotplan varchar(15) null,
5 seg_num integer null,
6 par_num integer null,
7 segpar integer null,
8 par_ind integer null,
9 lot_area numeric(38,8) null,
10 excl_area numeric(38,8) null,
11 lot_volume numeric(38,8) null,
12 surv_ind varchar(1) null,
13 tenure varchar(40) null,
14 prc integer null,
15 parish varchar(20) null,
16 county varchar(16) null,
17 lac integer null,
18 shire_name varchar(40) null,
19 feat_name varchar(60) null,
20 alias_name varchar(400) null,
21 loc integer null,
22 locality varchar(30) null,
23 parcel_typ varchar(24) null,
24 cover_typ varchar(10) null,
25 acc_code varchar(40) null,
26 ca_area_sqm numeric(38,8) null,
27 smis_map varchar(100) null,
28 objectid integer not null,
29 gdb_geomattr_data bytea null,
30 shape geometry null
31 );

1 CREATE TABLE proplegacy.qld_cadastre_dcdb (
2 lot character varying(5),
3 plan character varying(10),
4 lotplan character varying(15),
5 seg_num integer,
6 par_num integer,
7 segpar integer,
8 par_ind integer,
9 lot_area numeric(38,8),
10 excl_area numeric(38,8),
11 lot_volume numeric(38,8),
12 surv_ind character varying(1),
13 tenure character varying(40),
14 prc integer,
15 parish character varying(20),
16 county character varying(16),
17 lac integer,
18 shire_name character varying(40),
19 feat_name character varying(60),
20 alias_name character varying(400),
21 loc integer,
22 locality character varying(100),
23 parcel_typ character varying(24),
24 cover_typ character varying(10),
25 acc_code character varying(100),
26 ca_area_sqm numeric(38,8),
27 objectid integer NOT NULL,
28 gdb_geomattr_data bytea,
29 shape public.geometry,
30 CONSTRAINT enforce_srid_shape CHECK ((public.st_srid(shape) = 4283))
31 );

Existing Line Feature Classes (DCDB)

Emulating Line Feature Classes (QSCF)

1 create table if not exists prop.qld_cadastre_lotbdy (
2 linestyle integer not null,
3 seg_num integer not null,
4 par_num integer not null,
5 objectid integer not null,
6 gdb_geomattr_data bytea null,
7 shape geometry null
8 );

1 CREATE TABLE proplegacy.qld_cadastre_lotbdy (
2 linestyle integer NOT NULL,
3 seg_num integer NOT NULL,
4 par_num integer NOT NULL,
5 objectid integer NOT NULL,
6 gdb_geomattr_data bytea,
7 shape public.geometry,
8 CONSTRAINT enforce_srid_shape CHECK ((public.st_srid(shape) = 4283))
9 );

1 create table if not exists prop.qld_cadastre_road (
2 linestyle integer not null,
3 seg_num integer not null,
4 par_num integer not null,
5 objectid integer not null,
6 gdb_geomattr_data bytea null,
7 shape geometry null
8 );

1 CREATE TABLE proplegacy.qld_cadastre_road (
2 linestyle integer NOT NULL,
3 seg_num integer NOT NULL,
4 par_num integer NOT NULL,
5 objectid integer NOT NULL,
6 gdb_geomattr_data bytea,
7 shape public.geometry,
8 CONSTRAINT enforce_srid_shape CHECK ((public.st_srid(shape) = 4283))
9 );

1 create table if not exists prop.qld_cadastre_natbdy (
2 linestyle integer not null,
3 seg_num integer not null,
4 par_num integer not null,
5 objectid integer not null,
6 gdb_geomattr_data bytea null,
7 shape geometry null
8 );

1 CREATE TABLE proplegacy.qld_cadastre_natbdy (
2 linestyle integer NOT NULL,
3 seg_num integer NOT NULL,
4 par_num integer NOT NULL,
5 objectid integer NOT NULL,
6 gdb_geomattr_data bytea,
7 shape public.geometry,
8 CONSTRAINT enforce_srid_shape CHECK ((public.st_srid(shape) = 4283))
9 );

Existing Non-Spatial Tables (DCDB)

Emulating Non-Spatial Tables (QSCF)

1 create table if not exists prop.qld_cadastre_bup_lot (
2 lotplan varchar(15) null,
3 bup_lot varchar(5) null,
4 bup_plan varchar(10) null,
5 bup_lotplan varchar(15) null,
6 lot_area_am integer null,
7 objectid integer not null
8 );

1 CREATE TABLE proplegacy.qld_cadastre_bup_lot (
2 lotplan character varying(15),
3 bup_lot character varying(5),
4 bup_plan character varying(10),
5 bup_lotplan character varying(15),
6 lot_area_am integer,
7 objectid integer NOT NULL
8 );

create or replace view prop.qld_cadastre_bup_link
AS
SELECT row_number() OVER (ORDER BY qld_cadastre_bup_lot.bup_lotplan)::integer AS objectid,
qld_cadastre_bup_lot.lotplan,
qld_cadastre_bup_lot.bup_lotplan, (('https://apps.information.qld.gov.au/data/v2/Cadastre/SmartMap?lot='::text || qld_cadastre_bup_lot.bup_lot::text) || '&plan='::text) || qld_cadastre_bup_lot.bup_plan::text AS smartmap,
(('https://search.titlesqld.com.au/product-search?LotNo='::text || qld_cadastre_bup_lot.bup_lot::text) || '&PlanNo='::text) || qld_cadastre_bup_lot.bup_plan::text AS title_search
FROM prop.qld_cadastre_bup_lot;

1 CREATE TABLE proplegacy.qld_cadastre_bup_link (
2 objectid integer NOT NULL,
3 lotplan character varying(15),
4 bup_lotplan character varying(15),
5 smartmap text,
6 title_search text
7 );

1 create table if not exists prop.qld_cadastre_link (
2 objectid integer not null,
3 lotplan varchar(15) null,
4 smartmap text null,
5 title_search text null
6 );

1 CREATE TABLE proplegacy.qld_cadastre_link (
2 objectid integer NOT NULL,
3 lotplan character varying(15),
4 smartmap text,
5 title_search text
6 );

Version 1.0 created 4 May 2025