Maps Hacking (volume 2)

The other weekend I spent some time hacking together an HTML map view of my GPS running data using the Yahoo! Maps API. One thing I wanted to do was to try doing the same thing using the Google Maps API. Inspired once again to fiddle, I copied over the HTML file and tweaked it to use Google’s API.

There’s two primary reasons I wanted to try out the Google API:

  1. Polylines. Google’s API will let me hand it a list of latitude and longitude coordinates and it will turn them into a nice line. The Yahoo! version I did had to plot a ton of points, which resembled a line. The Google version actually draws a nice line. As long as you have enough data points, you’ll get smooth turns as well.
  2. Satellite imagery. For most people, maps don’t need satellite imagery. Having a list of the streets is enough. But around my house and my work there’s a lot of trails to run on. In the Yahoo! version of my maps, you’d see me off running in the middle of nowhere. The thumbnail (click it for a larger view) shows one of those instances where I was off running in the Bay Area marshes. On the Yahoo! version, you have no idea where I’m at. But on the Google version with the satellite imagery, you can clearly see I’m running on a trail around what appear to be salt ponds.

The verdict? See for yourself. There’s no comparison. The Google polyline looks SO much better than the points plotted on the Yahoo! map. And the satellite imagery makes it easy to see trails off the beaten path. This could actually be really nice for annotating all of the bike trails in Folsom.

The Google API isn’t perfect, though. I had to trim down the number of points I used for the polyline. My longer runs have a ton of points (my 7 mile run has over 700 points). That’s simply WAY too many for GPolyline to handle (on my machine anyway). I’m currently triming the list down size by only plotting every third point. I tried plotting all of them and even only half of them, both caused my browser to choke and to pop up the “this script is taking too long” dialog box. Still, with a third of the points I’m able to get relatively smooth lines and curves.

There’s some things I also just don’t like about the Google API. The restrictive key signup is kind of a pain. You sign up for an API key with the URL of the site you’re going to use it on. From there on out, that API key will only work with pages served from that site. It’s not that it’s hard to do that, but if I ever move my stuff off of beta.unclehulka.com to unclehulka.com, I’ll have to get another key and change it in my code. I also had to do some stuff in the HTML to make the polyline work properly in IE. Again, not terribly difficult, just a pain in the butt to have to remember (although really, I probably can’t blame this on Google…it’s an IE-ism).

In all, I think the Google Maps API is much better than the Yahoo! Maps API. Polylines are simply a must-have item for doing the kinds of things I’m doing with maps. And if you’re going to do anything involving areas that aren’t on streets or highways, you need the satellite imagery.

8 Responses to “Maps Hacking (volume 2)”

  1. notes » Blog Archive » Simplifying GPS data to plot polylines Says:

    [...] I was reading Ryan’s post about Google Maps and could not resist hacking together a relatively simpleminded track simplifying script. [...]

  2. Jeffrey McManus Says:

    *snif*

  3. Ed Kohler Says:

    Very cool. What kind of applications do you think lines will have on web based maps? Driving directions, of course, is being done today, but I haven’t seen many other line based applications yet.

  4. runningblogger Says:

    Hey Ryan- nice work. It looks like there are a few of us doing very similar projects. Have you made more enhancements since this post? FYI, I am working on a very similar site, at http://www.runningblogger.com . I am working a web app that will allow users to store, parse and view their entire forerunner history on google maps and more. I’ll be looking for beta testers soon, so let me know if you’d be interested in trying it out.

  5. Greg Says:

    You might want to check out http://www.motionbased.com/ as well. They have some similar functionality that works pretty well to pull route data from a GPS (though the UI could definitely use some usability improvements, IMO).

  6. Ryan Says:

    Yep, I’ve used MotionBased before. It’s neat, but it didn’t satisfy my hacking itch. ;)

  7. scott Says:

    What datum are you using in your GPS unit to collect location points. Do you know what type of map projection or datum works best with Google maps?

    What do you think is an optimum number of points to have per mile? I’m sure this depends on the number of turns, but a ballpark figure would be nice to know.

  8. Ryan Says:

    I’m using the latitude and longitude off of the GPS. Basically I take consecutive points to come up with headings and then I check for massive heading changes. If the heading change between two points is negligible, I don’t plot the last point. Basically I drop anything that doesn’t look like it contributes to smoothing out a curve.

    Instead of thinking of it in terms of points per mile, I think of it as how many degrees can the heading deflect before I start plotting more points to ensure the curve is smooth.

Leave a Reply