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.

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.

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.

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.

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.

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.

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

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˚

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

ESRI File Geodatabase Technical Description. Follow this link: http://desktop.arcgis.com/en/desktop/latest/manage-data/administer-file-gdbs/file-geodatabases.htm

Language

English

GeoJSON

Format name

GeoJSON

Specification

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

GeoJSON specification: https://tools.ietf.org/html/rfc7946

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

JSON specification: https://www.json.org/json-en.html

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

Geopackage

Format name

Geopackage

Specification

This format includes files with the following extensions: *.gpkg

OGC Geopackage Standards. Follow this link: https://www.geopackage.org/

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’.