Advanced raster management speeds disaster response and other mission-critical data to U.S. Air Force operations worldwide.
By Mike Cannon, Dave Williams and Matt Moore, AECOM (http://www.aecom.com/), Virginia Beach, Va.
The U.S. Air Force (USAF) is divided into Major Commands that focus on specific geographic and functional areas. For example, the primary mission of the Air Combat Command (ACC) is to provide global air superiority. The ACC GeoBase program supports geospatial operations for more than 2,000 airfields, a complex mix of geographic and functional domains.
The program provides the infrastructure and tools to collect, manage, analyze and distribute raster imagery and geospatial content to a global audience. Much work has been done to improve the program's rendering speed and availability of Web map and data services. The lessons learned could benefit a wide range of organizations and agencies that distribute similar content.
Serving Imagery on the Web
The Department of Defense (DoD) network is complex, presenting the ACC GeoBase team with many challenges. Limited bandwidth, advanced security requirements and ever-changing network staff are daily factors, leading to many points of failure within the DoD information technology infrastructure. Different groups or agencies control different parts of the network, adding to the complexity. When designing ACC's Web map and data platform, a primary goal was to figure out the best way to serve its content in this environment as fast and reliably as possible.
A traditional Web map service can present potential performance and scalability concerns.
Traditionally, a Web map service sends a georeferenced map image across the Internet from a geographic information system database to a server. That server then uses the map service to generate an image for that extent and sends a URL of the image to a Web viewer interface, which then downloads the image and displays it for the user (Figure 1).
This method presents two potential problems:
Based on the bandwidth capabilities of the client's network and the server's network, map rendering performance may vary from 3 seconds to 60 seconds and in some cases timeout because of poor network conditions.
Scalability can be a concern. For example, 10 users may make a map service request at about the same time. The map service will have to process the requests in the order in which they were received. As a result, the model doesn't scale well, because the network, Web and database servers are taxed in a linear fashion relative to user growth.
There are many ways to improve this capability, including optimizing the map services, upgrading the server or adding an additional server to share the load. Although this may work in the dot-com environment, the DoD network is only as fast as the server's outgoing network pipe. To improve performance, the ACC GeoBase team began to investigate alternatives to the traditional Web map client-server architecture, focusing on the differences between static and dynamic content. Static content is pre-rendered, meaning the server doesn't have to generate the content on request. Dynamic content has to be generated each time the client makes a request. Additionally, static content has a known and discrete URL, which is an important aspect when it comes to network caching.
Cached map tiles can be used to serve content faster than a traditional map service.
Using Static Content
Static content may consist of data that are minutes or years old. The use of static content should be considered for data that don't change faster than the organization is able to generate them. The creation of pre-rendered Web map content, or cache tiles, can be used to serve content faster to an online Web viewing interface because the map service on the server doesn't have to take the time to generate the image; it can just provide the client viewer with a URL to the image for that extent (Figure 2).
Although this is faster than traditional map service communication, there are other methods to improve performance and availability. By building the logic into the client viewer to know which tiles it needs based on extent, ACC GeoBase was able to remove the need to communicate with a map service altogether. The question was still how to get this static content to the client faster. The answer came via the concept of a content delivery network (CDN). The Defense Information System Agency's GIG Content Delivery Service (GCDS), a CDN sometimes referred to as the Fed Cloud, provided this capability. Using the GCDS within the DoD allows for static content to be pushed to servers all over the world based on a client's request.
Edge servers maximize performance by allowing a CDN to deliver map tiles based on a client's location and network speed.
When a Web client makes a request for data on a server, the GCDS can locate the requested data nearest that client based on the client's location and network speed. If the GCDS can't locate the data on one of its nodes or edge servers, it will send the request to the origin (host) server and get the data to the client. At the same time, the GCDS will copy that piece of data to its nodes; the next time a Web client requests the same piece of data, it will pull the data from the most logical edge server (Figure 3).
The GCDS model reduces direct requests to the ACC GeoBase Web servers and improves application performance. In addition, as more users access a particular area, the system gets faster as the map tiles are cached. Although this approach adds more pieces to the puzzle, it reduces the number of failure points because of the ability to reroute to the next closest node if an issue occurs. In some cases, a request never has to go back to the origin server because all the content requested exist on the edge servers. The cached content has a time to live that determines when an edge server needs to go back to the origin server and retrieve updated data. The viewer itself, a flex application, also gets cached on the CDN, which reduces download times.
To use this capability, ACC GeoBase generated cache tiles for most of its sites onto its server. The imagery consists of the most recent image for an area of interest and is updated as new imagery becomes available. It's important to be selective about pre-generated content, because cache tiles take time to generate and in some cases require massive amounts of storage.
Using Dynamic Content
Although a CDN is great for static data, there's still a need to deliver dynamic data as well. Vector data are always changing in the ACC GeoBase database, and users need to see changes quickly. Additionally, some of the imagery is served dynamically to display historical imagery and rarely viewed locations. While the cache tiles show the most recent picture, map services are available to provide an older image of the same location based on date or of low-use sites where it may not make sense to pre-render the tiles.
The ACC GeoBase team established a rule to serve pre-rendered cached tiles by default; then users have the ability to turn on dynamic imagery layers when needed. As a result, by default there are no dynamic interactions between the client and the server”the client just loads the cache tiles as needed for the map extent being viewed. This greatly reduces the number of requests and relieves the server and the network of unnecessary load and communication.
The ACC GeoBase program performed detailed research and testing to implement the most appropriate technology for dynamically serving imagery. In the past, ACC GeoBase used a relational database management system (RDMS) to manage imagery, when at its peak the system contained more than 450 separate raster datasets in a storage footprint of nearly 2 terabytes. Some cons of managing imagery via the RDMS were the large storage footprint of the database and the amount of processing time required to load raster data with no benefit from having them stored within a database. Managing the entire imagery archive through the RDMS didn't seem to be the best practice because of the overhead required to load, store, manage and archive the database. The RDMS eventually proved to be too labor intensive, so ACC looked for another solution.
A file-based image management system was implemented in 2008 to serve all dynamic imagery content. The server-side system leveraged the existing imagery archive and didn't require an analyst to pre-process any imagery to use it. The technology supported a wide array of image formats, and multiple clients could use its services.
The storage footprint of the services used to feed client applications was small, and the processing method was more streamlined than managing the same data in an RDMS. In addition, the speed with which the images rendered in the client applications was faster,
allowing ACC GeoBase to serve its entire 5TB imagery archive instead of smaller subsets. Detailed analysis led to the operational architecture supporting the ACC GeoBase program. The end result includes a mix of technology and Standard Operating Procedures for when to use dynamic and pre-rendered content.
LESSONS LEARNED
Consider ACC GeoBase Program Guidelines
As a result of fine-tuning the ACC GeoBase program, the following set of Standard Operating Procedures were developed that can be applied by a wide range of organizations with similar needs.
Maintain a balance between static and dynamic content.
- Use static content by default, dynamic content on request.
- Web map services have all dynamic layers off by default.
- Users interact with a pre-generated Table of Contents (TOC) to make layers visible.
Reduce callbacks to the server.
- Use the least amount of communication back to the server
- Create a smarter client viewer, with more functionality on the client side.
Take advantage of static whenever possible.
- Application files, configs, scripts, TOCs and images can be considered static content.
- Cache tiles.
Upon following these rules, ACC GeoBase's users increased from an average of 100 a week to 5,000. The improvements have been most noticeable during emergencies. For example, after the January 2010 Haiti earthquake, ACC GeoBase was better prepared to deal with nearly triple the amount of normal usage to support relief operations.
By leveraging dynamic imagery immediately for emergency responders, then building the same information into pre-rendered cache tiles, users gained fast access to detailed imagery depicting changing ground conditions. Weekly and even daily pre-rendered cache tiles were updated, and the dynamic historical imagery showed the rapid changes occurring in different locations in Haiti, leading to improved decision making.
