OGC 13-080r3
Copyright © 2013 Open Geospatial Consortium
Page 29
The Well-known Binary Representation for Geometry is obtained by serializing a geometric object as a sequence of numeric types drawn from the set {Unsigned Integer, Double} and then serializing each numeric type as a sequence of bytes using one of
two well defined, standard, binary representations for numeric types NDR, XDR… …
A Double is a 64-bit 8-byte double precision datatype that encodes a double precision number using the IEEE754 double precision format.
The above definitions are common to both XDR and NDR.
More information on the functions ST_GeomFromText, ST_AsText and ST_AsBinary can be found in OGC 05- 134 Simple feature access - Part 2: SQL option SFA-SQL and ISOIEC CD 13249-3:2006E – Text for FDIS
Ballot Information technology – Database languages – SQL Multimedia and Application Packages — Part 3: Spatial, May 15, 2006. SQLMM
8.2 Data Delivery Services
The two primary outputs used in MOGIE were GML via WFS and KML via WMS. This section explains the interaction between the client and server for both output types.
8.2.1 WFS and GML
WFS has many components and supports multiple formats. It is outside the scope of this document to thoroughly describe them all. Therefore, this section describes the components of WFS used by MOGIE and the resulting
GML output.
As with all OWS compliant services, there is an initial negotiation phase that begins with the client application requesting a capabilities document. While the structure of these XML documents varies from service to service,
their general function is the same, they provide the client with the necessary knowledge to query the services provided. Figure 21 illustrates this process.
The first arrow shows the client issuing a GetCapabilities request to the server. This initial request typically takes the form of a HTTP GET call. This is the type of call made by a web browser when a
URL is entered into the browser address bar. To construct the GetCapabilities request, one starts with a base address, in the case of MOGIE: http:falconservices.icl.gtri.org:8080geoserverows?. The
question mark at the end indicates the beginning of parameters to follow. The two required parameters, in this case, are service and request. Setting service=WFS and request=GetCapabilities tells the server
to return the capabilities XML document for its WFS service. The final request URL looks like this:
http:falconservices.icl.gtri.org:8080geoserverows?service=WFSrequest=GetCapabilities .
The second arrow shows the server responding with the capabilities document. This document can be quite complex, depending on the server’s capabilities. The figure shows parts we will focus on for the
purposes of MOGIE. o
The first and second elements shown, collapsed, are GetFeature and DescribeFeatureType Operations. They will be discussed later but generally tell the client how to actually make
those requests.
o The third element shown, expanded, is the FeatureType of interest, latest_vessel_position. This
tells the client only basic information about the feature, including its name, prefixed with its namespace, and the geographic bounding box to which the spatial data is constrained. Now the
client has enough information to query the service further, as shown next.
The third arrow shows the client requesting more detailed information about the latest_vessel_position FeatureType listed in the capabilities document. It does this using the DescribeFeatureType request. By
setting the request=DescribeFeatureType and the typeName=mogiemaritime:latest_vessel_position, the client is asking the server for the data structure of latest_vessel_position.
OGC 13-080r3
Copyright © 2013 Open Geospatial Consortium
Page 30
The final arrow shows the server responding with the GML application schema of latest_vessel_position. The client now knows exactly what to expect when it actually receives the
requested data. Note: part of the XML is collapsed to save space The information contained here includes the field names and types, which will be used, among other things, for filtering the data in
subsequent requests. The schema itself can also be used to validate the actual Features when retrieved.
Figure 21: Data Retrieval Process from WFS Figure 22 shows the process to retrieve the actual data from the WFS.
The first arrow shows the client issuing a GetFeature request for the latest_vessel_position GML data. This is the simplest form of the GetFeature request. A more complex GetFeature request could include
spatial, temporal, numeric, etc. filters to limit the returned data. The second arrow shows the server responding with the GML Feature data. It should be noted,
GeoServer supports multiple output data types, not just GML. If one preferred the returned data to be in Comma Separated Values CSV format, they could set outputFormat=csv in the GetFeature request.
However, by not including that parameter, GML is returned by default.
OGC 13-080r3
Copyright © 2013 Open Geospatial Consortium
Page 31
Figure 22: Process to retrieve data from the WFS The basic process of discovering and retrieving data via WFS has been shown. However, WFS has many
capabilities, some of which were enabled but not used in the end. For example, data can be inserted, modified and deleted all with WFS operations similar to those shown above. The developer tested these operations,
initially, in case they found a use as the experiment evolved. While they did not, it should be noted to GeoServer’s credit, that they did function correctly.
8.2.2 WMS and KML
