NASA World Wind Open Source

Project
Caylyne A. Shelton
Embry-Riddle Aeronautical University
600 S. Clyde Morris Blvd.
Daytona Beach, FL 32114 USA

This paper covers the NASA World
Wind Open Source project as a soft
real-time system. Modifications in
design and implementation are done
daily to improve upon both the
performance capabilities as well as
feature and cache pack additions.
This paper will also address how the
World Wind project faces numerous
challenges forward. This paper
addresses some of the issues World
Wind faces and proposes solutions,
based on the author’s research, for
improvements that any end user can
implement on their own, as well as
provides information on what NASA
and the NSF are doing to resolve
issues with the image database server
on that side of the spectrum. This
paper will then cover more plans for
feature additions to World Wind. [5]
galaxies. More than 10 million users
from over 100 nations have used World
Wind since NASA first released it in
2005 and more than 100,000 new users
download it each week. The high-level
concept of how World Wind Works is
fairly simple to understand. NASA
receives satellite imagery on the ground,
formats it into files, and distributes it via
the internet out to end users requesting it
via World Wind which is running on
their local computers. See figure 1 for
an illustration. World Wind is used to
display satellite imagery of the Earth,
Moon, Venus, Mars, Jupiter, and Stars
and Galaxies far away from our own. [5]

Introduction
NASA World Wind is an open
source project funded by the National
Aeronautics and Space Administration
(NASA) and the National Science
Foundation (NSF) that allows visually
rich, interactive exploratory movement
around the Earth and its surface, Moon,
and other planets, as well as other
Figure 1
Using World Wind and How it
Works
As mentioned in the introduction
of this paper, NASA database imagery
servers receive sattelite imagery from
sattelites currently in orbit (Moderate
Resolution Imaging Spectrometer data is
receieved from NASA’s Aqua sattelite,
for example), as well as by previous
space exploration projects dating back as
far as 1989 (data from the Magellan
spacecraft that orbited Venus from 1989
through 1994, for example). The fastest
retrieval time for real-time imagery from
orbiting sattelites is about one hour. [5]
The recommended system
requirements for a computer to run
World Wind are as follows:
 3D Graphics Card- nvidia, ATI,
Intel, SIS, S3, and Matrox have
all been tested with World Wind
and work well.
 1.4 GHz CPU
 256 MB RAM
 Windows 2000, Windows 2003,
Windows XP, or Windows Vista
operating system
 DSL or Cable internet connection
 For World Wind Java:
o Eclipse 3.3 M7
o Java 1.6.0
 For World Wind in C++:
o .Net Framework 2.0
o Managed DirectX 9.0c
End users may choose from the
original World Wind open source project
that is coded in C++ with the Microsoft
Visual Studio development environment,
or the recently released World Wind
Java, which runs on Macintosh and
Linux computers. Both of which offer
many benefits and cache packs. World
Wind in C++, however, offers something
very beneficial to end users- that is
thorough documentation available
online. Documentation for World Wind
Java is currently limited in volume
online, as it is fairly new.[3] Both
projects have numerous forums available
online, and the World Wind Wiki
website is a good information repository
for someone just starting to work with
World Wind. Both the C++ and Java
implemented World Wind projects’
source code can be downloaded from the
SourceForge website. [1] The World
Wind program portion that comprises the
basic World Wind functionality is only
five megabytes in size total, and the
basic imagery that accompanies it totals
50 megabytes in size. [3]
A set of Earth imagery files is
provided with the World Wind
download, called Blue Marble. This
could be considered the “foundation” for
Earth surface images in World Wind.
Cache packs are collections files that
display various sets of imagery data.
Add-on packs, which can be downloaded
from the WorldWindData website, do
not include all of the imagery files in
cache packs. Add-on packs are the
software plug-ins that enable the user to
view numerous other features in World
Wind, and they use cache packs specific
to their functionality. For example,
Earthquake is an add-on pack that
provides displays of earthquakes that
have occurred and is updated once per
week with RSS feeds from United States
Geological Survey Data Topography
Maps with earthquake data for quakes of
magnitudes greater than 2.5. Figure 2
shows a screen shot of World Wind
running the Earthquake plug-in. The
following provides more add-on packs
available to use with World Wind (please
note that there are still many more than
these): NLT Landsat 7, Earthsat
Geocover 2000, Clementine 40xx, and
Blue Marble Next Generation
Topography plus Bathymetry. [3]

Figure 2
When a user loads World Wind,
the Blue Marble cache pack is loaded.
Before any cache pack is loaded, World
Wind checks with NASA servers for the
most recent imagery files for the cache
pack. If more recent files exist on the
server, world wind will replace local
copies with more recent copies from the
respective remote server. The file
structure for storing cache pack files
locally is handled by the end-user’s
operating system. A configuration
setting can also be changed to prevent
World Wind from updating cache packs
on load. Cache packs are loaded in
layers, with Blue Marble being the first
layer. Image display in done in what is
referred to as a “tile” format. Each
image data file is a “tile” that loads in
World Wind. All tiles for any given
cache pack load to construct a “layer of
tiles”. The result is what appears to a
user as a single image of a large physical
range, when it is actually millions of
images. Images are typically around
20KB in size a piece. [3]
The term “cache size” in World
Wind is used to describe the amount of
cache data that can be loaded into World
Wind at one time. When a user needs
cache that is not currently loaded, World
Wind must access the proper data image
server in real-time to retrieve the cache
data needed. Many users change the
cache size to a larger number, permitting
more cache to be stored at a time, and
preventing the lag that can be
experienced when World Wind retrieves
cache data on the fly from imagery
servers. Changing the cache size to hold
more cache can also have repercussions-
users may experience lag as World Wind
searches through the loaded cache pack
if the cache size is too large. [3]
Code analysis was done on
World Wind Java to determine how the
multi-threaded system handles numerous
tasks in real-time. A task queue contains
all tasks that are currently waiting to run.
If the queue becomes full and tasks get
rejected, each rejected task is logged.
Each task has a primary and a secondary
priority assigned to it. Tasks waiting to
run are categorized by the time frame
stamp which they requested to run. All
tasks waiting to run within the same time
frame are ordered to run from those with
the highest priorities first, and then down
from there. If a task’s wait time exceeds
the maximum wait time allowable and
still has not run, it will simply be deleted
and will not ever run. The maximum
wait time for a task is two seconds.
Lower priority tasks must relinquish a
resource if a higher priority task with
same time frame stamp requests it.
Duplicate tasks are not allowed to enter
the wait queue. World Wind Java
utilizes the java.util.concurrent class for
thread handling. [3]
Imagery databases each hold
billions of images, or in some cases
references to billions of images.
Demand on image-serving databases is
very intense most of the time (more than
10 million requests daily), as World
Wind interest has spread worldwide and
the project’s popularity is growing daily.
A user could so much as change the view
direction in World Wind and need
dozens of images immediately. World
Wind servers rely on SQL-based
databases to store imagery. To provide
an example of how much imagery is
provided on just one single server,
consider this: to view one of the sets of
the Earth’s surface imagery in 15 meter
granularity, it would take a server with a
couple of terabytes worth of imagery.
Take that a step further, and go to the sub
meter granularity and that couple of
terabytes quadruples a couple of times
for the amount of imagery on that server.
The following list covers the existing
NASA imagery servers: NASA Learning
Technologies at NASA Ames Research
Center,
Tileservice.worldwindcentral.org,
TerraServer-USA, MODIS Rapid
Response Project, NASA Goddard Space
Flight Center, and SVS Image Server at
NASA Goddard Space Flight Center. [7]
World Wind Issues and Proposed
Solutions
The fastest rate at which users
can receive imagery data from sattelites
in orbit now resides somewhere around
an hour. If there were a way to speed up
this process, end-users could rely on
World Wind to get information on items
such as current weather conditions
anywhere in the world (fires, floods,
etc.)- thus possibly making World
Wind’s information provision safety-
critical for those relying on the integrity
and timeliness of it’s data. Increasing
World Wind’s speed of data delivery
would need to start with the first data
transmission- from satellites in orbit to
NASA servers. After some
brainstorming on this issue, scientists
determined the only definite way to get
all of the Earth’s surface data faster
would be to have image data collection
over a much wider area from space by
using a “net” of satellite all gathering
image data simultaneously. This is not a
feasible option right now. In the future,
however, sattelites may be equipped
with more image gathering devices to
gather more image data concurrently.
NASA currently faces another
issue hindering data imagery delivery to
client systems of end-users: imagery
servers are increasingly becoming
bogged down with client requests for
images. NASA is actually in the
progress of implementing their solution
to this problem- refactoring the
implementation of their databases.
Currently in use are traditional SQL-
based databases and data delivery to
end-users via the Web Mapping Server
(WMS) protocol. Very soon, imagery
data will all be vector based and will
deliver data via the Web Feature Server
(WFS) protocol. [7]
Two other issues on the end-user
side are that many users in World Wind
forums have reported seeing are results
of the cache size. Users want larger
cache size so that they do not experience
lag because they will not need to retrieve
cache from imagery servers as often, and
then some users make the cache size so
large that their local system lags. The
resolution is simply to find a cache size
that is large enough to please the user
and does not make their specific
machine lag. Each user’s computer is
different, and their can not be a single
cache size number that will work for all.
The cache size is set in an *.xml
configuration file that is read when
World Wind loads. If the configuration
of the cache could be changed and
implemented while World Wind was
running, the user could change the cache
size whenever he/she would like.
Making the cache size changeable on the
fly could be implemented by using a
scripting language instead of an *.xml
file. The suggested scripting language is
Lua for it’s simplicity. By creating a
Lua file containing the cache size, C++
code can access it at any time without
needing to load an entire file. The user
can simple change the Lua file and save
it. The C++ code would need a wrapper
class for interfacing with Lua, many
source code examples of this exist on the
internet. Lua interfaces with C++ with a
simple stack of any combination data
types the C++ code uses- the C++ code
calls a Lua function from the Lua file to
retieve data and Lua pushes the data
onto a stack, then the C++ code pops the
data from the stack. Implementing
World Wind configuration via Lua
would allow users to change the cache
size and many other configuration
settings on the fly. [9]
Another option that needs further
investigation is to have an
implementation that will compress
imagery files as they are retrieved from
imagery servers and only “decompress”
files that are needed by World Wind at
that moment in time. “Decompressed”
files would not actually get
decompressed- their data is read and
wrote into a temporary file that is
deleted once they are not longer in use.
This is modeled after the functionality
that already exists in the open source
graphics rendering engine, Ogre. [8]
Another issue that end-users face
with World Wind Java is the lack of
online documentation. Doxygen was
used to document the C++ World Wind
and is an excellent choice for the Java
version as well. Doxygen generates
documentation for code that follows a
strict code commenting standard. The
code in World Wind Java already has
comments that conform to the Doxygen
commenting standard, so this solution
may actually be in-progress. [3]
Plans for Future World Wind
Development
More detailed image resolution is
one of many of the plans that NASA has
for World Wind expansion. Granularity
of images in World Wind in the future
will yield very detailed results. Also,
there are plans to develop local RSS
news feeds that will display when a user
zooms into a certain granularity on the
Earth’s surface. Other suggestions for
World Wind development include the
following: integrating World Wind with
flight plans, integrate with Google and
do searches for specific locations,
follow-up with more features to the
Flight Simulator software that World
Wind has already integrated with.
NASA’s plans for imagery expansion
include at least 250 more Lunar and
Mars data from the latest Lunar
Reconnaissance Orbiter (LRO) and Mars
Reconnaissance Orbiter (MRO).The
possibilities for expansion are as
limitless. The ultimate goal, slated for
many years from now, is 100’s of
different World Wind programs. [3]
Conclusions
 NASA World Wind is an open
source software project that has a lot to
offer and will remain this way for some
time. Users can view views of Earth
from space or from the surface, view the
moon, planets, and very distant galaxies
from their own personal computers.
World Wind Java opened up the ability
for Macintosh and Linux users to utilize
the features of World Wind as well.

World Wind has issues, some of

which already have solutions in the
works. A scripting language for
configuration would be a simple way to
make World Wind much more dynamic.
NASA is working towards improving
their imagery database architecture to
reduce the time elapsed for clients to
retrieve images. Compressing imagery
files and only “decompressing” those
needed at the time will reduce the
amount of disk space consumed, while
increasing the amount of imagery data
that can reside locally.
As the number of World Wind
users multiplies, more and more people
will contribute to new feature ideas as
well as resolutions for known issues.
 References

[1] NASA World Wind Downloads

http://sourceforge.net/project/showfiles.p
hp?group_id=69528

[2] Online Demo of World Wind

http://worldwind.arc.nasa.gov/java/index
.html

[3] World Wind Wiki

http://www.worldwindcentral.com/wiki/
Main_page

[4] MODIS Pictures and Information

http://rapidfire.sci.gsfc.nasa.gov/realtime
/2007298/

[5] World Wind Home Page

http://worldwind.arc.nasa.gov/

[6] Cache Packs

www.worldwinddata.com/

[7] Server Information

http://radar.oreilly.com/archives/2006/04/dat
abase_war_stories_4_nasa_wo.html

[8] Ogre Rendering Engine

www.ogre3d.org/

[9] Lua Information

www.lua.org