Re: Apache Jena GeoSPARQL mentioned in ISPRS Int. J. Geo-Inf. 2019, 8(7)
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 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 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)
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 mailto:galbis...@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)
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 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)
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
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