Hi Andy, The link about the spatial relationships you provided is very interesting. I've tried to study Lucene to figure out whether they are possible to be implemented. Shall we use Lucene 4.x or 3.x? For the current release of Lucene 4.2.1, it provides a high level abstraction for spatial query usage. - SpatialOperation [1]: compares a stored geometry to a supplied geometry. such as "IsWithin" and "Intersects". Actually, all of them are not supported. - SpatialStrategy [2]: encapsulates an approach to indexing and searching based on shapes. Different implementations will support different features. There're 3 implementations [3] now: PointVectorStrategy, RecursivePrefixTreeStrategy and TermQueryPrefixTreeStrategy. For example, PointVectorStrategy supports only "IsWithin" for Rectangle or Circle, while RecursivePrefixTreeStrategy can caculate "Intersects" of any kinds of Shapes. I'd like to make full use of Lucene to make jena-text support as many spatial relationships as possible. On the other hand, I can also make new SpatialOperations like "Northing/Westing" mentioned in [4] that are not available in Lucene. To wrap things up, here're the jena-spatial features that I can do this summer:
1) ?A -> within -> B A: Point Var B: Rectangle or Circle Approach: PointVectorStrategy directly supports this 2) A -> nearby ->?B, C A: Point B: Point Var C: radius Approach: RecursivePrefixTreeStrategy makes SpatialOperation.Intersects for the Circle with the center of A and the radius of C 3) A -> intersects -> ?B A: any Shape B: non-Point Shape Var Approach: RecursivePrefixTreeStrategy directly supports this (note: not tested) 4) A -> intersects -> ?B A: any Shape B: Point Var Approach: TermQueryPrefixTreeStrategy directly supports this 5) A -> northing/southing/easting/westing -> B A: Point B: Point Approach: use rangeQuery, or RecursivePrefixTreeStrategy makes SpatialOperation.Intersects of north/south/east/west Rectangle 6) A -> disjoint ->B A: Rectangle B: Rectangle Approach: PointVectorStrategy directly supports this (note: it doesn't handle dateline cross) They are from a developer's view of whether it's possible to be implemented. It's grateful to hear any comments from users' opinions. Are they enough or useless for basic spatial queries? For the Fuseki task, I don't think it's suitable for me to work on this summer. Just like I mentioned in the first e-mail, I'm not a web application development guy. It would take some time for me to study Apache Velocity. I'm not very familiar with the client-side stuff of javascript/css. In this 3-month GSoC project, I'd like to be more focused on the jena-spatial design and development. If more spatial relationships are required to be implemented, I would be happy to work on. I'll come up with a project proposal if it's basically OK. Thanks for your consideration! Best regards, Ying Jiang [1] http://lucene.apache.org/core/4_2_1/spatial/org/apache/lucene/spatial/query/SpatialOperation.html [2] http://lucene.apache.org/core/4_2_1/spatial/org/apache/lucene/spatial/SpatialStrategy.html [3] http://lucene.apache.org/core/4_2_1/spatial/overview-tree.html [4] http://beta.data.ordnancesurvey.co.uk/ontology/spatialrelations/ On Fri, Apr 26, 2013 at 8:07 PM, Andy Seaborne <a...@apache.org> wrote: > On 26/04/13 04:34, Ying Jiang wrote: >> >> Hi Andy, >> >> Thanks for your explanations! I've got the idea of jena-spatial. I can >> create it following the way of jena-text, with 2 implementations of >> "nearby" and "within" at least. It's OK for this part. > > > This is interesting: > > http://beta.data.ordnancesurvey.co.uk/ontology/spatialrelations/ > > other spatial relationships (regions not just points) but less that full > GeoSPARQL. > > >> >> As to the Fuseki task, it does not aim at jena-spatial, is it? Do you >> mean the other Jena GSoC projects [1] [2]? I've checked the source >> code of Fuseki UI pages. Could you tell me what's the technology, e.g. >> "sparql.tpl"? What's "tpl"? > > > No - the Fuseki tasks are not jena-spatial related. It should be possible > to have a Fuseki server with spatial support by simply adding it to the > build/classpath. > > The .tpl files are Apache Velocity. Usually that's .vm but I thought > making the external name tied to the internal technology was a bad idea for > a server side technology (may, in theory, want to change the templating > system - they were JSPs). > > Andy > > >> >> [1] https://issues.apache.org/jira/browse/JENA-420 >> [2] https://issues.apache.org/jira/browse/JENA-427 >> >> Best regards, >> Ying Jiang > >
