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

[strk at refractions.net]

I've handled to reach your "Compiling JTS" tutorial and 
compile the helloworld sample application.
It's impressive  (100% faster then equivalent GEOS).

Unfortunately I didn't have luck with step 2 of the tutorial
(building the TopologyTestApp):

gcj -O2 -classpath Acme.jar:jdom.jar:jts-1.5.jar:JTS_Test2.jar:xerces.jar:.:xml-apis.jar xerces.jar xml-apis.jar jdom.jar Acme.jar jts-1.5.jar JTS_Test2.jar  --main=com.vividsolutions.jtstest.testrunner.TopologyTestApp
com/vividsolutions/jts/io/WKTReader.java: In class `com.vividsolutions.jts.io.WKTReader':
com/vividsolutions/jts/io/WKTReader.java: In method `com.vividsolutions.jts.io.WKTReader.read(java.lang.String)':
com/vividsolutions/jts/io/WKTReader.java:113: warning: exception handler inside code that is being protected
com/vividsolutions/jts/io/WKTReader.java: In method `com.vividsolutions.jts.io.WKTReader.isNumberNext(java.io.StreamTokenizer)':
com/vividsolutions/jts/io/WKTReader.java:184: warning: exception handler inside code that is being protected

strk:~/src/jts/jts_compile$ ./a.out -Files validate_testfiles/
Segmentation fault

I'm using gcj-3.3.5 from debian sid (unstable).

--strk;


On Thu, Feb 17, 2005 at 10:16:00AM +0100, strk at refractions.net wrote:
> 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
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel