--- /dev/null
+%
+% `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}
+
projects / flightgear.git / commitdiff