Bushfire Exposure Across Victoria's Powerline Network
Databricks Community Genie-Powered App Challenge ยท Track A, Real-World Problem Solver
Powerlines start bushfires, and bushfires destroy powerlines. Victoria regulates the first half of that with electric line clearance rules, and every distribution business runs a vegetation program to comply. Those programs never have enough money for the whole network, so somebody has to choose which spans get inspected this year.
The data to make that call is public. Victoria has published its fire history back to 1903 and its powerline network for years, both open. Free Edition with Genie Agents and Databricks Apps is great to have all the tools in one place to finally do it.
Watch the demo: https://youtu.be/mYNgOuMWXUg
The app runs on Databricks Free Edition, where apps authenticate against the owning workspace, so the recording is the way to see it work. The notebooks, the Genie configuration and the full app source are in the repository linked at the end.
The problem
Deciding where to spend a clearance budget needs a view of which parts of the network sit in country with a real fire history. Nobody has that view, and it is not because the data is missing.
Who it is for
Vegetation managers and asset risk analysts at electricity distributors, first. These are the people who hold the inspection budget and have to defend how they spent it.
Beyond them, the same data answers questions for emergency management planners, regulators looking at network resilience, and researchers working on powerline ignition. None of these people write SQL, and none of them can predict in advance what they will need to ask.
That last point is what made this a Genie problem rather than a dashboard problem.
Architecture and data flow
Three open datasets from the Victorian government, all from DEECA:
| Source | What it is | Size |
|----------------------------------|----------------------------|------------------|
| Fire History Scar | Fire boundaries since 1903 | 109,219 polygons |
| Vicmap Infrastructure Power Line | The overhead network | 396,455 segments |
| Vicmap Admin LGA | Council boundaries | 137 polygons |
Three shapefiles (DEECA open data)
โ
โ GeoPandas, once, as a file reader
โผ
BRONZE bronze_power_line ยท bronze_fire_scar ยท bronze_lga
geometry stored as WKB in a binary column
โ
โ h3_coverash3 at resolution 8, then explode
โผ
SILVER cells_segment ยท cells_fire ยท cells_lga
one row per hexagon, so the spatial join becomes an integer join
โ
โผ
GOLD gold_segment_exposure 159,268 rows, no geometry column
every spatial fact is now an ordinary number
โ
โผ
GENIE v_segment_exposure the network, one row per stretch of line
v_fire_history the fires, one row each, 1903 to 2026
v_segment_fire the link between them
โ
โ Genie Conversations API
โผ
APP Streamlit on Databricks Apps
prose ยท generated SQL ยท table ยท chart ยท map
Ingestion. Shapefiles land in a Unity Catalog volume. A notebook reads them with GeoPandas and writes each to a Delta table with geometry stored as WKB in a binary column. GeoPandas appears once, as a file reader, and never again. Databricks SQL cannot read a shapefile, but once geometry is a WKB column everything downstream is
plain SQL.
Spatial join by H3.The real computation is "which fire scars intersect which line segments", which as a polygon-to-line operation across 109,219 polygons and 396,455 lines is expensive and awkward to reason about. H3 turns it into an integer join. Both layers get indexed to hexagonal cells at resolution 8, roughly 460 metres across, and two geometries sharing a cell are treated as near each other.
I used `h3_coverash3` rather than `h3_polyfillash3`, and that choice mattered more than I expected. Polyfill returns only cells whose centre falls inside the geometry. Tested against the council boundaries at resolution 7, three of the first five councils came back with zero cells: they were smaller than a single hexagon. Applied to fire scars, small fires would have vanished silently, which is a wrong answer nobody notices. Lines have no interior at all, so polyfill on the network layer would have been close to useless.
Resolution 8 was picked to match the accuracy the source data actually has. The fire history carries an `ACCURACY` field with values down to "greater than 100m", and Vicmap states that powerline locations are unverified. Indexing at 175 metres would have been false confidence.
The gold table One row per line segment, 159,268 of them, with no geometry column at all. Every spatial fact has already become an ordinary number: `times_major_bushfire`, `last_bushfire_season`, `pct_extent_major_bushfire`, `lga_name`. That is the single most important design decision in the build. Genie never sees a geometry column. It never generates spatial SQL and never reasons about coordinate systems. Every question it faces is plain aggregation over clean columns, which it handles reliably.
The app. A Streamlit app on Databricks Apps, with the Genie Agent attached as a resource. It calls the Genie Conversations API through a small client that handles polling, status updates, attachment parsing and conversation threading. Answers come back as prose, the generated SQL, a table, a chart, and where the result names specific
segments, a map of where they are.
What users can ask
Anything the data supports. Nothing is pre-built. Some of what it handles well:
- Which councils have the most bushfire-exposed powerline network?
- Are SWER lines more exposed to bushfire than other high voltage lines?
- Which segments should we inspect first?
- What network did the 2019/20 Black Summer fires affect?
- Which fires were caused by powerlines?
- Which 22 kV segments in Gippsland have burnt more than three times since 1980, excluding planned burns?
That last one is the shape of question a dashboard cannot anticipate. Three filters, one exclusion, one threshold, one geography. Building a control for every combination is impossible, and that is exactly the space natural language is good at.
Follow-ups work too, because the app threads conversations. Ask about SWER lines, then just say "which councils have the most", and it carries the context.
How Genie powers the experience
Remove Genie and this app is a map with some numbers on it. Every answer, every table, every chart is generated in response to a question that was not written in advance.
But the interesting part is not the plumbing. It is the semantic layer. Genie reads three curated views with a comment on every column, plus a set of instructions and thirteen trusted SQL examples. That configuration is where nearly all the effort went, because Genie's answer quality is mostly a function of what it has been told the data means.
An example. My trusted query for ranking councils includes `HAVING COUNT(*) >= 100`. Without it, Falls Creek Alpine Resort tops every average-based ranking on the strength of a single segment. Genie learned the pattern from that one example and now applies a minimum denominator to rankings I never wrote an example for, and says so in its answer. I did not ask it to explain the threshold. It does it because the instruction tells it why the threshold exists.
The best moment in testing was asking whether planned burns reduce bushfire risk. Genie found a positive correlation, then refused to read it as causation: it named the counterfactual problem, the absent severity data, and the confounding from targeting.That is a better answer than most analysts would give, and it came from three sentences in the instructions.
What I learned
One fire is drawn as many shapes. The 109,219 polygons in the fire history resolve to 17,934 actual fires. One fire from the 2019/20 season is mapped as 868 separate patches. Counting rows would have told a user that a single fire happened 868 times. Worse, 43% of polygons have no fire identifier at all, so I needed a three-tier
fallback (fire key, then fire number plus season, then polygon id) to group them correctly. Getting this right changed the powerline-caused fire count from 28 to 8.
Segments vary from 200 metres to 100 kilometres. A Vicmap segment is one feature, not one span. The most heavily burnt segment in my first cut was a 330 kV transmission line crossing 255 hexagons, roughly 100 km. It intersected everything along its route because it was long, not because it was in dangerous country. The fix was to compute what share of each segment's own length sits in major fire ground, which compares fairly regardless of size.
Areas cannot be summed. Fire polygons overlap. The 2019/20 Snowy Complex sums to 892,445 hectares across its polygons when the fire was around 400,000. If Genie could reach that column, someone would eventually ask for total hectares burnt and get an answer wrong by a factor of two that looked entirely credible. The column is hidden and the instructions explain why.
The wider lesson. Genie is very good at the questions you cannot anticipate, and completely dependent on what you tell it the data means.
Would the experience change if Genie were removed?
Remove Genie and what is left is a map of Victoria with four numbers above it. Every table, every chart, every ranking and every caveat in this app is generated in response to a question that was not written in advance. There is no dashboard underneath, no filter panel, no pre-built report to fall back on.
Details
Built entirely on Databricks Free Edition: Unity Catalog, serverless SQL warehouse, H3 and ST functions, a Genie Agent, and Databricks Apps with the agent attached as a resource. Everything reproducible from the notebooks.
Source data: Vicmap Infrastructure and Fire History Scar, State Government of Victoria, Department of Energy, Environment and Climate Action. Licensed CC BY 4.0.
Repository: https://github.com/viveknz/vic-powerline-bushfire-genie
Notebooks, the Genie instructions and trusted SQL examples, a 24-question test bank with a scoring rubric, and the full app source are all there.
