Just as measurements of length and weight have must have units to be meaningful, spa- tial coordinates must have a well-defined mathematical link to a fixed point of reference in space, which is usually the Earth. These could be Cartesian coordinates fixed with an origin at the centre of the Earth (Earth Centred Earth Fixed or ECEF), or spherical coordinates in either degrees or radians with a mathematical model of the Earth ellip- soid. The British National Grid system is slightly more complicated, being a projected coordinate system, which is fully defined together with definitions of datum, spheroid and ellipsoid in [Ord10].
Geospatial computing systems are concerned with coordinate systems in order to draw data on the display in the correct location to a known accuracy. According to the Open Geospatial Consortium, a Coordinate Reference System is defined as follows:
“A coordinate reference system is a coordinate system that has a ref- erence to the Earth. A coordinate reference system consists of a coordinate system and a datum. Types of coordinate reference systems include: geo- centric, geographic (including an ellipsoid), projected, engineering, image, vertical, temporal”
“A coordinate system is composed of a set of coordinate axes with a known metric.”
3.4. Map Projections 75 “The datum defines the origin, orientation and scale of the coordinate system and ties it to the Earth, ensuring that the abstract mathematical con- cept “coordinate system” can be applied to the practical problem of describ- ing positions or features on or near the Earth’s surface by means of coordi-
nates.” (From OGC document 03-040, 2001-11-13, OGC 01-063r1)
The origins of map projections are rooted in two-dimensional cartography and fall into one of the following three types: Cylindrical, Conic or Azimuthal. In “The Nomen- clature and Classification of Map Projections” [Lee44], Lee states that, “the projections are termed cylindric or conic because they can be regarded as developed on a cylin- der or a cone”, before going on to suggest dropping this terminology because, while mathematically correct, the cone or cylinder might, “bear no simple relationship to the sphere”. Azimuthal projections plot rays of light onto a developable surface which forms the projection plane. The focal position of the rays defines the geometry of the projection. While Lee is concerned with the terminology of map projections and clas- sification into groups of conformal (angle-preserving) and area-preserving, Snyder and Voxland have published “An Album of Map Projections” [SV89] for the U.S. Geolog- ical Survey, which serves as a visual illustration of the different types. In the section, “Classification based on Construction” on page 5 of this album, the types “Cylindric”, “Conic” and “Azimuthal” are used as classifications for the maps which follow. While hybrids of the three types are possible (e.g. HEALPix is a hybrid of Collignon and Lambert), mapping onto general polyhedra is another alternative, for example the “Dy- maxion” map of Buckminster Fuller, shown in figure 3.3d. For completeness, other projections that do not fit the three classes above are labelled as ‘miscellaneous’, like the Lagrange or various ‘Globular’ projections in [SV89]. Although the ‘Proj4’ library is introduced later, it is worth looking at the code behind its Java version at this point in order to more fully explain the relevance of the three types of projection. ‘Proj4J’ is the Java version of the open-source projection library which underpins all of the map pro- jections used by the ‘Geotools’ GIS library and ‘Geoserver’ web map tile server. Look- ing at the original Java source code for the Proj4J project9from OSGeo, the following
definitions exist for projection base classes: AzimuthalProjection.java, CylindricalPro- jection.javaand ConicProjection.java. Taking the ’PlateCarreeProjection’ class as an example, this extends the ’CylindricalProjection’ class, which demonstrates the object
oriented reasoning behind grouping the main projections in this way. All the concrete projection classes are derived from their respective base type, thereby re-using code and making for a logical structure which is based on the mathematics of how the projections are derived.
Map projection libraries take descriptions of coordinate reference systems in “well known text” (WKT) format, in the case of an OGC compliant library, and can derive a maths transform from one coordinate reference system to another. This is a utility library that can take data points in a projection like OSGB36 [Ord10] and reproject them into a Spherical Mercator projection for web mapping, or even convert to an unprojected spherical system like WGS84 or the Cartesian ECEF for 3D visualization. The ‘Spatial Referencing’ website, www.spatialreferencing.org, contains definitions of all the popular coordinate reference systems and is a useful reference when converting from one system to another. Where Cartesian systems like ‘ECEF’ are concerned, this is the difference between the definitions of “Geography” and “Geometry” in the OGC’s “Simple Features for SQL” definition [Ope10b]. Geography is an unprojected spherical coordinate system, while Geometry is projected onto a flat plane. There are only two “well known text” forms for describing coordinate reference systems, either the “WKT” form for OGC derivatives or “Proj4” for the Proj4c and Proj4j derivatives. Issues arise where coordinates are being moved from one coordinate system to another where the two systems are based on different spheroids, for example, OSGB36 to Mercator, where a translate, rotate and scale operation needs to be performed as a final step.
‘Proj4’ is a cartographic projections library which is part of OSGeo, an organisation which publishes open geospatial standards. ‘Proj4’ was originally written by Gerald Evenden of the USGS and has been converted to numerous languages [Eve05]. The source code is available from http:// download.osgeo.org/ prof/ prof-4.8.0.tar.gz and a quick Internet search yields a long list of ports to other languages: PROJ.4 VB (Vi- sual Basic), fPROJ4 (MySQL), proj4rb (Ruby), pyproj (Python), PROJ4JS (Javascript), PROJ4PHP (PHP), PROJ4.J (Java), PROJ.4 (Delphi and Borland C++), Proj.net (Mi- crosoft .net). The USGS ‘Album of Map Projections’ [SV89] is another useful resource which shows a number of map projections, and the mathematics behind how they work. Selected map projections are published as standards by organisations like the ‘European Petroleum Survey Group’ (EPSG), who govern the use of all ‘EPSG’ projection codes. Their website is a useful reference for looking up the definitions [Eur14]. Information
3.4. Map Projections 77 for projections usually contains the Proj4 string and the OGC’s ‘Well Known Text’ (WKT) formats. Figure 3.3 shows a number of commonly used map projections.
Map projection libraries form a necessary part of any geospatial system that is re- quired to compare data in different coordinate systems. It is entirely possible to plot data without any CRS by simply scaling the viewport to fit the data extents, although this can result in the data being visibly skewed where the North and East scaling is markedly different. Although measuring a point with reference to the Earth is simple in today’s GPS enabled world, it is entirely possible to collect and visualise spatial data with local, rather than global coordinates. A single fixed point from which to measure data and one, two or three orthogonal direction axes are all that is required. Aerial survey data can contain images of roads, buildings or crops where the information con- tained is relative to the collection area. An example of this could be image mapping using drones to determine the location and percentage coverage of an invasive species within a target area, as in [Riv+18], where the images from a downward pointing cam- era were stitched to form a cohesive map for analysis and geolocated later using map matching techniques. Another example is a point cloud taken of an archaeological site showing structures and artefacts with their relative positions to each other forming the spatial context, although it would be unusual not to GPS locate the instrument where this is possible. In “Simultaneous Localisation and Mapping” algorithms, or SLAM for short, 2D and 3D maps are constructed using a robot moving around the target area. The captured images are used to estimate position and pose, with the scene constructed from the relative positions of objects to each other. This technique can be used to survey indoor areas, caves and tunnels where GPS is not available.
In terms of visualisation without reference to the Earth, though, this is encountered in 3D visualisation systems where ‘model world’ coordinate systems have to be used. The Autodesk 3DS Max and XBox visualisations presented in this thesis are examples of this type of visualisation (figures 3.5, 3.6, 4.16 and 4.39), where data in an OSGB36 projection has been converted to model world coordinates. Here, either the size or ac- curacy of coordinates can cause a problem, resulting in the necessary conversion of Earth coordinates into screen coordinates. While it can be argued in this instance that there is a CRS because there is a defined mapping between the two coordinate sys- tems, the animation does not use it and renders all the data with reference to their own world box. This is an important point to make concerning the construction of visualisa-
tion systems because it recognises the limitations of the computer’s ability to represent numbers defining a point on the Earth. The mantissa and exponent sizes defined in the IEEE-754 specification [Ste80] result in approximately seven accurate decimal digits for single precision and sixteen for double precision. This has implications for coor- dinate systems like EPSG:900913, where representing the world in metres implies a range of ±20037508. Here, double precision floating point is the only option, so a graphics library that uses single precision for speed will not have enough precision. Virtual Earths like Google Earth and NASA’s Worldwind have to solve this problem to display the world, while allowing the user to zoom in close to an area of interest. How- ever, data might only exist for a small portion of the world, for example, the London Underground maps presented later in figure 4.39, so the viewport area can be limited and the data rescaled to fit.
While most geospatial systems will probably use one of the existing libraries, it is worth pointing out that a GPU accelerated reprojection, or parallel reprojection archi- tecture would be easy to implement and result in a large performance increase. At present, the floating point maths used will benefit from floating point unit (FPU) ac- celeration and ‘single instruction multiple data stream’ (SIMD) streaming extensions where available, but the task of reprojection is inherently mathematical and data paral- lel, with no sequential dependencies. Once the maths transform has been determined, it is a simple case of applying it to every point in the dataset. The only problem with this is that the world is a spheroid which wraps around from zero degrees to 360 (zero) again, so polygons which span both sides of the artificial separator will cause problems. The wrapping problem means that reprojection requires each feature10to be reprojected
in parallel, not each individual point.
10Feature is defined based on the “Simple Features for SQL” definition of geospatial geometry as unique object unconnected
3.4. Map Projections 79
(a) Polar Stereographic Projection. (b) Mercator Projection.
(c) Orthographic Projection. (d) Dymaxion Projection, created by Eric Gaba (username Sting), Wikimedia Commons.
(e) Space view, Meteosat full Earth disk, visible image for 13/2/2014 18Z. Image downloaded from NOAA.
(f) Earth Centred Earth Fixed Cartesian Coordinate Sys- tem. This example was rendered using WebGL in the Google Chrome Browser.