SOAP, WSDL and WPS are specifications for Web service interfaces, ensuring services describe their operations, inputs, outputs in the same way, and communicate using standard machine-to- machine protocols. They make no assumptions about the types of data used for inputs and outputs, allowing for an infinite amount of possible data types. We can restrict these data types to a limited, specific set by adopting standards for data encoding. Many data encoding standards exist, with the OGC defining GML and O&M, for encoding geospatial primitives and observations respectively. Also of note is UncertML for encoding various representations of probabilistic uncertainty.
GML
Geography Markup Language (GML) is an XML encoding standard for the description and trans- port of geographical information (OGC 07-036, 2007). GML contains an extensive set of types, including those for representing geometries such as points (Listing 2.7), lines, and polygons, time, units of measure and coordinate reference systems. These elements are commonly used as primi- tives in an application schema — containing definitions of object types specific to the domain of interest. For example, an application schema for city planning may define objects for roads, rivers, railways, and buildings. The standard has been widely implemented, and is adopted by all OGC specifications.
<gml:Point gml:id="point" xmlns:gml="http://www.opengis.net/gml/3.2" srsName="http: //www.opengis.net/def/crs/EPSG/0/27700">
<gml:pos>216521.28107019 771211.422979205</gml:pos> </gml:Point>
Listing 2.7: A GML document representing a point.
O&M
Observations & Measurements (O&M) is a conceptual model and corresponding XML implemen- tation for exchanging information describing observations (OGC 07-022r1, 2007). An observation is defined as an event which produces a value for an observed phenomenon at a specific point in time — whether that be the current air temperature, or the size of a field. The conceptual model aims to represent not only the resulting value, but additional information about the observation, and contains the following elements:
resultTime is the time the procedure was performed;
observedProperty describes the phenomenon for which the result is an estimated value of; phenomenonTime is the time the phenomenon occurred;
featureOfInterest represents the real-world subject of the observation; result is the value produced by the procedure.
O&M documents typically import elements from GML to represent time instants, time periods, and feature of interest geometries. Listing 2.8 gives an example O&M observation, where the feature of interest is located at the same point represented in Listing 2.7. A scalar result is shown in this example, but the result of an observation is unrestricted in type, making O&M appropriate in a wealth of use cases (OGC 07-041r1, 2007; Raape et al., 2010). Whilst enabling a wide array of usage opportunities, such genericity can create interoperability issues, as a client or service will not simply be able to advertise support for O&M, as in reality they can only support a very small subset of results.
UncertML
Uncertainty Markup Language (UncertML) is a conceptual model, dictionary and encoding spec- ification that can be used to convey probabilistic representations of uncertainty in an interoperable manner. A range of uncertainty types are supported by UncertML, from simple summary statistics such as mean and variance, to multivariate distributions and random samples. When dealing with uncertain observations, the generic nature of O&M allows us to use UncertML as the result in favour of a single scalar value.
UncertML was originally developed as a weakly typed language, where technically any type of statistic, distribution, or realisation could be encoded. This approach involves the use of gener- ically named elements with the exact types specified with an attribute, which links to a dictionary definition (OGC 08-122r2, 2007), and allows flexibility at the cost of usability. The weakly typed design allows a user to reference their own uncertainty types, and does not encourage the use of a shared dictionary. This poses a major problem for interoperability, as this could lead to the use of multiple definitions for well-known types, such as the normal distribution or variance. If the defi- nitions of two types do not match, they will be treated as different representations of uncertainty.
<om:OM_Measurement gml:id="measurement" xmlns:om="http://www.opengis.net/om/2.0"
xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xlink="http://www.w3.org/1999/ xlink" xmlns:sams="http://www.opengis.net/samplingSpatial/2.0" xmlns:sa="http:// www.opengis.net/sampling/2.0">
<om:type xlink:href="http://www.opengis.net/def/observationType/OGC-OM/2.0/ OM_Measurement"/>
<om:phenomenonTime>
<gml:TimeInstant gml:id="time">
<gml:timePosition>2012-01-01T00:00:00.000Z</gml:timePosition> </gml:TimeInstant>
</om:phenomenonTime>
<om:resultTime xlink:href="#time"/> <om:procedure xlink:href="field_sample"/> <om:observedProperty xlink:href="area"/> <om:featureOfInterest>
<sams:SF_SpatialSamplingFeature gml:id="feature">
<gml:identifier codeSpace="http://www.uncertweb.org">1</gml:identifier>
<sa:type xlink:href="http://www.opengis.net/def/samplingFeatureType/OGC-OM/2.0 /SF_SamplingSurface"/>
<sa:sampledFeature xsi:nil="true"/> <sams:shape>
<gml:Point gml:id="point" srsName="http://www.opengis.net/def/crs/EPSG /0/27700"> <gml:pos>216521.28107019 771211.422979205</gml:pos> </gml:Point> </sams:shape> </sams:SF_SpatialSamplingFeature> </om:featureOfInterest>
<om:result uom="m2">219726.98216837645</om:result> </om:OM_Measurement>
Listing 2.8: An O&M Measurement representing the area of a field.
<!-- UncertML version 1 -->
<un:Distribution xmlns:un="http://www.uncertml.org" definition="http:// dictionary.uncertml.org/distributions/gaussian">
<un:parameters>
<un:Parameter definition="http://dictionary.uncertml.org/distributions/ gaussian/mean">
<un:value>28.62</un:value> </un:Parameter>
<un:Parameter definition="http://dictionary.uncertml.org/distributions/ gaussian/variance"> <un:value>2.49</un:value> </un:Parameter> </un:parameters> </un:Distribution> <!-- UncertML version 2 -->
<un:NormalDistribution xmlns:un="http://www.uncertml.org/2.0"> <un:mean>28.62</un:mean>
<un:variance>2.49</un:variance> </un:NormalDistribution>
2010). While it is now restricted to a finite set of uncertainty representations defined by the au- thors, usability has increased substantially as a result, as seen by comparing two versions of the same normal distribution (Listing 2.9). The common dictionary has been made available through the UncertML Web site.
JSON
With universal support in browsers, JavaScript is the client-side language of the Web. The lan- guage is essential for building powerful Web applications — those which only require a browser to run. A growing trend towards Web applications has fostered JavaScript Object Notation (JSON) as an alternative data interchange format to XML. JSON is based on a subset of the JavaScript programming language, and can be natively parsed into JavaScript objects. In contrast, XML re- quires specific parsers for each XML-based language, requiring greater implementation cost for a Web application developer over JSON.
{ "type": "Point", "coordinates": [216521.28107019, 771211.422979205], "crs": { "type": "name", "properties": { "name": "http://www.opengis.net/def/crs/EPSG/0/27700" } } }
Listing 2.10: A geospatial point represented as a GeoJSON object.
JSON is built on two structures: an object, a collection of key/value pairs, and an array, an ordered list of values. The values in an object or array can be other objects or arrays, strings, numbers, boolean and null values. As objects and arrays map logically to typical programming language structures, the benefits of JSON are not limited to the JavaScript language. Listing 2.10 demonstrates the use of objects, arrays, and values to represent a geospatial point.
Popular social networking sites Twitter and Foursquare both deprecated parts of their XML APIs in late 2000, signifying the preference for JSON over XML for such Web applications. The geospatial domain has also made a move to adopt JSON, with the creation of several application and domain specific formats. GeoJSON is an open format for geometry and feature description, and shares much in common with the basic GML elements. Support for GeoJSON is widespread, with Web-based mapping libraries such as OpenLayers and Leaflet both able to import geometries and features encoded as GeoJSON. Although primarily XML-based formats, JSON encodings for
O&M and UncertML have recently been developed (Gerharz et al., 2011; Cornford and Williams, 2011).