The PostGIS geographic database
system is nearing its 2.0 release, a major update that adds several
significant new capabilities. PostGIS is an extension to the PostgreSQL
database manager that implements GIS-specific data types and
functions. Equally important, though, is the fact that a wide range of other open source geographic information system (GIS) projects can use PostGIS as a back-end data source, including GUI applications and servers. This 2.0 release is poised to be an important milestone not just for speed and stability reasons, but because it extends the database into three new areas: raster data, topology, and 3D.
PostGIS adds support for geometric primitives (points, lines, polygons,
as well as "collections" and other data structures of all three), plus
reading, transforming, and writing a vast array of standard geospatial data
formats. GIS applications often require special operators for calculating
distances and areas, unions, intersections, and other set functions, along
with specialized types of searches.
PostGIS implements this functionality by adhering to the Open Geospatial
Feature Access for SQL standard, although the project does not pay for
the compliance testing necessary to advertise itself as an official
implementation. PostGIS has been in active development since 2001, and
built up a notable library of supporting GIS applications, including GRASS GIS, gvSIG, and MapServer; there are even commercial connectors available to tie proprietary GIS products into PostGIS databases.
Still, in all this time, PostGIS has focused on what you might call traditional, vector-based, 2D geometry. One should not see this as a weakness; the majority of GIS applications are 2D and vector-based. Vector-based data encodes geographic features as shapes: points and polygons on a map projection, lines connecting features, and so on.
There is, however, a lot of data available as raster imagery, too
— aerial and satellite photographs, for example, which can be
geocoded so that they can be properly aligned and transformed to fit onto a
map. In recent years, the PostGIS community worked on raster support via
an add-on package originally named WKT Raster, which was later renamed PostGIS Raster.
With 2.0, its functionality will be fully integrated into the main application. Raster images are supported in special raster tables, which can be loaded from any format supported by the Geospatial Data Abstraction Library (GDAL), and exported to any GDAL-supported format. The list of supported formats is constantly growing, but at the moment the GDAL project lists more than 120.
Naturally, loading and exporting is not the real work of supporting
raster images in addition to vectors, so PostGIS 2.0 adds a slew of
functions for analyzing and operating on the data inside the pixels.
Rasters can be "extruded" into geometry (for example, turning regions of
one color in the raster image into a polygon), averaged, and otherwise
inspected. Rasters can be operated on with existing functions (such as calculating where they intersect with vector geometric shapes). It will also be possible to edit imported rasters in-place in the database, which opens the door to all sorts of transformations.
The third dimension
There is also no shortage of 3D data that could prove interesting to examine, if the data types to store it and the functions to transform it are available. PostGIS 2.0 adds extensive support for 3D, starting with two geometry types: polygonal surfaces and triangular irregular networks (TINs). Polygonal surfaces are just what you imagine them to be: three-dimensional surfaces defined by connected polygons. TINs define surfaces entirely with triangles, but the size of the triangles is flexible — somewhat like a multi-resolution mesh in a 3D modeling program. A TIN can use very few triangles to describe flatter areas of the map, and more to describe important features. In both cases, support for the new geometry consists not just of the basic data types, but the support operators to do recurring tasks like finding areas (and volumes) of regions in the new format.
In addition to the new geometry types, the existing spatial indices have been made 3D-aware, and a library of 3D-functions added. This will allow GIS users to calculate distances in three dimensions, find 3D intersections of lines and shapes, and return 3D bounding-boxes or calculate complex things like 3D shortest-paths.
The most straightforward application of 3D in GIS is to
model landscape features in three dimensions, but there are more. Many
other kinds of geo-coded data could be imported into a 3D PostGIS
database for modeling and analysis. Consider calculating line-of-sight
visibility between buildings, radio wave propagation, or flight vectors,
for example. All involve familiar GIS operations, in 3D, even though
they are not strictly "mapping"-related tasks.
How best to output 3D data is a question that remains largely the domain of the front-end application (more on that a bit later...), but PostGIS 2.0 is adding support for direct output of 3D data to the XML-based X3D format. X3D is defined by the Web3D Consortium, which is working hard to get the format accepted into HTML5. Whether or not HTML5 ever allows the inclusion of in-line X3D scenes within page content, however, the format is likely to get supported in
<canvas> elements or as embedded objects.
The last major extension of PostGIS functionality in the 2.0 release is support for topology. In GIS terms, topology is not a reference to topographical maps. Rather, it means supporting data types and functions that implement mathematical graphs. In other words, instead of points, lines, and polygons, topology uses nodes, edges, and faces — potentially even directed and/or weighted edges.
Transforming vector geometry into topology data makes what was a collection of shapes into a mathematical representation of the scene, including how nodes and regions are connected. The human eye can make those connections instantaneously, but the database requires explicit support for expressing them. Incorporating the topological version of a map layer in the database allows the application to perform path finding, routing, and flow analysis that cannot be done on raw geometry.
The canonical example of this distinction is the Königsberg bridge problem: a human mathematician (say, Euler, to pick one at random...) can look at a drawing of the city and its seven famous bridges and work out its graph as nodes and edges implicitly. A PostGIS application cannot do the same with just the shapes of the river and landmasses. The data must be converted first.
PostGIS 2.0 will be able to transform standard geometry into topological data, validate topology, and edit nodes and edges. Topology can also be converted to standard Geography Markup Language (GML) for output.
This step represents the beginning of topology support in PostGIS. The
future applications include network flow (such as traffic modeling), crisis
management for disaster planning (such as minimum spanning trees and shortest paths for logistics), auto-map-coloring, "covering" problems, and considerably more. Those of us not in the GIS field may tend to think of GIS work at the national-mapping scale, for instance, but consider how valuable topology support would make PostGIS for network flow analysis, or for routing utilities within a building.
Application support and additional enhancements
Features like topology and 3D are of limited value without support in the applications that use PostGIS. On that front, GRASS and gvSIG are the first to include topology, with others expected to follow. MapServer and QGIS, on the other hand, have raster layer support already. There may be more in the raster data support category that inherit their raster functionality from earlier support of the PostGIS Raster plug-in; the documentation is not always clear.
For 3D data, the only application that appears to be readying support at present is gvSIG, which is scheduled to include it in the next release. This will reportedly be 3D viewing support only. Several of the open source GIS blogs are excited about the possibilities of 3D, though, including its potential for integration with virtual reality or augmented reality. That seems to be a few steps away, however, as does the possibility of combining topology and 3D data.
The raster, 3D, and topology support slated for PostGIS 2.0 are not the database system's only new features. The blogs and mailing lists repeatedly mention the improvements to the TIGER geocoder, which imports data from the public domain map data gathered by the US Census Bureau, and broke when TIGER changed its format in 2010. There is also a new "reverse geocoder" function that takes a map point and returns nearby address data or street intersections, and a revamped GUI shape-file loader that for the first time can load several files at once. Finally, there are experimental builds for Windows for the very first time — in previous releases, Windows users had to compile PostGIS from scratch. The project has a complete list of new, enhanced, and deprecated functions in its online documentation.
There may still be more enhancements to come; PostGIS reportedly has not
yet declared its final feature freeze, and there are funded contractors
working on some important areas, 3D included. The final release is
officially expected in (northern hemisphere) "early spring," which of course is only a few days old at this point. In the meantime, the suitably daring can get test packages from the PostGIS site. With this many substantial new features, it may be worth taking an early look.
to post comments)