Google Maps & hurricane data

08 July 2005 @ early morning | Comments (21)

Without further ado, Google Hurricane Maps

With a little help from Google Maps API, historical hurricane data from Unisys, JavaScript, and some PHP, I’ve managed to scrap together a fairly nice (albeit still a bit slow) hurricane tracking overlay displayed using Google Maps.

Currently, I’ll not bother releasing the PHP source because, quite honestly, it’s a tad ugly. This is partly due to the fact that I’d like to work on moving toward reformatting the data in XML, but primarily because the data formatting and standards used by Unisys really suck. For instance, they delimit values with a varying amount of whitespace, their dates follow no standard formatting that I know of, and it’s a little difficult to grab the most recent observed value (as opposed to projected).

It would be nice if you could do multiple colors on one polyline in Google Maps, but (afaik) this is still not possible. This would lead to a more intuitive display of the progression of each hurricane’s severity. As of now, the path color represents the current intensity of the storm; the hurricane symbol its location; and any path past the hurricane’s current position, its projected path. Perhaps I’ll look into breaking out the method so that each polyline consists of many small polylines, although I’m not sure of how successful I’d be with that. We’ll see…

Update: Now accepts querystring parameter for past storm data maps ranging from 1851-present.

July 9, 2005: Updated the icon for the hurricane (now it’s visible). Today I’m going to try and tackle multi-colored hurricane paths, although it may slow performance significantly due to the sheer quantity of polylines it’ll be stuffing onto one map.

July 10, 2005: Major updates. Hurricane intensity is now detailed in multiple colors, making for a much better visual representation of storm paths. It’s also now possible to view any storm’s data for any point on a path. Historical data is available back to 1851.

Thanks to stumbling across Unisys’ decade data files, I was able to mirror their data locally and reformat each year into a separate xml document. Initially this was to facilitate using XMLHttpRequest, but after seeing no advantage and more http transactions I decided to just access the data locally via PHP. So instead, SimpleXML makes it just about as easy to manage the data.

Anyways… I hope it doesn’t crash too many people’s browsers out there. For years that experienced above average hurricane activity, it can take quite a while to load and render all the hurricane data points and paths (sometimes up to 30 seconds). But eventually it’ll load, I promise. Maybe some JavaScript gurus out there see some major flaws in this; I’m open for suggestions.

July 10, 2005: Some minor updates. I added a marker denoting a hurricane’s last observed (or current) position. Additionally, the date of each observation is now included in each popup info window.

July 10, 2005: Greatly increased the size of the map… how big is too big?

July 11, 2005: Anyone know what’s causing it to fail in IE? I was getting the dreaded “Operation Aborted“ IE bug (probably relating to Google Maps modifying the DOM before the page fully rendered) so I wrapped everything with Simon Willison’s addLoadEvent, which seems to have fixed that bug but there still appears to be some other javascript error. IE’s javascript console is so incredibly shitty: all I get is “Object doesn’t support this property or method; Line 285; Char 3“.

July 11, 2005: Now uses a liquid width, to accommodate multiple screen resolutions. Also added the ability to show/hide the legend so that it’s much more easily-accessible.

July 11, 2005 Now working in IE (man, I really hate that browser).

July 13, 2005: Stepped down resolution of hurricane paths by 1/3, due to insane rendering times on years like 1995; I’ll likely add this as a customizable feature. I’m also testing local XMLHttp to see if there’s any effect, but so far it seems all the lag is simply due to rendering.

July 13, 2005: Now liquid(ish). Tested only so far in Firefox 1.0.4 & Safari 2.0.

July 17, 2005: Slightly increased the size of markers to allow for textual abbreviations of storm status (uses Kottke’s Silkscreen font). I hope to have individual storm paths working by next weekend, so that a full-resolution storm path is again possible.

July 23, 2005: Individual storm information is now available for each year (in full resolution, too!). All-storm view for each year will be kept at 1/3 data resolution to keep from wreaking havoc on slower computers for active years.

July 25, 2005: Now with current and past storm information for the Eastern Pacific (dating back to 1949), as well as this year’s data for the Western Pacific. I’ll see if I can’t scrape the remaining data and reformat in XML sometime soon.

July 25, 2005: Hm… crashing occurs when resizing in IE. Once again, Internet Explorer sucks. Working to fix. Fixed it by moving the onresize jiggery-pokery to precede the DOM manipulation, but still needs a little IE-tweakage.

July 31, 2005: Finished scraping & formatting the Western Pacific past storm data for the years 1945-2004. I never realized how much more active that region is than the Atlantic; it’s really incredible. To try and accommodate the massive amount of total yearly data, I’ve set the data resolution to 1/4 when viewing all storms.

August 18, 2005: Google Maps has updated their marker-rendering JavaScript, so maps should now perform significantly better than a month or two ago (up to 3 or 4 times faster rendering times!). I’ve also finished the migration of all XML data to a MySQL database so hopefully I’ll be able to perform queries against that data in interesting ways. I’ll work to preserve old urls’ integrity through this process.

August 27, 2005: Slight enhancement to projected path markers. Now includes visual indication as to projected storm intensity.

September 30, 2005: Complete overhaul of map… check it out.


21 comments

1

Lovely.
Any idea if you can figure out how to show the projected path as more of an area, with some potential to diverge from the projection, and of some varying probability?

Mark Jones
2

As of this incarnation I’m still limited as to the data provided by Unisys, which doesn’t include probabilities or anything beyond that which is shown on the popup infomational bubble.

I think I’ll spend some time today looking around for secondary data sources, although I’m not sure if there are any free to the public other than RSS updates. I’ll be sure to post anything I find here, as there are likely others who could get even crazier with this implementation than I. Perhaps I can do a little more scraping for data.

Andrew → compooter.org/
3

Very cool. For the multi-colored polyline thing, you could just stop the line and start a new one every time the category changed.

It’d also be nice (for me, anyway) if the map was bigger.

David Brandon
4

Ahh, much better with the bigger map indeed. As for the multicolor line, that will require a major retooling, but I’m up for a challenge.

Andrew → compooter.org
5

Do you think you could add some dates to the position points?

I like how the bigger dots can show the different wind speeds, but I miss the current location icon…

blalor → bravo5.org/blog
6

blalor, sure thing. The observation date is now visible in each info window (if you click on the individual dot). I’ve also added an icon to represent a hurricane’s last observed location.

Andrew → compooter.org
7

I like your map. I actually used the same data from Unisys to display Dennis’ path Nationwide’s map of policy data, and I know what you mean with the horrible standard of data with Unisys. I have yet to find something better too though. I know there are companies that will supply a live shapefile feed, but you’d have to pay for that.

Vincent
8

How did you solve your “Operation Aborted”? I’m still having trouble with it, even after the suggestions you pointed out!

When I load your site with the hurricane map (nice work btw) no problems, load my map, similar config as your it still doesn’t work.

If you could elaborate a bit more on how your fixed the “Operation Aborted” that would be appreciated.

Thanks,

Bob

bob
9

Sure thing. It’s really a bug in Internet Explorer: a completely stupid step that unfortunately is necessary.

The one major step that avoided the “Operation Aborted” error was moving all of the JavaScript relating to modifying the DOM to after the containing element. For instance, if you look at the source of the page you will notice that the Google Maps JavaScript is the very last thing in the html, prior to closing the body/html tags. This was to ensure that it was not trying to modify the “map” div before the div was actually rendered on-page.

What’s strange is that at one point I wrapped the entire thing in a function to prevent it from executing map-related code until after the entire page loaded, but still no luck.

The only thing that had any effect was to ensure all JavaScript was no longer nested within divs (or tables if that’s what you’re using) and that it was located later in the document flow than the map-related container elements.

Does that make sense? Let me know if it helps out.

Andrew → compooter.org
10

Here’s some other hurricane tracking charts using google maps I’ve found. (To see and compare)

http://www.lets-go-dancing.com/hurricane.php?n=5&y=2005

http://map.sapp.org/hurricane/

http://flhurricane.com/googlemap.php?2005s5

Hurricaneman
11

Thanks for the links, Hurricaneman.

Flhurricane’s maps use a slightly different method of retrieving data, involving xmlhttprequest. I’ve rebuilt this thing three separate times using xmlhttp with no noticeable increase in performance. If anything, it became slower due to the increased http transactions. This is one of those examples where xmlhttp, while sexy, really doesn’t enhance the user experience and PHP might as well be doing the heavy lifting. The real processor strain is in JavaScript rendering, not data gathering.

That said, flhurricane clearly has more data at their disposal than I, being at the mercy of only that which Unisys and other organizations provide freely (which is still quite a bit of data, actually… I mean, if I really wanted to I could take the data I’ve mirrored and calculate much of the other probabilities myself). With more flexible Google Maps API rendering tools, say like a “polyarea” or something, flhurricane should be able to at some point render the projected area of a storm, similar to NOAA’s graphics. Whether or not they can is another question altogether.

For now, I’m satisfied how things have progressed. I’ll keep working to improve it based on feedback and iron out rough usability edges.

Andrew → compooter.org/
12

Great site, I am interested in plotting storms that have hit my hometown (Pensacola) over time. Any ideas on how to plot storms from multiple years?

Ted Kirchharr → roadkillrojo.com/tropical.html
13

Really nice, but a bug or two. For instance when I looked at the storms for 1888 (my grandmother’s birthyear) & clicked on dots, the dates were all 1969 !!

Brian Cuthbertson → bcuth.home.texas.net/
14

Ah yes, good ol’ Dec. 31, 1969. I thought I had squashed that bug a while back, but I seem to have reintroduced it. Thanks for the heads up.

Andrew → compooter.org
15

Bug officially squashed.

In case you’re wondering what that’s all about, it’s based on the maximum range of a timestamp within PHP.

The valid range of a timestamp is typically from Fri, 13 Dec 1901 20:45:54 GMT to Tue, 19 Jan 2038 03:14:07 GMT. (These are the dates that correspond to the minimum and maximum values for a 32-bit signed integer.)

So when a timestamp is out of range or invalid, the result (the server on which this website resides runs on FreeBSD) is the Unix epoch, or 00:00:00 UTC on January 1, 1970.

Who knows if that made any sense to you, just thought I’d explain the bug ;-)

Andrew → compooter.org
16

This is really cool.

Nice work :)

It’s funny that I ran into this today while checking out the blogs near me because I was having a conversation last night with a neighbor about using the Google Maps API and data from Weather.com or something to put together a live interactive weather map.

Isaac Z. Schlueter → isaacschlueter.com
17

Your map is pretty sweet! When you say you won’t bother to release your PHP code does that mean you won’t release your PHP code? I’m not a programmer at all but I’m working on a map of something completely different and I like the way your forms are set up, so I’d be interested to see the code as an example. Learning PHP, MySQL, Javascript, and the Google API all at once is not as easy as it sounded when I started! :)

REC → students.washington.edu/rec3141/crows/cgi-bin/crows3a.php
18

Great App.

Suggestion:
It would be nice for the current hurricanes (Rita) to see when it was last updated or how current the NOAA data is.

austin_tx
19

Best tracking map that I’ve seen.

Don’t know if these are possible, but…

  • Add the times of when it is supposed to be where on the track.
  • Give the option of seeing the projected wind speeds that will be hitting the various locations.
  • Give the option of seeing the projected rain amounts that will be hitting the various locations.

Thanks

Phineas
20

@Phineas: “on the track”? Do you mean aside from in the infowindow popup (when you click on a marker)? Rain amounts might be a bit tricky…

@austin_tx: I’ll see what I can do about that last updated time

Andrew → compooter.org
21

This is pretty awesome. The data that Unisys has seems to come stright from the National Weather Service: http://www.nhc.noaa.gov/pastall.shtml

Unisys does seem to have reformatted the data in an easier to parse format: http://weather.unisys.com/hurricane/atlantic/2000.data With the exception of a bug they have with regards to storms that cross year boundaries, it looks extremely easy to parse.

I’ve not found any other source for this data, and I’d be willing to bet that if the NWS doesn’t supply another data format, that there aren’t any other free ones available.

jeremiah johnson

Comments are closed for this article.

Previously