ArcUser Online

• ArcUser Main
• Current Issue
• Previous Issues
• Subscribe
• Advertise
• Submit an Article

From Design to Deployment

ArcGIS 10 apps in the cloud

By Brian Noyle and Dave Bouwman, DTSAgile

This article as a PDF.

Editor's note: In the last issue of ArcUser, the authors described some of the Flex API customization work they have done for the U.S. Department of Agriculture Forest Service Forest Health Technology Enterprise Team (FHTET) in "Remix Those Sample Viewers: Elevate your RIA and stand out from the crowd." This article details work they have done on applications that make FHTET information more accessible internally and externally.

Historically, the FHTET team has collected and analyzed data describing the effects of major forest pests on the landscape and disseminated this information through an annual hard-copy report. This article describes a custom application the team deployed to the cloud to make this information available to a wider audience.

While GIS and hard-copy maps play a role in the preparation of the FHTET report on the effects of major forest pests, this static report does not fully leverage the data exploration and analysis tools available from today's GeoWeb applications. A current software development initiative is using ArcGIS Server 10 and the Flex API to create a series of rich Internet applications (RIAs) facilitating the distribution of information on forest health to a variety of audiences. In addition, the FHTET team elected to use this initiative as a test bed for assessing the ease and speed with which custom applications can be deployed to the Amazon Web Services (AWS) cloud with ArcGIS 10 for greater scalability and convenience.

Given the richness of the FHTET data and the desire for novel user experience (UX) elements in the applications, FHTET has elected to pursue a fully custom Web implementation based on Esri ArcGIS Server 10 and the Flex API with many custom widgets and extensions of the DynamicMapServiceLayer. We have based our implementation on our considerable experience in customizing Esri's Flex Starter Kit to produce a template that will now serve as the starting point for many Flex-based applications leveraging ArcGIS Server 10.

The Forest Pest Conditions Viewer

A FHTET Forest Pest Conditions Viewer public application (fhtet.dtsagile.com/fhtet/Flex/FPC#) was first developed to help public users explore the impact of many forest pests for different forest service regions. The quantities and types of pests displayed in the Flex application can be configured by each forest service region so that users can see the "top" pests for a given region, based on the decisions and experience of forest health professionals.

Because the application is designed primarily as a data exploration tool, only minimal interaction is required of the user. Once a region, state, or county is selected, the application makes a service call to get updated data as JSON and renders the results for the user. Region and county selection can be done on the map or from pick lists in the search pane located on the left side of the page. Bar charts prominently displayed across the bottom of the map show the acreage and number of counties affected by each pest. Data summaries and links to external information are also provided in the dockable left pane. A function that generates a chart showing pest damage trends for all years in the system is included in the tabular data summaries. Users can also view information on specific pests, generate preformatted pest reports, and export raw data in CSV format.

The Disturbance Mapper

In addition to the public data explorer, FHTET has deployed a secured Disturbance Mapper Application designed to use remotely sensed data for detecting the presence of pests in the landscape. The application is targeted at individuals who perform statewide and regional flight planning for aerial pest surveys. Its goal is optimizing flight planning and reducing total costs for aerial pest surveys by allowing planners to target areas of interest through map exploration in a Web browser.

Areas of interest for pest surveys are identified based on change detection data from Moderate Resolution Imaging Spectroradiometer (MODIS) preprocessed imagery. Custom map layer extensions for extending the DynamicMapServiceLayer have been implemented that allow flight planners to adjust threshold settings on the change detection imagery to view differences in forest green-up and senescence that signal the presence of tree stressors.

Migrating to the Cloud: It's as Easy as�

As this article was being written, Esri announced the availability of a cloud-based solution for ArcGIS Server. Based in the AWS cloud, this deployment option provides Amazon Machine Images (AMIs) preloaded with ArcGIS Server for Esri customers who want quick deployment, scalability, and flexibility in their GIS infrastructure.

What do we—as architects and developers—need to know to be ready to deploy our custom ArcGIS Server apps to the cloud? The first thing you need to know is that the process is just plain easy and will require just a few tweaks of your normal deployment patterns for custom apps built against ArcGIS Server. The accompanying diagram maps major system components in a typical example of an ArcGIS Server solution to major system components used in an ArcGIS Server 10/AWS cloud implementation.

Once an ArcGIS Server 10 AMI has been launched in the Amazon cloud and sufficient storage space has been purchased and configured, the deployment of an on-premises application to the cloud is very straightforward. After RDP-ing [i.e., using remote desktop protocol] to the running AMI, the developer simply pulls in the deployed application (via FTP or using copy/paste for small items) and updates any configuration settings.

The DBMS instance (Microsoft SQL Server in our example) supporting the application is detached from the on-premises deployment database server, copied to the AMI, and reattached as a SQL Express instance (still well under the 4 GB size limit).

In our deployment of this application, we split our geodatabase into operational and base layers. Base layers that do not get edited are stored in a file geodatabase on the AMI, guaranteeing acceptable performance, while operational layers that are editable are stored in an instance of ArcSDE Workgroup on SQL Server Express.

Finally, any map documents required to support the ArcGIS Server map services are copied to the AMI, and the data sources are reset to reflect the new data locations. It is really just that easy and straightforward.

What About That Data Thing?

Some readers may be asking themselves why our migration story splits a perfectly good enterprise geodatabase running against SQL Server into a file geodatabase and workgroup instance of ArcSDE. The answer is that enterprise geodatabases are supported by another type of AMI in the cloud. For our test bed project, another AMI meant more money. In addition, the enterprise geodatabase AMI is PostgreSQL based. While the migration process does not involve any magic, it would have required a little more time and effort to get our tabular data in there, so we elected to store static layers in a file geodatabase to guarantee acceptable performance and store editable layers in a workgroup ArcSDE instance running against SQL Express on our existing AMI, which was safely under the 4 GB file size limit. There are no tile caches used in this test bed deployment.

Conclusion

The cloud-based deployment available under ArcGIS 10 is sure to present an excellent option to organizations that have wished for more scalability and flexibility in their existing ArcGIS Server infrastructure. Our experience to date has shown us that, for organizations where rapid deployment is critical, ArcGIS Server AMIs can be deployed in approximately 20 minutes (exclusive of the time needed for data and application loading and configuration). The ability to create additional AMIs from an already configured instance, when coupled with the Amazon Load Balancer, means that gaining capacity rapidly when necessary is a real benefit of this new development in the Esri product stack.

This scalability on demand, when viewed against the backdrop of the typical software and hardware procurement process in many organizations, is a very real benefit. Furthermore, the flexibility this provides to organizations, through the capability to deploy this additional capacity on demand—rather than having multiple ArcGIS Servers sit idle awaiting the next emergency response event or natural disaster—reinforces this benefit.

About the Authors

Brian Noyle, originally trained as a global change biologist and tundra botanist, has nearly 10 years of experience as a GIS software developer and architect. His professional and technical interests are primarily focused on moving clients toward more standard architecture and development practices and patterns to facilitate a closer integration of GIS with the standard IT enterprise. Noyle has extensive experience in full software life cycle management with a focus on delivering through Agile project management methods.

Dave Bouwman has been designing and developing GIS software for the last 12 years, with projects ranging from small Web sites to statewide enterprise forest management systems. Over the last few years, he has been leading a team of developers in the pursuit of great software built in a sane manner. The combination of an Agile process with pragmatic development practices taken from extreme programming has led to a highly optimized methodology of creating solid software.