Open Geospatial Consortium
OGC Doc 08-152
CR-Form-v3
CHANGE REQUEST
GML CR 08-152
rev-
Current version: 3.2.1 For
HELP
on using this form, see bottom of this page or look at the pop-up text over the symbols.Proposed change affects: AS X Imp Spec X Best Practices Paper Other
Title: GML TIN Support
Source: Paul Scarponcini
Work item code: Date: September 16, 2008
Category: C
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can be found in the TC Policies and Procedures.
Reason for change: Current TIN encoding is inadequate and overly verbose.
Summary of change: Add TIN elements, simplify triangle encoding, support engineering “by-reference” encoding
Consequences if
not approved: Jeopardizes harmonization with SQL and civil engineering/geospatial interoperability
Clauses affected:
Other specs X Other core specifications Simple Feature Common Architecture, SQL Option
Affected: X Abstract specifications Geometry Best Practices Document
Supporting Doc.
Other comments:
Status
GML TIN Support 08-152
The current support for Triangulated Irregular Networks (TIN) in GML is consistent with the OGC Geometry Abstract Specification, ISO IS 19107:2003 Spatial schema and the OGC Simple Feature Common Architecture. The OGC Simple Feature SQL Option profiles SQL/MM Part 3: Spatial for geometry types implemented as SQL abstract data types, including TINs though they have yet to be included in SQL/MM.
In developing the change proposal to add TINs to SQL/MM it has become apparent that GML and 19107 are inadequate. This is especially apparent when considering civil engineering needs in harmony with geospatial concerns.
Three areas of concern are herein raised.
1) Need for more robust set of “TIN elements”.
A TIN is comprised of a polyhedral surface composed of triangularly shaped polygons. These triangles are created by triangulating a set of known point 3D locations following an algorithm such as Delaunay triangulation. After initial triangulation based only on points, additional constraints (TIN elements) can be added to the surface and triangles can be modified accordingly. Currently, GML and 19107 only support stop line and breakline element types. Additional element types are needed to support civil engineering practice (e.g., site application software, LandXML, etc.), especially when supporting huge surfaces (millions of points and triangles). This should be done in conjunction with updates to 19107 and the Abstract Model to insure a consistent approach across all implementations (GML and SQL).
Breaklines are supported but the special case of a breakline with a constant elevation (a control contour) is not.
Stop lines are supported but are of limited applicability when a large number of triangles need to be voided.
The is no support for the three distinct types of void boundaries (void, drape void, and break void) supported by many civil application packages and LandXML.
2) Need for a simpler triangle encoding
Currently, GML and 19107 have Triangle as a subtype of Polygon, constrained to four points but inheriting the possibility of one or more interior boundaries. With striping, this is a concern since it is necessary to explicitly state that the points that comprise the exterior boundary are in fact part of the exterior boundary. A simpler encoding would reduce the number of points to three and would prevent interior boundaries, eliminating the additional exterior ring stripe. If there are those who still want to allow for a triangle with holes, either they can implement it as a Polygon or else we can have the hole-less one be of type TIN_Triangle. This may be an encoding issue without requiring a change to the Abstract Model or 19107.
3) Need for a by-reference encoding of the triangulated surface
As per the recent email exchange, most geospatial standards/apps (including SQL) are by value, requiring the triangle to specify its vertex coordinates as part of the triangle thus preventing the more normalized approach of shared points via their ID. Civil engineering standards/apps are by reference in that each point is defined by coordinated and tagged with an ID and then triangles are merely a list of three point IDs (ditto for other TIN elements). In SQL/MM I propose to make triangles a subtype of Polygon (and thereby by-value) but propose to add observer/mutator methods which will enable I/O by using the by-reference approach. I believe GML should likewise support such an alternative encoding. This may be doable without changing 19107 or the Abstract Model.
