PostGIS – a leading open source spatial database – has made significant strides in recent releases, including support for a round-earth model, better performance, and more complete support for curves. This week at FOSS4G, participants will explore how best to leverage these capabilities and look ahead to new ones, along with other open source geospatial technologies. So, this seemed a fitting time to reflect on a few of these new features.
Geography
When spatial data spans a large area, it’s often stored in latitude/longitude (with an appropriate regional or global datum). Effectively using this data requires a round-earth approach — otherwise areas and distances don’t make sense and you run into discontinuities around the poles and 180° meridian. With its new Geography type, PostGIS can store, query, and manipulate spatial data in a round-earth way. Two approaches are used: Some calculations (e.g., distance and area) are calculated mathematically, and others (e.g., buffer and intersection) are approximated via local, flat coordinate systems.
Curves
The SQL/MM-3 standard (which overlaps somewhat with OGC’s Simple Features Architecture) defines Well Known Text and Binary representations for curved paths and areas. It includes CircularStrings (sequences of circular arcs), CompoundCurves (sequences of circular arcs and lines), and CurvePolygons (areas bounded by curved paths); PostGIS supports all of the above.
One interesting limitation is that you can constrain a geometry column to a specific type (e.g. all Linestrings or all CircularStrings) but not to a generic type (e.g. all linear or all area geometries). This surprised me as I could imagine datasets containing a mix of lines and arcs (constraint to type Curve, unsupported), but couldn’t imagine many datasets consisting of all arcs and no lines (constraint to type CircularString, supported). This led me to challenge my earlier assumption that users frequently used geometry type constraints – is it that few users are interested in curves, or that few users are interested in geometry type constraints? I’d love to hear from you: How often do you constrain geometry columns to specific types? Are you using curved data? Does this limitation matter to you?
Community and Interoperability
In addition to releasing software, the PostGIS team has made significant contributions to interoperability in the wider geospatial landscape. For example, Paul Ramsey’s advocacy for the longitude/latitude ordering of geographic data (in a specific context) played a role in Microsoft’s round-earth implementation, reinforced an de facto standard, and made it easier to exchange this kind of data. I have also enjoyed Paul’s technical contributions on subjects such as “empty” geometries and challenges with round-earth data.
I’d also be remiss if I didn’t point out some new developments to how our own software (FME) works with PostGIS, including making it easy to load your data into these new PostGIS data types. Mark Ireland has a great summary of these enhancements and touches on updates to four key areas: geodetic data, Unicode, measures, and geometry model enhancements.
So I’m curious. How are you making the most of PostGIS?
Paul Nalos
