Day 1 started off with a series of keynote talks. Many of the were on high-level, vague topics and I didn’t find them particularly interesting. Show me the code. But then Paul Ramsey gave a highly informative and entertaining speech entitled Beyond Nerds Bearing Gifts: The Future of the Open Source Economy. The basic message was how the most proprietary software companies sell products (rather than software) by including value added items (installation, support, Larry, etc.) with the software that you purchase (or rent). In order to have a successful business model, open source software companies also need to sell a complete product, although in this case the software is free and the value added products are sold. Paul is a great speaker, and is able to flawlessly incorporate his mother-in-law and killer rabbits into a speech that seemed to keep everyone interested. Luckily somebody captured the talk and already posted it on YouTube, and I would encourage everyone to watch it here.

After that it is was on to the technical sessions. As usual for a FOSS4G conference, you are continuously picking between multiple interesting talks. Hopefully some of the sessions I missed were taped, and will be available for later viewing. Of the ones I that I was able to attend, here are some of talks I found the most informative…

Emmanuel Christophe gave an overview of the Orfeo Toolbox, a project that has integrated a number imaging and geospatial libraries (ITK, GDAL, OSSIM, etc) for use in the analysis of remote sensing data. It is a project funded by the French Space Agency through 2010 in order to increase the usable value of remote sensing datasets. To date, it seems that there has been a relative lack of compelling open source alternatives to proprietary remote sensing analysis packages (particularly desktop apps), so I was quite happy to see substantial development in this area and that the project is likely to be funded beyond 2010.

After lunch were a few talks on how ‘cloud computing’ and geoprocessing can work together. Bastian Schaeffer gave a quick overview of cloud computing platforms that can be used to run geospatial applications written in Java, focusing on Google’s AppEngine (less flexible, easier to setup and administer) and Amazon’s AWS (more flexible, more challenging to setup and administer). Next up, Claude Philipona gave a talk on using AWS to deploy websites created using the MapFish framework (such as http://map.veloland.ch). They had an interesting approach in solving the issue of allowing users to select which map layers are displayed while maintaining a good response time. Their solution was to create tiles of individual map layers, which are then combined on demand (server side) based on what layers the user has requested.

Other interesting talks included Volker Mishche’s Geodata and CouchDB which presented some initial work on adding geospatial query support to CouchDB, a non-relational document-oriented database with a RESTful API. It sounded promising, but I admittedly have a relational database mindset so I kept thinking how repetitive and wasteful the non-relational approach would be for complex features, and I came away thinking I need to do more reading on document-oriented databases so I can understand the potential benefits. My current impression is that they can scale to massive numbers of users, but the tradeoff is that you lose important analysis capabilities.

Later on, a couple members of the Zoo Project gave a presentation on their open OWS platform, on which developers will be able to expose their geoprocessing services as a standardized Web Processing Service (WPS). The expect their project to be released with examples and developer documentation around March 2010. One of my main goals of attending this year’s FOSS4G was to gain a better understanding of methods that are being used to create geoprocessing web services. While various WPS implementations were discussed by many presenters, nobody seemed to have working demonstrations of using WPS to do anything interesting. I’m not sure whether that is due to the complexity of the WPS spec, or whether there haven’t been enough compelling use cases to drive the development. WPS hasn’t arrived yet, but the potential is there.

For more reading, here are a few other posts on FOSS4G 2009:

• How 2 Map - FOSS4G Day n+1
• From the Inside Looking In - FOSS4G 2009 - Day 1

That’s all for now, I’ll follow up later recapping the remaining days of the conference. I have to go explore more of this beautiful city while I have the opportunity to do so…

The organizers put out a hardcopy map, but there also have been requests for digital versions. So here goes:

1. KMZ file - A file format viewable in GoogleEarth.
2. GPX file - A generic format for GPS devices. If your GPS doesn’t support the GPX file format, you can convert this file to other GPS formats with GPS Babel application/library.

The trail data has been added to the OpenStreetMap database. Look for it appear in the OpenCycleMap tiles in the next week.

Triple Trail Challenge GPS track

My friend John and I headed up to Winter Park for a few days.  I had brought along my GPS data logger (a BGT-31, used to measure windsurfing speed records), so I could log our runs.  The snow was warm, firm, and fairly fast, and we entertained ourselves seeing how fast we could go.  The max speed recorded on the GPS increased throughout the day, and on the final run the GPS registered a speed of over 50 mph.  John was undoubtedly going faster with his downhill gear, but I was on my teles and had the ‘official’ recording device.

After we retired back in our gasthaus at the end of the day, I downloaded the track log from the GPS device and converted them into KML for viewing in Google Earth (via gpsbabel and some python scripts).  I was surprised to see that the top speed recorded was actually 61.8 mph.  My (untested) theory is that the difference was because the max speed reported was the horizontal velocity, while the KML placemarks descriptions show the 3-D velocity.

Here are some KML files of the tracks:

• 2009-03-20-morning-runs.kmz
• 2009-03-20-afternoon-runs.kmz
• 2009-03-21-morning-runs.kmz
• 2009-03-21_afternoon_runs.kmz

On the third day we headed up to Berthoud Pass for a bit of backcountry skiing. It was a nice sunny day with little wind, but the snow was a bit rotten due to the recent warm spell. John, on his retro skinny randonee setup, ended up taking a abrasive faceplant on the descent due to the funky snow conditions.  Load up the following file and navigate to 2009-03-22T18:05:27Z to see the exact location.

• 2009-03-22_ski.kmz

Subject: DDA meeting, downtown, today; I have 4 minutes on the agenda
To: a2b3@yahoogroups.com

I have 4 minutes on their agenda. Where do you start? Send me suggestions.

1. Sidewalks, and the shoveling of.
2. Buses, in general.
3. Buses, particularly real time bus information a la ridetrak.
4. Real time bus info at stops.
5. Parking structures, and the surplus of; occupancy rates etc.

Only 4 minutes though, and I need to be prompt about it all.

–
Edward Vielmetti
Ann Arbor, MI

After a few replies about the need for real-time bus information (which the DDA doesn’t have), the thread quickly moved to parking structure data (which DDA has available in real-time on their website). There had been some creative use of the data in the past, including a map showing the proportion of free spaces in each structure, an analysis of a month’s worth of data, and an RSS feed of the data.

At the the time of Ed’s meeting, the DDA was exposing the data on a simple html page that contained a single table with the current spaces available for each structure. Within a day, Fred Posner had put together an telephony application that allows people to call a phone number to check the available spaces. Very cool.

I work in the area of geostatistics (among other things) and remote sensing and my initial interest in the dataset was in the temporal and spatial aspects of the data. But since the DDA website only lists the current conditions, the data would have to be scraped from the DDA website and stored for future use. So I set out to create a data system that would harvest and store the data in a format that would support later analyses on the dataset.

I settled on using the python web framework Django (which I regularly use), hosted on Google App Engine (which I was interested in trying out). The Beautiful Soup library was chosen for scraping the parking status data from the DDA web page. Ed pointed me in the direction of IUI which allows iPhone/iPod like navigation in a web page.

Here is how the project progressed:

• 1/13/09 ~3:00pm - the application was up and running, harvesting data from http://www.a2dda.org/parking.php .
• 1/15/09 ~3:00pm - the web page http://www.a2dda.org/parking.php was taken down
• 1/16/09 ~7:00am - I modified the application to scrape data from a second page http://www.a2dda.org/parking__transportation/available_parking_spots/
• 1/16/09 ~5:30pm - the harvesting script was ‘banned’ from accessing the second web page with the parking data

Apparently someone is worried that the parking status data is actually getting used…

I intend to talk to the DDA next week to find out why access was blocked, and hopefully reinstate access.

So at this point, there are a 3 days of time series data for nine garages in the database, and the website has few basic pages that display the most recent data as HTML or a time history as a CSV file. It’s a starting point, upon which additional output formats can be added. Just need to get the data flowing again…

The source code for the project is available at: http://bitbucket.org/tylere/a2-park

The following screenshot shows a few of the datasets. The LEF Tall Tower located in Wisconsin samples air the has traveled over a wide region, and is sensitive to CO2 release and uptake in regions that the air was beneath the atmospheric boundary layer (green lines).

Update:

A few days after the original deadline (Dec 1, 2008) the contest deadline was moved to February 1, 2009.

This is the fifth year in a row that I have raced the Iceman, but the first time on my new single speed.  I ended up finishing with a personal best (2:09:14) for the course.  Less gears = faster bike?

I recorded the course this year with a high frequency GPS data logger (1 record per second).  The data is available here in KML.  If you open up the file in Google Earth you can use the time slider to play through the race.

iceman08.kmz (right click to save)

I also loaded the route onto OpenStreetMap.  The cycle specific rendering can be found here:

http://opencyclemap.org/?lat=44.73977&lon=-85.20621&zoom=14&layers=B000

Long live long rides…

It was a good fall ride, where you tend to pass orange folks with guns on the trail.  The Gunnar SS works pretty well, except for the GPS mount, which came loose after a couple of miles.  I ended up stuffing the GPS in my jersey, where it seemed to collect just fine, and now there is a nice map of the Poto.  I plan on posting the route to OpenStreetMap, where it should appear on the cycle map in the next week or so…

The data was collected by a Locosys BGT-31, set to record position every second.

Story: This outhouse is located at the park visitor center for Halealaka National Park. John and I started here for our hike into the volcano crater via the Sliding Sands trail.

Location: Visitor Center, Haleakala National Park, Maui, Hawaii

Photo Credit: Tyler