See more, drive easy with the TomTom XXL. Go to tomtom.com to learn more.
7 February 2011 marked the second anniversary of the worst bushfire tragedy in Australian history – 173 people died and 414 were injured as the result of infernos raging around the State of Victoria. The Black Saturday Bushfire was a very traumatic event for many Australians, those directly affected by the fires but also those thousands who got emotionally and personally involved in post event forensic studies, clean up, counselling, rebuilding, Royal Commission and general assistance through voluntary work or collection of donations. The whole nation felt the pain and helplessness in the wake of such an enormous tragedy.
After a period of a relative calm over the last two years Australia has been struck again by several major natural disasters, such as flush floods in Queensland and Victoria, tropical cyclone Yasi, or bushfires in Western Australia. Events like these bring online crowds of people: those caught inadvertently in the incidents, or those concerned about safety of their family members and friends, but above all, “curious onlookers” from around the world who just would like to know what is happening. All those people are looking for basic information, such as maps of places to identify where “these things” reported in commercial and social media are happening, as well as anything that relates to progress of the event, likely scenarios it may evolve into and the impact on people, infrastructure and the surrounding environment.
In the first instance they turn to official sites run by State authorities – those that issue the alerts and warnings – and of course the Australian Bureau of Meteorology. When they can’t find what they are looking for, or the information is not in the format that is meaningful, they turn to online search engines seeking more details about the event. It is therefore not a coincidence that during the times of natural disasters the traffic to sites providing information on maps goes through the roof. A question comes to mind if there really is enough tools in the public domain to keep general public fully informed. Has anything changed since Victorian bushfires of 2009?
In an ideal world, all the relevant information would be provided by the authorities, along with alerts, warnings, evacuation orders, road closures and detour routes, situation briefs etc. And through all possible channels: online, stationary and mobile phones, radio and TV, and in all formats: text, audio and video broadcasts and online streaming, printed as well as static and interactive maps, and above all, web services for republishing the information through media and social channels. But that is still only a distant dream. The reality is that information is very fragmented, differs in formats and content from State to State and ultimately in reliability, accuracy and timeliness.
So, what information is actually available, in spatial format, to an average person interested in a particular event? Let’s start with bushfire related information as there is quite a few resources available…
Part 1: Mapping Bushfires
Detection of fire hotspots from satellites has been around for quite a while and Australia has two systems delivering such information that pre-dates Victorian bushfires of 2009: Geoscience Australia’s Sentinel and Landgate’s FireWatch. Both are using data obtained from the NASA Earth Observation Satellites Terra and Aqua which pass over Australia up to three times a day (although a revisit of the same area is only two times a day). Although data has some limitations, like timeliness due to infrequent revisit cycle or inability to detect hotspots through thick smoke and clouds, these applications provide excellent location reference for larger fire outbreaks throughout Australia. Geoscience Australia publishes the data in KML, WFS and WMS formats. I use those in my Hazard Monitor Bushfire Incidents map to publish an alternative view of the information. FireLocator from PitneyBowes provides yet another version of the same data in Silverlight format and with Bing Map in the background.
North Australia Fire Information is an application dedicated to monitoring fires in the northern part of Australia. In addition to satellite detected fire hotspots it also includes information on fire scars from past bushfires. Some of the information available on this site can be accessed in KML and WMS formats.
State authorities responsible for emergency alerts and response to natural disasters are publishing on their respective websites summaries of information on the latest incidents. Victorian Country Fire Authority (CFA) publishes a summary of incidents in a tabular format and on a Google Map. The information is also available as RSS feeds (locations are not georeferenced, hence cannot be directly imported into maps).
In NSW Rural Fire Service (RFS) publishes its version of summary of incidents – as a list and a map. Georeferenced RSS feed is also provided.
Both Bushfire Incidents map and FireLocator (developed in late 2009) are using the above feeds to display information about the latest incidents on the maps. During the peak of Victorian bushfires Google released its own application that mapped these feeds and showed satellite imagery of smoke and cloud cover.
Tasmania Fire Service (TFS) is another agency that publishes fire incidents information and a map as well as distributes the information via RSS (non-georeferenced) and KML. And South Australian Country Fire Service (CFS) publishes map and incidents in a similar fashion to already mentioned States (their RSS feed is also not georeferenced).
There are no interactive maps with the latest incidents for Queensland and Western Australia and those states do not publish RSS feeds in the format that could be easily reused for displaying the information in third party mapping applications.
The most recent additions to the list of online bushfire related information sources are BushfireConnect and everymap.com.au. Built with Ushahidi, these online mapping applications aim to publish information supplied by the public located in the affected areas, either by lodging reports online, or via SMS or Twitter (ie. crowd sourcing). They also republish RSS alerts from State authorities. Not the easiest and the most intuitive tools to use but these initiatives are attempting to engage a wider community in reporting of incidents so, deserving all the support.
At the time of major disasters media and private individuals create maps and various applications to share the information about a particular event. Examples include a Black Saturday feature created by ABC that allows users to explore timeline of events on an interactive map, or Google’s MyMap version created by a private individual as a static record of events (presented here on aus-emaps.com shareable map).
The recently released Query API within the Bing Spatial Data Services makes it easy to build applications that enable searching for locations by area, by property, and by ID. A common scenario is the ‘Locator’ application, in which end-users enter an address, and find the locations that are nearest to them. We can easily cater for this in Bing Maps by geocoding the end-user’s address with the Locations API, and then finding nearby locations with the Query API to Query by Area. Using a spatial filter, we can find the locations that sit within a specified radius of the given location, and present the results ordered by distance ‘as the crow flies’.
But what about those cases in which geography or other considerations mean that the closest location by straight line measurement will actually take much longer to drive to than one of the other locations? For example, if you are in the Upper West Side of Manhattan, NY, the nearest location by straight line distance might be across the Hudson River in New Jersey. But actually getting there will require you to drive or walk quite some distance in order to cross a bridge over the river.
It would be much quicker to make your way to a location in Manhattan that might be a bit further by straight-line distance, but doesn’t require you to cross any rivers.
So how can we help our users identify the locations that will take the least amount of time to get to? We can reorder our results by driving time before we present them to our end user. By using the Query API to obtain a set of locations in the vicinity of our user, then using the Routes API to determine how long it will take to drive to each of our nearby locations, we can guide our user to our locations which will be quickest for them to get to.
Reordering Results by Driving Time
The key step here will be the reordering of our results so that they are presented in order of least driving time, and doing this without making separate Routes API requests for each location. We achieve this by constructing a multi-point route request, going from the search origin (our user’s location) to each of the locations in our Query API result set and back. The Routes API supports up to 25 waypoints per route request, so we could use this technique to determine the driving distances for up to 12 locations in a single request. We can use the resulting drive time (or drive distance) of each leg of our route to reorder our locations before presenting them.
Included below is code for a basic application that combines the Bing Maps AJAX Control v7, the Query API, and the REST Locations and Routes APIs, to enable a fully client-side locator scenario in which we present our results based on driving time.
At a high-level, the application will:
- Capture a user address, and geocode it via the Locations API
- Take the latitude and longitude from our geocoded location, and use the Query API with a spatial filter to find the nearest 5 Fourth Coffee Shops to the user address
- Generate one multi-point route request that goes from our geocoded location to each Fourth Coffee Shop and back
- Reorder our results based on the driving distance from the geocoded location to each Fourth Coffee Shop
- Present the reordered results to the end user on a map using the Bing Maps AJAX Control v7
To optimize performance, we limit the result set to 5 locations, but to reduce the chances that there are other stores that might be closer by driving time than the 5 that are presented, we could also consider retrieving 10 results from the Query API, reordering them by drive time, then presenting only the top 5 from our reordered result set.
“Many people like the drag-able routes in the consumer facing implementation of Bing Maps. This feature basically allows you to mouse over a route-path and drag a point to a location that you want to drive past. “
Multi-waypoint routing in Bing Maps. You can have up to 25 waypoints, 27 including start point, an endpoint and up to 25 points in between within a single route-calculation. When the route is dragged the API re-calculates the route and basically adds an additional waypoint into the route.
Draggable Routes Bing Maps Demo
Source with Code with thanks to Johannes Kebeck
A few days ago, Google Sightseeing posted a few of their “most breathtaking rides” in Street View and they certainly found some great areas.
As you know, Google Earth 6 greatly enhanced the way that Street View works inside of Google Earth, allowing you to “drive” the routes much better than you can in Google Maps.
Even better, Google Sightseeing has put all of the locations they highlighted (plus a few extra) in a KML file for you to download. The only problem is that each location is a simple placemark, and doesn’t fly you directly into the Street View imagery.
Fortunately in Google Earth 6 it’s a simple fix! Just drag “peg man” from the top right corner of your screen onto the road they’ve highlighted, and you’ll instantly be taken into Street View mode, as shown below:
Google Earth has an abundance of amazing sights to see, and this is another great example of that. Thanks to the Google Sightseeing guys for putting together the list of breathtaking rides!