Re: About the Spatial Meronymy and Spatial Operators requirements (help needed!)

Is this not a case of topology but hierarchical relationships between
spatial objects ?

Ed


On Thu, 28 May 2015 at 17:03 Bill Roberts <bill@swirrl.com> wrote:

> Hi Frans
>
> I'll send some more specific thoughts and suggestions on what this might
> involve! I should have time tomorrow - in the middle of all day meeting at
> present.
>
> Cheers
>
> Bill
>
>
> On Thu, May 28, 2015 at 3:54 PM, Frans Knibbe <frans.knibbe@geodan.nl>
> wrote:
>
>> All,
>>
>> I am in need of assistance for formulating requirements in the UCR
>> document.
>>
>> This call for help is triggered by a remark from Bill Roberts in the UCR
>> spreadsheet
>> <https://docs.google.com/spreadsheets/d/1PSnpJYQDgsdgZgPJEfUU0EhVfgFFYGc1WL4xUX9Dunk/edit?usp=sharing>.
>> The remark added to the Spatial Meronymy requirement
>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#SpatialMeronymy>
>> reads:
>>
>> *"This standard should include not only whether A contains B, but to
>> express that A can be broken down into B,C,D which exactly cover A and do
>> not overlap.*
>>
>> *Also, that there can be several different collections of sub-areas that
>> make up a parent area. [..]**"*
>>
>> My initial thought was that that this further specification could be
>> covered by the Spatial Operators requirement
>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#SpatialOperators>.
>> And then I started wondering why there are two different requirements at
>> all. Then I started to try to find some information on the web about
>> spatial meronymy and possible relationships with topological
>> relationships. Then I started to become overwhelmed. Well, at least I think
>> I found out it is probably better to speak of  'spatial mereology'  than
>> 'spatial meronymy'.
>>
>> One aspect I wondered about is computability. I think that the
>> topological relationships that are in use in by the OGC as described by
>> the DE-9IM <http://en.wikipedia.org/wiki/DE-9IM> model are computable,
>> i.e. one needs quantitative geometries to determine a topological
>> relationship. Can anyone confirm or deny that? For example, let's say that
>> there are two spatial objects that have no clear boundaries, like the
>> Sahara desert and the Tanezrouft
>> <http://en.wikipedia.org/wiki/Tanezrouft>. From a mereology perspective,
>> we could say 'The Tanezrouft is part of the Sahara'. Could we also make
>> a similar statement from the DE-9IM perspective, e.g. 'The Sahara contains
>> the Tanezrouft', if there is no way to compute whether the statement is
>> true or false?
>>
>> Another thing to consider is the difference between spatial functions and
>> spatial properties. A spatial property can describe a relationship (e.g.
>> 'object A  overlaps  object B'). A spatial function can determine a
>> relationship (e.g. 'return all objects that overlap  object A'). There is a
>> need for both and a standard like GeoSPARQL has separated the two, e.g.
>> geo:sfContains is a property and geof:sfContains is a function (note the
>> different name space prefix). With the requirements phrased as they are now
>> the need for standardised spatial properties does not seem covered.
>>
>> I am now leaning towards suggesting changing the Spatial Meronymy
>> requirement
>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#SpatialMeronymy> to
>> a more general Spatial Relationships requirement:
>>
>> 1) There should be a standardised way for expressing spatial
>> relationships between spatial entities. These relationships can be
>> topological, mereological, directional or distance related.
>>
>> The Spatial Operators requirement
>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#SpatialOperators> perhaps
>> needs no change, but we could consider specifying that we understand
>> functions or operators to work on numerical data (so that includes raster
>> data next to vector data)
>>
>> 2) There should be standards for functions or operators working with
>> numerical spatial data.
>>
>> Rightly phrased requirements are what is needed most at the moment, I
>> hope we can agree on them.
>>
>> Regards,
>> Frans
>>
>>
>> --
>> Frans Knibbe
>> Geodan
>> President Kennedylaan 1
>> 1079 MB Amsterdam (NL)
>>
>> T +31 (0)20 - 5711 347
>> E frans.knibbe@geodan.nl
>> www.geodan.nl
>> disclaimer <http://www.geodan.nl/disclaimer>
>>
>>
> --

Ed Parsons
Geospatial Technologist, Google

Mobile +44 (0)7825 382263
www.edparsons.com @edparsons