Structure Inspection Data Pipeline
Automating flight-track processing and structure inspection data updates in enterprise GIS.
Why it matters
Connecting flight tracks, inspection records, and work orders gives reviewers a shared geographic view of maintenance activity. The pipeline keeps that view current while treating flight proximity as candidate inspection coverage.
My contribution
I built and maintained the pipeline as an independent consultant. It collects inspection records and helicopter tracks, links them to work orders, and publishes the updated data to ArcGIS Portal.
Result
The automated pipeline completed 30+ scheduled monthly runs and removed two hours of manual work per run. GIS database refreshes took 80% less processing time per run.
Tools
- Python
- Selenium
- ArcPy
- pandas
- SQL
- ArcGIS Portal
Client records, infrastructure locations, credentials, and source code are not shared. Proximity to a flight path indicates possible inspection coverage; it does not independently verify that an asset was inspected.
From flight tracks to candidate coverage
The flight-track component combines flight metadata with ordered GPS points, builds flight lines, and identifies assets within 350 feet as candidate coverage. Proximity alone does not confirm that an asset was inspected. A Python launcher coordinates six scripts from collection through enterprise GIS updates.
GPS records retain the order of the flight.
Proximity alone does not confirm an inspection.
How updates are handled
- Combine sources: join flight metadata to GPS points by track identifier and standardize the fields with pandas.
- Select newer records: compare timestamps with the latest stored records, both before local processing and before enterprise append.
- Stage before delivery: prepare points, lines, and asset matches in a local file geodatabase, with explicit field mappings for GIS updates.
- Record progress: write per-stage logs, row counts, and subprocess status to help trace a run.
Outputs and scope
These outputs support the wider project’s work-order joins, inspection priorities, and ArcGIS Portal reporting. The related ground patrol case explains the priority rules and reporting work.
The runnable example below uses invented records. Its validation and rollback behavior belong to that teaching example, not to the historical flight-track scripts.
| Output | Purpose |
|---|---|
| Ordered flight lines | Review each flight path with its identifiers, dates, and movement attributes. |
| Candidate asset coverage | Associate assets within 350 feet of a flight line with its flight attributes. Proximity alone does not confirm an inspection. |
Example
Try a small data pipeline
See how sample records are checked, loaded, and updated, including what happens when a load fails.
Uses invented data; separate from this project.
View exampleTechnical details
Independent consulting · September 2022 to August 2025
Inspection data came from several sources and needed regular updates in the GIS database.
- Collect flight metadata with Selenium, retrieve GPS track exports, and join them with pandas.
- Select newer records, create points, and build lines grouped by flight and ordered by point sequence.
- Standardize flight attributes and stage points and lines in a local file geodatabase.
- Find assets within 350 feet of flight lines and attach the flight attributes using explicit field mappings.
- Select newer local records for enterprise-geodatabase append. The wider project also joined work orders, calculated inspection priorities, and delivered updated information through ArcGIS Portal.