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.
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,
This paper will also address how the
World Wind project faces numerous challenges forward. This paper formats it into files, and distributes it via the internet out to end users requesting it via World Wind which is running on addresses some of the issues World
Wind faces and proposes solutions, based on the author’s research, for 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] 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]
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 galaxies. More than 10 million users from over 100 nations have used World
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 safetycritical 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 SQLbased 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.
worldwind data.com/
[7] Server Information http://radar.oreilly.com/archives/2006/04/dat abase_war_stories_4_nasa_wo.html
[8] Ogre Rendering Engine www.
ogre 3d.org/
[9] Lua Information www.lua.org