18 Mar 2009
We completed the 3.1.0 release cycle today! Here’s the announcement:
The GEOS team is pleased to announce that GEOS 3.1.0 has been pushed out the door, cold, wet, trembling and looking for love.
http://download.osgeo.org/geos/geos-3.1.0.tar.bz2
Version 3.1.0 includes a number of improvements over the 3.0 version:
- PreparedGeometry operations for very fast predicate testing.
- Intersects()
- Covers()
- CoveredBy()
- ContainsProperly()
- Easier builds under MSVC and OpenSolaris
- Thread-safe CAPI option
- IsValidReason added to CAPI
- CascadedUnion operation for fast unions of geometry sets
- Single-sided buffering operation added
- Numerous bug fixes.
Users of the upcoming PostGIS 1.4 will find that compiling against GEOS 3.1 provides them access to some substantial performance improvements and some extra functions.
Thanks everyone on the GEOS team for the work over this cycle!
11 Mar 2009
Update. The pictures from the event are being uploaded.
So, this week was my first code sprint, and I feel like I learned a few things, which can hopefully be applied to future events. (Theoretically, I organized and participated in the 2007 FOSS4G event, but in reality I was too burned out to do more than watch people work with a dizzy smile on my face.)
Length. I think we accidentally hit on the perfect length for a sprint. Four days. Day one was “talking day”, the teams had a year of piled up discussions and decisions to make, and relatively little code was cut, but group cohesion and unity of purpose was achieved. Day two was “start coding” day, as people bit off bugs and features and so on. Day three was “wrap up coding” day, as larger features and bugs were completed. And day four was “polish and depart” day, as many people did a bit of work and then left for flights mid-day.
A shorter event would compress away coding time, not leaving enough duration to attempt larger features or bugs. A longer event would burn people out and by day four they would be slogging. Four days is just right for a self-contained event. For a sprint tacked onto the back of a larger event, that would have to be re-evaluated, as presumably people would already be pretty tired.
Venue. I think our choice of a travel hub in the off season worked out well. Most people had fairly direct travel options, and we were able to get very good hotel rates for a large city. Arranging block hotel rooms to keep everyone together was also good, as it made social organizing very simple (“meet in the lobby!”).
Using the hotel meeting facilities was less optimal. I would really like a room with windows next time, it would make the atmosphere much lighter. And banquet catering is extortionately expensive, to the extent we didn’t use it. If you don’t like the meeting room, and you’re not using the services, why use a hotel venue at all? So next time, I will spend a little longer looking for an alternate venue – our needs are simple, 1000sqft, 25 chairs, tables, and internet connectivity. It’s a code sprint, not a wedding.
Social. Circumstances (our inability to afford hotel catering) actually forced us into an enjoyable alternate plan, of having people fend for themselves during the day, and then all eat together in the evenings at sponsored dinners. We were also able to use sponsorship money for an evening of minor hockey, which was a fun cultural event. It turned out well, our money went further, the beer flowed freely and we had more non-coding time to interact than if everyone split up for dinner in the evenings. Another cultural event would be a good addition next year.
Effectiveness. One of the interesting side effects of our community overlaps (PostGIS developers are Mapserver developers are GDAL developers are libLAS developers) is that on “talking day” people had to make some hard choices about how to self-identify. Because I was concentrating on PostGIS, I mostly missed out on the Mapserver sprint, which is too bad.
Otherwise, as I mentioned in the day four summary, it was incredibly effective. It takes a long time to reach a decision over e-mail compared to face-to-face. That can be benefit (more time to consider options without getting stampeded into a decision) but also a drawback (more time taken, period).
Effort. Not hard at all, a very easy event to organize, with relatively few moving parts, and lots of help from locals like Tom Kralidis and Jeff McKenna in organizing. I’d do it again. In fact, I will do it again, going to start planning for the 2010 event starting this fall.
10 Mar 2009
Today we wrapped up the first annual code sprint for the “C tribe” of the open source geospatial community.
The final results in the code were great. We got some major performance improvements into Mapserver (shape file speed, projection lookup speed, query speed); we got PostGIS 1.4 ready for release; GDAL performance was investigated and work started on big speed-ups.
The final results for the community were also great. With everyone around the table, the PostGIS community agreed on development priorities for the 2.0 cycle. Mapserver got in good long discussions about long-range plans such as XML mapfile, and OWS services access control. I didn’t see the results, but the libLAS developers also had lots of time coordinating.
The face-to-face communications bandwidth is so much higher that problems fall by the wayside at a great rate. I saw Frank Warmerdam reviewing MrSid code in GDAL with Michael Gerlek, and Michael being able to quickly point out performance mistakes: “don’t call that function every time”, “these functions are costly, but only the first time through”. I saw Steve Lime mentally model several approaches to query improvement, trying them out on different community members before settling on the final solution (which I implemented in the PostGIS driver this morning, and has improved performance in WFS-on-PostGIS by a factor of 24 (!!!)).
Thanks to the GDAL project for sponsoring today’s activities.
And thanks to all the attendees, who paid their way to Toronto, and their accommodation, for the privilege of spending four days in a hotel conference room hacking on open source. You are wonderful, weird, wonderful people!
