W3C home > Mailing lists > Public > public-sdw-wg@w3.org > September 2016

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

From: Frans Knibbe <frans.knibbe@geodan.nl>
Date: Fri, 9 Sep 2016 13:29:04 +0200
Message-ID: <CAFVDz43hH50nermvCq1FeHpFphxeUHhU=CZHP4iOxOENpGV8fA@mail.gmail.com>
To: "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
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_Specificatio
>> ns/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.
>>
>>
Received on Friday, 9 September 2016 11:29:38 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:26 UTC