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
>>>
>>>
>>>
>

Reply via email to