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.
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.
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
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 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 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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
Feature level solar change management:
Addition of newly captured solar.
Retiring of non-identified solar.
Validation of solar geometry and attribution.
All Solar relationships to other Geoscape products (G-NAF, Buildings, Planning, Address APIs) to account for any changes in either product.
Corrections and/or improvements to production processes in generating Solar.
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.
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 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.
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:
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.
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:
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.
This product has been processed to assure all polygons are stored as single part features to improve compatibility with a range of software applications.
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.
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.
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’.