I think it would be great for PostgreSQL to be an 'OpenGIS Simple
Feature Specification for SQL' compliant database with robust spatial
operators right-out-of-the-box.
Currently, PostGIS implements most of the OpenGIS specification. The
unimplemented portions are the important; spatial operators (the DE-9IM
spatial relationship matrix) and boolean functions (union, intersection,
XOR, etc…). Since these are extremely difficult algorithms, the PostGIS
team will probably translate the JTS (Java Topology Suite) to C++. The
JTS is a soon-to-be-released robust Java implementation of the OpenGIS
simple feature type. Vivid Solutions (cf.
http://www.vividsolutions.com/jts/jtshome.htm) will be releasing it
under the LGPL. JTS is the only open-source robust spatial library I've
ever heard of. The PostGIS developers and Vivid Solutions want this to
remain Free Software and not be co-opted and closed.
Since PostgreSQL cannot have LGPL code in its core, this would make it
impossible to ever have a fully-compliant PostGIS in its core. In fact,
its unlikely that anyone will spend the huge effort required creating a
BSD equivalent spatial library when there is already a LGPL one
available.
This leaves the option for creating a semi-compliant OpenGIS core inside
PostgreSQL and having a LGPL add-on for the complex spatial operations
(making a fully compliant implementation).
The next question is, of course, what does 'semi-compliant' mean? Or,
more interesting, why would you want a semi-compliant database? For
most people's simple tasks, the built in geometry types are adequate.
Those interested in doing more complex tasks will probably want the full
OpenGIS implementation.
A few people have suggested that we simplify PostGIS, release it as BSD,
and use that in the core of PostgreSQL. The simplified PostGIS would
have the basic types, indexing, and a few operations (those following
PostGIS development, this is very much like version 0.5 and earlier).
The 'full' PostGIS (with JTS) would have the entire OpenGIS spec.
Unfortunately, this is easier said than done. The full implementation
requires a properly maintained metadata table (with information about
every geometry column in the DB), a spatial referencing system table
(info about each map projection used), and each geometry must have
spatial referencing information. The JTS may also require precision
grid (offset/scale) information in each geometry. This would make it
really difficult (and confusing) to upgrade to the fully compliant
version from the partially compliant version - friction I don't want.
Secondly, as paul has already pointed out, there wouldn't be very many
operations you could do on these objects.
dave
For those reading the OpenGIS spec, PostGIS is most accurately described
as "SQL92 with Geometry Types Implementation of FeatureTables".
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
