You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Holger Knublauch <ho...@topquadrant.com> on 2020/02/17 02:48:05 UTC
Unclosed iterator in GeoSPARQL
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
Re: Unclosed iterator in GeoSPARQL
Posted by Holger Knublauch <ho...@topquadrant.com>.
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
>>>
>>>
>
Re: Unclosed iterator in GeoSPARQL
Posted by Greg Albiston <ga...@mail.com>.
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
>>
>>
Re: Unclosed iterator in GeoSPARQL
Posted by Holger Knublauch <ho...@topquadrant.com>.
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
>
>