[SoC] uDig GSoC / final report

Craig Taverner craig at amanzi.com
Wed Aug 18 03:49:01 EDT 2010

> Ooh look, it works in GeoServer as well!
> However, to start including it as a GeoServer extension it must be first
> become a GeoTools official module.
> Any thoughts on that?

Yes, indeed. However an early decision in the project was to initially keep
the geotools components part of the neo4j-spatial library. This was mostly
because it was not completely clear up-front where to do the split, since we
were already using parts of geotools in the core. At some point the code
could be split and the geotools parts moved to geotools itself. Davide made
an initial split with the geotools DataStore and related parts in a separate
java package, so this should not be hard.

Btw, did you many any performance comparison? How does it compare to
> shapefile or postgis in the case where one does not really need a
> topologic network?

Unfortunately not. It has been on the radar for a long time, but no-one has
gotten 'round to that yet. I personally think that in principle it should be
able to outperform other systems in many ways. However, I doubt it will
outperform everything in every way. Some things are suited to graph
databases and others are less suited. One rule of thumb I have is that if a
query is likely to hit data that is close (in the graph), then it should
perform much better than a relational database (or be easy to optimize to
perform better). For this reason, our indices are simply additional graph
structures that make sure that spatial 'closeness' is represented in the

I will see if I can get some initial performance numbers out in time for the
FOSS4G presentation, as they are clearly interesting.

Cheers, Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/soc/attachments/20100818/ef41082c/attachment.html

More information about the SoC mailing list