Update: See also Day 1, Day 2 and Day 3.

Friday was code sprint day, and a healthy pile of nerds settled into a nice modern space at the Barcelona CitiLab for 8 hours of coding and technical discussion. Team PostGIS dedicated the day to discussions of PostGIS 2.0, and identifying and closing off high priority tickets before releasing a 1.5.2 update (to provide support for PostgreSQL 9.0, coming out soon).

Subject to approval by the full Project Steering Committee (PSC) there will a couple big changes to PostGIS through the 2.0 cycle. First, the raster experimental spike will move into the main tree and become a default part of PostGIS. Second, the PgRouting external project will move into the PostGIS source tree and issue tracking system as a spike, and reside there while it is harmonized with PostGIS, probably entering the main tree at the 2.1 cycle. Those are the headlines. The sub-heads are 3d and 4d indexing support, real 3d objects (polyhedra), and an official translation pipeline for the reference manual so we can support the international community more comprehensively.

I spent Saturday walking my legs down to round nubbins.

I could not attend FOSS4G in 2008, and in 2009 I did not feel like there was much momentum in the technology area, but this year it felt like the community was in fact still innovating rapidly. This is a perception of course, they obviously innovated throughout 2009, but the innovators probably just found it harder to get to Sydney.

The places I am seeing and expecting to see more changes are in continuing power in client frameworks, and in the distributed computing (“cloud”) space.

Probably there will be a minor explosion of mobile projects over the next year. gvSIG mobile has been alone in that space for a long while, and emergence of competition is pretty inevitable. At the minimum we should see an open source iPhone mobile framework.

Also, the distributed computing space is ripe for some new projects, in particular distributed spatial analysis in both the vector and raster spaces. I know the intellectual ferment is out there, so we should see first releases and new projects popping out over the next 12 months. And then hear about them in Denver (September 12-16, 2011).

As an aside, I have been surprised there are so few talks about spatial CMS framework extensions at FOSS4G, since so many problems boil down to basic content management with a tasty, spicing of location and maps. There was a talk about a new spatial extension for Drupal, but I think that’s it for this year. Perhaps next year the extremely popular GeoDjango project will get some FOSS4G hype: it deserves some.

Per usual, it was a treat to see the FOSS4G regulars and meet new folks who are just entering the community, my only regret is that the event is over so quickly. It is always the most intense week of my year.

Adiós  Barcelona! Me la pasé bien.

5 thoughts on “FOSS4G 2010 Final Answer

  1. Paul,

    Code implementing 3D/4D indexing, routing, and others not mentioned in this blog are excellent candidates for considering re-usable libraries rather than implementing in one specific database implementation.

    I write this to encourage collaborating around re-usable libraries that can be used in PostGIS, Ingres, CouchDB, Spatial-Lite, MySQL, and others. We’re moving in the same direction, why not work together and move the state of the art ahead of closed source offerings sooner rather than later?

    I am offering developer time, code, money, tester time, and more towards such initiatives. I’m also willing to help rally others that might be interested in contributing. It would be great if we can come together around this.


  2. With two exceptions, Andrew, I don’t agree. The core of the 3/4D index implementations, the core of the raster type, the 3D type code, are all very specific to the PostgreSQL mechanisms and code. Even much of PgRouting is actually specific to the PostGIS model underneath. The exception for the routing is the actual graph traversal code, so there’s a possibility there if we feel the algorithmic basis is sufficiently unique (some if it is just binding to other existing graph libraries like Boost, so again not a big sharing opportunity). The exception for 3D objects is the actual object algorithms (distance, intersection, etc). However thus far we are only talking about object creation and serialization/deserialization, which is again very database specific.

    Little known fact. Much of the “internal” PostGIS logic is actually separable from the PostgreSQL core, by extracting the liblwgeom directory (which builds a static library). Schuyler Erle used liblwgeom outside of PostGIS in his shape to spatialite loader tool. Less obviously the shp2pgsql and pgsql2shp tools are instances of non-PostgreSQL apps that use liblwgeom as a (static) library.

    PostGIS walks a tension line between the core C implementation and the shared C++ GEOS implementation of algorithms. I particularly am caught between my desire to share code and my lack of C++ knowledge. It’s just so much easier (and somewhat more efficient since I don’t have to slug data over the library boundary from PostGIS to GEOS) to work in C. A personal failing I would work on if I had some more free time.

  3. Paul,
    I think you are right that GeoDjango is getting a lot more use within the FOSS4G crowd than you would think from marketing materials and talks. Just about all the python programmers I sat down with at FOSS4G pulled open laptops to show me apps written in GeoDjango and Mapnik.

Comments are closed.