Conclusion

Compact jar file with source codes and javadoc was added to downloads section (Home/Compact repository/db4o-sp.jar).

Technical report will be available for download as soon as possible.

There are some observations from development which can be useful for other developers who want to implements its own spatial extension.

1) When you choose database for spatial extension, you need to determine the most useful information about it. Focusing mainly on the extension points, such as integration of its own indexing strategy, etc.

2) In the implementation of core, you should use principles of exact geometric computation. If it is possible, some robust EGC library should be used (for example CGAL or Core Library).

3) Basic geometric algorithms must be properly tested to ensure their correctness, because a lot of other algorithms are built on them.

4) The implementation should use algorithms as PlaneSweep or other fast algorithms wherever possible.

5) The integration layer should be independent on the geometric library and database as much as possible. If this succeeds, the developer has a high chance to replace the database.

6) If there is a possibility that the solution will be used in a disconnected environment, there should be given support for this in the form of methods for merging changes in objects. For this purpose you can use existing tools like Dozer, etc.

7) I would mention the need to comply with high usability. This means that you must know how potential users treat and provide them the most suitable solution.