Elevation datasets will remain relatively small, in the hundreds of MBs." NASA plans to deliver at least 250 times more Lunar and Mars data from the latest LRO (Lunar Reconnaissance Orbiter) and MRO (Mars Reconnaissance Orbiter) satellites. Imagery datasets will grow and rather quickly. Once you go to the submeter resolution, these numbers quadruple a couple times. When I asked him about the scale and type of data his application manages and its growth rates, Patrick wrote: "On our own servers, we serve a couple Terabytes worth of imagery for each Earth dataset (and there are several of these) for just 15-meter coverage. The intent is to allow plugins to be used as interchangeably as possible, i.e. These implementations (.NET and Java) that will remain structurally identical. I guess the biggest news is that we will have a 'shared' architecture of NET and Java technologies that will allow for much greater speed in the product development cycle. ![]() It is interesting to watch the advances being made by the. ![]() An API-centric architecture, with all functionalities as modular components, which is how we are refactoring the implementation, would have saved us some rework. Moving towards a more efficient and consistent solution, like a light-weight SQL database might solve a couple issues, but could add a level of complexity above and beyond our current system, which enjoys a fairly easy-to-understand structure. This method basically relies on the underlying OS to handle the "database", and this leaves room for irregularities, which we have experienced. In response to my question about lessons learned in managing their data store, Patrick wrote: "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. World Wind already delivers data via WMS." 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." 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |