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

Lorenzo Bigagli lorenzo.bigagli at cnr.it
Sun Aug 9 05:20:20 EDT 2015


Hi Peter, all,

I chime in with a comment from the PubSub work. Also in that context, we had a requirement to support “querying” the capabilities document. As a practical solution, we have sketched a “Capabilities Filtering” requirement class adding a few parameters to the GetCapabilities request (see the PubSub Core draft).

However, we concur that a more general mechanism would be desirable; we left a comment to the OAB to consider whether such functionality should be given a Commons status.
Personally, I like the XPath idea quite much.

Best,
  Lorenzo

> Il giorno 08/ago/2015, alle ore 09:55, Peter Baumann <p.baumann at jacobs-university.de> ha scritto:
> 
> You are right, Marten - I did not want to see this as a general statement, my
> fingers just typed what the eyes saw.
> 
> And I couldn't agree more on consistency. However, I am talking to people since
> a couple of years now. Most people find it somehow interesting, but nothing
> happens. As we direly need this in WCS I have done the spec now (actually,
> brushed it up - it's on my PC already since a year).
> 
> There is quite some time to be spent with OAB, RFC, vote - maybe a good
> discussion like this makes OWS Common adopt it in the meantime, too. I'm ready
> for discussion.
> 
> -Peter
> 
> 
> 
> On 2015-08-07 23:24, Marten Hogeweg wrote:
>> 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
> 
> -- 
> 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

---
Lorenzo Bigagli, Ph.D.
National Research Council of Italy
Institute of Atmospheric Pollution Research (CNR-IIA)
Earth and Space Science Informatics Laboratory (ESSI-Lab)

a: Area della Ricerca di Firenze
   Via Madonna del Piano 10
   50019 Sesto Fiorentino (FI), Italia
t: +39 055 5226582
m: lorenzo.bigagli at cnr.it
m: l.bigagli at iia.cnr.it






-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1940 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20150809/cd1fb79b/attachment.bin>


More information about the Requests mailing list