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
