NASA World Wind Open Source Project



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]

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 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]

[pic]

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., 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



[2] Online Demo of World Wind



[3] World Wind Wiki



[4] MODIS Pictures and Information



[5] World Wind Home Page



[6] Cache Packs



[7] Server Information

[8] Ogre Rendering Engine



[9] Lua Information



................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download