flightgear/CoordinateSystem/CoordinateSystem.tex

%
% `coord.tex' -- describes the coordinate systems and transforms used
%                by the FG scenery management subsystem
%
%  Written by Curtis Olson.  Started July, 1997.
%
% $Id$


\documentclass[12pt]{article}
% \usepackage{times}
% \usepackage{mathptm}

\usepackage{anysize}
\papersize{11in}{8.5in}
\marginsize{1in}{1in}{1in}{1in}

\usepackage{epsfig}

\usepackage{setspace}
\onehalfspacing

\usepackage{url}


\begin{document}


\title{
  Flight Gear Internal Scenery Coordinate Systems and
  Representations.
}

\author{
    Curtis L. Olson\\ 
    (\texttt{curt@me.umn.edu})
}

\maketitle

\section{Coordinate Systems}

\subsection{Geocentric Coordinates}

Geocentric coordinates are the polar coordinates centered at the
center of the earth.  Points are defined by the geocentric longitude,
geocentric latitude, and distance from the \textit{center} of the
earth.  Note, due to the non-spherical nature of the earth, the
geocentric latitude is not exactly the same as the traditional
latitude you would see on a map.

\subsection{Geodetic Coordinates}

Geodetic coordinates are represented by longitude, latitude, and
elevation above sea level.  These are the coordinates you would read
off a map, or see on your GPS.  However, the geodetic latitude does
not precisely correspond to the angle (in polar coordinates) from the
center of the earth which the geocentric coordinate system reports.

\subsection{Geocentric vs. Geodetic coordinates}

The difference between geodetic and geocentric coordinates is subtle
and must be understood.  The problem arose because people started
mapping the earth using latitude and longitude back when they thought
the Earth was round (or a perfect sphere.)  It's not though.  It is
more of an ellipse.  

Early map makers defined the standard \textit{geodetic} latitude as
the angle between the local up vector and the equator.  This is shown
in figure \ref{fig:geodesy}.  The point $\mathbf{B}$ marks our current
position.  The line $\mathbf{ABC}$ is tangent to the ellipse at point
$\mathbf{B}$ and represents the local ``horizontal.''  The line
$\mathbf{BF}$ represents the local ``up'' vector.  Thus, in
traditional map maker terms, the current latitude is the angle defined
by $\angle \mathbf{DBF}$.

However, as you can see from the figure, the line $\mathbf{BF}$ does
not extend through the center of the earth.  Instead, the line
$\mathbf{BE}$ extends through the center of the earth.  So in
\textit{geocentric} coordinates, our latitude would be reported as the
angle $\angle \mathbf{DBE}$.

\begin{figure}[hbt]
  \centerline{                   
      \psfig{file=geodesy.eps}
  }
  \caption{Geocentric vs. Geodetic coordinates}
  \label{fig:geodesy}
\end{figure}

The LaRCsim flight model operates in geocentric coordinates
internally, but reports the current position in both coordinate
systems.

\subsection{World Geodetic System 1984 (WGS 84)}

The world is not a perfect sphere.  WGS-84 defines a standard model
for dealing with this.  The LaRCsim flight model code already uses the
WGS-84 standard in its calculations.

For those that are interested here are a couple of URLS for more
information:

\noindent
\url{http://acro.harvard.edu/SSA/BGA/wg84figs.html} \\
\url{http://www.afmc.wpafb.af.mil/organizations/HQ-AFMC/IN/mist/dma/wgs1984.htm}
\\
\url{http://www.nima.mil/publications/guides/dtf/datums.html}

To maintain simulation accuracy, the WGS-84 model should be used when
translating geodetic coordinates (via geocentric coordinates) into the
FG Cartesian coordinate system.  The code to do this can probably be
borrowed from the LaRCsim code.  It is located in
\texttt{ls\_geodesy.c}.

\subsection{Cartesian Coordinates}

Internally, all flight gear scenery is represented using a Cartesian
coordinate system.  The origin of this coordinate system is the center
of the earth.  The X axis runs along a line from the center of the
earth out to the equator at the zero meridian.  The Z axis runs along
a line between the north and south poles with north being positive.
The Y axis is parallel to a line running through the center of the
earth out through the equator somewhere in the Indian Ocean.  Figure
\ref{fig:coords} shows the orientation of the X, Y, and Z axes in
relationship to the earth.

\begin{figure}[hbt]
  \centerline{                   
      \psfig{file=coord.eps}
  }
  \caption{Flight Gear Coordinate System}
  \label{fig:coords}
\end{figure}

\newpage

\subsection{Converting between coordinate systems}

Different aspects of the simulation will need to deal with positions
represented in the various coordinate systems.  Typically map data is
presented in the geodetic coordinate system.  The LaRCsim code uses
the geocentric coordinate system.  FG will use a Cartesian coordinate
system for representing scenery internally.  Potential add on items
such as GPS's will need to know positions in the geodetic coordinate
system, etc.

FG will need to be able to convert positions between any of these
coordinate systems.  LaRCsim comes with code to convert back and forth
between geodetic and geocentric coordinates.  So, we only need to
convert between geocentric and cartesian coordinates to complete the
picture.  Converting from geocentric to cartesian coordinates is done
by using the following formula:  \\
$x = cos(lon_\mathit{geocentric}) * cos(lat_\mathit{geocentric}) *
radius_\mathit{geocentric}$  \\
$y = sin(lon_\mathit{geocentric}) * cos(lat_\mathit{geocentric}) *
radius_\mathit{geocentric}$ \\
$z = sin(lat_\mathit{geocentric}) * radius_\mathit{geocentric}$

So far I haven't needed to convert from the cartesian coordinate
system back into any of the polar representations so I haven't derived
that part yet.  However, it should be pretty straightforward.


\section{Scenery Representation}

This section is a work in progress.  I am hashing out ideas as I
write, so please feel free to send me your comments and suggestions.

\subsection{External Scenery Representation}

This section should deal with the external file format(s) that FG can
use for input.

\subsection{Internal Scenery Representation}

This section describes how FG represents, manipulates, and
transforms scenery internally.

Internal, all FG scenery is defined using the coordinate system shown
in figure \ref{fig:coords}.  This means that regardless of the
external scenery representation, FG will convert all object to it's
internal coordinate system when it loads the external file.  Note,
when a default external FG scenery representation is created, its
representation should probably parallel the internal FG representation
as close as possible.  This way, most necessary conversions can then
be done offline in advance.

\subsection{Scenery Partitioning}

For a first stab, scenery will be partitioned along longitude and
latitude lines.  This will form trapezium shaped chunks.  I'd like to
shoot for 10km x 10km chunks.  So, as we move towards the poles, the
width in degrees of these areas will have to increase.  Figure
\ref{fig:trap} shows an exaggerated scenery area.

\begin{figure}[hbt]
  \centerline{                   
      \psfig{file=trap.eps}
  }
  \caption{Scenery Partitioning Scheme}
  \label{fig:trap}
\end{figure}

\subsection{Reference Points}

Each scenery area will have a reference point at the center of its
area.  This reference point (for purposes of avoiding floating point
precision problems) defines the origin of a local coordinate system
which is oriented the same as the global coordinate system.  The only
difference is the origin is translated from the center of the earth to
the center of the individual areas.  Figure \ref{fig:reference}
demonstrates this.

\begin{figure}[hbt]
  \centerline{                   
      \psfig{file=ref.eps}
  }
  \caption{Reference Points and Translations}
  \label{fig:reference}
\end{figure}

All the objects for a specific scenery area will be defined based on
this local coordinate system.  For each scenery area we define a
vector $\vec{\mathbf{a}}$ which represents the distance from the
center of the earth to the local coordinate system.


\subsection{Putting the pieces of scenery together}

To render a scene, the scenery manager will need to load all the
nearby areas.  Also, we define a vector $\vec{\mathbf{v}}$ which
represents the distance from the center of the earth to the current
view point.  Before rendering each scenery area we translate it by
$\vec{\mathbf{a}} - \vec{\mathbf{v}}$.  This moves all the current
scenery areas near the origin, while maintaining the relative
positions and orientations.  All these transformations are inexpensive
to calculate and can be done easily with standard OpenGL calls.

It is straightforward to calculate the proper view point and up vector
so that the scenery will appear right side up when it is rendered.



\end{document}