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


.. graphviz::

    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.

.. figure:: technical_description/solar_to_solar_building_image.png
    :alt: Solar to Building relationship
    :align: center

    Image of solar and building relationship with © Aerometrex Ltd Aerial Imagery :cite:p:`Aerometrex2023`.

solar table

.. csv-table::
    :header-rows: 1
    :file: technical_description/solar_to_solar_building_image_table1.csv

solar_building table

.. csv-table::
    :header-rows: 1
    :file: technical_description/solar_to_solar_building_image_table2.csv


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.

.. figure:: technical_description/solar_to_solar_address_image_eg1.png
    :alt: Solar to Address relationship
    :align: center

    Two or many addresses relate to one solar record with © Aerometrex Ltd Aerial Imagery :cite:p:`Aerometrex2023`.

solar table

.. csv-table::
    :header-rows: 1
    :file: technical_description/solar_to_solar_address_eg1_table1.csv

solar_solar_address table

.. csv-table::
    :header-rows: 1
    :file: technical_description/solar_to_solar_address_eg1_table2.csv

solar_address table

.. csv-table::
    :header-rows: 1
    :file: technical_description/solar_to_solar_address_eg1_table3.csv


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

.. figure:: technical_description/solar_to_solar_address_image_eg2.png
    :alt: Solar to Address relationship
    :align: center

    Two or many addresses relate to one solar record with © Aerometrex Ltd Aerial Imagery :cite:p:`Aerometrex2023`.

solar table

.. csv-table::
    :header-rows: 1
    :file: technical_description/solar_to_solar_address_eg2_table1.csv

solar_solar_address table

.. csv-table::
    :header-rows: 1
    :file: technical_description/solar_to_solar_address_eg2_table2.csv

solar_address table

.. csv-table::
    :header-rows: 1
    :file: technical_description/solar_to_solar_address_eg2_table3.csv


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

.. figure:: technical_description/solar_to_solar_address_image_eg3.png
    :alt: Solar to Address relationship
    :align: center

    Two or many addresses relate to one solar record with © Aerometrex Ltd Aerial Imagery :cite:p:`Aerometrex2023`.

solar table

.. csv-table::
    :header-rows: 1
    :file: technical_description/solar_to_solar_address_eg3_table1.csv

solar_solar_address table

.. csv-table::
    :header-rows: 1
    :file: technical_description/solar_to_solar_address_eg3_table2.csv

solar_address table

.. csv-table::
    :header-rows: 1
    :file: technical_description/solar_to_solar_address_eg3_table3.csv


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

.. image:: technical_description/solar_to_solar_address_image_eg4.png
    :alt: Many addresses relate to many solar records (complex example)

solar table

.. csv-table::
    :header-rows: 1
    :file: technical_description/solar_to_solar_address_eg4_table1.csv

solar_solar_address table

.. csv-table::
    :header-rows: 1
    :file: technical_description/solar_to_solar_address_eg4_table2.csv

solar_address table

.. csv-table::
    :header-rows: 1
    :file: technical_description/solar_to_solar_address_eg4_table3.csv


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

.. graphviz::

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

.. csv-table:: solar
    :header-rows: 1
    :widths: 150,100,300,100,100,100
    :file: technical_description/table_solar.csv


.. csv-table:: solar_solar_address
    :header-rows: 1
    :widths: 150,100,300,100,100,100
    :file: technical_description/table_solar_solar_address.csv


.. csv-table:: solar_address
    :header-rows: 1
    :widths: 150,100,300,100,100,100
    :file: technical_description/table_solar_address.csv


.. csv-table:: solar_building
    :header-rows: 1
    :widths: 150,100,300,100,100,100
    :file: technical_description/table_solar_building.csv


-------------
Domain Values
-------------

solar
-----

.. csv-table:: solar_type
    :widths: 33 66
    :header-rows: 1
    :file: technical_description/domain_solar_type.csv

.. csv-table:: state
    :header-rows: 1
    :widths: 33 66
    :file: technical_description/domain_state.csv


solar_address
-------------

.. csv-table:: state
    :header-rows: 1
    :widths: 33 66
    :file: technical_description/domain_state.csv


.. csv-table:: planning_zone
    :header-rows: 1
    :widths: 33 66
    :file: technical_description/domain_planning_zone.csv


.. csv-table:: is_residential
    :header-rows: 1
    :widths: 33 66
    :file: technical_description/domain_is_residential.csv


.. csv-table:: solar_flag
    :header-rows: 1
    :widths: 33 66
    :file: technical_description/domain_solar_flag.csv


solar_building
--------------

.. csv-table:: state
    :header-rows: 1
    :widths: 33 66
    :file: technical_description/domain_state.csv


.. csv-table:: planning_zone
    :header-rows: 1
    :widths: 33 66
    :file: technical_description/domain_planning_zone.csv


.. csv-table:: primary_roof_material
    :header-rows: 1
    :widths: 33 66
    :file: technical_description/domain_primary_roof_material.csv


.. csv-table:: roof_shape
    :header-rows: 1
    :widths: 33 66
    :file: technical_description/domain_roof_shape.csv


.. csv-table:: solar_flag
    :header-rows: 1
    :widths: 33 66
    :file: technical_description/domain_solar_flag.csv


----------------
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:

#. Feature level solar change management:
    a. Addition of newly captured solar.
    b. Retiring of non-identified solar.
    c. 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.


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.

..  table:: Attributes used for Persistency.
    :align: center

    ===================== ===================================
     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˚

.. image:: technical_description/extent_map.png
    :alt: Solar Data Extent Map.



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

.. csv-table::
    :header-rows: 1
    :file: technical_description/solar_extent.csv


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

.. csv-table::
    :header-rows: 1
    :file: technical_description/solar_formats.csv


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