OpenGeo

Since our first release of the OpenGeo Suite in January, our team has been working consistently to improve and refine the software. Much of this was based on feedback from our users, leading us to create a Community Forum where users can share their ideas and solutions. We have been periodically releasing a free Community Edition of the OpenGeo Suite, both as a testing environment for new features, and as a way for users to get the very latest in our technology.

Today, we release version 2.0 of the OpenGeo Suite Enterprise Edition. Here are just some of the many new features that comprise this software:

• Fully integrated PostGIS, including the new pgShapeLoader, a graphical shapefile loading utility.
• A new application, GeoEditor, that allows for web-based editing of geospatial features.
• New code samples and recipes to help you design your own mapping applications.
• Individualized packages of each application to integrate with an existing IT infrastructure.

And of course, all components are updated to the most recent stable version: PostGIS 1.5.1, GeoServer 2.0.2, GeoWebCache 1.2.2, and GeoExt 0.7.

With the OpenGeo Suite, you have all you need at your disposal to publish your data and maps on the web, as well as create virtually any web-based geospatial application for your organization. We hope that the new version 2.0 of the OpenGeo Suite will make your work even easier.

Register now to get your copy of the OpenGeo Suite 2.0. And please let us know what you think.

We have been hard at work on improving the OpenGeo Suite. Part of our development process is to make interim releases available as Community Edition downloads.  These downloads are functional and ready to try out, but they could still use some more testing. Please download and try out the latest Community Edition and give us feedback on our new community forum.

And you definitely want to try out this new release. Why? Check out some of the new features:

• PostGIS is now integrated into the OpenGeo Suite install experience! You now get a complete spatial mapping stack: database, map server, tile cache, web interface. Or, in project terms: PostGIS, GeoServer, GeoWebCache, OpenLayers, GeoExt!
• pgShapeLoader, a graphical interface for loading shapefiles into your PostGIS database
• pgAdmin a graphical interface for database administration.
• GeoEditor, a web application. GeoEditor allows for web based editing of data, regardless of the underlying data format (shapefiles, PostGIS, ArcSDE, Oracle Spatial, DB2, etc.). This offers a great opportunity to integrate web based applications with traditional GIS workflows.

We currently have one-click installers available for Windows and Mac OS X. We will be adding an installer for Linux very soon.

It’s worth noting what you’re getting with the OpenGeo Suite. With a simple and quick installation, you have the functional equivalent of ArcGIS Server and Oracle Spatial.

Download the OpenGeo Suite Community Edition

Robert Haas has a nice post looking forward to the release-after-this-one of PostgreSQL (the next release will be 9.0, but Robert is looking towards 9.1). He contextualizes his ideas like this:

But I think it might be good to step back and look at the problem a bit more broadly. Ignoring for a minute what people actually are working on, what should they be working on? Where is PostgreSQL strong as a product and where does it need improvement?

I strongly recommend you go read Robert’s ideas on new features, but here are my favorites, from the point of view of making PostGIS even better:

• KNNGiST, almost made it into 9.0, an extremely important feature to allow PostGIS to do index-assisted nearest neighbor searches (”find the N closest items to this item”).
• Formal packaging system for extensions. Right now there is no way to distinguish functions installed by PostGIS with other functions installed by the user. So an “uninstall PostGIS” routine, or a “backup everything but not the PostGIS functions” has to be needlessly complex.
• Framework for multi-threading. PostGIS is on the front-lines of database functions needing a standardized system for doing parallel processing. Calculations like point-in-polygon are easily parallelizeable, but it would be nice to do so in a way that is standard for PostgreSQL. Also, aggregate calculations are also often susceptible to parallel processing.

What features are you dreaming of for PostgreSQL and PostGIS? Maybe it is something on the core development menu for PostGIS already.

Update: We’re here! Look for Paul Ramsey and Sophia Parafina on stage at Ignite on Tuesday. Paul will also be at the OSGeo booth intermittently throughout the event!

I’m looking forward to this year’s Where 2.0 in San Jose coming up in three weeks! Where is always a different mix of folks from a usual GIS show, and the Silicon Valley vibe is something you can only get… well, in Silicon Valley.  I am going to be teaching a workshop with Steve Citron-Pousty on the open source geospatial stack, using our own OpenGeo Suite for a big part of the software we show.

If you’re coming to Where 2.0 and want to talk about OpenGeo in general or PostGIS in particular, please let me know! Either drop me an email or hit my Where 2.0 profile.

In preparing some data for our next round of training courses, I spent a fair amount of time today processing and cleaning the US Federal Electoral Commission (FEC) database for 2008. The FEC is extremely good about releasing their data, even though it looks like they have to dump it out of a very old database system.

I processed the three main files, and then converted the associated code tables into side tables, so the whole thing is pretty self-contained and hopefully self-explanatory. I had originally hoped to fully replicate something like the FundRace site from 2008, but since the FEC data only has zip-code as a location entity, that is not going to happen this time around. I assume the FundRace folks also had access to a nationwide telephone directory or some other way of taking name and zip-code and using that to leverage out an actual street address.

If you are interested in playing with the FEC data and don’t feel like spending a couple hours mucking about in Perl to get it into tables, I’ve placed a PostgreSQL dump file online. Candidates are linked to individuals via committees. The FEC model has a lot of complexity hiding in it, with some committees not associated with candidates, and so on, so using the data correctly will probably require a little care.

Update: The FundRace folks did in fact only use FEC data, the trick is, they used the original filings, rather than the FEC database dump. The original filings include a street address for each donation.

On Thursday, the latest major release of PostGIS came out: version 1.5.  This release adds a long-wished-for feature to the open source spatial database—direct support for “geodetic” coordinates.

Geodetics are more commonly known as “lat/lon” coordinates. While you could load and work with lat/lon coordinates in earlier versions of PostGIS, the indexing and calculation code did not make any allowance for the fact that the coordinates were angular units, not cartesian units. As a result, objects that crossed the poles or datelines would not index properly, and calculations of areas, lengths and distances returned strange looking answers in “degrees” rather than meters.

With PostGIS 1.5, the new “geography” type is a 100% sphere-aware type, which can be indexed globally and returns answers in meters, using calculations on the spheroid for maximum correctness. It is built on top of a new disk storage and index format, which the existing “geometry” type will also transition to in version 2.0.

The development of the “geography” type was funded as a PostGIS core development task, by a company that chooses to remain anonymous.  Since the main geography development is complete the old task has been updated to a new version, outlining extra functions and performance additions that could be added to geography support.

We expect that the geography type will make it easier for new users to store their data in PostGIS (without having to learn about projections and coordinate systems before starting) and also allow global data managers to store and query international data sets for effectively.

GEOS, the geometry engine underneath the PostGIS spatial database (part of the OpenGeo Suite), has achieved a version 3.2.0 release! The latest release includes performance improvements in buffering, general C++ performance improvements, and an implementation of single-sided buffering. PostGIS users who upgrade their GEOS will get all the performance improvements automatically. The upcoming release of PostGIS 1.5 (about which we are very excited) will also tie in support for the new single-sided buffers.

One of the items we launched with our new web site this spring was what we have been internally calling “the menu”, and ended up calling “core development“. The premise is that a generation of proprietary software experiences have broken customers of the idea that they can directly pay a vendor for a new feature — as customers we’ve been trained to just wait until the next version and hope.  But in an open source world, developers (us) are happy to work on new features directly for customers. So in our core development “menu” we try to provide customers with some guidance about what is possible, writing up some descriptions of larger development pieces and enumerating the functionality they would provide.

One of the items I put in my PostGIS menu last spring was “geodetic types“, native support for latitude/longitude coordinates that allows for indexing of features that cross the poles or dateline, provides direct calculation of distances and areas on the spheroid, and integrates with the other functions in PostGIS.  And a few months ago, that menu item was funded by a client!  We are currently approaching the final delivery date, the code is committed to the PostGIS SVN repository, and I’m spending the rest of the week testing and polishing.

Amazingly, the open source development started paying off almost immediately — I was getting testing and bug reports from third parties very early in the process, which means the final delivery will be that much stronger for the client. I’ve also added a large number of functions above and beyond those itemized in the contract terms, since this code is going to be in wide use as soon as it is released.

To get a feel for the functions that have been added, check out the documentation for the upcoming PostGIS release. For more technical details on using the new type, see this post.