OGR WCTS Implementation Details

Methods Implemented

GetCapabilities

The returned capabilities document is taken from static document provided by the installer, it is not actually machine generated at all. In particular the list of supported coordinate systems is not machine generated.

IsTransformable

The geometric primite type, coverage type, and coverage interpolation method parameters are currently ignored.

Transform

It is apparently legal to submit key/value pair requests with remotely referred to, or url encoded GML data but there are no examples of how this would be done so it has not been implemented at this time.

The transformation sequence (gml:_CoordinateOperation) argument is unsupported and ignored.

The data argument may be a GML instance document, or a FileURL referencing a remote document which may be fetched using HTTP GET. It may not be a wcts:RemoteOWS element for doing operations against a remote WFS instance. How this actually works is not currently well defined in the WCTS document.

DescribeTransformation

Coordinate Systems Supported

Converting between different datums is only supported for some coordinate systems for which a single 3 or 7 parameter datum transformation to WGS84 exists in the EPSG database. Other datums for which multiple transformations 3 or 7 parameter transformations are defined, or for which no such transformations are available are not able to be converted to other datums. One exception is NAD27 and NAD83. NAD83 is considered equivelent to WGS84. NAD27 is handled specially using grid shift files for the area of Canada and the United States (either NTv2, NTv1, or NADCON grid shift information is used depending on the location being transformed, and the configuration of the server.

Coordinate systems based on datum that cannot be related to WGS84 can still be trasformed to other coordinate systems based on the same datum.

Supported EPSG projections

Unsupported EPSG Projections

User Defined CRSes

Implementation Strategy

1. All XML handling is done using the CPL MiniXML parser. This is a simple well formed XML parser but it does not treat the whole XML standard properly. It is likely to fail dramatically if given files in other than 8bit codes spaces (ie. UTF-8), and there may well be esoteric XML constructions that will not be parsed properly by it.

2. In order to transform GML geometries, the server walks the <data> subtree searching for elements recognisable as GML geometries. The rules to recognise GML geometries are basically to strip any namespace value off an element name, and compare to the simple feature GML elements (such as Polygon, LineString, Point, Box, GeometryCollection, MultiPoint, MultiLineString or MultiPolygon. Problems may be encountered if non-geometries (marked as being from non-gml names spaces) are incorrectly identified as being geometries. Alternate names for geometries (established by derivation in application schemas) are not supported.

   A good aspect of the above approach is that there is no need to understand the application schema of the gml features passed to the server.

3. Once recognised GML geometry elements are transformed into OGRGeometry's, transformed, and converted back into GML to substitute "inplace" in the file. This process will drop any attributes of the geometries, such as srsName, and will produce new gml with the gml: namespace prefix regardless of what namespace may have been in place originally. Resulting geometries are converted back to GML using a %.16g C format string preserving double precision accuracy, but potentially implying far more precision that is meaningful depending on the precision of the original points.

4. When the <FileURL> data item is found, the URL is resolved and the resulting document is substituted in the place of the original FileURL in the transformation request. At this point a special step is done to try and remove any <?xml> line to avoid confusing the XML/GML parsing. However, other constructions, such as a DOCTYPE declaration might well foul things up.

5. Currently SourceCRS and TargetCRS definitions are supported well supported by <crsID> as well as a more limited form of user defined coordinate system. The user defined coordinate system support is experimental and will not be further discussed here for now.

   Those defined via <crsID> will be inspected for a code, and codeSpace element. The codeSpace must be EPSG, and the code will be lookuped up in the EPSG 6.2.2 .csv files using the OGRSpatialReference:ImportFromEPSG() method.

6. Internally all coordinate transformations are accomplished using the OGRCoordinateTransformation class which in turns converts the coordinate system definitions into PROJ.4 format, and uses the PROJ.4 pj_transform() function to transform the points. This supports reprojection, change of ellipsoid, change of datum (sometimes), and change of prime meridian.

OGR WCTS Security Audit

1. libcurl (not checked) - all URLs other than http, https and ftp have been disabled to avoid issues with less known protocols.
2. CPLTokenize() support for parsing QUERY_STRING. (checked)
3. OGR GML Geometry reading and writing services. (checked)
4. OGR GML CRS reading and writing services. (not checked)
5. cpl_minixml.cpp parsing and serializing services (checked)
6. cpl_string escaping logic, and stringlist handling (checked)

This security audit was primarily directed to discovering buffer overrun issues possible with user input. Several isses were discovered and corrected though it isn't clear if they could have been externally utilized to gain control as each of them related only to buffer overruns within the heap (not on the stack).

A review of the overall architectural approach of the server identified only the issue with use of libcurl to access user supplied URLs. With this disabled no vulnerability remains.

The initial security audit was completed by Frank Warmerdam. An independent audit is underway by Andrey Kiselev.

Other Notes

1. The server does not do any schema validation, but does require input XML documents to be well formed.

2. Input SourceCRS and TargetCRS elements must have a crsID element with a gml:code that is the EPSG code of the coordinate system, and a gml:codeSpace that is EPSG.

3. Version and Service parameters are never checked.

4. The server handles bounding box (boundedBy properties in GML) specially. It transforms the box into a polygon, transforms that and then regenerates a box based on the mimimum bounding box of that polygon. While better than just transforming the two corner coordinates of the bounding box, it is not generally going to produce a minimal bounding box for the features in question in the target coordinate systems. In fact, depending on the nature of the transformation (bowing out of a side for instance) the resulting box may not even quite contain all the transformed feature.

5. The current GML geometry handling in OGR does not support tuple separators other than " " or ordinate separators other than ",".