Fire Incidents

It’s not a good idea to go walking when there’s a bush fire nearby, hence it’s important for us to include bush fire information on BeyondTracks. We do this by showing all fire incidents on the map, and then again alerts for fire incidents nearby each walk.

At the moment we only do this for NSW, but in the future we hope to expand it Australia wide.

Source Data

Tim Berners-Lee suggested a 5-star rating system for open data:

★ make your stuff available on the Web (whatever format) under an open license

★★ make it available as structured data (e.g., Excel instead of image scan of a table)

★★★ make it available in a non-proprietary open format (e.g., CSV instead of Excel)

★★★★ use URIs to denote things, so that people can point at your stuff

★★★★★ link your data to other data to provide context

Star 1 - The NSW Rural Fire Service publish information about active incidents and release it under the Creative Commons Attribution 4.0 license, thus allowing us to legally include their fire incident information on BeyondTracks without needing to ask permission.

Star 2 & 3 - They publish machine readable and structured* feeds of fire incidents, in RSS, CAP (XML) and GeoJSON formats.

Star 4 - URI’s are used to denote specific incidents, eg. https://incidents.rfs.nsw.gov.au/api/v1/incidents/322851 however those URI’s don’t publicly resolve, so we can’t link directly to an incident.

Overall the NSW Rural Fire Service has done a good job in making this data open and available, although there’s room for improvement, what is in place currently meets about 90% of our need.

Future Improvements

• In the GeoJSON feed, a lot of information is overloaded into a “description” field.

"description": "ALERT LEVEL: Advice <br />LOCATION: 875 Aarons Pass Rd, Pyramul, NSW 2850 <br />COUNCIL AREA: Mid-Western <br />STATUS: Under control <br />TYPE: Bush Fire <br />FIRE: Yes <br />SIZE: 3 ha <br />RESPONSIBLE AGENCY: Rural Fire Service <br />UPDATED: 4 Jan 2019 15:35"

We can manually parse this out, but the data would be even more machine readable and structured if this was decomposed into a native JSON object.

• The feeds use terms like “Under control” and “Advice”, these are backed up with detailed descriptions of exactly what they mean on rfs.nsw.gov.au, however those descriptions aren’t provided as structured data. We’ve tried to address this manually creating these, publishing on GitHub and NPM.

We use these descriptions on BeyondTracks as tooltips when hovering over the specific terms.

Data Transformation

We’ve open sourced our Node module we use to aid working with the RFS’s GeoJSON feed, specifically this:

• defines a crontab job so you can mirror the upstream feed (you normally can’t use it directly in web applications due to a lacking Access-Control-Allow-Origin HTTP header)
• unnests GeoJSON GeometryCollection’s into either single level GeometryCollection’s where you have both a point and polygon geometry as part of the single feature, or a multipart geometry
• reduces unnecessary coordinate precision to reduce bandwidth
• unpacks the overloaded description field into JSON key value proprieties
• provides a machine readable schema and documentation of values
• enforces a GeoJSON geometry winding order
• sorts features by status

Furthermore on the client side we filter fire incidents to only show bush fires, grass fires, hazard reduction, haystack fires and burn offs. Other incidents like motor vehicles accidents and search/rescue aren’t relevant so we don’t show them.

Currency

Timely information is critical, a lot can change in a few hours. All we can do is try to minimise the delay between RFS publishing information and BeyondTracks showing it. We mirror the RFS data every 5 minutes, and show two pieces of temporal information for each alert.

Last updated 15 minutes ago, current as of 3 minutes ago

The Last updated is when the RFS last updated any information for this specific incident, the current as of is when we last pulled the latest information from the RFS.

Future Work

• I’d like to build in more automated checks all through the process, if something looks unexpected in the source data, that should be flagged so it can be checked. s Although the current as of should never be more than 5 minutes, we should code for cases when it’s greater, perhaps by emphasising that our data is delayed and to check rfs.nsw.gov.au directly.
• I’d also like to see the source feeds the RFS provide have more rigor, including documentation, strict schema specifications and versioning so they can make changes without breaking downstream consumers.