|Date:||23 August 2012|
Developers often use Twitter to point out exciting new libraries, or share mistakes that might also catch others. But sometimes we are less constructive and simply use Twitter to complain, as I did on Tuesday when I noticed that different weather radars on Radarmatic were not consistent in how they positioned storms.
Sobering to scroll around radarmatic.com and look at a 1 storm from several different Doppler radars—they all put it different places!— Brandon Rhodes (@brandon_rhodes) August 21, 2012
Radarmatic is a recent find for me, that I discovered in mid-July when @buzz mentioned it. Its interface was an instant revelation: this was what I had wanted, without ever knowing it! It was as though my screen were washed clean and everything was suddenly gone — the tedious clicking to navigate to a normal site's radar map, the wait for banners and borders to load before the radar itself — and I was given instant access to the information. The only setup is to scroll the site to the radar for your area. From then on it remembers which radar you want to see.
I still use WeatherSpark for forecasts, of course, because nothing packs in as much weather information as its beautiful and concise forecast graphs. But most of the time I don't need a forecast. I just need to see if a storm is coming before going on a walk, or starting a project in the yard.
Fortunately, one of my followers was well-qualified to challenge my cranky tweet. Eric Floehr is not only founder of the Central Ohio Python Users Group, but also the owner of Intellovations — whose products provide weather forecasts! As a domain expert experienced in Doppler radar accuracy, he could immediately challenge my mistaken assumption: how did I know that the problem was with the radars?
— Eric Floehr (@ForecastWatch) August 21, 2012
@brandon_rhodes I think it's more likely the developer isn't doing a proper mapping to Google maps...
All right: good point, Eric. So how could I discover for sure where the error lay? I opened Radarmatic and saw no activity in my area, but over in Minnesota there was an excellent candidate — a bright line of storms that Radarmatic painted as west of Saint Cloud when viewed from the Sioux Falls radar, but as east of the exact same location when viewed from La Crosse. You can find Saint Cloud near the storm's northern tip in these images:
var start_x = radius * Math.cos(start_angle) + center_x; var start_y = radius * Math.sin(start_angle) + center_y;
The idea behind this code can be expressed this way:
“I want to draw the precipitation that is at a distance of radius from the Doppler radar, so how about I just head in that direction across the screen by moving a corresponding number of pixels?”
Which would be absolutely perfect — if only the world were flat.
The famous Mercator projection used by Google Maps presents the Earth's lines of longitude as vertical parallels that run straight up and down the page — despite that fact that, on the real earth, the lines of longitude will bulge farthest apart at the equator and then gradually narrow together as they approach the poles. This has several consequences.
All of which means that a Doppler radar beam pointing exactly northeast from Sioux Falls, for example, across the pixels of a pretty Google Map, will not actually march diagonally. It will start its journey by making an exact diagonal, but it will soon start swinging south as its path — arcing straight along the curved globe — warps as it is mapped to the distortion of Mercator's grid.
And, even more importantly at the scales we are concerned with, the beam will appear to speed up as it heads north, since distances high on a Mercator map are so much smaller. A kilometer-long severe storm far north of Sioux Falls should look larger than one caught at the south end of its beam.
Spherical geometry is the branch of mathematics that deals with these relationships, and, quite happily, I discovered that I did not need it at all — because Google Maps already implements the essential formulae in its spherical namespace! This meant that I could close a half-dozen browser tabs full of mathematics that I had just opened, and instead just use what Google Maps provided.
The necessary Google Maps functions are not available to the stock Radarmatic service, incidentally, because of the URL that it uses to fetch the Maps API. Instead, a site has to declare this at the top:
With the library in place, all that is required is discipline: whenever you want to draw a point on the map, you must figure out the real latitude and longitude that you are targeting, and then submit those values to the API to learn their true x- and y-coordinates.
If you wanted Radarmatic to render accurate radar maps, you could simply drop into place a new version of its sweepArc() function like the one that I provide in this Gist. I provide this code as a kind of example tutorial for anyone trying to work with distance-and-direction data across the flat surface of Google Maps. As you will see if you read the code, there are three crucial steps:
The two really crucial functions to use in this case are:
The result is quite gratifying, as you can see by mousing over this map to compare the two versions of the image:
Of course, there remain many numerous, legitimate, and interesting differences here about what the two radars see. Sioux Falls, for example, seems to only see the closest edge of the severe weather stretching south of St. Paul, with the rest remaining hidden. But the radars now agree quite closely about the overall outline of the storm system they are tracking, and, most crucially, you can see that the bright line of storms near Saint Cloud now has exactly the same position in both images — just barely northeast of the city, as it happens, and not far off in the distance as originally mapped!
Radarmatic does not seem to advertise a bug tracker, but it does provide author contact information, so I will send him a link to this article in case he is interested in tweaking his wonderful service. Of course, for people located in major metropolitan areas, the site works just fine — if you live close to one of the Doppler radars, then the error will not even be noticeable. But those of us who are living far from Doppler radars, who always have to stare at the very edges of a radar plot to determine whether a storm is coming, will be quite happy if the site some day rolled out this improvement.
And, yes, I am, in fact, the guy who mapped Middle Earth on to Google Earth. I know. Small world.