However, on the server side of things, World Wind enabled servers have relied on SQL-based databases to store imagery and will soon in-the near future deliver vector-based data via the WFS protocol. The client depends mostly on flat-file stores to maintain data. On the client side of World Wind, there is very limited use of traditional SQL-based databases. Dozens of images could be needed immediately with each small change in the user's view direction. Each image, although typically ~20KB can also be megabytes in size.ĭemand on the image-serving database is bursty and intense. In an application like World Wind, which displays many different kinds of large ranges, the database must hold billions of images (Gigaimages) or references to them. I asked: "Tell me about your database architecture for NASA World Wind." Patrick replied: "What appears to the user as a single image of a very large physical range really consists of millions of images. Flat files are used for quick response on the client side, while on the server side, SQL databases store both imagery (and soon to come, vector files.) However, he admits that "using file stores, especially when a large number of files are present (millions) has proven to be fairly inconsistent across multiple OS and hardware platforms."
#NASA WORLD WIND CODE#
The source code links below reference the initial commit to GitHub and are incorrect.Patrick Hogan of NASA World Wind, an open source program that does many of the same things as Google Earth, uses both flat files and SQL databases in his application. Subversion hosts the original v1.2.0 source code. This archived World Wind Java release has been migrated to GitHub from the World Wind Subversion server. The release 1.2 webinar slides are available for download. The bug database describes all such known problems. All other platform dependencies are related to specific problems, such as the existence of a bug on one platform but not another. The most significant one is the absence of BrowserBalloon availability on Linux. There are very few platform-specific dependencies. It is expected to work on Solaris but has not been tested on that platform.
#NASA WORLD WIND WINDOWS#
This release of World Wind operates on all platforms World Wind has historically supported: OS X, Windows 32 & 64, Linux 32 & 64. It also initiates a portal - that gathers into one place all information relative to understanding and using World Wind and its API. It’s undergone significant testing and contains important documentation that was missing from the previous “pre-alpha” daily releases. World Wind’s first public formal release. This release positions WorldWind Java to begin adding new functionality in the near future, please watch this repository for further updates.
Removing deprecated functionality like WebStart, Applets and WebView.
Discussions around the types of changes that need to be made when moving from 8 to 11 are broadly available on the Web. For example, setting the java library path system property.
#NASA WORLD WIND UPGRADE#
The decision was made to upgrade WWJ to Java 11 based on questionable support options for Java 8 at the time. The prior release of WorldWind Java, v2.1.0, was compiled with Java 8. WorldWind's API remains largely unchanged in this release and we are committed to maintaining a consistent API in future releases. Deprecation of unsupported functionality such as Applets, WebStart and WebView.During this process some defects were addressed as well. The primary goal of the WorldWind Java (WWJ) v2.2.0 release is to modernize the SDK after a period of inactivity.
0 kommentar(er)
