Technical Description

The solar theme (solar layer) consists of digital representations of the outlines of photovoltaic solar panels and arrays in urban areas. Urban areas are those with a population greater than 200, or with significant industrial/commercial activity.

Solar is populated from two different capture sources and the population of the product schema will vary between these as follows:

  • Aerial capture source – Where Solar has been captured from aerial imagery the full product schema for Solar will be populated.

  • Satellite capture source – Where Solar has been captured from satellite imagery only yes/no indicators will be populated in the solar_building and solar_address tables.

Solar polygons have been digitized from remotely sensed aerial imagery using a combination of automated and manual processes to identify, extract and orthogonalize objects resembling solar panels and arrays. The process also determines the type of solar panel/s captured. Image quality factors including currency, capture geometry and applicable weather conditions influence the specific image which can be utilised for further processing.

Non-photovoltaic solar such as hot water heating and swimming pool heating have been removed from the capture where possible.

The solar_address theme (solar_address layer) provides information relating to solar at an address. Only addresses that relate to urban buildings are included. The solar_building theme (solar_building layer) provides information relating to solar for a building. Only urban buildings are included.

Linkages

This product is integrated with the following Geoscape products:

  • G-NAF

  • Buildings

  • Planning

The joins used to link to these products are shown below, with attributes used in the joins described.

digraph G {

fontname="ROBOTO" fontsize="10pt"
node [fontname="ROBOTO" fontsize="8pt"]
edge [fontname="ROBOTO" fontsize="8pt"]
rankdir = LR; nodesep=2

subgraph cluster_solar { label="Solar"
graph[style="dashed,rounded"  color="#EA6B66"]

solar [shape=plain
label=<<TABLE BGCOLOR="#7EA6E0"
BORDER="1"
CELLBORDER="0"
style="rounded"
CELLSPACING="0"
CELLPADDING="5">

<TR>
<TD  COLSPAN="2">solar</TD>
</TR>

<TR>
<TD BGCOLOR="white" >PK</TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_pid: varchar (15) </TD>
</TR>

<TR>
<TD BGCOLOR="white" >FK</TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_building_pid: varchar (15) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >date_created: date </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >capture_source: varchar (30) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >capture_date: date </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_type: varchar (20) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >state: varchar (3) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_area: number (10,2) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >daily_estimated_power: number (10,2)      </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >geometry: Polygon </TD>
</TR>

</TABLE>>];

solar_solar_address [shape=plain
label=<<TABLE BGCOLOR="#FFD966"
BORDER="1"
CELLBORDER="0"
style="rounded"
CELLSPACING="0"
CELLPADDING="5">

<TR>
<TD  COLSPAN="2">solar_solar_address</TD>
</TR>

<TR>
<TD BGCOLOR="white" >PK</TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_pid: varchar (15) </TD>
</TR>

<TR>
<TD BGCOLOR="white" >PK</TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_address_pid: varchar (15)      </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >date_created: date </TD>
</TR>

</TABLE>>];

solar_address [shape=plain
label=<<TABLE BGCOLOR="#FFD966"
BORDER="1"
CELLBORDER="0"
style="rounded"
CELLSPACING="0"
CELLPADDING="5">

<TR>
<TD  COLSPAN="2">solar_address</TD>
</TR>

<TR>
<TD BGCOLOR="white" >PK</TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_address_pid: varchar (15) </TD>
</TR>

<TR>
<TD BGCOLOR="white" >FK</TD>
<TD BGCOLOR="white" ALIGN="LEFT" >address_pid: varchar (15) </TD>
</TR>

<TR>
<TD BGCOLOR="white" >FK</TD>
<TD BGCOLOR="white" ALIGN="LEFT" >address_detail_pid: varchar (15) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >date_created: date </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >date_modified: date </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >address: varchar (150) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >state: varchar (3) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >planning_zone: varchar (30) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >is_residential: varchar (3) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >captue_source: varchar (30) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_review_date: date </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_flag: varchar (3) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_area: number (10,2) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >daily_estimated_power: number (10,2)      </TD>
</TR>

</TABLE>>];

solar_building [shape=plain
label=<<TABLE BGCOLOR="#FFD966"
BORDER="1"
CELLBORDER="0"
style="rounded"
CELLSPACING="0"
CELLPADDING="5">

<TR>
<TD  COLSPAN="2">solar_building</TD>
</TR>

<TR>
<TD BGCOLOR="white" >PK</TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_building_pid: varchar (15) </TD>
</TR>

<TR>
<TD BGCOLOR="white" >FK</TD>
<TD BGCOLOR="white" ALIGN="LEFT" >building_pid: varchar (15) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >date_created: date </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >date_modified: date </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >state: varchar (3) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >planning_zone: varchar (50) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >primary_roof_material: varchar (20) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >roof_shape: varchar (7) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >roof_slope: number (4,2) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >building_area: number (10,2) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >capture_source: varchar (30) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_review_date: date </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_flag: varchar (3) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_area: number (10,2) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >daily_estimated_power: number (10,2)      </TD>
</TR>

</TABLE>>];

solar -> solar_solar_address [arrowhead=crownoneodot dir=both arrowtail=nonetee]

solar_solar_address -> solar_address [arrowhead=nonetee dir=both arrowtail=crownoneodot]

solar -> solar_building [arrowhead=teenoneodot dir=both arrowtail=crownonetee]

 rank=same {solar_address, solar_building}

}

subgraph cluster_gnaf { label="G-NAF"
graph[style="dashed,rounded"  color="#7EA6E0"]


ADDRESS [ style=filled shape=Mrecord  fillcolor="#FFD966" ]
solar_address -> ADDRESS [arrowhead=nonetee dir=both arrowtail=noneteenoneodot]

}

subgraph cluster_address{ label="Addressing Services"
graph[style="dashed,rounded"  color="#60A917"]

address_services [label="Address API" style=filled shape=Mrecord  fillcolor="#60A917" ]
solar_address -> address_services [arrowhead=nonetee dir=both arrowtail=noneteenoneodot]

}


subgraph cluster_buildings { label="Buildings"
graph[style="dashed,rounded"  color="#7EA6E0"]


BUILDINGS [ style=filled shape=Mrecord  fillcolor="#7EA6E0" ]
solar_building -> BUILDINGS [arrowhead=nonetee dir=both arrowtail=noneteenoneodot]

}




    subgraph cluster_legend {
     graph[style="" label="Legend" ]

    legend [shape=plain
    label=<<TABLE
        CELLBORDER="0"
        Border="0">
    <TR>
        <TD BGCOLOR="#7EA6E0" BORDER="1">     </TD>
        <TD>Spatial Attribute Table</TD>
    </TR>

    <TR>
        <TD BGCOLOR="#FFD966" BORDER="1">     </TD>
        <TD>Textual Attribute Table</TD>
    </TR>


    </TABLE>>]

    key [shape=plain  label=<<table border="0" cellpadding="1" cellspacing="0" cellborder="0">
      <tr><td port="i1"> Zero or Many </td> </tr>
      <tr><td port="i2"> Zero or One </td> </tr>
      <tr><td port="i3"> One or Many </td> </tr>
      <tr><td port="i4"> One </td> </tr>

      </table>>]

    key2 [shape=plain label=<<TABLE border="0" cellpadding="1" cellspacing="0" CELLBORDER="0">
      <tr><td port="i1"> </td></tr>
      <tr><td port="i2"> </td></tr>
      <tr><td port="i3"> </td></tr>
      <tr><td port="i4"> </td></tr>
      </TABLE>>]

      key:i1 -> key2:i1 [arrowhead=crownoneodot]
      key:i2 -> key2:i2 [arrowhead=noneteenoneodot]
      key:i3 -> key2:i3 [arrowhead=crownonetee]
      key:i4 -> key2:i4 [arrowhead=nonetee]

    }

}

Solar to solar building linkage

A solar polygon will be linked to a building based on maximum spatial overlap. One or many solar polygons can relate to a single building. In the below example, 6 solar polygons relate to a single building.

Solar to Building relationship

Image of solar and building relationship with © Aerometrex Ltd Aerial Imagery [Aerometrex, 2023].

solar table

solar_pid

sol446632e235b0

sol0d1eaf72d78b

solf88fcf8b143a

sol562414c51053

solb883391069f7

sol359928889039

solar_building table

solar_pid

solar_building_pid

sol446632e235b0

bldfcbc5a741525

sol0d1eaf72d78b

bldfcbc5a741525

solf88fcf8b143a

bldfcbc5a741525

sol562414c51053

bldfcbc5a741525

solb883391069f7

bldfcbc5a741525

sol359928889039

bldfcbc5a741525

Solar building to planning zone linkage

A solar building record will be assigned a planning_zone value from the related Buildings product record. In the Buildings product, a building will be assigned a generalised planning zone description through linkage with the Planning product, using the Cadastre relationship with the highest confidence. Where two or more cadastral relationships exist for a building with the same confidence, the generalised planning description is assigned using the following priority order (with “Residential” as the highest priority):

Residential > Commercial/Business > Industrial/Utilities > Community Use > Mixed Use > Special Use > Transport/Infrastructure > Rural/Primary Production > Conservation/National Park > Recreational/Open Space > Water

Solar to solar address linkage

In Solar, the solar_solar_address table describes the many to many relationships between the solar table and solar_address table. This table has been derived from solar to building and building to address relationships and as such complex relationships can be created, examples are shown below.

Example 1: Two or many addresses relate to one solar record

A single solar polygon relates to two or more addresses through a single building (brown). An example of this would be an apartment block containing multiple addresses with a single solar array. Where this occurs the solar_pid in the solar table will relate to different solar_address_pids in the solar_solar_address table.

Solar to Address relationship

Two or many addresses relate to one solar record with © Aerometrex Ltd Aerial Imagery [Aerometrex, 2023].

solar table

solar_pid

sol6f38e36c22ce

solar_solar_address table

solar_pid

solar_address_pid

sol6f38e36c22ce

sap1fb52c027ff7

sol6f38e36c22ce

sapab851293bc2b

solar_address table

solar_address_pid

address_pid

sap1fb52c027ff7

add585600ac45c2

sapab851293bc2b

add447d30f6f3fc

Example 2: One address relates to many solar records

Multiple solar polygons relate to a single address through a single building. An example of this would be a single residential dwelling with multiple solar arrays on the roof. Where this occurs the solar_solar_address table would have multiple solar_pids relating to the same solar_address_pid.

Solar to Address relationship

Two or many addresses relate to one solar record with © Aerometrex Ltd Aerial Imagery [Aerometrex, 2023].

solar table

solar_pid

sol0c16daff15f6

sold2943c27356f

sol4b3d869fe44d

sol4abf7a86210a

sol5867bd2ff4a5

solc7b968f21c30

solar_solar_address table

solar_pid

solar_address_pid

sol0c16daff15f6

sapc2e25311196f

sold2943c27356f

sapc2e25311196f

sol4b3d869fe44d

sapc2e25311196f

sol4abf7a86210a

sapc2e25311196f

sol5867bd2ff4a5

sapc2e25311196f

solc7b968f21c30

sapc2e25311196f

solar_address table

solar_address_pid

address_pid

sapc2e25311196f

add0b930fcc7208

Example 3: Many addresses relate to many solar records

Multiple solar polygons relate to multiple addresses through multiple buildings. An example of this would be where there are multiple addresses that relate to multiple buildings (and their solar panels) through a cadastre/property (purple outline) relationship. Where this occurs the solar_solar_address table would have multiple solar_pids relating to multiple solar_address_pids.

Solar to Address relationship

Two or many addresses relate to one solar record with © Aerometrex Ltd Aerial Imagery [Aerometrex, 2023].

solar table

solar_pid

sol58e6055b3a27

solffe07e2e540e

sol69fed4aa883e

sol8d56b9d29394

solar_solar_address table

solar_pid

solar_address_pid

sol58e6055b3a27

sapaaeb83de865f

solffe07e2e540e

sapaaeb83de865f

sol69fed4aa883e

sapaaeb83de865f

sol8d56b9d29394

sapaaeb83de865f

sol58e6055b3a27

sap553ae621ebe8

solffe07e2e540e

sap553ae621ebe8

sol69fed4aa883e

sap553ae621ebe8

sol8d56b9d29394

sap553ae621ebe8

solar_address table

solar_address_pid

address_pid

sapaaeb83de865f

addfee87a43f2d7

sap553ae621ebe8

add7db1daa67e4e

Example 4: Many addresses relate to many solar records (complex example)

An address is linked to a solar array through the building relationship, and another address links to that same solar array as well as another array through cadastre/property (green) to building relationship. Where this occurs the solar_solar_address table would have one solar_address_pid relating to only one of the solar_pids, and the other solar_address_pid relating to both solar_pids.

Many addresses relate to many solar records (complex example)

solar table

solar_pid

sol1aaaaaaaaaaa

sol2aaaaaaaaaaa

solar_solar_address table

solar_pid

solar_address_pid

sol1aaaaaaaaaaa

sapbbbbbbbbbbbb

sol2aaaaaaaaaaa

sapbbbbbbbbbbbb

sol2aaaaaaaaaaa

sapcccccccccccc

solar_address table

solar_address_pid

address_pid

sapbbbbbbbbbbbb

addbbbbbbbbbbbb

sapcccccccccccc

addcccccccccccc

Solar address to planning zone linkage

The planning_zone attribute is assigned for an address through its building relationship. Where an address relates to multiple buildings, the most common planning_zone value from the buildings is assigned to the solar address record.

Attributes Solar Table

Capture Source

Provides the resolution in centimetres of the source imagery used to capture the solar feature (e.g. 5cm aerial, 7.5cm aerial, 50cm satellite).

Solar Type

Classification of the type of photovoltaic solar panel. The three classified types for solar are ‘Monocrystalline’, ‘Polycrystalline’ and ‘Thin-film’. This classification is used in the calculation of the “daily_estimated_power” attribute as each solar panel type has different levels of efficiency and therefore power output.

Solar Area

The area of the solar polygon in square metres, calculated using an equal area Albers projection.

Daily Estimated Power

The daily estimated power output of the solar polygon in kilowatt hours per day (kWh/day). This attribute is calculated using the area, solar type and its estimated efficiency, and weather data.

Attributes Solar Address Table

Is Residential

A flag used to indicate if the address has been identified as currently or having previously thought to be residential. The source of the residential indicator is currently derived from Commonwealth Government sources.

Capture Source

Informs about the source imagery, whether it is a satellite or aerial capture and the resolution of the imagery in centimetres, used for the building related to the address.

Solar Review Date

The solar_panel_review_date provides the date at which the presence of solar panels was last reviewed for the building related to the address.

Solar Flag

Provides an indicator of the presence (‘Yes’ value) or absence (‘No’ value) of a photovoltaic solar panel on the roof surface of a building that relates to the address. Where an address relates to multiple buildings and at least one relates to a solar panel, a ‘Yes’ solar_flag is assigned to the address. Where an address relates to multiple buildings and we do not have complete information on whether there are solar panels related to these buildings, a null solar_flag is assigned to the address.

Solar Area

The total area of all solar polygons related to the address in square metres.

Daily Estimated Power

The total estimated daily power output of all solar polygons related to the address in kilowatt hours per day (kWh/day).

Attributes: Solar Building table

Primary Roof Material

The roof material is the classification of the primary roof material found across the building surface. The primary_roof_material attribute is classified from image pixels that intersect the building. The image signature of the intersecting pixels is matched to a spectral library of known material compositions to determine the best matching material for each pixel.

Roof Shape

Provides the most common roof shape for the building roof (e.g. ‘Flat’, ‘Gabled’, ‘Hipped’ etc.).

Roof Slope

Maximum angle of slope in degrees of the building roof structure, rounded to standardised class values.

Building Area

Building area in square meters assigned from Geoscape Buildings.

Capture Source

Informs about the source imagery, whether it is a satellite or aerial capture and the resolution of the imagery in centimetres, used to capture each building record.

Solar Review Date

The solar review date provides the date at which the presence of solar panels was last reviewed for the building.

Solar Flag

Provides an indicator of the presence (‘Yes’ value) or absence (‘No’ value) of a photovoltaic solar panel on the roof surface of the building. Where the presence of solar for a building cannot be determined, a null value is assigned.

Solar Area

The total area of all solar polygons related to the building in square metres.

Daily Estimated Power

The total estimated daily power output of all solar polygons related to the building in kilowatt hours per day (kWh/day).

Data Model

digraph G {

fontname="ROBOTO" fontsize="10pt"
node [fontname="ROBOTO" fontsize="8pt"]
edge [fontname="ROBOTO" fontsize="8pt"]
rankdir = LR; nodesep=2

subgraph cluster_solar { label="Solar"
graph[style="dashed,rounded"  color="#EA6B66"]

solar [shape=plain
label=<<TABLE BGCOLOR="#7EA6E0"
BORDER="1"
CELLBORDER="0"
style="rounded"
CELLSPACING="0"
CELLPADDING="5">

<TR>
<TD  COLSPAN="2">solar</TD>
</TR>

<TR>
<TD BGCOLOR="white" >PK</TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_pid: varchar (15) </TD>
</TR>

<TR>
<TD BGCOLOR="white" >FK</TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_building_pid: varchar (15) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >date_created: date </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >capture_source: varchar (30) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >capture_date: date </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_type: varchar (20) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >state: varchar (3) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_area: number (10,2) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >daily_estimated_power: number (10,2)      </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >geometry: Polygon </TD>
</TR>

</TABLE>>];

solar_solar_address [shape=plain
label=<<TABLE BGCOLOR="#FFD966"
BORDER="1"
CELLBORDER="0"
style="rounded"
CELLSPACING="0"
CELLPADDING="5">

<TR>
<TD  COLSPAN="2">solar_solar_address</TD>
</TR>

<TR>
<TD BGCOLOR="white" >PK</TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_pid: varchar (15) </TD>
</TR>

<TR>
<TD BGCOLOR="white" >PK</TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_address_pid: varchar (15)      </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >date_created: date </TD>
</TR>

</TABLE>>];

solar_address [shape=plain
label=<<TABLE BGCOLOR="#FFD966"
BORDER="1"
CELLBORDER="0"
style="rounded"
CELLSPACING="0"
CELLPADDING="5">

<TR>
<TD  COLSPAN="2">solar_address</TD>
</TR>

<TR>
<TD BGCOLOR="white" >PK</TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_address_pid: varchar (15) </TD>
</TR>

<TR>
<TD BGCOLOR="white" >FK</TD>
<TD BGCOLOR="white" ALIGN="LEFT" >address_pid: varchar (15) </TD>
</TR>

<TR>
<TD BGCOLOR="white" >FK</TD>
<TD BGCOLOR="white" ALIGN="LEFT" >address_detail_pid: varchar (15) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >date_created: date </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >date_modified: date </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >address: varchar (150) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >state: varchar (3) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >planning_zone: varchar (30) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >is_residential: varchar (3) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >captue_source: varchar (30) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_review_date: date </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_flag: varchar (3) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_area: number (10,2) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >daily_estimated_power: number (10,2)      </TD>
</TR>

</TABLE>>];

solar_building [shape=plain
label=<<TABLE BGCOLOR="#FFD966"
BORDER="1"
CELLBORDER="0"
style="rounded"
CELLSPACING="0"
CELLPADDING="5">

<TR>
<TD  COLSPAN="2">solar_building</TD>
</TR>

<TR>
<TD BGCOLOR="white" >PK</TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_building_pid: varchar (15) </TD>
</TR>

<TR>
<TD BGCOLOR="white" >FK</TD>
<TD BGCOLOR="white" ALIGN="LEFT" >building_pid: varchar (15) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >date_created: date </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >date_modified: date </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >state: varchar (3) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >planning_zone: varchar (50) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >primary_roof_material: varchar (20) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >roof_shape: varchar (7) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >roof_slope: number (4,2) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >building_area: number (10,2) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >capture_source: varchar (30) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_review_date: date </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_flag: varchar (3) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >solar_area: number (10,2) </TD>
</TR>

<TR>
<TD BGCOLOR="white" ></TD>
<TD BGCOLOR="white" ALIGN="LEFT" >daily_estimated_power: number (10,2)      </TD>
</TR>

</TABLE>>];

solar -> solar_solar_address [arrowhead=crownoneodot dir=both arrowtail=nonetee]

solar_solar_address -> solar_address [arrowhead=nonetee dir=both arrowtail=crownoneodot]

solar -> solar_building [arrowhead=teenoneodot dir=both arrowtail=crownonetee]

 rank=same {solar_address, solar_building}

}

ADDRESS [ style=filled shape=Mrecord  fillcolor="#FFD966" ]
solar_address -> ADDRESS [arrowhead=nonetee dir=both arrowtail=noneteenoneodot]

BUILDINGS [ style=filled shape=Mrecord  fillcolor="#7EA6E0" ]
solar_building -> BUILDINGS [arrowhead=nonetee dir=both arrowtail=noneteenoneodot]

rank=same {ADDRESS, BUILDINGS}


    subgraph cluster_legend {
     graph[style="" label="Legend" ]

    legend [shape=plain
    label=<<TABLE
        CELLBORDER="0"
        Border="0">
    <TR>
        <TD BGCOLOR="#7EA6E0" BORDER="1">     </TD>
        <TD>Spatial Attribute Table</TD>
    </TR>

    <TR>
        <TD BGCOLOR="#FFD966" BORDER="1">     </TD>
        <TD>Textual Attribute Table</TD>
    </TR>


    </TABLE>>]

    key [shape=plain  label=<<table border="0" cellpadding="1" cellspacing="0" cellborder="0">
      <tr><td port="i1"> Zero or Many </td> </tr>
      <tr><td port="i2"> Zero or One </td> </tr>
      <tr><td port="i3"> One or Many </td> </tr>
      <tr><td port="i4"> One </td> </tr>

      </table>>]

    key2 [shape=plain label=<<TABLE border="0" cellpadding="1" cellspacing="0" CELLBORDER="0">
      <tr><td port="i1"> </td></tr>
      <tr><td port="i2"> </td></tr>
      <tr><td port="i3"> </td></tr>
      <tr><td port="i4"> </td></tr>
      </TABLE>>]

      key:i1 -> key2:i1 [arrowhead=crownoneodot]
      key:i2 -> key2:i2 [arrowhead=noneteenoneodot]
      key:i3 -> key2:i3 [arrowhead=crownonetee]
      key:i4 -> key2:i4 [arrowhead=nonetee]

    }


}

Data Dictionary

solar

Attribute

Data Type

Description

Primary Key

Mandatory

10 Character Alias

solar_pid

character string (15)

Unique persistent identifier for the solar polygon representing a contiguous array of solar panels.

Yes

Yes

SOLAR_PID

solar_building_pid

character string (15)

Unique persistent identifier for the solar building related to the solar record.

No

Yes

SLR_BL_PID

date_created

date

The date the record is first introduced to the Geoscape product.

No

Yes

DT_CREATE

capture_source

character string (30)

Imagery source from which the solar information was extracted.

No

Yes

CAPT_SRC

capture_date

date

Date of imagery capture for the imagery the feature was extracted from.

No

Yes

CAPT_DATE

solar_type

character string (20)

Classification of the type of solar panel.

No

Yes

SOLAR_TYPE

state

character string (3)

The abbreviated name of the State or Territory that the boundary spatially resides within.

No

No

STATE

solar_area

number (10,2)

Area of the solar polygon in square meters.

No

Yes

SOLAR_AREA

daily_estimated_power

number (10,2)

Estimation of the power generated on an average day in kilowatt hours.

No

Yes

D_EST_PWR

geometry

polygon

Polygon representing the solar array.

No

Yes

GEOMETRY

solar_solar_address

Attribute

Data Type

Description

Primary Key

Mandatory

10 Character Alias

solar_pid

character string (15)

Unique persistent identifier of the solar record related to the solar address record.

Yes

Yes

SOLAR_PID

solar_address_pid

character string (15)

Unique persistent identifier of the solar address related to the solar record.

Yes

Yes

SLR_AD_PID

date_created

date

The date the record is first introduced to the Geoscape product.

No

Yes

DT_CREATE

solar_address

Attribute

Data Type

Description

Primary Key

Mandatory

10 Character Alias

solar_address_pid

character string (15)

Unique persistent identifier for the solar address record.

Yes

Yes

SLR_AD_PID

address_pid

character string (15)

Unique persistent identifier for the address.

No

Yes

ADD_PID

address_detail_pid

character string (15)

Foreign key relationship to G-NAF.

No

No

ADD_DT_PID

date_created

date

The date the record is first introduced to the Geoscape product.

No

Yes

DT_CREATE

date_modified

date

The date of most recent change to any attribute of the feature.

No

No

DT_MOD

address

character string (150)

The address string from the address.

No

Yes

ADDRESS

state

character string (3)

The abbreviated name of the State or Territory that the boundary spatially resides within.

No

No

STATE

planning_zone

character string (30)

The planning zone that is related to the address.

No

No

PLAN_ZONE

is_residential

character string (3)

Value of “Yes” allocated where address information has identified the land use as residential.

No

No

IS_RESI

capture_source

character string (30)

The lowest resolution of capture used to identify a building that is related to the address.

No

Yes

CAPT_SRC

solar_review_date

date

The oldest solar review date for a building that is related to the address.

No

No

SLR_RV_DT

solar_flag

character string (3)

Yes or No flag indicating whether photovoltaic solar has been detected for this address.

No

No

SOLAR_FLAG

solar_area

number (10,2)

Total area of solar arrays related to the address in square meters.

No

No

SOLAR_AREA

daily_estimated_power

number (10,2)

Estimation of the power generated on an average day by all solar arrays for the address in kilowatt hours.

No

No

D_EST_PWR

solar_building

Attribute

Data Type

Description

Primary Key

Mandatory

10 Character Alias

solar_building_pid

character string (15)

Unique persistent identifier for the solar building.

Yes

Yes

SLR_BL_PID

building_pid

character string (15)

Unique persistent identifier for the building.

No

Yes

BLD_PID

date_created

date

The date the record is first introduced to the Geoscape product.

No

Yes

DT_CREATE

date_modified

date

The date of most recent change to any attribute of the feature.

No

No

DT_MOD

state

character string (3)

The abbreviated name of the State or Territory that the boundary spatially resides within.

No

No

STATE

planning_zone

character string (30)

The planning zone that is related to the building.

No

No

PLAN_ZONE

primary_roof_material

character string (20)

Primary roof material detected at the building.

No

No

PR_RF_MAT

roof_shape

character string (7)

Classification of the shape of the roof (Gabled, Hipped, Mixed, Flat, Shed, Mansard, Other).

No

No

ROOF_SHAPE

roof_slope

number (4,2)

Maximum angle of slope in degrees of the building roof structure, rounded to standardised class values.

No

No

ROOF_SLOPE

building_area

number (10,2)

Area of the building in square metres measured on the Building polygon geometry.

No

Yes

BLD_AREA

capture_source

character string (30)

Imagery source from which the building and/or solar was extracted.

No

Yes

CAPT_SRC

solar_review_date

date

The source imagery date used to review the solar information.

No

No

SLR_RV_DT

solar_flag

character string (3)

Yes or No indicating whether photovoltaic solar has been detected for this building.

No

No

SOLAR_FLAG

solar_area

number (10,2)

Total area of solar arrays related to the building in square meters.

No

No

SOLAR_AREA

daily_estimated_power

number (10,2)

Estimation of the power generated on an average day by all solar arrays for the building in kilowatt hours.

No

No

D_EST_PWR

Domain Values

solar

solar_type

Domain Value

Description

Monocrystalline

The solar panel type has been identified as Monocrystalline. Monocrystalline panels are made from a single pure silicon crystal that is cut into several wafers to be used for the cells of the panel.

Polycrystalline

The solar panel type has been identified as Polycrystalline. Polycrystalline panel cells are made from multiple silicon crystals.

Thin-film

The solar panel type has been identified as Thin-film (also known as amorphous). Thin-film panels are made by depositing thin layers of photovoltaic material (composing of silicon, cadmium, copper and other elements) on a substrate to create a solar cell.

state

Domain Value

Description

ACT

The data is located within the Australian Capital Territory.

NSW

The data is located within the state of New South Wales.

NT

The data is located within the Northern Territory.

OT

The data is located within the Other Territories classification. Other Territories covers the external Australian territories of Cocos (Keeling) Islands, Christmas Island, Jervis Bay and Norfolk Island.

QLD

The data is located within the state of Queensland.

SA

The data is located within the state of South Australia.

TAS

The data is located within the state of Tasmania.

VIC

The data is located within the state of Victoria.

WA

The data is located within the state of Western Australia.

solar_address

state

Domain Value

Description

ACT

The data is located within the Australian Capital Territory.

NSW

The data is located within the state of New South Wales.

NT

The data is located within the Northern Territory.

OT

The data is located within the Other Territories classification. Other Territories covers the external Australian territories of Cocos (Keeling) Islands, Christmas Island, Jervis Bay and Norfolk Island.

QLD

The data is located within the state of Queensland.

SA

The data is located within the state of South Australia.

TAS

The data is located within the state of Tasmania.

VIC

The data is located within the state of Victoria.

WA

The data is located within the state of Western Australia.

planning_zone

Domain Value

Description

Residential

Areas where the state, territory or local government planning scheme generally indicate residential.

Commercial/Business

Areas where the state, territory or local government planning scheme generally indicate a commercial or business focus.

Industrial/Utilities

Areas where the state, territory or local government planning scheme generally indicate industrial activities and/or utility facilities.

Community Use

Areas where the state, territory or local government planning scheme generally indicate community use.

Mixed Use

Areas where the state, territory or local government planning scheme generally indicate mixed use.

Special Use

Areas where the state, territory or local government planning scheme generally indicate special use.

Transport/Infrastructure

Areas where the state, territory or local government planning scheme generally indicate transport and/or other infrastructure.

Rural/Primary Production

Areas where the state, territory or local government planning scheme generally indicate rural and/or primary production activities.

Conservation/National Park

Areas where the state, territory or local government planning scheme generally indicate National Park or a conservation requirement.

Recreational/Open Space

Areas where the state, territory or local government planning scheme generally indicate recreational activities and or open space.

Water

Areas where the state, territory or local government planning scheme generally indicate waterways or other water areas.

<NULL>

Areas where the planning zone is not known.

is_residential

Domain Value

Description

Yes

Yes, the address information in G-NAF has identified the land use as residential.

<NULL>

The address information in G-NAF has identified the land use as non-residential, or there is not sufficient information to identify the land use as residential. Addresses that have not yet been linked to an ADDRESS_DETAIL_PID in G-NAF will be assigned a null value.

solar_flag

Domain Value

Description

Yes

There is a solar polygon associated with the address.

No

There is no solar polygon associated with the address.

<NULL>

The address has not been assessed for whether a solar polygon is associated.

solar_building

state

Domain Value

Description

ACT

The data is located within the Australian Capital Territory.

NSW

The data is located within the state of New South Wales.

NT

The data is located within the Northern Territory.

OT

The data is located within the Other Territories classification. Other Territories covers the external Australian territories of Cocos (Keeling) Islands, Christmas Island, Jervis Bay and Norfolk Island.

QLD

The data is located within the state of Queensland.

SA

The data is located within the state of South Australia.

TAS

The data is located within the state of Tasmania.

VIC

The data is located within the state of Victoria.

WA

The data is located within the state of Western Australia.

planning_zone

Domain Value

Description

Residential

Areas where the state, territory or local government planning scheme generally indicate residential.

Commercial/Business

Areas where the state, territory or local government planning scheme generally indicate a commercial or business focus.

Industrial/Utilities

Areas where the state, territory or local government planning scheme generally indicate industrial activities and/or utility facilities.

Community Use

Areas where the state, territory or local government planning scheme generally indicate community use.

Mixed Use

Areas where the state, territory or local government planning scheme generally indicate mixed use.

Special Use

Areas where the state, territory or local government planning scheme generally indicate special use.

Transport/Infrastructure

Areas where the state, territory or local government planning scheme generally indicate transport and/or other infrastructure.

Rural/Primary Production

Areas where the state, territory or local government planning scheme generally indicate rural and/or primary production activities.

Conservation/National Park

Areas where the state, territory or local government planning scheme generally indicate National Park or a conservation requirement.

Recreational/Open Space

Areas where the state, territory or local government planning scheme generally indicate recreational activities and or open space.

Water

Areas where the state, territory or local government planning scheme generally indicate waterways or other water areas.

<NULL>

Areas where the planning zone is not known.

primary_roof_material

Domain Value

Description

Flat Concrete

The roof is primarily made from concrete.

Fiberglass/Plastic

The roof is primarily made from fiberglass or plastic.

Metal

The roof is primarily made from metal.

Tile

The roof is primarily made from tile.

<NULL>

The primary roof material is not assigned.

roof_shape

Domain Value

Description

Flat

The primary roofing system is constructed as a single horizontal plane.

Gabled

The primary roofing system is constructed as two rectangular angled planes supporting each other along the central ridgeline.

Hipped

The primary roofing system is constructed as multiple angled planes meeting at a central ridgeline oriented along the longest centreline of the building. The larger roof planes are typically trapezoidal in shape while the roof planes of the shorter ends are usually triangular in shape.

Mansard

The primary roof system is constructed as multiple planes with part of the planes on an angle and a flat section at the top of the roof.

Mixed

The roof shape is both hipped and gabled

Other

The roof type is not one of the above types.

Shed

The primary roofing system is constructed as a single plane on a slope.

<NULL>

The building has not been assessed for roof shape.

solar_flag

Domain Value

Description

Yes

There is a solar polygon associated with the address.

No

There is no solar polygon associated with the address.

<NULL>

The address has not been assessed for whether a solar polygon is associated.

Data Maintenance

  • Urban (satellite source) – Urban areas captured through the original rollout and maintenance updates for buildings from satellite imagery.

  • Urban (aerial source) – Urban areas being refreshed with increased quality through capture from aerial imagery.

The age and resolution of source imagery used for capturing solar information varies across each of the categories to enable full urban coverage. ‘Urban’ areas have been captured with the most recent available source imagery.

Update Frequency

This product is continuously updated and released with the most up to date data available on a quarterly schedule in the months of March, June, September, December.

Update Scope

Solar updates occur for all existing objects with changed geometry, attributes and/or metadata, as well as data for new objects supplied prior to the release.

Updates to the product include:

  1. Feature level solar change management:
    1. Addition of newly captured solar.

    2. Retiring of non-identified solar.

    3. Validation of solar geometry and attribution.

  2. All Solar relationships to other Geoscape products (G-NAF, Buildings, Planning, Address APIs) to account for any changes in either product.

  3. Corrections and/or improvements to production processes in generating Solar.

Update Rules

The update process describes rules that are applied to records to determine persistency. A record can be updated, retired or created.

The following table outlines the required attributes needed to be changed to cause a record to be retired.

Attributes used for Persistency.

Table Name

Attributes Used for Persistency

solar

solar_pid

solar_solar_address

solar_pid, solar_address_pid

solar_address

solar_address_pid

solar_building

solar_building_pid

Solar Change Management

  • Where a new solar record is created, new related solar_solar_address linkage records are also created. Solar and Building features are captured concurrently therefore where a new Solar record is created a new solar_building record with new solar_building_pid will often be created. This new solar_building record will relate to the new solar polygon through the solar_building_pid foreign key relationship. If a building has only undergone a minimal change to the geometry from previous captures, the building_pid will persist and the old solar_building_pid will also persist. This means that a new solar record with new solar_pid can relate to a pre-existing solar_building * Where an existing solar record is retired, all existing related solar_solar_address linkage records are also retired. The related solar_building will also be retired if the related building_pid is retired from the Buildings product. This may not always occur, as the building product has persistency in the building_pid and may keep the same building_pid if there has been minimal change to the building geometry between the old and new capture. A solar_building record will not be retired in this instance.

  • Where an address is retired, the related solar_address record and solar_solar_address linkages will also be retired.

  • Where a new address is created, a new solar_address record with new solar_address_pid will be created. New solar_solar_address relationships will also be created where the address relates to a solar polygon.

  • Where a building is retired in the Buildings product, the related solar_building record will also be retired.

  • Where a new building is created in the Buildings product, a new solar_building record will be created with a new solar_building_pid.

Data Quality

The quality of Solar is yet to be fully benchmarked as product coverage is not yet of a scale to allow for a full set of sampling. As the product coverage increases Geoscape will undertake quantitative sampling which will allow us to test and validate the quality of the data and update the information in this section. Geoscape currently manages quality through supply specifications with our partners and we are targeting the following accuracies:

  • >95% of solar panels captured from source imagery

  • <5% of over capture. (Objects that aren’t solar but look similar in imagery)

  • >95% of the solar panel vertices within 2 pixels of the same point in the imagery

Positional Accuracy

Positional accuracy is an assessment of the closeness of the location of the spatial objects in relation to their true positions on the earth’s surface. Positional accuracy consists of 2 assessments:

  • Horizontal accuracy

  • Vertical accuracy

The horizontal and vertical positional accuracy is the assessed accuracy after all transformations have been carried out.

Horizontal Accuracy

The horizontal accuracy of Solar data reflects the positional accuracy of source sensors utilised in the data collection, and the reliability of feature classification and associated orthogonalisation processes.

The horizontal accuracy of aerial imagery used for the extraction of solar features is:

  • +/- 3 pixels RMSE, where the pixel size is referenced in the capture_source attribution.

The horizontal accuracy of satellite imagery used to assign a solar_flag to satellite derived buildings or addresses related to satellite derived buildings is:

  • +/-2.5m Circular Error 90% (CE90).

Influences on horizontal accuracy

The positional accuracy of solar is yet to be benchmarked as the sample size isn’t large enough to provide a definitive result. As the number of aerial derived solar polygons increase we’ll assess the accuracies and provide further information. The accuracy of the aerial imagery used in the solar product is measured at ground level. Across the imagery there are occurrences of building lean which can influence a solar panel/array’s position. In these locations, elevation models are utilised to adjust the solar feature to the base of the building.

The positional accuracy of the vertices of unobstructed solar features will reflect the accuracy of the source imagery from which it is extracted. Obstructed vertices will have their position estimated with solar shapes orthogonalised using trained algorithms with some operator assistance. Users should note that anomalies from the solar extraction algorithm may cause erroneous captures and reduce the positional accuracy of the vertices of solar features.

Geometry Validity

The geometry is validated to ensure polygons are a valid representation and free of self-intersection. Issues being detected and resolved include spikes, bow ties, duplicate vertices, null geometries, multipart geometries and self-contacts. Polygon orientation conforms to the following specifications:

  • OGC Simple Feature Access Specification v1.2.1 [Section - 6.1.11.1]

  • The GeoJSON Specification RFC7946 [Section 3.1.6 dot point 4]

This means the polygon outer boundary will be counter clockwise and the inner boundary will be clockwise for file formats that support the above standards.

Further Comments

This product has been processed to assure all polygons are stored as single part features to improve compatibility with a range of software applications.

Extent/Geographic Description

The spatial coverage of this dataset includes Australia’s land mass and surrounding offshore islands.

The Bounding Box for this data is as follows:

  • North bounding latitude: -9˚

  • South bounding latitude: -44˚

  • East bounding longitude: 160˚

  • West bounding longitude: 100˚

Solar Data Extent Map.

A detailed description of the coverage for each State and Territory is provided in the table below.

State

Specific Area

Coverage

ACT

Partial coverage of urban areas based on capture schedule.

NSW

Partial coverage of urban areas based on capture schedule.

NT

Partial coverage of urban areas based on capture schedule.

OT

Christmas and Cocos (Keeling) Islands

No coverage

Jervis Bay

Partial coverage of urban areas based on capture schedule.

Norfolk Island

No coverage

QLD

Partial coverage of urban areas based on capture schedule.

SA

Partial coverage of urban areas based on capture schedule.

TAS

Partial coverage of urban areas based on capture schedule.

VIC

Partial coverage of urban areas based on capture schedule.

WA

Partial coverage of urban areas based on capture schedule.

Spatial Reference System

GDA94

Horizontal Datum: The Geocentric Datum of Australia 1994 (GDA94) is the target horizontal datum.

Coordinate System: Geographic Coordinate System Geocentric Datum of Australia 1994 (GDA94).

GDA2020

Horizontal Datum: The Geocentric Datum of Australia 2020 (GDA2020) is the target horizontal datum.

Coordinate System: Geographic Coordinate System Geocentric Datum of Australia 2020 (GDA2020).

Coordinates Referencing the GDA2020 Datum

Spatial features referencing the GDA2020 datum are produced using a coordinate transformation from the GDA94 datum using the following parameters.

  • shift_x = 0.06155,

  • shift_y = -0.01087,

  • shift_z = -0.04019,

  • rotate_x = -0.0394924,

  • rotate_y = -0.0327221,

  • rotate_z = -0.0328979,

  • scale_adjust = -0.009994

Delivery Format

Buildings is provided at a National and State/Territory level, depending on the file format selected. The data is made available in the File Geodatabase, GeoJSON, ESRI Shapefile and MapInfo TAB formats described below.

Format

National

State/Territory

File Geodatabase

Yes

Yes

GeoJSON

Yes

Yes

ESRI Shapefile

No

Yes

MapInfo TAB

No

Yes

File Geodatabase

Format name
File Geodatabase – ESRI™

Specification
This format includes files with the following extensions: *.gdb

Language
English

GeoJSON

Format name
GeoJSON

Specification
This format includes files with the following extensions: *.geojson

Language
English

Note

The GeoJSON specification states that the coordinate reference system for all GeoJSON coordinates is:

“a geographic coordinate reference system, using the World Geodetic System 1984 (WGS 84) datum, with longitude and latitude units of decimal degrees”

Solar will be provided with coordinates using the datum selected for download (GDA94/GDA2020) with longitude and latitude units of decimal degrees.

JSON

Format name
JSON

Specification
This format includes files with the following extensions: *.json

Language
English

ESRI Shapefile

Format name
Shape – ESRI™

Specification
This format includes files with the following extensions: *.shp, *.shx, *.dbf
ESRI Shapefile Technical Description, an ESRI White Paper, July 1998. Follow this link: www.esri.com/library/whitepapers/pdfs/shapefile.pdf

Language
English

MapInfo TAB

Format name
TAB – MapInfo Professional™

Specification

This format includes files with the following extensions: *.tab, *.dat, *.id, *.map
The MapInfo TAB format is a popular geospatial vector data format for geographic information systems software. It is developed and regulated by MapInfo as a proprietary format. TAB files support geospatial standards such as Open GIS, the OGC, ISO, W3C and others.

Language
English

Product Versioning

Versioning is managed through incrementing when there is a change to the product schema or a significant change in data population, these are described further below:

  • A schema change can affect a major or minor increment to the versioning. Additive changes (changes that won’t break customers’ ability to work with the data) will be incremented with a minor version increment, an example is the addition of a new attribute. Removal of attributes or changing the structure of the schema will enact a major change to identify that this requires the attention of all customers and partners.

  • Where a significant geography of Australia either has a new population of data for an attribute or is populated from a much higher quality source a minor increment will be applied to the product version.

Therefore, versioning will not increment with every data update. Published releases will have a name e.g. ‘May 2021’ and will reference a version of the product e.g. ‘1.0’.