W3C home > Mailing lists > Public > public-sdwig@w3.org > November 2018

Re: A universal model for spatial data

From: Rob Atkinson <rob@metalinkage.com.au>
Date: Thu, 15 Nov 2018 08:50:29 +1100
Message-ID: <CACfF9LwMxC9KBcOL7g6h1bpzsL5CdVcyotTHR-N3R9nD7xeXOA@mail.gmail.com>
To: Frans.Knibbe@kadaster.nl
Cc: Linda van den Brink <l.vandenbrink@geonovum.nl>, public-sdwig@w3.org
If we had a CRS definition Ontology the OGC Definitions server could
(technically) host the RDF version of CRS registries - care would need to
be taken about the governance - we have issues with CRS authority and
liability for any errors.

In general, I think a canonical mechanism to share metadata about accuracy,
provision and authority for such concepts is necessary - wars have been
fought over incompatible lines drawn on maps..

Rob



On Thu, 15 Nov 2018 at 08:35, Knibbe, Frans <Frans.Knibbe@kadaster.nl>
wrote:

> Hello Linda,
>
>
>
> Thanks. I have just added the proposal
> <https://github.com/w3c/sdw/issues/1095>, I hope I did it
> right.
>
>
>
> As for your questions: In the original post I mentioned three things that
> could be in the ontology:
>
> ·        A specification for coordinate reference systems (not just
> geographic),
>
> ·        a specification for numerical definitions of shapes or
> distributions of spatial things,
>
> ·        functions/assertions that are applicable to spatial things
> and/or descriptions of their shapes or distributions.
>
>
>
> But once work gets underway it could be that further thought results in
> something different. I do think the primary motive should be to have a
> domain-independent specification and through that improved interoperability
> of data and systems.
>
> A universal space ontology could be a further elaboration of GeoSPARQL,
> which is now geared towards geography, but could be opened up to
> non-geographic spatial data. For instance by accommodating defining and/or
> referencing coordinate reference systems (geographical or not). Definition
> of classes and properties for CRS would be beneficial for the geography
> domain itself, it seems to me. And within said domain, a further expansion
> of semantics in GeoSPARQL could bridge the gap between vector data and
> raster data. So even within the geography domain an upgrade of GeoSPARQL
> seems worthwhile.
>
> I could come up with some examples (in Turtle format) of how different
> kinds of spatial data could be modelled with a hypothetical spatial
> ontology, but I would need some extra time to do that. I could add those
> examples to the GitHub issue ASAP. Would that be OK?
>
>
>
> Regards,
>
> Frans
>
>
>
>
> *Van:* Linda van den Brink [mailto:l.vandenbrink@geonovum.nl]
> *Verzonden:* vrijdag 9 november 2018 09:42
> *Aan:* Knibbe, Frans <Frans.Knibbe@kadaster.nl>
> *CC:* public-sdwig@w3.org
> *Onderwerp:* RE: A universal model for spatial data
>
>
>
> Hi Frans,
>
>
>
> There may be something in your idea of creating a universal model for
> spatial data, or as we might call it “the Space ontology” (OWL Space).
>
>
>
> Part of this group’s way of working is that we track new ideas for
> standards (that fall within our spatial web scope of course). Could you
> create an item for your idea in our Proposals project?
> https://github.com/w3c/sdw/projects/15 Then we can track it and see if
> there is support for this idea within the group. Since you triggered some
> discussion, that may be the case.
>
>
>
> A question I have is what kinds of things would this ontology contain and
> how would it relate to the GeoSPARQL ontology? Can you give an example with
> data?
>
>
>
> Linda
>
>
>
> *Van:* Knibbe, Frans <Frans.Knibbe@kadaster.nl>
> *Verzonden:* maandag 5 november 2018 09:12
> *Aan:* George Percivall <gpercivall@opengeospatial.org>
> *CC:* public-sdwig@w3.org
> *Onderwerp:* RE: A universal model for spatial data
>
>
>
> Hello George,
>
>
>
> Thank you for those comments, and I am glad you don’t dismiss the idea of
> spatial unification.
>
>
>
> You do mention the uniqueness of geospatial data. Probably all the
> different domains where spatial data are used have their peculiarities. For
> instance, in geographic data (at least if polar coordinates are used) a lot
> of attention is given to describing the shape of the earth. Geometric
> building data rely heavily on using parameters instead of collections of
> coordinates to define shapes of things. 3D graphics focus on materials and
> lighting. But despite different accents, the basic nature of the spatial
> data is the same. I see many cases where different standards, formats and
> data types are used for things that are fundamentally the same. So there
> seems to be room for improvement.
>
>
>
> I think that a general model for spatial data can accommodate domain
> specific peculiarities, especially when it is developed as a web ontology
> (using RDFS/OWL), because it is easy to pick just the things you need from
> a model (a certain branch of the model, and/or a certain abstraction level)
> and it is possible to extend such a model (define specialised classes or
> properties). The ability to drill down to a shared abstraction level should
> also accommodate defining domain-independent data types that can be used
> for storage and exchange of spatial data.
>
>
>
> Building a spatial ontology in such a way that common ground between
> domain applications can be found should be a requirement, but perhaps it is
> not necessary to go to the most fundamental mathematical description of
> space in an ontology for spatial data?
>
>
>
> Regards,
>
> Frans
>
>
>
>
>
> *Van:* George Percivall [mailto:gpercivall@opengeospatial.org
> <gpercivall@opengeospatial.org>]
> *Verzonden:* vrijdag 26 oktober 2018 16:25
> *Aan:* Knibbe, Frans <Frans.Knibbe@kadaster.nl>; Chris Little <
> chris.little@metoffice.gov.uk>
> *CC:* public-sdwig@w3.org
> *Onderwerp:* Re: A universal model for spatial data
>
>
>
> Some comments trigger by earlier comments from Chris and Frans.
>
>
>
> From Chris:
>
> I guess the fundamental accuracy limit for space would be the smallest
> ‘ruler’ or thing, such as an atom or sub atomic particle.
>
>
>
> from Frans:
>
> domain-independent model for space should rely heavily on pure mathematics.
>
>
>
> A domain independent model of space is be provided by Calculus and
> mathematical analysis based on infinitesimal limits.  That approach is very
> powerful but too abstract on its own for our geospatial applications that
> include the physical world.  This is similar to CRS:  CRS include a
> Coordinate Systems and Datum.  CS are mathematical constructions that
> become useful for geospatial when a datum is defined that ties the abstract
> CS to the physical world.
>
>
>
> What smallest "rulers" limits - similar to clocks for time - are relevant
> to physical space?   It maybe that a relevant physical space ruler is
> application dependent.
>
> 1. For imagery a relevant physical lower limit is Ground Sample Distance
> for spatial resolution of the image (see notes below)
>
> 2. For surveying and other positioning technologies, it might be the
> something on the order of the wavelength of the signals used to determine
> distance.
>
> 3. At the limit of spatial resolution in physical processes is the photon
> and its relation to the Planck constant.
>
>
>
> On a related note, an ontology for geospatial space should clarify the
> difference distance and coordinates.  Distance can be measured, e.g. based
> on the time for a round trip signal to be received.  Coordinates are
> assigned based on a distance measurement and a CRS.  Clarifying the
> distinction between distance and coordinates would help correct the
> misnaming of a GPS calculator as a "GPS Sensor.”  The territory is not the
> map.
>
>
>
> Regards,
>
> George
>
>
>
>
>
> ++++++++++++++++++++++++++++++++++++
>
>
>
> Excerpt from ISO 19101-2:2017 Geographic Information - Reference Model -
> Part 2: Imagery
>
>
>
> From section 8.1.4.1 Resolution
>
>
>
> The spatial resolution of an image is the minimum separation between two
> objects that can be distinguished as separate objects in the image. Pixel
> ground resolution defines the area on the ground represented by each pixel.
> This is often expressed as the distance between the centers of the
> areas represented by two adjacent pixels, called Ground Sample Distance
> (GSD) or Ground Sample Interval (GSI).
>
> Related to the spatial resolution is the Instantaneous Geometric Field of
> View (IGFOV). IGFOV is the geometric size of the image projected by the
> detector on the ground through the optical system. IGFOV is also called
> pixel footprint. ISO 19123 defines the related concept of CV_Footprint. A
> CV_Footprint is the sample space of a grid in an external coordinate
> reference system,  e.g. a geographic CRS or a map projection CRS.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Oct 26, 2018, at 6:35 AM, Knibbe, Frans <Frans.Knibbe@kadaster.nl>
> wrote:
>
>
>
> Hello Chris,
>
>
>
> Thank you for your response. Perhaps it would be good to separate subjects
> in my original post. One is that there is a need for a fundamental ontology
> for space, the other is what that ontology should look like. I (shamefully)
> have to admit that I had not read the QB4ST documentation in that light,
> but it is interesting to note that Rob has made accommodations for a future
> space ontology (see https://w3c.github.io/sdw/qb4st/#Spatial and
> https://w3c.github.io/sdw/qb4st/#SpatialConcepts).
>
>
>
> As for the mathematical part: I am not a mathematician myself, but I
> wanted to propose the idea that a truly domain-independent model for space
> should rely heavily on pure mathematics. Perhaps I should have left it at
> that J. Exactly how a space ontology should take shape is then best left
> up to the specialists (geometers).
>
>
>
> Regards,
>
> Frans
>
>
>
>
>
> *Van:* Little, Chris [mailto:chris.little@metoffice.gov.uk
> <chris.little@metoffice.gov.uk>]
> *Verzon**den:* vrijdag 26 oktober 2018 12:09
> *Aan:* Knibbe, Frans <Frans.Knibbe@kadaster.nl>; public-sdwig@w3.org
> *CC:* Folmer, Erwin <Erwin.Folmer@kadaster.nl>; Stoter, Jantien <
> Jantien.Stoter@kadaster.nl>
> *Onderwerp:* RE: A universal model for spatial data
>
>
>
> Hi Frans,
>
>
>
> I am supportive of your idea, though not sure whether it is feasible.
>
>
>
> One or two assumptions that are made in maths are:
>
> 1.      Space dimensions do have a metric
>
> 2.      Euclidean space is assumed to have a locality property (every
> point can have a small area/volume drawn around it and ‘shrunk’ to the
> point.
>
> 3.      Space in each and all dimensions is assumed to be continuous, and
> between any two points there is an infinite number of other points
>
>
>
> The underlying idea of the OWL-Time ontology is the ‘clock’ which ticks
> (any physically repeating event that can be counted). There is no accuracy
> finer than that clock, unless one can find another. E.g. replace the
> Caesium atomic clocks of BIPM TAI with an ytterbium clock.
>
>
>
> I guess the fundamental accuracy limit for space would be the smallest
> ‘ruler’ or thing, such as an atom or sub atomic particle.
>
>
>
> I suggest that the starting point is not the above but Rob Atkinson’s
> QB4ST ontology.
>
>
>
> HTH, Chris
>
>
>
> *From:* Knibbe, Frans <Frans.Knibbe@kadaster.nl>
> *Sent:* 24 October 2018 09:11
> *To:* public-sdwig@w3.org
> *Cc:* Folmer, Erwin <Erwin.Folmer@kadaster.nl>; Stoter, Jantien <
> Jantien.Stoter@kadaster.nl>
> *Subject:* A universal model for spatial data
>
>
>
> Hello all,
>
>
>
> Warning: long text ahead. In short, I try to argue that it would be a good
> idea to have a domain-independent web ontology for spatial data.
>
>
>
> *Introduction*
>
> After having to cut back my participation in the Spatial Data on the Web
> Working Group (SDWWG) I have been (partially) working for the Dutch
> Cadastre, who are doing a great job at publishing geographic data on the
> web as Linked Data. Examples of such datasets are buildings, addresses,
> cadastral parcels, governmental spatial plans and large scale (i.e.
> detailed) topography, all with national coverage. In working on these
> efforts, and trying to make those data work for society, a familiar and
> very basic problem keeps turning up: the various domain models for geometry
> have poor interoperability. Consequently, the same can be said for data
> formats. I believe this is very harmful for getting spatial data on the web
> to really work. And by extension, it is harmful for the web of data itself.
>
>
>
> It was not possible to address this issue fully in the SDWWG, but I am
> glad to see the charter of the Spatial Data on the Web Interest Group fully
> supportive of what I would like to suggest in this message: That a
> universal basic web ontology for spatial data should be developed.
>
>
>
> *The current problem*
>
> We live in an age where data from many different sources can live together
> in one information system: the world wide web. Data are interlinked and
> self-describing, making it possible to decouple publication of data from
> fixed ways of putting data to use. People as well as machines are free to
> mix and process data as they please. Many types of usage will involve
> space, in one way or another, because  space is a fundamental aspect of our
> reality. Consequently, many data have spatial aspects. But spatial data are
> modelled in many different ways, and can appear in many different formats.
> This diversity is a result of historical developments. Before the
> foundations for a global web of data were in place, there was a need to
> digitize spatial data in many information domains, which led to development
> of different ways of digitizing what is essentially the same thing, but
> looked at from different perspectives. For example, there is the domain of
> geography, from which the current set of standards of the OGC spring. The
> domain of building construction also deals with things related to the
> Earth’s surface, but its standards have roots in CAD, leading to very
> different ways of specifying geometries. Then there the domain of 2D and 3D
> graphics, which also deals with spatial objects, but related to different
> reference systems: a sheet of paper, a computer screen or a virtual space,
> and is heavily focused on appearance. The transport domain has yet another
> focus: it is primarily concerned with network connectivity, leading to a
> graph-based view of spatial information. That is just mentioning a few
> domains that I am familiar with, probably there are more domains in IT and
> science that have developed their own ways of coding space.
>
>
>
> Different domain models and data formats may function well within their
> respective domains, but real life problems requiring sound solutions are
> likely not limited to a certain domain. The restrictiveness of domain
> standards has always existed, but comes to light more clearly now we have
> the means to work with data irrespective of their origin.
>
>
>
> *Can Time set the pace for Space?*
>
> As a data type, time has much in common with space. It is a universal
> reality that is always present in everyday life, and has therefore been
> described in many domain models. In a recent effort coordinated in the
> SDWWG, a universal model for time was made available: the Time Ontology
> in OWL <https://www.w3.org/TR/owl-time/>. It can be used to unify many
> different ways of how people have historically coded time instants and
> intervals. I think the Time Ontology could be an inspiration for a Space
> Ontology. Seemingly, it was possible to unify different ways of expressing
> information about time by going to the mathematical roots of the
> phenomenon. Mathematics is a truly domain-independent science and it is
> great for reducing everyday phenomena to their most basic and simple forms,
> using a language that all people on earth are able to speak, irrespective
> of their place of birth. I think going to the mathematical roots of space
> is what is required to come to a universal model for spatial information on
> the web.
>
>
>
> *Doing the maths*
>
> When looking at different ways spatial data are encoded, it seems to me
> that there are three basic ingredients needed. All of them can be expressed
> mathematically:
>
>
>
> 1) The notion of a spatial reference system. For geographers that will be
> some kind of model of the Earth’s surface. For astronomers some kind of
> model of the solar system, the galaxy or something even bigger. Physicists
> and chemists studying other phenomena might have a need for much smaller
> reference systems. For graphic designers an arbitrary 2D or 3D space needs
> to be agreed upon. For architects and engineers it could be a building plot
> or a building. The common ground seems to be that in order to define a
> spatial thing, first a frame of reference, a coordinate space, needs to be
> defined. Being able to do so using universal semantics would do a lot of
> good for data interoperability and transformation of spatial data between
> different reference systems.
>
> 2) The notion of coding the shape or spatial distribution of a thing in
> numbers. Related to this is the concept of spatial resolution, or the idea
> that when spatial data represent a real world phenomenon the numbers used
> will always be an approximation.
>
> 3) The notion of functions that work on numerical definitions of shapes or
> spatial distributions. One group of such functions would be topological
> relations between geometries. Other functions could define how to extrude a
> 2D shape to a 3D shape. Still other functions could be used to add or
> subtract shapes. And much more is needed and possible.
>
>
>
> These three ingredients depend on each other: a spatial reference system
> is needed to define shapes of things, and a way of defining shapes by
> numbers is needed to define functions working on those shapes. I hope it is
> possible to combine the three ingredients in a single model that is
> mathematical at its core, giving it the ability to be used at varying
> levels of complexity, with basic usage (e.g. defining a point location in a
> 2D space) being very simple.
>
>
>
> I can imagine that when such a shared model is in place it will be much
> easier to derive data types and data formats that are truly interoperable
> because they all have the same mathematical foundations. And probably we
> could do with far less data types and data formats too. That should be a
> great boost for developing software that can work with spatial data, on the
> web and elsewhere.
>
>
>
> *Final words*
>
> Ok, that is the idea I wanted to float. I hope it makes some kind of
> sense, but it would also be interesting to know if there are flaws in the
> reasoning. Of course, should people see the merit, a next question could
> how to make such a thing happen. Without going into detail about that
> issue, I just would like to note that a lot of what is needed already
> exists, and that the OGC-W3C combo seems to be just the right environment
> to make it happen.
>
>
>
> Regards,
>
> Frans
>
>
>
> Disclaimer:
> De inhoud van dit bericht is uitsluitend bestemd voor geadresseerde.
> Gebruik van de inhoud van dit bericht door anderen zonder toestemming van
> het Kadaster
> is onrechtmatig. Mocht dit bericht ten onrechte bij u terecht komen, dan
> verzoeken wij u
> dit direct te melden aan de verzender en het bericht te vernietigen.
> Aan de inhoud van dit bericht kunnen geen rechten worden ontleend.
>
> Disclaimer:
> The content of this message is meant to be received by the addressee only.
> Use of the content of this message by anyone other than the addressee
> without the consent
> of the Kadaster is unlawful. If you have received this message, but are
> not the addressee,
> please contact the sender immediately and destroy the message.
> No rights can be derived from the content of this message.
>
>
>
> Disclaimer:
> De inhoud van dit bericht is uitsluitend bestemd voor geadresseerde.
> Gebruik van de inhoud van dit bericht door anderen zonder toestemming van
> het Kadaster
> is onrechtmatig. Mocht dit bericht ten onrechte bij u terecht komen, dan
> verzoeken wij u
> dit direct te melden aan de verzender en het bericht te vernietigen.
> Aan de inhoud van dit bericht kunnen geen rechten worden ontleend.
>
> Disclaimer:
> The content of this message is meant to be received by the addressee only.
> Use of the content of this message by anyone other than the addressee
> without the consent
> of the Kadaster is unlawful. If you have received this message, but are
> not the addressee,
> please contact the sender immediately and destroy the message.
> No rights can be derived from the content of this message.
>
>
>
>
>
> Disclaimer:
> De inhoud van dit bericht is uitsluitend bestemd voor geadresseerde.
> Gebruik van de inhoud van dit bericht door anderen zonder toestemming van
> het Kadaster
> is onrechtmatig. Mocht dit bericht ten onrechte bij u terecht komen, dan
> verzoeken wij u
> dit direct te melden aan de verzender en het bericht te vernietigen.
> Aan de inhoud van dit bericht kunnen geen rechten worden ontleend.
>
> Disclaimer:
> The content of this message is meant to be received by the addressee only.
> Use of the content of this message by anyone other than the addressee
> without the consent
> of the Kadaster is unlawful. If you have received this message, but are
> not the addressee,
> please contact the sender immediately and destroy the message.
> No rights can be derived from the content of this message.
>
>
> Disclaimer:
> De inhoud van dit bericht is uitsluitend bestemd voor geadresseerde.
> Gebruik van de inhoud van dit bericht door anderen zonder toestemming van
> het Kadaster
> is onrechtmatig. Mocht dit bericht ten onrechte bij u terecht komen, dan
> verzoeken wij u
> dit direct te melden aan de verzender en het bericht te vernietigen.
> Aan de inhoud van dit bericht kunnen geen rechten worden ontleend.
>
> Disclaimer:
> The content of this message is meant to be received by the addressee only.
> Use of the content of this message by anyone other than the addressee
> without the consent
> of the Kadaster is unlawful. If you have received this message, but are
> not the addressee,
> please contact the sender immediately and destroy the message.
> No rights can be derived from the content of this message.
>
Received on Wednesday, 14 November 2018 21:51:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:17:52 UTC