GeoSPARQL Standards Working Group Meeting Minutes

Meeting Details

Meeting Date: 22/09/2021

Meeting Time: 2030 UTC

Meeting Location: GoToMeeting

Attendees

Attendee Moniker
Timo Homburg TH
Joseph Abhayaratna JA
Matthew Perry MP
Frans Knibbe FK
Nicholas Car NC
Paul Cripps PC
Robert Gibb RG

Note Takers

  • JA, MP

Action Items From Last Meetings

| Done? | Item | Responsible | Due Date | | —- | —- | —- | — |

Discussion Items

Time Item Who Notes
2038 Intro JA Call for Patents
  • None known
Roll Call
  • Attendees recorded in minutes
  • Attendees confirmed vocally
2040 Actions for chairs JA
  • PC [#196](https://github.com/opengeospatial/ogc-geosparql/issues/196).
    • We need a home for development of peripheral Shape Constraints, Ontologies, etc., that do not form part of the standard.
    • The popular suggestion is the Geosemantics DWG, and its Github repositories.
    • We have a 30 minute timeslot at the next DWG meeting to discuss it.
    • Meeting is Sep 15, 630-8am EDT, combined with the W3C Spatial Data on the Web Working Group
    • [(**Action 1**)](#action_1)
2044 Run through of Pull Requests NC
  • [#173](https://github.com/opengeospatial/ogc-geosparql/pull/173)
    • NC: REGEX shapes are controversial
    • NC: Leading space can be an issue with current REGEX and probably other issues
    • TH: Definitely need to handle whitespaces. Not sure if these should be in the standard - they certainly don’t validate WKT, GML, etc.
    • NC: Not intended to validate - just a simple check. Checking literals falls out of scope of GeoSPARQL.
    • MP: Also feels that it is out of scope of GeoSPARQL to validate literal contents.
    • TH: checking that e.g., asWKT points to a wktLiteral would be an in-scope rule.
    • NC: matching property with literal type is a valid check.
    • NC: Plan is to add property and literal type check but remove literal content regex checks.
  • [#205](https://github.com/opengeospatial/ogc-geosparql/pull/205)
    • NC: Ready to go except for some spacing issue
    • NC: Bibtex merged
  • [#208](https://github.com/opengeospatial/ogc-geosparql/pull/208)
    • SC: .cff is for citing whole repo
    • NC: Let’s leave the .cff in there and update as needed
    • TH: .cff is now natively supported by GitHub
  • [#136](https://github.com/opengeospatial/ogc-geosparql/pull/136)
    • FK: DGGS object view does not match geometry formal definition.
    • NC: DGGS literals project something on Earth and can act as geometries as far as GeoSPARQL is concerned
    • FK: Do functions work if the input is a mix of DGGS and WKT, for example.
    • NC: Such case can work - we can convert back and forth between non-DGGS and DGGS.
    • TH: Supporting a mix is a requirement for GeoSPARQL 1.1
    • NC: Most geometry conversions are lossy. Many WKT geometries cannot be converted to GeoJSON for example because of CRS incompatibilities.
    • NC: Will take a closer look at Frans’ comments.
2121 What’s left JA, NC
  • [#164](https://github.com/opengeospatial/ogc-geosparql/issues/164) FK: Done
  • [#60](https://github.com/opengeospatial/ogc-geosparql/issues/60) JA: In progress
  • [#149](https://github.com/opengeospatial/ogc-geosparql/issues/149) JA: In progress
  • [#165](https://github.com/opengeospatial/ogc-geosparql/pull/165) Issue removed from 1.1
  • [#63](https://github.com/opengeospatial/ogc-geosparql/issues/63) FK: Done
  • [#120](https://github.com/opengeospatial/ogc-geosparql/issues/120)
    • FK: Only a new module for DGGS
    • NC: Let’s move 120 to done and create another to check modularization
  • [#204](https://github.com/opengeospatial/ogc-geosparql/issues/204)
    • FK: Why such a restrictive definition of hasLength? What about hasPerimeter?
    • General agreement to add hasPerimeter and relax definition of hasLength.
    • FK to take a shot at rewording hasLength definition
  • [#181](https://github.com/opengeospatial/ogc-geosparql/issues/181)
    • TH: Found vocabulary from OGC-NA that can replace the one we came up with.
    • TH: Can be done this week
    • JA: Moving 181 to “to do”
  • [#104](https://github.com/opengeospatial/ogc-geosparql/issues/104)
    • NC: This is a valid issue to resolve
    • JA: Moving 104 to “to do”
  • [#133](https://github.com/opengeospatial/ogc-geosparql/issues/133)
    • NC: I think we have addressed this because we have standardized the references
    • NC to work on 133
  • [#156](https://github.com/opengeospatial/ogc-geosparql/issues/156) JA: removing this from 1.1 projec
  • [#167](https://github.com/opengeospatial/ogc-geosparql/issues/167) NC: has been dealt with, and we can close it.
  • [#199](https://github.com/opengeospatial/ogc-geosparql/issues/199)
    • FK: there are 2 candidates
    • FK: do the OGC versions match the ISO exactly?
    • NC: I can check if they are the same and create a PR if they are
  • [#198](https://github.com/opengeospatial/ogc-geosparql/issues/198)
    • FK: aggregate functions should have a set as input, which should be represented in the function signature.
    • TH: earlier we came to the conclusion that we do not really need to change the signature but do not exactly remember the reasoning
    • JA: will leave it in the backlog
  • [#200](https://github.com/opengeospatial/ogc-geosparql/issues/200) JA: Moving this one to “to do”
  • [#201](https://github.com/opengeospatial/ogc-geosparql/issues/201)
    • All: type of distance should be based on input CRS
    • Agreement that this should be clearer in the spec.
    • FK to make a PR
    • Ontology for CRS is a good topic for GeoSemantics DWG discussion.
  • [#197](https://github.com/opengeospatial/ogc-geosparql/issues/197)
    • FK: Simple Features does not support Circle type
    • TH: bigger issue is that we do not mandate what geometry types are returned from functions.
    • JA: Moving this one to “to do” since bounding circle is new - we don’t want to create an issue.
  • [#209](https://github.com/opengeospatial/ogc-geosparql/issues/209) JA: Moved to “to do”
2200 Any other business? JA  
2200     MEETING ENDS

Action Items

| # | Item | Responsible | Due Date | | —- | —- | —- | —- |