[jira] [Closed] (JENA-2266) convertLatLon swaps coordinates

[Greg Albiston (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Albiston closed JENA-2266.
---
Resolution: Invalid

> convertLatLon swaps coordinates
> ---
>
> Key: JENA-2266
> URL: https://issues.apache.org/jira/browse/JENA-2266
> Project: Apache Jena
>  Issue Type: Bug
>  Components: GeoSPARQL
>Affects Versions: Jena 4.3.2
>Reporter: Claus Stadler
>Priority: Major
> Attachments: image-2022-01-30-18-28-56-974.png
>
>
> The correct setting is that longitude corresponds to x-axis and latitude to 
> y-axis, but in the code lat is passed for x and lon for y.
> {code:java}
> public class ConvertLatLon {
> public static final Literal toLiteral(double lat, double lon) {
> checkBounds(lat, lon);
> return WKTLiteralFactory.createPoint(lat, lon, SRS_URI.WGS84_CRS);
> }
> }
> {code}
> {code:java}
> public class WKTLiteralFactory {
> public static final Literal createPoint(Double x, Double y, String 
> srsURI) {
> String tidyURI = tidySrsURI(srsURI);
> return ResourceFactory.createTypedLiteral(tidyURI + "POINT(" + 
> reducePrecision(x) + " " + reducePrecision(y)
>  + ")", WKTDatatype.INSTANCE);
> }
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (JENA-2266) convertLatLon swaps coordinates

[Greg Albiston (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17484988#comment-17484988
 ] 

Greg Albiston commented on JENA-2266:
-

Sorry, but I'm unclear about your use case and how it relates to GeoSPARQL Jena.

Perhaps this question may be better directed at the {{us...@jena.apache.org}} 
mailing list with further detail provided.

> convertLatLon swaps coordinates
> ---
>
> Key: JENA-2266
> URL: https://issues.apache.org/jira/browse/JENA-2266
> Project: Apache Jena
>  Issue Type: Bug
>  Components: GeoSPARQL
>Affects Versions: Jena 4.3.2
>Reporter: Claus Stadler
>Priority: Major
> Attachments: image-2022-01-30-18-28-56-974.png
>
>
> The correct setting is that longitude corresponds to x-axis and latitude to 
> y-axis, but in the code lat is passed for x and lon for y.
> {code:java}
> public class ConvertLatLon {
> public static final Literal toLiteral(double lat, double lon) {
> checkBounds(lat, lon);
> return WKTLiteralFactory.createPoint(lat, lon, SRS_URI.WGS84_CRS);
> }
> }
> {code}
> {code:java}
> public class WKTLiteralFactory {
> public static final Literal createPoint(Double x, Double y, String 
> srsURI) {
> String tidyURI = tidySrsURI(srsURI);
> return ResourceFactory.createTypedLiteral(tidyURI + "POINT(" + 
> reducePrecision(x) + " " + reducePrecision(y)
>  + ")", WKTDatatype.INSTANCE);
> }
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (JENA-2266) convertLatLon swaps coordinates

[Greg Albiston (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17484418#comment-17484418
 ] 

Greg Albiston commented on JENA-2266:
-

Longitude is indeed the X axis and latitude is the Y axis. However, the SRS 
EPSG 4326 (referenced by {{{}SRS_URI.WGS84_CRS{}}}) used for WGS84 reverses the 
axis order when encoding to latitude/longitude. The SRS OGC CRS84 has the axis 
order longitude/latitude.

The produced Point literal conforms with the axis order, if it is perhaps 
somewhat confusing in the naming of function parameters.

An example of this is provided on page 17 of the GeoSPARQL standard.

!image-2022-01-30-18-28-56-974.png!

> convertLatLon swaps coordinates
> ---
>
> Key: JENA-2266
> URL: https://issues.apache.org/jira/browse/JENA-2266
> Project: Apache Jena
>  Issue Type: Bug
>  Components: GeoSPARQL
>Affects Versions: Jena 4.3.2
>Reporter: Claus Stadler
>Priority: Major
> Attachments: image-2022-01-30-18-28-56-974.png
>
>
> The correct setting is that longitude corresponds to x-axis and latitude to 
> y-axis, but in the code lat is passed for x and lon for y.
> {code:java}
> public class ConvertLatLon {
> public static final Literal toLiteral(double lat, double lon) {
> checkBounds(lat, lon);
> return WKTLiteralFactory.createPoint(lat, lon, SRS_URI.WGS84_CRS);
> }
> }
> {code}
> {code:java}
> public class WKTLiteralFactory {
> public static final Literal createPoint(Double x, Double y, String 
> srsURI) {
> String tidyURI = tidySrsURI(srsURI);
> return ResourceFactory.createTypedLiteral(tidyURI + "POINT(" + 
> reducePrecision(x) + " " + reducePrecision(y)
>  + ")", WKTDatatype.INSTANCE);
> }
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (JENA-2266) convertLatLon swaps coordinates

[Greg Albiston (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Albiston updated JENA-2266:

Attachment: image-2022-01-30-18-28-56-974.png

> convertLatLon swaps coordinates
> ---
>
> Key: JENA-2266
> URL: https://issues.apache.org/jira/browse/JENA-2266
> Project: Apache Jena
>  Issue Type: Bug
>  Components: GeoSPARQL
>Affects Versions: Jena 4.3.2
>Reporter: Claus Stadler
>Priority: Major
> Attachments: image-2022-01-30-18-28-56-974.png
>
>
> The correct setting is that longitude corresponds to x-axis and latitude to 
> y-axis, but in the code lat is passed for x and lon for y.
> {code:java}
> public class ConvertLatLon {
> public static final Literal toLiteral(double lat, double lon) {
> checkBounds(lat, lon);
> return WKTLiteralFactory.createPoint(lat, lon, SRS_URI.WGS84_CRS);
> }
> }
> {code}
> {code:java}
> public class WKTLiteralFactory {
> public static final Literal createPoint(Double x, Double y, String 
> srsURI) {
> String tidyURI = tidySrsURI(srsURI);
> return ResourceFactory.createTypedLiteral(tidyURI + "POINT(" + 
> reducePrecision(x) + " " + reducePrecision(y)
>  + ")", WKTDatatype.INSTANCE);
> }
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (JENA-2230) Assembler for GeoSPARQL

[Greg Albiston (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466110#comment-17466110
 ] 

Greg Albiston commented on JENA-2230:
-

Thank you for adding this in. It is a big step closer to {{fuseki-geosparql}} 
not being needed (and possibly the data loading command moving to {{jena-cmd 
}}or equivalent).

About GeoSPARQL's handling of update, it is only the spatial index that is a 
concern. The rest of the functionality checks the dataset on-demand as part of 
the SPARQL query engine's property and filter functions.

When setting up the {{fuseki-geosparql}} application, it wasn't clear, or 
documented as far as I could tell, how to hook into update queries to add or 
remove geometries to the spatial index.  At the time, the JTS library only 
offered a read-only (after setup) StrTree and a write QuadTree (with the latter 
requiring additional filter checks for validity). Since Fuseki at the time 
required a restart when using inferencing with updates, the same approach was 
followed for the use of spatial indexes and the StrTree selected.

The JTS spatial indexes have a common interface, so switching to one of the 
alternatives should be straightforward and several more have been implemented 
since (see {{{}org.apache.jena.geosparql.spatial.SpatialIndex in GeoSPARQL 
module and org.locationtech.jts.index [JTS 
library|https://locationtech.github.io/jts/javadoc/org/locationtech/jts/index/package-frame.html]{}}}).

It then just comes down to how the SPARQL query engine notifies of update 
queries, so these can be passed to the spatial index. The spatial index is 
stored in the Dataset Context during setup and provided to the property and 
filter functions during querying.

If I can be pointed in the right direction then I can look to resolve updating 
the spatial index?

> Assembler for GeoSPARQL
> ---
>
> Key: JENA-2230
> URL: https://issues.apache.org/jira/browse/JENA-2230
> Project: Apache Jena
>  Issue Type: New Feature
>  Components: GeoSPARQL
>Affects Versions: Jena 4.3.2
>Reporter: Andy Seaborne
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 4.4.0
>
>
> An assembler for the GeoSPARQL engine.
> This is for {{jena-geosparql}}, making it a loadable module for Jena and 
> usable with any Fuseki server.
> jena-fuseki-geosparql and its command line are unchanged.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (JENA-2136) Reintroduce spatial module

[Greg Albiston (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17385134#comment-17385134
 ] 

Greg Albiston commented on JENA-2136:
-

The spatial functions from the jena-spatial module are already supported in 
jena-geosparql. There are versions available for using lat/lon geo predicates 
or the GeoSPARQL data structure, so it isn't a requirement to convert datasets 
to access this functionality.

> Reintroduce spatial module
> --
>
> Key: JENA-2136
> URL: https://issues.apache.org/jira/browse/JENA-2136
> Project: Apache Jena
>  Issue Type: Wish
>  Components: Spatial
>Reporter: Øyvind Gjesdal
>Priority: Minor
>
> I would like to reintroduce the jena-spatial module for future versions of 
> Jena. I've begun [a PR|https://github.com/apache/jena/pull/1029] for this but 
> I'm not sure if it should be in the jena-repo, since jena-geosparql is in use.
> We would like to use jena-spatial, while also being able to upgrade our 
> fuseki servers. We still have internal and external datasets not prepared for 
> geosparql.
> Changes made so far
>  * Readd code from last working jena-spatial in 3.12
>  * Remove dependency for Lucene-spatial (is now part of Lucene spatial 
> extras, removed in 
> [https://github.com/apache/lucene/commit/78655239c58a1ed72d6e015dd05a0b355c936999])
>  * Upgrade Spatial4j version 0.8 (Two minor versions since last time)
>  * Readd as main module in pom.xml files
>  * Comment out spatial Logging initialization in tests (No longer used 
> library) in tests
> The tests for jena-spatial are now running again on 
> ([https://github.com/OyvindLGjesdal/jena/runs/3114796795?check_suite_focus=true#step:4:3804])
> Is adding it again useful for more users, or is maintaining the module 
> outside of Apache/jena and adding it to classpath the best option?
> We can look at changes for getting tests to pass if the build for 
> jena-spatial starts failing in the future, and I can also create a PR for 
> reopening the jena-site documentation. 
>  
> https://github.com/apache/jena/pull/1029



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (JENA-1996) Updating org.apache.sis from 0.8 to 1.0 causes jena-geosparql test failure

[Greg Albiston (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Albiston closed JENA-1996.
---
Fix Version/s: Jena 3.17.0
   Resolution: Fixed

> Updating org.apache.sis from 0.8 to 1.0 causes jena-geosparql test failure
> --
>
> Key: JENA-1996
> URL: https://issues.apache.org/jira/browse/JENA-1996
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.17.0
>Reporter: Andy Seaborne
>Assignee: Greg Albiston
>Priority: Major
> Fix For: Jena 3.17.0
>
>
> After the recent dependabot updates:
> jts-core 1.16.1 to 1.17.1 works.
> sis from 0.8 to 1.0 causes a test failure.
> org.apache.sis.core:sis-referencing-data:1.0 (scope test)
> org.apache.sis.non-free:sis-embedded-data:1.0 (scope test)
>  
> With version 1.0:
> {noformat}
> [INFO] Running 
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest
> [ERROR] Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.019 
> s <<< FAILURE! - in 
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest
> [ERROR] 
> testGetDefaultWKTCRS(org.apache.jena.geosparql.implementation.registry.SRSRegistryTest)
>   Time elapsed: 0.018 s  <<< FAILURE!
> org.junit.ComparisonFailure: expected:<...CRS", 84, CITATION["[OGC:]WMS"], 
> URI["urn:ogc:...> but was:<...CRS", 84, CITATION["[]WMS"], URI["urn:ogc:...>
>   at 
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest.testGetDefaultWKTCRS(SRSRegistryTest.java:94)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (JENA-1996) Updating org.apache.sis from 0.8 to 1.0 causes jena-geosparql test failure

[Greg Albiston (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Albiston reassigned JENA-1996:
---

Assignee: Greg Albiston

> Updating org.apache.sis from 0.8 to 1.0 causes jena-geosparql test failure
> --
>
> Key: JENA-1996
> URL: https://issues.apache.org/jira/browse/JENA-1996
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.17.0
>Reporter: Andy Seaborne
>Assignee: Greg Albiston
>Priority: Major
>
> After the recent dependabot updates:
> jts-core 1.16.1 to 1.17.1 works.
> sis from 0.8 to 1.0 causes a test failure.
> org.apache.sis.core:sis-referencing-data:1.0 (scope test)
> org.apache.sis.non-free:sis-embedded-data:1.0 (scope test)
>  
> With version 1.0:
> {noformat}
> [INFO] Running 
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest
> [ERROR] Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.019 
> s <<< FAILURE! - in 
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest
> [ERROR] 
> testGetDefaultWKTCRS(org.apache.jena.geosparql.implementation.registry.SRSRegistryTest)
>   Time elapsed: 0.018 s  <<< FAILURE!
> org.junit.ComparisonFailure: expected:<...CRS", 84, CITATION["[OGC:]WMS"], 
> URI["urn:ogc:...> but was:<...CRS", 84, CITATION["[]WMS"], URI["urn:ogc:...>
>   at 
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest.testGetDefaultWKTCRS(SRSRegistryTest.java:94)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JENA-1996) Updating org.apache.sis from 0.8 to 1.0 causes jena-geosparql test failure

[Greg Albiston (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17232336#comment-17232336
 ] 

Greg Albiston commented on JENA-1996:
-

Test has been fixed and is now in `master`.

> Updating org.apache.sis from 0.8 to 1.0 causes jena-geosparql test failure
> --
>
> Key: JENA-1996
> URL: https://issues.apache.org/jira/browse/JENA-1996
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.17.0
>Reporter: Andy Seaborne
>Assignee: Greg Albiston
>Priority: Major
>
> After the recent dependabot updates:
> jts-core 1.16.1 to 1.17.1 works.
> sis from 0.8 to 1.0 causes a test failure.
> org.apache.sis.core:sis-referencing-data:1.0 (scope test)
> org.apache.sis.non-free:sis-embedded-data:1.0 (scope test)
>  
> With version 1.0:
> {noformat}
> [INFO] Running 
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest
> [ERROR] Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.019 
> s <<< FAILURE! - in 
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest
> [ERROR] 
> testGetDefaultWKTCRS(org.apache.jena.geosparql.implementation.registry.SRSRegistryTest)
>   Time elapsed: 0.018 s  <<< FAILURE!
> org.junit.ComparisonFailure: expected:<...CRS", 84, CITATION["[OGC:]WMS"], 
> URI["urn:ogc:...> but was:<...CRS", 84, CITATION["[]WMS"], URI["urn:ogc:...>
>   at 
> org.apache.jena.geosparql.implementation.registry.SRSRegistryTest.testGetDefaultWKTCRS(SRSRegistryTest.java:94)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JENA-1969) Can't start geosparql fuseki server with -rf and -t

[Greg Albiston (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17207321#comment-17207321
 ] 

Greg Albiston commented on JENA-1969:
-

The current Spatial Index is immutable once built. It needs to be 
re-constructed when new geometries are added. This is consistent with the need 
to restart Fuseki when using inferencing to detect new triples.

Adding a TDB2 switch should be straightforward to do.

> Can't start geosparql fuseki server with -rf and -t
> ---
>
> Key: JENA-1969
> URL: https://issues.apache.org/jira/browse/JENA-1969
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Fuseki, Spatial, TDB
>Affects Versions: Jena 3.16.0
> Environment: Ubuntu 20.04.1 LTS
> JENA_HOME=/apache-jena-3.17.0-SNAPSHOT
> FUSEKI_HOME=/home/lotico/jena/apache-jena-fuseki-3.17.0-SNAPSHOT
> openjdk version "13.0.3" 2020-04-14
> OpenJDK Runtime Environment (build 13.0.3+3-Ubuntu-1ubuntu2)
> OpenJDK 64-Bit Server VM (build 13.0.3+3-Ubuntu-1ubuntu2, mixed mode)
>Reporter: Marco Neumann
>Assignee: Greg Albiston
>Priority: Major
> Fix For: Jena 3.17.0
>
>
> geosparql fuseki server can't be started with option combination -rf and -t 
> as described in the jena fuseki geosparql user documentation 
> (https://jena.apache.org/documentation/geosparql/geosparql-fuseki). 
> Individually with either option -rf or -t fuseki geosparql starts fine and 
> works as expected. Data can be loaded programmatically to tdb once created.
> {noformat}
> java -jar jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar -rf data.ttl -t 
> "testDB2"
> WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will 
> impact performance.
> [2020-09-25 20:22:39] Main   INFO  Arguments Received: [-rf, data.ttl, 
> -t, testDB2]
> [2020-09-25 20:22:39] DatasetOperations INFO  Server Configuration: 
> port=3030, datsetName=ds, loopbackOnly=true, updateAllowed=false, 
> inference=false, applyDefaultGeometry=false, validateGeometryLiteral=false, 
> convertGeoPredicates=false, removeGeoPredicates=false, queryRewrite=true, 
> tdbFile=testDB2, fileGraphFormats=[FileGraphFormat{rdfFile=data.ttl, 
> graphName=, rdfFormat=Turtle/pretty}], fileGraphDelimiters=[], 
> indexEnabled=true, indexSizes=[-1, -1, -1], indexExpiries=[5000, 5000, 5000], 
> spatialIndexFile=null, help=false
> [2020-09-25 20:22:39] DatasetOperations INFO  TDB Dataset: testDB2
> [2020-09-25 20:22:41] DatasetOperations INFO  Reading RDF - Started - File: 
> data.ttl, Graph Name: , RDF Format: Turtle/pretty
> [2020-09-25 20:22:41] DatasetOperations INFO  Reading RDF - Completed - File: 
> data.ttl, Graph Name: , RDF Format: Turtle/pretty
> Exception in thread "main" 
> org.apache.jena.tdb.transaction.TDBTransactionException: Not in a transaction
>   at 
> org.apache.jena.tdb.transaction.DatasetGraphTransaction.get(DatasetGraphTransaction.java:138)
>   at 
> org.apache.jena.tdb.transaction.DatasetGraphTransaction.get(DatasetGraphTransaction.java:49)
>   at 
> org.apache.jena.sparql.core.DatasetGraphWrapper.getR(DatasetGraphWrapper.java:103)
>   at 
> org.apache.jena.sparql.core.DatasetGraphWrapper.isEmpty(DatasetGraphWrapper.java:192)
>   at org.apache.jena.sparql.core.DatasetImpl.isEmpty(DatasetImpl.java:247)
>   at 
> org.apache.jena.fuseki.geosparql.DatasetOperations.setup(DatasetOperations.java:95)
>   at org.apache.jena.fuseki.geosparql.Main.main(Main.java:64)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (JENA-1969) Can't start geosparql fuseki server with -rf and -t

[Greg Albiston (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Albiston resolved JENA-1969.
-
Fix Version/s: Jena 3.17.0
   Resolution: Fixed

TDB now requires a transaction to check if dataset is empty. Transaction now 
added.

> Can't start geosparql fuseki server with -rf and -t
> ---
>
> Key: JENA-1969
> URL: https://issues.apache.org/jira/browse/JENA-1969
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Fuseki, Spatial, TDB
>Affects Versions: Jena 3.16.0
> Environment: Ubuntu 20.04.1 LTS
> JENA_HOME=/apache-jena-3.17.0-SNAPSHOT
> FUSEKI_HOME=/home/lotico/jena/apache-jena-fuseki-3.17.0-SNAPSHOT
> openjdk version "13.0.3" 2020-04-14
> OpenJDK Runtime Environment (build 13.0.3+3-Ubuntu-1ubuntu2)
> OpenJDK 64-Bit Server VM (build 13.0.3+3-Ubuntu-1ubuntu2, mixed mode)
>Reporter: Marco Neumann
>Assignee: Greg Albiston
>Priority: Major
> Fix For: Jena 3.17.0
>
>
> geosparql fuseki server can't be started with option combination -rf and -t 
> as described in the jena fuseki geosparql user documentation 
> (https://jena.apache.org/documentation/geosparql/geosparql-fuseki). 
> Individually with either option -rf or -t fuseki geosparql starts fine and 
> works as expected. Data can be loaded programmatically to tdb once created.
> {noformat}
> java -jar jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar -rf data.ttl -t 
> "testDB2"
> WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will 
> impact performance.
> [2020-09-25 20:22:39] Main   INFO  Arguments Received: [-rf, data.ttl, 
> -t, testDB2]
> [2020-09-25 20:22:39] DatasetOperations INFO  Server Configuration: 
> port=3030, datsetName=ds, loopbackOnly=true, updateAllowed=false, 
> inference=false, applyDefaultGeometry=false, validateGeometryLiteral=false, 
> convertGeoPredicates=false, removeGeoPredicates=false, queryRewrite=true, 
> tdbFile=testDB2, fileGraphFormats=[FileGraphFormat{rdfFile=data.ttl, 
> graphName=, rdfFormat=Turtle/pretty}], fileGraphDelimiters=[], 
> indexEnabled=true, indexSizes=[-1, -1, -1], indexExpiries=[5000, 5000, 5000], 
> spatialIndexFile=null, help=false
> [2020-09-25 20:22:39] DatasetOperations INFO  TDB Dataset: testDB2
> [2020-09-25 20:22:41] DatasetOperations INFO  Reading RDF - Started - File: 
> data.ttl, Graph Name: , RDF Format: Turtle/pretty
> [2020-09-25 20:22:41] DatasetOperations INFO  Reading RDF - Completed - File: 
> data.ttl, Graph Name: , RDF Format: Turtle/pretty
> Exception in thread "main" 
> org.apache.jena.tdb.transaction.TDBTransactionException: Not in a transaction
>   at 
> org.apache.jena.tdb.transaction.DatasetGraphTransaction.get(DatasetGraphTransaction.java:138)
>   at 
> org.apache.jena.tdb.transaction.DatasetGraphTransaction.get(DatasetGraphTransaction.java:49)
>   at 
> org.apache.jena.sparql.core.DatasetGraphWrapper.getR(DatasetGraphWrapper.java:103)
>   at 
> org.apache.jena.sparql.core.DatasetGraphWrapper.isEmpty(DatasetGraphWrapper.java:192)
>   at org.apache.jena.sparql.core.DatasetImpl.isEmpty(DatasetImpl.java:247)
>   at 
> org.apache.jena.fuseki.geosparql.DatasetOperations.setup(DatasetOperations.java:95)
>   at org.apache.jena.fuseki.geosparql.Main.main(Main.java:64)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (JENA-1970) GeoSPARQL spatial:nearby geo:lat and geo:long indexing of Literals

[Greg Albiston (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-1970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Albiston resolved JENA-1970.
-
Fix Version/s: Jena 3.17.0
   Resolution: Fixed

Double typed literals and untyped literals in double form are now accepted when 
converting from latitude and longitude coordinates.

> GeoSPARQL spatial:nearby geo:lat and geo:long indexing of Literals
> --
>
> Key: JENA-1970
> URL: https://issues.apache.org/jira/browse/JENA-1970
> Project: Apache Jena
>  Issue Type: New Feature
>  Components: Jena
>Affects Versions: Jena 3.16.0
> Environment: any
>Reporter: Marco Neumann
>Assignee: Greg Albiston
>Priority: Minor
> Fix For: Jena 3.17.0
>
>
> PREFIX spatial: 
> the spatial:nearby property function now fails to operate on untyped 
> literals. While http://www.w3.org/2003/01/geo/wgs84_pos# mentions decimals in 
> the range it is common to find  data in the wild that fails to adhere to the 
> vocabulary specification. Furthermore functions in the 
> http://jena.apache.org/function/spatial# namespace continue to be able to 
> process untyped literals. It might be worthwhile to consider to typecast 
> literals here in spatial functions for data processed for latitude and 
> longitude in the wgs84_pos namespace.
> {noformat}
> Fuseki WARN  [1] RC = 500 : Not a number: "53.72833"
> org.apache.jena.sparql.expr.ExprEvalException: Not a number: "53.72833"
> Caused by: org.apache.jena.datatypes.DatatypeFormatException: Not a number: 
> "53.72833"
>   at 
> org.apache.jena.geosparql.spatial.ConvertLatLon.toNodeValue(ConvertLatLon.java:47)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.geosparql.spatial.ConvertLatLon.toNode(ConvertLatLon.java:62) 
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.geosparql.spatial.property_functions.GenericSpatialPropertyFunction.checkBound(GenericSpatialPropertyFunction.java:132)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.geosparql.spatial.property_functions.GenericSpatialPropertyFunction.search(GenericSpatialPropertyFunction.java:87)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.geosparql.spatial.property_functions.GenericSpatialPropertyFunction.execEvaluated(GenericSpatialPropertyFunction.java:66)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.pfunction.PFuncSimpleAndList.execEvaluated(PFuncSimpleAndList.java:44)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.pfunction.PropertyFunctionEval.exec(PropertyFunctionEval.java:42)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.pfunction.PropertyFunctionBase$RepeatApplyIteratorPF.nextStage(PropertyFunctionBase.java:106)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.makeNextStage(QueryIterRepeatApply.java:108)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:65)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.engine.iterator.QueryIterProcedure.hasNextBinding(QueryIterProcedure.java:73)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.engine.main.iterator.QueryIterGraph$QueryIterGraphInner.hasNextBinding(QueryIterGraph.java:121)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:74)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
>  

[jira] [Assigned] (JENA-1969) Can't start geosparql fuseki server with -rf and -t

[Greg Albiston (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Albiston reassigned JENA-1969:
---

Assignee: Greg Albiston

> Can't start geosparql fuseki server with -rf and -t
> ---
>
> Key: JENA-1969
> URL: https://issues.apache.org/jira/browse/JENA-1969
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: Fuseki, Spatial, TDB
>Affects Versions: Jena 3.16.0
> Environment: Ubuntu 20.04.1 LTS
> JENA_HOME=/apache-jena-3.17.0-SNAPSHOT
> FUSEKI_HOME=/home/lotico/jena/apache-jena-fuseki-3.17.0-SNAPSHOT
> openjdk version "13.0.3" 2020-04-14
> OpenJDK Runtime Environment (build 13.0.3+3-Ubuntu-1ubuntu2)
> OpenJDK 64-Bit Server VM (build 13.0.3+3-Ubuntu-1ubuntu2, mixed mode)
>Reporter: Marco Neumann
>Assignee: Greg Albiston
>Priority: Major
>
> geosparql fuseki server can't be started with option combination -rf and -t 
> as described in the jena fuseki geosparql user documentation 
> (https://jena.apache.org/documentation/geosparql/geosparql-fuseki). 
> Individually with either option -rf or -t fuseki geosparql starts fine and 
> works as expected. Data can be loaded programmatically to tdb once created.
> {noformat}
> java -jar jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar -rf data.ttl -t 
> "testDB2"
> WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will 
> impact performance.
> [2020-09-25 20:22:39] Main   INFO  Arguments Received: [-rf, data.ttl, 
> -t, testDB2]
> [2020-09-25 20:22:39] DatasetOperations INFO  Server Configuration: 
> port=3030, datsetName=ds, loopbackOnly=true, updateAllowed=false, 
> inference=false, applyDefaultGeometry=false, validateGeometryLiteral=false, 
> convertGeoPredicates=false, removeGeoPredicates=false, queryRewrite=true, 
> tdbFile=testDB2, fileGraphFormats=[FileGraphFormat{rdfFile=data.ttl, 
> graphName=, rdfFormat=Turtle/pretty}], fileGraphDelimiters=[], 
> indexEnabled=true, indexSizes=[-1, -1, -1], indexExpiries=[5000, 5000, 5000], 
> spatialIndexFile=null, help=false
> [2020-09-25 20:22:39] DatasetOperations INFO  TDB Dataset: testDB2
> [2020-09-25 20:22:41] DatasetOperations INFO  Reading RDF - Started - File: 
> data.ttl, Graph Name: , RDF Format: Turtle/pretty
> [2020-09-25 20:22:41] DatasetOperations INFO  Reading RDF - Completed - File: 
> data.ttl, Graph Name: , RDF Format: Turtle/pretty
> Exception in thread "main" 
> org.apache.jena.tdb.transaction.TDBTransactionException: Not in a transaction
>   at 
> org.apache.jena.tdb.transaction.DatasetGraphTransaction.get(DatasetGraphTransaction.java:138)
>   at 
> org.apache.jena.tdb.transaction.DatasetGraphTransaction.get(DatasetGraphTransaction.java:49)
>   at 
> org.apache.jena.sparql.core.DatasetGraphWrapper.getR(DatasetGraphWrapper.java:103)
>   at 
> org.apache.jena.sparql.core.DatasetGraphWrapper.isEmpty(DatasetGraphWrapper.java:192)
>   at org.apache.jena.sparql.core.DatasetImpl.isEmpty(DatasetImpl.java:247)
>   at 
> org.apache.jena.fuseki.geosparql.DatasetOperations.setup(DatasetOperations.java:95)
>   at org.apache.jena.fuseki.geosparql.Main.main(Main.java:64)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (JENA-1970) GeoSPARQL spatial:nearby geo:lat and geo:long indexing of Literals

[Greg Albiston (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-1970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Albiston reassigned JENA-1970:
---

Assignee: Greg Albiston

> GeoSPARQL spatial:nearby geo:lat and geo:long indexing of Literals
> --
>
> Key: JENA-1970
> URL: https://issues.apache.org/jira/browse/JENA-1970
> Project: Apache Jena
>  Issue Type: New Feature
>  Components: Jena
>Affects Versions: Jena 3.16.0
> Environment: any
>Reporter: Marco Neumann
>Assignee: Greg Albiston
>Priority: Minor
>
> PREFIX spatial: 
> the spatial:nearby property function now fails to operate on untyped 
> literals. While http://www.w3.org/2003/01/geo/wgs84_pos# mentions decimals in 
> the range it is common to find  data in the wild that fails to adhere to the 
> vocabulary specification. Furthermore functions in the 
> http://jena.apache.org/function/spatial# namespace continue to be able to 
> process untyped literals. It might be worthwhile to consider to typecast 
> literals here in spatial functions for data processed for latitude and 
> longitude in the wgs84_pos namespace.
> {noformat}
> Fuseki WARN  [1] RC = 500 : Not a number: "53.72833"
> org.apache.jena.sparql.expr.ExprEvalException: Not a number: "53.72833"
> Caused by: org.apache.jena.datatypes.DatatypeFormatException: Not a number: 
> "53.72833"
>   at 
> org.apache.jena.geosparql.spatial.ConvertLatLon.toNodeValue(ConvertLatLon.java:47)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.geosparql.spatial.ConvertLatLon.toNode(ConvertLatLon.java:62) 
> ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.geosparql.spatial.property_functions.GenericSpatialPropertyFunction.checkBound(GenericSpatialPropertyFunction.java:132)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.geosparql.spatial.property_functions.GenericSpatialPropertyFunction.search(GenericSpatialPropertyFunction.java:87)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.geosparql.spatial.property_functions.GenericSpatialPropertyFunction.execEvaluated(GenericSpatialPropertyFunction.java:66)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.pfunction.PFuncSimpleAndList.execEvaluated(PFuncSimpleAndList.java:44)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.pfunction.PropertyFunctionEval.exec(PropertyFunctionEval.java:42)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.pfunction.PropertyFunctionBase$RepeatApplyIteratorPF.nextStage(PropertyFunctionBase.java:106)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.makeNextStage(QueryIterRepeatApply.java:108)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:65)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.engine.iterator.QueryIterProcedure.hasNextBinding(QueryIterProcedure.java:73)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.engine.main.iterator.QueryIterGraph$QueryIterGraphInner.hasNextBinding(QueryIterGraph.java:121)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:74)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
>  ~[jena-fuseki-geosparql-3.17.0-20200915.115805-17.jar:3.17.0-SNAPSHOT]
>   at 
> org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.makeNextStage(QueryIterRepeatApply.java:101)
>  

[jira] [Commented] (JENA-1915) spatial:greatCircle appears to be returning wrong answers

[Greg Albiston (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17135217#comment-17135217
 ] 

Greg Albiston commented on JENA-1915:
-

Hi Bryon,

Thanks for reporting this and the test cases. This has now been fixed on 
`master` branch with the test values you provided now being used as unit tests. 
There are still the minor discrepancies (less than 300m) which are likely due 
to rounding differences.

Thanks again,

Greg

> spatial:greatCircle appears to be returning wrong answers
> -
>
> Key: JENA-1915
> URL: https://issues.apache.org/jira/browse/JENA-1915
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Spatial
>Affects Versions: Jena 3.13.1
>Reporter: Bryon Jacob
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> the `spatial:greatCircle` function appears broken - sometimes returning 
> negative numbers.  returning negative numbers can never be correct from a 
> distance function - but I've tried to produce something more useful than that 
> as a defect report and repro...
> I was trying to "port" some SPARQL queries where I'd written the great circle 
> function (Haversine formula) to use the spatial:greatCircle function - which 
> means I had a pretty good test case to see where the issue arises.  I 
> simplified my query down to a repeatable test that demonstrates the issue:
> note that in my original query, I was using a custom jena function to compute 
> `radians` - since that function won't be available to you in stock jena to 
> try this out, I've precomputed the radians values and put them in the VALUES 
> block next to lat/lon pairs.  This should be runnable on any stock Jena 
> instance with the jena-geosparql functions loaded.  Note that for most of the 
> distances computed, the two distances agree quite closely - but for the last 
> two, the jena function returns a negative number, where the hand-computed 
> value is a correct distance between those points 
> {code:java}
> PREFIX m: 
> PREFIX spatial: 
> # this is a namespace of custom functions, which won't be available in stock 
> Jena - to reproduce
> # this, I've pre-computed the radian values and included them in a VALUES 
> block below...
> # PREFIX f: 
> SELECT ?lat1 ?lon1 ?lat2 ?lon2 ?φ1 ?φ2 ?Δφ ?Δλ ?d1 ?d2
>  WHERE {
>  VALUES (?lat1 ?lon1 ?lat2 ?lon2 ?φ1 ?φ2 ?Δφ ?Δλ) {
>  # in my original query, I was computing radians using a custom 
> radians function, which won't be available 
>  # in stock Jena, so to make this reproducible I precomputed the 
> radians values needed for the Haversine
> (41.2572  -95.965641.2592 -95.93390.7201  0.7201  
> 0.  0.0006)
> (41.2572  -95.965641.2482 -96.072 0.7201  0.7199  
> -0.0002 -0.0019)
> (41.2572  -95.965641.5871 -93.626 0.7201  0.7258  
> 0.0058  0.0408)
> (41.2572  -95.965651.0472 -113.9998   0.7201  0.8909  
> 0.1709  -0.3148)
> (41.2572  -95.965640.7528 -73.98760.7201  0.7113  
> -0.0088 0.3836)
> (41.2572  -95.965649.7237 13.3422 0.7201  0.8678  
> 0.1478  1.9078)
> (41.2572  -95.9656-33.906518.4175 0.7201  
> -0.5918 -1.3119 1.9964)
> (41.2572  -95.9656-33.8646151.20990.7201  
> -0.5910 -1.3111 4.3140)
>  }
> 
> # calculate the "great circle" distance between the two (lat φ, long λ) 
> points, in kilometers.
> # these are the function calls in my original query, commented out and 
> replaced with VALUES above
> # BIND (f:radians(?lat1) AS ?φ1)
> # BIND (f:radians(?lat2) AS ?φ2)
> # BIND (f:radians(?lat2 - ?lat1) AS ?Δφ)
> # BIND (f:radians(?lon2 - ?lon1) AS ?Δλ)
> BIND (m:sin(?Δφ / 2) * m:sin(?Δφ / 2) + m:cos(?φ1) * m:cos(?φ2) * 
> m:sin(?Δλ / 2) * m:sin(?Δλ / 2) AS ?a)
> BIND (2 * m:atan2(m:sqrt(?a), m:sqrt(1 - ?a)) AS ?c)
> BIND (6371 AS ?RadiusOfEarthInKm)
> BIND (?RadiusOfEarthInKm * ?c AS ?d1)
> # call the Jena function for comparison
> BIND(spatial:greatCircle(?lat1, ?lon1, ?lat2, ?lon2, 
> ) AS ?d2)
> }
> {code}
>  
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (JENA-1818) Bug: CustomCoordinateSequence::setOrdinate missing break statements

[Greg Albiston (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Albiston resolved JENA-1818.
-
Fix Version/s: Jena 3.15.0
   Resolution: Fixed

Break statements added.

> Bug: CustomCoordinateSequence::setOrdinate missing break statements
> ---
>
> Key: JENA-1818
> URL: https://issues.apache.org/jira/browse/JENA-1818
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Spatial
>Affects Versions: Jena 3.13.1
>Reporter: Philipp Neuschwander
>Assignee: Greg Albiston
>Priority: Major
> Fix For: Jena 3.15.0
>
>
> https://github.com/apache/jena/blob/master/jena-geosparql/src/main/java/org/apache/jena/geosparql/implementation/jts/CustomCoordinateSequence.java#L441
>  
> There should be "break" statements in that switch.
> Currently there is a fallthrough manipulating other axis' values leading to 
> data corruption.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (JENA-1818) Bug: CustomCoordinateSequence::setOrdinate missing break statements

[Greg Albiston (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Albiston reassigned JENA-1818:
---

Assignee: Greg Albiston

> Bug: CustomCoordinateSequence::setOrdinate missing break statements
> ---
>
> Key: JENA-1818
> URL: https://issues.apache.org/jira/browse/JENA-1818
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Spatial
>Affects Versions: Jena 3.13.1
>Reporter: Philipp Neuschwander
>Assignee: Greg Albiston
>Priority: Major
>
> https://github.com/apache/jena/blob/master/jena-geosparql/src/main/java/org/apache/jena/geosparql/implementation/jts/CustomCoordinateSequence.java#L441
>  
> There should be "break" statements in that switch.
> Currently there is a fallthrough manipulating other axis' values leading to 
> data corruption.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (JENA-1820) GeometryWrapper::asLiteral throws NullPointerException for GMLDatatype, malformed lexicalForm

[Greg Albiston (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Albiston resolved JENA-1820.
-
Fix Version/s: Jena 3.15.0
   Resolution: Fixed

LinearRing added to XML construction for Polygon GML shape. Tests updated.

> GeometryWrapper::asLiteral throws NullPointerException for GMLDatatype, 
> malformed lexicalForm
> -
>
> Key: JENA-1820
> URL: https://issues.apache.org/jira/browse/JENA-1820
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Spatial
>Affects Versions: Jena 3.13.1
>Reporter: Philipp Neuschwander
>Assignee: Greg Albiston
>Priority: Major
> Fix For: Jena 3.15.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> GML-Literal of MultiPolygon/Polygon is malformed (generated by GMLWriter).
> Under the gml:exterior and gml:interior node, there should be a linear ring 
> that contains the posList. But the posList is generated as a direct child to 
> gml:exterior/interior:
> {code:java}
> http://www.opengis.net/ont/gml; 
> srsName="http://www.opengis.net/def/crs/OGC/1.3/CRS84;>  
> srsName="http://www.opengis.net/def/crs/OGC/1.3/CRS84;>0
>  0 10 0 10 10 0 10 0 
> 05 5 7 7 7 5 5 
> 54 4 4 5 5 5 4 
> 4
> {code}
> The missing linearRing leads to NullPointerException when trying to call
> {code:java}
> geometryWrapper.asLiteral(GMLDatatype.INSTANCE)
> {code}
> as the GMLReader (I have no clue why it is called as part of the 
> asLiteral-call) tries to access the linearRing and it's posList child. 
> Stackstrace:
> {code}
> java.lang.NullPointerException: null
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.extractPosList(GMLReader.java:223)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildLinearRing(GMLReader.java:503)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildPolygon(GMLReader.java:477)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildMultiSurface(GMLReader.java:644)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildGeometry(GMLReader.java:199)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.(GMLReader.java:108)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.extract(GMLReader.java:707)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.datatype.GMLDatatype.read(GMLDatatype.java:84)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.index.GeometryLiteralIndex.retrieveMemoryIndex(GeometryLiteralIndex.java:77)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.index.GeometryLiteralIndex.retrieve(GeometryLiteralIndex.java:51)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:57)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:50)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:32)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.graph.impl.LiteralLabelImpl.setValue(LiteralLabelImpl.java:217)
>  ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.graph.impl.LiteralLabelImpl.setLiteralLabel_1(LiteralLabelImpl.java:111)
>  ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.graph.impl.LiteralLabelImpl.(LiteralLabelImpl.java:100) 
> ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.graph.impl.LiteralLabelFactory.create(LiteralLabelFactory.java:50)
>  ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.graph.NodeFactory.createLiteral(NodeFactory.java:171) 
> ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.rdf.model.ResourceFactory$Impl.createTypedLiteral(ResourceFactory.java:313)
>  ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.rdf.model.ResourceFactory.createTypedLiteral(ResourceFactory.java:148)
>  ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.GeometryWrapper.asLiteral(GeometryWrapper.java:986)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (JENA-1820) GeometryWrapper::asLiteral throws NullPointerException for GMLDatatype, malformed lexicalForm

[Greg Albiston (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17019764#comment-17019764
 ] 

Greg Albiston edited comment on JENA-1820 at 1/20/20 10:56 PM:
---

This has now been fixed in 3.15.0-snapshot. Apologies for any inconvenience.

 


was (Author: gregalbiston):
This has now been fixed in 3.15-snapshot. Apologies for any inconvenience.

 

> GeometryWrapper::asLiteral throws NullPointerException for GMLDatatype, 
> malformed lexicalForm
> -
>
> Key: JENA-1820
> URL: https://issues.apache.org/jira/browse/JENA-1820
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Spatial
>Affects Versions: Jena 3.13.1
>Reporter: Philipp Neuschwander
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> GML-Literal of MultiPolygon/Polygon is malformed (generated by GMLWriter).
> Under the gml:exterior and gml:interior node, there should be a linear ring 
> that contains the posList. But the posList is generated as a direct child to 
> gml:exterior/interior:
> {code:java}
> http://www.opengis.net/ont/gml; 
> srsName="http://www.opengis.net/def/crs/OGC/1.3/CRS84;>  
> srsName="http://www.opengis.net/def/crs/OGC/1.3/CRS84;>0
>  0 10 0 10 10 0 10 0 
> 05 5 7 7 7 5 5 
> 54 4 4 5 5 5 4 
> 4
> {code}
> The missing linearRing leads to NullPointerException when trying to call
> {code:java}
> geometryWrapper.asLiteral(GMLDatatype.INSTANCE)
> {code}
> as the GMLReader (I have no clue why it is called as part of the 
> asLiteral-call) tries to access the linearRing and it's posList child. 
> Stackstrace:
> {code}
> java.lang.NullPointerException: null
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.extractPosList(GMLReader.java:223)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildLinearRing(GMLReader.java:503)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildPolygon(GMLReader.java:477)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildMultiSurface(GMLReader.java:644)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildGeometry(GMLReader.java:199)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.(GMLReader.java:108)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.extract(GMLReader.java:707)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.datatype.GMLDatatype.read(GMLDatatype.java:84)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.index.GeometryLiteralIndex.retrieveMemoryIndex(GeometryLiteralIndex.java:77)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.index.GeometryLiteralIndex.retrieve(GeometryLiteralIndex.java:51)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:57)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:50)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:32)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.graph.impl.LiteralLabelImpl.setValue(LiteralLabelImpl.java:217)
>  ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.graph.impl.LiteralLabelImpl.setLiteralLabel_1(LiteralLabelImpl.java:111)
>  ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.graph.impl.LiteralLabelImpl.(LiteralLabelImpl.java:100) 
> ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.graph.impl.LiteralLabelFactory.create(LiteralLabelFactory.java:50)
>  ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.graph.NodeFactory.createLiteral(NodeFactory.java:171) 
> ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.rdf.model.ResourceFactory$Impl.createTypedLiteral(ResourceFactory.java:313)
>  ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.rdf.model.ResourceFactory.createTypedLiteral(ResourceFactory.java:148)
>  ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.GeometryWrapper.asLiteral(GeometryWrapper.java:986)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (JENA-1820) GeometryWrapper::asLiteral throws NullPointerException for GMLDatatype, malformed lexicalForm

[Greg Albiston (Jira)]

 [ 
https://issues.apache.org/jira/browse/JENA-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Albiston reassigned JENA-1820:
---

Assignee: Greg Albiston

> GeometryWrapper::asLiteral throws NullPointerException for GMLDatatype, 
> malformed lexicalForm
> -
>
> Key: JENA-1820
> URL: https://issues.apache.org/jira/browse/JENA-1820
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Spatial
>Affects Versions: Jena 3.13.1
>Reporter: Philipp Neuschwander
>Assignee: Greg Albiston
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> GML-Literal of MultiPolygon/Polygon is malformed (generated by GMLWriter).
> Under the gml:exterior and gml:interior node, there should be a linear ring 
> that contains the posList. But the posList is generated as a direct child to 
> gml:exterior/interior:
> {code:java}
> http://www.opengis.net/ont/gml; 
> srsName="http://www.opengis.net/def/crs/OGC/1.3/CRS84;>  
> srsName="http://www.opengis.net/def/crs/OGC/1.3/CRS84;>0
>  0 10 0 10 10 0 10 0 
> 05 5 7 7 7 5 5 
> 54 4 4 5 5 5 4 
> 4
> {code}
> The missing linearRing leads to NullPointerException when trying to call
> {code:java}
> geometryWrapper.asLiteral(GMLDatatype.INSTANCE)
> {code}
> as the GMLReader (I have no clue why it is called as part of the 
> asLiteral-call) tries to access the linearRing and it's posList child. 
> Stackstrace:
> {code}
> java.lang.NullPointerException: null
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.extractPosList(GMLReader.java:223)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildLinearRing(GMLReader.java:503)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildPolygon(GMLReader.java:477)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildMultiSurface(GMLReader.java:644)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildGeometry(GMLReader.java:199)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.(GMLReader.java:108)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.extract(GMLReader.java:707)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.datatype.GMLDatatype.read(GMLDatatype.java:84)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.index.GeometryLiteralIndex.retrieveMemoryIndex(GeometryLiteralIndex.java:77)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.index.GeometryLiteralIndex.retrieve(GeometryLiteralIndex.java:51)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:57)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:50)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:32)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.graph.impl.LiteralLabelImpl.setValue(LiteralLabelImpl.java:217)
>  ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.graph.impl.LiteralLabelImpl.setLiteralLabel_1(LiteralLabelImpl.java:111)
>  ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.graph.impl.LiteralLabelImpl.(LiteralLabelImpl.java:100) 
> ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.graph.impl.LiteralLabelFactory.create(LiteralLabelFactory.java:50)
>  ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.graph.NodeFactory.createLiteral(NodeFactory.java:171) 
> ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.rdf.model.ResourceFactory$Impl.createTypedLiteral(ResourceFactory.java:313)
>  ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.rdf.model.ResourceFactory.createTypedLiteral(ResourceFactory.java:148)
>  ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.GeometryWrapper.asLiteral(GeometryWrapper.java:986)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JENA-1820) GeometryWrapper::asLiteral throws NullPointerException for GMLDatatype, malformed lexicalForm

[Greg Albiston (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17019764#comment-17019764
 ] 

Greg Albiston commented on JENA-1820:
-

This has now been fixed in 3.15-snapshot. Apologies for any inconvenience.

 

> GeometryWrapper::asLiteral throws NullPointerException for GMLDatatype, 
> malformed lexicalForm
> -
>
> Key: JENA-1820
> URL: https://issues.apache.org/jira/browse/JENA-1820
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Spatial
>Affects Versions: Jena 3.13.1
>Reporter: Philipp Neuschwander
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> GML-Literal of MultiPolygon/Polygon is malformed (generated by GMLWriter).
> Under the gml:exterior and gml:interior node, there should be a linear ring 
> that contains the posList. But the posList is generated as a direct child to 
> gml:exterior/interior:
> {code:java}
> http://www.opengis.net/ont/gml; 
> srsName="http://www.opengis.net/def/crs/OGC/1.3/CRS84;>  
> srsName="http://www.opengis.net/def/crs/OGC/1.3/CRS84;>0
>  0 10 0 10 10 0 10 0 
> 05 5 7 7 7 5 5 
> 54 4 4 5 5 5 4 
> 4
> {code}
> The missing linearRing leads to NullPointerException when trying to call
> {code:java}
> geometryWrapper.asLiteral(GMLDatatype.INSTANCE)
> {code}
> as the GMLReader (I have no clue why it is called as part of the 
> asLiteral-call) tries to access the linearRing and it's posList child. 
> Stackstrace:
> {code}
> java.lang.NullPointerException: null
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.extractPosList(GMLReader.java:223)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildLinearRing(GMLReader.java:503)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildPolygon(GMLReader.java:477)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildMultiSurface(GMLReader.java:644)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.buildGeometry(GMLReader.java:199)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.(GMLReader.java:108)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.parsers.gml.GMLReader.extract(GMLReader.java:707)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.datatype.GMLDatatype.read(GMLDatatype.java:84)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.index.GeometryLiteralIndex.retrieveMemoryIndex(GeometryLiteralIndex.java:77)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.index.GeometryLiteralIndex.retrieve(GeometryLiteralIndex.java:51)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:57)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:50)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.datatype.GeometryDatatype.parse(GeometryDatatype.java:32)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.graph.impl.LiteralLabelImpl.setValue(LiteralLabelImpl.java:217)
>  ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.graph.impl.LiteralLabelImpl.setLiteralLabel_1(LiteralLabelImpl.java:111)
>  ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.graph.impl.LiteralLabelImpl.(LiteralLabelImpl.java:100) 
> ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.graph.impl.LiteralLabelFactory.create(LiteralLabelFactory.java:50)
>  ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.graph.NodeFactory.createLiteral(NodeFactory.java:171) 
> ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.rdf.model.ResourceFactory$Impl.createTypedLiteral(ResourceFactory.java:313)
>  ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.rdf.model.ResourceFactory.createTypedLiteral(ResourceFactory.java:148)
>  ~[jena-core-3.13.1.jar:3.13.1]
>   at 
> org.apache.jena.geosparql.implementation.GeometryWrapper.asLiteral(GeometryWrapper.java:986)
>  ~[jena-geosparql-3.13.1.jar:3.13.1]
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query

[Greg Albiston (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929969#comment-16929969
 ] 

Greg Albiston commented on JENA-1402:
-

There is `java.time.Period` 
([https://docs.oracle.com/javase/8/docs/api/java/time/Period.html)] for 
differences in dates, perhaps this could replace the `javax.xml.Duration`?

I found this StackOverflow which goes into detail about replacing Gregorian 
Calendar with `java.time`.

[https://stackoverflow.com/questions/835889/java-util-date-to-xmlgregoriancalendar]

 

> Subtracting two xsd:Duration gives incorrect results in SPARQL query
> 
>
> Key: JENA-1402
> URL: https://issues.apache.org/jira/browse/JENA-1402
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.4.0
>Reporter: Greg Albiston
>Priority: Major
>
> There is an issue when subtracting two xsd:durations that include:
> * decimal seconds
> * non-zero minutes
> * second operand has a greater number of seconds than the first operand, i.e. 
> the minutes are reduced. 
> The result is a large number of minutes and incorrect seconds.
> For example:
> Integer, Larger: "PT2M3S" - "PT1M10S"  = "PT0M53S" CORRECT
> Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
> Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S"  = "-PT1M7.000S" 
> CORRECT
> Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S"  = "PT883M0.020S" 
> INCORRECT
> Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S" 
> INCORRECT
> Example SPARQL:
> {code:sparql}
> SELECT ?res ?op1 ?op2
> WHERE{
>VALUES (?op1 ?op2) {
> ("PT2M3S"^^ 
> "PT1M10S"^^)
> ("PT2M3.123S"^^ 
> "PT1M1.123S"^^)
> ("PT0M3.123S"^^ 
> "PT1M10.123S"^^)
> ("PT2M3.123S"^^ 
> "PT1M10.123S"^^)
> ("PT1H4M3.123S"^^ 
> "PT0M10.123S"^^)
> }
> BIND(?op1 - ?op2 AS ?res)
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (JENA-1740) Extending Apache Jena with more geospatial functions

[Greg Albiston (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16918396#comment-16918396
 ] 

Greg Albiston commented on JENA-1740:
-

Ideally the textual data formats would be treated with a similar approach to 
the GeometryLiterals. It will depend upon how costly they are to deserialise 
but should be possible to re-use/re-purpose the current caching for them.

> Extending Apache Jena with more geospatial functions
> 
>
> Key: JENA-1740
> URL: https://issues.apache.org/jira/browse/JENA-1740
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Timo Homburg
>Priority: Minor
>
> Hello,
> I am the developer of a project which I named postgis-jena 
> (https://github.com/i3mainz/postgis-jena), originally aimed at extending 
> JenaARQ with query functions common in databases such as POSTGIS but now 
> going beyond that approach and also integrating support for raster data 
> (still WIP). I am building up work being done by Greg Albistons extension 
> geosparql-jena.
> Is this extension of interest for Apache Jena as a plugin or in another 
> context?



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (JENA-1740) Extending Apache Jena with more geospatial functions

[Greg Albiston (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917512#comment-16917512
 ] 

Greg Albiston commented on JENA-1740:
-

Additional contributions to the GeoSPARQL extension can be provided through a 
pull request against the Apache Jena repo on GitHub.

A concern with storing large pieces of data in triplestores is that triples can 
be accessed repeatedly during a query, e.g unbound variables. This means that 
performance can suffer if the triple cannot be quickly processed and analysed. 
When developing the GeoSPARQL, I found that the GeometryLiterals were being 
accessed and decoded about 7 times when resolving a query, hence the short-term 
caching that is applied.

It may be more prudent to use a hashing function, or similar, and store that as 
the literal value in the triplestore. This can then be used to look up from a 
filestore and return/manipulate the raster if required. This might mean having 
a function that converts the hash literal into a raster literal for return from 
a query.

It would seem that a seperate module is needed that can then depend upon the 
GeoSPARQL module. Within that module the two (or more) groups of functions can 
be loaded as required by the user.

> Extending Apache Jena with more geospatial functions
> 
>
> Key: JENA-1740
> URL: https://issues.apache.org/jira/browse/JENA-1740
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Timo Homburg
>Priority: Minor
>
> Hello,
> I am the developer of a project which I named postgis-jena 
> (https://github.com/i3mainz/postgis-jena), originally aimed at extending 
> JenaARQ with query functions common in databases such as POSTGIS but now 
> going beyond that approach and also integrating support for raster data 
> (still WIP). I am building up work being done by Greg Albistons extension 
> geosparql-jena.
> Is this extension of interest for Apache Jena as a plugin or in another 
> context?



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (JENA-1740) Extending Apache Jena with more geospatial functions

[Greg Albiston (Jira)]

[ 
https://issues.apache.org/jira/browse/JENA-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16913789#comment-16913789
 ] 

Greg Albiston commented on JENA-1740:
-

Hi Timo,

The work from geosparql-jena is now available as a module in Jena. It should be 
possible to switch the dependency with only the package names needing updating, 
i.e. `io.github.galbiston.geosparql_jena` to `org.apache.jena.geosparql`.


    org.apache.jena
    jena-geosparql
    3.12.0


 

>From what I recall the PostGIS functions in some cases overlap with the 
>GeoSPARQL functions, which focuses on spatial relations. This is due to both 
>in part being derived from the Simple Features standard, but where GeoSPARQL 
>was designed for open system of SPARQL and PostGIS for closed system of SQL.

Something that the PostGIS functions also seem to offer is an extensive range 
of functions to manipulate geospatial data.

The raster data functionality mentioned is not considered in GeoSPARQL. Others 
might be able to answer better whether raster data is ideally suited for 
encoding in RDF, storing in a triplestore and querying (doesn't raster data get 
large very quickly while potentially having a lot of similarity between cases?) 
or whether some cross-reference lookup to another datastore is needed.

Hopefully this a useful and accurate enough generalisation of some differences 
between GeoSPARQL and PostGIS.

Thanks,

Greg

> Extending Apache Jena with more geospatial functions
> 
>
> Key: JENA-1740
> URL: https://issues.apache.org/jira/browse/JENA-1740
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Timo Homburg
>Priority: Minor
>
> Hello,
> I am the developer of a project which I named postgis-jena 
> (https://github.com/i3mainz/postgis-jena), originally aimed at extending 
> JenaARQ with query functions common in databases such as POSTGIS but now 
> going beyond that approach and also integrating support for raster data 
> (still WIP). I am building up work being done by Greg Albistons extension 
> geosparql-jena.
> Is this extension of interest for Apache Jena as a plugin or in another 
> context?



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Closed] (JENA-1661) FunctionBase5: 5 argument abstract class for filter functions.

[Greg Albiston (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Albiston closed JENA-1661.
---
Resolution: Fixed

Sorry. Didn't realise this had already been merged.

> FunctionBase5: 5 argument abstract class for filter functions.
> --
>
> Key: JENA-1661
> URL: https://issues.apache.org/jira/browse/JENA-1661
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Greg Albiston
>Priority: Trivial
>
> Extended FunctionBase4 for 5 argument case.
> Currently, one to four arguments are supported.
> A use case is the spatial GeoSPARQL module measuring distance between two 
> Lat/Lon pairs and a units URI label (i.e. 2 + 2 + 1 arguments).
> Pull request created on GitHub for this minor addition.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (JENA-1661) FunctionBase5: 5 argument abstract class for filter functions.

[Greg Albiston (JIRA)]

Greg Albiston created JENA-1661:
---

 Summary: FunctionBase5: 5 argument abstract class for filter 
functions.
 Key: JENA-1661
 URL: https://issues.apache.org/jira/browse/JENA-1661
 Project: Apache Jena
  Issue Type: Improvement
Reporter: Greg Albiston


Extended FunctionBase4 for 5 argument case.

Currently, one to four arguments are supported.

A use case is the spatial GeoSPARQL module measuring distance between two 
Lat/Lon pairs and a units URI label (i.e. 2 + 2 + 1 arguments).

Pull request created on GitHub for this minor addition.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query

[Greg Albiston (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740821#comment-16740821
 ] 

Greg Albiston commented on JENA-1402:
-

I've had a quick look at _NodeValueDuration_ and where it is used in the ARQ 
module.

In _XSDFuncOp,_ there are checks to get and set fields (i.e. year, month) which 
aren't explicit on the _java.time.Duration_ as it only goes up to days. 
Converting days to months and years consistently could be problematic without a 
start date for context.

In _CastXSD,_ there are checks against the _xml.Duration_ fields for building 
new durations of type _xdt:dayTimeDuration_ or _xdt:yearMonthDuration_ (these 
aren't explicit in _java.time.Duration_). Same issue as above in distinguishing 
when x days becomes y months.

In _NodeValueOps,_ there are operations using _XMLGregorianCalendar_ for which 
_java.time.Duration_ doesn't have methods. _java.time.__LocalTime_ and 
_java.time.__OffsetTime_ can be built from parsing the 
_XMLGregorianCalendar.toString()_ but need to be selected based on whether 
there is a TimeZone offset. _LocalTime/__OffsetTime_ could then be used to 
operate on the _java.time.Duration._

So it could be quite difficult to swap to _java.time.Duration_ and retain the 
XML Datatype functionality. Perhaps the extra classes or approach Bruno 
mentioned might help.

> Subtracting two xsd:Duration gives incorrect results in SPARQL query
> 
>
> Key: JENA-1402
> URL: https://issues.apache.org/jira/browse/JENA-1402
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.4.0
>Reporter: Greg Albiston
>Priority: Major
>
> There is an issue when subtracting two xsd:durations that include:
> * decimal seconds
> * non-zero minutes
> * second operand has a greater number of seconds than the first operand, i.e. 
> the minutes are reduced. 
> The result is a large number of minutes and incorrect seconds.
> For example:
> Integer, Larger: "PT2M3S" - "PT1M10S"  = "PT0M53S" CORRECT
> Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
> Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S"  = "-PT1M7.000S" 
> CORRECT
> Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S"  = "PT883M0.020S" 
> INCORRECT
> Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S" 
> INCORRECT
> Example SPARQL:
> {code:sparql}
> SELECT ?res ?op1 ?op2
> WHERE{
>VALUES (?op1 ?op2) {
> ("PT2M3S"^^ 
> "PT1M10S"^^)
> ("PT2M3.123S"^^ 
> "PT1M1.123S"^^)
> ("PT0M3.123S"^^ 
> "PT1M10.123S"^^)
> ("PT2M3.123S"^^ 
> "PT1M10.123S"^^)
> ("PT1H4M3.123S"^^ 
> "PT0M10.123S"^^)
> }
> BIND(?op1 - ?op2 AS ?res)
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query

[Greg Albiston (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16737062#comment-16737062
 ] 

Greg Albiston commented on JENA-1402:
-

Just to update that the underlying issue in javax.xml is reported as fixed in 
JDK12 (JDK-8190835).

[https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190835]

 

> Subtracting two xsd:Duration gives incorrect results in SPARQL query
> 
>
> Key: JENA-1402
> URL: https://issues.apache.org/jira/browse/JENA-1402
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.4.0
>Reporter: Greg Albiston
>Priority: Major
>
> There is an issue when subtracting two xsd:durations that include:
> * decimal seconds
> * non-zero minutes
> * second operand has a greater number of seconds than the first operand, i.e. 
> the minutes are reduced. 
> The result is a large number of minutes and incorrect seconds.
> For example:
> Integer, Larger: "PT2M3S" - "PT1M10S"  = "PT0M53S" CORRECT
> Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
> Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S"  = "-PT1M7.000S" 
> CORRECT
> Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S"  = "PT883M0.020S" 
> INCORRECT
> Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S" 
> INCORRECT
> Example SPARQL:
> {code:sparql}
> SELECT ?res ?op1 ?op2
> WHERE{
>VALUES (?op1 ?op2) {
> ("PT2M3S"^^ 
> "PT1M10S"^^)
> ("PT2M3.123S"^^ 
> "PT1M1.123S"^^)
> ("PT0M3.123S"^^ 
> "PT1M10.123S"^^)
> ("PT2M3.123S"^^ 
> "PT1M10.123S"^^)
> ("PT1H4M3.123S"^^ 
> "PT0M10.123S"^^)
> }
> BIND(?op1 - ?op2 AS ?res)
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1644) ParameterizedSparqlString Empty List fix

[Greg Albiston (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16704632#comment-16704632
 ] 

Greg Albiston commented on JENA-1644:
-

Pullrequest to fix this issue submitted on GitHub.

> ParameterizedSparqlString Empty List fix
> 
>
> Key: JENA-1644
> URL: https://issues.apache.org/jira/browse/JENA-1644
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.9.0
>Reporter: Greg Albiston
>Priority: Minor
>
> ParameterizedSparqlString throws a StringIndexOutOfBoundsException when empty 
> list of values is provided.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JENA-1644) ParameterizedSparqlString Empty List fix

[Greg Albiston (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Albiston updated JENA-1644:

Description: ParameterizedSparqlString throws a 
StringIndexOutOfBoundsException when empty list of values is provided.  (was: 
ParameterizedSparqlString now accepts an empty list of values rather than 
throwing a StringIndexOutOfBoundsException.)

> ParameterizedSparqlString Empty List fix
> 
>
> Key: JENA-1644
> URL: https://issues.apache.org/jira/browse/JENA-1644
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.9.0
>Reporter: Greg Albiston
>Priority: Minor
>
> ParameterizedSparqlString throws a StringIndexOutOfBoundsException when empty 
> list of values is provided.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (JENA-1644) ParameterizedSparqlString Empty List fix

[Greg Albiston (JIRA)]

Greg Albiston created JENA-1644:
---

 Summary: ParameterizedSparqlString Empty List fix
 Key: JENA-1644
 URL: https://issues.apache.org/jira/browse/JENA-1644
 Project: Apache Jena
  Issue Type: Bug
Affects Versions: Jena 3.9.0
Reporter: Greg Albiston


ParameterizedSparqlString now accepts an empty list of values rather than 
throwing a StringIndexOutOfBoundsException.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (JENA-1578) SPARQL VALUES for ParameterizedSparqlString

[Greg Albiston (JIRA)]

Greg Albiston created JENA-1578:
---

 Summary: SPARQL VALUES for ParameterizedSparqlString
 Key: JENA-1578
 URL: https://issues.apache.org/jira/browse/JENA-1578
 Project: Apache Jena
  Issue Type: New Feature
  Components: ARQ
Affects Versions: Jena 3.8.0
Reporter: Greg Albiston


ParameterizedSparqlString provides an API for substituting variables within 
SPARQL queries with bound values. It does not support the SPARQL VALUES keyword 
which allows multiple values to be specified. The VALUES syntax supports 
multiple values for a single variable, sets of values for multiple variables 
and multiple sets of values for multiple values.

Inquiry on 24/07/18 the mailing list about this feature. Patch is forthcoming.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1521) TDB2 backed Datasets cannot be re-opened.

[Greg Albiston (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437775#comment-16437775
 ] 

Greg Albiston commented on JENA-1521:
-

Hi Andy,

I understand what your saying about not using it again and the create/destroy 
pattern. However, should there not be some way to reverse a closure without an 
application restarting? There is no obvious method on the Dataset. What if a 
dataset is passed into a third party library which closes it?

Also, how are resources associated with opening the dataset released? For 
example, open the dataset, do some work, go away for a long time, come back and 
reopen. There might only be a small overhead but a developer may wish to they 
are being well behaved and ensuring an in-memory caching is flushed.

>From what you've mentioned the semantics of Datasets are close and can NEVER 
>be accessed again but QueryIterators are MUST close after use to avoid wasting 
>resources.

It just seems strange,

Greg

> TDB2 backed Datasets cannot be re-opened.
> -
>
> Key: JENA-1521
> URL: https://issues.apache.org/jira/browse/JENA-1521
> Project: Apache Jena
>  Issue Type: Bug
> Environment: Apache Jena: 3.7.0
> Java: 1.8_162
>Reporter: Greg Albiston
>Priority: Major
>
> If a Dataset connected to with TDB2Factory.connectDataset() is opened, closed 
> and then later re-opened it is reported that the Dataset is closed.
> Opening, closing and re-opening a Dataset with TDBFactory.createDataset() 
> causes no issues.
> Example code to reproduce:
> {noformat}
> public void testTDB2OpenClose() {
> System.out.println("TDB2 Open Close");
>  try {
>  Dataset dataset = TDB2Factory.connectDataset("test_tdb2");
>  dataset.begin(ReadWrite.WRITE);
>  Model defaultModel = dataset.getDefaultModel();
>  
> defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
>  ResourceFactory.createProperty("http://example.org/my#PropA;), 
> ResourceFactory.createResource("http://example.org/my#ObjA;));
>  dataset.commit();
>  dataset.end();
>  dataset.close();
> Dataset dataset2 = TDB2Factory.connectDataset("test_tdb2");
>  dataset2.begin(ReadWrite.READ);
>  Model readModel = dataset2.getDefaultModel();
>  Iterator statements = readModel.listStatements();
>  while (statements.hasNext())
> { Statement statement = statements.next(); System.out.println(statement); }
>  dataset2.end();
>  dataset2.close();
>  } catch (Exception ex) \{ System.out.println("Exception: " + 
> ex.getMessage()); }
>  }
>  {noformat}
> {noformat}
>  public void testTDB1OpenClose() {
>  
>  System.out.println("TDB1 Open Close");
>  try {
>  Dataset dataset = TDBFactory.createDataset("test_tdb1");
>  dataset.begin(ReadWrite.WRITE);
>  Model defaultModel = dataset.getDefaultModel();
>  
> defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
>  ResourceFactory.createProperty("http://example.org/my#PropA;), 
> ResourceFactory.createResource("http://example.org/my#ObjA;));
>  dataset.commit();
>  dataset.end();
>  dataset.close();
>  
>  Dataset dataset2 = TDBFactory.createDataset("test_tdb1");
>  dataset2.begin(ReadWrite.READ);
>  Model readModel = dataset2.getDefaultModel();
>  Iterator statements = readModel.listStatements();
>  while (statements.hasNext()) \{ Statement statement = statements.next(); 
> System.out.println(statement); }
> dataset2.end();
>  dataset2.close();
>  } catch (Exception ex)
> { System.out.println("Exception: " + ex.getMessage()); }
> }
> {noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JENA-1521) TDB2 backed Datasets cannot be re-opened.

[Greg Albiston (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Albiston updated JENA-1521:

Environment: 
Apache Jena: 3.7.0

Java: 1.8_162

> TDB2 backed Datasets cannot be re-opened.
> -
>
> Key: JENA-1521
> URL: https://issues.apache.org/jira/browse/JENA-1521
> Project: Apache Jena
>  Issue Type: Bug
> Environment: Apache Jena: 3.7.0
> Java: 1.8_162
>Reporter: Greg Albiston
>Priority: Major
>
> If a Dataset connected to with TDB2Factory.connectDataset() is opened, closed 
> and then later re-opened it is reported that the Dataset is closed.
> Opening, closing and re-opening a Dataset with TDBFactory.createDataset() 
> causes no issues.
> Example code to reproduce:
> public void testTDB2OpenClose() {
> System.out.println("TDB2 Open Close");
>  try {
>  Dataset dataset = TDB2Factory.connectDataset("test_tdb2");
>  dataset.begin(ReadWrite.WRITE);
>  Model defaultModel = dataset.getDefaultModel();
>  
> defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
>  ResourceFactory.createProperty("http://example.org/my#PropA;), 
> ResourceFactory.createResource("http://example.org/my#ObjA;));
>  dataset.commit();
>  dataset.end();
>  dataset.close();
> Dataset dataset2 = TDB2Factory.connectDataset("test_tdb2");
>  dataset2.begin(ReadWrite.READ);
>  Model readModel = dataset2.getDefaultModel();
>  Iterator statements = readModel.listStatements();
>  while (statements.hasNext()) {
>  Statement statement = statements.next();
>  System.out.println(statement);
>  }
>  dataset2.end();
>  dataset2.close();
>  } catch (Exception ex) {
>  System.out.println("Exception: " + ex.getMessage());
>  }
>  }
>  public void testTDB1OpenClose() {
> System.out.println("TDB1 Open Close");
>  try {
>  Dataset dataset = TDBFactory.createDataset("test_tdb1");
>  dataset.begin(ReadWrite.WRITE);
>  Model defaultModel = dataset.getDefaultModel();
>  
> defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;),
>  ResourceFactory.createProperty("http://example.org/my#PropA;), 
> ResourceFactory.createResource("http://example.org/my#ObjA;));
>  dataset.commit();
>  dataset.end();
>  dataset.close();
> Dataset dataset2 = TDBFactory.createDataset("test_tdb1");
>  dataset2.begin(ReadWrite.READ);
>  Model readModel = dataset2.getDefaultModel();
>  Iterator statements = readModel.listStatements();
>  while (statements.hasNext()) {
>  Statement statement = statements.next();
>  System.out.println(statement);
>  }
>  dataset2.end();
>  dataset2.close();
>  } catch (Exception ex) {
>  System.out.println("Exception: " + ex.getMessage());
>  }
>  }
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (JENA-1521) TDB2 backed Datasets cannot be re-opened.

[Greg Albiston (JIRA)]

Greg Albiston created JENA-1521:
---

 Summary: TDB2 backed Datasets cannot be re-opened.
 Key: JENA-1521
 URL: https://issues.apache.org/jira/browse/JENA-1521
 Project: Apache Jena
  Issue Type: Bug
Reporter: Greg Albiston


If a Dataset connected to with TDB2Factory.connectDataset() is opened, closed 
and then later re-opened it is reported that the Dataset is closed.

Opening, closing and re-opening a Dataset with TDBFactory.createDataset() 
causes no issues.

Example code to reproduce:

public void testTDB2OpenClose() {

System.out.println("TDB2 Open Close");
 try {
 Dataset dataset = TDB2Factory.connectDataset("test_tdb2");
 dataset.begin(ReadWrite.WRITE);
 Model defaultModel = dataset.getDefaultModel();
 
defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;), 
ResourceFactory.createProperty("http://example.org/my#PropA;), 
ResourceFactory.createResource("http://example.org/my#ObjA;));
 dataset.commit();
 dataset.end();
 dataset.close();

Dataset dataset2 = TDB2Factory.connectDataset("test_tdb2");
 dataset2.begin(ReadWrite.READ);
 Model readModel = dataset2.getDefaultModel();
 Iterator statements = readModel.listStatements();
 while (statements.hasNext()) {
 Statement statement = statements.next();
 System.out.println(statement);
 }
 dataset2.end();
 dataset2.close();
 } catch (Exception ex) {
 System.out.println("Exception: " + ex.getMessage());
 }
 }


 public void testTDB1OpenClose() {

System.out.println("TDB1 Open Close");
 try {
 Dataset dataset = TDBFactory.createDataset("test_tdb1");
 dataset.begin(ReadWrite.WRITE);
 Model defaultModel = dataset.getDefaultModel();
 
defaultModel.add(ResourceFactory.createResource("http://example.org/my#SubjA;), 
ResourceFactory.createProperty("http://example.org/my#PropA;), 
ResourceFactory.createResource("http://example.org/my#ObjA;));
 dataset.commit();
 dataset.end();
 dataset.close();

Dataset dataset2 = TDBFactory.createDataset("test_tdb1");
 dataset2.begin(ReadWrite.READ);
 Model readModel = dataset2.getDefaultModel();
 Iterator statements = readModel.listStatements();
 while (statements.hasNext()) {
 Statement statement = statements.next();
 System.out.println(statement);
 }
 dataset2.end();
 dataset2.close();
 } catch (Exception ex) {
 System.out.println("Exception: " + ex.getMessage());
 }
 }

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query

[Greg Albiston (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16242215#comment-16242215
 ] 

Greg Albiston edited comment on JENA-1402 at 11/7/17 3:51 PM:
--

The _java.time_ API is supposed to be ISO-8601 compliant as are _xsd:duration_, 
_xsd:time_ and _xsd:dateTime_.

I've used _java.time.Duration_ and _java.time.LocalTime_ in a project and 
parsed into Jena XSD Typed Literals. I haven't found any problems with 
_java.time.Duration_.

The only issue I've found with _java.time.LocalTime_ is that 
_LocalTime.toString()_ drops zero seconds (i.e. "09:00:00" becomes "09:00"), 
when Jena expects them to be preserved. I don't know which is the correct 
behaviour for ISO-8601 but the latter seems to be a _xsd:time_ requirement 
(based on 3rd bullet point in [W3C XML Schema Definition Language (XSD) 1.1 
Part 2: 
Datatypes|https://www.w3.org/TR/xmlschema11-2/#partial-implementation]). 

It can be worked around with a _java.time.format.DateTimeFormatter_ to enforce 
the format.

{code:java}
public static final DateTimeFormatter TIME_FORMATTER = 
DateTimeFormatter.ofPattern("HH:mm:ss[:SSS]");

public static final Literal createLocalTime(LocalTime localTime) {
return 
ResourceFactory.createTypedLiteral(localTime.format(TIME_FORMATTER), 
XSDBaseNumericType.XSDtime);
}
{code}

Usage of the _java.time.Duration_ would suggest replacing 
_javax.xml.datatype.XMLGregorianCalendar_ and _java.util.Calendar_ in Jena. An 
issue here is that _ java.time_ distinguishes between dateTime and time with 
timezone (_java.time.OffsetDateTime_ and _java.time.OffsetTime_) from those 
without timezones (_java.time.LocalDateTime_ and _java.time.LocalTime_). XSD 
does not distinguish and so "09:00:00" and "09:00:00+00:00" are both valid 
_xsd:time_ literals that throw exceptions if parsed through the wrong 
_java.time_ object.

Thanks,

Greg




was (Author: gregalbiston):
The _java.time_ API is supposed to be ISO-8601 compliant as are _xsd:duration_, 
_xsd:time_ and _xsd:dateTime_.

I've used _java.time.Duration_ and _java.time.LocalTime_ in a project and 
parsed into Jena XSD Typed Literals. I haven't found any problems with 
_java.time.Duration_.

The only issue I've found with _java.time.LocalTime_ is that 
_LocalTime.toString()_ drops zero seconds (i.e. "09:00:00" becomes "09:00"), 
when Jena expects them to be preserved. I don't know which is the correct 
behaviour for ISO-8601 but the latter seems to be a _xsd:time_ requirement 
(based on 3rd bullet point in [W3C XML Schema Definition Language (XSD) 1.1 
Part 2: 
Datatypes|https://www.w3.org/TR/xmlschema11-2/#partial-implementation]). 

It can be worked around with a _java.time.format.DateTimeFormatter_ to enforce 
the format.

{code:java}
public static final DateTimeFormatter TIME_FORMATTER = 
DateTimeFormatter.ofPattern("HH:mm:ss[:SSS]");

public static final Literal createLocalTime(LocalTime localTime) {
return 
ResourceFactory.createTypedLiteral(localTime.format(TIME_FORMATTER), 
XSDBaseNumericType.XSDtime);
}
{code}

Usage of the _java.time.Duration_ would suggest replacing 
_javax.xml.datatype.XMLGregorianCalendar_ and _java.util.Calendar_ in Jena. An 
issue here is that_ java.time_ distinguishes between dateTime and time with 
timezone (_java.time.OffsetDateTime_ and _java.time.OffsetTime_) from those 
without timezones (_java.time.LocalDateTime_ and _java.time.LocalTime_). XSD 
does not distinguish and so "09:00:00" and "09:00:00+00:00" are both valid 
_xsd:time_ literals that throw exceptions if parsed through the wrong 
_java.time_ object.

Thanks,

Greg



> Subtracting two xsd:Duration gives incorrect results in SPARQL query
> 
>
> Key: JENA-1402
> URL: https://issues.apache.org/jira/browse/JENA-1402
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.4.0
>Reporter: Greg Albiston
>
> There is an issue when subtracting two xsd:durations that include:
> * decimal seconds
> * non-zero minutes
> * second operand has a greater number of seconds than the first operand, i.e. 
> the minutes are reduced. 
> The result is a large number of minutes and incorrect seconds.
> For example:
> Integer, Larger: "PT2M3S" - "PT1M10S"  = "PT0M53S" CORRECT
> Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
> Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S"  = "-PT1M7.000S" 
> CORRECT
> Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S"  = "PT883M0.020S" 
> INCORRECT
> Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S" 
> INCORRECT
> Example SPARQL:
> {code:sparql}
> SELECT ?res ?op1 ?op2
> WHERE{
>VALUES (?op1 ?op2) {
> ("PT2M3S"^^ 
> 

[jira] [Comment Edited] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query

[Greg Albiston (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16242215#comment-16242215
 ] 

Greg Albiston edited comment on JENA-1402 at 11/7/17 3:51 PM:
--

The _java.time_ API is supposed to be ISO-8601 compliant as are _xsd:duration_, 
_xsd:time_ and _xsd:dateTime_.

I've used _java.time.Duration_ and _java.time.LocalTime_ in a project and 
parsed into Jena XSD Typed Literals. I haven't found any problems with 
_java.time.Duration_.

The only issue I've found with _java.time.LocalTime_ is that 
_LocalTime.toString()_ drops zero seconds (i.e. "09:00:00" becomes "09:00"), 
when Jena expects them to be preserved. I don't know which is the correct 
behaviour for ISO-8601 but the latter seems to be a _xsd:time_ requirement 
(based on 3rd bullet point in [W3C XML Schema Definition Language (XSD) 1.1 
Part 2: 
Datatypes|https://www.w3.org/TR/xmlschema11-2/#partial-implementation]). 

It can be worked around with a _java.time.format.DateTimeFormatter_ to enforce 
the format.

{code:java}
public static final DateTimeFormatter TIME_FORMATTER = 
DateTimeFormatter.ofPattern("HH:mm:ss[:SSS]");

public static final Literal createLocalTime(LocalTime localTime) {
return 
ResourceFactory.createTypedLiteral(localTime.format(TIME_FORMATTER), 
XSDBaseNumericType.XSDtime);
}
{code}

Usage of the _java.time.Duration_ would suggest replacing 
_javax.xml.datatype.XMLGregorianCalendar_ and _java.util.Calendar_ in Jena. An 
issue here is that _java.time_ distinguishes between dateTime and time with 
timezone (_java.time.OffsetDateTime_ and _java.time.OffsetTime_) from those 
without timezones (_java.time.LocalDateTime_ and _java.time.LocalTime_). XSD 
does not distinguish and so "09:00:00" and "09:00:00+00:00" are both valid 
_xsd:time_ literals that throw exceptions if parsed through the wrong 
_java.time_ object.

Thanks,

Greg




was (Author: gregalbiston):
The _java.time_ API is supposed to be ISO-8601 compliant as are _xsd:duration_, 
_xsd:time_ and _xsd:dateTime_.

I've used _java.time.Duration_ and _java.time.LocalTime_ in a project and 
parsed into Jena XSD Typed Literals. I haven't found any problems with 
_java.time.Duration_.

The only issue I've found with _java.time.LocalTime_ is that 
_LocalTime.toString()_ drops zero seconds (i.e. "09:00:00" becomes "09:00"), 
when Jena expects them to be preserved. I don't know which is the correct 
behaviour for ISO-8601 but the latter seems to be a _xsd:time_ requirement 
(based on 3rd bullet point in [W3C XML Schema Definition Language (XSD) 1.1 
Part 2: 
Datatypes|https://www.w3.org/TR/xmlschema11-2/#partial-implementation]). 

It can be worked around with a _java.time.format.DateTimeFormatter_ to enforce 
the format.

{code:java}
public static final DateTimeFormatter TIME_FORMATTER = 
DateTimeFormatter.ofPattern("HH:mm:ss[:SSS]");

public static final Literal createLocalTime(LocalTime localTime) {
return 
ResourceFactory.createTypedLiteral(localTime.format(TIME_FORMATTER), 
XSDBaseNumericType.XSDtime);
}
{code}

Usage of the _java.time.Duration_ would suggest replacing 
_javax.xml.datatype.XMLGregorianCalendar_ and _java.util.Calendar_ in Jena. An 
issue here is that _ java.time_ distinguishes between dateTime and time with 
timezone (_java.time.OffsetDateTime_ and _java.time.OffsetTime_) from those 
without timezones (_java.time.LocalDateTime_ and _java.time.LocalTime_). XSD 
does not distinguish and so "09:00:00" and "09:00:00+00:00" are both valid 
_xsd:time_ literals that throw exceptions if parsed through the wrong 
_java.time_ object.

Thanks,

Greg



> Subtracting two xsd:Duration gives incorrect results in SPARQL query
> 
>
> Key: JENA-1402
> URL: https://issues.apache.org/jira/browse/JENA-1402
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.4.0
>Reporter: Greg Albiston
>
> There is an issue when subtracting two xsd:durations that include:
> * decimal seconds
> * non-zero minutes
> * second operand has a greater number of seconds than the first operand, i.e. 
> the minutes are reduced. 
> The result is a large number of minutes and incorrect seconds.
> For example:
> Integer, Larger: "PT2M3S" - "PT1M10S"  = "PT0M53S" CORRECT
> Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
> Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S"  = "-PT1M7.000S" 
> CORRECT
> Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S"  = "PT883M0.020S" 
> INCORRECT
> Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S" 
> INCORRECT
> Example SPARQL:
> {code:sparql}
> SELECT ?res ?op1 ?op2
> WHERE{
>VALUES (?op1 ?op2) {
> ("PT2M3S"^^ 
> 

[jira] [Comment Edited] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query

[Greg Albiston (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16242215#comment-16242215
 ] 

Greg Albiston edited comment on JENA-1402 at 11/7/17 3:49 PM:
--

The _java.time_ API is supposed to be ISO-8601 compliant as are _xsd:duration_, 
_xsd:time_ and _xsd:dateTime_.

I've used _java.time.Duration_ and _java.time.LocalTime_ in a project and 
parsed into Jena XSD Typed Literals. I haven't found any problems with 
_java.time.Duration_.

The only issue I've found with _java.time.LocalTime_ is that 
_LocalTime.toString()_ drops zero seconds (i.e. "09:00:00" becomes "09:00"), 
when Jena expects them to be preserved. I don't know which is the correct 
behaviour for ISO-8601 but the latter seems to be a _xsd:time_ requirement 
(based on 3rd bullet point in [W3C XML Schema Definition Language (XSD) 1.1 
Part 2: 
Datatypes|https://www.w3.org/TR/xmlschema11-2/#partial-implementation]). 

It can be worked around with a _java.time.format.DateTimeFormatter_ to enforce 
the format.

{code:java}
public static final DateTimeFormatter TIME_FORMATTER = 
DateTimeFormatter.ofPattern("HH:mm:ss[:SSS]");

public static final Literal createLocalTime(LocalTime localTime) {
return 
ResourceFactory.createTypedLiteral(localTime.format(TIME_FORMATTER), 
XSDBaseNumericType.XSDtime);
}
{code}

Usage of the _java.time.Duration_ would suggest replacing 
_javax.xml.datatype.XMLGregorianCalendar_ and _java.util.Calendar_ in Jena. An 
issue here is that_ java.time_ distinguishes between dateTime and time with 
timezone (_java.time.OffsetDateTime_ and _java.time.OffsetTime_) from those 
without timezones (_java.time.LocalDateTime_ and _java.time.LocalTime_). XSD 
does not distinguish and so "09:00:00" and "09:00:00+00:00" are both valid 
_xsd:time_ literals that throw exceptions if parsed through the wrong 
_java.time_ object.

Thanks,

Greg




was (Author: gregalbiston):
The {noformat}java.time{noformat} API is supposed to be ISO-8601 compliant as 
are {noformat}xsd:duration{noformat}, {noformat}xsd:time{noformat} and 
{noformat}xsd:dateTime{noformat}.

I've used {noformat}java.time.Duration{noformat} and 
{noformat}java.time.LocalTime{noformat} in a project and parsed into Jena XSD 
Typed Literals. I haven't found any problems with 
{noformat}java.time.Duration{noformat}.

The only issue I've found with {noformat}java.time.LocalTime{noformat} is that 
{noformat}LocalTime.toString(){noformat} drops zero seconds (i.e. "09:00:00" 
becomes "09:00"), when Jena expects them to be preserved. I don't know which is 
the correct behaviour for ISO-8601 but the latter seems to be a 
{noformat}xsd:time{noformat} requirement (based on 3rd bullet point in 
[https://www.w3.org/TR/xmlschema11-2/#partial-implementation]). 

It can be worked around with a 
{noformat}java.time.format.DateTimeFormatter{noformat} to enforce the format.

{code:java}
public static final DateTimeFormatter TIME_FORMATTER = 
DateTimeFormatter.ofPattern("HH:mm:ss[:SSS]");

public static final Literal createLocalTime(LocalTime localTime) {
return 
ResourceFactory.createTypedLiteral(localTime.format(TIME_FORMATTER), 
XSDBaseNumericType.XSDtime);
}
{code}

Usage of the {noformat}java.time.Duration{noformat} would suggest replacing 
{noformat}javax.xml.datatype.XMLGregorianCalendar{noformat} and 
{noformat}java.util.Calendar{noformat} in Jena. An issue here is that 
{noformat}java.time{noformat} distinguishes between dateTime and time with 
timezone ({noformat}java.time.OffsetDateTime{noformat} and 
{noformat}java.time.OffsetTime{noformat}) from those without timezones 
({noformat}java.time.LocalDateTime{noformat} and 
{noformat}java.time.LocalTime{noformat}). XSD does not distinguish and so 
"09:00:00" and "09:00:00+00:00" are both valid {noformat}xsd:time{noformat} 
literals that throw exceptions if parsed through the wrong 
{noformat}java.time{noformat} object.

Thanks,

Greg



> Subtracting two xsd:Duration gives incorrect results in SPARQL query
> 
>
> Key: JENA-1402
> URL: https://issues.apache.org/jira/browse/JENA-1402
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.4.0
>Reporter: Greg Albiston
>
> There is an issue when subtracting two xsd:durations that include:
> * decimal seconds
> * non-zero minutes
> * second operand has a greater number of seconds than the first operand, i.e. 
> the minutes are reduced. 
> The result is a large number of minutes and incorrect seconds.
> For example:
> Integer, Larger: "PT2M3S" - "PT1M10S"  = "PT0M53S" CORRECT
> Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
> Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S"  = "-PT1M7.000S" 
> CORRECT
> Decimal, Larger, Minutes: 

[jira] [Commented] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query

[Greg Albiston (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16241720#comment-16241720
 ] 

Greg Albiston commented on JENA-1402:
-

The bug in javax.xml.datatype.Duration has been reported to Oracle as Bug ID: 
JDK-8190835 [http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8190835].

It has been assigned a priority of P4, so is apparently an optional fix for the 
next release.

Thanks,

Greg

> Subtracting two xsd:Duration gives incorrect results in SPARQL query
> 
>
> Key: JENA-1402
> URL: https://issues.apache.org/jira/browse/JENA-1402
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.4.0
>Reporter: Greg Albiston
>
> There is an issue when subtracting two xsd:durations that include:
> * decimal seconds
> * non-zero minutes
> * second operand has a greater number of seconds than the first operand, i.e. 
> the minutes are reduced. 
> The result is a large number of minutes and incorrect seconds.
> For example:
> Integer, Larger: "PT2M3S" - "PT1M10S"  = "PT0M53S" CORRECT
> Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
> Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S"  = "-PT1M7.000S" 
> CORRECT
> Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S"  = "PT883M0.020S" 
> INCORRECT
> Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S" 
> INCORRECT
> Example SPARQL:
> {code:sparql}
> SELECT ?res ?op1 ?op2
> WHERE{
>VALUES (?op1 ?op2) {
> ("PT2M3S"^^ 
> "PT1M10S"^^)
> ("PT2M3.123S"^^ 
> "PT1M1.123S"^^)
> ("PT0M3.123S"^^ 
> "PT1M10.123S"^^)
> ("PT2M3.123S"^^ 
> "PT1M10.123S"^^)
> ("PT1H4M3.123S"^^ 
> "PT0M10.123S"^^)
> }
> BIND(?op1 - ?op2 AS ?res)
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query

[Greg Albiston (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16211520#comment-16211520
 ] 

Greg Albiston commented on JENA-1402:
-

Hi Andy,

It does look like a bug in javax.xml.datatype.Duration.

Can Jena be switched over to the new JDK8 Time API?

This gives correct results for the two incorrect examples given previously.
The new Java Time should overcome issues in the old API and is compliant with 
ISO-8601 used by the XSD dateTime, time and duration datatypes.
[http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html#close]

Thanks,

Greg

{code:java}
import java.time.Duration;
import javax.xml.datatype.DatatypeConfigurationException;
import javax.xml.datatype.DatatypeFactory;

public class ExampleApp {

public static void main(String[] args) {

//Jena result: PT883M0.020S
//Java result: PT53S
Duration dur1 = Duration.parse("PT2M3.123S");
Duration dur2 = Duration.parse("PT1M10.123S");
Duration result = dur1.minus(dur2);
System.out.println(dur1 + " - " + dur2 + " = " + result);

//Jena result: PT1H3883M0.020S
//Java result: PT1H3M53S
dur1 = Duration.parse("PT1H4M3.123S");
dur2 = Duration.parse("PT0M10.123S");
result = dur1.minus(dur2);   //gives "PT53S" - correct
System.out.println(dur1 + " - " + dur2 + " = " + result);

//Jena result: PT883M0.020S
//Java result: PT883M0.020S
DatatypeFactory factory = DatatypeFactory.newInstance();
javax.xml.datatype.Duration dt1 = factory.newDuration("PT2M3.123S");
javax.xml.datatype.Duration dt2 = factory.newDuration("PT1M10.123S");

javax.xml.datatype.Duration res1 = dt1.subtract(dt2);
System.out.println(dt1 + " - " + dt2 + " = " + res1);
}
}
{code}


> Subtracting two xsd:Duration gives incorrect results in SPARQL query
> 
>
> Key: JENA-1402
> URL: https://issues.apache.org/jira/browse/JENA-1402
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.4.0
>Reporter: Greg Albiston
>
> There is an issue when subtracting two xsd:durations that include:
> * decimal seconds
> * non-zero minutes
> * second operand has a greater number of seconds than the first operand, i.e. 
> the minutes are reduced. 
> The result is a large number of minutes and incorrect seconds.
> For example:
> Integer, Larger: "PT2M3S" - "PT1M10S"  = "PT0M53S" CORRECT
> Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
> Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S"  = "-PT1M7.000S" 
> CORRECT
> Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S"  = "PT883M0.020S" 
> INCORRECT
> Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S" 
> INCORRECT
> Example SPARQL:
> {code:sparql}
> SELECT ?res ?op1 ?op2
> WHERE{
>VALUES (?op1 ?op2) {
> ("PT2M3S"^^ 
> "PT1M10S"^^)
> ("PT2M3.123S"^^ 
> "PT1M1.123S"^^)
> ("PT0M3.123S"^^ 
> "PT1M10.123S"^^)
> ("PT2M3.123S"^^ 
> "PT1M10.123S"^^)
> ("PT1H4M3.123S"^^ 
> "PT0M10.123S"^^)
> }
> BIND(?op1 - ?op2 AS ?res)
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query

[Greg Albiston (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Albiston updated JENA-1402:

Description: 
There is an issue when subtracting two xsd:durations that include:
* decimal seconds
* non-zero minutes
* second operand has a greater number of seconds than the first operand, i.e. 
the minutes are reduced. 

The result is a large number of minutes and incorrect seconds.

For example:
Integer, Larger: "PT2M3S" - "PT1M10S"  = "PT0M53S" CORRECT
Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S"  = "-PT1M7.000S" CORRECT
Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S"  = "PT883M0.020S" 
INCORRECT
Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S" 
INCORRECT

Example SPARQL:

{code:sparql}

SELECT ?res ?op1 ?op2
WHERE{

   VALUES (?op1 ?op2) {
("PT2M3S"^^ 
"PT1M10S"^^)
("PT2M3.123S"^^ 
"PT1M1.123S"^^)
("PT0M3.123S"^^ 
"PT1M10.123S"^^)
("PT2M3.123S"^^ 
"PT1M10.123S"^^)
("PT1H4M3.123S"^^ 
"PT0M10.123S"^^)
}

BIND(?op1 - ?op2 AS ?res)

}

{code}


  was:
There is an issue when subtracting two xsd:durations that include:
* decimal seconds
* non-zero minutes
* second operand has a greater number of seconds than the first operand, i.e. 
the minutes are reduced. 

The result is a large number of minutes and incorrect seconds.

For example:
Integer, Larger: "PT2M3S" - "PT1M10S"  = "PT0M53S" CORRECT
Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S"  = "-PT1M7.000S" CORRECT
Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S"  = "PT883M0.020S" 
INCORRECT
Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S" 
INCORRECT

Example SPARQL:

SELECT ?res ?op1 ?op2
WHERE{

   VALUES (?op1 ?op2) {
("PT2M3S"^^ 
"PT1M10S"^^)
("PT2M3.123S"^^ 
"PT1M1.123S"^^)
("PT0M3.123S"^^ 
"PT1M10.123S"^^)
("PT2M3.123S"^^ 
"PT1M10.123S"^^)
("PT1H4M3.123S"^^ 
"PT0M10.123S"^^)
}

BIND(?op1 - ?op2 AS ?res)

}



> Subtracting two xsd:Duration gives incorrect results in SPARQL query
> 
>
> Key: JENA-1402
> URL: https://issues.apache.org/jira/browse/JENA-1402
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.4.0
>Reporter: Greg Albiston
>
> There is an issue when subtracting two xsd:durations that include:
> * decimal seconds
> * non-zero minutes
> * second operand has a greater number of seconds than the first operand, i.e. 
> the minutes are reduced. 
> The result is a large number of minutes and incorrect seconds.
> For example:
> Integer, Larger: "PT2M3S" - "PT1M10S"  = "PT0M53S" CORRECT
> Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
> Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S"  = "-PT1M7.000S" 
> CORRECT
> Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S"  = "PT883M0.020S" 
> INCORRECT
> Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S" 
> INCORRECT
> Example SPARQL:
> {code:sparql}
> SELECT ?res ?op1 ?op2
> WHERE{
>VALUES (?op1 ?op2) {
> ("PT2M3S"^^ 
> "PT1M10S"^^)
> ("PT2M3.123S"^^ 
> "PT1M1.123S"^^)
> ("PT0M3.123S"^^ 
> "PT1M10.123S"^^)
> ("PT2M3.123S"^^ 
> "PT1M10.123S"^^)
> ("PT1H4M3.123S"^^ 
> "PT0M10.123S"^^)
> }
> BIND(?op1 - ?op2 AS ?res)
> }
> {code}



--
This message was sent 

[jira] [Created] (JENA-1402) Subtracting two xsd:Duration gives incorrect results in SPARQL query

[Greg Albiston (JIRA)]

Greg Albiston created JENA-1402:
---

 Summary: Subtracting two xsd:Duration gives incorrect results in 
SPARQL query
 Key: JENA-1402
 URL: https://issues.apache.org/jira/browse/JENA-1402
 Project: Apache Jena
  Issue Type: Bug
  Components: ARQ
Affects Versions: Jena 3.4.0
Reporter: Greg Albiston


There is an issue when subtracting two xsd:durations that include:
* decimal seconds
* non-zero minutes
* second operand has a greater number of seconds than the first operand, i.e. 
the minutes are reduced. 

The result is a large number of minutes and incorrect seconds.

For example:
Integer, Larger: "PT2M3S" - "PT1M10S"  = "PT0M53S" CORRECT
Decimal, Smaller: "PT2M3.123S" - "PT1M1.123S" = "PT1M2.000S" CORRECT
Decimal, Larger, Seconds: "PT0M3.123S" - "PT1M10.123S"  = "-PT1M7.000S" CORRECT
Decimal, Larger, Minutes: "PT2M3.123S" - "PT1M10.123S"  = "PT883M0.020S" 
INCORRECT
Decimal, Larger, Hours: "PT1H4M3.123S" - "PT0M10.123S" = "PT1H3883M0.020S" 
INCORRECT

Example SPARQL:

SELECT ?res ?op1 ?op2
WHERE{

   VALUES (?op1 ?op2) {
("PT2M3S"^^ 
"PT1M10S"^^)
("PT2M3.123S"^^ 
"PT1M1.123S"^^)
("PT0M3.123S"^^ 
"PT1M10.123S"^^)
("PT2M3.123S"^^ 
"PT1M10.123S"^^)
("PT1H4M3.123S"^^ 
"PT0M10.123S"^^)
}

BIND(?op1 - ?op2 AS ?res)

}




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JENA-1339) Property Function signature for List subjects and List objects.

[Greg Albiston (JIRA)]

Greg Albiston created JENA-1339:
---

 Summary: Property Function signature for List subjects and List 
objects.
 Key: JENA-1339
 URL: https://issues.apache.org/jira/browse/JENA-1339
 Project: Apache Jena
  Issue Type: Improvement
  Components: ARQ
Affects Versions: Jena 3.3.0
Reporter: Greg Albiston
Priority: Minor
 Fix For: Jena 3.4.0
 Attachments: PFuncListAndList.patch

An abstract Property Function signature is already defined for single subject 
and multiple objects but there is no signature for multiple subject and 
multiple objects. 

SPIN permits defining property functions (magic properties) with this n:n 
signature.

The patch is a single class PFuncListAndList with formatting based upon the 
existing PFuncSimpleAndList class.

Documentation will need updating at: 
https://jena.apache.org/documentation/query/writing_propfuncs.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (JENA-1339) Property Function signature for List subjects and List objects.

[Greg Albiston (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Albiston updated JENA-1339:

Attachment: PFuncListAndList.patch

> Property Function signature for List subjects and List objects.
> ---
>
> Key: JENA-1339
> URL: https://issues.apache.org/jira/browse/JENA-1339
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: ARQ
>Affects Versions: Jena 3.3.0
>Reporter: Greg Albiston
>Priority: Minor
>  Labels: easyfix, newbie
> Fix For: Jena 3.4.0
>
> Attachments: PFuncListAndList.patch
>
>
> An abstract Property Function signature is already defined for single subject 
> and multiple objects but there is no signature for multiple subject and 
> multiple objects. 
> SPIN permits defining property functions (magic properties) with this n:n 
> signature.
> The patch is a single class PFuncListAndList with formatting based upon the 
> existing PFuncSimpleAndList class.
> Documentation will need updating at: 
> https://jena.apache.org/documentation/query/writing_propfuncs.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)