content/developer-guide/referencing/ComponentsOfCRS.html

<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE html>  <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head> <title>ComponentsOfCRS</title> <meta charset="UTF-8"/> <link rel="stylesheet" type="text/css" href="../book.css"/> </head> <body>  <section> <header> <h2 id="ComponentsOfCRS">Coordinate reference systems</h2> </header> <p> Spatial reference systems by coordinates provide necessary information for mapping numerical coordinate values to real-world locations. In Apache <abbr>SIS</abbr>, most information is contained (directly or indirectly) in classes with a name ending in <abbr>CRS</abbr>, the abbreviation of <i>Coordinate Reference System</i>. Those objects contain: </p> <ul> <li>A <i>datum</i>, which specifies among other things which ellipsoid to use as an Earth shape approximation.</li> <li>A description for each axis: name, direction, units of measurement, range of values.</li> <li>Sometimes a list of parameters, especially when using map projections.</li> </ul> <p> Those systems are described by the <abbr>ISO</abbr> 19111 standard (<i>Referencing by Coordinates</i>), which replaces for most parts the older <abbr>OGC 01-009</abbr> standard (<i>Coordinate Transformation Services</i>). Those standards are completed by two other standards defining exchange formats: <abbr>ISO</abbr> 19136 and 19162 respectively for the <cite>Geographic Markup Language</cite> (<abbr>GML</abbr>) — a <abbr>XML</abbr> format which is quite detailed but verbose — and the <cite>Well-Known Text</cite> (<abbr>WKT</abbr>) — a text format easier to read by humans. </p> <h3 id="ProjectedCRS">Map projections</h3> <p> Map projections represent a curved surface (the Earth surface) on a plane surface (a map or a computer screen). Every rendering of geospatial data on a flat screen uses some kind of map projection, sometimes implicitly. Well-designed map projections provide some control over deformations: one can preserve the angles, another projection can preserve the areas, but none can preserve both in same time. The geometric properties to preserve depend on the feature to represent and the work to do on that feature. For example countries elongated along the East-West axis often use a Lambert projection, while countries elongated along the North-South axis prefer a Transverse Mercator projection. </p><p> There is thousands of projected <abbr>CRS</abbr> in use around the world. Many of them are published in the <a href="../../epsg.html"><abbr>EPSG</abbr> geodetic database</a>. The easiest way to get a projected <abbr>CRS</abbr> with Apache <abbr>SIS</abbr> is to use its <abbr>EPSG</abbr> code. For example the following code gets the definition of the <cite>JGD2000 / UTM zone 54N</cite> <abbr>CRS</abbr> (for Japan from 138°E to 144°E): </p> <pre><code>CoordinateReferenceSystem crs = CRS.forCode("EPSG:3100");</code></pre> <p> Other ways to get a coordinate reference system will be given in a <a href="#GetCRS">next section</a>. </p> <h3 id="GeographicCRS">Geographic reference systems</h3> <p> All map projections are based on a geodetic (usually geographic) <abbr>CRS</abbr>. A geodetic <abbr>CRS</abbr> is a coordinate reference system with latitude, longitude and sometimes height axes. There is many kinds of latitudes and longitudes, but two common kinds supported by Apache <abbr>SIS</abbr> are <dfn>geodetic</dfn> and <dfn>geocentric</dfn> latitudes. Those two angles differ slightly in the way they intersect the ellipsoid surface. On Earth surface, the difference between those two kinds of latitude varies between 0 and about 20 km. </p><p> When peoples talk about latitudes and longitudes, they usually mean <em>geodetic</em> latitudes and longitudes. A coordinate reference system using such latitudes and longitudes is said <dfn>geographic</dfn> and is represented by the <code>GeographicCRS</code> interface. Systems using the other kinds of latitude are represented by other <abbr>CRS</abbr> interfaces. </p><p> Theoretically, data expressed in a geographic <abbr>CRS</abbr> can never be rendered directly on a flat screen (they could be rendered directly on a planetarium dome however). In practice we allow data rendering in a geographic <abbr>CRS</abbr>, but this process implicitly uses a <cite>Plate Carrée</cite> projection. </p> <h3 id="CompoundCRS">Vertical and temporal dimensions</h3> <p style="color: red">TODO</p> <h3 id="CoordinateSystem">Coordinate systems</h3> <p> A Coordinate System (<abbr>CS</abbr>) defines the set of axes that spans a given coordinate space. Each axis defines an approximative direction (north, south, east, west, up, down, port, starboard, past, future, <i>etc.</i>), units of measurement, minimal and maximal values, and what happen after reaching those extremum. For example in longitude case, after +180° the coordinate values continue at −180°. Axes having such behavior are flagged by the <code>RangeMeaning.WRAPAROUND</code> code. </p> <aside> <h4>Generalizing to other types of axes</h4> <p> Wraparound can also exist in time axis. For example in climatological data defining normal temperatures, after December the data sequence restarts to January; those months are associated to no particular year. Apache <abbr>SIS</abbr> allows wraparound to happen on any axis, as long as it is flagged by <code>RangeMeaning</code> code. It is possible to have many wraparound axes in the same coordinate system. </p> </aside> <p> Each Coordinate Reference System (<abbr>CRS</abbr>) is associated with exactly one Coordinate System (<abbr>CS</abbr>). Some properties that we can get from a coordinate system and its axes are shown below. Axes are numbered from 0 to <code>cs.getDimension()-1</code> inclusive. </p> <pre><code>CoordinateSystem cs = crs.getCoordinateSystem(); CoordinateSystemAxis secondAxis = cs.getAxis(1); // For a geographic CRS, this is usually geodetic longitude. String abbreviation = secondAxis.getAbbreviation(); // For a longitude axis, this is usually "λ", "L" or "lon". AxisDirection direction = secondAxis.getDirection(); // For a longitude axis, this is usually EAST. Another occasional value is WEST. Unit<?> units = secondAxis.getUnit(); // For a longitude axis, this is usually Units.DEGREE. double minimum = secondAxis.getMinimumValue(); // For a longitude axis, this is usually −180°. Another common value is 0°. double maximum = secondAxis.getMaximumValue(); // For a longitude axis, this is usually +180°. Another common value is 360°. RangeMeaning atEnds = secondAxis.getRangeMeaning(); // For a longitude axis, this is WRAPAROUND. </code></pre> <p> In addition to axis definitions, another important coordinate system characteristic is their type (<code>CartesianCS</code>, <code>SphericalCS</code>, <i>etc.</i>). The <abbr>CS</abbr> type implies the set of mathematical rules for calculating geometric quantities like angles, distances and surfaces. Usually the various <abbr>CS</abbr> subtypes do not define any new Java methods compared to the parent type, but are nevertheless important for type safety. For example many calculations or associations are legal only when all axes are perpendicular to each other. In such case the coordinate system type is restricted to <code>CartesianCS</code> in method signatures. </p><p> Coordinate systems are mathematical concepts; they do <strong>not</strong> contain any information about where on Earth is located the system origin. Consequently coordinate systems alone are not sufficient for describing a location; they must be combined with a <dfn>datum</dfn> (or <dfn>reference frame</dfn>). Those combinations form the <dfn>coordinate reference systems</dfn> described in previous sections. </p> <h3 id="GeodeticDatum">Geodetic reference frame</h3> <p> Since the real topographic surface is difficult to represent mathematically, it is not used directly. A slightly more convenient surface is the geoid, a surface where the gravitational field has the same value everywhere (an equipotential surface). This surface is perpendicular to the direction of a plumb line at all points. The geoid surface would be equivalent to the mean sea level if all oceans where at rest, without winds or permanent currents like the Gulf Stream. </p><p> While much smoother than topographic surface, the geoid surface still have hollows and bumps caused by the uneven distribution of mass inside Earth. For more convenient mathematical operations, the geoid surface is approximated by an ellipsoid. This “figure of Earth” is represented in GeoAPI by the <code>Ellipsoid</code> interface, which is a fundamental component in coordinate reference systems of type <code>GeographicCRS</code> and <code>ProjectedCRS</code>. Tenth of ellipsoids are commonly used for datum definitions. Some of them provide a very good approximation for a particular geographic area at the expense of the rest of the world for which the datum was not designed. Other datums are compromises applicable to the whole world. </p> <div class="example"> <p><b>Example:</b> the <abbr>EPSG</abbr> geodetic dataset defines among others the “<abbr>WGS</abbr> 84”, “Clarke 1866”, “Clarke 1880”, “<abbr>GRS</abbr> 1980” and “<abbr>GRS</abbr> 1980 Authalic Sphere” (a sphere of same surface than the <abbr>GRS</abbr> 1980 ellipsoid). Ellipsoids may be used in various places of the world or may be defined for a very specific region. For example in <abbr>USA</abbr> at the beginning of XX<sup>th</sup> century, the Michigan state used an ellipsoid based on the “Clarke 1866” ellipsoid but with axis lengths expanded by 800 feet. This modification aimed to take in account the average state height above mean sea level.</p> </div> <p> The main properties that we can get from an ellipsoid are given below. The semi-major axis length is sometimes called <cite>equatorial radius</cite> and the semi-minor axis length the <cite>polar radius</cite>. The inverse flattening factor is apparently superfluous since it can be derived from other quantities, but many ellipsoid definitions provide this factor instead of semi-minor axis length. </p> <pre><code>Unit<Length> units = ellipsoid.<code class="API">getAxisUnit()</code>; double semiMajor = ellipsoid.<code class="API">getSemiMajorAxis()</code>; // In units of measurement given above. double semiMinor = ellipsoid.<code class="API">getSemiMinorAxis()</code>; // In units of measurement given above. double ivf = ellipsoid.<code class="API">getInverseFlattening()</code>; // = semiMajor / (semiMajor - semiMinor). </code></pre> <p> For defining a geodetic system in a country, a national authority selects an ellipsoid matching closely the country surface. Differences between that ellipsoid and the geoid’s hollows and bumps are usually less than 100 metres. Parameters that relate an <code>Ellipsoid</code> to the Earth surface (for example the position of ellipsoid center) are represented by instances of <code>GeodeticDatum</code>. Many <code>GeodeticDatum</code> definitions can use the same <code>Ellipsoid</code>, but with different orientations or center positions. </p><p> Before the satellite era, geodetic measurements were performed exclusively from Earth surface. Consequently, two islands or continents not in range of sight from each other were not geodetically related. So the <cite>North American Datum 1983</cite> (<abbr>NAD83</abbr>) and the <cite>European Datum 1950</cite> (<abbr>ED50</abbr>) are independent: their ellipsoids have different sizes and are centered at a different positions. The same geographic coordinate will map different locations on Earth depending on whether the coordinate uses one reference system or the other. </p><p> The <abbr title="Global Positioning System">GPS</abbr> invention implied the creation of a world geodetic system named <abbr title="World Geodetic System 1984">WGS84</abbr>. The ellipsoid is then unique and centered at the Earth gravity center. <abbr>GPS</abbr> provides at any moment the receptor absolute position on that world geodetic system. But since <abbr>WGS84</abbr> is a world-wide system, it may differs significantly from local systems. For example the difference between <abbr>WGS84</abbr> and the European system <abbr>ED50</abbr> is about 150 metres, and the average difference between <abbr>WGS84</abbr> and the <cite>Réunion 1947</cite> system is 1.5 kilometres. Consequently we shall not blindly use <abbr>GPS</abbr> coordinates on a map, as transformations to the local system may be required. Those transformations are represented in GeoAPI by instances of the <code>Transformation</code> interface. </p><p> The <abbr>WGS84</abbr> ubiquity tends to reduce the need for <code>Transformation</code> operations with recent data, but does not eliminate it. The Earth moves under the effect of plate tectonic and new systems are defined every years for taking that fact in account. For example while <abbr>NAD83</abbr> was originally defined as practically equivalent to <abbr>WGS84</abbr>, there is now (as of 2016) a 1.5 metres difference. The <cite>Japanese Geodetic Datum 2000</cite> was also defined as practically equivalent to <abbr>WGS84</abbr>, but the <cite>Japanese Geodetic Datum 2011</cite> now differs. Even the <abbr>WGS84</abbr> datum, which was a terrestrial model realization at a specific time, got revisions because of improvements in instruments accuracy. Today, at least six <abbr>WGS84</abbr> versions exist. Furthermore many borders were legally defined in legacy datums, for example <abbr>NAD27</abbr> in <abbr>USA</abbr>. Updating data to the new datum would imply transforming some straight lines or simple geometric shapes into more irregular shapes, if the shapes are large enough. </p><p> Contrarily to other kinds of objects introduced in this section, there is not many useful information that we can get from a <code>Datum</code> instance except its name. It is difficult to translate in programming language how a datum is related to the Earth. Often, the most we can do is to consider that having two datums with different names implies that the same location on Earth has different coordinate values when using those different datums, even if the ellipsoid is identical in both cases. Coordinate transformations between datums require some kind of database. </p> </section> </body> </html>

content/developer-guide/referencing/ComponentsOfCRS.html (211 lines of code) (raw):