Technical Ramblings

At the OSGeo Board meeting in Barcelona, we discussed many things, but one of the topics of special interest to me is the simple question: “What is OSGeo all about?”

The first place to look for that, of course, is the website; although many parts of the website address many specific problems, there is one place that we define what OSGeo is really about: the mission statement. It says that the Mission of OSGeo is:

To support the collaborative development of open source geospatial software, and promote its widespread use.

When we started our board discussions, there was one word missing there: the “collaborative” is something we voted to add, something I was very supportive of. There are many organizations (Sencha being a significant example in the space I work in) where organizations are developing Open Source software that is not openly developed. OSGeo is not about that: instead, it’s about encouraging exactly the opposite.

One of the most important things that OSGeo incubation does is ensure that a project is collaboratively developed. We seek for projects with a reasonably broad base of support, in terms of both developers and users. We seek to encourage community; our default project setup uses open, widely available collaborative development tools.

We host dozens of mailing lists. We have a single login account that gives access to the bug trackers for more than a dozen projects. We seek the broadest interaction between projects possible in order to foster a collaborative environment.

OSGeo is a really interesting case for this type of foundation work, because we have such a broad collection of projects despite the narrow scope. Databases. Web servers — both Map and other GIS related. Clients. Data manipulation libraries. Metadata catalogs. All of them interact at almost every stage of the process. Interoperability of this software is a key way to make the Open Source geospatial world more successful, and something we do relatively well.

So, if anyone ever asks you: What does OSGeo do? The answer, at its heart, is: “Support the collaborative development of open source geospatial software.” And I’m pretty thrilled with both the goal, and the success so far.

In the past, for tiling, we discussed tiling on an EOGEO list. In the meantime, OSGeo has grown up, EOGEO has moved on, and it seems that there isn’t a very good home for future tiling discussions.

As a result, I have added a tiling list to the OSGeo mailing list server.

Tiling List @ OSGeo

Projects that I hope to see people joining from: TileCache, Tirex, Mapproxy, GWC, others, etc.

This list will be discussing general tiling ideas — how to cache tiles, how to manage caches, how to work with limited caches, where to put your tiles, things like S3, etc. etc. If you are at all interested in tiling — not at the level of a specific application, but in general — please join the list.

Additionally, if you are interested in discussing providing feedback to the OGC regarding the WMTS spec — especially if you are an implementer, but also if you are a user — I would encourage you to join the standards list at OSGeo:

http://lists.osgeo.org/mailman/listinfo/standards

Several people have expressed interest in coordinating a response to the OGC regarding the spec, and we would like to work together on this list to coordinate.

Day 2 of the code sprint seemed to be much more productive. With much of the planning done yesterday, today groups were able to sit down and get to work.

Today, I accomplished two significant tasks:

• Setting up the new OSGeo Gallery, which is set to act as a repository for demos of OSGeo software users in the same way that the OpenLayers Gallery already does for OpenLayers. We’ve even added the first example.
• TMS Minidriver support for the GDAL WMS Driver: Sitting down and hacking out a way to access OSM tiles as a GDAL datasource, Schuyler and I built something which is reasonably simple/small — an 18k patch including examples and docs — but allows for a significant change in the ability to read tiles from existing tileset datasources on the web.

Other things happening at the sprint today were more WKT Raster discussions, liblas hacking, and single-pass MapServer discussions, as well as some profiling of MapServer performance with help from Paul and Shark. Thanks to the participation of the LizardTech folks, I think there will also be some performance testing done with MrSID rendering within MapServer, and there was — as always — more discussion of the “proj strings are expensive to look up!” discussion.

Other than that, it was a quiet day; lots of work getting done, but not much excitement in the ranks.

We then had a great dinner at Baton Rouge, and made it home.

This evening, I’ve been doing a bit more hacking, opening a GDAL Trac ticket for an issue Schuyler bumped into with the sqlite driver, and pondering the plan for OpenLayers tomorrow.

As before, a special thanks to the conference sponsors for today: Coordinate Solutions via David Lowther, and the lovely folks at SJ Geophysics Ltd.. Thanks for helping make this thing happen! I can guarantee that neither of those GDAL tickets would have happened without this time.

I’m here at the OSGeo Code Sprint in Toronto, where more than 20 OSGeo hackers have gathered to work on all things OSGeo — or at least MapServer, GDAL/OGR, and PostGIS.

For those who might not know, a code sprint is an event designed to gather a number of people working on the same software together with the intention of working together to get a large amount of development work done quickly. In this case, the sprint is a meeting of the “C tribe”: Developers working on the C-based stack in OSGeo.

After some discussion yesterday, there ended up being approximately 3 groups at the sprint:

• People targeting MapServer development
• PostGIS developers
• liblas developers

(As usual, I’m a floater, but primarily concentrating on OpenLayers; Schuyler will be joining me in this pursuit, and I’ve got another hacker coming Monday and Tuesday to sprint with us.)

The MapServer group was the most lively discussion group (and is also the largest). It sounded like there were three significant development discussions that were taking place: XML Mapfiles, integration of pluggable rendering backends, and performance enhancements, as well as work on documentation.

After a long discussion on the benefits/merits of XML mapfiles, it came down to there being one main target use case for the XML mapfile is encouraging the creation and use of more editing clients. With a format that can be easily round-tripped between client and server, you might see more editors able to really speak the same language. In order to test this hypothesis, a standard XSLT transform will be created and documented, with a tool to do the conversion; this will allow MapServer to test out the development before integrating XML mapfile support into the library itself.

I didn’t listen as closely to the pluggable renderers discussion, but I am aware that there’s a desire to improve support and reduce code duplication of various sorts, and the primary author of the AGG rendering support is here and participating in the sprint. Recently, there has been a proposal to the list to add OpenGL based rendering support to MapServer, so this is a step in that direction.

The PostGIS group was excited to have so many people in the same place at the same time, and I think came close to skipping lunch in order to get more time working together. In the end, they did go, but it seemed to be a highly productive meeting. Among some of their discussions was a small amount of discusssion on the WKTRaster project which is currently ongoing, I believe.

After our first day of coding, we headed to a Toronto Marlies hockey game. This was, for many of us, the first professional hockey we’d ever seen. (The Marlies are the equivilant of AAA baseball; one step below the major leagues.) The Canadians in the audience, especially Jeff McKenna, who played professional hockey for a time, helped keep the rest of us informed. The Marlies lost 6-1, sadly, but as a non-Canadian, I had to root a bit for the Hershey team. (Two fights did break out; pictures forthcoming.)

We finished up with a great dinner at East Side Mario’s.

A special thanks to our two sponsors for the day, Rich Greenwood of Greenwood Map and Steve Lehr from QPUBLIC! Our sprint was in a great place, very productive, and had great events, thanks to the support of these great people.

Looking forward to another great day.

OSGeo Users Group meeting in Boston tomorrow (well, it’s already tomorrow, but you know what I mean) night, 7pm at MIT Museum in Cambridge.

When: Wednesday, Oct 17th, 7PM
Where: MIT Museum, Downstairs, “MIT360” space,
265 Massachusetts Ave., Cambridge, MA
http://web.mit.edu/museum/
Boston Freemap
What: First Meeting of Boston OSGeo users group: intro, and maybe review of FOSS4G?
Who: Anyone interested in open source geo software
Why: Because it’s there!

I figure we’ll spend an hour or two getting to know people, talking about FOSS4G (for those of us who went… that might just be me), etc.

If you plan to be there, please respond to the list so people know to expect you! (A ‘maybe’ is fine.)

From an email I’ve been sending around:

As part of an effort to seek out Open Source Geo people in the Boston area, I’m canvassing the local community for interest in a regular open source geospatial interest group meeting.

For those of you who don’t know, OSGeo is a non-profit organization which is seeking to fulfill an umbrella organizational role for a number of Open Source Geospatial software projects, including projects like GeoServer and OpenLayers. It is currently entering its third year of operation, and has a number of projects undergoing incubation currently to become "OSGeo projects", including everything from uDig and QGIS to GRASS to GeoServer.

The goal of having regular meetings would be:

• Create Networking oppourtunities: allow users of open source geo software to meet with creators of open source geo software where possible.
• Share knowledge: meetings could have a presentation from a particular person on everything from how to use a certain tool, to types of data available, to anything else.
• "Chill out": spend social time with other like-minded individuals — either users of open source geosoftware, or just people interested in learning more about it.

Essentially, I personally envision this as being very similar to a Linux Users Group meeting: go someplace, here a 45 minute presentation with 15 minutes of questions on a particular related topic, then head out, get beers someplace, and relax.

If such a thing were to take place in the Bostonish area, would anyone in the area be interested in attending? Anything in particular that strikes your interest?

Looking forward to hearing from anyone interested in creating a local group of OS Geosoftware users…