The Federal Geographic Data Committee (FGDC) of the US Government is currently proposing a seven-part standard to represent various common feature types. Called Information Technology - Geographic Information Framework Data Content Standard, this is being proposed as an American National Standard and has been approved by INCITS/L1, once all the comments have been successfully ajudicated. The elevation part (Part 3), in the form distributed for review, adds complexity without adding basic required functionality. The final form of the standard is unknown at this point, as it will change as the FGDC takes comments into consideration.
So now that the pressure of trying to influence a gargantuan standards body is off, we can now watch the evolution of a means of handling elevation data and determine how we might want to approach such a problem from within GeoTools. This page reverse-engineers the FGDC proposal in order to determine the capabilities it tries to provide. Problems with the execution of the design are identified. The capabilities are then implemented in a different design which does not have the same problems. (But perhaps has different problems.)
If GeoTools wants to handle elevation data in the future, this page may serve to jumpstart the process of selecting an elevation data model. In the end, we can either use the FGDC standard in its final form, this proposed alternative, a different elevation standard, or some combination of these choices. It is good to learn from other people's mistakes, it is better to distinguish what someone was trying to do from how they tried to do it, and sometimes the best solution is to merge the best features of several different designs.
Prior to evaluating the elevation standard, or constructing a proposed alternative, we must come to agreement as to what should be included in an elevation data content model and what should be omitted.
The previous section outlines the characteristics of elevation data. The most serious inadequacy of the FGDC proposal is that it does not provide a way to associate a datum with a particular attribute of the elevation coverage. This is a showstopper in and of itself. Units are also difficult to specify. Worse: using the example provided on the top of page 12 (lines 610-612) excludes the specification of units. In summary, the current incarnation of the FGDC standard does not consider units or a vertical datum to be an essential part of elevation data.
Beyond supplying certain basic, mandatory data attributes the FGDC standard solves all problems using inheritance and realization relationships with ISO 19123. After reviewing this standard, it seems that this could be nearly a textbook application of either the adapter pattern or the decorator pattern. In this instance, inheritance is an extremely clumsy tool to use, as it requires extending or realizing quite a few types in 19123. Either of the above patterns would be a more natural fit to the function of associating a datum and units with an existing data structure. I'd like to explore the potential afforded by these well known design patterns to evaluate whether it makes a bigger or smaller mess than does inheritance.
The FGDC proposal may be divided into two parts:
The above figure illustrates the current support provided by the FGDC standard for integrated horizontal and vertical coordinates. As shown, the primary functionality is to collect (x,y,z) tuples into a "set" data structure. The elements of these sets are points (or in the case of the profile, curves which are composed of a series of connected points.) These data must be associated with a CompoundCRS consisting of some horizontal CRS (Geographic, Projected, Derived, etc.) and a VerticalCRS. As such, both units and datum are defined.
The limitation of this data structure is that it behaves only as a collection of points or curves. There is no means of querying the data. One may iterate over the data or test for the presence of a particular data point.
In contrast to the integrated representation of horizontal and vertical coordinates, the case where horizontal coordinates are represented separately from the vertical measurement is illustrated below. As shown, the chosen vehicle for the representation is the coverage. The Domain of the coverage is used to represent the horizontal coordinates, and the Range is used to represent the vertical measurement.
The vertical measurements are represented as a "feature attribute value" of the coverage. This means that one or more of the named attributes of the coverage is designated to contain vertical measurement data. There are a few problems with this:
The choice to represent elevation values as an attribute of a coverage permits the specification of more than one elevation value per horizontal coordinate. However, as the elevation values must be named for the type of elevation measurement, and the names must be unique, it may be inferred that there may only be one elevation measurement of a particular type at a particular horizontal coordinate. This choice also permits the user to query for the elevation measurement using only the horizontal coordinate, which is likely to be the most common usage.
Both representations (separated and integrated coordinates) are composed of individual measurements which are collected into an organizing data structure. The integrated representation specifies only that the elements be corralled into a collection, while the separated representation supplies this functionality with the list() operation on the coverage and also permits the user to query via horizontal coordinates.
The ElevationPointSet is a duplicate of the elevation point coverage. It represents the special case where only one elevation measurement is contained in the point.
This proposal concentrates only on the value which is added by an elevation data type: interpreting one or more feature attribute values as a measurement of elevation. This is in contrast to the FGDC proposal, which concentrates on the creation of what amount to "tagging interfaces" for all of the predefined data management types in ISO 19123. This focus on redefining data management has excluded the definition of that which is unique to elevation data: the interpretation of numeric data as elevation measurements. As such, this proposal is not only simpler than the FGDC alternative, it is more to the point.
The proposed alternative addresses one functional subsystem of the standard at a time. The following diagram implements all of the use cases identified for the "Separated Horizontal and Vertical Coordinates" case. Key features of this class diagram:
