On Thu, Sep 13, 2012 at 5:25 AM, Marco Neumann <marco.neum...@gmail.com> wrote: > On Thu, Sep 13, 2012 at 8:19 AM, Andy Seaborne <a...@apache.org> wrote: > >> On 12/09/12 23:10, Marco Neumann wrote: >> >>> I would say yes the interesting bits are done by JTS. we used another LGPL >>> index for geosparql.org. >>> >>> I think Jena deserves a dedicated file based indexer to support the full >>> OGC geosparql standard but that said the task should not be >>> underestimated. >>> >> >> (a certain amount for recall from my last look at GeoSPARQL ...) >> >> There are four parts: >> >> 1/ Persistent index (r-tree, quadtree,...) >> >> 2/ Algorithms + Geo objects layer >> inc parsers and a Java library to handle geo data >> >> 3/ GeoSPARQL specifics - transformation, query rewrite etc etc >> >> 4/ Creating the index, either externally or coupled to a dataset. >> >> There don't all have to be perfect and complete on day 1 to provide users >> with useful GeoSPARQL capability. For example, an in-memory index gets a >> certain amount of scale over brute force search of all data and not all >> uses are a billion polygons. >> >> >> Parliament? >> opensahara->useekme (uses JTS inside?) >> > > parliament uses postgres for the spatial filter >
Actually Parliament can use several back-ends. I believe the default at this point is a library from the Deegree project (LGPL). See the previous thread [1] for a little more background. -Stephen [1] http://markmail.org/message/6v7q6nhpd2xleyvs
