Geographic coordinates are numbers which describe the position of a point
on the planetary surface, where the "surface" is some mathematical
approximation of the physical planet - most commonly a **plane**, a
**sphere** or an **ellipsoid** of rotation. In the context of some
particular application, the mathematical surface is an adequate coordinate
domain if there is no consequential difference between the topology and the
geometry elements (most often, the distances between two points) as derived
by computation, and those measured or observed on the planetary surface.

Planar computations are simpler and faster than those on the sphere, which
are in turn simpler and faster that those on the ellipsoid. On the other hand,
ellipsoid will satisfy the "adequacy requirement" for wider area and more
precise field measurements than a sphere, which will do the same compared to
the plane. This consideration will determine which mathematical surface is
selected for an application with a given territory size and the required
precision of field measurements and activities. Nemo Library addresses the
requirements of **applications that can not use a plane** as the coordinate
computations surface - either because they operate on continental or
global scale, or because the plane geometry does not match the geometry
measured in the field with sufficient precision.

Coordinate systems and transformation functions of Nemo Library.

This is the most common and widely used global coordinate system: the point is defined by the spatial direction of its normal to the ellipsoid surface using two angles, latitude (φ) - the angle between the normal and the Equatorial plane and longitude (λ) - the angle between the normal projection into the Equatorial plane and the projection of some arbitrary selected primary meridian

This coordinate system fits extraordinarily well the physical geography:
latitude is directly related to the Solar irradiance and the day/night duration
changes, while the longitude is the direct measure of the Earth's rotation
we experience as **time**: together with distance the most directly
observable phenomenon of the physical world.

Ellipsoid coordinate numbers are not "universal"; in addition to the exact ellipsoid geometry parameters (ellipsoid semi-axes, commonly denoted "a" and "b"), they depend on the origin of points that have been used as the "framework" for the ellipsoid coordinates in a particular coordinate repository ("geodetic datum"). The transformation of coordinates between different geodetic datums is outside of the scope of most system that handle geographical data, but it is important to point out that mixing geographical data from different repositories that do not explicitly define what is the geodetic datum of the their coordinates has been known to result in expensive application failures.

The same as ellipsoid φ,λ system, this one represents a point on the surface using the direction of its normal. Each point on the surface of the sphere is uniquely associated with one (and only one!) point on the ellipsoid, and that association is bidirectional, without any "computational drift" that would be introduced by repeated transformation of coordinates of the same point between the two surfaces.

The mathematical transformation of coordinates is s numerically very close to the conformal (i.e., "shape preserving") mapping between two surfaces. Unlike the conformal coordinate transformation, NCS coordinates are not encoded as angles, but instead of the unit vector direction cosines i,j,k. While this introduces one additional number in each point's' coordinate row, geometry computations are much faster, as the trigonometric functions are replaced by vector algebra.

While the ellipsoid to NCS transformation is very fast, the change from angular (φ,λ) into direction cosines (i,j,k) (and the inverse) by necessity requires the evaluation of slow trigonometric functions.

The same normal that defines the location of the point on the surface of an ellipsoid can be numerically described by i,j,k direction cosines (instead of φ,λ). This enables ellipsoid geometry computations based on iterative vector algebra algorithms, instead of the traditional geodetic propositions based on the series expansion of ellipsoid geometry differential equations.

If point's NCS coordinates are already known, obtaining ellipsoid i,j,k from those will be much faster than using trigonometric functions to obtain i,j,k from ellipsoid φ,λ.

The coordinate systems described so far all assume that the point is on the ellipsoid (or - in case of NSC - spherical) surface, and that any elevation above (or depth below) the surface is, if required by the application, recorded separately from (in addition to) the coordinates.

Applications which deal with the geometry relationships between an object in the orbit above the planet and the object on the planetary surface (such as determining the instantaneous satellite's nadir location, swath of the sensor on the planetary surface etc.) require the representation of a point above the surface associated with a given point and above it along it's normal in geocentric three-dimensional Cartesian coordinate system x,y,z.

NCS coordinates consist of three (in most implementation 8-byte) numbers. Since they are direction cosines of a unit vector, the number with the largest magnitude can be removed and restored when required, and the remaining two numbers can have their resolution - and the storage required to record them - reduced, while still retaining the spatial granularity sufficient for most high-volume geographical data.

Such coordinates are can be easily transformed back into full, three number NCS coordinates and used for computations. In addition to compact storage of high-volume data, CDC coordinates are also of significant utility in exchange of global location data between different application systems or on-line data exchange between different data repositories.

The only disadvantage of CDC coordinates is their lack of any intuitive relationship between the coordinate number and the physical geography.

The library provides functions for direct and inverse transformation (sphere to plane and plane to sphere, respectively) for several essential cartographic projections; Stereographic projection is the most important among those and is used as example on the diagram above. With the possible exception of Gnomonic projection, it is assumed that planar coordinates are not used for geometry calculations. The primary requirement for cartographic transformations is speed, as often large volumes of data-points must be shown on a transient computer "map"; less critical is the speed of inverse transformations, typically to "un-map" the location selected by a GUI pointing device back to NCS coordinates for data selection and/or computations.

Only a high-level summary of the functions that transform point coordinates between different surfaces and coordinate systems is provided below. For details, consult the library Reference Manual and the individual function source code commentary.

`nemo_LatLongToDcos3()`

and `nemo_Dcos3ToLatLong()`

transfromation functions perform only the fundamental spherical trigonometry
computations (sine and cosine by former, arctangent by the latter). Their
speed is primarily the function of the speed of trigonometric function
evaluation provided by the hardware.

`nemo_NcsToEnr()`

`nemo_EnrToNcs()`

both perform only
simple algebraic operations on vector components and ellipsoid parameters,
and are considerably faster than angle/vector transformation functions.
However, if in addition to vector component manipulation,
`nemo_EllToNcs()`

and `nemo_NcsToEll()`

also transfer
the coordinates between the angular and vector numerical domains, as a result
of which their speed is comparable to other angle/vector transformation
functions.

`nemo_EnrToCc3()`

performs only the vector algebra operations,
and thus its speed is comparable to other functions performing only the vector
algebra operations. However, its inverse, `nemo_Cc3ToEnr()`

, must
perform an iterative computation required to determine the point on the
meridian ellipse, the normal of which, extended, passes through the point
defined by its radiusvector. Its speed is thus dependent on the degree
of ellipsoid flattening and (to a lesser degree) on the elevation of the
given point above (or below) it.

`nemo_NcsToU64()`

and `nemo_U64ToNcs()`

functions
perform only the real to integer number scaling and conversion, and simple
bitwise operations, and are comparable to functions performing simple vector
algebra - thus they are among the fastest transformation functions in the
library.

The library currently provides five near-conformal sphere (NCS) to cartographic
projections: Gnomonic, Stereographic, Orthographic, Conical and Stylindrical.
The names of coordinate transfromation functions for all of those have the same
format; for instance - (code>nemo_StereographicDirect()
and `nemo_StereographicInverse()`

).

Functions that only transform numerical coordinate representation of a point
on the same surface (ellipsoid or sphere, functions
`nemo_LatLongToDcos3()`

and `nemo_Dcos3ToLatLong()`

),
(sphere, `functions nemo_NcsToU64()`

and
`nemo_U64ToNcs()`

) require no information other than source
point coordinates in order to perform the transformation.

Functions that transfer a point between the ellipsoid and sphere
`(nemo_EllToNcs()`

, `nemo_NcsToEll()`

,
`nemo_NcsToEnr()`

and `nemo_EnrToNcs()`

), as
well as those that re-locate a given ellipsoid point
(`nemo_EnrToCc3()`

and `nemo_CC3ToEnr()`

) require
the knowledge of ellipsoid geometry. This knowledge, in the form of an array
of ellipsoid parameters, is provided by the `nemo_ElrInit()`

or
`nemo_ElrWgs84()`

functions.

Similarly, cartographic functions, which transfer a point between the NCS
and some purposefully selected plane, require the knowledge of the geometry
that defines the spatial relationship between the sphere and the plane. This
knowledge is supplied, again in the form of an array of mapping parameters,
by the "parameter initialization functions'; for example
`nemo_StereographicInit()`

, `nemo_GnomonicInit()`

and so on.