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

Timothy Astle timothy.astle at caris.com
Thu Aug 6 13:06:21 EDT 2015


I like the idea of leaning on an existing API, like OpenSearch or a 
CSW.  Both would work.  This is what I imagined what the OWS Common 
"OtherSource" was designed for.  I find using an existing API is a nicer 
approach than creating something new.  (Similar to Tim Bray's "Don't 
Invent XML Languages 
<http://www.tbray.org/ongoing/When/200x/2006/01/08/No-New-XML-Languages>" adage.)

Tim

On 06/08/2015 1:36 PM, Panagiotis (Peter) A. Vretanos wrote:
> Simon at al.
>
> Already done ... but we used an OpenSearch API rather than XPath 
> letting the underlying server pick nay query technology it likes.
>
> https://portal.opengeospatial.org/files/?artifact_id=54580
>
> Ciao.
>
> On 08/05/2015 05:56 PM, Simon.Cox at csiro.au wrote:
>> Ø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!
>>
>> And perhaps better still, submit this idea as an OWS Common CR or as 
>> input to
>> the upcoming revision.
>>
>> *From:*Requests
>> [mailto:requests-bounces+simon.cox=csiro.au at lists.opengeospatial.org] 
>> *On Behalf
>> Of *Peter Baumann
>> *Sent:* Wednesday, 5 August 2015 5:31 PM
>> *To:* Timothy Astle <timothy.astle at caris.com>; 
>> requests at lists.opengeospatial.org
>> *Subject:* Re: [Requests] OGC Web Coverage Service - Transaction 
>> operation
>> extension - Comment
>>
>> 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
>> inflexible.
>>
>> 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,
>> Peter
>>
>> 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 gridsand grid-related 
>> terminology
>>     and concepts.  I'm concerned that if / when point clouds or TINsare
>>     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 be
>>     created for point cloud operations?  I guess I'm just asking for 
>> clarification.
>>
>>     Thank you 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 
>> <mailto:Requests at lists.opengeospatial.org>
>>
>>     https://lists.opengeospatial.org/mailman/listinfo/requests
>>
>>
>>
>> -- 
>>
>> Dr. Peter Baumann
>>
>>   - Professor of Computer Science, Jacobs University Bremen
>>
>>     www.faculty.jacobs-university.de/pbaumann 
>> <http://www.faculty.jacobs-university.de/pbaumann>
>>
>>     mail:p.baumann at jacobs-university.de 
>> <mailto: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  <http://www.rasdaman.com>, 
>> mail:baumann at rasdaman.com  <mailto: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)
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Requests mailing list
>> Requests at lists.opengeospatial.org
>> https://lists.opengeospatial.org/mailman/listinfo/requests
>>
>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20150806/6bcd260f/attachment-0001.html>


More information about the Requests mailing list