One of the developers in my section (Chris McLuckie) has been working on a replacement for our creaky old fire incident notification system, and launched the new City of Nanaimo Fire Daily Calls page last week. If you’re interested, you can read the official press release (pdf).

Basic improvements include:

• automatic pull from our FDM Computer Aided Dispatch (CAD… a popular acronym) database, removing requirement for dispatchers to manually update this list
• publication of the incidents in multiple formats (GeoRSS, HTML… KML planned for an intermediate update)
• integration with Google Maps

This is what the query interface for incidents looks like:

This is the embedded Google Map (using the GGeoXML class to hit the GeoRSS feed) showing incidents for the selected day:

This is the basic statistics interface allowing users to see incident activity for a date range (which also has a similar Google Map embedded):

And this is what the GeoRSS feed looks like in Google Maps

And now for the technical stuff…

Chris has put together a fairly strong process for extracting and displaying this information publicly, consisting of several components:

• A monthly FME process that reads the current 9-1-1 streets shape file and places it into a normalized database structure (one-to-many between lines and coordinates). This allows easy formatting of coordinates for different output formats (GeoRSS, KML, etc) in native ASP.Net.
• A SQL Server Integration Services job that pulls initial incident data from our CAD database, as well as updated information from the RMS (records management system), generalizes it to block ranges to reduce privacy concerns, and writes it our publicly accessible webserver.
• An ASP.Net web application that transforms an XML serialized data set into GeoRSS (and eventually other formats) using XSLT.
• An ASP.Net web application that provides the rudimentary user interface, including the incident query mechanism, incident statistics, and Google Maps integration.

The current applications are accessed via IFRAMEs because although our standard for web apps on our main site has changed from ASP to ASP.Net, our web site migration is still under way. Once the web site is redeveloped, these will be standard non-encapsulated web apps.

This is definitely just a starting point for us; the framework that has been used for this application was designed so that we can add other data sources that make sense for GeoRSS syndication, such as recent business licenses, building permits, etc. This aligns with our website redevelopment, where we are using RSS/Atom as an alternate access mechanism wherever possible.

As an initial project, there are certainly limitations with this implementation. For instance, we haven’t defined an API for pulling down specific categories or date ranges from the RSS feed. Also, because the GGeoMap class doesn’t expose properties of specific features, we were unable to link the incident rows with the map (pan and pop-up). There are third-party interfaces to Google Maps (GeoXML, EGeoXML) that work around this, and of course the option of just creating the lines ourselves, but we were trying to keep coding and dependencies to a minimum. There is a ticket in the Google Maps API issue tracker for this, so hopefully it will be addressed eventually…

Ideally we’d be using a spatially-enable database (such as PostGIS) as the underlying data store for this application, but we don’t have PostGIS in place on our public webserver yet.

-J

Related posts

• KML Goodness from the FME User Conference (1)
• GeoRSS: FME Rocks My World Again (8)
• A really Safe place to be… (1)