Last Friday (20/2) saw the public release of my long term project Fire Report, albeit in its 3rd incarnation. The first two succeeded in opposite directions before ultimately failing, this time both direction were brought together to create a working solution. OK so now you probably want to know one of two things, either:
- Where can I find this?, or
- What is this?
Both of these questions can be answered by a visit to the Google Map Fire Report Direct Link.
What you will see will look like this:
Screenshot: Mapplet client (BETA) just before submision to Google.
As I believe in free and open source software (FOSS), and the rights for anyone in the community to use such a solution, this project in its entirety are licensed under the GPLv3 unless otherwise specified; like in the case of borrowed code. Of course as with the nature of the solutions client side Mapplet that code is already available by searching for it on Google Maps Directory under “Fire Report” and clicking “View Source”. The server side code (PHP) will be avaliable soon; I just need to clean it up a bit.
If you have looked at the Mapplet, read through “help” and “about”, and still don’t understand what this project is then here it is in a nutshell:
The Fire Report (VIC/AUS) is a software project hosted on sourceforge.net with the purpose of viewing the CFA incidents from the CFAs website on a map of Victoria, and future versions will include features above and beyond that that the CFA provide.
This BETA version has all the features of the CFAs incidents summary displayed on the map, all feed through an auto updating solution that can be paused/resumed and that caches everything except the hit counter. All caching is provided first by the server here and secondly by Googles servers before it reaches the masses. If your curies about the hit counter the stats can e viewed on my newly created statistics page; be forewarned this is a pretty basic page.
If you find any spelling mistakes, hey I’m a programmer not a ‘person that writes stuff’, anywhere throughout the project I will gladly correct them, just send me a message, either through email, the sourceforge.net project or a comment here.
And now for some of the technical background, some of which I haven’t spoken about anywhere else. If you either get bored or confused by this kind of thing you are very welcome to got back up to the direct link to the Mapplet and play around with it instead.
The first thing you need to understand is where is all of this data coming from, its one thing to have a map but an entirely separate thing to have something to put on it. Well first of all the CFA create the information, direct from their Incident Management System (IMS) then they put it into an RSS feed which this website collects. At this point the CFA has finished their part of the process and no more load is put on them.
Secondly my website receives the RSS information and makes use of MagpieRSS to parse (decipher) what the information is. This information is broken down and the relevant bits used to geocode (get the longitude and latitude for) the incident. Once this is done the system stores all of this information in a mySql database, all incidents older that 24 hours old are removed and thus a whole days incidents are always kept. Everything in this paragraph is performed by the file GET.php.
To ensure that the mySql database is kept updated a CRON (automated scheduler) job runs the GET.php script 42mins passed each hour, unless the script was run in the last 90 seconds and I’ll get to that in a moment.
Next we make the long leap to the client side. You the end-user enable the Mapplet at google maps, the Mapplet code itself is cached by Google. The Mapplet begins to set things like the menu up and then makes a request (cached by Google) to a file on this website called list.php, this file first checks to see that GET.php has been run in the last 90seconds, if it hasn’t it runs it, and collects the last 500 incidents (usually all of the ones from the last 24 hours) from the mySql database, puts them into a text file in a special format where each incident is on a new line and each piece of information about that incident is separated by a pipe, “|”, symbol, this text fille is returned to the Mapplet. But the websites job hasn’t finished yet, as you will find out later.
Once the Mapplet in your browser receives this data it quickly puts it into an array of incidents, indexed by the incidents id, specified by the CFA in the RSS feed. Then it needs to create that list that will appear on the left hand side under the buttons and status, to reduce load on your browser the details that appear when you click “details” and created on demand only. Now comes the really useful part the Mapplet uses the information now stored in its array to place markers on the map, some people may have to be patient depending on their computer, but this is a one off occurrence that only happens when you enable the Mapplet after that it only has to update the markers.
But instead of the boring old nondescript marker provided by default by Google the Mapplet uses this website to create new descriptive ones. These markers show type, size, age, status, and number of ‘appliances’ in attendance. The Mapplet tells the website what it wants and the website sends it back, cached of course by Google. The markers fade out the older they get, so the Mapplet simply asks for each marker to be redrawn each time the transparency needs to be increased. There are currently eight levels of transparency. Incidents up to one hour old are opaque, and for each half hour older gain another 10% transparency until they are 70% transparent. I am planning of adding a feature to change the time it takes the markers to fade out, your input on this is welcome.
The Mapplet also auto-updated its incident list, the status will flash yellow then fade back when an auto-update occurs. If a new incident arrives it will flash red then fade over a longer period back. In the case that you will be away from the map for more than about 3mins you can pause the auto-updater and it will run again when you resume it. The auto updater runs every 90 seconds.
Clicking on an incident name in the list will take you to it on the map. The details displayed when you click on a marker are also created on demand and include a copy of the icon to help you either find it on the map or find it amongst others.
And now a quick analysis of who gets the load. The Mapplet is cached by Google so anytime someone enables the Mapplet Google takes the load. Therefore this website takes one hit for that about every few hours. Next the Mapplet get the first load of data also cached by Google, refreshed every 90 seconds, list.php takes the call and runs GET.php which only runs if it hasn’t run in the last 90 seconds, if it runs it gets the RSS feed from the CFA, the if the isn’t anything new then the whole RSS feed won’t be requested, the genius here is that if one person is using the Mapplet then the website here and at the CFA take load equivalent to one user, if two people use it the server here takes a little more load but the CFA receive no more, and after that the load does not increase for the CFA, the only increase in the load here is the hit counter that isn’t cached by Google but that only has a minimalist impact on this website, the rest goes to Google. So if the CFA website is under heavy load you can be assured that the Mapplet wont be, and using the Mapplet can in an indirect way help the CFA to reduce load.
I would have added some more images but there really isn’t any point, you can just go and use it and see for yourself.