[postgis-devel] Spatial DB in a Box - Postgresql Bindings

Craig Miller craig.miller at spatialminds.com
Fri Feb 18 12:09:14 PST 2005


I am going to play the devil's advocate here, but first let me say that I
think the idea has a lot of merit.  Having less code to maintain is always a
good idea, performance gains are always nice, and portability to other
databases is also pretty exciting.  Now onto the possible reasons not to do
this...

Will the use of GJC prevent a Windows version?

Is GEOS being dropped due to performance?  I thought GCC had been proven to
be faster than GJC.  Perhaps GEOS needs some TLC.

Will adding support for multiple databases ultimately result in an average
product that supports a lot of databases rather than a single optimized
product for a specific database (PostgreSQL)?
 
--Craig
 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
dblasby at openplans.org
Sent: Wednesday, February 16, 2005 2:45 PM
To: postgis-devel at postgis.refractions.net
Subject: [postgis-devel] Spatial DB in a Box - Postgresql Bindings

The original PostGIS (way back in 2001 - including all version up to
1.0) was based on my original ideas for putting spatial objects inside
postgresql.  These were known as "heavy weight geometries" (HWGEOM). 
There were several issues involving HWGEOMs - most notably was that
they were very big (memory size) and the implementation was difficult
to maintain.

Almost a year ago, I introduced the light-weight geometry (LWGEOM). 
This drastically reduced the size of the geometry objects and made
postgis somewhat more maintainable and extendable.  The 1.0 series of
releases are based on these lwgeoms.

I've been doing more thinking, and I've come up with a much much more
generic approach, which I'm calling "Spatial DB in a Box".  The idea is
very simple - use JTS (the Java Topology Suite) to handle all the
actual processing and use autogenerated code to handle the
communication between the database and JTS.


DATABASE <--> "glue" <--> JTS

The "glue" code is autogenerated.  This makes the system EXTREAMLY
maintainable since there's almost no code to actually maintain (see
"add a function" below). Also, any improvement made to ONE of the
supported database will find its way into ALL of the databases!

Martin Davis (the developer of JTS) has been madly adding functionality
and improvements to JTS, all of which will automatically be included in
all the "Spatial DB in a Box" databases.

You might be asking yourself how you can use a java library (JTS) in a
"C" program.  Well, I've figure out how to compile JTS (in fact any
java library) to an ".so/.dll" using GCC (GCJ).  Keeping with the
autogeneration theme, the C++ wrapper for JTS is also autogenerated.


Multiple databases can be 'spatialized'.  Currently, I have bindings
for:
PostgreSQL
Hsql (aka Hypersonic SQL)
Derby/Cloudbase

Basically, almost any database that allows for custom types and custom
functions can be easily supported.  I'd like to try this with Oracle,
and work with the MySQL folks to add real spatial functionality to
MySQL.
NOTE: MySQL doesnt allow for custom types, and its very difficult to add
custom functions so it needs a little help from the MySQL developers...

The current version is fairly simple, but supports almost all the OGC SF
SQL functions.  If you see one missing, its trivial to add it. See the
"postgresql bindings" and "add a function" below.


For more information on "Spatial DB in a Box", see:
http://docs.codehaus.org/display/GEOS/spatialDBbox

For more information on how easy it is to add functionality to all the
databases:
http://docs.codehaus.org/display/GEOS/Add+A+Function

For more information on compiling JTS, see:
http://docs.codehaus.org/display/GEOS/Compiling+JTS

For more information specific to the postgresql bindings:
http://docs.codehaus.org/display/GEOS/Postgresql+Bindings


Let me know what you think,
dave



----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel





More information about the postgis-devel mailing list