On 03/08/17 11:59, Ullah, Izhar wrote:
Dave,
Thanks for your ideas. I'm sorry I didn't get your statement "If you already have a
GeoSPARQL system then just use that, no point in rewriting into Jena Rules."
Actually, I want to deduce the 'Risk of Pollution' phenomenon using Jena rules for which
one of the factors that needs to be satisfied/fired is 'if sheep are in the field' and I
have to do all this through Jena rules.
That doesn't explain *why* you think you have to do this through rules.
If this is an assignment then go discuss that with your tutor.
If you already have working queries in some geosparql engine of some
sort then use sparql update to assert your conclusions, no need to use
rules.
Regarding GPS data, we are collecting raw geo coordinates and then convert it
Point(long lat) geometries because of the requirements of GeoSPARQL ontology in
our work. You are right that the field geometry can't be a Point, actually, it
is divided into three different zones having LineString, Polygon and LineString
geometries but yes it(field) could be a rectangle having different
geocoordinates as well.
So, what I understand from your answer is, I need to model both sheep and field
geometries in simple lat and long coordinates and then use the Jena built-in
primitive i.e. equal(?sheeplat, ?fieldlat) and equal(?sheeplong, ?fieldlong) .
Please correct me if that is not one of the right ways to doing it.
That's nothing like what I said. Re-read my suggestions.
It's clear from your description that your fields are not restricted to
be *only* nicely aligned rectangles so there is no reasonable way to do
this in just jena rules. Either create geometry builtins for Jena rules,
ideally using a geometry library to do the heavy work, or give in on
using Jena rules.
Dave
From: Dave Reynolds [[email protected]]
Sent: 03 August 2017 08:25
To: [email protected]
Subject: Re: Comparing GPS Coordinates Data i.e. Point(long lat) in Jena Rules
On 02/08/17 19:58, Ullah, Izhar wrote:
Hi,
I want to write a Jena rule which could deduce the fact that 'Sheep have found
in the field'. To do this, I have got only geometries of sheep in the form of
GPS coordinates like Point(longitude latitude) e.g. POINT(-3.783065 53.202158).
Similarly, I have got the geometries of the field in the same format.
POINT can't be the geometry of a field it's a point. The answer to your
problem will depend on what range of geometries you need to support.
My question is how can I match the sheep's geometries with that of field
geometries and deduce the said fact. In SPARQL, I have done the same task
through the following SPARQL Query with the help of GeoSPARQL functions and it
runs succesfully:
If you already have a GeoSPARQL system then just use that, no point in
rewriting into Jena Rules.
Query: Are sheep found in the field?
ASK WHERE {
?sheep rdf:type enviot:SheepNodeOutput ;
geosparql:hasGeometry ?sgeo.
?sgeo geosparql:asWKT ?swkt.
?feature rdf:type enviot:Field;
geosparql:hasGeometry ?fgeo.
?fgeo geosparql:asWKT ?fwkt.
FILTER(geof:sfIntersects(?swkt, ?fwkt))
}
By the way, my jsonld data borrows/uses the vocabulary from my ontology which
uses the GeoSPARQL Ontology as well.
Can someone please give their thoughts/ideas about this issue/challenge? There
is a built-in primitive in Jena i.e. equal(?x, ?y) but I don't know whether it
works for comparing geo coordinates like Point(long lat) or not.
In the unlikely case that your fields are just rectangles aligned
north-south/east-west. And if you have raw coordinates in your data not
just WKT literals then you just compare the lat and long values between
the sheep and the left/right and top/bottom field boundaries.
In all other cases you would need a GIS library to decode the WKT
literals and to compute the intersection of a point with your polygons.
The common one is GeoTools (note LGPL) which you could either just use
or, if you really need to do this in Jena rules, then you could create
some builtins to do this which call out to GeoTools.
Dave
