I've seen evidence that people have done this. Some of the user
sceneries for Condor mention having
analyzed igc files to generate the thermal probability chart.

A good first pass would just determine overall climb rates per
thermal. Examine the time spent with a
ground speed below about 60kts (100kph), and average out the climb
rate. That makes one data point,
which can be assigned a grid address. The grid could be determined on
one minute (lat/long) intervals,
or better yet on 0.02 degree intervals (since igc files list locations
in ddd.dddd format). The data could
be summarized in a google overlay, with the color indicating lift
strength and the saturation the number
of data points.

Sounds like fun! (said the true computer geek)

-- Matt

On Jul 8, 11:50 pm, "noel.wade" wrote:
Hello All,

Some local club members are really getting into logging their flights
and posting them on the OLC. One posed a good question about trying
to use the flight tracks to develop a better sense of the best soaring
spots in the area by viewing multiple flight tracks at a time. I'm a
computer-geek by trade and this naturally got my brain thinking about
potential programmatic solutions. I'm TOTALLY swamped with work and
club-officer duties (that I'm behind on), but I thought I'd toss this
out if anyone wants to take it up as a project:

I'm envisioning something like a Google Maps overlay that has color-
coded points or blobs based on the average vario reading or climb-rate
in a given area. Obviously you would need a certain number of
overlapping or nearby data-points to generate a decent average.

Here's one potential implementation strategy: You have an "offline"
processing program that takes a bunch of IGC files and scrutinizes all
of the datapoints that they contain within a predefined geographic
area (a set of lat/long coordinates as a bounding-box or something).
This bounding-box could be broken down into sectors that are
equidistant to any adjacent sector (imagine a grid, with the center-
point of each grid square being 150m or ~500 feet from the center-
point of each adjacent square). The processing program could iterate
through each sector, looking at all of the IGC data-points that fall
within the current one. As long as a certain minimum threshold of
points could be found, a reasonable average value could be
calculated. To make the average value more universal with regards to
actual airmass movement, you'd need to know the speed and type of
glider that is responsible for each data-point, and remove its
theoretical sink-rate at that speed (wingloading is perhaps another
required variable - though a smart program with a baseline polar for
that glider should be able to make a good guess about the wingloading
if it looks at a variety of sink-rates and speeds over the course of
the glider's IGC log). You'll get a little error because inevitably
each glider's performance will deviate slightly from the theoretical
sink-rate at its recorded speed, and the contributor might have been
maneuvering in an unusual manner at a certain spot; but over a large
enough set of flights it would be a small error.

These average values for each sector could then be written into a
database and used as the source value for the Map overlay/display.
Over time, the processing program could be re-run periodically with a
new (larger) set of ICG files, resulting in more datapoints being
evaluated.

Anyone think this is interesting enough to give it a whirl?

Take care,

--Noel
P.S. I have already thought about mixed lift sources overlapping and
causing "misinterpretation" of the data, as well as the fact that some
areas will always be overflown by pilots in a certain manner (while
never looking for lift even if its there)... I don't view these as
bad things - they might not result in a map that accurately shows
climb-rates to expect, but the overall map would result in a sort of
"betting guide" to the more likely spots of useable or useful lift in
the area, based on terrain, lift, and other pilot's experiences...