RE: Don't you use GeoSPARQL? [ was: Do you use GeoSPARQL?]

Indeed. GeoSPARQL is not designed to replace GIS functions. It is designed to

  1.  Carry complete descriptions of geometries, primarily by ‘passing through’ microformats (WKT, GML, GeoJSON coming soon)
  2.  Provide a useful subset of topology relations so that the relationships between geometries can be expressed directly
  3.  Specify basic functions that follow from those topologies, to be implemented by APIs.
The functionality that Peb describes goes significantly beyond the scope of GeoSPARQL v1. My hunch is that most of that functionality would remain the province of specialized geospatial software, even specialized applications on top of general geospatial software. However the upcoming revision is certainly a phase in which you might make a case for adding functions, but bear in mind that standards development is a collaborative activity and the results usually reflect the relative willingness of contributors.

Simon Cox


From: Frans Knibbe <fjknibbe@gmail.com>
Sent: Thursday, 20 August, 2020 23:49
To: peb aryan <pebbie@gmail.com>
Cc: Semantic Web <semantic-web@w3.org>
Subject: Re: Don't you use GeoSPARQL? [ was: Do you use GeoSPARQL?]

Hello Peb,

Thanks for your insights!  I think I understand your experiences. One way of looking at publishing and linking raw data on the web is expecting data to be directly usable, without needing to pull the data through offline software. Although that would be great, I don't think it will happen anytime soon. Probably additional specialist software will be always needed by specialists. But we do have to make sure that raw data on the web are as usable as possible for any additional software. So extra care must be given to thoroughness, completeness, interpretability, etc. of (spatial) data on the web. In that respect, I'm sure there is room for improvement in GeoSPARQL.

The subject you raise about accessing sub-geometries is interesting, because the problem could be solved by specifying additional SPARQL functions (like ST_PointN<http://postgis.net/docs/ST_PointN.html> and ST_GeometryN<https://postgis.net/docs/ST_GeometryN.html> in PostGIS), but it could also be solved by allowing complex/nested geometries in the (RDF) graph. So this requirement could play a role in discussion about optimal (or allowed) representations of geometry in the semantic web: is it necessary to pick one geometry 'atom', and if so, what should it be? Anyway, the two PostGIS functions I mentioned are described in the OGC simple features for SQL specification, so adding them to GeoSPARQL is covered by this issue<https://github.com/opengeospatial/geosemantics-dwg/issues/13>.

About transforming geometry coordinates from one coordinate reference system (CRS) to another: I don't see an issue for that yet in the list. Would you care to add one?  And would you agree that the best way to express the CRS of a geometry is to use an IRI in a separate graph node?

Greetings,
Frans


Op di 18 aug. 2020 om 14:27 schreef peb aryan <pebbie@gmail.com<mailto:pebbie@gmail.com>>:
Hi Frans,

Thank you for initiating the discussion.
As a person who has worked on both worlds, I still find GeoSPARQL very limiting from both sides.
The last thing I really used geosparql for was mashing up personal trajectory data and public transport (GTFS).
Other than that, it's far easier to just directly manipulate the spatial data itself with OGR/GDAL.

Some difficulties i encountered are on how to do geometry manipulation when querying, e.g. :
- functions for accessing sub-geometries (e.g. point at index i from a line or a polyline), retrieving one coordinate component from a literal value in WKT, or constructing new geometry component without falling back to error-prone string manipulation
- a way to express transformation of geometry from one CRS to another CRS outside WKT specs(also with the update on how it is expressed with WKT2:2015 and WKT2:2019 allows for custom pipeline and referencing raster data source (i.e. geoid & custom local correction grid)).
- functions involving different spatial data representation beyond qualitative spatial relations: e.g. augmenting 2D data with raster for vertical component and making it 3D point data.
- a way to express the CRS of a geometry in less verbose manner

The above issues are what I can summarize from photogrammetry/remote sensing domain.
It seems that some of the issues (CRS, 3D and Rasters) have already been raised in the github and the standard tracker.

Cheers,

Peb

On Tue, Jul 28, 2020 at 10:13 PM Frans Knibbe <fjknibbe@gmail.com<mailto:fjknibbe@gmail.com>> wrote:
Hi,

GeoSPARQL<https://www.ogc.org/standards/geosparql> 1.0 (released in 2012) is a standard from the OGC<https://www.ogc.org/about>. It offers, among other things, an ontology for geographical features and geometry<http://www.opengis.net/ont/geosparql> and SPARQL functions to work with geospatial data.
As Simon wrote, GeoSPARQL is about to be revised, so now is a perfect time for the semantic web community to have a critical look at the specification. I would say that the upcoming revision work is not only of interest to those who are already using GeoSPARQL, but also to everyone that might some day work with spatial/geometric data on the web, either on the supply or the demand side. So that is probably you, dear reader :-)
The current list of issues for the revision<https://github.com/opengeospatial/geosemantics-dwg/issues> was mainly compiled by people whose job it is to work with (geo)spatial data. I think it will be very beneficial for the revision if people with different backgrounds make their impressions known. Explicit targets for the next version of GeoSPARQL are improving the way GeoSPARQL can be put to use in the Semantic Web and in graph databases, so any input from people working in those areas is highly valued and of great importance.
Here are some questions that could spark a bit of discussion in this list, perhaps resulting in additional official comments or change requests:

  *   Have you ever used GeoSPARQL? If so, any problems?
  *   Have you ever tried to implement (parts of) GeoSPARQL in your software? If yes, did you run into problems?
  *   Have you ever run into problems working with spatial or geometric data? Perhaps on the ontology level, or on the data integration level, or in some other way?
  *   Domains like geography, astronomy, biology, computer graphics, web graphics, building information modelling (BIM) and computer aided design (CAD) all use spatial data. Have you ever tried to somehow combine different types of spatial data or spatial knowledge? If so, how was that experience?
Even if you're not interested in spatial data on the web at all, but do like to fuss about lists in RDF or the sweet spot of atomicity in RDF literals, you're very welcome to weigh in...

Greetings,
Frans

Op di 21 jul. 2020 om 08:19 schreef Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>>:
... revision underway. Submit issues and requests here: https://github.com/opengeospatial/geosemantics-dwg


-----Original Message-----
From: Linda van den Brink <l.vandenbrink@geonovum.nl<mailto:l.vandenbrink@geonovum.nl>>
Sent: Tuesday, 21 July, 2020 01:42
To: public-sdwig <public-sdwig@w3.org<mailto:public-sdwig@w3.org>>
Subject: FYI: OGC requests public comment on GeoSPARQL Standards Working Group recharter

Hi all,

This may be of interest to some of you and may have been missed by non-OGC members...

We have talked a little about work on the GeoSPARQL standard in this group. The work will take place within OGC, where a working group is now being resurrected. This OGC Standards Working Group will provide a major update to a key standard for representing and querying spatial data on the Semantic Web.

The Open Geospatial Consortium (OGC) now seeks public comment on the draft updated charter for the OGC GeoSPARQL Standards Working Group (SWG). The GeoSPARQL SWG will revise, and likely extend, the GeoSPARQL standard. Comments are due by August 6, 2020.

See https://www.ogc.org/standards/requests/210 for more information.

Linda