Back to Blog
solar design15 min read

Solar Roof Obstruction Register: A Better Way to Record Design Constraints

How solar installers and EPCs can document roof obstructions as traceable design constraints instead of leaving critical site evidence scattered across photos, notes, and memory.

Nimesh Katariya

Written by

Nimesh Katariya

Solar-industry contributor

Rainer Neumann

Edited by

Rainer Neumann

Editorial contributor · SurgePV

Published ·Updated

Answer

A solar roof obstruction register records each feature that can affect layout, access, drainage, structural review, safety, or installation: its location, source evidence, status, owner, and impact on the next decision. It separates a field observation from an approved design response.

A roof obstruction is not simply an object a designer draws around. It is a site condition that can change the layout, installation method, access, drainage, electrical route, safety plan, or need for qualified review. A register gives that condition a clear project identity. Instead of leaving a vent, skylight, parapet, damaged area, roof hatch, conduit, service path, or uncertain feature inside a photo folder, the team can see what was observed, what evidence supports it, and what decision remains.

This is desk research for solar professionals. It does not replace a roof inspection, structural assessment, engineering, manufacturer instructions, waterproofing expertise, site safety plan, local code, fire requirements, or authority decision. The necessary setback, access, and installation requirements depend on the jurisdiction, roof system, equipment, and project. Treat this as an evidence-control method rather than a universal layout rule.

Why Photos Alone Do Not Control Roof Information

Photos are valuable, especially when they preserve context, date, orientation, and a reference point. They become less useful when no one knows which roof plane they show, whether they were taken before or after a repair, or what the observer intended the next person to notice. A shared drive can hold dozens of images while the design team still lacks a reliable answer about a critical feature.

Section 6.4 of the 2018 NREL PV and storage O&M guide describes retaining equipment, as-built, inspection, and change records. Those documentation principles do not establish whether a feature is measured correctly, structurally relevant, or acceptable under local requirements. Project evidence needs a source and a boundary. A register turns a photo, drawing, imagery observation, survey measurement, or customer note into a question that someone can act on.

The most useful entries are decision-led. “Skylight near east array” is a starting point. “Skylight observed on east plane from survey photo 17; exact clearance to be verified before construction layout; design owner to assess” has an owner, evidence, and release effect.

Define What Counts as a Register Item

Do not create a register for every harmless roof detail. Include features or conditions that could change the work or require a deliberate confirmation. Examples may include roof penetrations, skylights, hatches, vents, drains, mechanical equipment, parapets, structural joints, areas of visible damage, access routes, nearby overhead conditions, existing PV equipment, cable routes, and zones with uncertain geometry.

Register field What to capture Why it matters
Identifier and location Roof plane, grid reference, drawing or photo reference Lets design and field teams discuss the same item
Description What was observed without assuming its technical effect Separates fact from judgment
Geometry and units Position, footprint, height datum, and source for each Distinguishes measured values from defaults
Model and output revision Scene object ID and affected layout or shade result Supports evidence-to-scene reconciliation
Source and date Survey, current drawing, image, customer note, or observation Shows evidence strength and currency
Status Confirmed, planning assumption, or verification required Makes uncertainty visible
Affected decision Layout, access, routing, waterproofing, review, sequencing Prevents a generic “note” from being ignored
Owner and next action Who will measure, review, ask, or route it Establishes accountability

Avoid terms such as “clear” or “no issue” unless the record states who made that determination and on what basis. A field photograph may show a clear visual route without confirming roof condition, attachment feasibility, required access, drainage impact, or a local requirement.

Use Evidence Statuses That Match the Project Stage

At early design, satellite imagery or customer photographs may be enough to outline a preliminary layout. At construction release, the same evidence may be inadequate. The register should say which stage the evidence supports rather than forcing a false yes-or-no conclusion.

Use three practical statuses: supported for this decision, planning assumption, and required before later release. A dormer outline from imagery might be supported for screening but require field verification before a construction layout. A roof hatch shown in a current survey may still need an access review. The status describes the evidence boundary, not the importance of the feature.

PVsyst’s shading documentation distinguishes distant horizon effects from near-object shading requiring a detailed 3D scene. A plan-view footprint does not provide every height or spatial relationship needed for the latter. Record the height datum and measurement basis; do not assign all vents or parapets the same supposedly typical height.

LiDAR, imagery, and a site observation may support different fields. A sensor label does not guarantee an accurate, complete roof model. Preserve conflicting evidence and mark the fields requiring resolution before the relevant decision.

Connect the Register to the Layout, Not Just the Survey

Every material entry should point to the design output it affects. A roof-plane reference, layout markup, drawing callout, or photo annotation may be appropriate. The goal is traceability: a later reviewer should be able to see whether the register item was considered, deferred, or found to require a design change.

When evaluating Solar Designing, ask how register items would be mapped to the actual scene and output revision. Software can represent a feature in a model; it cannot confirm a roof condition, make a structural judgment, or determine compliance without the necessary project evidence and responsible review.

Turn Site Evidence Into a More Traceable Solar Design Record

Bring an obstruction entry and its source files to a SurgePV demo. Ask how the workflow would preserve its identity, unresolved dimensions, and affected outputs.

Book a Demo

Discuss the survey-to-design handoff in a live walkthrough.

Reconcile the Register With the Modeled Scene

Map each register identifier to the modeled object and retain the scene revision. Check whether every material item is represented, deliberately excluded with a reason, or remains open. In the reverse direction, a scene object without a source should not appear measured simply because it is rendered in 3D.

Aurora’s obstruction guide describes editing obstruction geometry and states that removing an obstruction requires rerunning irradiance calculation in that product. This vendor-specific example does not establish a SurgePV capability. In the actual tool, identify which layout, shade, production, or customer outputs become stale after a geometry change, then recompute or review them as appropriate.

Do Not Treat a Sketch as a Construction Decision

A survey sketch is often a fast, useful communication tool. It is not automatically a final dimensioned design or instruction for an installer. If a feature changes array placement, attachment planning, electrical route, access, or another controlled part of the work, the appropriate design or review owner must incorporate or resolve it through the project process.

This distinction is especially important where a feature appears different in imagery, drawings, and field observation. The register can preserve all three sources, flag the conflict, and assign a resolution. Choosing the most convenient source without documenting why creates a quiet assumption that may surface only during installation.

Route Items by Effect, Not by Object Type

Two skylights may require different next actions. One may simply affect preliminary layout. Another may sit beside a required access path or reveal a roof condition that needs specialist review. The register should route the effect, not attach a fixed action to the noun.

Item effect A sensible next route
Changes preliminary panel area Update the layout scenario and label it appropriately
Needs exact field dimensions Assign survey measurement before the designated release
Affects roof condition or waterproofing question Route to the competent roof or technical owner
Affects access or immediate site safety Follow applicable site safety control and stop/escalate as needed
Conflicts with an existing drawing Open a design question and preserve both evidence sources

US OSHA’s solar electrical guidance identifies shock and arc-flash hazards. It is not a project-specific electrical or roof-access procedure, and its US scope does not establish rules elsewhere. If an observed condition presents a safety concern, follow the applicable plan and responsible safety process. A register should make the concern visible; it does not authorize work near a hazard.

Review the Register at the Moments That Matter

Review entries at intake, after survey, before proposal release, before technical or construction issue, and when a field observation changes the available evidence. Not every item needs a meeting. A short review can clear routine entries and focus attention on the few conditions that could stop work or change the customer promise.

At each review, ask: Has new evidence changed the status? Has the layout or plan responded to the item? Is there a decision owner? Does the item affect what can be said to the customer or scheduled on site? If the answer is unknown, the entry is doing its job by revealing it.

Keep the Customer Conversation Specific

Do not say a layout “will fit” when the record shows that access, roof condition, dimensions, or another material feature is still open. Explain the stage: “This preliminary option uses available site information; we will confirm the listed roof features before a later release.” Specific qualification gives the customer a practical next step and protects the team from presenting an early model as settled construction scope.

Preserve the Evidence When the Item Is Closed

Closing an entry should not mean deleting its history. Record the resolution, the person or role that made it, the evidence reviewed, the affected design revision, and any limitation that still applies. A later service, warranty, or modification conversation may need to understand why a feature was handled in a particular way. The historical record should be easy to retrieve without being mistaken for the current construction instruction.

If the resolution relies on a later survey, photo, or specialist response, link that source rather than rewriting it as an unsupported summary. Record which scene and dependent outputs were updated and reviewed before closure; acknowledging an entry is not technical approval. This keeps the register useful as an index of decisions instead of a second, conflicting version of the project file.

Choose evidence through the site-assessment method guide. If a discovery changes the released basis, use field-change communication to distribute the current direction.

Improve Survey Requests From Actual Gaps

After a project reaches installation, review which register entries appeared too late. Repeated uncertainty around hatch locations may justify a better survey-photo request. Recurring conflicts between drawings and site conditions may signal an evidence-date issue. Do not label those observations as universal industry results. Use them to improve the next briefing question, survey annotation, or handoff rule.

Practical Next Steps

  1. Create an entry for every roof condition that could change layout, access, technical review, or installation planning.
  2. Link each entry to its evidence and the design output it affects.
  3. Mark what is confirmed, assumed, or required before the next release, then assign an owner.

Make Solar Site Inputs Easier to Follow Through Design

Bring a register-to-scene handoff example to a SurgePV demo and evaluate the workflow against your evidence and revision requirements.

Book a Free Demo

Frequently Asked Questions

What is a solar roof obstruction register?

It is a controlled list of roof features and conditions that can affect a PV project. Each entry identifies the location, evidence, status, affected decision, owner, and next action, so a site observation does not disappear into photos or personal memory.

Can satellite imagery confirm all roof obstructions for solar design?

No. Imagery can be useful for early modeling, but it may not show current dimensions, roof condition, access, concealed features, service routes, or local constraints. State what imagery supports and what still needs survey or qualified review.

Does every roof feature need an engineering review?

No. Route the item according to its actual effect and the applicable project requirements. Some features affect only preliminary layout; others may require a measurement, design change, safety control, roof specialist input, or another qualified review.

Sources

Primary research and reference material used for this desk-research article.

Where this fits

This article is part of SurgePV's Solar Design hub, which works through the topic from first principles to the decisions a project team actually has to make.

About the Contributors

Author
Nimesh Katariya
Nimesh Katariya

Solar-industry contributor

Nimesh Katariya contributes to SurgePV content concerning solar project workflows. This profile intentionally does not assert certifications, project totals, seminar counts, or technical-review authority without retained verification evidence.

Editor
Rainer Neumann
Rainer Neumann

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.

Get Solar Design Tips in Your Inbox

Join 2,000+ solar professionals. One email per week - no spam.

No spam · Unsubscribe anytime

Book Free Demo

Choose which optional technologies SurgePV may use. Essential storage remains active for security and requested features.