Sounds better, thanks. Another corner case to check is the handling of
features that are bnodes. For example SpatialIndexStorage.StorageItem
seems to rely on getURI() yet the surrounding loops may operate on blank
nodes too. In my own code I have excluded those nodes for now, yet an
alternative would be to treat them using the _:URI naming scheme to
round-trip the bnodes.
Holger
On 18/02/2020 08:06, Greg Albiston wrote:
Hi Holger,
Thank you for highlighting these points. The following fixes have been
applied to the 3.15-SNAPSHOT.
* The iterators are now checked for more than one of either property
and are closed along with a DatatypeFormat exception being thrown
since only a single of each property should be present.
* The getProperty methods have been replaced by getRequiredProperty
methods which throws an PropertyNotFoundException as these
properties are both expected to be present.
Thanks,
Greg
On 17/02/2020 05:01, Holger Knublauch wrote:
A similar small issue seems to be when the index is built:
SpatialIndex.getGeoPredicateIndexItems, line 460 may cause a
NullPointerException if a resource happens to have a geo:lat but no
geo:long. With messy data this doesn't look very robust:
Literal lat =
feature.getProperty(SpatialExtension.GEO_LAT_PROP).getLiteral();
Literal lon =
feature.getProperty(SpatialExtension.GEO_LON_PROP).getLiteral();
Thanks
Holger
On 17/02/2020 12:48, Holger Knublauch wrote:
Hi,
I am starting to look into GeoSPARQL and run into an issue related to
this line 135 in SpatialObjectGeometryLiteral:
Node lat = graph.find(targetSpatialObject,
SpatialExtension.GEO_LAT_NODE, null).next().getObject();
This is creating an Iterator in the find() and then just calls next()
without checking whether the iterator is exhausted. However, a
subject may have multiple values for that geo:lat property and then
we end up with an unclosed iterator. This breaks our assumptions in
that each Jena iterator must be either exhausted by reaching the end,
or closed with .close().
Isn't this a bug?
Thanks
Holger
