Making sure that the results we deliver to our customers are the quality they expect start with how the data is acquired. Making sure that we have all of the data that we need in, delivered in the way we expect will make sure processing runs as smoothly as possible.
However, capturing these thousands of images might be challenging. Therefore, we created this article, considering the best practices to save you time and frustration during the data acquisition.
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.
Front-Overlap: 75% minimum.
If the terrain or the assets to be mapped are too complex, please increase the front overlap.
Side Overlap: 70% minimum.
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.
While we recommend flying sites in one continuous block there can be circumstances where it might be useful to use blocks either when flying or uploading.
For example, if there are large elevation differences that make it necessary to have multiple flights to keep your GSD consistent. Or if there are objects such as powerlines crossing the site that make it not safe to fly one altitude across the whole site. In these instances you will beed to fly separate flights so it would be a good idea to split the operations into blocks
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 Asset timeline 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.
Besides requirements for the flight plan, some features require some data to be set up in the platform before they are available. The table below highlights the main input requirements for different features.
High absolute accuracy (GCP, RTK, PPK)
Acquisition of parts of the site
DXF containing structures
Custom-level structure reporting
Regions + CSV with region targets
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.
As 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 often happens on a different level. Some customers report on table level, others on string level, etc. As 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 would like to have structures reported on a different level, a DXF file should be provided containing the required reporting level. For example, 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.
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 platform.
Check out this support article to learn more about regions.
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:
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.
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.