Google hurricane maps update
29 September 2005 @ late at night | Comments (64)
After many hours of tinkering with every latest Web 2.0 fad, I’ve managed to scrape together an improved implementation of storm tracking with Google Maps.
Tools
- FireBug – essential JavaScript debugger
- Yahoo! Geocoding API
- JSON – my new best friend
- Sajax – you know, that silly Ajax thing
- FAT – eye candy
Ajax
I chose to use Sajax for the XMLHttpRequest transactions, for which I could also have used XAJAX, eliminating the need for callback functions and providing some nifty DOM manipulation functions via XML response, but I didn’t stumble upon XAJAX until just recently and didn’t feel like re-rebuilding. I also really would have loved to jump on Rails for this one, but it’ll have to wait until another day. That one’s been on my to-do list for months now…
Permalinks
Moving toward Ajax presents some challenges by itself, like allowing for permalinks. Not only did it need to be able to accept permalinks for any map created via the Ajax interface, but also redirect old permalinks to the new format.
The old permalinks relied on two querystring variables, year & storm (?year=2005&storm=katrina); new permalinks use chained storm ids that consist of year/storm id (?2005s1&2005s12). In order to not break old permalinks there is an initial querystring check, followed by a 301 permanent redirect if it finds a storm match. All of the querystring processing is done server-side via PHP.
So the coolest thing about the permalink change? Now you can compare stuff. For instance, Camille vs. Katrina or Gilbert vs. Allen.
Layout
I’ve tried to keep everything as cross-browser as possible, but liquid layouts are quite a pain so please report any “deal-breaker” strangeness you encounter. I’ve tried this thing out in a ton of browsers, including all of Google Maps’ supported browsers, without finding any major bugs.
The worst layout issue I’ve found is Opera 8’s miscalculation of the body/html 100%. I could use overflow:hidden to prevent the scrolling page, but there really is no way of performing an Opera-only CSS rule and it’s not a horrible usability hit, since the extra page height/width and scrollbar doesn’t negatively affect page functionality.
Data
I managed to migrate all data into MySQL that I had collected from Unisys and formatted as XML. This allows for more powerful and easier querying, less overhead from XML processing from within PHP, and more potential for cool additional features, like “smart-searching” (if I ever get around to implementing them). It also eliminates the possibility of more than one person triggering a cache update during heavy traffic by flagging a cache lock in the database while an update is in progress.
Observations
Was it necessary to use Ajax? Well… quite honestly, no. But Google Maps is not accessible to anyone without JavaScript enabled anyways, so that exempted me from a few of the major Ajax mistakes.
Additionally, I feel that I’ve done a fairly good job navigating the remaining items on that list by simplifying the interface, providing immediate visual cues (but not too many), cascading local changes to the page title and current storm list, allowing for permalinks, and (_not Ajax-related_) making the liquid layout work consistently in all supported browsers.
To Do
Live updating of page titles via both permalinks & AjaxDONECenter on storm when selectedDONEDisplay storm list w/ “Current Map” pane active for permalink entranceDONEAdd “Select All / None” for storm listDONEDisplay last updated timestamp for current year’s dataDONE- Zoom-to-bounds for each storm’s link
- Smart-searching… popup? separate page?
Known Issues
- Solve occasional initial connection lag issue (Sajax bug?)
64 comments