This weekend I was at
RHoK Melbourne hosted at my old stomping ground of
Swinburne University (I did graduate from there after all), spending 2 days hacking out a workable solution within the given time frame and parameters.
Prologue
I first got wind of RHoK from an old uni friend on Facebook. Intrigued, I attended the free information night that was being held to provide more information to interested parties.
The theme of the event was disaster risk and crisis planning (for bush fires, extreme weather events, etc). Going through the stories of all the problem stakeholders there was another common overarching theme: the relevancy and importance of location and spatial data, which incidentally happens to be problem domain I'm intimately familiar with (if the title of this blog and the
200+ posts of related content didn't give that away :))
The challenge
The problem I chose to attack was the one of
"Spatial Truth" for the simple reason that of all the problems listed, this was the one that could allow me to make maximum use of my knowledge and skills in this particular area. Other problems have a spatially-relevant component to them, but this one on paper looked 100% spatial to me.
The problem in question is one of mash-ability. The vicmap API data provided by the
DSE needs to be able to be overlaid or mashed up with other mapping service providers (Google/Bing/OSM) and other assorted spatial data to allow the user to compare the various spatial data sources to ascertain which particular data source is the definitive source of truth for a particular area or region.
A small hiccup
The original intended solution was to have a
HTML5 single-page application powered by the trinity of:
And use the vast capabilities of OpenLayers to mash up our all desired spatial data sources together, with Twitter Bootstrap providing us with a decent looking UI (hey I'm no web designer) that can easily scale down to mobile devices and jQuery just doing what it does best.
Well, this intended solution didn't quite pan out as we wanted to because of some problems:
- The vicmap API was built on OpenLayers (great!) but it using its own bundled copy of OpenLayers (not so great. 2.10, pre-dates mobile/touch device support)
- This bundled copy of OpenLayers defined its own OpenLayers Map and Layer types, making it difficult to integrate with our own (newer) OpenLayers.
The vicmap API was basically a JS wrapper around a
WMS server, so we decided to eschew the provided vicmap javascript libraries and go directly to the WMS source (maybe a hack, but fits the name of this event)
After deciding to go directly to the WMS source, we found the biggest problem: The vicmap raster imagery was not in the projection we require (
EPSG:3111 instead of
EPSG:900913). You can't line up and/or overlay multiple raster imagery sources if they aren't in the same projection. Unfortunately JS web mapping libraries (and browser technology) have not sufficiently advanced enough to allow us to re-project raster imagery client-side (vector data is not an issue, but most of the data we're working with are raster, so no go).
So faced with this problem, I looked to an
old friend who
knew exactly how to deal with problems like this.
MapGuide to the rescue
I originally didn't want to involve MapGuide, despite most of the problems presented having a spatially-relevant problem (that MapGuide could partially/fully solve). I really wanted a pure client-side HTML5 map viewer. Although it would've been dead simple to just serve out a fully-featured MapGuide AJAX/Fusion viewer with the re-projected vicmap WMS layers like so ...
... and leave it at that, these viewers are notoriously difficult to adapt to tablet/smartphone displays (they were built before the emergence of HTML5/iPhone/Android after all) and are very GIS-y, which might be a bit hostile to normal users.
Accessibility and simplicity was key. The solution
had to be accessible from smartphones and tablets. So in that respect, MapGuide's role in our solution was to act more as spatial data "proxy server", funnelling the vicmap imagery into a form that allows us to line it up and/or overlay it against Google/Bing/OSM imagery.
And as I've blogged in the past,
OpenLayers makes mobile maps dead simple.
Twitter Bootstrap gives the application a shiny enough look that can gracefully scale down on smaller displays due to heavy use of
responsive design. So actually building a mobile map viewer from scratch was not exactly difficult to do.
The solution
The solution came in two parts, demonstrating 2 approaches to the objective of ascertaining the "Spatial Truth" among various spatial data sets.
The first one was a 4 viewer layout showing vicmap against Google, Bing and OSM data sets, with some pre-fabricated data to show off
custom markers and heat maps (which could easily represent bushfire incidents or weather patterns)
All 4 viewers are synchronized, meaning panning or zooming one of the viewers does the same for the rest. One can easily ascertain the "Spatial Truth" by being able to look at all 4 sets of data
at once instead of overlaying one on top of another. Unfortunately, this layout is clearly intended for use on the desktop and cannot clearly degrade gracefully to tablet/smartphone displays.
Hence the 2nd part of the solution, a fully responsive version.
Unlike the desktop-optimized layout, we only have one map viewer, so our ability to compare various datasets is to overlay the vicmap layers on top, through our own layer switcher.
The application takes advantage of HTML5 features like geolocation, that is near-universally supported on most smartphones and tablets
And for smartphone displays, our application scales down nicely to match due to the responsive design of the Twitter Bootstrap framework our application is built on top of
If the active layer is a Google one, the application can tap into the Google Map's geocoding API, allowing for address query and address resolution from coordinates (which we can't legally do with other layers due to Google's terms of use. We
must have a Google map present and displaying to legally use their other services)
Finally, the application can allow for spatially-enabled RSS feeds (GeoRSS) to be overlaid onto the map. I scoured through many Victorian Government websites looking for any usable spatially enabled RSS feeds, but the only one I could find (which also happens to be very relevant to the theme of this event), was the GeoRSS feeds from the CFA showing the fire incidents and warnings for the last 4 days.
When overlaid, each incident and warning is indicated with custom OpenLayers markers
And because we're using OpenLayers GeoRSS layers to overlay this information, each marker can be clicked to bring up its feed item as a popup
Not bad for 2 days work I must say.
The source code for this application is available on
github. This solution currently requires installing
MapGuide Open Source 2.4 and the Vicmap MGP package (included in the github repo) in order to serve out the re-projected vicmap data. I've been told that the Vicmap data will also be available in a Google/Bing/OSM-compatible in the near future, which would remove the need to have MapGuide in place to do the re-projection work.
Just a small word of warning. The code quality of the solution reflects the nature of how it was built (a proto-typical proof-of-concept in 24-36 hours). Of course if we had more time, we'd do things in a more cleanly structured and architected manner.
My
brief presentation slides on this solution are also available
Epilogue / Postmortem
The presented solution didn't win the first place prize for the event, but did win the special mention award. Of particular note from the Judging Panel (memory is a bit fuzzy here) was:
1. The visually stunning aspect of the demo (interactive maps have that kind of quality)
2. The amount of work done in the given timeframe with the number of team members involved (2, which includes myself). I owe this to the simplicity of OpenLayers and Twitter Bootstrap. The respective taglines of these two libraries are true.
OpenLayers does make it easy to put a dynamic map in any web page. Twitter Bootstrap
does make it faster and easier to build a sleek, intuitive and powerful front-end. Combine this with
the write less, do more library and you have the holy trinity of tools to churn out beautiful, mobile-friendly web mapping applications in no time.
What were the lessons that could be learned from this event?
- Spatial and Location is very important. Every solution presented at the end had some form of mapping component involved. If your solution can leverage spatial data, take advantage of it! Spatial is to data what time is to x, y and z. It is an extra dimension that gives new ways to view, query and analyse your data. I already knew this going in, and being armed with the knowledge and the tools I knew how to carry out the best approach.
- The vicmap API could definitely be improved. Shen, my team partner for the first day of the event actually built part of the vicmap API and would agree with this sentiment (dogfooding ftw!). If the API is ultimately just a way to consume WMS data (we don't know because we bypassed the current API straight to the underlying WMS source), then there isn't really a point in wrapping that up in a custom JS API. The fact that this data is exposed through a well-supported OGC standard is good enough for most, if not all geospatial software and libraries to consume this information. If you really have to extend OpenLayers to access this data, then you realistically only need to extend the OpenLayers.Layer or one of its subclasses to support the vicmap data and nothing else. Most vendor-specific extensions to OpenLayers (like MapGuide's OpenLayers support) are done at the layer level. A fully custom version of OpenLayers should not be necessary.
- The state of freely available spatial data in Australia is still somewhat woeful. Vicmap opening up their data is a start and hopefully more government departments follow suit. No need to have special APIs to access this data, OGC standards were invented for a reason.
- On a similar vein, more organizations need to be spatially aware of the data they make available to the public. I was sorely disappointed at how many Australian RSS feeds are not spatially-enabled GeoRSS feeds. For example, VicRoads provides RSS feeds of traffic and roadwork information, yet this data has no geographic information, significantly hampering its utility. If this was a GeoRSS feed, we could've overlaid this information on a map and be able to see where these traffic incidents and roadworks are happening. You can't do that with regular RSS feeds.
- Oh an manually setting up a MapGuide layer in OpenLayers (in our case, the re-projected vicmap data), is still an absolutely cumbersome process. Fusion, which also uses OpenLayers doesn't have this problem because your ApplicationDefinition document auto-plumbs all the necessary configuration values. Good luck trying to remember all those values when doing it manually!
A big thanks to everyone who organized this event. It was a blast.
I'll be waiting for my prize RHoK hoodie in the mail.
Posts
