| 107 |
107 |
CRSType getType();
|
| 108 |
108 |
|
| 109 |
109 |
/**
|
| 110 |
|
* FIXME: GeoAPI
|
| 111 |
|
* Returns a <cite>Well-Known Text</cite> (WKT) for this object.
|
| 112 |
|
* Well-Known Texts (WKT) may come in two formats:
|
|
110 |
* Returns a <cite>Well-Known Text</cite> (WKT) definition for this object.
|
|
111 |
* Note that there are different versions of the WKT specification
|
|
112 |
* (the older WKT defined by OGC 01-009 and the newer one, defined by OGC 12-063r5
|
|
113 |
* and ISO 19162). Also note that ESRI uses different names to refer to CRSs, datums,
|
|
114 |
* ellipsoids, etc. compared to OGC, so OGC and ESRI WKTs can be considered as different
|
|
115 |
* dialects.
|
|
116 |
*
|
|
117 |
* Whenever possible, this method will return a WKT following the same specification and
|
|
118 |
* dialect that the one used to instantiate this CRSDefinition. If the original
|
|
119 |
* specification or dialect are unknown, implementations are encouraged to format according
|
|
120 |
* to the most recent standard and following OGC dialect.
|
| 113 |
121 |
*
|
| 114 |
|
* <ul>
|
| 115 |
|
* <li>The current standard, WKT 2, is defined by ISO 19162.</li>
|
| 116 |
|
* <li>The legacy format, WKT 1, was defined by {@linkplain org.opengis.annotation.Specification#OGC_01009 OGC 01-009}
|
| 117 |
|
* and is shown using Extended Backus Naur Form (EBNF) <a href="doc-files/WKT.html">here</a>.</li>
|
| 118 |
|
* </ul>
|
| 119 |
|
*
|
| 120 |
|
* Implementations are encouraged to format according the most recent standard.
|
| 121 |
|
* This operation may fail if unsupported or if this instance contains elements that do not have
|
| 122 |
|
* WKT representation.
|
| 123 |
|
*
|
| 124 |
|
* @return the Well-Known Text (WKT) for this object.
|
|
122 |
* @return the Well-Known Text (WKT) definition for this object.
|
| 125 |
123 |
* @throws UnsupportedOperationException if this object can not be formatted as WKT.
|
| 126 |
|
*
|
| 127 |
|
* @departure extension
|
| 128 |
|
* This method is not part of the OGC specification. It has been added in order to provide
|
| 129 |
|
* the converse of the <code>CRSFactory.createFromWKT(String)</code> method, which is
|
| 130 |
|
* defined in OGC 01-009.
|
| 131 |
|
*
|
| 132 |
|
* @see org.opengis.referencing.crs.CRSFactory#createFromWKT(String)
|
| 133 |
124 |
*/
|
| 134 |
125 |
String toWKT() throws UnsupportedOperationException;
|
| 135 |
126 |
|
| 136 |
127 |
/**
|
| 137 |
|
* FIXME: GeoAPI & review definition
|
| 138 |
|
* The ordered list of coordinate reference systems.
|
| 139 |
|
*
|
| 140 |
|
* @return the ordered list of coordinate reference systems.
|
| 141 |
|
*
|
| 142 |
|
* @departure generalization
|
| 143 |
|
* ISO 19111 said <cite>"nesting of compound CRSs shall not be permitted; the individual single systems
|
| 144 |
|
* shall be aggregated together"</cite>. However this approach causes data lost: it is difficult to add
|
| 145 |
|
* a temporal CRS to an existing three-dimensional compound CRS without loosing the name and identifiers
|
| 146 |
|
* of the 3D CRS, unless nesting is permitted. It is programmatically easier to convert nested CRSs to a
|
| 147 |
|
* flat list of single CRSs when needed than to reconstruct the 3D CRS from the single components.
|
| 148 |
|
* Consequently GeoAPI has been keep conformant with the legacy OGC 01-009 specification in this aspect,
|
| 149 |
|
* which were allowing nested compound CRS.
|
| 150 |
|
*
|
| 151 |
|
* @since 2.3
|
| 152 |
|
*/
|
|
128 |
* If the CRS type is {@link CRSType#CompoundCRSType}, this method returns the ordered
|
|
129 |
* list of coordinate reference systems which are its components.
|
|
130 |
*
|
|
131 |
* @return the ordered list of coordinate reference systems, or <code>null if the CRS
|
|
132 |
* is not compound
|
|
133 |
* @see #getType()
|
|
134 |
* @see CRSType#CompoundCRSType
|
|
135 |
*/
|
| 153 |
136 |
List<CRSDefinition> getComponents();
|
| 154 |
137 |
|
| 155 |
138 |
/**
|