PostGIS spatial extensions - Mailing list pgsql-hackers

Tom Lane wrote:
>
> [ why is this thread hiding in -patches?  It should be on -hackers or
>   -general, methinks. ]
>
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Let me suggest a solution.  What if we took the part of the GIS code
> > that duplicated our existing code (geometric types) and replaced what we
> > had in the core distribution with the GIS version.
>
> This is a complete nonstarter unless the GIS guys are willing to accept
> BSD licensing of that part of their code; which I doubt given Paul's
> prior comments.
>
>                         regards, tom lane

Hi Tom,
I have discussed this with Dave Blasby, who has done all of the
programming to date (and will no doubt pop up here soon to put his oar
in). There are a few issues germain to us in this:

1) Protection of important intellectual property under the GPL so that a
core of geospatial algorithms can begin to coallesce.
2) Promotion of PostGIS as a central OpenGIS component (the University
of Minnesota Mapserver is another) which will hopefully bring our
business some consulting work over time.
3) Promition of PostgreSQL/PostGIS as an open-source alternative to
things like OracleSpatial or SDE/Oracle.

Our feeling is that the basic database objects and their hooks into GiST
are not the core of IP we are interested in protecting. The most
important code for PostGIS and open source GIS is not yet incorporated:
it is the overlay, union, binary predicate algorithms specificed by the
OpenGIS spec. Those are the bits we want to have GPL'ed. We are not
averse to having the objects and spatial indexing under BSD and in the
core pgsql distribution, but would like the rest of the OpenGIS Simple
Feature Spec to be part of a GPL package (the functions, the supporting
triggers and consistency maintainance devices, blah blah blah).

So,

1) we can do by maintaining the important OpenGIS algorithms in an
external package while the objects and indexes are brought into the
pgsql main tree
2) and 3) are better served by being part of the main tree, where
everyone can use the main objects, and the savants can learn about
OpenGIS and move on to the complete package.

Now, why would you want these objects?

- they are toastable, so one of the big GIS usability bugaboos with the
old geometries
- they are indexable, using GiST, and do lossy indexing so "large
polygon" bugaboo is not a problem
- they follow an existing spec for GIS-in-a-database
- they support polygons-with-holes
- 3d coordinates supported

Why don't you want these objects?

- some of the existing funcionatily is missing, because it is not in the
OpenGIS spec
- no circles, or arcs
- different canonical representations (EG, a point is 'POINT(1 2)' not
'(1,2)'
- superannuation of alot of the operator notation
in short...
- not backward compatible

I'm sure there's other reasons as well.

Something I would like Dave to comment on is how cleanly we can split
the object/indexing from the OpenGIS spec'ed support tables and
reference systems. I am thinking about the canonical representation in
particular, which could be pretty ugly with the SRS id's hanging in
there for no purpose. The OpenGIS spec is at
http://www.opengis.org/techno/specs/99-049.pdf