Fuzzy Spatial relations - was RE: Spatial relations - was RE: Request for help: BP 9 "How to describe relative positions"

Probably going off on a tangent here, but it is related…..

I see this discussion of vagueness in spatial relations in many aspects as being related to the concept of Spatial Resolution (to use the terminology from ISO 19139).  We have talked a bit about the related issues of precision and accuracy but not much about scale – what level of spatial detail the data was designed to be used at.  To illustrate this, what is the bounding box of a single point?  That depends on the Spatial Resolution.  You could have a point feature for “American West” and describe it with a large bounding geometry based on a 1:250 million scale factor.

Currently Spatial Resolution is stated in the geo community as a Map Scale factor, e.g. 1:50:000.  I see this as a terribly outmoded conceptual approach to stating the spatial resolution of an object.  It is meaningless because of differences of display dimensions makes stating scale in such a way inaccurate at best and hard to understand.  Concepts such as large scale and small scale are also confusing to the non-specialist.  These people don’t generally work with data this way.  What they are more familiar with is Zoom Levels.

If we could talk about spatial resolution in terms of Zoom Levels, I think we could reach a broader audience of data users.  Luckily for us, there seems to be close to a consensus in modern web mapping tools on what these level should be.  There are generally about 20 levels.  The best compilation and description of these that I have found comes from OSM shown below.  http://wiki.openstreetmap.org/wiki/Zoom_levels  I like this approach because it gives us a handle as to how we talk about spatial vagueness, scale, accuracy and precision with a handy heuristic.  While this does not cover all the issues of Fuzzy spatial relations as raised by Jeremy, I think it is a useful approach.  Unfortunately, this standard does not exist currently, nor do mechanisms in support this exist in tools such as metadata standards.  So if people agree this is a useful idea, where do we go with it?

Or am I way off base and is this not a path worth pursuing?

Level

Degree

Area

m / pixel

~Scale

# Tiles

0

360

whole world

156,412

1:500 million

1

1

180

78,206

1:250 million

4

2

90

39,103

1:150 million

16

3

45

19,551

1:70 million

64

4

22.5

9,776

1:35 million

256

5

11.25

4,888

1:15 million

1,024

6

5.625

2,444

1:10 million

4,096

7

2.813

1,222

1:4 million

16,384

8

1.406

610.984

1:2 million

65,536

9

0.703

wide area

305.492

1:1 million

262,144

10

0.352

152.746

1:500,000

1,048,576

11

0.176

area

76.373

1:250,000

4,194,304

12

0.088

38.187

1:150,000

16,777,216

13

0.044

village or town

19.093

1:70,000

67,108,864

14

0.022

9.547

1:35,000

268,435,456

15

0.011

4.773

1:15,000

1,073,741,824

16

0.005

small road

2.387

1:8,000

4,294,967,296

17

0.003

1.193

1:4,000

17,179,869,184

18

0.001

0.596

1:2,000

68,719,476,736

19

0.0005

0.298

1:1,000

274,877,906,944


Byron


From: Jeremy Tandy [mailto:jeremy.tandy@gmail.com]
Sent: Friday, 2 September 2016 4:28 a.m.
To: Simon.Cox@csiro.au; jlieberman@tumblingwalls.com
Cc: eparsons@google.com; public-sdw-wg@w3.org
Subject: Re: Spatial relations - was RE: Request for help: BP 9 "How to describe relative positions"

@simon - that's perfect. Do you agree that it would be a good idea to get these registered as Link Relation types on the IANA registry?

I think the definitions are also in your document [1] for input into the registry ...

Jeremy

[1]: https://www.w3.org/TR/owl-time/#vocabulary


On Thu, 1 Sep 2016 at 08:56 <Simon.Cox@csiro.au> wrote:
For temporal relations, I re-drafted a diagram from one of Allen’s papers:
https://www.w3.org/TR/owl-time/images/IntervalRelations.png


From: Jeremy Tandy [mailto:jeremy.tandy@gmail.com<mailto:jeremy.tandy@gmail.com>]
Sent: Wednesday, 31 August 2016 9:43 PM
To: Joshua Lieberman <jlieberman@tumblingwalls.com<mailto:jlieberman@tumblingwalls.com>>; Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>
Cc: eparsons@google.com<mailto:eparsons@google.com>; public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>
Subject: Re: Request for help: BP 9 "How to describe relative positions"

[…]
Finally, I also note that I still need help on the "spatial relations" topic that was second in my original email. More help required please.


Jeremy

[…]
On Wed, 31 Aug 2016 at 10:26 Jeremy Tandy <jeremy.tandy@gmail.com<mailto:jeremy.tandy@gmail.com>> wrote:
Hi-

BP doc section § 10.5.1 "Describing location" [1] is where we intend to provide all the guidance that explains how you should encode location information in a web-friendly way.

This includes BP 8 "Provide geometries on the Web in a usable way" [2] and BP 9 "How to describe relative positions" [3].

(I think it's likely that we will also need a BP to help people choose the right CRS too ...)

We editors envisage BP 9 covering:

(1) Linear referencing
(2) Use of spatial relations [4]

...

[…]

(2)
We also want to demonstrate how spatial relations are used. There are obvious examples of topological relationships such as "this administrative unit _touches_ that administrative unit" (or contains etc.).

I recall that we were going to get the set of topological relationships added to the IANA Link Relations registry [7]. I am not even sure which set of topological relations we should be recommending? GeoSPARQL has me somewhat confused with "Simple Features Relation", "Egenhofer Relation" and "RCC8 Relation". Then there's D9-EIM too ...

Can someone provide me some worked examples using the preferred set of topological relationships?

We also need to illustrate use of _directional_ (e.g. "left", "in front of" and "astern") and _distance_ relations (e.g. "at", "nearby" and "far away"). I don't know of any formalised vocabulary for expressing these things. If there is one, should we be seeking to add these to the IANA Link Relations registry too?

Again, worked examples requested! If you can related them to an urban environment / flooding scenario all the better. (e.g. someone might assert "the flooding is near my house")

Finally, we also need to show people how to express "fuzzy" spatial things. Examples we have elsewhere in the BP doc are "the American West" and "Renaissance Italy". These are spatial things were there is not general agreement about the exact geographic extent, so it is not possible to use a geometry to describe it. What is the best way to describe things like this? Should we use spatial relations e.g. "downtown" _contains_ city districts A, C, D, and G (because "everyone" agrees this) - but we're not saying it's exact geometry because it's a colloquial term used by citizens of our fictional Nieuwhaven.

Again, I'd like to see a worked example.

...

There's a lot of questions wrapped up in this email. I'm looking for help to resolve them ... preferably with someone in the WG taking the lead to coordinate a response.

I'm also aware that we need to avoid an RDF bias, so it would be good to have examples in other formats too.

Volunteers, please step forward!

Thanks in advance. Jeremy

[1]: http://w3c.github.io/sdw/bp/#bp-expr-geo

[2]: http://w3c.github.io/sdw/bp/#describe-geometry

[3]: http://w3c.github.io/sdw/bp/#relative-position

[4]: http://w3c.github.io/sdw/bp/#spatial-relations

[5]: https://github.com/ISO-TC211/HMMG

[6]: http://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_TN_v3.2.pdf

[7]: http://www.iana.org/assignments/link-relations/link-relations.xhtml


--

Ed Parsons FRGS
Geospatial Technologist, Google

Google Voice +44 (0)20 7881 4501<tel:%2B44%20%280%2920%207881%204501>
www.edparsons.com<http://www.edparsons.com/> @edparsons

________________________________
This message contains information, which may be in confidence and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or info@linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You.