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.

What is elevation data content?

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.

  1. Elevation data content models the attributes and characteristics particular to numeric data which is to be interpreted as "elevation". These particulars include:
    1. Units for the vertical axis.
    2. A vertical datum for the vertical axis.
    3. An indication of the "type" of vertical measurement, which could include:
      1. bare earth surface reflectance (suggested by FGDC)
      2. reflective surface elevation (suggested by FGDC)
      3. GPS (suggested by Bryce)
  2. Elevation data content excludes "encoding". Neither the data, attributes, nor metadata shall have an encoding specified. In particular, the form of metadata shall not be specified to be a free-form character string.
  3. Associated metadata must be well thought out as well as extensible. Metadata which are expected to generically apply to elevation data shall be explicitly modeled by this proposal. The means for extending the metadata model shall be specified, leveraging the extension mechanism of 19115 to the maximum extent possible.
  4. Elevation data types may allow for querying the vertical dimension when supplied with a horizontal dimension.

Problems with the FGDC proposal

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.

Functionality of the FGDC proposal

The FGDC proposal may be divided into two parts:

  1. Separated horizontal and vertical coordinates (e.g., 2D points for the horizontal position, associated with a 1D measurement of the vertical dimension; see above caveat about units and datum). This strategy permits more than one elevation measurement per horizontal coordinate.
  2. Integrated horizontal and vertical coordinates (e.g. a single 3D point represents horizontal and vertical coordinates.) This strategy permits a single vertical measurement at a horizontal coordinate.

Integrated horizontal and vertical coordinates

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.

Separated horizontal and vertical coordinates

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:

  1. The standard provides no means to identify which attribute contains the elevation data.
  2. The standard requires that the name of the elevation feature attribute be named such that it reflects the type of elevation data, but does not specify any naming restrictions or supply a CodeList of common elevation data types.
  3. The standard recommends using "Real" data to represent the elevation measurements, without supplying a means to select a particular unit or datum. The standard's recommendation may be disregarded in favor of representing elevation data with a "Measure" data type, but this specifies only units, and leaves the datum unconstrained.

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.

The proposed alternative.

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:

  1. It is much simpler than the FGDC proposal.
  2. It unambiguously identifies the elevation feature attributes.
  3. It correctly associates all elevation attributes with a particular VerticalCRS, which designates both reference elevation surface and units.
  4. The classes below are specified at the same level of abstraction as ISO 19123, as opposed to the FGDC standard, which "realize" components from ISO 19123. This is less constrictive to implementors.
  5. This design offers increased isolation from the particulars of data management specified in 19123. The FGDC proposal is heavily dependant on the specializations of CV_GeometryValuePair and CV_ValueObjects. These constructs have known issues which must be corrected eventually.


  1. The FGDC Elevation Framework Standard Proposal
  2. Comment adjudication on Part 3 (MS Excel file)
  3. The ISO 19123 Primer (sorry, this is only a description of the standard, not the standard itself.)
  4. Poseidon UML model of alternative