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

Hi Jeremy,

I think that zoom level could be used in a variety of context, but primarily to state the resolution of the dataset.  Instead of stating the resolution (scale at which the data was designed to be used) as 1:50000, a data publisher could state the data (say a coastline) as meant to be used at Zoom level 13.  A more detailed version of the coastline could be stated as being Zoom Level 18.

This approach could possible be used for stating some fuzzy boundary type data, say the American West.  These are often represented as label points since a polygon would be misleading.  A bounding box or radius could be derived based on some statement of zoom level appropriate to the data.  In this case, American West is a broad area, so zoom level 3 or 4 might be appropriate for this spatial object.  This would be a statement of vagueness in this case.

I would change your statement slightly from “stating the extent of a spatial thing based on the first zoom-level that it would be resolved at” to “stating the extent of a spatial thing based on the first zoom-level that it was designed to be used at.”  I don’t believe there is currently any support in existing metadata standards or tools for zoom levels.

Just throwing this out there.  My feeling is that Zoom Levels are a more accessible concept to the non-gis folk.  It is something they use frequently and is tangible to them.  Definitely needs more work.  But there is a near consensus it seems on what these zoom levels are so we have a good start to build on.

Cheers,
Byron

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

Hi Byron- apologies for missing this at the end of last week. I think that this is an interesting concept; to use resolution to describe spatial things

I summarise as "stating the extent of a spatial thing based on the first zoom-level that it would be resolved at". Is this a reasonable approximation?

Of course, what you display on a map tile at a given resolution is somewhat subjective - it clearly has to be bigger than a single pixel, and big enough so that it is not cluttered with other spatial things of the same type. Have you come across any guidance for what size of spatial thing should be displayed at each zoom level? (more so than the few items in the table you included in your email) ... Is size even the right measure? For example - why is Aukland the first city to appear when zooming in on NZ? It's bigger by population, but it's not the capital city ...

Jeremy

On Fri, 2 Sep 2016 at 00:00, Byron Cochrane <bcochrane@linz.govt.nz<mailto:bcochrane@linz.govt.nz>> wrote:
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<mailto:jeremy.tandy@gmail.com>]
Sent: Friday, 2 September 2016 4:28 a.m.
To: Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>; jlieberman@tumblingwalls.com<mailto:jlieberman@tumblingwalls.com>
Cc: eparsons@google.com<mailto:eparsons@google.com>; public-sdw-wg@w3.org<mailto: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<mailto: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<mailto: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<mailto: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.