Large GPS Track Logs

I had the need to display GPS tracks in DeepEarth. GPS tracks can contain thousands of points. DeepEarth has three update modes called ElementUpdate, PanOnlyUpdate and TransformUpdate for showing features such as tracks:

• ElementUpdate recalculates the point positions on every map movement. This produces an accurate track display but gets slower as the number of points increases.
• PanOnlyUpdate recalculates point positions during panning and hides features while zooming. Not too useful for me and didn’t seem to show anything anyway.
• TransformUpdate draws the tracks to the map once then scales and pans the vector graphic in synchronization with the map. This makes it very fast. Sadly the scaling code is flawed. Lines disappear as you zoom in and sections of the tracks become distorted, almost looking like calligraphy.

I wasted many evenings trying to get the scaling in TransformUpdate mode working before giving up. I then turned my attention back to the ElementUpdate mode to see where the bottleneck is.

The LogicalToPixel Function

LineStringControl objects represent the GPS tracks and they draw as lines using multiple points. When points are added to a LineStringControl they are transformed from longitude and latitude into logical coordinates. This is an intermediate coordinate system that can easily be converted into pixel coordinates later.

When the map is panned or zoomed the CoordTransform.LogicalToPixel function is called for every point in line. This function uses some simple mathematics to work out where the point should be on the map in terms of pixels. This is the bottleneck.

A single zoom or pan operation can result in this function being called several times. If a GPS track has 7,000 points that is a lot of calls. My testing showed that even the very first mathematical operation caused considerable slow down. Overall this function had several problems:

• Using 64-bit division
• Creating three Point objects and then discarding two for each call
• Using Math.Log and Math.Pow functions

Optimizing LogicalToPixel

The first step was to separate out the mathematical operations into two groups:

• Those that can be executed once per movement of the map
• Those that have to be executed once per point

I split the function into two new functions, LogicalToPixelPrepare and LogicalToPixelPerform to allow the two groups to be called separately.

Next instead of creating two temporary Point objects and then throwing them away, two global (to the class) Point objects are created and continually reused. This eliminates any overhead of object creation.

Finally I saw that I could eliminate both Math.Log and Math.Pow, as they were not necessary.

The last step was to modify the GeometryLayer.UpdatePathData function to call LogicalToPixelPrepare once and then LogicalToPixelPerform for every point. This reduces the transformation code needed for every point down to four multiplications and two additions.

Conclusion & Download

By finding the bottleneck and looking at way to optimize it, I was able to gain a significant speed increase for my 7,000 point test GPS track. I think the performance is close to that which could be obtained from the TransformUpdate mode, but without the scaling flaws found in that mode.

Download a patch that can be applied to the Silverlight 4 branch of DeepEarth (currently at revision 49789).

www.youtube.com/watch?v=22MOWEAzmoY

www.youtube.com/watch?v=H5SiCU7xk-4

The total elapsed time shown was one hour and 41 minutes, compressed into two minutes at 24 frames per second.

www.youtube.com/watch?v=CG7YV2LZzgQ

There are lots of ways to make cheap panning mechanisms, with the most popular involving an old egg timer. However these approaches have some limitations:

1. Once the panning starts you don’t stop it, even if you panned away from an area where something happened 10 minutes after the start
2. The panning is typically a linear motion – the same speed all the time
3. Most panning mechanisms do not have vertical panning, only horizontal

Number one comes from the limitation of having to set up the motion before starting to take the pictures. It can be difficult to anticipate in advance what might happen in the scene and once it does even if the motion was somehow changed, it would have to change slowly to avoid disrupting the video in a jarring way, missing the item of interest anyway.

Number two can be solved by using a PC or microcontroller to control the camera motion in more complex ways. However this is added time and expense for design and setup.

Number three can be solved by using two motors, one for horizontal and one for vertical. Again, unless the motion is very simple and defined in advance, a PC or microcontroller would be needed.

www.youtube.com/watch?v=vg2WYUQB4Uo

It was generated with 3750 pictures taken two seconds apart using CHDK.

www.youtube.com/watch?v=gk7h5ZzNqhs

www.youtube.com/watch?v=lKiOrLHW1fU

• Driving time -- 55 minutes
• Distance -- 31 miles
• Altitude gain -- 5,500 feet
• Temperature drop -- 29 degrees Fahrenheit
• Pictures taken -- 1,219

www.youtube.com/watch?v=iewUINHZg6Q

Some things to look for:

• Overexposure in most of the frames. This is because I forgot I left the camera on ISO 800. Don’t do that.
• 0:24 -- cyclist
• 0:25 -- end of the cactus, start of the small bushes
• 0:29 -- fee station
• 0:41 -- start of large trees
• 0:50 -- Windy Point, a popular vista location to look down on Tucson
• 0:55 -- start of the pine trees
• 1:06 -- turn off the main road onto a dirt road
• 1:12 -- Forest Service truck
• 1:13 -- people camping
• 1:16 -- a family with a dog
• 1:18 -- looking north towards San Manuel, Ariz.

www.youtube.com/watch?v=ciAV0ng1KkI

It’s amazing how Pinnacle Studio and it’s Dazzle interface can take a nice clean input and make it look like an old VHS tape…