Last September, I talked about some of the major recent additions to PostGIS, focusing on support for curves and a round-earth model. Now, with PostGIS 2.0 perhaps only a few months away, I’d like to highlight some of the interesting changes and improvements in store.
(Need a little more context? PostGIS is an open source spatial database: You can store spatial data, like river networks, property boundaries, or locations of bird nests, with all the power and simplicity of a traditional database. The project home page has a more detailed description and a number of case studies.)
Raster
Raster support has been available as an add-on to PostGIS for a few releases, but becomes a full citizen at 2.0. PostGIS has taken a unique approach to rasters (it’s more than just blob support, and different than e.g. Oracle or RasterLite), with a focus on rich vector/raster analysis. For example, you can intersect vector polygons with a raster DEM to compute average heights, easily and all in SQL. Rasters are converted to vectors (by grouping neighboring cells by value) and vectors into rasters (keeping overlaps and object identity intact) transparently as needed.
3D
PostGIS 2.0 adds support for Triangles, Polyhedral Surfaces (surfaces made up of polygon faces), and TINs (surfaces made up of triangle faces). Generally speaking, there are two kinds of TINs in GIS: one kind can represent closed objects but is limited to a moderate number of vertices, and the other is limited to terrain (with only one Z value for any given XY position) but scalable to an enormous number of vertices. PostGIS’ TINs are of the first kind, useful e.g. for modeling buildings in a city.
One of the things not part of 2.0, but of great interest to me, is a native point cloud support for LiDAR; it’s on their radar.
Breaking Changes
PostGIS 2.0 gives up some backwards compatibility in exchange for a cleaner, more consistent interface. This is perhaps an odd thing to highlight, but PostGIS — like our FME — has been vigilant about maintaining backwards compatibility over time. Ancient PostGIS SQL (or ancient “mapping file” scripts, or slightly-less-ancient workspaces in our case) will likely work with current versions (up to 1.x for PostGIS).
Sometimes maintaining backwards compatibility leads to awkward or inconsistent user experiences, and we’ve run into a few of those while working with PostGIS over the years (e.g., the different way geometry and geography columns are created, or the use of non-standard geometry type codes in WKB). The jump to 2.0 provides an opportunity to clean up these issues.
… and more!
Beyond these, there are other great improvements (like topology and reverse geocoding) worth checking out. Want to learn more? Last year’s FOSS4G presentations included quite a few updates on these PostGIS advances, and this year’s program is scheduled to be announced any moment. There’s also a wonderfully detailed overview of all things PostGIS 2.0 by Nathan Willis at lyn.net.
If you’re using PostGIS, what do you think about these soon-to-be enhancements? If not, have they piqued your interest?
Paul Nalos
