Interface Datum

All Superinterfaces:
All Known Subinterfaces:
EngineeringDatum, GeodeticDatum, ImageDatum, ParametricDatum, TemporalDatum, VerticalDatum
All Known Implementing Classes:
SimpleCRS.Temporal, SimpleCRS.Vertical, SimpleDatum

@Classifier(ABSTRACT) @UML(identifier="CD_Datum", specification=ISO_19111) public interface Datum extends IdentifiedObject
Specifies the relationship of a coordinate system to the earth, thus creating a coordinate reference system. For geodetic and vertical coordinate reference systems, the datum relates the coordinate system to the Earth. With other types of coordinate reference systems, the datum may relate the coordinate system to another physical or virtual object.

A datum uses a parameter or set of parameters that determine the location of the origin of the coordinate reference system. Each datum subtype can be associated with only specific types of coordinate systems, documented in their javadoc.

See Also:
  • Field Details

  • Method Details

    • getAnchorPoint

      @UML(identifier="anchorDefinition", obligation=OPTIONAL, specification=ISO_19111) default InternationalString getAnchorPoint()
      A description, possibly including coordinates of an identified point or points, of the relationship used to anchor the coordinate system to the Earth or alternate object. Also known as the "origin", especially for Engineering and Image Datums.
      • For a GeodeticDatum, this anchor may be a point known as the fundamental point, which is traditionally the point where the relationship between geoid and ellipsoid is defined, together with a direction from that point. In other cases, the anchor may consist of a number of points. In those cases, the parameters defining the geoid/ellipsoid relationship have then been averaged for these points, and the coordinates of the points adopted as the datum definition.
      • For an EngineeringDatum, the anchor may be an identified physical point with the orientation defined relative to the object.
      • For an ImageDatum, the anchor point is usually either the centre of the image or the corner of the image. The coordinate system orientation is defined through the AxisDirection class.
      • For a TemporalDatum, this attribute is not defined. Instead of the anchor point, a temporal datum carries a separate time origin of type Date.
      a description of the anchor point, or null if none.
      See Also:
      Departure from OGC/ISO abstract specification:
      Departure for historical reason This method has been kept conformant with the specification published in 2003 for compatibility reasons. The revision published in 2007 renamed this property as anchorDefinition.
    • getRealizationEpoch

      @UML(identifier="realizationEpoch", obligation=OPTIONAL, specification=ISO_19111) default Date getRealizationEpoch()
      The time after which this datum definition is valid. This time may be precise (e.g. 1997 for IRTF97) or merely a year (e.g. 1983 for NAD83). In the latter case, the epoch usually refers to the year in which a major recalculation of the geodetic control network, underlying the datum, was executed or initiated.

      An old datum can remain valid after a new datum is defined. Alternatively, a datum may be superseded by a later datum, in which case the realization epoch for the new datum defines the upper limit for the validity of the superseded datum.

      Upcoming API change — temporal schema
      The return type of this method may change in GeoAPI 4.0 release. It may be replaced by a type matching more closely either ISO 19108 (Temporal Schema) or ISO 19103.
      the datum realization epoch, or null if not available.
    • getDomainOfValidity

      @UML(identifier="domainOfValidity", obligation=OPTIONAL, specification=ISO_19111) default Extent getDomainOfValidity()
      Area or region or timeframe in which this datum is valid.
      the datum valid domain, or null if not available.
    • getScope

      Description of domain of usage, or limitations of usage, for which this datum object is valid.
      a description of domain of usage, or null if none.
      Departure from OGC/ISO abstract specification:
      Departure for historical reason This method has been kept conformant with the specification published in 2003. The revision published in 2007 replaced the singleton by a collection and changed the obligation from "optional" to "mandatory", requiring a return value of "not known" if the scope is unknown.