The Planning Insights dataset is to be used in conjunction with Cadastre or G-NAF (Geocoded National Address File) products to enable spatial representation and analysis. Annex A describes how these linkages are made and considerations for users when applying the linkages.
Planning Insights provides a linkage to Cadastre where the Planning Insights base_cadastre_pid is equal to the base_cadastre_pid in Cadastre. Joining the data in this manner will provide both primary and secondary linkages. Please note that there are records in Cadastre that do not link to Planning Insights but have been assigned a default base_cadastre_pid value that is equal to that record’s cadastre_pid. These are non-Road parcels whose base_cadastre_pid will not match a base_cadastre_pid in planning_insights. Please also note that this join will enable links to Cadastre that have a title_status of ‘Not Titled’ - user discretion is advised when utilising links to these parcels.
A primary link is one where the cadastre has direct spatial intersection with a planning zone or overlay boundary. Primary links are generally made to Cadastre with parcel_type of ‘Lot’, but in some scenarios can also be made with Strata or Stratum parcel types. Road parcels are not linked to in Planning Insights. If only primary linkages are required by a user, the above join can be run while filtering out Cadastre where the Cadastre cadastre_pid is not equal to the Cadastre base_cadastre_pid, which indicates that the cadastre is not linked to directly and is a secondary link.
The majority of primary links will be to Lot parcels in Cadastre. The cadastre parcel with cadastre_polygon_pid of ‘cp76d87f9b350b5’ is a Lot parcel at a site with no other parcels present. Zoning and overlay information are spatially linked to this Lot parcel (primary link).
In the states of ACT, NSW, QLD and TAS there are parcels with height or depth limitations (e.g. a tunnel passes underneath the parcel) called ‘Stratum’ parcels. In the NSW example for the cadastre_polygon_pid of ‘cpb0d3cfd01b465’, the NSW Jurisdiction has supplied a single Stratum parcel at a site (blue parcel). Geoscape has a concept of ‘base parcels’ in the Cadastre product which describes the counts of Strata parcels (e.g. units, townhouses) for a strata development and provides a ‘base’ coverage of Lot parcels. Base parcels have a base_parcel value of ‘Yes’ in Cadastre. At this site, Geoscape has created a Lot parcel (source = ‘Geoscape Australia’, red parcel) underneath the provided Stratum parcel (blue parcel) to provide Lot coverage. Planning Insights has provided a primary link to the Stratum parcel (primary link) at this location as the Geoscape Australia sourced Lot parcel here is not provided by the NSW Jurisdiction.
At this site in VIC there are Strata parcels (blue parcels) that do not have an underlying Lot parcel provided by the VIC Jurisdiction. At these sites, Geoscape creates a base Lot parcel with source value of ‘Geoscape Australia’ (red parcel) that is representative of the development (parcels with same plan). These Geoscape Australia parcels are created to enable the representation of strata counts for the development. In other states a primary link to the Geoscape Australia parcel will generally be made in Planning Insights over a link to Strata. However, for VIC many Strata parcels have been assigned a primary linkage to Planning Insights due to large developments that don’t meet a traditional definition of strata, with the Strata parcels being linked to in preference over the created Geoscape Australia Lot parcel.
Secondary links are links that have not been made through a direct spatial intersection between cadastre and planning zone or overlay boundaries. Instead, these secondary linkages are inferred through a spatial relationship between the centroid of cadastre with no primary link and the polygon of a cadastre that has a primary link. Secondary linkages have been created principally to enable unlinked parcels such as Stratum (parcels with height or depth limitations) and Strata parcels (e.g. units, townhouses, etc.) to inherit the zoning and overlay information of the underlying Lot parcel that has a primary link.
For example, the orange Lot parcel below has a direct spatial link (primary) to planning zone and overlay boundaries. The cadastre_pid and base_cadastre_pid match for this record.
At this same location a blue Strata parcel exists that has not been linked to planning zone or overlay boundaries through spatial intersection. The red centroid of this Strata parcel intersects the orange cadastre with a primary link, so a secondary link to planning zone and overlay information is made to the Strata parcel. The Strata parcel is therefore assigned a base_cadastre_pid of ‘cad4f0beced777d’ which matches the cadastre_pid of the orange Lot parcel with a primary linkage. The cadastre_pid and base_cadastre_pid will match for the Strata parcel which is indicative of a secondary linkage.
User discretion is advised when utilising these secondary links as they are spatial linkages to cadastre with primary linkages rather than direct spatial linkage to planning zone or overlay boundaries. A potential risk here would be that the cadastre with secondary linkage does not actually intersect the planning zone or overlay boundary for which it has been assigned zone or overlay information through a primary link to a cadastre. For example, if a green flood overlay intersected the orange Lot parcel (primary link) but not the blue Strata parcel (secondary link), the blue Strata parcel would still receive a flood overlay flag through the secondary relationship. This can also occur for planning zone assignment but will be to a much lesser extent across Planning Insights due to the better alignment between planning zones and cadastre.
The cadastre with cadastre_polygon_pid of ‘cp801f9e3572ce9’ is a Strata parcel that relates to a block of townhouses (blue parcels) with plan of ‘S638’. At this site a Geoscape Australia parcel (red) has been created to provide base Lot coverage and enable strata counts for the site. Planning Insights provides a primary link here between planning zone/overlay information and the Geoscape Australia parcel which has a cadastre_pid of ‘cad59418a6700a6’, instead of the Strata parcels. To provide a secondary link to this Strata parcel, Geoscape has assigned the Strata parcels at this site (e.g. cadastre_polygon_pid = ‘cp801f9e3572ce9’) a base_cadastre_pid of ‘cad59418a6700a6’ which allows them to be linked to zoning and overlay information that relates to the Geoscape Australia parcel.
The cadastre with cadastre_polygon_pid of ‘cp86fb93ca8792b’ is a Stratum parcel (blue parcel) in Sydney that has a tunnel running underneath it and therefore has a depth limitation. Geoscape creates a base Lot parcel (source = ‘Geoscape Australia’) under this Stratum parcel for base Lot coverage (red parcel) with cadastre_pid of ‘cadc578985b89a9’. Planning Insights has not provided a primary link between the planning zone/overlay information and the Stratum polygon and has instead provided a primary link to the created Geoscape Australia parcel. To provide a secondary link to this Stratum parcel, Geoscape has assigned it with a base_cadastre_pid of ‘cadc578985b89a9’ which allows it to be linked to planning zone and overlay information that relates to the Geoscape Australia parcel.
In a small number of cases, a parcel with a Lot parcel type can have a secondary linkage. This occurs where there is a Lot parcel that overlaps a second parcel but only the second parcel has been linked to with a primary linkage. The example cadastre (cadastre_polygon_pid = ‘cp45f31b183f7c3’, cadastre_pid = ‘cad6512d1295efd’, blue parcel) is a small Lot parcel that overlaps a larger Lot parcel (cadastre_pid = ‘cad152c87fef07e’, red parcel) that has been assigned a base_parcel value of ‘Yes’. In this case the larger parcel has been linked to via a primary link as it is the base Lot parcel. To provide a secondary link to the smaller Lot parcel, Geoscape has assigned it with a base_cadastre_pid of ‘cad152c87fef07e’ which allows it to be linked to planning zone and overlay information that relates to the larger Lot parcel.
Small Lot parcel.
Small Lot parcel with large overlapping Lot parcel.
To spatially enable the planning_insights table, a join can be made to the polygon geometry within the cadastre table, using the base_cadastre_pid between the two tables to make the join. Any other required information from cadastre such as parcel_id, parcel_type, area, etc. can also be selected in this join.
An inner join can be used if only the records in cadastre that have a link to planning_insights are required. This will exclude road cadastre and cadastre for which there is no planning zone or overlay information. To link to all cadastre, use a left join (see example below). If only primary linkages are required, filter to exclude cadastre where the cadastre_pid and base_cadastre_pid do not match (secondary linkages) from the join. It is recommended that these joins are done within a database due to the size of the datasets involved. Please note that the cadastre and planning_insights tables have attributes with the same names (e.g. ‘state’, ‘date_created’), so it is recommended to either prefix one table’s attributes or retain only the attributes from one table for the join.
The result of the join will provide high-level zoning and overlay information for the cadastre, as well as permitted, permitted with controls and prohibited uses. Please note that the pi_zone_code will only provide a single zone code for the cadastre, even if two zones relate to it. It is recommended to consult the planning_insights_zoning table for this detailed zoning information.
An example of how to join the tables is shown below. This SQL keeps all attribution from cadastre and attaches all attribution from planning_insights except for state and date_created attributes. Please note that cadastre that don’t join to planning_insights will have empty string values for the planning insights attribution.
To spatially enable the planning_insights_zoning table, a join can be made to the polygon geometry within the cadastre table, using the base_cadastre_pid between the two tables to make the join. Any other required information from cadastre such as parcel_id, parcel_type, area, etc. can also be selected in this join.
An inner join can be used if only the records in cadastre that have a link to planning_insights_zoning are required. This will exclude road cadastre and parcels for which zoning information has not been linked to. To link to all cadastre, use a left join (see example below). If only primary linkages are required, filter to exclude cadastre where the cadastre_pid and base_cadastre_pid do not match (secondary linkage) from the join. It is recommended that these joins are done within a database due to the size of the datasets involved. Please note that the cadastre and planning_insights_zoning tables have attributes with the same names (‘state’ and ‘date_created’) so it is recommended to either prefix one table’s attributes or retain only the attributes from one table for the join.
The result of the join will provide in-depth zoning information for the cadastre. Please note that multiple planning zones can relate to a single cadastre.
An example of how to join the tables is shown below. This SQL keeps all attribution from cadastre and attaches all attribution from planning_insights_zoning except for the state and date_created attributes. Please note that cadastre that don’t join to planning_insights_zoning will have empty string values for the planning zone attribution.
To retain only primary linkages and filter out secondary linkages, add this:
1wherea.cadastre_pid=a.base_cadastre_pid;
Linkages to Cadastre - planning_insights_overlays¶
To spatially enable the planning_insights_overlays table, a join can be made to the polygon geometry within the cadastre table, using the base_cadastre_pid between the two tables to make the join. Any other required information from cadastre such as parcel_id, parcel_type, area, etc. can also be selected in this join.
An inner join can be used if only the records in cadastre that have a link to planning_insights_overlays are required. This will exclude road cadastre and parcels for which overlay information has not been linked to. To link to all cadastre, use a left join (see example below). If only primary linkages are required, filter to exclude cadastre where the cadastre_pid and base_cadastre_pid do not match (secondary linkage) from the join. It is recommended that these joins are done within a database due to the size of the datasets involved. Please note that the cadastre and planning_insights_overlays tables have attributes with the same names (‘state’ and ‘date_created’) so it is recommended to either prefix one table’s attributes or retain only the attributes from one table for the join.
The result of the join will provide in-depth overlay information for the cadastre. Please note that multiple overlays can relate to a single cadastre.
An example of how to join the tables is shown below. This SQL keeps all attribution from cadastre and attaches all attribution from planning_insights_overlays except for the state and date_created attributes. Please note that cadastre that don’t join to planning_insights_overlays will have empty string values for the overlay attribution.
There are cadastre that are comprised of more than one polygon. These can be identified by searching for duplicate cadastre_pid values in the cadastre table. These records will have the same cadastre_pid but different cadastre_polygon_pid values. This usually occurs where the cadastre has been split by a road, river or other feature, but the parts together still represent the smallest legal area of land capable of sale without further approval to subdivide. Please note that due to the nature of the link from Cadastre to Planning Insights (base_cadastre_pid linkage), if an overlay (e.g. flood, bushfire, etc.) intersects only one of these parcels the overlay relationship will be applied to both parcels through the base_cadastre_pid. This also applies to the planning zone relationships with these parcels, but to a much lesser extent due to the better alignment of planning zones with cadastre. An example is shown below that describes the two polygons (cadastre_polygon_pid values of ‘cpa23de6b188159’ and ‘cpd85eee2e3ce50’) that are part of the same cadastre (cadastre_pid value of ‘cad6124658cc2cb’).
Linkages to G-NAF through planning_insights_address¶
G-NAF (Geocoded National Address File) is a trusted index of Australian address information. It contains the state, suburb, street, number and coordinate reference (or “geocode”) for street addresses in Australia. G-NAF addresses are linked to base_cadastre_pids in Cadastre through spatial intersection, which allows Planning Insights attribution at the cadastre level to be assigned to the address. The relationship between G-NAF and Planning Insights is provided within the planning_insights_address table which links G-NAF ADDRESS_DETAIL_PID to Planning Insights base_cadastre_pid. G-NAF Addresses for which Geoscape has low confidence that they physically exist at a location, such as LOCALITY (address point placed in centre of suburb/locality) and STREET LOCALITY (point placed in centre of street) geocodes are excluded from this spatial link. Retired G-NAF addresses (confidence = -1) are also excluded from the linkage. These addresses will not link to Planning Insights information.
G-NAF can be linked to Planning Insights by joining the ADDRESS_DETAIL_PID from the G-NAF ADDRESS_DETAIL table to the address_detail_pid in the planning_insights_address table. From this, the base_cadastre_pid in the planning_insights_address table can be used to link out to the planning_insights, planning_insights_zoning and planning_insights_overlays tables to provide the Planning Insights attribution at the address level. The LONGITUDE and LATITUDE values from the G-NAF ADDRESS_DEFAULT_GEOCODE table can also be linked to provide a spatial representation of the addresses as points. Please note that G-NAF coordinates are available in both GDA2020 and GDA94 projections – to ensure alignment to Planning Insights use G-NAF in the GDA2020 projection. When joining these tables, be aware of matching attribute names across tables e.g. address_detail_pid, date_created, etc.
It is recommended that these tables are joined together in a database due to file sizes.
The SQL to join G-NAF to the Planning Insights tables is provided below. Please note that to make the output spatial you will need to convert the latitude and longitude values from the GNAF address_default_geocode table to point geometry. Also note that addresses that don’t join to Planning Insights will have empty string values for the Planning Insights attribution.
Linkages to G-NAF – Address links to multiple cadastre with primary linkage to Planning Insights¶
Addresses are spatially linked to cadastre with primary linkages to Planning Insights for the planning_insights_address table. In some cases, an address point spatially intersects two cadastre that have a primary linkage to Planning Insights. Where this occurs, the address will link to both cadastre in the planning_insights_address table. This means that a single address_detail_pid can relate to more than one base_cadastre_pid in the planning_insights_address table, as shown below:
Once the data has been spatially enabled, a user can interact with and gain insights from the data. The examples below describe some of the applications of the data once spatially enabled.
A user can identify high-level planning zone and overlay information as well as permitted, permitted with controls and prohibited uses for a cadastre or address using the planning_insights table. For example, the cadastre with cadastre_polygon_pid of ‘cpeca2b96d1a1f7’ and base_cadastre_pid of ‘cad7d25f1165b2e’ has a primary linkage to Planning Insights and has the following information associated:
The planning_insights information associated with the Cadastre.¶
From this we can see that the parcel is in a RZ1 planning zone, and that various types of development that are permitted at the site (e.g. boarding house, child care) and prohibited at the site (e.g. agriculture, airport). Apartments and townhouses may be able to be built at the site, duplexes can be built at the site and mixed use developments cannot be built at the site. The cadastre also intersects a bushfire overlay. This information is also available at the address level if G-NAF has been used to spatially enable the data.
A user could also search for all parcels for which a flood overlay (blue parcels) or bushfire overlay (red parcels) has intersection. This is also applicable for Planning Insights when spatially enabled using G-NAF.
A user can identify detailed planning zone information for a cadastre or address using the planning_insights_zoning table. For example, the cadastre with cadastre_polygon_pid of ‘cp06cb181ce7426’ and base_cadastre_pid of ‘cad004d879047ea’ has a primary linkage to Planning Insights and relates to the planning zones of ‘NUZ4’ and ‘NUZ2’:
A user could query this data for a specific zone code to identify areas where specific development can take place. The example below shows a filter over the data where zone codes of ‘RZ2’ have been selected in the ACT. This is also applicable for addresses when G-NAF has been used to spatially enable the data.
A user can identify detailed overlay information for a cadastre or address using the planning_insights_overlays table. For example, the cadastre with cadastre_polygon_pid of ‘cp6b64f5b196f88’ and base_cadastre_pid of ‘cad0000276ef829’ has a primary linkage to Planning Insights and relates to four overlays.
A user could query this data for a specific overlay to identify areas of higher risk, such as areas that intersect flood or bushfire overlays. The example below shows a filter over the data where overlay_category of ‘flood’ (blue) and ‘bushfire’ (red parcels) have been selected in the ACT. This is also applicable for addresses when G-NAF has been used to spatially enable the data.
