All Collections
Data Acquisition & Upload
Flight Parameters and Other Requirements
Data Input Requirements for Solar Construction Monitoring
Data Input Requirements for Solar Construction Monitoring
Updated over a week ago

Our goal is to process your data as quickly and efficiently as possible to ensure customer delight. We invest a significant amount of effort to process the data successfully the first time. However, capturing these thousands of images might be challenging. Therefore, we created this article, taking into account the best practices that will save you a lot of time and frustration during the data acquisition. First we will share the min requirements for the flight plan.

Flight Plan

For the Solar Construction data product we require only visual (RGB) photos. A drone pilot will use an unmanned aerial system (a drone with a camera) to capture the data on site.

Visual (RGB) Image Requirements

  • GSD: 2.0 ± 0.5cm per pixel at ground level.

  • Accuracy: High absolute accuracy is required in order to Fuse the data. This can be obtained using RTK/PPK and/or GCPs.

  • Front-Overlap: min 75%.
    If the terrain or the assets to be mapped are too complex, please increase the front overlap.

  • Side Overlap: min 70%.
    If the terrain or the assets to be mapped are too complex, please increase the side overlap.

  • Flight Line Direction: Flight direction can be any orientation up until the modules are installed, once modules start being installed on site then the flight direction should be along the long edge of the solar rows.

  • Flight Path: At least 2 flight lines should be outside the boundaries of the operation in all directions.

  • Gimbal Orientation: Nadir (-90 deg). Capture additional oblique photos for improved quality in case of complex terrains/buildings.

  • Image Format: JPEG
    Each image should contain the following metadata: GPS location, relative altitude and timestamp.

  • Image Quality: in focus, free from motion blur and with minimal glare.

  • At least 20 photos need to be uploaded.

Ground Control Points

Ground Control Points (GCPs) are optional, but highly recommended. Even when using photos that have been geotagged using a Real Time Kinematic (RTK) or a Post Processing Kinematic (PPK) solution, we highly recommend placing at least one GCP for optimal position accuracy of the end result.

If you would like to take advantage of our digital thread feature for object fusing you will need a very high absolute accuracy for each inspection that can only be achieved with the use of GCPs or a combination of PPK/RTK and GCPs. For more information on how to achieve this level of accuracy we have a support article to help here.

For more information on how to use Ground Control Points, please refer to the following article: How to Use Ground Control.


Blocks cannot be used for this data product, since one homogeneous output has to be produced.

Feature Requirements

Besides requirements for the flight plan, some features require some data to be set up in the platform. The table below highlights the main input requirements for different features. More details can be found further down.

Input requirement


High absolute accuracy (GCP, RTK, PPK)

Acquisition of parts of the site
Site-based statistics (object fusing)
Digital thread


Region-based statistics

DXF containing structures

Custom-level structure reporting

Regions + CSV with region targets

Target-based statistics

Completion percentages

Site-based statistics / Digital thread / Object fusing

When scanning a larger solar site, we typically don't cover the entire site in each flight. In order to make the statistics work on site level, we use a technology called Object Fusing which combines detections of the same element in different operations automatically. Since it uses the location of the detected elements to fuse them, the acquisition must happen with high absolute accuracy. See the section about ground control points above for more information.

Without high absolute accuracy scans, no site-level statistics will be possible.

Structure reporting

Structure reporting often happens on a different level. Some customers report on table level, others on string level, etc. Since these levels aren't always easy to detect in the visual scans of the structures themselves, our system detects structures as one continuous item by default. If you want to have structures reported on a different level, a DXF file should be provided containing the required reporting level.

Consider the example below.

The red boundaries define what the system would detect by default.

The green boundaries define a custom reporting level, which can only be achieved if a DXF is provided that defines these structures.

Different levels for reporting structures

Region-based statistics

The solar construction product detects piles, structures and panels and reports on how many elements of each type were detected. If you want to split the statistics across regions, regions have to be defined in the Fuse platform.

Region-based statistics

Check out this support article to learn more about regions.

Target-based statistics

It's often easier to work with completion percentages, rather than the raw number of elements detected.

To enable target-based statistics, two things are needed:

  1. Regions have to be defined in the system, as targets are linked to regions. If you only wish to use site-level targets, a single region should be drawn.

  2. A CSV or Excel file has to be provided with the target numbers for each element (piles, structures and panels) for each region defined in the platform. The names of the regions must match the names in the platform.

Target completion reporting per region
Progress table using region targets

Did this answer your question?