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

Only if you have a geometry associated with the thing you are interested
in... I want to be able to express Soho is inside London and that it is
west of the Greenwich Meridian without needing to know the precise location
of these things ?

So these are very relative locations :-)

Ed


On Fri, 9 Sep 2016 at 12:30 Frans Knibbe <frans.knibbe@geodan.nl> wrote:

> Hello,
>
> What could be wrong with simply expressing spatial resolution as a
> distance in CRS units? It would be a number that is easy to interpret,
> process and compare.
>
> Regards,
> Frans
>
>
> On 7 September 2016 at 01:16, Rob Atkinson <rob@metalinkage.com.au> wrote:
>
> 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.
>
>
> --

*Ed Parsons *FRGS
Geospatial Technologist, Google

Google Voice +44 (0)20 7881 4501
www.edparsons.com @edparsons