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> 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]
> *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]
> *Sent:* Wednesday, 31 August 2016 9:43 PM
> *To:* Joshua Lieberman <jlieberman@tumblingwalls.com>; Cox, Simon (L&W,
> Clayton) <Simon.Cox@csiro.au>
> *Cc:* eparsons@google.com; 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> 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
> 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.
>