Spatial web services & data journalism, the Talvivaara case

We had an interesting real-world case of using open environmental data for journalism a couple of weeks ago in Finland. In the early hours of Saturday the 10th of November Yle, the Finnish public broadcasting company, published a background news item at their site related to the continued pollution leakage at Talvivaara mining site in Sodankylä, Finland.

In the post “Kaikki Talvivaaran alueesta” (“All about Talvivaara area”) they point to the interactive mashup map of the mining area, including natural protection areas, mining reservations etc., aggregated at the Paikkatietoikkuna geoportal of the Finnish National Land Survey.

A few hours later the map was rendered practically useless because of the serious performance problems of the background WMS services providing the data.

The map window application at Paikkatietoikkuna makes it possible for any user to aggregate and publish web maps with their preferred selection of visualized geospatial data layer provided by the various Finnish governmental organizations. The data layers are served by the WMS servers hosted by the organizations, the application only provides an interactive graphical user interface for displaying them as a mashup. In this case Yle reporters had been able to make an up-to-date, interactive map covering soil types, lakes and rivers, ground water reserves, land claims for minings and natural protection areas just by selecting the layers and publishing the link pointing at it in their news item.

The data layers in the mashup was provided by the Geological Survey of Finland (soil types), Finnish Environment Institute (river, lake, natural water reserves and natural protection area) and the Finnish Ministry of Employment and the Economy (the mining-related information). The attached report from our Spatineo Monitor clearly shows the increased response times for all the WMS servers providing the selected data layers starting in the morning of 10th Nov 2012. At 04 UTC (06 local time) the Soil type service were struggling with the first traffic peak, and by 06 UTC the server was unresponsive. The situation started to improve only at evening, about 17 UTC.

The one month time series of one of the services (Soil data) shows the average response times on10th Nov. were considerably above normal for that service:

It seems that the journalists are really starting to take advantage of the public open geospatial data resources and easily available web map tools like Paikkatietoikkuna, but the data providers are not very well prepared for even pretty minor “slashdot effects” caused by sudden increased traffic at their services.

We at Spatineo are quite glad to be able to report things like this based on our continuous monitoring of thousands of spatial web services around the world. It confirms us that our proactive monitoring strategy is the right one: In most cases we have been collecting the performance data already before our customers experience performance problems in their spatial web services.

2 Comments

Ilkka Rinne

David, yes, indeed this is not a problem in WMS itself, but the configuration and the computing resources reserved to run the services. A WMS can be set up to be very efficient, but sometimes it’s difficult to test in advance how much load your setup can take.

Advanced “mashup” tools can also make the usage peaks more unexpected to the data providers, as in this case, where a service normally has very little usage, and suddenly it becomes very popular because it’s data is required in a popular and novel application.

In many cases the experienced sluggishness of WMS services is caused by slow retrieval and possibly re-projection of very complex or just big geometries required for rendering the WMS GetMap responses. There are often good possibilities in WMS software for optimizing this kind of queries once these bottlenecks have been identified.

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *