You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2013/04/15 15:37:27 UTC
GSoC: Simple spatial query
=== Spatial query
JENA-10
Not all spatial queries are complicated. Many use case are covered by
provision of a single facility like get all objects within a given
radius or within a given bounding box. GeoSPARQL which is a complete
approach to geospatial query but it is complicated and driected more
towards the specialist, not the average linked data developer with
SPARQL knowledge.
This project is to provide a one or two basic geospatial query functions.
Example: return places within 10 kilometers of Bristol UK (which as
latitude/longitude of 51.46,2.6).
SELECT ?placeName
{
?place spatial:query (51.46 2.6 10) .
?place rdfs:label ?placeName
}
We have a similar property function architecture in jena-text [0] so
this project is to take that concept and apply it to geospatial
information.
Lucene spatial could be used for the spatial index. There is a simple
vocabulary for expressing WGS80 information [1]; there is also the point
information in WKT [2].
This project is not primarily about geospatial processing; it is
concerned with the indexing and querying simple, existing geospatial
data and integration with Fuseki.
[0] http://jena.staging.apache.org/documentation/query/text-query.html
[1] http://www.w3.org/2003/01/geo/
[2] http://en.wikipedia.org/wiki/Well-known_text
Re: GSoC: Simple spatial query
Posted by Ying Jiang <jp...@gmail.com>.
Hi Andy,
I agree with you. A consistent style of would be better. In the
project proposal, I just listed the features that we could do. As to
the property function names, the arguments and the styles, they can be
discussed and adjusted.
Best regards,
Ying Jiang
On Thu, May 2, 2013 at 7:30 PM, Andy Seaborne <an...@apache.org> wrote:
> On 30/04/13 16:44, Ying Jiang wrote:
>>
>> 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!
>
>
> Well - it has made it in the system and is in the Apache area.
>
> Nothing I can see needs changing.
>
>
>
> One minor comment:
>
> 2.2 could be folded into the style of 2.1. This is the sort of detail that
> chnages as we gain experience with usage of the system.
>
> If the query can be
>
> ?point :withinCircle (?X radius)
>
> and ?X a literal of datatype point 2.1 and 2.2 are very similar.
>
> It's a bit weird to change the operation just on the fixed syntax of 2 or 3
> arguments so maybe two property functions
>
> ?point :withinDistance (point radius)
>
> ?point :withinCircle (?X radius)
>
> is clear to the user and the two property functions go to much the same
> code. But this is a minor change.
>
> Generally a consistent style of
>
> ?output :property (arguments.)
>
> As stated, 2.2 puts the output on the right.
>
> RDF lists don't have comma in - eventually, the brain reprograms eventually
> to cope, but not sure mime has. Ditto SELECT lists. :-)
>
>
> Andy
>
>>
>> Best regards,
>> Ying Jiang
>>
>> On Mon, Apr 29, 2013 at 9:08 PM, Andy Seaborne <an...@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 <an...@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
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
Re: GSoC: Simple spatial query
Posted by Andy Seaborne <an...@apache.org>.
On 30/04/13 16:44, Ying Jiang wrote:
> 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!
Well - it has made it in the system and is in the Apache area.
Nothing I can see needs changing.
One minor comment:
2.2 could be folded into the style of 2.1. This is the sort of detail
that chnages as we gain experience with usage of the system.
If the query can be
?point :withinCircle (?X radius)
and ?X a literal of datatype point 2.1 and 2.2 are very similar.
It's a bit weird to change the operation just on the fixed syntax of 2
or 3 arguments so maybe two property functions
?point :withinDistance (point radius)
?point :withinCircle (?X radius)
is clear to the user and the two property functions go to much the same
code. But this is a minor change.
Generally a consistent style of
?output :property (arguments) .
As stated, 2.2 puts the output on the right.
RDF lists don't have comma in - eventually, the brain reprograms
eventually to cope, but not sure mime has. Ditto SELECT lists. :-)
Andy
>
> Best regards,
> Ying Jiang
>
> On Mon, Apr 29, 2013 at 9:08 PM, Andy Seaborne <an...@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 <an...@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
>>>>
>>>>
>>>>
>>
Re: GSoC: Simple spatial query
Posted by Ying Jiang <jp...@gmail.com>.
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 <an...@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 <an...@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
>>>
>>>
>>>
>
Re: GSoC: Simple spatial query
Posted by Andy Seaborne <an...@apache.org>.
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 <an...@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
>>
>>
Re: GSoC: Simple spatial query
Posted by Ying Jiang <jp...@gmail.com>.
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 <an...@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
>
>
Re: GSoC: Simple spatial query
Posted by Andy Seaborne <an...@apache.org>.
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
Re: GSoC: Simple spatial query
Posted by Ying Jiang <jp...@gmail.com>.
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.
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"?
[1] https://issues.apache.org/jira/browse/JENA-420
[2] https://issues.apache.org/jira/browse/JENA-427
Best regards,
Ying Jiang
On Tue, Apr 23, 2013 at 8:26 PM, Andy Seaborne <an...@apache.org> wrote:
> On 22/04/13 13:50, Ying Jiang wrote:
>>
>> Dear Andy,
>>
>> Sorry for the late reply. These days, I've been studying the source
>> code of Jena pfunction, LARQ, jena-text and GeoARQ. Now I can
>> understand all of them by every single code line :). This summer, I
>> think I can take the concept of jena-text and make a similar one
>> applied to geospatial information. I'd like to compose a project
>> proposal when the GSoC website opens for the student applications.
>> Before that, could you please help me with the following questions:
>>
>> 1) It seems LARQ and jena-text provide the same functions of text
>> searching. If we have LARQ, why bother to use jena-text? What're the
>> differences of the goals, the users, the use scenarios? I also have
>> the same doubt with GeoARQ and the product of this GSoC project, since
>> GeoARQ already provides the "near" and "within" functions.
>
>
> LARQ / jena-text:
>
> Think of jena-text as "LARQ v2". The LARQ 1 internal design is quite old
> and does not play so well with RDF datasets and update, as well as adding
> assembler capabilities because currently LARQ 1 needs some coding work to
> integrate with Fuseki.
>
> GeoARQ is not specifically related to the formal Jena project.
>
> What I had in mind for jena-spatial is exploiting the spatial capabilities
> of Lucene to create a fully integrated capability that we can add to the
> main download when it's stable. As many of the "nearby" or "bounding box"
> queries for point spatial data. Geospatial stretched to much more
> complicated relationships but I believe that a lot of useful things can be
> done with less than the full geospatial model which is too complicated for
> the average web developer to take on board with their limited time.
>
>
>> 2) For the integration with Fuseki. What do you mean by "a better
>> Fuseki UI"? Does UI here mean client-side javascript/css work? Can you
>> tell me more details about this part?
>
>
> (My take - others may have a different view)
>
> A management/admin interface to running a Fuseki server. Add and remove
> datasets to a running engine, report statistics (see e.g. Solr's web
> interface and stats page).
>
> An orthogonal matter is improved query and update forms. Those are good -
> it is the admin and control that I think will really help people in
> deploying data publishing systems for real use.
>
>
>> 3) Is there a GSoC project proposal template for Jena? Basically, it
>> should include self-introduction, project goal, project plan, etc, I
>> think. What's your opinion?
>
>
> All those things!
>
> There isn't a official proposal form for Jena but all those things you have
> on the list are good.
>
> (Stephen - any more that needs to be done?)
>
> Do ask more questions for anything you need,
>
> Andy
>
>
>
>>
>> Best,
>> Ying Jiang
>>
>> On Tue, Apr 16, 2013 at 8:32 PM, Andy Seaborne <an...@apache.org> wrote:
>>>
>>> This is a potential GSoC project - I'd see it firstly being a separate
>>> codebase as it develops, then get some people using it and providing
>>> feedback and, if it's popular, it can move into Jena proper. The nice
>>> thing
>>> is that doesn't (err "shouldn't") require modifications to the main
>>> modules
>>> as it should use standard extension mechanisms. However, if the
>>> mechanisms
>>> prove inadequate, we can fix the extension mechanisms.
>>>
>>> This is the very similar to the status of jena-text - it's in
>>> /Experimental
>>> so anyone can look, use and contribute but it's not in the Jena
>>> distribution. If and when it's considered stable, it could become part of
>>> trunk. That's a group decision to be made.
>>>
>>> The project is also open ended depending on how "simple" it is. There
>>> are
>>> some jumps in going from, say, points to polygons in the data that I
>>> think
>>> are just too big for the GSoC timeframe but there are potential
>>> additional
>>> query functions to just "near".
>>>
>>> At least look at GeoSPARQL [1] to see what a complete solution looks
>>> like.
>>> I think that the sweet spot is something simpler (and less capable)
>>> because
>>> the average web developer, even if writing SPARQL, isn't looking for a
>>> complete solution to all geospatial use cases. They are looking for
>>> something easier (= smaller). There is space for both approaches.
>>>
>>> Being able to use Lucene-spatial for the index, and have it instep with
>>> the
>>> data, rather than an external rpcoess like PostGIS (c.f. Parliament)
>>> makes
>>> it much more usable.
>>>
>>> It also avoids some licensing issues - some geo libraries are GPL,LGPL
>>> which
>>> makes them unsuitable for Apache.
>>>
>>> Combine this with any work on a better Fuseki UI, and we have a nice,
>>> easy-to-use SPARQL server that gets people up and running with
>>> interesting
>>> features beyond basic RDF storage and query.
>>>
>>> Andy
>>>
>>> [1] http://www.opengeospatial.org/standards/geosparql
>>>
>>>
>>>
>>> On 15/04/13 22:52, Gyanasekaran Radhakrishnan wrote:
>>>>
>>>>
>>>> This is an awesome idea which could be extensively used if implemented
>>>> (I
>>>> would!). Is this going to be a stand-alone project for GSoC? I would be
>>>> interested in working in this.
>>>>
>>>> Thanks
>>>> ~Gyan
>>>>
>>>>
>>>> On Mon, Apr 15, 2013 at 9:37 AM, Andy Seaborne <an...@apache.org> wrote:
>>>>
>>>>> === Spatial query
>>>>> JENA-10
>>>>>
>>>>> Not all spatial queries are complicated. Many use case are covered by
>>>>> provision of a single facility like get all objects within a given
>>>>> radius
>>>>> or within a given bounding box. GeoSPARQL which is a complete approach
>>>>> to
>>>>> geospatial query but it is complicated and driected more towards the
>>>>> specialist, not the average linked data developer with SPARQL
>>>>> knowledge.
>>>>>
>>>>> This project is to provide a one or two basic geospatial query
>>>>> functions.
>>>>>
>>>>> Example: return places within 10 kilometers of Bristol UK (which as
>>>>> latitude/longitude of 51.46,2.6).
>>>>>
>>>>> SELECT ?placeName
>>>>> {
>>>>> ?place spatial:query (51.46 2.6 10) .
>>>>> ?place rdfs:label ?placeName
>>>>> }
>>>>>
>>>>>
>>>>> We have a similar property function architecture in jena-text [0] so
>>>>> this
>>>>> project is to take that concept and apply it to geospatial information.
>>>>>
>>>>> Lucene spatial could be used for the spatial index. There is a simple
>>>>> vocabulary for expressing WGS80 information [1]; there is also the
>>>>> point
>>>>> information in WKT [2].
>>>>>
>>>>> This project is not primarily about geospatial processing; it is
>>>>> concerned
>>>>> with the indexing and querying simple, existing geospatial data and
>>>>> integration with Fuseki.
>>>>>
>>>>> [0]
>>>>>
>>>>> http://jena.staging.apache.**org/documentation/query/text-**query.html<http://jena.staging.apache.org/documentation/query/text-query.html>
>>>>> [1] http://www.w3.org/2003/01/geo/
>>>>> [2]
>>>>>
>>>>> http://en.wikipedia.org/wiki/**Well-known_text<http://en.wikipedia.org/wiki/Well-known_text>
>>>>>
>>>>
>>>
>
Re: GSoC: Simple spatial query
Posted by Andy Seaborne <an...@apache.org>.
On 22/04/13 13:50, Ying Jiang wrote:
> Dear Andy,
>
> Sorry for the late reply. These days, I've been studying the source
> code of Jena pfunction, LARQ, jena-text and GeoARQ. Now I can
> understand all of them by every single code line :). This summer, I
> think I can take the concept of jena-text and make a similar one
> applied to geospatial information. I'd like to compose a project
> proposal when the GSoC website opens for the student applications.
> Before that, could you please help me with the following questions:
>
> 1) It seems LARQ and jena-text provide the same functions of text
> searching. If we have LARQ, why bother to use jena-text? What're the
> differences of the goals, the users, the use scenarios? I also have
> the same doubt with GeoARQ and the product of this GSoC project, since
> GeoARQ already provides the "near" and "within" functions.
LARQ / jena-text:
Think of jena-text as "LARQ v2". The LARQ 1 internal design is quite
old and does not play so well with RDF datasets and update, as well as
adding assembler capabilities because currently LARQ 1 needs some coding
work to integrate with Fuseki.
GeoARQ is not specifically related to the formal Jena project.
What I had in mind for jena-spatial is exploiting the spatial
capabilities of Lucene to create a fully integrated capability that we
can add to the main download when it's stable. As many of the "nearby"
or "bounding box" queries for point spatial data. Geospatial stretched
to much more complicated relationships but I believe that a lot of
useful things can be done with less than the full geospatial model which
is too complicated for the average web developer to take on board with
their limited time.
> 2) For the integration with Fuseki. What do you mean by "a better
> Fuseki UI"? Does UI here mean client-side javascript/css work? Can you
> tell me more details about this part?
(My take - others may have a different view)
A management/admin interface to running a Fuseki server. Add and remove
datasets to a running engine, report statistics (see e.g. Solr's web
interface and stats page).
An orthogonal matter is improved query and update forms. Those are good
- it is the admin and control that I think will really help people in
deploying data publishing systems for real use.
> 3) Is there a GSoC project proposal template for Jena? Basically, it
> should include self-introduction, project goal, project plan, etc, I
> think. What's your opinion?
All those things!
There isn't a official proposal form for Jena but all those things you
have on the list are good.
(Stephen - any more that needs to be done?)
Do ask more questions for anything you need,
Andy
>
> Best,
> Ying Jiang
>
> On Tue, Apr 16, 2013 at 8:32 PM, Andy Seaborne <an...@apache.org> wrote:
>> This is a potential GSoC project - I'd see it firstly being a separate
>> codebase as it develops, then get some people using it and providing
>> feedback and, if it's popular, it can move into Jena proper. The nice thing
>> is that doesn't (err "shouldn't") require modifications to the main modules
>> as it should use standard extension mechanisms. However, if the mechanisms
>> prove inadequate, we can fix the extension mechanisms.
>>
>> This is the very similar to the status of jena-text - it's in /Experimental
>> so anyone can look, use and contribute but it's not in the Jena
>> distribution. If and when it's considered stable, it could become part of
>> trunk. That's a group decision to be made.
>>
>> The project is also open ended depending on how "simple" it is. There are
>> some jumps in going from, say, points to polygons in the data that I think
>> are just too big for the GSoC timeframe but there are potential additional
>> query functions to just "near".
>>
>> At least look at GeoSPARQL [1] to see what a complete solution looks like.
>> I think that the sweet spot is something simpler (and less capable) because
>> the average web developer, even if writing SPARQL, isn't looking for a
>> complete solution to all geospatial use cases. They are looking for
>> something easier (= smaller). There is space for both approaches.
>>
>> Being able to use Lucene-spatial for the index, and have it instep with the
>> data, rather than an external rpcoess like PostGIS (c.f. Parliament) makes
>> it much more usable.
>>
>> It also avoids some licensing issues - some geo libraries are GPL,LGPL which
>> makes them unsuitable for Apache.
>>
>> Combine this with any work on a better Fuseki UI, and we have a nice,
>> easy-to-use SPARQL server that gets people up and running with interesting
>> features beyond basic RDF storage and query.
>>
>> Andy
>>
>> [1] http://www.opengeospatial.org/standards/geosparql
>>
>>
>>
>> On 15/04/13 22:52, Gyanasekaran Radhakrishnan wrote:
>>>
>>> This is an awesome idea which could be extensively used if implemented (I
>>> would!). Is this going to be a stand-alone project for GSoC? I would be
>>> interested in working in this.
>>>
>>> Thanks
>>> ~Gyan
>>>
>>>
>>> On Mon, Apr 15, 2013 at 9:37 AM, Andy Seaborne <an...@apache.org> wrote:
>>>
>>>> === Spatial query
>>>> JENA-10
>>>>
>>>> Not all spatial queries are complicated. Many use case are covered by
>>>> provision of a single facility like get all objects within a given radius
>>>> or within a given bounding box. GeoSPARQL which is a complete approach
>>>> to
>>>> geospatial query but it is complicated and driected more towards the
>>>> specialist, not the average linked data developer with SPARQL knowledge.
>>>>
>>>> This project is to provide a one or two basic geospatial query functions.
>>>>
>>>> Example: return places within 10 kilometers of Bristol UK (which as
>>>> latitude/longitude of 51.46,2.6).
>>>>
>>>> SELECT ?placeName
>>>> {
>>>> ?place spatial:query (51.46 2.6 10) .
>>>> ?place rdfs:label ?placeName
>>>> }
>>>>
>>>>
>>>> We have a similar property function architecture in jena-text [0] so this
>>>> project is to take that concept and apply it to geospatial information.
>>>>
>>>> Lucene spatial could be used for the spatial index. There is a simple
>>>> vocabulary for expressing WGS80 information [1]; there is also the point
>>>> information in WKT [2].
>>>>
>>>> This project is not primarily about geospatial processing; it is
>>>> concerned
>>>> with the indexing and querying simple, existing geospatial data and
>>>> integration with Fuseki.
>>>>
>>>> [0]
>>>> http://jena.staging.apache.**org/documentation/query/text-**query.html<http://jena.staging.apache.org/documentation/query/text-query.html>
>>>> [1] http://www.w3.org/2003/01/geo/
>>>> [2]
>>>> http://en.wikipedia.org/wiki/**Well-known_text<http://en.wikipedia.org/wiki/Well-known_text>
>>>>
>>>
>>
Re: GSoC: Simple spatial query
Posted by Ying Jiang <jp...@gmail.com>.
Dear Andy,
Sorry for the late reply. These days, I've been studying the source
code of Jena pfunction, LARQ, jena-text and GeoARQ. Now I can
understand all of them by every single code line :). This summer, I
think I can take the concept of jena-text and make a similar one
applied to geospatial information. I'd like to compose a project
proposal when the GSoC website opens for the student applications.
Before that, could you please help me with the following questions:
1) It seems LARQ and jena-text provide the same functions of text
searching. If we have LARQ, why bother to use jena-text? What're the
differences of the goals, the users, the use scenarios? I also have
the same doubt with GeoARQ and the product of this GSoC project, since
GeoARQ already provides the "near" and "within" functions.
2) For the integration with Fuseki. What do you mean by "a better
Fuseki UI"? Does UI here mean client-side javascript/css work? Can you
tell me more details about this part?
3) Is there a GSoC project proposal template for Jena? Basically, it
should include self-introduction, project goal, project plan, etc, I
think. What's your opinion?
Best,
Ying Jiang
On Tue, Apr 16, 2013 at 8:32 PM, Andy Seaborne <an...@apache.org> wrote:
> This is a potential GSoC project - I'd see it firstly being a separate
> codebase as it develops, then get some people using it and providing
> feedback and, if it's popular, it can move into Jena proper. The nice thing
> is that doesn't (err "shouldn't") require modifications to the main modules
> as it should use standard extension mechanisms. However, if the mechanisms
> prove inadequate, we can fix the extension mechanisms.
>
> This is the very similar to the status of jena-text - it's in /Experimental
> so anyone can look, use and contribute but it's not in the Jena
> distribution. If and when it's considered stable, it could become part of
> trunk. That's a group decision to be made.
>
> The project is also open ended depending on how "simple" it is. There are
> some jumps in going from, say, points to polygons in the data that I think
> are just too big for the GSoC timeframe but there are potential additional
> query functions to just "near".
>
> At least look at GeoSPARQL [1] to see what a complete solution looks like.
> I think that the sweet spot is something simpler (and less capable) because
> the average web developer, even if writing SPARQL, isn't looking for a
> complete solution to all geospatial use cases. They are looking for
> something easier (= smaller). There is space for both approaches.
>
> Being able to use Lucene-spatial for the index, and have it instep with the
> data, rather than an external rpcoess like PostGIS (c.f. Parliament) makes
> it much more usable.
>
> It also avoids some licensing issues - some geo libraries are GPL,LGPL which
> makes them unsuitable for Apache.
>
> Combine this with any work on a better Fuseki UI, and we have a nice,
> easy-to-use SPARQL server that gets people up and running with interesting
> features beyond basic RDF storage and query.
>
> Andy
>
> [1] http://www.opengeospatial.org/standards/geosparql
>
>
>
> On 15/04/13 22:52, Gyanasekaran Radhakrishnan wrote:
>>
>> This is an awesome idea which could be extensively used if implemented (I
>> would!). Is this going to be a stand-alone project for GSoC? I would be
>> interested in working in this.
>>
>> Thanks
>> ~Gyan
>>
>>
>> On Mon, Apr 15, 2013 at 9:37 AM, Andy Seaborne <an...@apache.org> wrote:
>>
>>> === Spatial query
>>> JENA-10
>>>
>>> Not all spatial queries are complicated. Many use case are covered by
>>> provision of a single facility like get all objects within a given radius
>>> or within a given bounding box. GeoSPARQL which is a complete approach
>>> to
>>> geospatial query but it is complicated and driected more towards the
>>> specialist, not the average linked data developer with SPARQL knowledge.
>>>
>>> This project is to provide a one or two basic geospatial query functions.
>>>
>>> Example: return places within 10 kilometers of Bristol UK (which as
>>> latitude/longitude of 51.46,2.6).
>>>
>>> SELECT ?placeName
>>> {
>>> ?place spatial:query (51.46 2.6 10) .
>>> ?place rdfs:label ?placeName
>>> }
>>>
>>>
>>> We have a similar property function architecture in jena-text [0] so this
>>> project is to take that concept and apply it to geospatial information.
>>>
>>> Lucene spatial could be used for the spatial index. There is a simple
>>> vocabulary for expressing WGS80 information [1]; there is also the point
>>> information in WKT [2].
>>>
>>> This project is not primarily about geospatial processing; it is
>>> concerned
>>> with the indexing and querying simple, existing geospatial data and
>>> integration with Fuseki.
>>>
>>> [0]
>>> http://jena.staging.apache.**org/documentation/query/text-**query.html<http://jena.staging.apache.org/documentation/query/text-query.html>
>>> [1] http://www.w3.org/2003/01/geo/
>>> [2]
>>> http://en.wikipedia.org/wiki/**Well-known_text<http://en.wikipedia.org/wiki/Well-known_text>
>>>
>>
>
Re: GSoC: Simple spatial query
Posted by Andy Seaborne <an...@apache.org>.
This is a potential GSoC project - I'd see it firstly being a separate
codebase as it develops, then get some people using it and providing
feedback and, if it's popular, it can move into Jena proper. The nice
thing is that doesn't (err "shouldn't") require modifications to the
main modules as it should use standard extension mechanisms. However,
if the mechanisms prove inadequate, we can fix the extension mechanisms.
This is the very similar to the status of jena-text - it's in
/Experimental so anyone can look, use and contribute but it's not in the
Jena distribution. If and when it's considered stable, it could become
part of trunk. That's a group decision to be made.
The project is also open ended depending on how "simple" it is. There
are some jumps in going from, say, points to polygons in the data that I
think are just too big for the GSoC timeframe but there are potential
additional query functions to just "near".
At least look at GeoSPARQL [1] to see what a complete solution looks
like. I think that the sweet spot is something simpler (and less
capable) because the average web developer, even if writing SPARQL,
isn't looking for a complete solution to all geospatial use cases. They
are looking for something easier (= smaller). There is space for both
approaches.
Being able to use Lucene-spatial for the index, and have it instep with
the data, rather than an external rpcoess like PostGIS (c.f. Parliament)
makes it much more usable.
It also avoids some licensing issues - some geo libraries are GPL,LGPL
which makes them unsuitable for Apache.
Combine this with any work on a better Fuseki UI, and we have a nice,
easy-to-use SPARQL server that gets people up and running with
interesting features beyond basic RDF storage and query.
Andy
[1] http://www.opengeospatial.org/standards/geosparql
On 15/04/13 22:52, Gyanasekaran Radhakrishnan wrote:
> This is an awesome idea which could be extensively used if implemented (I
> would!). Is this going to be a stand-alone project for GSoC? I would be
> interested in working in this.
>
> Thanks
> ~Gyan
>
>
> On Mon, Apr 15, 2013 at 9:37 AM, Andy Seaborne <an...@apache.org> wrote:
>
>> === Spatial query
>> JENA-10
>>
>> Not all spatial queries are complicated. Many use case are covered by
>> provision of a single facility like get all objects within a given radius
>> or within a given bounding box. GeoSPARQL which is a complete approach to
>> geospatial query but it is complicated and driected more towards the
>> specialist, not the average linked data developer with SPARQL knowledge.
>>
>> This project is to provide a one or two basic geospatial query functions.
>>
>> Example: return places within 10 kilometers of Bristol UK (which as
>> latitude/longitude of 51.46,2.6).
>>
>> SELECT ?placeName
>> {
>> ?place spatial:query (51.46 2.6 10) .
>> ?place rdfs:label ?placeName
>> }
>>
>>
>> We have a similar property function architecture in jena-text [0] so this
>> project is to take that concept and apply it to geospatial information.
>>
>> Lucene spatial could be used for the spatial index. There is a simple
>> vocabulary for expressing WGS80 information [1]; there is also the point
>> information in WKT [2].
>>
>> This project is not primarily about geospatial processing; it is concerned
>> with the indexing and querying simple, existing geospatial data and
>> integration with Fuseki.
>>
>> [0] http://jena.staging.apache.**org/documentation/query/text-**query.html<http://jena.staging.apache.org/documentation/query/text-query.html>
>> [1] http://www.w3.org/2003/01/geo/
>> [2] http://en.wikipedia.org/wiki/**Well-known_text<http://en.wikipedia.org/wiki/Well-known_text>
>>
>
Re: GSoC: Simple spatial query
Posted by Gyanasekaran Radhakrishnan <gn...@gmail.com>.
This is an awesome idea which could be extensively used if implemented (I
would!). Is this going to be a stand-alone project for GSoC? I would be
interested in working in this.
Thanks
~Gyan
On Mon, Apr 15, 2013 at 9:37 AM, Andy Seaborne <an...@apache.org> wrote:
> === Spatial query
> JENA-10
>
> Not all spatial queries are complicated. Many use case are covered by
> provision of a single facility like get all objects within a given radius
> or within a given bounding box. GeoSPARQL which is a complete approach to
> geospatial query but it is complicated and driected more towards the
> specialist, not the average linked data developer with SPARQL knowledge.
>
> This project is to provide a one or two basic geospatial query functions.
>
> Example: return places within 10 kilometers of Bristol UK (which as
> latitude/longitude of 51.46,2.6).
>
> SELECT ?placeName
> {
> ?place spatial:query (51.46 2.6 10) .
> ?place rdfs:label ?placeName
> }
>
>
> We have a similar property function architecture in jena-text [0] so this
> project is to take that concept and apply it to geospatial information.
>
> Lucene spatial could be used for the spatial index. There is a simple
> vocabulary for expressing WGS80 information [1]; there is also the point
> information in WKT [2].
>
> This project is not primarily about geospatial processing; it is concerned
> with the indexing and querying simple, existing geospatial data and
> integration with Fuseki.
>
> [0] http://jena.staging.apache.**org/documentation/query/text-**query.html<http://jena.staging.apache.org/documentation/query/text-query.html>
> [1] http://www.w3.org/2003/01/geo/
> [2] http://en.wikipedia.org/wiki/**Well-known_text<http://en.wikipedia.org/wiki/Well-known_text>
>