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

I have a bad feeling about this - describing zoom levels clearly enough so
that MyZoom can be compared with YourZoom means a description of CRS and
precision, and maybe rendering technology, deduplication and labelling.
There are lots of datasets with something similar built in - but not a lot
of evidence people are trying to standardise such terms.

My feeling is that we should leave the datatype of precision/resolution
open - then people can use a zoom level categorisation as an option. I
would suggest that BP is that the coordinate precision  can be identified
_if present_ and described in units relevant to the CRS (perhaps the term
should be "spatial resolution" perhaps as grid tesselations such as DGGS or
what3wordsmay be used instead of coordinates for spatial positioning).

thus its fine to have something like
geo-core:resolution :zoom1;
:zoom1 a myns:ZoomLevel ;
myns:ZoomLevel a wms:DisplayZoomConcept;
zoom1 wms:nominalDisplayScale 50000;
zoom1 myns:nearestHigherOrderZoomObjectDistance 1000;

i.e. i think Zoom semantics need to defined in some operational context,
then instantiated with parameters - but I dont think we could specify
canonical properties easily - so it needs to be bound to a more general
property - which probably does need to be canonical (or declared as a
subProperty of the canonical Property, to allow backwards compatibility
with existing data)

Rob



On Wed, 7 Sep 2016 at 07:09 Byron Cochrane <bcochrane@linz.govt.nz> wrote:

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