RE: updates to the Best Practice document

> We can’t change the definition of coverage in this group

I agree. That is beyond the scope or mandate of this group. An attribute-less point cloud is not a coverage.

________________________________
From: Jon Blower <j.d.blower@reading.ac.uk>
Sent: Wednesday, 14 September 2016 1:10:39 PM
To: Frans Knibbe; Byron Cochrane
Cc: Jeremy Tandy; SDW WG Public List
Subject: Re: updates to the Best Practice document

Hi Frans,


Ø  the ability of specifications for coverage data to work with data that have no range values.

I don’t understand this. If the coverage doesn’t have any range values at all, then it’s not a coverage. The whole point of a coverage is to map positions in space and time (or other dimensions) to data values. For a point cloud coverage, the data values may represent intensity, reflectancy, colour or something like that.

If you really just have the points then you have the domain of a coverage. Or perhaps a geometry. Or Just A Bunch Of Points. Anyway, it’s not a full coverage.

We can’t change the definition of coverage in this group to accommodate point clouds, and there is no need to do so.

Cheers,
Jon

From: Frans Knibbe <frans.knibbe@geodan.nl>
Date: Wednesday, 14 September 2016 13:53
To: Byron Cochrane <bcochrane@linz.govt.nz>
Cc: Jon Blower <sgs02jdb@reading.ac.uk>, Jeremy Tandy <jeremy.tandy@gmail.com>, SDW WG Public List <public-sdw-wg@w3.org>
Subject: Re: updates to the Best Practice document

Yes, probably forcing people to model point clouds without associated values as multipoints is not that helpful. If you store or exchange a point cloud that way all point coordinates would be lumped together in a single object, which will hinder data processing.

But a consequence of that will be that a somewhat looser definition of 'coverage' is needed, and together with that the ability of specifications for coverage data to work with data that have no range values.

Regards,
Frans



On 13 September 2016 at 01:07, Byron Cochrane <bcochrane@linz.govt.nz<mailto:bcochrane@linz.govt.nz>> wrote:
I would be hesitant to refer to point clouds as multipoints.  While a multipoint format can be used to store point clouds I see this as really just a useful kludge.  A multipoint feature is a Spatial Thing that is best represented as a collection of points, e.g. the entrances to a rabbit warren, the outlet of a river where it forks in a delta, the multiple strike points from a singular meteor.  Point clouds are a coverage type, an irregular raster that is a collection of points that reference all Spatial Things the signals happens to reflect.

True real world multipoint spatial things are actually quite rare.  Usually they are a convenience of scale.  I have rarely used them.

Cheers,
Byron

From: Frans Knibbe [mailto:frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>]
Sent: Friday, 9 September 2016 10:38 p.m.
To: Jon Blower
Cc: Jeremy Tandy; SDW WG Public List

Subject: Re: updates to the Best Practice document

Hi Jon,

If I look at the description of point clouds in the Wikipedia<https://en.wikipedia.org/wiki/Point_cloud> it seems that in practice they are used to describe the edge of a spatial thing. By our definitions they are multipoint geometries, I think. So in practice there seems to be some overlap between the concepts of coverage and geometry. Should that be cause for alarm on our part? Or could we safely say to our audience: pick whatever floats your boat? Could there be need for some extra guidance for people that work with point cloud data?

Regards,
Frans



On 9 September 2016 at 11:55, Jon Blower <j.d.blower@reading.ac.uk<mailto:j.d.blower@reading.ac.uk>> wrote:
Hi Frans,

If the point clouds really have no other value than location then I would say this is a multipoint. If you modelled it as a coverage you would have a domain but no range (and also no metadata about the range). I guess that if you really wanted it to be a coverage you could model it as a degenerate case where all the range values are null, or repeat the location values somehow.

Cheers,
Jon




From: Frans Knibbe <frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>>
Date: Friday, 9 September 2016 10:48
To: Jeremy Tandy <jeremy.tandy@gmail.com<mailto:jeremy.tandy@gmail.com>>
Cc: SDW WG Public List <public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>>
Subject: Re: updates to the Best Practice document
Resent-From: <public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>>
Resent-Date: Friday, 9 September 2016 10:48

Hello,

About the difference between spatial data as coverage and spatial data as geometry: Is the difference between a point cloud and a multipoint clear? I understand that point clouds are regarded as coverages. Multipoints are geometry. But I notice that points clouds exist where the points have no other value next, apart from geometry. One could say that in that case the mapped value is 'location'... I wonder if readers need more guidance on when point collections should be modelled as multipoint or as coverage.

Regards,
Frans

On 8 September 2016 at 14:00, Jeremy Tandy <jeremy.tandy@gmail.com<mailto:jeremy.tandy@gmail.com>> wrote:
Thank you! I reference ISO 19109 from the coverage definition in the glossary (although I've not set up the bibliographic ref yet) so it should be credited in the bibliography.

Jeremy

On Thu, 8 Sep 2016 at 12:58, <Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>> wrote:
You've largely paraphrased and only directly used a couple of sentences, so unlikely to be a problem. If in doubt, give credit - ie add it to the bibliography.
________________________________
From: Jeremy Tandy <jeremy.tandy@gmail.com<mailto:jeremy.tandy@gmail.com>>
Sent: Thursday, 8 September 2016 9:50:19 AM
To: Cox, Simon (L&W, Clayton); public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>
Subject: Re: updates to the Best Practice document

All- I've tried to incorporate some of the useful text cited by Simon. I've also taken the opportunity to update the definition of coverage in the glossary.

On Thu, 8 Sep 2016 at 07:24 Jeremy Tandy <jeremy.tandy@gmail.com<mailto:jeremy.tandy@gmail.com>> wrote:
Hi Simon- That's useful ... what's the copyright associated with the ISO text?
On Thu, 8 Sep 2016 at 04:43, <Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>> wrote:
The recent revision of ISO 19109 added material on Coverages (as well as Observations) that was not in the original, recognising that coverages are important tools for some applications. You might also like to consider these sections from ISO 19109:2013

7.2.2 Coverages

Many aspects of the real-world may be represented as features whose properties are single-valued and static. These conventional features provide a model of the world in terms of discrete objects located in it. However, in some applications it is more useful to use a model focussing on the variation of property values in space and time, formalized as coverages. Users of geographic information may utilize both viewpoints. While coverages are themselves strictly features as well, it is common to contrast coverages and non-coverage features when discussing the functionality provided by each viewpoint. In the following discussion the name ‘feature’ refers to non-coverage features.
The feature and coverage representations may be related in several ways:

— signal processing to find and characterize features: signals in coverages may provide evidence for the existence, location and type of features, detected through modelling and interpretation;

EXAMPLE 1 Patterns of colour or other radiance bands within a remotely-sensed image may be used to infer the existence of specific objects or features on the ground.

EXAMPLE 2 Signals in a geophysical borehole log may be used to infer the presence of particular rock-units at underground locations.

— coverage-typed feature properties: feature properties whose value vary within the scope of a feature may be described as coverages whose domain extent is the geometry of the feature;

EXAMPLE 3 The variation of concentration of a particular ore-mineral within a mine may be described as a spatial function or coverage within the spatial limits of the mine.

— features sample a coverage: the values of a common property of a set of features provide a discrete sampling of a coverage, whose range type is the property, and whose domain is the aggregate geometry of the set of features.

EXAMPLE 4 The temperature at a set of weather stations may be compiled to show the spatial variation of temperature across the region where the stations are located.

A constraint in the latter two cases is that a property-type from a feature catalogue is the range-type of a coverage description in the same universe of discourse.

The case of features having property values that vary within the scope of the feature can be described using the general feature model (7.5.8).

While the coverage model is described in detail in ISO 19123, an application schema may include both feature- and coverage-types.
NOTE The feature and coverage viewpoints are related to (though not identical with) the so-called ‘vector’ and ‘raster’ approaches from traditional GIS implementations.

Then, immediately following:

7.2.3 Properties and observations

Property values are associated with features and coverages. In the case of features, a property value is associated with a classified object. In the case of coverages, a property value is associated with a position in the domain.

Later

8.8 Rules for use of coverage functions

Coverage functions are used to describe characteristics of real-world phenomena that vary over space and/or time. Typical examples are temperature, elevation and precipitation. A coverage contains a set of such values, each associated with one of the elements in a spatial, temporal or spatio-temporal domain. Typical spatial domains are point sets (e.g. sensor locations), curve sets (e.g. contour lines), grids (e.g. orthoimages, elevation models), etc. A property whose value varies as a function of time may be represented as a temporal coverage or time-series. A continuous coverage is associated with a method for interpolating values at spatial positions between the elements of a domain, e.g. between two points or contour lines.

From: Jeremy Tandy [mailto:jeremy.tandy@gmail.com<mailto:jeremy.tandy@gmail.com>]
Sent: Thursday, 8 September 2016 7:17 AM
To: SDW WG Public List <public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>>
Subject: updates to the Best Practice document

Following today's BP call, I've now added into the BP doc what I was talking about:

* A section explaining about Coverages [1] (thanks to Jon Blower; I repurposed one of his Melodies blog posts!)
* The beginnings of a section that tries to provide a linear path through the decisions you might make when publishing data: "How to use these best practices" [2] ... this tries to combine SDW and DWBP best practices into a coherent whole ... that said, I've found it really hard to plan this out; I think it's working (& there's more in my head that I unfortunately don't have time to write before I disappear tomorrow ... leaving no more time for update before TPAC.

Hope these additions are worthwhile.

Jeremy

[1]: http://w3c.github.io/sdw/bp/#coverages
[2]: http://w3c.github.io/sdw/bp/#how-to-use



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