DASNET

There's no doubt about it -- Google Maps is cool. It's not providing much more in terms of information than other, competing map services, but it more than makes up for that in terms of user interface. It's the easiest, most intuitive way to look at maps.

Of course, it's limited to whatever maps Google wants to provide. Some very good maps, certainly, but not always everything people might want. Almost from the start, I'd wanted to see additional map types added to Google, and in recent weeks they've added some of their Keyhole images (down to about 1 meter resolution or so). But I'd wanted to see better resolution (we have USGS Urban area photography available to almost 1/4 meter), and also topographic maps.

Of course, those maps and images are already out there, at Microsoft's TerraServer. Several applications (USAPhotoMaps on the PC, and TerraBrowser on the Mac) already interface to that server pretty well, but they're standalone apps, tied to an operating system. I wanted something that worked in the browser. So when I learned that Google had included some hooks to abstract the back-end image tile server, I knew I had to try. And now, after about a week of obsessing, I've got something that works pretty well (though it's not perfect).

The latest Google Maps code (I've been experimenting with maps.keyhole.1.js) includes some interesting methods: getLatLng, getTileURL, getBitmapCoordinate, and others. (It's worth mentioning here that I don't know Javascript, so my hack is probably even uglier than I think.) The Google code defines a "SPEC" for the map and keyhole data types, and then defines these methods independently for each. That is, the implementation of getBitmapCoordinate() for Keyhole images is very different from that for the street maps.

So all I have to do is create a new spec, and rewrite those functions accordingly. Should be easy, right?

Unfortunately, it's not as easy as I'd hoped. While Google uses its own methods of addressing tiles, they're fairly simple and easily derived from standard Latitude / Longitude coordinates. Terraserver, however, uses UTM, the Universal Tranverse Mercator system. Which isn't too bad in and of itself, except that now I've got to locate some Javascript (which, remember, I don't really know) to convert Lat/Lon to UTM.

I eventually found something that seemed to work. Then I had to worry about pixels-per-degree, which is hardcoded in Google's interface but was an unknown for Terraserver's images. In fact, I'm still not sure I've got that right, but it seems to be working, more or less, so I'm not futzing with it for now.

I did some quick hacking to Google's street map code, mostly just inserting a UTM converstion step in the getTileURL function, and it worked! Well, okay, not completely. And certainly not the first time out. Tiles didn't seem to get fetched properly, but interestingly, it was a consistent problem. There'd be a whole row of tiles skipped, or shifted left one block, and then that discontinuity would change when I zoomed to a diffferent level, but return in the same place when I zoomed back. So I started to suspect the UTM algorithm I'd found.

I eventually found another algorithm, written in FORTRAN, converted to C, and converted again to Perl. But rather than fighting to convert that to Javascript, I decided to try a different approach. Instead of keeping Google's bitmap-level coordinates and converting at the last moment, I tried converting to UTM right up front, and using UTM-based bitmap coordinates throughout.

Wow! Much better! All the rows are properly continuous, at all zoom levels! But....the vertical is messed up. Each row, as I went up, was instead the row that should've been seen moving down. Hm. Maybe Google expects all coordinate systems to be negative northward, and positive as you move south. Change a sign...and...Presto! The maps work! I just had to put one more fix in to accomodate the fact that terraserver tiles are referenced from the lower corner, while Google expects them referenced from the top, and now everything's working great.

So can we see a demo, you ask? Here ya go. This is the "Zero Milestone," just outside the White House in Washington, DC. When the map comes up, zoom in a couple of times (hitting "+" on the map zoom bar), and you should see the Google marker sitting right in the milestone box on the topographic map. Then you can switch between the Topo, the B&W, and the Urban photos pretty seamlessly. Naturally, you can also see Google's two image types, and scroll around and everything.

You can find my additions to the Google code here. I've tried to comment it, but I'll run through some of it here, because I'm sure it's not clear.

Also, I'm using a slightly-hacked up version of the Google Maps Standalone Mode in order to make this work from my own site. Ideally, this would be moved out of hacked Google code and into its own file that gets pre-loaded by the standalone code, but I'll leave that as an exercise for the reader.

Essentially, the TerraServer tiles are addressed by UTM coordinates: Northing, Easting, and Zone. For example, the Zero Milestone (in the demo above) is at 38.8951 N, 77.0365 W. Converted to UTM coordinates, it's at Northing 4307107, Easting 323388, Zone 18S. The Zone represents the 18th 6-degree-wide zone, moving eastwards from -180 Longitude. It covers, roughly, -72 to -78 degrees. (The "S" further isolates it to a particular range of lattitudes, but that doesn't factor into TerraServer's system). Easting 323388 means that it's 323.388 KM east of the reference meridian (again, about -78 degrees), while Northing 4307107 means it's 4,307.107 KM north of the equator. More or less.

Anyway, that gives you an absolute location on the planet. To figure out which TerraServer tile covers that location, we simpy divide down by the resolution of each tile at the selected zoom level, and then divide again by the tile size. For zoom level 4, and tiles 200 pixels square, we get y=5383, x=404. TerraServer's zoom level runs from 8 to 16, so I have to convert the Google zoom level by adding 8. Finally, I have to select a particular image tile type: 1 for old black and white images, 2 for topographic maps, and 4 for USGS Urban overheads. This all gives me the following URL: http://terraserver-usa.com/tile.ashx?t=2&s=12&x=404&y=5383&z=18. Which, as you can see, includes my target right near the top. Very cool.

Most of the rest is simply trying to work with UTM-based bitmap coordinates within the Google map system. Unfortunately, there's no way to track the UTM zone within Google's code, so I have to do some hand-waving. I use, to create an X-coordinate for the bitmap, the target coordinate's Easting value, but with the zone level prepended in the millions. That is, for zone 18, I add 17,000,000 to the Easting value. Then it gets divided down by resolution, and the result is a master bitmap coordinate. This gets squirrely when you get near the edge of a UTM zone, but that's already pretty messed up anyway. Plus, I don't live near a boundary, so for my purposes, well, I don't really care. :)

Finally, I had to add my new variables (representing each map type) to a master array within the Google Maps code so that they'd show up as an option.

It's not perfect. Aside from problems near the UTM zone boundaries, there's a nagging imperfection with markers at zoom level 6 and above, where they end up being somewhat off. But consistently off, so I'm sure there's some assumption or code problem here. Also, if you move the map, then zoom in, the zoom isn't centered on the marker as it should be -- it tends to veer southwards. Still, it's working for my purposes, and as I said, I really am not a Javascript hacker, so I'll leave cleaning this up to smarter people than I. Besides, I'm sure that this'll get integrated directly into Google just as soon as they can get all the Topo maps scanned themselves.

Someone's hacked a totally custom map into Google (Chicago Transit Authority maps) and he's used a Greasemonkey script to integrate it directly into the regular maps.google.com map. If you've got Greasemonkey installed (on Mozilla), then right-click on this script: topo_monkey.user.js, and select "Install user script".

Then, reload Google Maps, and you should see some new options (Terra, Topo, and Urban) appear next to Map and Satellite. I've noticed that the markers are even more off now, and I'm not sure why, but at least you can browse....

Further updates: I've fixed the marker-off problem at more distant zoom levels. I haven't figured out why it works, but it does (that is, I've identified a pattern, just not an algorithm to base the pattern on). Still, at least now the marker is properly placed everywhere. I've also aligned the zoom levels for Topo and B&W images, so that when you switch among those and the Google images, they're all at the same zoom level. I can't do that with the Urban overheads, because they actually get closer than the interface allows for. I've made the fixes to the demo on this page, and my Greasemonkey script, but haven't updated the documented changes file. Maybe later tonight...