Re: PostGIS spatial extensions - Mailing list pgsql-hackers
From | Dave Blasby |
---|---|
Subject | Re: PostGIS spatial extensions |
Date | |
Msg-id | 3B785B46.7765D28A@refractions.net Whole thread Raw |
In response to | PostGIS spatial extensions (Paul Ramsey <pramsey@refractions.net>) |
Responses |
Re: PostGIS spatial extensions
|
List | pgsql-hackers |
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".
pgsql-hackers by date: