Re: updates to the Best Practice document

Hi Jon,

Fair enough. I was just trying on the perspective of someone that has point
cloud data without associated values and who is looking for the most
appropriate way to publish those data on the web, given that point clouds
are considered a type of coverage.

Probably JABOP (Just A Bunch Of Points) is the best way to make a rangeless
point cloud available. Anyway, it could be confusing so it seems some sort
of guidance is useful.

Regards,
Frans

On 14 September 2016 at 15:10, Jon Blower <j.d.blower@reading.ac.uk> wrote:

> 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>
> 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]
> *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> 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>
> *Date: *Friday, 9 September 2016 10:48
> *To: *Jeremy Tandy <jeremy.tandy@gmail.com>
> *Cc: *SDW WG Public List <public-sdw-wg@w3.org>
> *Subject: *Re: updates to the Best Practice document
> *Resent-From: *<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> 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> 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>
> *Sent:* Thursday, 8 September 2016 9:50:19 AM
> *To:* Cox, Simon (L&W, Clayton); 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> 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> 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]
> *Sent:* Thursday, 8 September 2016 7:17 AM
> *To:* SDW WG Public List <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) 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.
>
>
>