The Western Governors’ Association (WGA) rolled out its Crucial Habitat Assessment Tool (CHAT) in December 2013. A cooperative effort of 16 western states, the map-based tool provides the public and industry an overview of crucial wildlife habitats. The goal is to ensure that fish and wildlife are better incorporated into land use decision making. Learn how the high demand website was designed to be scalable, cost effective and beautiful.
The Western Governors’ Association (WGA) rolled out its Crucial Habitat Assessment Tool (CHAT,www.WestGovCHAT.org) in December 2013 (press release). A cooperative effort of 16 western states, the map-based tool provides the public and industry an overview of crucial wildlife habitats. The goal is to ensure that fish and wildlife are better incorporated into land use decision making. Directions Magazine interviewed Michael Terner, executive vice president at Applied Geographics (AppGeo), the company that developed and implemented CHAT, to learn more about the project.
Directions Magazine (DM): The WGA put out a request for proposals (RFP) for what became CHAT in October 2012. Were there any aspects to the document that allowed AppGeo to show its strengths in the competition and later in the implementation?
Michael Terner (MT): The WGA did two things in the RFP process that we believe played to our strengths and reflected a similar outlook. First, the RFP reiterated the resultant website was to be a “unique web destination” which made sense since the website was to be the culmination of a three-year-long process that included the development of the crucial habitat data. This language implied to us that the WGA wanted something that was highly customized and beautiful and we believed the budget supported this.
Second, the WGA did not lay out any requirements for specific technologies. Rather, the RFP described what the association wanted the website to do. The WGA left it to the marketplace to describe how it would get done.
DM: What was the final architecture? How did AppGeo and WGA arrive at that combination?
MT: One of the key drivers of the architecture we proposed and implemented was the fact that the WGA does not have a “GIS shop.” This means there are no professional GIS people on staff, and there are no “sunk” investments in any particular technology. One of the contractor's responsibilities was to host the final application for one year, and then be prepared to “turn it over” to the WGA after that year.
This situation pointed us clearly in two directions. First, the solution needed to be deployed in the cloud on virtual hardware. Second, the solution should use Open Source Software (OSS) that did not require software license fees. Incorporating these two things helped us be very cost competitive. In short, we proposed a cloud-based, hybrid-technology architecture:
- Geospatial server: Used “Boundless open source stack” (aka “OpenGeo suite”): PostGIS for vector data management, query and attribute access; GeoServer for Web map services
- Tile Cache creation: Again, Boundless’ OSS stack, and specifically GeoWebCache as well as Arc2Earth were used
- Cloud-based Infrastructure as a Service (IaaS) and virtual servers: Amazon Web Services; Elastic Cloud Compute (EC2) for servers; Simple Storage Service (S3) for tile cache storage
- Data aggregation and management: The WGA managed this aspect of the project through its partner, the University of Kansas, and they managed the process using Esri technology.
DM: How was this implementation different in project management and/or or technology than other high exposure sites AppGeo has worked on, such as state broadband maps? What did the AppGeo team learn in the process?
MT: One key thing that became apparent very early in the project was that this site was going to be “announced” via a press release from the Western Governors’ Association itself, and potentially from several of the governors individually. As such, we were expecting there’d be a significant “launch spike” in usage that needed to be managed (see the next question).
Second, the Web publication was the culmination of a very significant, 3-year-long WGA project and was very important to the organization. The WGA is collaborative by nature and there’s a balance between “group interests” and “state autonomy.” We had a strong WGA project manager and fantastic multi-state “steering committee” that worked with us throughout the process, including through the agile development iterations. We did not go into the backroom and produce this website. Rather, it was a true collaboration. But active collaboration takes time and costs resources. We think the product shows that those investments paid off.
DM: What were the biggest worries before launch in December? How did the technology team reassure WGA the site would survive launch day and beyond?
MT: We were aware of a potential “launch spike” from the outset. We’d learned through some of our broadband projects - unfortunately, somewhat the “hard way” - that such launch spikes can be disruptive and tricky to manage. As the HealthCare.gov fiasco showed, you don’t want your site to fail at precisely the moment the most eyes are on it.
The architecture we used was well-suited for managing such a spike. Amazon’s cloud has great tools for “auto-scaling” whereby new servers can be automatically launched when the current servers reach a threshold of “busy-ness” (e.g., when a server’s CPU gets to 80% utilization, a new server is launched). Additionally, with OSS software, there are not new license requirements/costs when one of those new servers is automatically spawned. Finally, our decision to use pre-cached tiles meant there would be less load on the servers and instead Amazon’s S3 would handle that traffic.
So we planned for it, and we load tested and we felt we were well prepared. Still, as the launch approached we were a bit nervous. We’d talked about it so much, what would happen if we failed? Happily, the preparations paid off and the site hummed throughout its launch (and could have handled a much bigger load if it was needed).
DM: About what aspect of the project are you and the team most pleased/proud? Why?
MT: Ultimately, both we and the customer like the site that was constructed. I think we got the important stuff right, like keeping it simple and intuitive, having it run on a variety of devices, and having it be reliably fast. We think we pass a challenge that Brian Timoney put out in his MapBrief blog: “If you are building any public-facing interface you have exactly four requirements: FAST, INTUITIVE, INFORMATIVE, FAST.”
Figure 1: Screen capture from Western Governors' CHAT site showing the habitat characteristics of one of the hexagons. Note the link to “view metadata” which takes the user to a page where, in this case, Washington State describes how they identified “crucial habitats.”
I like to describe the site this way: “We built a simple site for exposing complex data.” Indeed, the crucial habitat data are quite complex, and the fact that the data are a composite of datasets emanating from 16 different states makes it more complicated. We’re actually very proud of how the metadata are exposed. Indeed, if someone wants to know “How did Oregon determine what habitats are crucial?” that question is answered. In the spirit of keeping things simple and focused on the most important things, that information is not prominent, but it is accessible. As the image shows, zoom in to where you can click on a hexagon; then hit the metadata link that appears in the pop-up that exposes the attributes.
DM: AppGeo’s press release on the site launch notes "AppGeo is a Boundless, Google, and Esri partner.” The Google relationship is new. Can you share how the company plans to leverage these different platforms on behalf of your clients?
MT: AppGeo has always been a customer focused organization. Our primary allegiance is to our customers. Our job is to help them to solve their business problems using the best and most cost effective technologies available in the marketplace, including our own innovation.
The Google partnership is new, and we’re very excited about it. We see the geospatial world opening up and there are more and more geospatial opportunities coming from organizations that might not know what “GIS” is, much less have a “GIS shop.” But those organizations invariably know what Google Maps and Google Earth are. In fact, five-plus years after most people started navigating their cars and boats with GPS and habitually using Google (or Bing, or MapQuest) to see where something is, more and more people are realizing they can bring these same technologies into their organizations. But they’re not coming at it from the angle of “doing GIS.” Rather, they’re wondering “How can I manage my fleet of vehicles?” or “How can I better understand my customers?” or “How can people find my store more easily?” At the same time, Google has increasingly opened up its backend to commercial and enterprise uses via a variety of new services and APIs that are available for a fee. And, at the moment when more and more organizations understand the benefits of cloud computing and software as a service (SaaS), few would argue that Google’s cloud doesn’t have the capacity, reach, performance and maturity to tackle the biggest and most challenging problems. And it performs pretty well on the simple stuff too. As shown with the WGA CHAT site, there are some great opportunities to mix and match technologies in order to leverage each one’s strength in a hybrid environment.