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

Marten Hogeweg mhogeweg at esri.com
Fri Aug 7 17:24:28 EDT 2015


There's nothing in opensearch that prevents a sophisticated multi-termed query to be submitted to the opensearch provider. Just that is not a strong enough argument to not use opensearch. 

Resolving the problem of large W*S capabilities responses will likely take a combination of a couple approaches: place the information elsewhere and decide how to retrieve it. Indeed consistently across the various service types.



Marten Hogeweg
Esri inc.

> On Aug 7, 2015, at 1:29 PM, Cechini, Matthew F. (GSFC-586.0)[COLUMBUS TECHNOLOGIES AND SERVICES INC] <matthew.f.cechini at nasa.gov> wrote:
> 
> I think Peter’s distinction between OpenSearch catering to human
> interactivity vs xPath catering to machine interactions is important.  In
> both situations, lengthy GetCapability documents present issues.  I’m not
> familiar with the genesis of this topic to know what side of the coin
> started the conversation, but I see value in both xPath and OpenSearch and
> don’t think that one nullifies the need for the other.
> 
> In general, I think the W*S suite of services would benefit from a
> consistent approach to deal with this issue.  I’m more familiar with WMS
> that the others, but I gather that they all need a way to deal with large
> capabilities documents.  Is there a mechanism to derive the
> requirements/approach across those services?  Or perhaps letting WCS blaze
> the trail and provide guidelines to the others.  What I want to avoid is
> each W*S service ending up with a slightly different solution.
> 
> Matt
> 
> .................................................................
> Matthew Cechini
> Contractor, Columbus Technologies & Services
> Systems Engineer
> NASA GSFC / ESDIS Project Code 423
> 410.205.6272(NASA)
> 
> Note:  I am not a government employee and have no legal authority to
> obligate any federal, state, or local government to perform any action or
> payment.
> 
> 
> 
> 
> 
> 
> On 8/7/15, 1:20 AM, "Requests on behalf of Peter Baumann"
> <requests-bounces+matthew.f.cechini=nasa.gov at lists.opengeospatial.org on
> behalf of p.baumann at jacobs-university.de> wrote:
> 
>> 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/@s
>> rsName
>> 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/12390750098
>>>> 7669?v=app_4949752878>
>>>>    | Google+
>>>> 
>>>> 
>>>> <https://plus.google.com/b/114389770462919844434/114389770462919844434/p
>>>> osts> |
>>>>    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
> 
> _______________________________________________
> Requests mailing list
> Requests at lists.opengeospatial.org
> https://lists.opengeospatial.org/mailman/listinfo/requests


More information about the Requests mailing list