Enabling automated Unit of Measure Conversion

108 Copyright © 2011 Open Geospatial Consortium, Inc. All Rights Reserved. fes:PropertyIsGreaterThanOrEqualTo fes:ValueReference aixm:Runwayaixm:timeSliceaixm:lengthStrip fes: ValueReference fes:Literal gml:measure uom = m 3000 gml:measure fes:Literal fes:PropertyIsGreaterThanOrEqualTo Note 1: the Sensor Event Service OGC 08-133 introduced a similar way to perform UoM conversion. The difference there was that the comparison literal includes an element of the GML ScalarValue group, i.e. a gml:Boolean, gml:Count, gml:Category or gml:Quantity - the latter of which is of type gml:MeasureType and thus has the uom attribute attached to it. This approach allows even more explicit indication of the type that the Literal is given in. The “type” attribute that can be added to an fes:Literal could be used to indicate the type of the fes:Literal content. This is useful for primitive content, such as a boolean value in which case the type attribute could be set to “xs:boolean” but not so useful for element content where the element usually follows a global element definition. Note 2: The discussion how to represent the UoM of a comparison value also included discussion of the case that the UoM is given in. It was suggested to set the “matchCase” parameter of a comparison operator to false in order to ensure that the request is fulfilled regardless of whether the UoM is defined as, for example, ‘M or m. However, discussion of this revealed issues with this approach. Sticking to the example where meter is the UoM, Mm megameter and mm millimeter both use case sensitive UCUM symbols s second vs. S Siemens is another example without prefixes. The same with case insensitive symbols see UCUM for further details would be MAM and MM with mAm, mam, Mam etc and mM, Mm, mm being equivalents because of case insensitivity. Ignoring case would be dangerous when case sensitive symbols are used - one would compare otherwise incompatible uoms or confuse their actual value by misinterpreting the prefix. If a domain chooses to use only case sensitive uoms, then this needs to be clearly documented. GML does not seem to restrict case sensitivity on the UomSymbol type. As UCUM states, the use of case insensitive symbols may be the greatest common denominator. Now that the various ways to provide the UoM for feature property and comparison value have been discussed, we need to identify the different situations in which UoM conversion can or cannot be performed: UoM in feature property known either constant, explicitly provided or known to be given in base units UoM in comparison value known either constant [if known for the feature type of the referenced value], explicitly provided or known to be given in base units UoM conversion possible yes yes yes Copyright © 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 109 yes no no no yes no no no no Automatic UoM conversion can only be performed if the UoM for both the feature property value and the comparison value is known. Otherwise, the service would need to resort to perform direct number comparison.

10.3.3 Conclusion

Automated UoM conversion as described in this section would improve the filter capabilities of OGC Web Services. Especially when the UoM of a feature property is not constant, the mechanism helps to perform meaningful comparison operations. Eventually, the mechanism should be integrated in or become an extension of the OGC Filter Encoding Specification. The discussion performed in OWS-8 on this topic did not cover all relevant aspects. A proper specification of automated UoM conversion would need to define: how to identify UoMs of both the feature property targeted by a comparison operator and the comparison value itself - this has been discussed in OWS-8 see previous section the behavior in case that UoM conversion is not possible - this was not discussed during the testbed how to advertise that the service supports UoM conversion and which UoM definitions it understands - this was also not discussed during the testbed, but the SES OGC 08-133 has some information on this that may be useful essentially, the filter capabilities are extended to indicate UoM conversion capabilities how to handle precision errors in comparison operations caused by value conversion - rounding errors may be introduced through the conversion process, which may or may not be relevant for a given application; this was not discussed during the testbed how case sensitivity of UoM symbols is handled - this has been discussed to a certain extent see previous section 11 Scenarios Several realistic scenarios were developed for the OWS-8 Aviation thread. The demonstration of the OWS-8 Aviation thread was inspired by these scenarios – detailed scenario information is provided in chapter 0. The scenarios provided a fictitious but realistic context for testing the developed functionality. They prompted the exercising of interfaces, components, tools and services as well as the use of encodings. This includes exercising a variety of web services 110 Copyright © 2011 Open Geospatial Consortium, Inc. All Rights Reserved. utilizing AIXM and WXXM encodings including digital NOTAMs, information about field conditions and relevant meteorological information.