Kusam Klimb + GPS Watch + Google Earth = Kool

Please understand that an insane mountain challenge like the Kusam Klimb is about as far away from how I’d choose to spend my weekends as…. well… anything. Fortunately one of my co-workers, Ross Collicutt, is both a sports nut and a tech geek.

Jason Gut

Me

Ross at Gutbuster

Ross

This past week was an interesting bit of synchronicity. First, Ross took advantage of a Costco sale on the Garmin Forerunner 405, a really interesting bit of sports gadgetry that gives you real time location and performance information including heart rate.

Garmin Forerunner 405

Garmin Forerunner 405

Second, Google released Google Earth 5.2 with considerable enhancements including elevation profiles and the inclusion of additional data (such as heart rate) in its GPS import function.

Google Earth 5.2

Google Earth 5.2

And third, this weekend Ross took part in the Kusam Klimb, a gnarly 23 km long trek over Mount H”Kusam near Sayward BC, featuring rugged conditions and a 1.5 km change in elevation. Make sure you check out this year’s conditions

Kusam Klimb

Kusam Klimb in Google Earth

After completing the event, Ross somehow managed to summon up the energy to post a link to his data upload on Facebook. I have to say, Garmin’s web-based visualizer is very nice! it combines a graph, a map, and gauges in a very clear and easy to use format.

Garmin Player

Garmin Player

If you visit the activity page, you will notice that below the map you can export as TCX, GPX, and KML files. Garmin’s KML file is actually a very nice time-enabled presentation, but it doesn’t include the heart rate or speed data. For this, you need to download the GPX file. The easiest way to open it in Google Earth is to drag it into the globe window. This pops up a dialogue asking what features you want in the generated KML, and then creates a new file in your Temporary Places.

Google Earth - GPS Data Import

GPS Data Import

Now the fun begins. Of course, the obvious first step is to click on the Play button in the time menu to watch Ross run the trail…

Google Earth GPX Animation

GPX Animation

But that capability has been there for a while. What I find really interesting is the extra data that the GPX file brought along for the ride: heart rate, elevation, and speed. You can see the heart rate and speed (I think it may pull elevation from the terrain) by right-clicking anywhere on the track and choosing Show Elevation Profile. This gives you a cool interactive screen where you can display up to two variables, position your mouse anywhere along the graph, and see the information on the globe.

The Run of Ross

Ross on the Kusam Klimb

I have to admit that I have some reservations about this. The profile was very usable, but the design didn’t really fit with the rest of the Google Earth interface, and I would have liked to see all three data points (elevation, speed, and heart rate) at once. Fortunately, Google is well known for its incremental improvements, and I’m sure that it will get better over time.

Something else you can do with GPX data is create a Tour of your run and follow along with dizzying swoops and dips :) To do this, import the GPX as a linestring instead of a track, then expand the legend until you get to the Path and click on the “Play” button, and finally save the path tour.

Play the Path

Play the Path

Save as Tour

Save as Tour

You may need to play around with the Tour Settings in the Google Earth options a bit to get the correct zoom and speed, but eventually you’ll end up with something like the link below. Download the file, expand it in the Google Earth menu, and double-click on the Tour for some dorm-room-Quake queasiness:

Run Ross Run!

Whew. Time for some hard-earned relaxation! ;)

-J

Validating against the OGC KML Schema in jEdit

The Google Earth Outreach team has a good little tutorial on validating KML as you type in jEdit.  Unfortunately, it’s a little bit out-of-date, so here are some pointers for validating against the newer OGC 2.2 schema, using the current version of jEdit.

Follow the video instructions above for setting up jEdit, with the following exception: when you go to dock Sidekick, you click on Sidekick instead of Structure Browser and then, in order to start parsing the document, you need to select XML mode:

image

Once you have loaded your KML file, replace the root kml entity with the following instead of the older Google schemas, and you will be able to validate against the OGC’s KML and partial Atom schemas as you work:

<kml 
  xmlns="http://www.opengis.net/kml/2.2" 
  xmlns:kml="http://www.opengis.net/kml/2.2" 
  xmlns:atom="http://www.w3.org/2005/Atom"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="
    http://www.opengis.net/kml/2.2 http://schemas.opengis.net/kml/2.2.0/ogckml22.xsd
    http://www.w3.org/2005/Atom http://schemas.opengis.net/kml/2.2.0/atom-author-link.xsd"
>

One odd thing that I noticed in validating my KML.  When I placed the <name> entity anywhere other than right after its parent entity (such as Document or Placemark) the parser complained that it was not valid.  I don’t know if not having the <name> as the first entity is truly invalid, or if this is just a little quirk of the schema or the parser.  The Galdos KML Validator throws the same error.

The main reason I went through setting this up is that I decided that I had to, in good conscience, ignore the part of the OGC KML written standard that constrains Atom relation types to "related".  Not specifying the correct type of relationship means that I am contributing to the downfall of society, or at least to a less meaningful GeoWeb.  See my previous post and some follow-up at Sean Gillies’ blog for more on this.  Using jEdit allows me to ensure that my documents validate against the schema, which gives me at least some level of comfort when ignoring the online validator.

-J

KML Spec Bizarro?

I’m working on some new KML resources and, just as I try to do for my HTML, I want to at least attempt to get it to validate against an official specification.  For KML, this means the OGC KML specification.

These resources will be single-feature, and will each be related to exactly one HTML representation of the same feature.  Now, it seems logical to me that I would specify an atom:link with rel="alternate" inside of these KML files, either at the Document level or perhaps at the Placemark level.

Unfortunately, from section 9.1.3.5.1 of the official OGC KML specification:

The atom:link rel attribute shall be present and its value shall be related.

What the heck?  I’m not an XML guy by any means, but I think this means that the best I can do is specify a "I think I met that guy in a bar a couple years ago" kind of relationship, when what I really want is something more like "hey, that’s me in a dress shirt."

Now, if I’m right, the question is:  do I exclude the atom:link element from my KML, do I include the element and settle for a generic relationship, or do I intentionally break compliance with the OGC specification.  Tough choice.

-J

KML FDO Provider!

Just a quick note… Haris Kurtagic at SL-King just mentioned that he has put up a very alpha release of a KML FDO provider along with a new release of FDO2FDO which supports it.

With this tool, you can read KML files from MapGuide, and read/write KML using FDO2FDO or Autodesk Map 3D. This provider is still early in development, so get your feedback in now while you can still have an impact on how it works when it’s released.

As an aside, this is the first (soon to be) open source project I know of which uses Google’s libkml.

-J

KML Goodness from the FME User Conference

The FME User Conference is always great value. You get to see interesting presentations, learn about new technologies, and talk to bright people from all across the industry. This last point is probably the most important to me. Mixed in with other great conversations, I got to chat at length with Ed Katibah about SQL Server Spatial, and Don Cooke told me I dressed too well to be a neogeographer :)

It is also the best place to corner an FME developer. I managed to grab Tom Weir, Safe’s KML guru, and go over some of the changes in KML support with FME 2008. During a presentation on the first day of the conference I had included an “easter egg” where I spoke about how to enable active mouse-overs in KML using FME. To my chagrin, after a couple minutes with Tom I realized that my advice was not exactly best practice, and with FME2008 becomes downright ridiculous.

Here’s the before shot from my slide deck (zipped workspace):

Old FME KML StyleMap Workspace

And the after shot once I applied what Tom showed me (zipped workspace):

New FME KML StyleMap Workspace

Obviously, the FME 2008 press release should read: “KML Support in FME: Now with 50% less fat!”

KML FME has been generating multi-geometry for information points for quite some time, so that cuts most of the data wrangling out to generate the info point and merge the features into multi-geometry. And FME 2008 will automatically generate StyleMap elements for you if you follow a couple sneaky tricks.

First, when you create each KMLStyler, set its name to the style ID you want it to receive:

New FME KML StyleMap Workspace - KMLStyler trick

And second, on your geometry set the kml_target_style_normal and kml_target_style_highlight attributes to the IDs that you created in the KMLStylers:

New FME KML StyleMap Workspace - AttributeCreator trick

That gets my embarrassment out of the way, but doesn’t even begin to touch on the extent of KML 2.2 support in FME 2008. Another issue that I have written about is extended data or schema support, and I am happy to say that FME deals with this. Attributes are stored in your output KML as extended data by default, and it is easy to generate a BalloonStyle template. Here’s my first take on this support, which does a great job of separating data from presentation (zipped workspace):

FME KML workspace using balloonstyle

And a quick look at the new basic editor which is included in FME and used for modifying BalloonStyle templates:

FME KML workspace using balloonstyle editor

Which gives us this KML output (source).

There is a going to be a lot more to the KML 2.2 support in FME 2008, including generation of image pyramids for PhotoOverlays, but I’ll leave it to you to explore those on your own.

-J