org.opengis.referencing.crs
Interface SingleCRS
- All Superinterfaces:
- CoordinateReferenceSystem, IdentifiedObject, ReferenceSystem
- All Known Subinterfaces:
- DerivedCRS, EngineeringCRS, GeneralDerivedCRS, GeocentricCRS, GeodeticCRS, GeographicCRS, ImageCRS, ProjectedCRS, TemporalCRS, VerticalCRS
@Classifier(value=ABSTRACT)
@UML(identifier="SC_SingleCRS",
specification=ISO_19111)
public interface SingleCRS- extends CoordinateReferenceSystem
Abstract coordinate reference system, consisting of a single
Coordinate System and a single
Datum (as opposed to Compound CRS).
A coordinate reference system consists of an ordered sequence of coordinate system
axes that are related to the earth through a datum. A coordinate reference system
is defined by one datum and by one coordinate system. Most coordinate reference system
do not move relative to the earth, except for engineering coordinate reference systems
defined on moving platforms such as cars, ships, aircraft, and spacecraft.
Coordinate reference systems are commonly divided into sub-types. The common classification
criterion for sub-typing of coordinate reference systems is the way in which they deal with
earth curvature. This has a direct effect on the portion of the earth's surface that can be
covered by that type of CRS with an acceptable degree of error. The exception to the rule is
the subtype "Temporal" which has been added by analogy.
- Since:
- 2.0
- See Also:
CoordinateSystem,
Datum
getCoordinateSystem
@UML(identifier="coordinateSystem",
obligation=MANDATORY,
specification=ISO_19111)
CoordinateSystem getCoordinateSystem()
- Returns the coordinate system.
- Specified by:
getCoordinateSystem in interface CoordinateReferenceSystem
- Returns:
- The coordinate system.
getDatum
@UML(identifier="datum",
obligation=OPTIONAL,
specification=ISO_19111)
Datum getDatum()
- Returns the datum.
- Returns:
- The datum.
Departure from OGC/ISO specification:
This method is conform to ISO 19111:2003. The 2007 revision moved this attribute to subclasses,
where it is repeated with different return types. While ISO does not provide explanation for this move,
one possible reason may have been to enforce type safety in languages that do not support type covariance.
Since Java 5 and later supports return type covariance, this method has been keep in this parent class
both for historical and for genericity reasons.
Copyright © 1994-2013 Open Geospatial Consortium. All Rights Reserved.