<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Ooh look, it works in GeoServer as well!<br>
However, to start including it as a GeoServer extension it must be first<br>
become a GeoTools official module.<br>Any thoughts on that?<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Btw, did you many any performance comparison? How does it compare to<br>
shapefile or postgis in the case where one does not really need a<br>
topologic network?<br></blockquote><div><br></div><div>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 graph.</div>
<div><br></div><div>I will see if I can get some initial performance numbers out in time for the FOSS4G presentation, as they are clearly interesting.</div><div><br></div><div>Cheers, Craig</div></div>