You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Marco Neumann <ma...@gmail.com> on 2019/12/04 14:00:56 UTC
Apache Jena GeoSPARQL mentioned in ISPRS Int. J. Geo-Inf. 2019, 8(7)
FYI here is a new review / comparison that mentions the new Apache Jena
GeoSPARQL effort in this recent publication:
Assessment and Benchmarking of Spatially Enabled RDF Stores for the Next
Generation of Spatial Data Infrastructure
by Weiming Huang,Syed Amir Raza,Oleg Mirzov and Lars Harrie
ISPRS Int. J. Geo-Inf. 2019, 8(7), 310;
https://doi.org/10.3390/ijgi8070310
Enjoy,
Marco
--
---
Marco Neumann
KONA
Re: Apache Jena GeoSPARQL mentioned in ISPRS Int. J. Geo-Inf. 2019, 8(7)
Posted by Marco Neumann <ma...@gmail.com>.
Thank you Greg,
I will try to make sure to work some of these remarks into the GeoSPARQL
review.
Happy holidays,
Marco
On Sun, Dec 15, 2019 at 9:47 AM Greg <ga...@mail.com> wrote:
> Hi Marco,
>
> Thank you for the invitation but I'm not sure I have the availability for
> the meetings. I've thrown down some notes about various things that cropped
> up while I was working with GeoSPARQL. Some you will already be aware from
> Jena, others are minor snags and some speculative ideas.
>
> Thanks,
>
> Greg
>
> - getSRID replaced by getSRS or getSRS_URI as it is a URI that is returned
> and not an integer as in the Simple Features standard.
> - fixing error in the published XML schema: "defaultGeometry" to
> "hasDefaultGeometry".
> - conformance queries and dataset/s so that both functionality and
> correctness can be demonstrated by implementations in a standard manner
> (this is a major shortfall and some mechanism is needed).
> - performance queries and dataset/s (although this is probably best left
> as an area of wider research).
> - inclusion of GeoJSON as an explicit serialisation property with
> examples, i.e. asGeoJSON, given the widespread usage of JSON data.
> - there are variations between the equals realtions of GeoSPARQL/Simple
> Features standards (TFFFTFFFT) and those in use by some libraries, e.g.
> JTS (T*F**FFF*), to allow equality between Points to be tested.
> - aggregate functions (as included in Strabon), e.g. union and extent
> across N geometries.
> - convenience geometry filter functions (to simplify query syntax), e.g.
> isPoint, isLineString, isPolygon, nearby points up to limit, points within
> bounding box up to limit.
> - geometry manipulation (as found in PostGIS functions), e.g. splitting
> polygon into points or forming linestring from points, forming a linestring
> from set of linestrings, transform datatype/serialisation.
> - geometry functions, e.g. centre point of polygon, bounding box of
> geometry, midpoint of a line, point along line by distance from start/end,
> test relative positions of geometries (e.g. point is to left of line),
> pathfinding? (e.g. A* across set of points).
> - SRS functions, e.g. isProjected, isGeographic, and functions to
> translate between SRS.
> - cardinal direction functions, e.g. north, south, east, west. Would
> require wrap around for geographic SRS.
> - considering support for geographic SRS as WGS84 appears in most
> examples. e.g. great circle distance, angle, azimuth.
> - filter functions for Geometry properties but applied to Geometry
> Literals.
>
>
> On 08/12/2019 17:39, Marco Neumann wrote:
>
> I am still using my old GeoSPARQL implementation with the new Apache Jena
> libs on the GeoSPARQL.org endpoint. I will have to find some time to
> further evaluate and possibly switch over to your new GeoSPARQL module
> early in the new year.
>
> The OGC GeoSPARQL team has invited me to participate in
> the discussion about a new OGC GeoSPARQL 2.0 specification later in the
> month. Will be interesting to see how the use of geospatial features will
> evolve in the RDF ecosystems in 2020. If you are interested to join these
> meetings please let me know.
>
> Best,
> Marco
>
>
> On Sun, Dec 8, 2019 at 1:30 PM Greg Albiston <ga...@mail.com> wrote:
>
>> Thanks for this Marco. Interesting to see it all in action.
>>
>> Apache Jena GeoSPARQL does quite well.
>>
>> I've ran the benchmarking dataset against Jena 3.13.1 for the one query
>> they said didn't give results.
>> It does give results and in a couple of seconds as reported for the other
>> systems so unsure what has happened there.
>>
>> Cheers,
>>
>> Greg
>> On 04/12/2019 14:00, Marco Neumann wrote:
>>
>> FYI here is a new review / comparison that mentions the new Apache Jena
>> GeoSPARQL effort in this recent publication:
>>
>> Assessment and Benchmarking of Spatially Enabled RDF Stores for the Next
>> Generation of Spatial Data Infrastructure
>>
>> by Weiming Huang,Syed Amir Raza,Oleg Mirzov and Lars Harrie
>>
>> ISPRS Int. J. Geo-Inf. 2019, 8(7), 310;
>> https://doi.org/10.3390/ijgi8070310
>>
>>
>> Enjoy,
>> Marco
>>
>> --
>>
>>
>> ---
>> Marco Neumann
>> KONA
>>
>>
>
> --
>
>
> ---
> Marco Neumann
> KONA
>
>
--
---
Marco Neumann
KONA
Re: Apache Jena GeoSPARQL mentioned in ISPRS Int. J. Geo-Inf. 2019,
8(7)
Posted by Greg <ga...@mail.com>.
Hi Marco,
Thank you for the invitation but I'm not sure I have the availability
for the meetings. I've thrown down some notes about various things that
cropped up while I was working with GeoSPARQL. Some you will already be
aware from Jena, others are minor snags and some speculative ideas.
Thanks,
Greg
- getSRID replaced by getSRS or getSRS_URI as it is a URI that is
returned and not an integer as in the Simple Features standard.
- fixing error in the published XML schema: "defaultGeometry" to
"hasDefaultGeometry".
- conformance queries and dataset/s so that both functionality and
correctness can be demonstrated by implementations in a standard manner
(this is a major shortfall and some mechanism is needed).
- performance queries and dataset/s (although this is probably best left
as an area of wider research).
- inclusion of GeoJSON as an explicit serialisation property with
examples, i.e. asGeoJSON, given the widespread usage of JSON data.
- there are variations between the equals realtions of GeoSPARQL/Simple
Features standards (|TFFFTFFFT)| and those in use by some libraries,
e.g. JTS (|T*F**FFF*|), to allow equality between Points to be tested.
- aggregate functions (as included in Strabon), e.g. union and extent
across N geometries.
- convenience geometry filter functions (to simplify query syntax), e.g.
isPoint, isLineString, isPolygon, nearby points up to limit, points
within bounding box up to limit.
- geometry manipulation (as found in PostGIS functions), e.g. splitting
polygon into points or forming linestring from points, forming a
linestring from set of linestrings, transform datatype/serialisation.
- geometry functions, e.g. centre point of polygon, bounding box of
geometry, midpoint of a line, point along line by distance from
start/end, test relative positions of geometries (e.g. point is to left
of line), pathfinding? (e.g. A* across set of points).
- SRS functions, e.g. isProjected, isGeographic, and functions to
translate between SRS.
- cardinal direction functions, e.g. north, south, east, west. Would
require wrap around for geographic SRS.
- considering support for geographic SRS as WGS84 appears in most
examples. e.g. great circle distance, angle, azimuth.
- filter functions for Geometry properties but applied to Geometry Literals.
On 08/12/2019 17:39, Marco Neumann wrote:
> I am still using my old GeoSPARQL implementation with the new Apache
> Jena libs on the GeoSPARQL.org endpoint. I will have to find some time
> to further evaluate and possibly switch over to your new GeoSPARQL
> module early in the new year.
>
> The OGC GeoSPARQL team has invited me to participate in
> the discussion about a new OGC GeoSPARQL 2.0 specification later in
> the month. Will be interesting to see how the use of geospatial
> features will evolve in the RDF ecosystems in 2020. If you are
> interested to join these meetings please let me know.
>
> Best,
> Marco
>
>
> On Sun, Dec 8, 2019 at 1:30 PM Greg Albiston <galbiston@mail.com
> <ma...@mail.com>> wrote:
>
> Thanks for this Marco. Interesting to see it all in action.
>
> Apache Jena GeoSPARQL does quite well.
>
> I've ran the benchmarking dataset against Jena 3.13.1 for the one
> query they said didn't give results.
> It does give results and in a couple of seconds as reported for
> the other systems so unsure what has happened there.
>
> Cheers,
>
> Greg
>
> On 04/12/2019 14:00, Marco Neumann wrote:
>> FYI here is a new review / comparison that mentions the new
>> Apache Jena GeoSPARQL effort in this recent publication:
>>
>> Assessment and Benchmarking of Spatially Enabled RDF Stores for
>> the Next Generation of Spatial Data Infrastructure
>>
>> by Weiming Huang,Syed Amir Raza,Oleg Mirzov and Lars Harrie
>>
>> ISPRS Int. J. Geo-Inf. 2019, 8(7), 310;
>> https://doi.org/10.3390/ijgi8070310
>>
>>
>> Enjoy,
>> Marco
>>
>> --
>>
>>
>> ---
>> Marco Neumann
>> KONA
>>
>
>
> --
>
>
> ---
> Marco Neumann
> KONA
>
Re: Apache Jena GeoSPARQL mentioned in ISPRS Int. J. Geo-Inf. 2019, 8(7)
Posted by Marco Neumann <ma...@gmail.com>.
I am still using my old GeoSPARQL implementation with the new Apache Jena
libs on the GeoSPARQL.org endpoint. I will have to find some time to
further evaluate and possibly switch over to your new GeoSPARQL module
early in the new year.
The OGC GeoSPARQL team has invited me to participate in
the discussion about a new OGC GeoSPARQL 2.0 specification later in the
month. Will be interesting to see how the use of geospatial features will
evolve in the RDF ecosystems in 2020. If you are interested to join these
meetings please let me know.
Best,
Marco
On Sun, Dec 8, 2019 at 1:30 PM Greg Albiston <ga...@mail.com> wrote:
> Thanks for this Marco. Interesting to see it all in action.
>
> Apache Jena GeoSPARQL does quite well.
>
> I've ran the benchmarking dataset against Jena 3.13.1 for the one query
> they said didn't give results.
> It does give results and in a couple of seconds as reported for the other
> systems so unsure what has happened there.
>
> Cheers,
>
> Greg
> On 04/12/2019 14:00, Marco Neumann wrote:
>
> FYI here is a new review / comparison that mentions the new Apache Jena
> GeoSPARQL effort in this recent publication:
>
> Assessment and Benchmarking of Spatially Enabled RDF Stores for the Next
> Generation of Spatial Data Infrastructure
>
> by Weiming Huang,Syed Amir Raza,Oleg Mirzov and Lars Harrie
>
> ISPRS Int. J. Geo-Inf. 2019, 8(7), 310;
> https://doi.org/10.3390/ijgi8070310
>
>
> Enjoy,
> Marco
>
> --
>
>
> ---
> Marco Neumann
> KONA
>
>
--
---
Marco Neumann
KONA
Re: Apache Jena GeoSPARQL mentioned in ISPRS Int. J. Geo-Inf. 2019,
8(7)
Posted by Greg Albiston <ga...@mail.com>.
Thanks for this Marco. Interesting to see it all in action.
Apache Jena GeoSPARQL does quite well.
I've ran the benchmarking dataset against Jena 3.13.1 for the one query
they said didn't give results.
It does give results and in a couple of seconds as reported for the
other systems so unsure what has happened there.
Cheers,
Greg
On 04/12/2019 14:00, Marco Neumann wrote:
> FYI here is a new review / comparison that mentions the new Apache
> Jena GeoSPARQL effort in this recent publication:
>
> Assessment and Benchmarking of Spatially Enabled RDF Stores for the
> Next Generation of Spatial Data Infrastructure
>
> by Weiming Huang,Syed Amir Raza,Oleg Mirzov and Lars Harrie
>
> ISPRS Int. J. Geo-Inf. 2019, 8(7), 310;
> https://doi.org/10.3390/ijgi8070310
>
>
> Enjoy,
> Marco
>
> --
>
>
> ---
> Marco Neumann
> KONA
>