There’s a need for a good, high level description of the alternatives within in the “gently settling” stack of open source geoweb application development.

The OpenGeo Stack is the epitome of clarity, breaking down their tool set in a nice executive summary. But the OpenGeo stack only covers their tools, not all the available options. So I’m going to make a quick first pass of a high level overview. It’s useful for me, maybe for others. If you think I’ve done a poor job, help improve it in the comments, or on some wiki somewhere.

OpenGeo breaks things down into FrontEnd, Tiling, ApplicationFramework, Database. I’ll add Rendering, since in other tool sets this is split into different packages.

There really is a need for a new book on this stuff, the O’Reilly trio of paper geo titles are great but out of date, and the landscape of osgeowebappdev is stabilising. Of course, no one wants to write it.

6 Comments

mikel said,

It’s been pointed out that GeoServer really isn’t an app framework, but a very easy to configure, nice admin UI, server for raster and vector data, in all the geoweb formats. Could almost be thought of as mapserver+featureserver.

http://featureserver.org/ is almost like a reference implementation of GeoRESTful services, if REST actually needed a reference implementation.

So there’s definitely blurring and overlap between app frameworks, rendering, and vector services…

Hey Mikel,
Nice job on a first pass. I agree that there is a great need for this high level overview – thanks for raising the bar.

I’d recommend breaking out your categories out to include both Renderers, Mapping Frameworks, Application Frameworks, and Core Libraries, and then a special status for the blurring apps. This might help clarify and contrast the role that the ‘geostack’ plays in different projects and deployments.

For example, Django alone is a very complete and featured Web Framework and in combination with an OpenLayers Front End may be all a small mapping site needs. But having GeoDjango as a contributed package to Django (available in the standard source download), quickly blurrs the boundaries, and that’s the real magic. Rather than thinking in terms of ‘stacked’ components, GeoDjango provides synergy between geo tools, including GDAL, GEOS, and PostGIS. See this article for more background: http://www.geoconnexion.com/uploads/opensource_14_intv7i9.pdf

mikel said,

Totally agree that the stack concept breaks down under the most minimal of poking .. I’ve never really liked it! But there’s a need for this 10,000 foot view, how to do deal with that. Was trying to not mention the underlying libraries, as I figured these details would be hidden from most developers, and certainly decision makers. But maybe it’s unavoidable in explaining what a framework actually provides.

This is really a great list, thanks for linking to it and the OpenGeo stack. The more OS tools out there, the better for everyone. I agree with Dane, some sort of core libraries list would be really helpful, something that would contain GDAL/OGR, but also some less “core” but still vital list of tools. Maybe it’s time for a wiki.

mikel said,

Inge Wallin said,

If you just constraint yourself to the web, then this description is accurate. But don’t forget real applications that can also use and display tiles.

One such application is Marble (http://edu.kde.org/marble). It’s cross-platform and can run natively on Unix, Windows and Macintosh. Try it out! For some uses it’s much more versatile than any web browser solution.