You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by "Lorenz Bühmann (Jira)" <ji...@apache.org> on 2022/02/22 07:25:00 UTC
[jira] [Updated] (JENA-2289) Geospatial index not being loaded with assembler
[ https://issues.apache.org/jira/browse/JENA-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lorenz Bühmann updated JENA-2289:
---------------------------------
Description:
Using the GeoSPARQL component via assembler doesn't load the geospatial index from disk and therefore doesn't register it to the context of the dataset which makes querying fail on a second startup.
In the method {{prepareSpatialExtension}} in {{GeoAssembler}} class we have currently the following cases handled:
case 1: no file given
case 2: file given and either doesn't exists yet or empty
Thus, case 3 is missing:
case 3: file given and it isn't empty, i.e. the index has been precomputed
First I thought just ignore the file existence/emptyness check and go with
{code:java}
GeoSPARQLConfig.setupSpatialIndex(dataset, spatialIndexPath.toFile());{code}
But this would lead to an unnecessary retrieval of the SRS occurrences.
What I did for testing is to add
{code:java}
SpatialIndex si = SpatialIndex.load(spatialIndexPath.toFile());
SpatialIndex.setSpatialIndex(dataset, si); {code}
but maybe we want to have this case also encapsulated in the {{GeoSPARQLConfig }} class? Something like
{code:java}
GeoSPARQLConfig.setupFromPrecomputedIndex(dataset, spatialIndexPath.toFile());{code}
maybe?
was:
Using the GeoSPARQL component via assembler doesn't load the geospatial index from disk and therefore doesn't register it to the context of the dataset which makes querying fail on a second startup.
In the method {{prepareSpatialExtension}} in {{GeoAssembler}} class we have currently the following cases handled:
case 1: no file given
case 2: file given and either doesn't exists yet or empty
Thus, case 3 is missing:
case 3: file given and it isn't empty, i.e. the index has been precomputed
First I thought just ignore the file existence/emptyness check and go with
{code:java}
GeoSPARQLConfig.setupSpatialIndex(dataset, spatialIndexPath.toFile());{code}
But this would lead to an unnecessary retrieval of the SRS occurrences.
What I did for testing is to add
{code:java}
SpatialIndex si = SpatialIndex.load(spatialIndexPath.toFile());
SpatialIndex.setSpatialIndex(dataset, si); {code}
but maybe we want to have this case also encapsulated in the {{GeoSPARQLConfig }}class? Something like
{code:java}
GeoSPARQLConfig.setupFromPrecomputedIndex(dataset, spatialIndexPath.toFile());{code}
maybe?
> Geospatial index not being loaded with assembler
> ------------------------------------------------
>
> Key: JENA-2289
> URL: https://issues.apache.org/jira/browse/JENA-2289
> Project: Apache Jena
> Issue Type: Bug
> Components: GeoSPARQL
> Affects Versions: Jena 4.4.0
> Reporter: Lorenz Bühmann
> Priority: Major
>
> Using the GeoSPARQL component via assembler doesn't load the geospatial index from disk and therefore doesn't register it to the context of the dataset which makes querying fail on a second startup.
> In the method {{prepareSpatialExtension}} in {{GeoAssembler}} class we have currently the following cases handled:
> case 1: no file given
> case 2: file given and either doesn't exists yet or empty
> Thus, case 3 is missing:
> case 3: file given and it isn't empty, i.e. the index has been precomputed
> First I thought just ignore the file existence/emptyness check and go with
>
> {code:java}
> GeoSPARQLConfig.setupSpatialIndex(dataset, spatialIndexPath.toFile());{code}
>
> But this would lead to an unnecessary retrieval of the SRS occurrences.
> What I did for testing is to add
> {code:java}
> SpatialIndex si = SpatialIndex.load(spatialIndexPath.toFile());
> SpatialIndex.setSpatialIndex(dataset, si); {code}
> but maybe we want to have this case also encapsulated in the {{GeoSPARQLConfig }} class? Something like
> {code:java}
> GeoSPARQLConfig.setupFromPrecomputedIndex(dataset, spatialIndexPath.toFile());{code}
> maybe?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)