Oklahoma and Massachusetts, like almost every other state and territory, have built and launched their interactive state broadband maps. While end users may note a Google logo and some famil-iar looking tools, they are probably not interested in what technology is running in the back-ground. Those involved in geospatial technology, on the other hand, want to know the details. Directions Magazine spoke to the team at Applied Geographics (AppGeo) in Boston, a subcon-tractor to the Sanborn Mapping Company for Oklahoma’s site, and the prime contractor for the Massachusetts Broadband Institute’s site, to learn more about the implementation of these web-sites.
Directions Magazine (DM): What technology powers the Oklahoma and Massachusetts broadband maps?
Applied Geographics (AG): Both Oklahoma and Massachusetts are built with similar technology mixes. Both states use the “OpenGeo” stack which includes PostgreSQL, PostGIS, GeoServer and GeoWebCache. These software environments are independent open source projects compris-ing the OpenGeo stack. Amongst other things, OpenGeo has built a “one-click” installer that greatly simplifies establishing the software environment.
DM: How did the projects end up with that mix?
AG: In both cases, other elements of state government had established open source (i.e., Geo-Server) infrastructures for their public facing Web services. Thus, the states were familiar with open source geospatial technologies. AppGeo is responsible for hosting Oklahoma’s website for the first two years, but the state wanted a website that could be easily transferred to, and hosted on, its infrastructure in the future. Massachusetts was attracted to the greater GIS server license flexibility that allows for scalability and hosting on multiple, cloud-based servers. The Massa-chusetts Broadband Institute expected a large spike of use during a launch that would be accom-panied by significant publicity and needed the system to scale effortlessly. In short, the custom-ers asked for this technology. And interestingly, this is also essentially the same stack that Na-tional Telecommunications and Information Administration (NTIA) elected to use for the recent-ly launched National Broadband Map.
DM: What differences would an end user find on these state broadband maps that might not appear on others?
AG: We would like to believe that there aren’t any. We did not approach these two projects any differently than other broadband mapping projects that involve other technologies. For example, we’ve worked on sites for four other states where Esri Web server technology is involved. The goal is to build an excellent broadband mapping site that showcases the new broadband data to answer questions about broadband availability and the level of service across the states. We have not found any functional limitations in what we were trying to do in either environment.
DM: What aspects of working with an open source stack were particularly valuable? Challenging?
AG: Two aspects were particularly valuable. First, the open source license gave us a great degree of flexibility in architecting these systems, both in terms of planning for scaling with increased use and also dividing the load (e.g., DB serving, map serving, cache building) across multiple servers. Second, our programming staff was eager and enthusiastic to explore new technology and participate in the open source communities that surround these projects. Thus, it has proven to be an excellent learning opportunity and things have gone more smoothly than we could have hoped. Probably the biggest challenge was creating high quality cartographic symbolization in the open source environment. The mechanisms are quite different and take some getting used to and the tools are not as mature or robust as Esri’s tools for what-you-see-is-what-you-get (WY-SIWYG) map authoring. Another major challenge, regardless of the server environment, is build-ing statewide tile caches. It’s just a lot of data and processing to manage. For instance, in Okla-homa, each of the 10 broadband tile caches contains approximately 1.6 million files requiring 2GB of storage.
DM: Both applications are now hosted in the cloud. What were the challenges of finding an appropriate host? Getting the app up and running in the cloud?
AG: We have experimented with building map servers in Amazon’s cloud but in this case we elected to use a smaller outfit in Southern California called VM racks. First, we use VMware internally and liked the idea of building an infrastructure in a familiar environment (e.g., Amazon uses the Xen virtual environment). Second, we liked the idea of a smaller outfit where we could build a personal relationship with people who understood our requirements and where we could get the same set of people on the phone if trouble arose. It was very helpful getting VM racks’ advice on solving our problems, with our focus being on withstanding a significant launch spike in use. In Oklahoma, 25% of visitors to the site in February were concentrated into the two days that immediately followed public notices of the site (e.g., an article appearing in The Oklahoman). On those two days, almost eight times the amount of bandwidth was consumed as on a “typical” day.
Once we identified the kinds of virtual machines we required, the next biggest challenge was moving significant amounts of data (i.e. large, statewide PostGIS databases and in some cases, statewide tile caches) onto the cloud. Our Internet connection is only so big and moving large amounts of data takes time. Our architecture for Oklahoma relies on Google’s base maps when zoomed out and the state’s own orthophoto map service when zoomed in tight. This helped minimize the amount of data that needed to be moved. Whenever possible, we built the tiles directly on the cloud server to avoid the lengthy copying process.