Re: BP document FROZEN - vote next Monday [SEC=UNCLASSIFIED]

Hi Bruce- one more update on this topic ... having re-read the "How to use"
section, I didn't feel it was adding much value anymore - so I deleted it!
Now people won't be flummoxed about imagery formats and spectral bands!

Jeremy

On Thu, 4 May 2017 at 21:08 Jeremy Tandy <jeremy.tandy@gmail.com> wrote:

> Hi Bruce -
>
> I've updated the BP doc to incorporate some of your comments. See PR #796
> [1]
>
> Before I go into details, let me say:
> 1/ I have an outstanding action to update section 11 - your commentary is
> useful and I will try to incorporate that
> 2/ you ask what's driving the deadline? the SDW WG Charter expires at the
> end of June, and when you factor a 45-day vote in for OGC, we're already a
> little over. We plan to freeze the document on Monday 8-May, with a WG vote
> to release on Wednesday 10-May, then there will be a OGC TC presentation
> (via webinar) on Friday 12-May. Then begins the 45-day vote which will be
> running while the St. Johns TC happens.
>
> So - looking back at the feedback you gave (on 13 Apr)
>
> A/ Section 5 Spatial Things: I have added The Sahara as an example of a
> spatial thing with fuzzy boundaries
> B/ Section 6 Coverages: You're right that conceptually, a coverage has
> extent. While some may see it just as a data structure, I think it is more
> convenient to think of a coverage as a type of spatial thing with some
> particular characteristics. I've updated the text to reflect this more
> flexible approach
> C/ You suggest that "a discussion on how ‘spatial things’ are
> conceptualised as ‘objects’/features/coverages etc could be useful" - but
> this is potentially a huge & complex topic in and of itself. We have
> attempted to give a light touch to 'conceptualising' spatial things in
> Section 5; and Section 6 describes how spatial things (features) and
> coverages may be related. Early on, the WG agreed that we would not try to
> provide advice on [semantic] data modelling. DWBP [2] (which we refer to)
> talks about data modelling (or at least picking the right vocabulary) to
> some degree I think. Without adding a whole new section, I'm struggling to
> see what changes I might make to the SDW BP doc.
> D/ Section 7 Spatial Relations: I think that the current text is correct
> here - certainly, it is drawn from trustworthy sources. You also suggest
> adding a discussion about spatial joins. Again, I smell trouble here. If B
> is within A, then figuring out which properties from A also apply to B is a
> complex problem for which you need to have a good understanding of the
> semantics; it's similar to determining is to resources are actually the
> same (correlation etc.) - "Here be dragons" we said. I said earlier that
> the WG has shied away from semantics, because our focus is on the spatial
> aspects. And yes, you could argue the a spatial join is a spatial aspect,
> but it does rely on the understanding of the semantic model which is domain
> dependent. Finally, I'll add that we have unashamedly focused on _data
> publication_; spatial joins are a usage concern. Given the limited
> resources we have available in the group, we sadly can't cover all the
> problems.
> E/ Section 8 CRS: I covered this in a separate email and PR
> F/ Section 10 SDI: Apologies if it reads that we have an overly
> pessimistic view of SDIs. I tried to assert that SDIs are a necessary part
> of managing spatial information. The challenge is that they are not easy to
> use by non-experts. I totally agree that SDIs are more than the discovery
> catalogue! On the subject of discovery metadata, we have a whole best
> practice (BP13 [3] - sorry, we changed the numbers) devoted to dataset
> metadata; and BP2 [4] talks about the role that that dataset metadata has
> in making the spatial data discoverable by getting stuff indexed by search
> engines. So I think that we're really not throwing out babies and bath
> water together :-)
>
> That's all for now.
>
> If you're content with these changes, that's good. If there's still stuff
> you're struggling with, then you have two options:
> 1/ provide some text for us to incorporate ... remember we want to freeze
> the document by Monday 8-May
> 2/ wait for the OGC vote (starting 12-May) and provide feedback about your
> concerns there ... the earlier the better, then we stand a better chance of
> being able to respond.
>
> Oh- one more thing. The SDW Best Practice doc is a W3C Note, which means
> it can be updated. There is a plan to create a Spatial Data on the Web
> 'community group' that will carry the work on.
>
> Best Regards, Jeremy
>
> [1]: https://github.com/w3c/sdw/pull/796
> [2]: https://www.w3.org/TR/dwbp/
> [3]: http://w3c.github.io/sdw/bp/#spatial-info-dataset-metadata
> [4]: http://w3c.github.io/sdw/bp/#indexable-by-search-engines
>
> On Wed, 19 Apr 2017 at 08:22 Bruce Bannerman <bruce.bannerman@bom.gov.au>
> wrote:
>
>> Hi Jeremy,
>>
>>
>> I've just had a quick scan through the rest of the best practice.
>>
>>
>> This document needs time for a decent sanity check.
>>
>>
>> It is quite technical and assumes quite a bit of prior knowledge.
>>
>>
>> I suspect that we may be missing the needs of the targeted audience (that
>> I'm assuming to be a Web Developer).
>>
>>
>>
>>
>> As an example under 11.4 Parse that, there is the text:
>>
>>
>> "Imagery formats JPEG [JPEG2000
>> <http://w3c.github.io/sdw/bp/#bib-JPEG2000>] and PNG [PNG
>> <http://w3c.github.io/sdw/bp/#bib-PNG>] can also be coerced to carry
>> data; providing 3 or 4 channels of 8-bit data values."
>>
>>
>> An end user would need to understand that imagery is typical presented as
>> a set of bands of data, where each band is a segment of the Electromagnetic
>> Spectrum.
>>
>>
>> Using the example of a set a 7 bands within a Landsat 7 scene, only three
>> bands are typically presented in a JPEG/PNG file as RGB values. These
>> RGB values in the file may actually depict a different band combination
>> from the image, e.g. data from Blue, NIR and MIR bands.
>>
>>
>> The paragraph goes on to discuss the need to avoid compressed data, but
>> does not discuss lossy and non-lossy compression algorithms.
>>
>>
>> Lossy compression should be avoided (as stated), but lossless may well be
>> OK.
>>
>>
>> Though this will also depend on intended use. If the data is just to be
>> used as a 'pretty picture' background then the lossy format is probably OK.
>>
>>
>> The JPEG2000 image format that is used as an example is typically
>> compressed with a wavelet compression. This is usually a lossy compression,
>> unless the data creator has explicitly created a lossless image.
>>
>>
>>
>> This is only one example that I was able to quickly find for this email.
>>
>>
>> =====
>>
>> What is driving the current rush to finish this work? Is the deadline
>> just arbitrary that someone has pulled out the air?
>>
>> =====
>>
>>
>> There is a lot of good work in this document. I'd like too see it undergo
>> a rigorous edit and sanity check.
>>
>>
>>
>> I will have to leave this version of the document now, as I really do
>> have other priorities that I need to concentrate on.
>>
>>
>>
>> Kind regards,
>>
>>
>> Bruce
>>
>>
>>
>> ​
>> ------------------------------
>> *From:* Jeremy Tandy <jeremy.tandy@gmail.com>
>> *Sent:* Thursday, 13 April 2017 3:54 PM
>> *To:* Bruce Bannerman; Tandy, Jeremy
>> *Cc:* public-sdw-wg@w3.org
>> *Subject:* Re: BP document FROZEN - vote next Monday [SEC=UNCLASSIFIED]
>>
>> Hi Bruce. This is all good input which I will weave into the draft ...
>> many thanks for your efforts!
>>
>> Our dates seem to have got crossed though :-)
>>
>> The "Monday" in the email title was back in March ahead of the TC meeting
>> in Delft! We voted to release that draft anyway.
>>
>> Currently, we expect to have a _FINAL_ draft (pending editorial fixes
>> etc) ready for vote on 26 April ... however I've just picked up an extra
>> week of week that was unexpected so we may slide that a little.
>>
>> So-
>> 1/ thank you
>> 2/ there's still time for more :-)
>> 3/ incorporating the outcomes from the CRS thread is on my to-do list
>>
>> Happy Easter!
>>
>> Jeremy
>> On Thu, 13 Apr 2017 at 06:24, Bruce Bannerman <bruce.bannerman@bom.gov.au>
>> wrote:
>>
>>> Hi Jeremy,
>>>
>>> I’m not going to get the time to review this BP within the timeframe
>>> required by SDWWG.
>>>
>>> I’ll send you what I have to date. You may be able to do something with
>>> it.
>>>
>>>
>>>
>>> 5. Spatial Things
>>>
>>>    - I recall that there was some discussion on imprecisely defined
>>>    locations. Where did we get to with this.   Some examples:
>>>
>>>
>>>    - The Mara-Serengeti ecosystem
>>>       - The Great Barrier Reef
>>>       - Dogger Bank
>>>       - West of the Black Stump
>>>       - The Sahara
>>>       - the coastline
>>>       - The Western Australian Greenstone belt
>>>       - The Mary River floodplain
>>>
>>>
>>>    - These could also be considered 'Spatial Things’, we just can’t
>>>    reliably define their locations with crisp vector boundaries.
>>>
>>>
>>> 6. Coverages
>>>
>>>    - I note the statement about coverages not being a 'spatial thing’.
>>>
>>>
>>>    - This is quite constraining and implies that only vector data can
>>>       be a 'spatial thing’.
>>>
>>>
>>>    - Following on from my comments in response to 2 above, many of
>>>       these features are best represented with imprecise ‘fuzzy’ boundaries. A
>>>       coverage is a good way of handling this.
>>>
>>>
>>>
>>> On  5. Spatial Things  and  6. Coverages
>>>
>>>    - I don’t like the artificial delineation between ‘spatial things’
>>>    and Coverages.
>>>
>>>
>>>    - Both are conceptually ‘Spatial Things’
>>>
>>>
>>>    - We are just talking about vector and raster data in different
>>>       terms.
>>>
>>>
>>>    - A ‘Spatial Thing’ could be represented using both raster and
>>>       vector representations, depending on the context of what the representation
>>>       is to be used for.
>>>
>>>
>>>    - This is probably where a discussion on how ‘spatial things’ are
>>>       conceptualised as ‘objects’/features/coverages etc could be useful. It
>>>       could bring in discussions on scale, precision, accuracy, intended use etc.
>>>
>>>
>>>    - I do like the the linkage between a real world concept and
>>>    multiple representations of that concept. It will allow us to overcome a
>>>    long term issue inherent in spatial data modelling.
>>>
>>>
>>>
>>> 7.  Spatial Relations
>>>
>>>    - Topological Relations
>>>
>>>
>>>    - Topology is more about the connectedness of features e.g.:
>>>
>>>
>>>    - Network trace, upstream, downstream
>>>          - Left of, right of
>>>          - Etc
>>>
>>>
>>>    - The examples given are conflating topology with spatial overlay
>>>       functions, e.g.
>>>
>>>
>>>    - Intersects, Overpaps, Point in poly, Buffer, etc
>>>
>>>
>>>    - Perhaps a brief discussion on 'spatial joins’ may be also
>>>    appropriate here, where the attributes of one feature can potentially be
>>>    assumed by another feature due to their spatial co-location, e.g.:
>>>
>>>
>>>    - 'this building’ is located in 'this census district', therefore I
>>>       infer that the census attributes for 'this census district’ apply to the
>>>       residents of ’this building'
>>>
>>>
>>> 8. CRS
>>>
>>>    -
>>>
>>>    See my comments in the related email. They are still relevant as
>>>    noted by Byron in his email of 4 April.
>>>
>>>
>>>
>>> 10. SDI
>>>
>>>    - This document takes an overly pessimistic and narrow view of SDIs.
>>>
>>>
>>>    - SDIs are more than just a Discovery Metadata catalogue.
>>>
>>>
>>>    - They are defined as "the base collection of technologies, policies
>>>    and institutional arrangements that facilitate the availability of and
>>>    access to spatial data”. See the SDI Cookbook [1], Chapter 1, SDI.
>>>
>>>
>>>    - Discovery metadata records *can* be very useful for determining
>>>    the content of a given spatial dataset and its intended use. They
>>>    are very useful to use to determine if it is appropriate to use the data
>>>    set for a purpose other than that for which it was created.
>>>
>>>
>>>    - What would be useful is if a way could be found to make these
>>>    metadata records within the catalogues indexable, together with a way of
>>>    linking the Discovery Metadata record to the Spatial Data Service(s) that
>>>    provide access to this data. This is where there is considerable potential
>>>    for linked data. And yes these services could be configured to provide
>>>    GUID’s for spatial things, just don’t throw the baby out with the bathwater.
>>>
>>>
>>> Sorry, that is all that I’ve been able to get to.
>>>
>>> Kind regards,
>>>
>>> Bruce
>>>
>>> [1]
>>> http://gsdiassociation.org/images/publications/cookbooks/SDI_Cookbook_from_Wiki_2012_update.pdf
>>>
>>>
>>>
>>> From: Linda van den Brink <l.vandenbrink@geonovum.nl>
>>> Date: Thursday, 16 March 2017 at 20:04
>>> To: "SDW WG (public-sdw-wg@w3.org)" <public-sdw-wg@w3.org>
>>> Subject: BP document FROZEN - vote next Monday
>>> Resent-From: <public-sdw-wg@w3.org>
>>> Resent-Date: Thursday, 16 March 2017 at 20:04
>>>
>>> Hi all,
>>>
>>>
>>>
>>> The BP document is FROZEN and ready for people to read/review at
>>> http://w3c.github.io/sdw/bp/.
>>>
>>>
>>>
>>> A massive amount of work has been done during this sprint. To summarize:
>>>
>>> - Section 8 CRS, BP1, BP3, BP6, BP8, BP9, BP10, BP11, BP14, BP17 updated
>>>
>>> - BP2, BP12, BP13, BP15, BP16, Section 12.8 (Dealing with large
>>> datasets), Section 14 Narrative removed
>>>
>>>
>>>
>>> A full account of the changes is in the sprint plan[1].
>>>
>>>
>>>
>>> VOTE is scheduled for MONDAY 20-3-2017 during the face to face meeting
>>> in Delft.
>>>
>>>
>>>
>>> Special thanks to Andrea, Josh, Clemens, Bill, Ed, and Byron for putting
>>> in the hours this sprint!
>>>
>>>
>>>
>>> Linda & Jeremy
>>>
>>>
>>>
>>> [1]:
>>> https://www.w3.org/2015/spatial/wiki/Detailed_planning_BP_document#February_-_mid_March_2017
>>> :
>>>
>>>