Spatial analysis
Spatial analysis is the engine that derives new data from existing data: spatial operations (buffer / intersect / proximity / etc.), aggregate statistics, and AI-driven defect detection, change detection, and natural-language querying. Every analysis output is itself a feature layer, so results are visible on the map immediately and are valid input to the next operation. Everything is chainable.
Core data model
geoprocessing_jobs:
| Column | Purpose |
|---|---|
operation | BUFFER / INTERSECT / UNION / DIFFERENCE / CLIP / PROXIMITY / SPATIAL_JOIN / HEATMAP / ISOCHRONE / STATS. |
input_layer_ids[] | Array of input feature classes. |
parameters JSONB | Operation-specific (buffer distance, proximity radius, heatmap bandwidth, isochrone time window, …). |
output_feature_class_id | The new layer produced. |
status | QUEUED / RUNNING / COMPLETED / FAILED. |
progress | 0–100. |
ai_jobs (in development):
| Column | Purpose |
|---|---|
| Job kind | Semantic segmentation / defect detection / change detection / vegetation encroachment / mesh quality / scan-to-BIM / IoT anomaly / predictive maintenance / simulation surrogate / report narrative / NL querying / data valuation. |
model_version, confidence_threshold, status | Reproducibility, tuning, lifecycle. |
analysis_results (in development): VOLUME / CHANGE_DETECTION / DEFECT_SCAN with JSONB output.
Async operations run via Kafka on a dedicated geoprocessing worker. Buffer, intersect, union, difference, clip, proximity (nearest N features), spatial join (count-in-polygon, sum-in-polygon), heatmap density generation, attribute statistics within a region, isochrone (drive / walk-time catchment, via pgRouting). All results produced as new feature layers, chainable analysis.
Why it matters
Spatial analysis is Stratumly's wedge against traditional desktop GIS: not the whole of geoprocessing, but enough of the 15–20% of operations operators run weekly (buffer, intersect, proximity, spatial join) to stop them opening a separate desktop tool at all. Public sharing is the contract-renewal hook: when an operator shares a flood-risk map with their council partner, the next budget cycle is yours.
Sample workflow:
The asset team is preparing a regulator submission. They open the bridges layer, filter to "concrete, built pre-1960, not inspected in 18 months": 42 bridges. They run a spatial analysis: buffer each by 500 m, intersect with a flood-risk layer, heat-map the result. A new
flood_risk_bridgeslayer is produced. For the three highest-risk bridges, they dispatch drone surveys, let AI flag spalling and deformation. One of the three has a twin, so they run a structural-load simulation and attach the output to the regulator PDF. Three days of work collapsed to an afternoon.
Daily users
- GIS analyst / Asset manager: runs weekly spatial analyses against asset registers.
- Field engineer / Inspector: sees AI-flagged defects in the survey viewer, accepts or rejects them.
- Structural / mechanical engineer: runs simulations on twins.
Geoprocessing (shipped)
| Operation | Output |
|---|---|
| Buffer | Buffer features by distance (m / ft) → new POLYGON layer. |
| Intersect | Features from A overlapping with B → new layer. |
| Union | Merge overlapping features → new layer. |
| Difference | A minus B → new layer. |
| Clip | Clip features to a bounding geometry → new clipped layer. |
| Proximity (Nearest N) | Nearest N features from B to each feature in A, with distance → new layer. |
| Spatial join | Count-in-polygon / sum-in-polygon → new polygon layer with counts/sums as properties. |
| Heatmap | Density layer (POLYGON or RASTER). |
| Isochrone | Drive / walk-time catchment via pgRouting → POLYGON. |
| Attribute stats | Sum / mean / min / max / count over a region → aggregate value. |
- All outputs are new feature layers, chainable; no dead-end exports.
- Async via Kafka: operations queued as
geoprocessing.jobs.queuedevents. - A Python
geoprocessing-workerconsumes the queue, runs PostGIS operations, and writes results as new feature classes. - WebSocket
/ws/geoprocessing/{jobId}streams live progress (0–100, log messages).
Spatial analysis UI
Pick operation → select input layers → configure params → run → watch live progress → result becomes a new layer visible on the map immediately.
AI / ML workflows
The workflows below are on our roadmap. The list maps the model-driven analyses Stratumly will run end-to-end on customer surveys; today, the manual annotation workflow ships and AI-assisted detection is integrated incrementally.
| Workflow | Why it matters | Approach |
|---|---|---|
| Point-cloud semantic segmentation | Before defects can be detected, the AI needs to know what it's looking at: concrete crack ≠ dirt crack. | PointNet++ or RandLA-Net. |
| Defect detection | Manual review of millions of points per survey doesn't scale. AI flags, humans confirm. Per-industry variants: concrete cracks, rail deformation, pipe corrosion, road surface, embankment slippage. | 3D CNN on point-cloud patches + 2D CNN on orthoimage. |
| Change detection | Humans can't reliably spot 5 cm of subsidence between two surveys. | DTM surface differencing + learned threshold classification. Output: heatmap, area, max deformation, risk score. |
| Vegetation encroachment | Trees on powerlines, roots on pipes: leading cause of failures. | Segmentation + buffer-zone analysis. |
| Mesh quality assessment | Catch poor photogrammetry meshes before engineers waste time on them. | CNN on rendered mesh patches. |
| Scan-to-BIM | Manual BIM from scan takes weeks; AI does first pass in minutes. | 3D object detection + primitive fitting. |
| IoT anomaly detection | A drifting pressure sensor is an early warning. | LSTM / Transformer on time series. |
| Predictive maintenance scoring | Replace reactive maintenance with predictive. | Gradient-boosted trees on tabular features. |
| Simulation surrogate models | FEA simulations take hours; surrogates give an instant ballpark. | Neural net trained on simulation I/O. |
| Compliance report narrative | Engineers shouldn't write boilerplate. | LLM with industry context. |
| Natural-language querying | "Show me all critical defects in the last 6 months on the northern pipeline." | LLM with retrieval over the project database. |
| Marketplace data valuation | Contractors don't know what data is worth. | Regression on listing metadata + historical sales. |
Twin simulations
Twin simulations are on our roadmap.
- Flood simulation: water source + volume → propagate through terrain twin.
- Structural load simulation: apply forces → FEA → highlight stress points.
- Asset failure propagation: mark element failed → propagate impact through connected network.
- Proposed-change risk: edit twin → simulate modified version → compare risk scores.
How it links to the others
- Analysis → Map. Every geoprocessing output is a new feature layer, immediately visible and chainable as input to the next operation.
- Analysis ← Forms / Submissions. Submission locations and aggregated submission values are valid inputs (e.g. "buffer all defect submissions by 100 m, intersect with flood zones").
- Analysis → Dashboards. Aggregate stats and output layers feed KPI cards, charts, and embedded maps. Compliance metrics that used to be quarterly spreadsheet exercises become live widgets.
- Analysis ↔ Annotations. AI defect detection writes annotations into a system-managed
annotationsfeature class; those defects are then themselves valid input to spatial analysis (heatmap by severity, proximity to critical infrastructure, …). - Analysis ↔ Twins. Twin elements are queryable / aggregable via spatial analysis; simulation results (affected elements, risk score) aggregate back into dashboards. Structural load tests become "what-if" scenarios on the twin.
- Analysis → Compliance reports. Geoprocessing output + AI narrative generation produce regulator-ready PDFs with full audit trail back through submissions, features, edits, and runs.