DM: You told us the software was developed with Open Source. Why did you use this technology? Do you think if you had used commercial software you would have been able to improve the performance?
Developing on open source has given us the flexibility needed in a project like this without having to worry about whether we had enough licenses per computing "core" or not, and choosing the right components for each requirement, rather than having to adopt monolithic suites with great functionality but poor performance and little chance of adaptation. One of the advantages that may seem trivial but in this work environment is very important is that I have the whole project on my laptop, and I can make changes from a Starbucks, if necessary (and I use this example because it happened to me once on the project). The performance we obtained is very good although I have to say that we can squeeze out a lot more; there are optimizations that, due to lack of time, we have not implemented yet.
DM: With respect to the particular software components, which database manager have you employed? What tools are you using for the map interface?
JMO: The main database is PostgreSQL with the spatial extension PostGIS for spatial data. The presentation layer is mainly OpenLayers, Geoserver as a GIS server and we used GeoWebCache to cache most map layers. The entire website is built on Wordpress.
DM: We saw that during the first hours the map was open to the public an enormous amount of interest and traffic caused the map to crash. How do you redo the architecture of cloud services to fix this issue?
JMO: We knew that this was an important project that would generate interest, but no one was prepared to have to meet peaks of up to 9,000 requests per second. When you serve your own caches of maps, [this] generated a lot of stress on the servers, especially if used as we have used to describe the content in question and not only as a base map. The solution to this problem came through horizontal scaling strategy, basically putting more servers to service. Support from Cloudmade and OpenGeo was critical in these initial moments, and in my opinion they did an excellent job supporting this launch. We had several waves of demand as it was published in the media (CNN, Fox News, The New York Times, etc.) which made the intervention a bit more complicated and longer than we would have desired.
DM: Over the many months of work, what has been the most important challenge you faced with a project of this magnitude?
JMO: The most important challenge was always meeting the deadline of February 17, which was mandated by Congress and therefore unchangeable. But this was not the most difficult challenge. The more complicated challenge was the integration of data. As often happens in many GIS projects, integrating disparate data providers, as was the case, caused many problems even when we had defined a common data model. We have many ideas, some new, on how to improve this process in the next round. Keep in mind that the map information is serving the entire United States. We have some geographic layers with 25 million polygons that describe the broadband access with a fairly high degree of detail, and a very big country such as the United States. This information will be refreshed every six months, so our attention is now focused on how to improve this integration process.
DM: The application uses OpenStreetMap (OSM). How was the experience of integrating OSM? Is OpenStreetMap able to respond to a mass market application such as this?
JMO: This project uses CloudMade, a service based on OpenStreetMap with some very attractive features. One of them was commercial support. OSM also suffered the barrage of requests the first two days, but I will say that their response has been exceptional, and within hours [we] had a solution that scaled without problems. In my opinion this option is very attractive because of the possibility of adjusting the map based on a certain style, but without having to worry about working with data from OpenStreetMap locally.