[GeoSciML] TR: OGC Request Submitted (QuantityRange and GeoSciML v3.2)

Boisvert, Eric Eric.Boisvert at RNCan-NRCan.gc.ca
Wed Jul 3 10:29:34 EDT 2013


FYI
-----Message d'origine-----
De : portaladmin at opengeospatial.org [mailto:portaladmin at opengeospatial.org] 
Envoyé : 3 juillet 2013 10:28
À : Boisvert, Eric
Objet : OGC Request Submitted

Dear Eric Boisvert:

The Request "Add FES friendly encoding to Range data types" has been submitted to OGC for review.

Once this submission has been deemed appropriate, the Technical Committee Chair (TCC) will assign the Request to the appropriate OGC Committee, Domain Working Group or Standards Working Group. All Requests are public and will be made available on the OGC Website.

For your reference the Request ID is: 304.

Spec:  SWE Common Data Model Encoding Standard
SpecID:  450
Specversion:  2.0
DocNum:  08-094r1
Num:  
Rev:  
Title:  Add FES friendly encoding to Range data types
Source:  GeoSciML SWG
Workitem:  
Category:  B
Reason:  Certain GeoSciML use cases require filtering on the lower ofr upper value of a QuantityRange (eg, select geologic units where proportion of sandstone > 50 %).  Proportions are encoded with swe:QuantityRange and therefore the filter expression must identify the first or second term of a value encoded using a swe:RealPair 

(eg. <swe:value>45 65</swe:value>, we need to filter in on the first element of the list)

Unfortunately , FES (Filter Encoding Standard) does not provide a mechanism to “parse” the content of a RealPair nor does minimum XPath (OGC 09-026r1, clause 7.4.4) hasve a syntax to identify a specific element. The only solution within the current specification is to implement a server side function or an extended XPath support, neither being practical or likely.  We therefore need a range encoding that is within reach of a FES expression

Summary:  To each Range data type (CategoryRange, CountRange,QuantityRange and TimeRange), add an alternate encoding where each of the elements of the range will have an explicit property name (eg, lowerValue and upperValue). 

 We propose the following property names CategoryRange : lowerToken, upperToken CountRange : lowerCount, upperCount QuantityRange : lowerValiue, upperValue TimeRange : lowerTime, upperTime

Consequences:  Failure to achieve important use case in GeoSciML (and probably other that uses SWE Comm,on) that need to filter on either element of ranges.  Future versions of GeoSciML will most likely abandon the use of at least the swe:QuantityRange element.
Clauses:   7.2.10 to 7.2.7.2.14, 8.1.9 to 8.1.12
Otherdocs:  
Documentation:  
Comments:  We did not make an exhaustive review of SWE Common to identify other potential encoding that could not be used by FES.


Again, thank you for your submission.




More information about the GeoSciML mailing list