GeoSPARQL: Why either geo:lat/long or geosparql:hasGeometry

[Holger Knublauch <ho...@topquadrant.com>]

See 
https://github.com/apache/jena/blob/c9b1ae25f4e73066f3832ba4c4adc0250f42f1de/jena-geosparql/src/main/java/org/apache/jena/geosparql/spatial/SpatialIndex.java#L382

//Only add one set of statements as a converted dataset will duplicate 
the same info.

It appears that the index will skip any geo:lat/long triples as soon as 
one geosparql:hasGeometry is in the graph. This feels rather arbitrary 
as some graphs may well contain a mix of those. If I understand the 
comment correctly, this was done under the assumption that lat/long 
would also be duplicated as WKT or GML triples. (Maybe this is a step I 
am missing somewhere).

Wouldn't it be then more consistent to include both but skip duplicate 
lat/long or Points that describe the same Feature?

Thanks
Holger

Re: GeoSPARQL: Why either geo:lat/long or geosparql:hasGeometry

[Holger Knublauch <ho...@topquadrant.com>]

Hi Greg,

thanks for your reply. For the record, we have seen several uses of the 
(older) geo:lat/long properties in the wild and have used them ourselves 
for demos etc. I have therefore updated our integration of GeoSPARQL to 
allow mixing both styles. I had to duplicate 
SpatialIndex.getGeometryLiteralIndexItems as that is private, so maybe 
this could be made public in a future version.

Overall it's a very nice feature and I thank you for your efforts to 
integrate this with Jena!

Thanks
Holger


On 2/05/2020 21:17, Greg Albiston wrote:
> The use of mixed datasets is not recommended and could be argued to be a
> somewhat niche use case. Conversion functions are provided to change
> Lat/Lon geometries to GeoSPARQL geometry. A user could also run two
> instances and direct the relevant spatial queries to either.
>
> Support for Lat/Lon was included to allow easier transition from the
> exisiting Apache Jena Spatial module and not lose the Spatial functions
> offered. There is support for both types in the Spatial functions as
> this did not introduce excessive additional complexity.
>
> However, there needs to be a boundary to the design at some point and
> this was an area where it was deemed more "nice" than "need".
> Particularly since the user has several options to access the tool; it
> is a variation from the primary use case; and supporting Lat/Lon in any
> manner is an enhancement.
>
> Thanks,
>
> Greg
>
> On 01/05/2020 03:59, Holger Knublauch wrote:
>> See
>> https://github.com/apache/jena/blob/c9b1ae25f4e73066f3832ba4c4adc0250f42f1de/jena-geosparql/src/main/java/org/apache/jena/geosparql/spatial/SpatialIndex.java#L382 
>>
>>
>>
>> //Only add one set of statements as a converted dataset will duplicate
>> the same info.
>>
>> It appears that the index will skip any geo:lat/long triples as soon
>> as one geosparql:hasGeometry is in the graph. This feels rather
>> arbitrary as some graphs may well contain a mix of those. If I
>> understand the comment correctly, this was done under the assumption
>> that lat/long would also be duplicated as WKT or GML triples. (Maybe
>> this is a step I am missing somewhere).
>>
>> Wouldn't it be then more consistent to include both but skip duplicate
>> lat/long or Points that describe the same Feature?
>>
>> Thanks
>> Holger
>>
>>

Re: GeoSPARQL: Why either geo:lat/long or geosparql:hasGeometry

[Greg Albiston <ga...@mail.com>]

The use of mixed datasets is not recommended and could be argued to be a
somewhat niche use case. Conversion functions are provided to change
Lat/Lon geometries to GeoSPARQL geometry. A user could also run two
instances and direct the relevant spatial queries to either.

Support for Lat/Lon was included to allow easier transition from the
exisiting Apache Jena Spatial module and not lose the Spatial functions
offered. There is support for both types in the Spatial functions as
this did not introduce excessive additional complexity.

However, there needs to be a boundary to the design at some point and
this was an area where it was deemed more "nice" than "need".
Particularly since the user has several options to access the tool; it
is a variation from the primary use case; and supporting Lat/Lon in any
manner is an enhancement.

Thanks,

Greg

On 01/05/2020 03:59, Holger Knublauch wrote:
> See
> https://github.com/apache/jena/blob/c9b1ae25f4e73066f3832ba4c4adc0250f42f1de/jena-geosparql/src/main/java/org/apache/jena/geosparql/spatial/SpatialIndex.java#L382
>
>
> //Only add one set of statements as a converted dataset will duplicate
> the same info.
>
> It appears that the index will skip any geo:lat/long triples as soon
> as one geosparql:hasGeometry is in the graph. This feels rather
> arbitrary as some graphs may well contain a mix of those. If I
> understand the comment correctly, this was done under the assumption
> that lat/long would also be duplicated as WKT or GML triples. (Maybe
> this is a step I am missing somewhere).
>
> Wouldn't it be then more consistent to include both but skip duplicate
> lat/long or Points that describe the same Feature?
>
> Thanks
> Holger
>
>