Micro Reader

Building the Tour Tracker, part 3

2007-03-07T10:52:00.000-08:00

So, a number of folks want to see the XML files that were used in the Tracker. Pending the source being posted, I wanted to provide a glimpse of the XML data I was consuming... Part 4 will get back to the real stuff, I promise.

tour.xml looked something like this....

<tour>
<name>Tour Of California</name>
<stages href="stages.xml">
<teams href="teams.xml">
<riders href="riders.xml">
</tour>

stages.xml looked something like this....

<stages>
<stage>
<name>Stage 1</name>
<number>1</number>
<description>Sausalito to Santa Rosa</description>
<date>02/19/2007 11:00:00 AM</date>
<course>
<route href="stage1.xml">
<length>97.2</length>
<sprints>
<sprint>
<name>Point Reyes Station</name>
<distance>27.9</distance>
</sprint>
</sprints>
<climbs>
<climb>
<name>Mount Tamalpais</name>
<distance>7.9</distance>
<category>4</category>
<elevation>1512</elevation>
</climb>
</climbs>
</course>
</stage>
</stages>

teams.xml something like this....

<teams>
<team>
<name>Discovery Channel</name>
<code>DSC</code>
<jerseyclass>JerseyColorsDisc</jerseyclass>
<markerclass>MarkerTeamDisc</markerclass>
</team>
</teams>

riders.xml like this....

<riders>
<rider team="TMO" name="ROGERS Michael">
<rider team="DSC" name="LEIPHEIMER Levi">
</riders>

and stage1.xml (the route description) is... obviously the coordinates section is the real meat of the route and i'm only showing 3 of thousands of coordinates...

<kml>
<document>
<folder>
<name>TOC - stage one</name>
<placemark>
<name>stage one route</name>
<linestring>
<tessellate>1</tessellate>
<coordinates>
-122.525029684569,37.8820621222632,11.222371084321395
-122.5251466016472,37.88202877312941,11.358573896309174
-122.5255467637875,37.88180258521668,11.975485783494067
</coordinates>
</linestring>
</placemark>
</folder>
</document>
</kml>

Later I'll include the XML that gets posted during the race. But this shows what we load at startup to display the race details to the user.

Building the Tour Tracker, part 2

2007-03-06T17:55:00.000-08:00

The Application
Okay, part 1 gave an overview of the big parts of the Tracker solution. Now, let's take a closer look at how I built the Flex application. The source will be available soon should people be interested, but in the meantime, I want to give a structural overview and provide some details of the architecture and implementation. In part 3, I will then go into more details about specific parts.

For those who care, my Flex project is made of 50 MXML files and 75 ActionScript files. Throw in a couple of SWC files for visual assets and the XML that describes the race itself and that's everything.

Application Visual Tree
Application contains a single Tracker object (pure ActionScript) that maintains all the state of the application and a set of visual components (all MXML): the course map in the background, a navigation bar across the top, a branding bar at the bottom, and one class for each of the "pods" in the user interface. Those pods are the profile display (the mountain range), the play-by-play pod, the live video pod, the tour standings, the GPS rider list, the stage results list and the video/photo list.

Tracker
The tracker class is the heart of the machine and is passed to most top-level visual elements. Since the singleton tracker object is declared in the main MXML file, it is constructed automatically and its constructor begins the process of loading data from servers. It has a number of critical functions:

- has a Tour object which represents everything that is known by the system about the race.
- has a member that represents the stage that the user is currently viewing
- has a set of data managers for communicating with Flex Data Services, the XML web server, and Flickr

At startup, the Tracker coordinates the loading of various data, making sure the required XML files are loaded and process, that connections to Flex Data Services are established, and a bit of bookkeeping.

Tour
The tour class is primarily an in memory representation of the state of the race. It is loaded from an XML file (either embedded or on the web server) and includes:

- the name of the tour
- an array of Stages
- an array of Teams (name, 3-letter code)
- an array of Riders (name, team, location if GPS tagged)

Stage
The stage class contains everything known about a specific day of the race. Half of that information is read from XML files as part of the Tour initialization. Half comes from other data sources (like Flickr). And the third half is real-time race data. It also provides methods for starting and stopping a race. The stage keeps track of:

- name, date, location, start time
- a Course object
- an array on play-by-plays for that day (grows real-time)
- an array of photos and videos from that day (grows real-time)
- actual start time of the race if it has started
- the position and speed of the peleton, broom wagon and break-away cars
- an array of GPS-tagged riders for that day and their positions and speed
- a Results object once the race is over (read from XML posted real-time)

Course
The course class represents the race course itself including the route the race covers (a KML file generated in Google Earth), Markers that represent special points along the course (climbs, sprints). In addition, the course provides methods for mapping between lat/long, elevation, distance and grade.

Okay, enough for one post. Next, I'll get into a few details of these classes and the some of the more interesting stuff: server connections and my favorite, the map and it's overlays...

Building The Tour Tracker, part 1

2007-03-06T14:11:00.000-08:00

This post will describe how the Adobe Tour Tracker was built. I'll break it into a couple of parts: the overall system architecture and the design of the Flex application itself. First, the overall architecture:

Overview
The Tracker is a Adobe Flex application built using Flex Builder 2.01. Thus it is in reality a Flash application from the user's point of view and will run on any system that has Flash Player 9 installed. Flash Player 9 is required because newer applications built with Flex Builder are all ActionScript 3.0 and version 9 was the first player to support ActionScript 3.

In addition to the Tracker itself, there are a number of server-side components that make up the complete solution:

- Flex Data Services: This Adobe server product provides dead-simple server support for Flex applications. In this case, I use it to multi-cast data changes to all active Trackers. Those changes include new play-by-play messages from Velonews, new GPS-tagged photos that have been posted by the photographer, new GPS-tagged videos that have been uploaded by the production crew, and new GPS information for each rider/car. In addition, it provides a small amount of state data by recording if and when a given day's race has started.

- Akamai Video/Audio Streaming: This is a cluster of servers that provide the live video and audio streams to all of the Trackers. Each Tracker connects to the cluster directly. The servers are using Adobe Flash Media Servers to stream the video and audio data.

- Flickr Photo Servers: As the race photographer takes GPS-tagged photos of the race, the photos are uploaded to a Flickr Pro account. The Tracker accesses this account directly when it starts up to find out about old photos, and the FDS server (above) accesses the account regularily to look for new photos. When the FDS server discovers a new photo, it broadcasts details about the photo to all running Trackers.

- Portent Web Servers: The Tracker itself (ie, the SWF file) is hosted on a cluster of Portent web servers. In addition, a great deal of XML data is hosted there and is accessed by the Tracker at runtime. That includes information about the tour itself (times, courses, teams, riders) and daily updates (standings, video clips, stage results).

- Yahoo Maps: Not much to say here. Our map data for the overhead view is provided by Yahoo and it's imaging partners.

- Akamai Web Servers: Archived video clips (whose location is recorded in the XML files mentioned above) are actually stored on a cluster of Akamai servers. They are servered as progressive FLV's directly to the Tracker when users view video clips.

So, that is the highest level of Tracker design. For more information about the FDS solution, see http://coenraets.org/blog/2007/02/building-the-back-end-of-the-tour-of-california-%e2%80%9ctour-tracker%e2%80%9d-using-flex-data-services/ where the FDS engineer describes what he had to do to provide the Tracker with real-time updates.

Next, some details...

Feedback from tourtracker@yahoo.com

2007-03-01T14:50:00.000-08:00

Here are some comments from the official feedback email:

Chuck Moore says: "I really loved the tour tracker when I could see it live. It would be fantastic to be able to go back in time and watch it all from the beginning. Sometimes I had to do some work during the stages! Also, there were times that the velonews play action was ahead of the video by several minutes."

Barrie Rempel says: "Congratulations on a great tour! When everything was up and running the coverage was awesome. I was amazed by some of the events I thought were important that the VS coverage ignored. Your commentators were excellent, making the pictures meaningful."

Steve Ellis: "Yes, the riders are great, but the www site has poor performance... that is with the video feed, and audio is choppy at nearly all times. Suggestions? 1. Stream audio on XM radio. 2. Get servers with sufficient capacity. 3. Talk to NASA about how they can stream LIVE video and audio, with EXCELLENT resolution to millions across the globe every shuttle launch, even full screen."

Jane Frybarger: "Don't change a thing! I can't even believe how cool this was.
Someone deserves a huge pat on the back, a raise, a huge hug."

Mark Koep: "1. Lower bandwidth version – video and audio were choppy with a Broadband Cellular card 2. Login options that enable user to only see certain aspects (i.e. audio and text only) 3. Worry less about the aerial map loading and more about the speed and accuracy of the GPS tracker uploads 4. Ability to tune into the race radio channels"

Carsten Olsen: "It has bin great to watch the races over the web and since we have 10 ince of snow here, it not much of cycling going on here... and we are looking forward to one more victory to Team CSC... greating from Carsten, Copenhagen, DENMARK"

Mike Finnegan: "Thanks for trying. But I've been dissappointed by the on-line coverage. I tuned in all week."

A Cycling Fan Prompts A New Version?

2007-03-01T09:39:00.000-08:00

Paul at Velochimp (http://velochimp.com/2007/02/19/amgen-toc-website-pushes-boundaries-again) has accidentally prompted me to write a version of the tracker that is all about the fans. Will try to build it soon. In particular Paul said "Anyone with a flickr account can upload photos, and as long as they are tagged with the relevant coordinates and placed in the proper pool they may show up on the Tour tracker." Alas, for sponsor branding reasons, that is not true. But that doesn't mean I can't build one without branding! Although do any of those fans really have GPS-enabled cameras? Stay tuned!

My Reply To One Blogger

2007-03-01T09:20:00.000-08:00

Here's a reply I made to one of the bloggers (http://www.veen.com/jeff/archives/000962.html) that sheds some light on some of his and his reader's questions. Thought reproducing it here might be useful...

Hi Jeff. I wrote the Tracker (for more see http://www.allanpadgett.com/blog) and thought it might help to respond to your comments and those of your readers. First off, timeshifting. You are 100% right. That was in the dream plan, but with only 4 weeks from concept to ship, and only one programmer on the client, only so much got done! In particular, we didn't have anyone willing to store that much archived video, and while CSC did archive the GPS data, they forgot to include timestamps in the data. Soon, however, I'll be putting a version up that will allow you to scrub through each stage and at least see the photos and play-by-play. Adobe saved GPS data for the last few days once we realized CSC's error, and I will try to incorporate that too. As for "too much at once," you are not alone on that one, and the next version (Tour de France?) will have better information management. As for your readers, here are some answers to their comments. Dunstan commented on Flickr usage. We used a specific account instead of tags as part of protecting the photographer's copyright. Plus, Amgen and the other sponsors understandably did not want random photos showing up in a branded application. Matt mentioned Quokka, and yes, we owe a great deal to Michael's past at that trail blazing company! Sadly, Michael was too busy schmoozing with race officials to be a big part of the project... Brett mentioned Portent as the designer, but they just provided the backend support for hosting the application and the results from each day. Sadly, they didn't set up a cluster for a few days, so getting the application and data was a challenge for many users. Dan asked about future Grand Tours? As a bike nut (that's why I volunteered to write the application) I'm all over that! Finally, and most importantly, Gartenfackel said that the infrastructure was inadequate, and that's 100% true. Akamai provided the video and audio streaming and they were running beta software (why? who knows!) which went down every day. CSC's GPS system was dependent on beta GPS devices and T-Mobile's terrible coverage on California back-roads. And as I mentioned, the Amgen site itself was running just one machine for much of the race, while we had 8,000 or so viewers. If you or your readers have more questions or comments, feel free to ask away!

Other Tour Tracker Blogs

2007-03-01T08:29:00.000-08:00

Wow, before I even get started on describing the application, there are lots of links I have to share! Here are some, if you know of more, email me for sure....

From the cycling community....
http://www.tdfblog.com/2007/02/adobes_californ.html
http://www.bikingbis.com/blog/_archives/2007/2/19/2747203.html
http://www.cyclingfans.com/
http://velochimp.com/2007/02/19/amgen-toc-website-pushes-boundaries-again/

From the geek community....
Mike Potter:
http://www.riapedia.com/2007/02/18/the_absolute_coolest_sexiest_flex_application_ever
Joe Rinehart called it “My dream application!”:
http://www.firemoss.com/blog/index.cfm?mode=entry&entry=DB8C3C60-3048-55C9-437A2E35DD512CAA
Simon Barber:
http://spbarber.com/blog/the-amgen-tour-of-california-flex-2-application/
Matt Chotin: http://weblogs.macromedia.com/mchotin/archives/2007/02/amgen_tour_of_c.cfm
Andrew Spaulding:
http://www.flexdaddy.info/2007/02/20/the-adobe-tour-tracker-real-time-bicycle-race-info/
Ben Forta: http://www.forta.com/blog/index.cfm/2007/2/19/AmgenTourOfCalifornia
Christophe Coenraets:
http://coenraets.org/blog/2007/02/building-the-back-end-of-the-tour-of-california-%e2%80%9ctour-tracker%e2%80%9d-using-flex-data-services/
Ted Patrick:
http://www.onflex.org/ted/2007/02/tour-of-california-live-part-2.php
Francis Potter:
http://www.yottapixel.com/2007/02/18/live-videodataimage-mix-of-california-bike-race/
Jeffrey Veen:
http://www.veen.com/jeff/archives/000962.html

Interestingly, someone thinks that Portent did the design, since they list the website in their portfolio! Not true! The design was a combination of Dave Nelson (original design), myself (added the satelite maps with riders, photos, etc), and Mike Sundermeyer (fixed everything I did wrong).

Adobe Tour Of California Tracker

2007-02-28T21:53:00.000-08:00

So, my first Flex application is complete: the Tour Tracker. The Tracker is a real-time application for following each day of the Amgen Tour Of California bike race. Adobe (my employer) is a sponsor of the race and part of that sponsorship is this application. I volunteered for the project as a bike nut who wanted to learn Flex.

I'll be adding posts this week and next about how we built the application and my experiences over the past 4 weeks of development, but I'll start out with a couple of thoughts....

1 - The project took about 4 weeks from initial design meeting to final product to build.
2 - The team included:
- one designer who did the initial comp and one who produced the graphics
- one engineer working part-time to create the back-end data server (Flex Data Services)
- one engineer primarily handling our connection to the back-end servers (FDS, Akamai)
- one engineer (me) who built the Flex application
3 - Personally, before this project I had never...
- built a website other than the Web 1.0 "Padgett Printing Prototype" on my home page
- seen let alone writtne a single line of Actionscript
- used Flash
- used Flex Builder
4 - The site, when it worked, was SWEET. Sadly....
- the Akamai (video/audio) back-end was very unstable and unreliable
- the GPS coverage was spotty (beta devices, dependence on T-mobile coverage)
- Amgen's servers (hosting the SWF and the results) were down 1/2 the time
5 - Of course, I should have made my application handle all these better...

Tomorrow, some real details....