Hi Andy, I'm grateful to your advice. I think withinCircle and withinBox are both possible to be made. I've composed and submitted the project proposal to Apache GSoC 2013 here: https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/jpz6311whu/7003
Any comments are welcome! Best regards, Ying Jiang On Mon, Apr 29, 2013 at 9:08 PM, Andy Seaborne <a...@apache.org> wrote: > On 28/04/13 11:25, Ying Jiang wrote: >> >> 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? > > > 4.x, unless there is some good reason for needing 3.x; currently, I don't > see one. When starting a new piece of work, starting with legacy is just > overhead. > > >> 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: > > > For all these, framing a use case would be good. Maybe that's a > documentation matter :-) > > >> >> 1) ?A -> within -> B >> A: Point Var >> B: Rectangle or Circle >> Approach: PointVectorStrategy directly supports this > > > Can a circle be specified in the query as (point, radius)? > > The use case I can think of is wanting all places with a box or circle > centred on a given point. Maybe its what this does with "B" being > > ?point :withinCircle ( x,y,r ) . > > ?point :withinBox ( x1,y1,x2,y2) . > > SPARQL isn't going to be particularly pretty specifying boxes and circles > but probably better than a WKT/GML literal! > > >> 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! > > > (treat the fuseki task as a completely project - it can be 3m on its own - > don't mix it with spatial work - they are orthogonal). > > The next step is to write+submit the proposal. > > Andy > > >> >> 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 >>> >>> >>> >
