Quick answer
A design feature for defining candidate panel-placement areas and exclusions on a roof or site. Its geometry and configured clearances need verification; a boundary does not establish structural suitability, electrical compatibility or permit approval.
Answer: An array boundary tool defines where a candidate solar layout may place modules on a roof or ground surface. Designers use placement polygons and exclusion zones to represent edges, obstructions, access routes and other constraints. The boundary controls geometric placement; it does not establish structural capacity, electrical suitability or authority approval. Verify the underlying measurements and the project-specific rules before relying on the layout.
Placement boundaries and exclusions
A placement boundary describes an allowed region. An exclusion removes a region from that candidate area. Polygon boundaries can follow irregular geometry; rectangles are useful for simple areas. Automatically suggested boundaries remain subject to review.
On a complex roof, a broad placement region with separate exclusions can make individual constraints easier to inspect than one highly detailed perimeter. Keep the exclusion reason visible: an access path, obstruction clearance, structural restriction and customer preference are different inputs, even when each prevents placement.
For ground-mounted projects, property boundaries, easements, drainage and access requirements need their own evidence. An imagery outline is not a verified legal parcel survey. Roof segmentation and module placement optimization address related but separate tasks.
A practical boundary workflow
- Establish the surface: record the geometry source, capture date, dimensions, slope and orientation. Keep different roof planes distinct in the model.
- Identify constraints: locate obstructions and record the source of each exclusion or clearance.
- Configure rules: use the requirements applicable to the actual project, equipment and jurisdiction. Do not treat software defaults as approved rules.
- Draw and inspect: check vertices, closed shapes, gaps, overlapping exclusions and the intended roof or site surface.
- Generate a candidate: review complete module or rack footprints, spacing, orientation and access, rather than only centre points.
- Reconcile the design: confirm the final count, electrical configuration, shading model and drawings refer to the same boundary revision.
OpenSolar’s documentation provides a vendor-specific example of configurable roof-edge setback templates and criteria for applying them. Configurability demonstrates a workflow, not automatic knowledge of every local requirement or support for the same feature in SurgePV. OpenSolar setback templates.
Calculate usable area without double-counting
Use the placement surface minus the union of excluded regions. Simply subtracting every exclusion’s area separately gives the wrong result when exclusions overlap. Use the same coordinate system and area basis throughout; sloped roof-surface area and horizontal projected area are different quantities.
Hypothetical example: a placement surface is 100 m². Two exclusions occupy 12 m² and 10 m², with 4 m² of overlap. Their combined excluded area is 12 + 10 − 4 = 18 m², so the remaining area is 82 m², not 78 m².
Even if each module has a 2 m² footprint, 82 ÷ 2 = 41 is only an area-based upper bound under those assumed values. Geometry, spacing and other constraints can prevent 41 modules from fitting. A valid placement must be demonstrated in the layout; usable area alone does not determine system capacity or energy production.
Constraints are not universal distances
| Constraint | Evidence needed |
|---|---|
| Fire access or pathways | Applicable local requirements and approved project interpretation |
| Roof equipment and servicing | Actual equipment location and relevant service clearances |
| Structural exclusions | The responsible structural assessment and mounting design |
| Property or easement restrictions | Project survey and applicable legal or planning records |
| Customer preferences | Agreed scope, clearly separated from mandatory constraints |
Avoid a generic “3 feet everywhere” rule or an assumed percentage reduction in usable area. A configured boundary can omit a requirement, apply the wrong edge type or reflect stale measurements.
Handoffs to installation and sales
The survey team should report missing or relocated obstructions, dimension differences and uncertain roof conditions. Refer structural questions to the responsible qualified team. Reconcile changed boundaries through the project’s revision process before installation.
Sales layouts should label preliminary geometry and explain why a region is excluded. If offering maximum-coverage and preferred-coverage options, compare verified configurations rather than promising that every remaining square metre is buildable. Automated boundaries and auto-design do not remove review responsibilities.
To evaluate the boundary and review workflow available for your project, book a SurgePV demo with a representative site and your required deliverables.
Frequently asked questions
Is an array boundary the same as a roof outline?
Not necessarily. A roof outline describes geometry; the candidate placement area may exclude access, obstructions and other restricted regions.
Does a boundary make the layout permit-ready?
No. Geometry, applicable requirements and the wider design package still need the project’s required review.
Can software generate boundaries automatically?
Some products support suggested geometry or configured clearances. Verify the exact feature, inputs and correction workflow instead of assuming universal accuracy.
Does usable area determine the module count?
No. Complete module footprints, spacing and the shape of the remaining area determine whether a candidate count fits.
Related Glossary Terms
About the Contributors
CEO & Co-Founder · SurgePV
Keyur Rakholiya is identified by SurgePV as its CEO and a company co-founder. His SurgePV author page lists only role information that can be tied to the public profile below; credentials, project totals, testing claims, media appearances, and speaking engagements are not asserted without retained evidence.
Editorial contributor · SurgePV
Rainer Neumann is credited as an editorial contributor on SurgePV content. This profile does not assert engineering credentials, project totals, software-testing experience, education, speaking engagements, or media citations because independent verification evidence is not retained in the publication record.
