Before PostGIS – 2000
Adding spatial capabilities to PostgreSQL is a project that seems redundant – after all, PostgreSQL already has “geometric types”. Unfortunately the native PostgreSQL geometric types, while interesting, are too limited for GIS data and analysis
Before PostGIS – 2000
Adding spatial capabilities to PostgreSQL is a project that seems redundant – after all, PostgreSQL already has “geometric types”. Unfortunately the native PostgreSQL geometric types, while interesting, are too limited for GIS data and analysis. They were built for academic research purposes and are more suitable for computer graphics than GIS use.
In 2000 and 2001, Refractions was doing data management and some systems work for a British Columbia government Ministry. Most things could be done easily enough with file-based storage, but a couple data sets were sufficiently changeable that managing the files was a pain – a versioned database would be so much easier, but how to store the spatial data?
The OpenGIS “Simple Features for SQL” document seemed to provide some basic recipes: normalize the geometries into the relational model; or, create a “geometry” object. The path of least resistance was to simply use the relational model, so we implemented that, and then wrote some scripts to load data.
Unfortunately, the overhead involved in tearing geometries apart for relational storage, and then putting them together again when extracting them was very high – the system was slow. So, in 2001, we turned our attention to building a geometry object instead.
Early PostGIS – May 2001
Government contracting has a certain rhythm, and the rhythm of the British Columbia government is dictated by the March 31 fiscal year-end. Prior to the year-end, consultants are very busy, and after the year-end, very idle. In 2001, we spent our after-fiscal idle time on the problem of building a spatial database in PostgreSQL using a custom
geometry type of our own invention.
We were lucky to be using PostgreSQL at this point, because the ability to add “custom types” is a core part of the PostgreSQL design, with both documentation and examples available in the
contrib directory of the source code.
The performance of the first implementation of a PostGIS
geometry type was better than we ever could have hoped. It was 100-times faster than the relational model to load and unload, and about 10-times faster than using the generic BLOB (binary large object) sub-system.
Now we needed a spatial index to allow fast queries of subsets of large tables. Fortunately, again, PostgreSQL already had examples available in the
contrib directory of R-Tree bindings to the GiST indexing subsystem. With the index in place, we were able to demonstrate millisecond access to features in multi-million record spatial tables.
We now had the basic components of a spatial data storage and retrieval system:
- spatial objects and standards-based text representations (OpenGIS “well-known text”) for loading and unloading;
- some basic introspection functions like Length() and Area();
- a simple JDBC extension component for input/output in Java; and,
- a spatial index for fast random access of the data.
These components made up the first release of PostGIS, version 0.1, which was made public on May 31, 2001.
- 0.1 – May 31, 2001
Released June 20, 2001, only three weeks after the initial cut, the 0.2 release primarily added documentation, so that users could figure out building and using the software more easily.
- 0.2 – June 20, 2001
The 0.2 release included a few functions for creating OpenGIS “well-known binary” formats as output from PostGIS. Frank Warmerdam noticed that these functions had exactly the same purpose as standard functions in the OpenGIS specification, but had different names. He suggested that PostGIS should follow the specification more exactly, and for 0.5, the old function names and all new functions were harmonized with the OpenGIS specification.
- 0.5 – July 21, 2001
In addition to the Mapserver support, the 0.5 release added a large number of the functions required by the OpenGIS specification. In fact, so much functionality was added that we decided to skip versions 0.3 and 0.4!
The 0.6 series of releases was focussed mainly on adding new functions in line with the OpenGIS specifications.
While the 0.6 series was coming out, a parallel development was occuring that would have a big effect on PostGIS. The British Columbia government had let a contract to develop an open source Java library of topological predicates, based on the same OpenGIS standards as PostGIS. The functions being added through 0.6 were the “low hanging fruit”, the really hard functions were the predicates and operators: Touches(), Intersects(), Contains(), Buffer(), Union() and Difference(). The first indication that this “JTS Topology Suite” was bearing fruit came in December 2001.
In 2002, the PostgreSQL team released version 7.2, which substantially changed the GiST index bindings in previous PostGIS versions, and forced us to release a new PostGIS series to support 7.2. The 0.7 series also included support for coordinate reference system transformations, and a more thorough approach to figuring out spatial index selectivity.
- 0.7.0 – May 5, 2002
- 0.7.1 – May 14, 2002
- 0.7.2 – September 4, 2002
- 0.7.3 – September 5, 2002
- 0.7.4 – February 13, 2003
While the 0.7 series wa