GeoServer : SpatialDBBox
This page last changed on Jul 31, 2006 by cholmes.
I've been thinking about a generic method for adding spatial capabilities to non-spatial databases. "Spatial DB in Box" is the result of this research.
The basic idea is two fold:
1. Any improvements to JTS algorithms are instantly realized in all Databases
The biggest advantage is that there is only one code base that all the databases derive from. When JTS maintainer Martin Davis adds or improves functionality, these changes automatically get wrapped into all the databases. If someone adds a "complex" spatial algorithm to one of the databases, that will also be available to all the DBs.
Martin has added significant functionality to JTS for versions 1.6 (like optimized rectangle queries, buffer algorithm improvements, and topology preserving simplification) and 1.7 (snap rounding - making the overlay operations mostly robust). Other projects (like geotools and the Java Conflation Suite (JCS)) have added other JTS-based functionality.
In fact, this method is generic enough that you can add non-spatial Java smarts to a database - like David Zwiers' fancy Geotools GML parser.
Since JTS is a Java application, you might think that it would not be accessible from non-java databases. I've solved this problem with GJC (the java plugin to the GCC compiler) - the results are very good. For more information see the Compiling JTS page and the Postgresql Bindings page.
The architecture is similiar for both cases - at the top is the actual smarts: JTS and any other java libraries. Only the StaticGeometry class interacts with this level.
StaticGeometry is a very simple class that has a bunch of static methods that call JTS. The original StaticGeometry class was auto-generated by walking around the JTS com.vividsolutions.jts.geom.* class hierarchy. To add more functionality to the databases, simply provide a function here. See Add A Function
For a non-Java database, an autogenerated C++ wrapper class is formed that will handle the interaction with the compiled Java code. This is formed by looking at what's inside the StaticGeometry class.
Finally, two more files are automatically created that are specialized for each supported database. The first one is code (java or otherwise) that the database will actually call to execute a function - it's simple code that passes the evalutation off to the StaticGeometry class. The second file is a set of SQL CREATE FUNCTION statements that tell the DB what functions it needs to call. These are formed by looking at what's inside the StaticGeometry class.
If you look at the Derby/Cloudscape implementation, you'll see:
If you look at the Postgresql bindings you'll see:
The hsqldb project is expecting to implement GiST indexing soon (which means that a spatial index will be available for hsqldb databases).
|Document generated by Confluence on May 14, 2014 23:00|