[Requests] OGC Web Coverage Service - Transaction operation extension - Comment

Peter Baumann p.baumann at jacobs-university.de
Wed Aug 5 03:31:16 EDT 2015

Dear Timothy,

after completion of the RFC period I'm coming back to your (very thoughtful)
questions below.

Re Req 8: This actually is a known issue with OWS Common. A service provider can
decide which elements to expose in a Capabilities document, which has been
considered sufficient in the past. Alas, it does not solve the issue - practice
shows that either you get not enough information, or too much (such as all
coverages listed). In fact, the Capabilities mechanism is way too static and

OGC has started thinking about how to fix and modernize, but there is no relief
on the horizon soon. Therefore, we have prepared a WCS Extension which I want to
propose for voting at the Nottingham TC. This extension introduces a very simple
concept: an XPath expression can be submitted which is evaluated on the
Capabilities document on server side. This allows applications to get exactly
what they need, without excess data transfer. If you feel that this is a way
forward, maybe you want to support this in the upcoming TC meeting - any such
support is greatly appreciated!

Re References to grids: Core and extensions have been formulated very carefully
so as to allow all coverage types defined, which includes point clouds and
meshes. Currently, there is one extension which specifically refers to grids,
that is WCS Scaling: change of resolution is an operation meaningful on grids
only (at least that is my current understanding). Concretely speaking about
WCS-T, a point cloud (MultiPointCoverage) or mesh (MultiCurveCoverage or
MultiSurfaceCoverage or MultiSolidCoverage) can be inserted and deleted, and can
even be updated. Of course, update of a mesh requires more complex consistency
constraints to be respected, but that is inherent to the definition of such mesh
types, so does not have to be treated separately here.

Actually, there is nothing in the mask parameter that confines us to a grid.
Consider a point cloud, for example, The mask in this case will contain the
direct positions of the points to be updated, associated with a range value of
"1" (likely in this case the "0" points will simply be left out), and this
guides the server on the points to be updated - say, with a new temperature
value. Hence, I'd claim that this definition works on all coverage types -
kindly let me know should I miss something here, it's a good opportunity to
catch any and all hiccups.

And obviously there is one: searching for the root cause of your concern I find
occurrences of "maskGrid", a leftover forgotten in an earlier renaming action. I
have corrected this, and it actually resolves an inconsistency - good catch!

Thank you again for the encouraging assessment and your thoughtful comments.
Looking forward to further discussion in future.

best regards,

On 2015-06-26 20:48, Timothy Astle wrote:
> A couple of questions:
> _Requirement 8 _
> /After completion of a successful InsertCoverage request, the identifier of
> the coverage established in the server’s offering shall be listed as an
> existing coverage in this WCS service’s Capabilities document./
> OGC 06-121r9 (OGC Web Services Common Standard) still allows for the idea of
> an "otherSource" for finding OWS content.  Is the above requirement mandating
> thatwhen implementing a WCS-T, you must describe the coverage in the
> Capabilities' CoverageSummary list?  I'm concerned that when dealing with a
> large amount of coverages, that could really degrade the performance of a system.
> _References to Grids_
> I definitely see value to this transactional extension to WCS.  I'm definitely
> interested to watch WCS grow beyond gridded data.  In this particular
> extension, I seereferences to grids and grid-related terminology and
> concepts.  I'm concerned that if / when point cloudsor TINs are introduced as
> extensions, that this specification might not makesense in some contexts.  For
> example, if a WCS was created that specialized in TINs, the optional grid
> parameters wouldn't really apply.  Is the intent that this is a "grid
> transactional operation extension" or a "general coverage operation
> extension"?  Would a future point cloud transactional extension becreated for
> point cloud operations?  Iguess I'm just asking for clarification.
> Thankyou for your time and consideration.
> -- 
> Tim Astle
> Development Manager for Web Technologies
> *CARIS* <http://www.caris.com>
> 115 Waggoners Lane
> Fredericton, New Brunswick
> Canada    E3B 2L4
> Tel: +1.506.458.8533     Fax: +1.506.459.3849
> www.caris.com <http://www.caris.com>
> *Connect with CARIS*
> Twitter <http://www.twitter.com/CARIS_GIS> | LinkedIn
> <http://www.linkedin.com/groups?mostPopular=&gid=3217878> | Facebook
> <https://www.facebook.com/pages/CARIS-The-Marine-GIS-Experts/123907500987669?v=app_4949752878>
> | Google+
> <https://plus.google.com/b/114389770462919844434/114389770462919844434/posts>
> | YouTube <http://www.youtube.com/user/CARISGIS>
> Download your free copy of CARIS Easy View today!
> www.caris.com/easyview <http://www.caris.com/easyview>
> _________________________________________________________________________
> This email and any files transmitted with it are confidential and intended
> only for the addressee(s). If you are not the intended recipient(s) please
> notify us by email reply. You should not use, disclose, distribute or copy
> this communication if received in error.
> Any views or opinions expressed in this email are solely those of the author
> and do not necessarily represent those of the company. No binding contract
> will result from this email until such time as a written document is signed on
> behalf of the company.
> _______________________________________________
> Requests mailing list
> Requests at lists.opengeospatial.org
> https://lists.opengeospatial.org/mailman/listinfo/requests

Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   mail: p.baumann at jacobs-university.de
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   www.rasdaman.com, mail: baumann at rasdaman.com
   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20150805/84e16e60/attachment.html>

More information about the Requests mailing list