This made it somewhat tedious to decode them, as the only way to get the original list of points was to create a GPolyline and then pull out the points from that object. This is not ideal since the work must always be done on the client side with JavaScript and using Google Maps.

To solve this, I quickly ported the algorithm over to PHP from the JavaScript source. Please feel free to download/modify/use this script.

Since the encoded polyline format offers numerous benefits (and because I had data already stored in this format) I did not want to move away from it. At the same time, I needed access to the points for working with things like Google Static Maps, which curiously does not accept the encoded polyline format for displaying paths. (Probably to reduce resource usage on their end, since decoding takes CPU time)

Thankfully the polyline decoding algorithm was already available at Mark McClure’s site. I spent a few minutes understanding the process and porting it over to PHP. The source is attached above and is released under an MIT license. Basically, the only change I had to make was to use some PHP functions to convert characters to their ASCII code, since PHP doesn’t have a charCodeAt() function.

Please let me know if you find it to be useful.

I’ve just launched RunTrackr. It’s a site where you can create a running route in order to track, among other things, distances. It’s designed to be a tool to aid anyone who runs/jogs a lot, either recreationally or for training. A training log is also provided so that you can easily keep track of your running records and record your progress during training or just to watch your personal improvement.

Here’s a quick overview of what’s possible with RunTrackr as well as what we have in store for the future in terms of improvements to the site.

Adding/Creating a route

Creating a route probably the main reason you’d want to use RunTrackr. By creating a running route, you can measure its distance and keep track of it in your training log every time you run it.

Plotting a route is very easy; all you need to do is enter your location (Eg. “Belleville, ON”) and then click to add points. Existing points can be dragged around to alter the route. When you’re done, just click “Save Route” to finalize! You can also choose to enter a short description, tag your route with descriptive labels or rate your route’s difficulty.

Later on, I plan to add support for uploading automatically-generated routes/plots from GPS devices like those from Garmin, et al. This will make adding routes even easier for those who have access to such devices.

Searching for routes

Searching for routes is a great way to find running routes in your area submitted by other people. Simply enter a location and click “Search”.

If any routes are found, their location will show up on the map as markers and in the sidebar listing. Clicking on one brings up a preview of what the route looks like; clicking the preview image takes you to a full-sized view where you can see other statistics about the route.

Viewing routes

Going to the full view of a route brings up all of its details, such as the distance, description and any tags. You can also choose to add a route to your “Favourites” so that you can easily keep track of it in your Training Log.

Training Log

The Training Log allows you to keep track of the routes you’ve run and provides an easy way to record your progress. Here, each time you’ve run a route you can enter how long it took along with any other comments about the run. Calories burnt are automatically calculated based on an approximation that takes into account your weight and the distance.

The training log is very basic at this point and several improvements will be forthcoming, such as weekly/monthly/cumulative totals as with as some other statistics and graphics like charts and graphs. (Because everyone, myself included, loves colourful pictures)

Summing it up

Registration is optional but takes less than a minute and allows you to use fully use the service. We’ll be rolling out more features as times goes on. I regret not being able to launch this site earlier in the year (when the weather was starting to get nicer and people starting to get out more) but sometimes that’s just how things turn out.

As always, I welcome all feedback about RunTrackr, including any suggestions you might have about how to improve the service! In the meantime, please check out the site if you’re interested and enjoy your time there.

I’ve just starting playing around with the Google Static Maps API as a complement to the regular Google Maps API, which as you probably know, is for JavaScript. The Static Maps API, on the other hand, provides a way to display static map images. This is useful in situations where you just need a non-interactive map and don’t want the overhead of an Ajax/JavaScript-based one.

However, I ran into some minor problems related to the API key usage with the Static Maps. Basically, an API key is tied to a certain domain name so that Google can keep track of your site’s usage. This means that the API key is tied to the domain name of the web site where you’re using the Google Maps API.

As in most development situations, I maintain a production server (with a real domain name) and a test/sandbox/development machine, which is just running off of my localhost. Thus, I had to get two API keys - one for the real domain name, and one for localhost and then switch between the two depending on the host name. (In PHP it’s fairly easy to check, using something like $_SERVER['SERVER_NAME'])

However, with the regular JavaScript-based Google Maps, it appears that if you’re running off of localhost (not 127.0.0.1) the service doesn’t check if you have a valid API key - this was probably done because many people are probably running test servers off of localhost and trying enforce usage limits would be counter-productive. (You do, however, need to have a valid API key - even if it doesn’t match localhost - if you want to use GClientGeocoder to resolve locations)

Because of this, at one point or another, I decided just to stick with using the production API key in all situations; after all, things continued to work even on the development server and in general, I don’t like making changes just for testing purposes.

This ended up causing problems when I started using the Static Maps API though. It turns out that this API does require you to have a valid API key matched to the host name in all circumstances, even if it’s localhost. This, of course, is the proper behaviour, but it differs somewhat from the behaviour of the standards Google Maps API.

Guess it pays to be correct in all situations, even if you don’t need to be!

I’ve been playing around with the Google Maps API for a bit and it’s turned out to be a great way to get started with “mashups” and the like. One of the best uses of the API is the ability to create paths or routes on the map.

This is done by creating GPolyline object and then adding it as an overlay to the map. Basically, a polyline is just an ordered list of geographical points/coordinates on the map, each of which is a GLatLng object. For serialization/storage of polylines, there is an algorithm you can use to Base64-encode a series of points; the resultant string can later be passed directly into a factory method to regenerate the GPolyline. By using encoded polylines, you also get access to a few more interesting and useful options related to rendering and performance issues.

Encoded Polylines

Despite the algorithm for encoding polylines being readily available on the Google Maps API documentation site, there is no built-in functionality within the API for generating the encoded polyline string from an existing GPolyline object. This might be a bit strange, but it’s probably because the encoding process requires some extra values that aren’t available in the typical polyline.

As specified on the algorithm page, you also need to specify a list of encoded “levels” in addition to the points themselves. These levels tell the the Google Maps renderer when certain points can be omitted from the polyline depending on the zoom level. For example, with a polyline with n points, you’ll always want to show the first and last point, no matter what the zoom level. However, intermediate points can potentially be omitted at low zoom levels and only shown when the map has been sufficiently zoomed in to warrant the detail. This sort of optimization cannot be done with the typical GPolyline constructor that just takes an array of points. (GLatLng objects)

Making things easy

If you’ve looked at the polyline encoding algorithm, you’ll probably notice that it’s a bit tricky unless you’ve taken course in CS or done a lot of this stuff before. (At least it was tricky for me) Google has an interactive utility for generating the encoded polyline format for you. The results can then be stored and later fed into a call to the factory method GPolyline.fromEncoded() to regenerate the polyline.

However if you want to generate the encoded polyline format on-the-fly as part of your application, the interactive utility is not really an option. Instead of coding the algorithm from the ground-up, there’s a much better way of doing things, thanks to the PolylineEncoder class and other utilities provided by Mark McClure.

The PolylineEncoder class is written in JavaScript and is very straightforward in its usage. (It has been ported to several other languages as listed on his site, in case you need to use it in different contexts)

Using this class allows you to quickly and easily convert a GPolyline into a compact encoded format useful for serialization or storage. You can also use the class to convert arrays of points into encoded polylines, thus gaining the benefit of optimized rendering at different zoom levels. McClure goes into an in-depth, but easy to understand explanation of the encoding algorithm used complete with animations that show exactly how the polyline approximations work.

I highly recommend the usage of his polyline encoder as it saves you the headache of implementing it yourself. It’s well-written, thoroughly documented and is free for usage. (It isn’t licensed under open-source terms but has instead been placed in the public domain - which is perhaps even more “free”) McClure also has a few other interesing Google Maps projects that you may want to check out.

Some documentation warnings

The Google Maps API documentation is fairly thorough, but it’s out of date in some places, as some people have found. Indeed, in this case, it appears that the GPolyline.fromEncoded() is documented somewhat wrongly in the API reference, though curiously, is used properly in their examples page.

Specifically, you should not use:

GPolyline.fromEncoded(color?,  weight?,  opacity?,  latlngs,  zoomFactor,  levels,  numLevels)

if you want to generate a polyline from the encoded format. Instead, you should use something like:

GPolyline.fromEncoded({
    color: "#FF0000",
    weight: 10,
    points: "yzocFzynhVq}@n}@o}@nzD",
    levels: "BBB",
    zoomFactor: 32,
    numLevels: 4
});

This is because the API has been updated to accept an object of options instead of separate parameters. This, in my opinion, is better for readability and takes advantage of JavaScript’s ability to define inline anonymous object literals.

As a side note, the example actually calls something like new GPolyline.fromEncoded, but I’ve found that you don’t need the new keyword, and in fact, it’s a bit confusing that the example has it and that it would work - after all, you are calling a factory method that returns a type of GPolyline, and not directly instantiating an object. (At least as far as JavaScript uses the new keyword)

If you do a lot of running, you’ll often find that you’d like to keep track of how much distance you’ve accumulated. This is especially important if you’re training for some event, or even if you’re just a casual runner looking to build up your endurance and stay in shape. However, short of running around a track endlessly, it can be hard to gauge how far you’ve gone on your running route.

Short of having a fancy device such as the Nike iPod Kit (which requires calibration), or an even more costly GPS watch (that’ll probably eat through batteries), you can still manually measure your running distance using the many free tools out there, all of which are based upon the fantastic Google Maps API. Let’s have a look at some of them.

Gmaps Pedometer

Gmaps Pedometer was one of the first distance-logging tools created using the Google Maps API. It works well for tracking running/biking routes, and includes a calorie counter based on your weight, as well as some rudimentary elevation information. However, the interface is somewhat bland, and this app doesn’t include some of the features found on some other routes, such as a central repository of user-created running routes integrated with the main app. You can save your running route, however, and users have shared their creations in their forums. No registration is required (or available) for this site. You can easily print maps from within the interface.

Overall, it’s an simple, but effective and easy way to track your distance. It’s somewhat plain though, and a little lacking on features. You also have to enter each point manually, since there’s no option to follow roads. So, if your path goes down a curved boulevard, you’ll have to click along each point to keep the distance accurate, since the path just follows straight lines between each point.

WalkJogRun

WalkJogRun is an application that has a large number of user-created running routes integrated with the map. You can find routes near your location simply by searching for your city; markers will then show up on the map indicating where these running routes are. Clicking on a marker will bring the running route onto the map as an overlay, along with distance measurements for each point along the route. Zooming the map can be done with the mouse wheel, just like in the regular Google Maps.

Times are also included, and are in hours:minutes, and are based on a speed you select. You can configure the distance/speed measurements to be in kilometers or miles (I still like miles, despite being raised metric for everything), and a calorie-counter based on your weight is also included. These options are at the bottom of the screen, and are fairly small, and could be relocated for better visibility.

You can also create your own route by double clicking to enter points. Creating running routes and saving them doesn’t require you to register, but you can, and have to, if you want to mark them as private or be able to come back and alter them later. This seems fair enough, and it’s good that they don’t force you to register to use the service. Also, it’s very nice to be able to see/search for other people’s routes right within the application. Overall, the interface of WalkJogRun seems quite refined, and is fairly easy to use. There are plenty of features, and you can even export routes to Google Earth.

However, one thing to note is that this application feels somewhat sluggish. This is no doubt due to the heavy use of the Google API and the resulting number of Ajax queries that must take place, in order to update the map with users’ routes as you reposition it. This is in stark contrast to Gmaps Pedometer, which while simple and plain, is also faster and more lightweight. I suppose it’s a trade off. And, like Gmaps, WalkJogRun doesn’t support a “follow by road” feature, so entering in paths down curved roads will take more time.

MapMyRun

MapMyRun is like WalkJogRun in that you can search for user-created running routes and also add your own to the mix, and it also has a fairly decent interface that shows information in both kilometers and miles. It has the nice feature that auto-saves your route, and restores it should you accidentally navigate away from the page. It also also gives calorie counts, and supports elevation data as well. You can save this information to a training log, but this requires that you register with the site.

When creating routes, you can specify different types of waypoints, for example water breaks, aid stations and bathrooms. Notes can be added to the waypoints, and the route can be printed out with these notes to keep them handy. This is very nice for operation in the real-world. You can export the route to a variety of sources, such as Google Earth, a Garmin Forerunner or Edge GPS device, or to your blog as some embedded Javascript. This is also very handy, as information nowadays should work across a variety of devices.

However, the best feature is that this application can automatically create paths that follow roads. This is good if your routes follow through a lot of curved roadways, as it’ll save you the headache of manually entering in the path. However, sometimes it’ll automatically create a path from one point to another that doesn’t follow the road route you’d probably run - this is a limitation of the Google Maps system, as it is probably calculating how a car would drive from one point to another. (For example, you can run either way down a one-way street, but cars obviously cannot) Another nice feature is being able to remove a point in the middle of your route without having to re-enter all the subsequent points.

While this application is feature-filled, it also suffers from some sluggish performance like WalkJogRun.

Run.com

With Run.com’s application, you can also search for user-created running routes and add your own. The application is fairly responsive, and doesn’t feel too sluggish because of the way they’ve implemented it - searching for routes shows them on one map, and when you click a route to bring it up, it loads a new page with the route map. This reduces Ajax-activity that is often the cause of poor performance in web applications.

Routes show elevations, and distances in metric or imperial. Different waypoints (water break, aid station, scenic view) can be specified, and users can enter descriptions as well as difficulty ratings for each route. Tips entered by the person who created the route are often useful. (Eg. BE CAREFUL - LOTS OF BIKES)

Though I don’t have much to say about this application, I actually think I like it the best. Even though it doesn’t provide all the data or features that WalkJogRun or MapMyRun might, it’s lightweight, fast and easy to use, all of which are important hallmarks of any application, especially web apps.

One last thing

You don’t need to use one of these tools to measure your running distance. You could easily use Google Earth’s measure tool to map out your running route, but it’s a bit tedious, and these online applications will greatly simplify the process. Personally, I liked WalkJogRun and Run.com’s offerings the best, but you should give them all a try to see which fits your style best.

Lastly, these tools are probably best for road running, such as planning training for a marathon of some sort, or for the marathon itself. If you do a lot of trail running, they won’t work that great, since most of that data isn’t available on Google Maps, the basis for all of these tools. However, these tools do a good job of highlighting the features and flexibility of the Google Maps API by showing what can be accomplished.

Google Street View has been out for some time now, and its proven to be a pretty nifty feature. Basically, Google has sent out teams of people in vans with cameras mounted on the tops to major cities across the US. They’ve been able to capture 360-degree panoramic views of most of the streets in these cities, so you can view the surrounding area on almost any point in the street. This is obviously a great feature for people who find that maps don’t provide the best experience of “getting to know a place”. With Street View, you get the best experience of seeing what a new place will be like, short of actually visiting it. It’ll be great for visitors. Google hopes to extend to feature to more cities as time goes on.

However, the new feature has obviously raised some privacy concerns, but perhaps not in the strictest legal sense. Since Google has taken these pictures from public areas, they’re probably in the clear. However, they is somewhat of a difference when these public pictures are being integrated into the largest search engine for everyone to see.

Precedent

This isn’t first service that’s offered street views. Microsoft has also offered their own limited service, and as one blogger pointed out over a year ago, it would be cool if Google did the same. However, as pointed out in this article, Google Street Views are far more detailed and interactive. In addition to being able to rotate the view a full 360 degrees, you can zoom in. The level of quality in most pictures is quite good, so zooming actually produces good results, rather than just a larger blurry section of an image. You can easily see way down the street by zooming.

Privacy

However, this has also raised what some have called “privacy concerns” - not in the “NSA wiretapping” sense, but rather in the “it’s freaky” sense. A list was quickly formed for the most intriguing Street View sightings, and people also found one of a guy digging for gold. In another more innocent list, we can see Steve Jobs’ Mercedes. In many of these images, you can easily see the faces of those involved. Now, while it’s true that you could have easily seen all of this yourself going for a stroll down the street, it’s somewhat different when a picture is taken and put onto one of the most popular search engine maps for all to see.

Google has provided some recourse, though. If there’s an offending image, you can submit a complaint to have it removed. Indeed, some of the more racier images have been removed; however, while they’re no longer on Google Maps, they’ve forever been immortalized on the various blogs and forums that have covered this topic.

A big deal?

Now, don’t get me wrong. I don’t think this is a major breach of privacy, but if a government had done this, do you think people would respond differently? I think it’s great that Google is trying to improve their search and map functions through this “information fusion”. Once it expands to more cities, it’ll definitely help people like me who get lost easily. Being able to see and identify with a place before going there will be a huge aid. Who knows, once they roll out holographic monitors, I may not even have to save up for that trip around the world…