[SensorWeb DWG] Add FES friendly encoding to Range data types
All Fields marked with * are mandatory.
Change Request 304
#:
Assigned OGC 13-075
Document #:
Name: *Eric Boisvert
Organization: *Natural Resources Canada
Email: *eboisver@nrcan.gc.ca
Document
Name/Version:
*SWE Common Data Model Encoding Standard / 2.0
OGC Project
Document:
*08-094r1
If this is a revision of a previous submission and you have a Change Request Number, then check here:
Enter the CR number here:
Enter the Revsion Number that you are revising here:
Title:
Source:
*
Add FES friendly encoding to Range data types
*GeoSciML SWG
Work item code:
Category:
*
B (Addition of feature)
Reason for *
change:
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. 45 65, 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 of *
change:
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 if Failure to achieve important use case in GeoSciML (and probably other
that uses SWE Comm,on) that need to filter on either element of
not approved:
ranges. Future versions of GeoSciML will most likely abandon the use
of at least the swe:QuantityRange element.
Clauses affected: *
7.2.10 to 7.2.7.2.14, 8.1.9 to 8.1.12
Additional
Documents
affected:
Supporting
Documentation:
Comments:
Status:
Assigned To:
Disposition:
We did not make an exhaustive review of SWE Common to identify other
potential encoding that could not be used by FES.
Assigned
SensorWeb DWG
Referred
Change Request 304
#:
Assigned OGC 13-075
Document #:
Name: *Eric Boisvert
Organization: *Natural Resources Canada
Email: *eboisver@nrcan.gc.ca
Document
Name/Version:
*SWE Common Data Model Encoding Standard / 2.0
OGC Project
Document:
*08-094r1
If this is a revision of a previous submission and you have a Change Request Number, then check here:
Enter the CR number here:
Enter the Revsion Number that you are revising here:
Title:
Source:
*
Add FES friendly encoding to Range data types
*GeoSciML SWG
Work item code:
Category:
*
B (Addition of feature)
Reason for *
change:
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. 45 65, 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 of *
change:
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 if Failure to achieve important use case in GeoSciML (and probably other
that uses SWE Comm,on) that need to filter on either element of
not approved:
ranges. Future versions of GeoSciML will most likely abandon the use
of at least the swe:QuantityRange element.
Clauses affected: *
7.2.10 to 7.2.7.2.14, 8.1.9 to 8.1.12
Additional
Documents
affected:
Supporting
Documentation:
Comments:
Status:
Assigned To:
Disposition:
We did not make an exhaustive review of SWE Common to identify other
potential encoding that could not be used by FES.
Assigned
SensorWeb DWG
Referred