W3C home > Mailing lists > Public > public-sdw-wg@w3.org > March 2016

RE: An agreed spatial ontology

From: <Simon.Cox@csiro.au>
Date: Wed, 16 Mar 2016 22:24:56 +0000
To: <frans.knibbe@geodan.nl>, <public-sdw-wg@w3.org>
Message-ID: <c062fbae84b94dc0a277900c1f648780@exch1-mel.nexus.csiro.au>
Perhaps relevant: the GeoJSON team had a discussion on geometry interpolation a couple of weeks ago.
GeoJSON is self-consciously minimal, strictly flat-earth, so lines joining points are *not* geodesics.
Doesn’t matter much over small distances, but obviously matters a lot over large.
Consequence is that if a long geodesic is needed, then this must be constructed as a sequence of line-segments.

A suggestion was made overnight, by someone who has not been active on the list, to add ‘GeodesicLine’ and ‘GeodesicPolygon’ to the gamut of GeoJSON geometries.
This was politely but firmly rejected, partly for process reasons, but also for backward compatibility and ‘simplicity’ reasons.
But it was suggested to invent GeodesicJSON™ - as an incompatible alternative to GeoJSON.


From: Frans Knibbe [mailto:frans.knibbe@geodan.nl]
Sent: Thursday, 17 March 2016 1:09 AM
To: SDW WG Public List <public-sdw-wg@w3.org>
Subject: An agreed spatial ontology


I meant to send this message earlier, but a bout of illness got the better of me...

At the F2F meeting in Amersfoort we talked about the spatial ontology that should be included in the Spatial Data on the Web Best Practices according to our charter<https://www.w3.org/2015/spatial/charter>. It says that the deliverable will include “an agreed spatial ontology conformant to the ISO 19107 abstract model and based on existing available ontologies such as GeoSPARQL, NeoGeo and the ISA Core Location vocabulary”.

We talked about the possibility of really trying to make that happen. The discussion did not reach a clear conclusion and it was decided to park the subject. With this message I hope we can revisit the subject because I think it is very important and therefore should not be parked too long.

I think a good spatial ontology could help in many different areas, such as:

  *   Providing a bridge, or common ground between geographical and non-geographical spatial data.
  *   Provide a foundation for harmonization of the many different geometry encodings that exist today.
  *   Provide basic semantics for the concept of a reference system for spatial coordinates.
  *   Provide a link between W3C standards and OGC standards.
  *   Definition of a basic datatype, or basic datatypes for geometry.
  *   Agree on how geometry and real world objects are related and how different versions of geometries for a single real world object can be distinguished. For example, it makes sense to publish different geometric representations of a spatial object that can be used for different purposes. The same object could be modelled as a point, a 2D polygon or a 3D polygon. The polygons could have different versions with different resolutions (generalisation levels). And all those different geometries could be published with different coordinate reference systems. Regardless of geometry encoding, we need agreement on how to relate different geometries with different characteristics to an object/resource.
I think a basic shared model of geometry on the Web could help solve a multitude of current and future problems. Sure, it will be quite a task, but it could very well be worth the effort. Of course we can decide not to do it, for any set of reasons, but I do think we owe it to the world we try to serve to at least give it some serious consideration. Also we could consider taking just a few steps in the right direction, without any promises that we will come up with the perfect universal ontology. An option could also be to look specifically at GeoSPARQL, as an ontology that already is a merger of OGC and W3C standards, see to what extent it addresses our requirements, and what could be done to make it the single basic universal spatial ontology that would be so great to have.


Received on Wednesday, 16 March 2016 22:25:38 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:20 UTC