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

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>
>
>