Back on November 2nd, the City of Toronto launched their toronto.ca/open service – a project aimed to be the “official data set catalogue” of the city. Part of the OpenTO initiative to make various data that the city has collected available to developers in formats that make them easy to manipulate, toronto.ca/open is the first step to making the city and its services more “open and accessible”.

The hope is that if the city makes this information available in a readily-usable form, developers will take the time to create various services around them, helping citizens enjoy and take advantage of what Toronto has to offer. For example, data on garbage collection, public transit or upcoming city events could be used to create a service that would alert users through various means of communication. But at present, the amount and types of data available are fairly limited.

Announced back in April at the Mesh Conference in Toronto by Mayor David Miller, the openness initiative had a lot to live up to in the half-year following up to its release earlier this month at the Toronto Innovation Showcase.

Several cities have already implemented similar projects, leaving Toronto to play catch-up. Vancouver, for example, launched their own Open Data initiative earlier this year, and Toronto’s data catalogue appears to be modeled after it. Edmonton, a much smaller and less dense city than Toronto, has also recently begun an initiative to open their city’s data to the public in a similar manner, with promising results.

But the data is better late than never, so I applaud the City’s effort to democratize and help keep citizens better informed.

The data itself

Looking at what’s offered, you can see that most of the data sets or services have a geographical component to them. This only makes sense, as hyperlocal information is always of great interest to most people.

The data is presented in a variety of formats, but the most popular seems to be an ESRI Shapefile, a file format used by a popular suite of GIS software. With much of the data having a geospatial aspect to them, this makes sense as the data likely didn’t require much conversion before being released by the City. (I.E., they probably use ESRI’s application for city planning, etc.)

Thankfully, the format has been well-documented by its developer, and Wikipedia as well. All of these ESRI Shapefiles are intended to be downloaded for offline use, as they are typically made available inside of a zip file. Thus, the process of keeping them up to date may prove tedious, though I’m sure an enterprising developer could automate it nicely.

Other data has been made available in various XML formats. Some are intended to be accessed as online services, with a link to the XML document and the corresponding XSD file, while at least one is presumably meant to be used offline since it’s zipped up. Some of the XML “Feeds” are also in a format without a defined schema and are not RSS or Atom feeds. For example, the feed of City-sponsored events would be better served by an RSS or Atom feed, which would not only allow developers to integrate it into an application, but also regular users to sign up to the feed using any newsreader.

There are also some web services explicitly offered. The first is a geocoder service that can be used to validate addresses and other place names within the City. It is a WSDL service, and there is a full PDF file to document the input parameters and expected output.

The second is a series of services that provide access to “live geospatial data from the City of Toronto“. These are all Web Map Services that conform to a protocol specification developed by the Open Geospatial Consortium. It would have been nice if they had linked to the WMS Specification (PDF document) that explained how to query the services, instead of forcing you to find out the information yourself. (See page 14 and onwards of the mentioned document)

Lastly, some of the data is offered in plain old text files. In particular, the TTC Routes and Schedules is only available as a series of zipped text files that are periodically updated, presumably manually. This may be a bit backwards, but thankfully the formatting is well-defined.

Drawbacks

Though it may not be fair to criticize at this point, there are some clear limitations to the data. Firstly, much of the data is intended to be downloaded and then used in an “offline” capacity, that is, without further communication between the application and the City’s servers that host the data. Though this was probably done due to technical limitations (i.e. reducing bandwidth usage), it limits the ability of an application to stay up to date with the latest data. For things like the TTC Route and Schedules and the list of Apartment Bylaw Infractions, this severely reduced their effectiveness as the data will likely need to be periodically manually updated.

Furthermore, the current data set is somewhat limited and may impede the usefulness of any applications or services that can be developed. For example, making real-time TTC updates and other data available would be an immense benefit, yet the only TTC data currently available are in zipped text files that are only periodically updated. Thankfully, the City has setup a site to allow users to request more data, and there are already many requests for more TTC data.

It would also be nice if crime statistics for Toronto could be made available in an easy to use format. In particular, the underlying data used by the TPS to produce their crime maps and statistics could be beneficial in developing all sorts of interesting maps. In fact, this is what the Toronto Star has been doing for some time, but they had to get the data through an explicit request under access-to-information legislation. Since then, they’ve produced some very interesting maps and it would be beneficial if everyone had access to the same data so that the maps could be improved upon and kept up to date.

Producing such crime-based maps can provide people with one more factor to help them determine what part of the City they’d like to live in, or just allow them to have access to accurate statistics on crime. Not all of this is negative – as any study of crime in Toronto will show that it’s been following a downward trend for quite some time, so such information could help ward off any potential negative spin that media may put on crime. However, I do realize the privacy implications that come with releasing such data, so time should be taken to ensure that it is released in a manner where anonymity is preserved as best as possible.

Lastly, it’s important to note that the OpenTO initiative is still at a very early stage. Even with the way things move at City Hall, things will eventually improve. It’s also very important to give your feedback, either at DataTO or directly by email to opendata@toronto.ca. Additionally, if you’re a developer, the corresponding Google Group is a good place to get started. Even with the current limitations, I am sure we’ll see some great applications developed based on the data. One need only to look at MyTTC to see what can be done with some effort and ingenuity – and this was done well before the City officially released any data!

After much delay, possibly due to government meddling, Google Street View finally went live in select Canadian cities last week! Most of the GTA is covered, along with Kitchener/Waterloo, Ottawa, Montreal, Quebec City, Halifax, Calgary and Vancouver. This likely ensures coverage for a majority of Canada’s population, if only a very small minority of its geographical area.

This is a welcome move, since street view has been available for our neighbours to the south for the past two years.

According to some reports, Street View was supposed to launch in Canada earlier this year, and some of the imagery was collected as early as 2007. (Though the images around my area seem to be from early this year) Oh well, this is better late than never!

I’m speculating that the government’s concern with Google Street View may have slowed deployment, as in 2007 the privacy commissioner voiced strong concerns against the technology. I’ve never believed any of that FUD, but it seems that their concerns have been addressed with Google’s automatic detection and blurring of faces and license plates, along with new straightforwards processes to request that your image be removed from the service.

But it’s still been much ado about nothing, not really like the conflict between the government and Facebook earlier this year, which was also subsequently resolved. In the case with Facebook, privacy settings were often complicated and unclear; with Google Street view, they’re merely providing public views of public places, so I don’t see what the problem with that is.

Also available on the iPhone/iPod Touch

You can also use Street View on the built in Maps app for the iPhone OS, though it’s a bit convoluted since there’s no “Street View” button to toggle. Instead, you must first drop a pin (click on the “layer peel back” icon in the lower right corner) and then bring up the dialog box for that pin. If it’s in an area with Street View present, the little guy icon on the left will be lit up and you should be able to click it to bring up Street View.

Street View only works in landscape mode but it’s still pretty useful for getting to know an area before you visit it for the first time. Sometimes an actual image can convey sense better than just a map.

Competition?

It remains to be seen how the launch of Street View in Canada will fare for the similar service launched by Canpages in BC. That service only covers Vancouver, Whistler and Squamish but was launched back in March.

Nonetheless, it’s very neat technology, even if it was originally unveiled over two years ago. Witness this by the fact that reporters are still drooling over it by embedding the service in every article covering the launch.

Motivation and Usage

There are numerous reasons for using the user’s location to improve the quality of a service. For example, the restaurant guide and review site, Restaurantica, automatically makes a guess as to your location and populates the “Search” field so that you are one click away from finding information tailored to your geographic area.

This determination is based on the user’s IP address. Usually, the lookup is done based on a static set of mappings from IP addresses to geographical locations, like cities. In fact, this is exactly what the IP address geolocation database (that we’ll use) does. It has the advantage of being easy to understand but unfortunately the accuracy can degrade over time, as IP addresses are usually not hardwired to specific locations. For example, most DSL users are subject to DHCP, so the same IP address may be re-used across different cities. (The IP address database from IPInfoDB is updated periodically to help reduce this inaccuracy)

Thus, you should not rely on the information provided to be 100% accurate; it should only be used as a suggestion. This is why Restaurantica only populates the search field with your estimated location, rather than giving you the results for that location right away; if it was wrong, the results for a different location would certainly be confusing to a user. This gives the user a chance to correct any inaccurate lookups.

Using the IP Address geolocation database

The first step is to download the database and import it into your local database; for this example I’ll use MySQL. Note that the site also offers an IP location Lookup API, which has the advantage of not requiring a local database but may be subject to usage limits; if you’ll be getting a lot of traffic you’ll be better off using the local database.

Import the contents into MySQL

I downloaded the Complete (City) database as one table in SQL format. Extracting the file from the archive, you’ll see that it’s well over 300 MB in size. If you’re fond of using phpMyAdmin, you unfortunately won’t be able to import such a large file using that tool, so we’ll have to rely on the command line to import the contents. Go to your mysql/bin folder and enter the following command, assuming you extracted the SQL file to the same location:

mysql -u root -p [name of database] < ipinfodb_one_table_full.sql

Running this command will take some time, as it won’t be fast having to import such a huge table. Take a break and come back in a few minutes. (You may want to create a new database to hold just this table, do that before running this command) After that’s done, you should be able to see the contents in phpMyAdmin, like below:

Using the database

Querying the database is straightforward, and the IP Info DB website has plenty of examples at the bottom of the download page. Basically, once you have the user’s IP, you can use a query like this to find the most likely city it originated from:

SELECT *
FROM `ip_group_city`
WHERE `ip_start` <= INET_ATON([ip address as a string])
ORDER BY ip_start DESC
LIMIT 1;

The INET_ATON function converts a string that is the dotted-quad octet form of an IP address (the form you’re most used to seeing) into a 32-bit unsigned integer. This integer is then used to locate the record that most likely corresponds to the geographical location. The database is structured such that row with the highest ip_start value not greater than the given IP address is deemed to be the most likely location.

An example:

SELECT * FROM `ip_group_city` WHERE `ip_start` <= INET_ATON('69.156.150.155') ORDER BY ip_start DESC limit 1;

(This returns the city of Toronto, Ontario, Canada) If you want to get a list of likely locations, just increase the LIMIT argument to something like 10, and this will return 10 locations that are likely close to where the IP address is located. Note that there may be duplicates in this list.

A simple example

Here’s a simple PHP script that takes the user’s IP address and displays their most likely location on a map using the Google Static Maps API.

<?php
$ipGeolocationDatabaseName = 'ip_geolocation';

$link = mysql_connect('localhost', 'root', '');
$ipAddress = mysql_real_escape_string($_SERVER['REMOTE_ADDR']);

echo $ipAddress;

mysql_select_db($ipGeolocationDatabaseName, $link);

$query = "SELECT * FROM `ip_group_city` " .
         "WHERE `ip_start` <= INET_ATON( '$ipAddress' ) " .
         "ORDER BY ip_start DESC " .
         "LIMIT 1";
$resultLocation = mysql_query($query);

$numRows = mysql_num_rows($resultLocation);

if (0 == $numRows)
{
  echo "No likely locations found.";
}

while ($row = mysql_fetch_array($resultLocation))
{
  echo "<pre>";
  print_r($row);
  echo "</pre>";

  $lat = urlencode($row['latitude']);
  $lng = urlencode($row['longitude']);
  if (!empty($lat) && !empty($lng))
  {
    // NOTE: Replace the `key` parameter with your own, obtained from:
    // http://code.google.com/apis/maps/signup.html
    // (The one in use is only good for URLs on `localhost`)
    $queryString = "center=$lat,$lng";
    $queryString .= "&zoom=10";
    $queryString .= "&size=300x300";
    $queryString .= "&markers=$lat,$lng,blue";
    $queryString .= "&key=ABQIAAAAicCf6MqoHlR-MsfivtVWPRT2yXp_ZAY8_ufC3CFXhHIE1NvwkxTNmqRdvnM9orG9QdyALHoUZfmFuQ";
    $queryString .= "&sensor=false";

    echo '<img src="http://maps.google.com/staticmap?' . htmlentities($queryString) . '" alt="location" />';
  }
}
?>

Here’s what it display for my IP address:

As you can see, it’s not always accurate, but it’s a good start to enhancing your website to offer localized services and features.

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.

Projects using this

• VORG Tool

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…