# Presentation: 154721

## “OnEarth” WMS ServerWMS Global Mosaic

- Lucian Plesea
- Jet Propulsion Laboratory
- California Institute of Technology

## WMS Global Mosaic

- Landsat 7, 9 band half arc-second, global earth image mosaic.
- This mosaic has 3600 times more pixels than previous global earth images, at 15m per pixel.
- This mosaic contains about three trillion pixels, and more than five Terabytes of data.

## WMS Global Mosaic

## Atacama Desert, South America, Default View (IR and Visual)

## Atacama Desert, South America, IR View

## Atacama Desert, South America, Visual View

## The Mosaic Project

- NASA is engaged in an effort to increase the accessibility of remote imagery and encourage interoperable tools.
- The availability of a recent, high resolution, global coverage map of the earth was seen as an important component of this effort.
- The project started in earnest in Jan 2003, with an expected completion date of Dec 2003
- Release One on-line since April 2004

## WMS Global Mosaic Vitals

- There are nine separate bands, at three different resolutions. Coverage area is 180W to 180E and S85 to N85.
- 600 GB, panchromatic band, 0.5 arc-second (15m), 2,592,000x1,224,000, or 3 trillion pixel.
- 50 GB, thermal band, high and low gain, 2 arc-second per pixel (60m).
- 900GB, three visual and three near IR bands, stored at 1 arc-second (30m).

## Current Activities

- Second phase started Jan 2005
- Generate a new release of the mosaic:
- Use the final scene set (50% new)
- Improved geolocation
- Better color matching
- Package for distribution
- Monochrome GeoTIFF

## Application

- An image mosaic builder for very large geographic datasets, applying in a single pass the coordinate transformation, color correction and scene blending.
- Unique capabilities include UTM to geographical reprojection , blend mask driven data selection and feathering, and per band first order polynomial color correction.
- Implemented as a single pass chain of custom SGI Image Library Operators.

## Internal Data Format

- A Journaling Image File Format is used extensively, for both the input scenes and the output mosaic.
- It is a tiled, 4D, multi-spectral and multi-resolution file format that supports lossless and lossy compression at the tile level.
- A level of indirection in data access, adding journaling features which ensures permanent file consistency

## Data Access

- Computation resources are located remote from the storage resources, direct access to the data is not always possible.
- An image specific data access subsystem allows small regions of the input and output images to be transferred independently. The Network Image Protocol is used, separating the location and specific file format from the application.
- Basis for dataset virtualization via processing data servers

## Computation Resource

- Four groups of 32 CPUs were running simultaneously on an SGI O3K to produce the mosaic, using about 50000 CPU-hours total.
- This architecture provided a balance of data access and computational loads, achieving a CPU load between 30 and 60 percent.
- Using a 15MB/second link, peak data transfer rates of 12MB/second were measured, with an average of 2.5MB/sec data read and 1.25MB/sec data write

## Large storage is no longer a big problem.
Raid Again Storage using Commodity Hardware And Linux RASCHAL, a 40TB NAS storage cluster, built in-house.
RASCHAL became operational April 2003, and has been in continuous use since then.
OnEarth uses about 15TBytes

- Raid Again Storage using Commodity Hardware And Linux RASCHAL, a 40TB NAS storage cluster, built in-house.
- RASCHAL became operational April 2003, and has been in continuous use since then.
- OnEarth uses about 15TBytes

- OnEarth Server Hardware

## Access to data: WMS

- Access to the mosaic is best done via the WMS server. A simple web client is available at http://OnEarth.jpl.nasa.gov
- The server is implemented as a CGI application, and uses the same technologies as the mosaic application.
- Server provides color pan-sharpening, band selection, multiple projections.
- Image control using Styled Layer Descriptor.

## GTOPO30PLUS derived colormap draped on GTOPO30P

- Hawaiian islands, color bands are 500m thick.
- Red - Water level, Blue +- 2500m, Green – 5000m

**Notes:**
Basic architectural view. Two Linux machines hold a copy of the Global Mosaic each.
The virtual image server hosted on each one of them scales the multiple resolution to a virtual 9 band at 0.5 arc-second single image. There are two of them for performance and reliability, there can be more. The image data flow using the network protocol is represented by the red arrows. The image network client built into the OnEarth WMS Server picks a random server for each request. If the connection is refused, it switches to the next one.
Blue boxes are software, green ones are hardware. Yellow circles are disks. On the local disks, regular datasets are hosted. The WMS Server code can’t tell if the file is local or if it is a virtual image server. The Global Mosaic Server decompresses (and scales if required) the data before sending it to the WMS server. The WMS server has handled whole hours of 4 WMS requests per second  traffic and 150,000 per day, and data rates of 30MB/sec have been seen on the  Image Network protocol side (over a single GigE).
WMS-Proxy is an apache 2.0 module. It runs in the memory space of the HTTP server itself, it is persistent and multithreaded. It serves ready made image files from a cache, based on a request pattern. It can also trigger the addition of new data to the cache. It can serve more than 100 times more requests than the regular CGI server, current access rate is close to 2.4 million hits per day. Latency is also extremely small, in the millisecond range.
The WMS cache format is known to the Image Access Layer, making it possible to re-apply all the facilities provided by the full WMS server.

## Tule fog in California Central Valley

- Mosaic is built from 250m Rapid Response MODIS subsets, one day old data. Two mosaics each day, from Terra and Aqua

**Notes:**
Basic architectural view. Two Linux machines hold a copy of the Global Mosaic each.
The virtual image server hosted on each one of them scales the multiple resolution to a virtual 9 band at 0.5 arc-second single image. There are two of them for performance and reliability, there can be more. The image data flow using the network protocol is represented by the red arrows. The image network client built into the OnEarth WMS Server picks a random server for each request. If the connection is refused, it switches to the next one.
Blue boxes are software, green ones are hardware. Yellow circles are disks. On the local disks, regular datasets are hosted. The WMS Server code can’t tell if the file is local or if it is a virtual image server. The Global Mosaic Server decompresses (and scales if required) the data before sending it to the WMS server. The WMS server has handled whole hours of 4 WMS requests per second  traffic and 150,000 per day, and data rates of 30MB/sec have been seen on the  Image Network protocol side (over a single GigE).
WMS-Proxy is an apache 2.0 module. It runs in the memory space of the HTTP server itself, it is persistent and multithreaded. It serves ready made image files from a cache, based on a request pattern. It can also trigger the addition of new data to the cache. It can serve more than 100 times more requests than the regular CGI server, current access rate is close to 2.4 million hits per day. Latency is also extremely small, in the millisecond range.
The WMS cache format is known to the Image Access Layer, making it possible to re-apply all the facilities provided by the full WMS server.

## Small dam and lake in Romanian AlpsLeft image was taken during a commercial fligh, the right image is generated by WorldWind using the OnEarth server for Landsat and

- elevation.

**Notes:**
Basic architectural view. Two Linux machines hold a copy of the Global Mosaic each.
The virtual image server hosted on each one of them scales the multiple resolution to a virtual 9 band at 0.5 arc-second single image. There are two of them for performance and reliability, there can be more. The image data flow using the network protocol is represented by the red arrows. The image network client built into the OnEarth WMS Server picks a random server for each request. If the connection is refused, it switches to the next one.
Blue boxes are software, green ones are hardware. Yellow circles are disks. On the local disks, regular datasets are hosted. The WMS Server code can’t tell if the file is local or if it is a virtual image server. The Global Mosaic Server decompresses (and scales if required) the data before sending it to the WMS server. The WMS server has handled whole hours of 4 WMS requests per second  traffic and 150,000 per day, and data rates of 30MB/sec have been seen on the  Image Network protocol side (over a single GigE).
WMS-Proxy is an apache 2.0 module. It runs in the memory space of the HTTP server itself, it is persistent and multithreaded. It serves ready made image files from a cache, based on a request pattern. It can also trigger the addition of new data to the cache. It can serve more than 100 times more requests than the regular CGI server, current access rate is close to 2.4 million hits per day. Latency is also extremely small, in the millisecond range.
The WMS cache format is known to the Image Access Layer, making it possible to re-apply all the facilities provided by the full WMS server.

## OnEarth WMS Server Architecture

**WMS-Proxy**
- High performance path
- Apache plug-in for high volume predictable
- pattern access

**WMS CGI Application**
- Single binary complete WMS server

**Apache 2.0 HTTP Server**

**Image Access Layer**
- Location and format agnostic data access

- WMS cache

- Local datasets

- Virtual datasets

- Global Mosaic
- Server

_**OnEarth WMS Server Architecture**_

**Notes:**
Basic architectural view. Two Linux machines hold a copy of the Global Mosaic each.
The virtual image server hosted on each one of them scales the multiple resolution to a virtual 9 band at 0.5 arc-second single image. There are two of them for performance and reliability, there can be more. The image data flow using the network protocol is represented by the red arrows. The image network client built into the OnEarth WMS Server picks a random server for each request. If the connection is refused, it switches to the next one.
Blue boxes are software, green ones are hardware. Yellow circles are disks. On the local disks, regular datasets are hosted. The WMS Server code can’t tell if the file is local or if it is a virtual image server. The Global Mosaic Server decompresses (and scales if required) the data before sending it to the WMS server. The WMS server has handled whole hours of 4 WMS requests per second  traffic and 150,000 per day, and data rates of 30MB/sec have been seen on the  Image Network protocol side (over a single GigE).
WMS-Proxy is an apache 2.0 module. It runs in the memory space of the HTTP server itself, it is persistent and multithreaded. It serves ready made image files from a cache, based on a request pattern. It can also trigger the addition of new data to the cache. It can serve more than 100 times more requests than the regular CGI server, current access rate is close to 2.4 million hits per day. Latency is also extremely small, in the millisecond range.
The WMS cache format is known to the Image Access Layer, making it possible to re-apply all the facilities provided by the full WMS server.

## Cache access patterns for the 120m per pixel layer in WorldWind

- White – cached data; Black – not requested; Gray – no data

**Notes:**
Basic architectural view. Two Linux machines hold a copy of the Global Mosaic each.
The virtual image server hosted on each one of them scales the multiple resolution to a virtual 9 band at 0.5 arc-second single image. There are two of them for performance and reliability, there can be more. The image data flow using the network protocol is represented by the red arrows. The image network client built into the OnEarth WMS Server picks a random server for each request. If the connection is refused, it switches to the next one.
Blue boxes are software, green ones are hardware. Yellow circles are disks. On the local disks, regular datasets are hosted. The WMS Server code can’t tell if the file is local or if it is a virtual image server. The Global Mosaic Server decompresses (and scales if required) the data before sending it to the WMS server. The WMS server has handled whole hours of 4 WMS requests per second  traffic and 150,000 per day, and data rates of 30MB/sec have been seen on the  Image Network protocol side (over a single GigE).
WMS-Proxy is an apache 2.0 module. It runs in the memory space of the HTTP server itself, it is persistent and multithreaded. It serves ready made image files from a cache, based on a request pattern. It can also trigger the addition of new data to the cache. It can serve more than 100 times more requests than the regular CGI server, current access rate is close to 2.4 million hits per day. Latency is also extremely small, in the millisecond range.
The WMS cache format is known to the Image Access Layer, making it possible to re-apply all the facilities provided by the full WMS server.

## Other Web Clients

- http://www.wmsviewer.com/main.asp
- Windows based freeware browser
- http://geoview.edina.ac.uk/JPL/index.jsp
- Educational
- http://esg.gsfc.nasa.gov
- Earth Sun Gateway
- http://mapserver.gis.umn.edu/
- Freeware server
- ESRI products, http://esri.com
- Commercial GIS software
- WorldWind, http://WorldWind.arc.nasa.gov
- Freeware, public, generates 3 million hits per day
- SINTEF Globe, http://globe.sintef.no
- Public software, Java 3D

## Contact information:

- Web front - http://onearth.jpl.nasa.gov
- WMS server – http://wms.jpl.nasa.gov/wms.cgi
- Lucian.Plesea@jpl.nasa.gov