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

Marten Hogeweg mhogeweg at esri.com
Fri Aug 7 12:11:11 EDT 2015


Isn't the point to not have the enormous GetCapabilities responses? Thus we need to move some of these things outside of the response and use a different mechanism (such as Peter proposed or using GetDomain or such). GetCapabilities would focus more on the operations the service supports, this GetDomain/search-like operation would allow a client to get the specifics of coverages, observations, projections, etc

-----Original Message-----
From: Requests [mailto:requests-bounces+mhogeweg=esri.com at lists.opengeospatial.org] On Behalf Of Peter Baumann
Sent: Friday, August 7, 2015 1:20 AM
To: Panagiotis (Peter) A. Vretanos; Simon.Cox at csiro.au; timothy.astle at caris.com; requests at lists.opengeospatial.org
Subject: Re: [Requests] OGC Web Coverage Service - Transaction operation extension - Comment

Hm, that's a different ballpark. At the bottom I add a few use cases which WCS operators typically need for their users.
But first an analysis:

- preamble: OpenSearch is for human users directly talking to the data. The gap XPath fills, however, is mainly that clients need some information for operation and maybe generate client info (such as pop-up menus) - in other words, the XPath is machine-generated and hidden from the humans.

- data model. OpenSearch does not know about the structure and semantics of the Capabilities document.
Ex: retrieving a URL OpenSearch cannot determine whether it is the Native CRS of some coverage or just some CRS supported.
Note that the XPath approach takes the complete WCS offering and hence allows drilling down into specific coverages (see examples).

- query model.
    - It looks like it allows conjunctive queries (only AND connections), but not disjunctive queries (OR connections), likely also no negation of predicates, and no nesting (ie: parentheses). The XPath approach relies on the established definitions of W3C which allows OR connections, predicates, etc.
    - OpenXPath allows to address only part of a Capabilities document, and for WCS it would not allow the coverages to be addresses; XPath allows both
    - XPath can deliver XML or just plain text lines, it's up to the user
    - XPath is fully W3C conformant whereas bbox and start/end introduce new query concepts (and separation of time and space does not work with coverages)

- complexity.
    - OpenSearch is rather complex (6 parameters) whereas XPath is simple and straightforward (1 parameter defined by just 4 requirements).
    - you introduce a specific requirement on the data kept in the server, whereas the XPath approach simply assumes document order, something inherent to the definition of XML and Capabilities.
    - OpenSearch introduces a series of new parameters, XPath has only one.

- generality:
    the XPath proposal likewise can be mapped to any underlying physical representation, but can make use of the structural knowledge.

- implementation:
    XPath engines are readily available, no code modification needed

So wrt expressive power your proposal is inbetween XPath (document-oriented
extraction) and SQL/WCPS/etc (query language).
What I wanted - based on user needs - is not something that makes Capabilities appear a catalog, but to obtain the technical information necessary for finding, recognizing, and binding WCSs. Hence, both proposals address different needs and hence follow different approaches.

So here the use cases:

.    "All WCS Extensions supported by this server"
XPath request:  /Capabilities/ServiceIdentification/Profile/text()
Sample response:
http://www.opengis.net/spec/GMLCOV/1.0/conf/gml-coverage
http://www.opengis.net/spec/GMLJP2/2.0
http://www.opengis.net/spec/WCS_coverage-encoding_geotiff/1.0

.    "All formats supported by this server"
XPath request: 
/Capabilities/ServiceIdentification/ServiceMetadata/formatSupported/text()
Sample response:
    application/netcdf
    image/jp2

.     "Identifiers of all coverages offered"
XPath request: /Capabilities/Contents/CoverageSummary/CoverageId/text()
Sample response:
    NASA_NIGHT_EARTH
    NASA_NIGHT_EARTH_SCALED_SHALLOW_TOPO

.     "spatial extent of coverage X"
XPath request: /Capabilities/OfferedCoverage/coverage[@id="X"]/boundedBy
Sample response (you see the CRS coming along):
<boundedBy>
    <Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326"
        axisLabels="Lat Long" uomLabels="deg deg" srsDimension="2">
        <lowerCorner>
            -179.9933330866212 -0.0133335802515
        </lowerCorner>
        <upperCorner>
            0.0133338271788 359.9933332102485
        </upperCorner>
    </Envelope>
</boundedBy>

.    "Native CRS of coverage X"
XPath request:
/CoverageOfferings/OfferedCoverage/coverage[@id="X"]/boundedBy/Envelope/@srsName
Sample response:
    http://www.opengis.net/def/crs/EPSG/0/4326

Some more:
* "Does this service support REST?"
* "Is there anything ground-level temperature measurement available in
(x0,y0,x1,y1) on this server?"
* "Which version of WCS-T is supported by this server?"

Ahem, so much about thoughts while reading the document.
Sorry for the lengthy reply,
Peter


On 2015-08-06 18:36, 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
>>
>

--
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   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)


_______________________________________________
Requests mailing list
Requests at lists.opengeospatial.org
https://lists.opengeospatial.org/mailman/listinfo/requests



More information about the Requests mailing list