OGC 13-080r3
Copyright © 2013 Open Geospatial Consortium
Page 28
…Leading and trailing zeroes are prohibited subject to the following: number representations must be normalized such that there is a single digit which is non-zero to the left of the decimal point and at least a single digit to the right of the decimal point unless
the value being represented is zero. The canonical representation for zero is 0.0E0.
The following section discusses the next step which is to parse the text representation of the coordinates, convert them into IEEE 754 doubles and insert them into the database.
8.1.3.3 Database Insertion
The standard PostgreSQL JDBC driver was used to populate the database from within Java. This step is where the longitude and latitude are converted to doubles in Java and then to a Point type in the database. This section
will follow a high level discussion of this process, for a detailed example of the process including source code see appendix J.
Essentially, the input to the database insertion code is a string with a latitude followed by a longitude. From the GML Point definition, it is assured that this string should be two valid IEEE 754 doubles with a single space
between them. The single string can now be split into two separate strings, without the space, by calling the String.split“ “ function. Each of these can then be converted to Java doubles with the function
Double.valueOfString.
17
Now the coordinates are actually stored as IEEE 754 doubles in memory. Next the doubles must be prepared to be inserted into the PostGIS database. PostGIS will store the coordinates as
a Point object, or column, in the spatially enabled database table. To achieve this, the coordinates will first be converted to Well Known Text WKT format and then passed into the SQL function
ST_GeomFromTextWKT,EPSG, provided by the PostGIS extension. The ST_GeomFromText function converts a WKT representation of an OGC Point, into the internal binary structure. Again, detailed steps are
shown in annex J. It’s worth noting here that there are obviously multiple ways to insert GML into a PostGIS database. This approach was chosen to make the actual coordinate conversion process as explicit and visible as
possible. Also, while it is not necessary to convert the coordinate values from text into doubles for this simple example, common use-cases might require including this conversion for error-checking, pre-processing,
additional calculations on the coordinates before inserting them into the database.
Once the data is in the database, GeoServer takes the conversion from there. However, reading from the database is not overly complicated. This can be accomplished with PostGIS functions. For example,
ST_AsTextgeometry_column will return the value of a spatial column as WKT. To ensure the returned value has not lost precision, a more direct function is ST_AsBinarygeometry_column which will return the Point as
Well Known Binary. WKB WKB encodes the actual coordinate values as binary IEEE 754 doubles.
Data Types
The Java double is explained in the Java Language Specification Section 4.2.3. http:docs.oracle.comjavasespecsjlsse7htmljls-4.htmljls-4.2.3 The section states:
The floating-point types are float and double, which are conceptually associated with the single-precision 32-bit and double- precision 64-bit format IEEE 754 values and operations as specified in IEEE Standard for Binary Floating-Point Arithmetic,
ANSIIEEE Standard 754-1985.
Point is defined in OGC 06-103r4 Simple Feature Access - Part 1: Common Architecture SFA-CA Section 6.1.4.
Well Known Text WKT is defined in SFA-CA Section 7. An example can be viewed in annex J. Well Known Binary WKB is defined in SFA-CA Section 8. The section states:
17
http:docs.oracle.comjavase6docsapijavalangDouble.htmlvalueOfjava.lang.String
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.
