Proposed Import of Large Solar Panel-Row Dataset

[MSUHydroWiki]

Proposed Import of Large Solar Panel-Row Dataset

Hello everyone! I am part of Michigan State University’s Hydrogeology Lab and have been collaborating on a project called Ground-Mounted Solar Energy in the United States (GM-SEUS). As part of this project, we have manually digitized solar panel-rows to fill gaps and improve the coverage of solar array metadata across the United States.

Today I am creating this post to propose the import of the GM-SEUS dataset into the OSM database. The primary goal of this import is to enhance OpenStreetMap’s solar energy coverage by adding a large dataset of hand-digitized solar panel-rows, supporting both OpenStreetMap and GM-SEUS.

The dataset contains 24,182 hand-delineated solar panel-rows (5.29 km²) across 1,485 arrays previously lacking panel-row data. Of these, 23,870 panel-rows did not overlap with existing OpenStreetMap contributions, representing 1,450 arrays. As of August 29, 2025, this upload would result in a 2.1% increase in panel-row count and a 23.1% increase in the number of arrays with panel-row data in OpenStreetMap. These panel-rows are the intended contribution to OpenStreetMap.

Documentation

• The Wiki Page dedicated to this import can be found here
• The Zenodo Repository dedicated to this import can be found here
• The Github Repository dedicated to this import can be found here

Licensing

• The imagery used for the digitization process was NAIP
• NAIP is open source. The link to their licensing page can be found in our Wiki page.
• ODbL compliance has been verified.

General

• Please consult the Wiki page, Zenodo Repository, and Github Repository with any questions related to our digitization process or import plan.
• If there are any unresolved issues that you notice, please let us know!

[Fizzie-DWG (Graeme Fitzpatrick)]

Hi!

One of our mappers has recently been working on solar farms, so may be able to give you some input?

@catgirlseraid You out there?

[catgirlseraid (Phoebe)]

Hi,

Thanks for your interest in doing a solar panel import! The wiki page lays out your methodology very well. Should this import go ahead it’s worth considering default OSM account’s have a rate limit of 100,000 objects per hour, while the total dataset contains 145,000 objects. JOSM uploads nodes first, then ways, then relations (not applicable here) so you should either reach out to the DWG (data working group) for the importer role which increases your account limits to 1,000,000 objects per hour or upload in two seperate sessions at least an hour apart. If your OSM account is brand new the rate limit is a lot lower, so it’s perhaps worth waiting a week after creation for your rate limit to increase or reaching out to the DWG.

I have noticed a few quality issues with this import however, most notably with offsets, likely due to NAIP (the imagery used when digitising) not being aligned perfectly. I’ve also noticed conflation seems to have failed in a lot of places resulting in duplicate data. There’s some very small misplaced panels that should be removed from the dataset first. Several of the solar panels also don’t seem to be squared. All analysis of this import was done using “GMSEUSv1_1_digUnique.osm” from Digitized geospatial dataset of ground-mounted solar energy panel-rows in the United States dated 3rd of September 2025. Please find screenshots and links to the relevant area below.

If you have metadata on the solar panels id’s within your dataset it’s also worth considering if these should be added to make potential future imports easier. Adding the solar panels electrical output if known would also be a great help!

These quality issues should be addressed before the import starts, if you need any further help or i’ve misread the documentation and used the wrong dataset please reach out!

Thanks,
Phoebe

Screenshot showing failed conflation, OSM way 375100102

Same issue, this time also overlapping service roads, OSM way 1117067088

Screenshot showing offset compared to other imagery and existing OSM data, OSM way 511640038

Non square solar panels, area: OpenStreetMap

More non squared solar panels, area: OpenStreetMap

Another example showing all three problems, failed conflation, offset and non square panels, OSM way 1151207480

An example of one of the small solar panel artifacts. area: OpenStreetMap

[Minh_Nguyen (Minh Nguyễn)]

@catgirlseraid

Several of the solar panels also don’t seem to be squared.

I assume this is because these canopies are usually tilted, and typical orthoimagery won’t completely correct for that. Whenever I encounter this while mapping solar panels manually, I square the corners for logical consistency, even if the resulting area differs from the imagery slightly.

[catgirlseraid (Phoebe)]

Fun fact, these industrial panels rotate on one axis to follow the sun, so squaring them would be mapping them at their centermost or resting position. It all depends on what time of day the photos were taken. In general recording aerial imagery in the middle of the day when the solar panels are pointing directly upwards isn’t ideal because it blows out the camera and the heat often messes with other sensors too. This is why we usually see them at least slightly tilted in aerial imagery.
Attatched are few examples of what happens

[catgirlseraid (Phoebe)]

bascially they act as giant mirrors to some degree

[MSUHydroWiki]

Hi Phoebe (@catgirlseraid) and other community commenters and contributors,

Thank you for taking the time to review our proposal and for flagging specific quality concerns. After considering the feedback and revisiting our workflow, we’ve decided not to proceed with importing the GM-SEUS solar panel-row dataset into OSM at this time.

Our reasoning in brief:

• Imagery alignment: Our workflow depends on NAIP (biannual, CONUS-wide) for research continuity, but NAIP-to-OSM basemap differences (orthorectification) create systematic offsets.

• Geometry characteristics: We preserve what’s visible in NAIP for research reproducibility, which yields some non-orthogonal panel-row edges due to acquisition timing and look angle.

• Scale and constraints: Remaining conflation/validation tasks plus OSM upload limits would effectively require re-digitizing ~25,000 panel rows against OSM-aligned imagery—beyond our current scope.

We’re keeping the wiki/import write-up available for transparency. We’re also genuinely excited by your efforts to map solar arrays and common efforts (MapYourGrid initiative) and would welcome opportunities to collaborate on energy-infrastructure mapping that meets OSM’s standards whether that’s sharing domain knowledge, metadata, or QA/QC workflows even if these specific geometries aren’t imported.

If a collaboration path makes sense, please reach out: stidjaco@msu.edu or kendal30@msu.edu. Additionally, for more information on our energy landscape mapping efforts, see our recently published work in Scientific Data.

Thanks again for the thoughtful engagement and guidance.

MSU Hydrogeology