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

strk at refractions.net strk at refractions.net
Thu Feb 17 01:16:00 PST 2005


Hello Dave,
This sounds very interesting to me, mostly due to slowness of GEOS
compared with JTS (I wonder how fast would your method be).
Unfortunately all the links you included results in an:
"Oops - an error has occurred"
So I couldn't check anything. But the idea is cool.

--strk;

On Wed, Feb 16, 2005 at 05:44:40PM -0500, dblasby at openplans.org wrote:
> 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