<html> <head> <title>OGR WCTS Implementation Details</title> </head> <body> <h1>OGR WCTS Implementation Details</h1> <h2>Methods Implemented</h2> The OGR WCTS server implements the <b>GetCapabilities</b>, <b>IsTransformable</b> and <b>Transform</b> server options (REQUEST= values). In all operation cases only VERSION 0.1.0 is currently supported.<p> <h3>GetCapabilities</h3> The <b>GetCapabilities</b> operation is supported as an XML request submitted using the HTTP POST mechanism, or as a key/value pair request submitted using the HTTP GET mechanism.<p> 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.<p> <h3>IsTransformable</h3> The <b>IsTransformable</b> operation is supported as an XML request submitted using the HTTP POST mechanism, or as a key/value pair request submitted using the HTTP GET mechanism.<p> The geometric primite type, coverage type, and coverage interpolation method parameters are currently ignored. <p> <h3>Transform</h3> The <b>Transform</b> operation is only supported as an XML request submitted using the HTTP POST mechanism.<p> 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.<p> The transformation sequence (gml:_CoordinateOperation) argument is unsupported and ignored.<p> 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. <p> <h3>DescribeTransformation</h3> The <b>DescribeTransformation</b> operation is not supported by the server at all at this time.<p> <h2>Coordinate Systems Supported</h2> Currently the server supports all EPSG 6.2.2 2D geographic coordinate systems and projected coordinate systems based on supported projections.<p> 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.<p> Coordinate systems based on datum that cannot be related to WGS84 can still be trasformed to other coordinate systems based on the same datum.<P> <h3>Supported EPSG projections</h3> <table border> <th>EPSG Code<th>Name<th>Comments<tr> <td>9801<td>Lambert Conic Conformal (1SP) <td><tr><td>9802<td>Lambert Conic Conformal (2SP) <td><tr><td>9803<td>Lambert Conic Conformal (2SP Belgium) <td>(treated same as 9802) <tr><td>9804<td>Mercator (1SP) <td><tr><td>9805<td>Mercator (2SP) <td><tr><td>9806<td>Cassini-Soldner <td><tr><td>9807<td>Transverse Mercator <td><tr><td>9809<td>Oblique Stereographic <td><tr><td>9810<td>Polar Stereographic <td><tr><td>9811<td>New Zealand Map Grid <td><tr><td>9812<td>Hotine Oblique Mercator <td><tr><td>9813<td>Laborde Oblique Mercator<td>(treated same as 9813) <tr><td>9815<td>Oblique Mercator <td><tr><td>9819<td>Krovak Oblique Conic Conformal <td><tr><td>9820<td>Lambert Azimuthal Equal Area <td><tr><td>9822<td>Albers Equal Area <td><tr><td>9823<td>Equidistant Cylindrical </table> <h3>Unsupported EPSG Projections</h3> <table border> <th>EPSG Code<th>Name<th>Comments<tr> <td>9808<td>Transverse Mercator (South Orientated) <td><tr><td>9814<td>Swiss Oblique Cylindrical <td><tr><td>9816<td>Tunisia Mining Grid <td><tr><td>9817<td>Lambert Conic Near-Conformal <td><tr><td>9818<td>American Polyconic <td><tr><td>9821<td>Lambert Azimuthal Equal Area (Spherical) <td><tr><td>9824<td>Transverse Mercator Zoned Grid System <td><tr><td>9825<td>Pseudo Plate Carree <td><tr><td>9826<td>Lambert Conic Conformal (West Orientated) <td><tr><td>9827<td>Bonne <td><tr><td>9828<td>Bonne (South Orientated) </table> <h2>User Defined CRSes</h2> The server has prototype support for coordinate systems described using the pre-approval 03-010r2 GML CRS schemas. Details of this implementation are evolving. Contact the author for sample requests that work at this time.<p> <h2>Implementation Strategy</h2> This section is intended to explain a bit about how the internals of this server are implemented to better understand likely strengths and weaknesses of the server.<p> <ol> <li> All XML handling is done using the <b>CPL MiniXML</b> 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. <p> <li> 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 <b>Polygon, LineString, Point, Box, GeometryCollection, MultiPoint, MultiLineString </b> or <b>MultiPolygon</b>. 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.<p> 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.<p> <li> 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.<p> <li> 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.<p> <li> 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.<p> 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. <p> <li> 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.<P> </ol> <h2><a name="audit">OGR WCTS Security Audit</a></h2> A security audit of the OGR WCTS server was completed on 2003/03/29. In addition to a careful inspection of the code in the ogrwcts.cpp module, the following components were also addressed: <P> <ol> <li> libcurl (not checked) - all URLs other than http, https and ftp have been disabled to avoid issues with less known protocols. <li> CPLTokenize() support for parsing QUERY_STRING. (checked) <li> OGR GML Geometry reading and writing services. (checked) <li> OGR GML CRS reading and writing services. (not checked) <li> cpl_minixml.cpp parsing and serializing services (checked) <li> cpl_string escaping logic, and stringlist handling (checked) </ol> The conclusion is that the <b>ogrwcts</b> is safe for use where it may potentially be given input by hostile parties as long as user defined CRS support is disabled. The user defined CRS code is in flux, so any audit will be rapidly outdated. Disabling user defined CRSes may be accomplished by compiling with DISABLE_USER_DEFINED_CRS defined in the GNUmakefile (the default).<p> 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).<p> 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.<p> The initial security audit was completed by Frank Warmerdam. An independent audit is underway by Andrey Kiselev.<p> <h2>Other Notes</h2> <ol> <li> The server does not do any schema validation, but does require input XML documents to be well formed. <p> <li> Input SourceCRS and TargetCRS elements must have a <b>crsID</b> element with a <b>gml:code</b> that is the EPSG code of the coordinate system, and a <b>gml:codeSpace</b> that is <b>EPSG</b>.<p> <li> Version and Service parameters are never checked.<p> <li> 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.<p> <li> The current GML geometry handling in OGR does not support tuple separators other than " " or ordinate separators other than ",".<p> </ol> </body> </html>
