Model output data integration using a Web Map Server

Maps are one of the basic products that can be created from numerical model output data. Whether numerical weather prediction models, air quality photochemical models, air dispersion models, wave models or any other, it is useful to show in a map different fields like the air temperature, wind speed and direction, pollutants concentration, significant wave height or any other variable obtained from the model.


Maps can be static images with fixed size, geographic extension, colour palette, axis, labels, and the rest of graphic elements where the user can not intervene. However, it is more frequent having interactive maps where the user can choose the zoom level, the area of interest, the variable or set of variables to overlay on the map, the topographic base maps, the colour scales, etc., so the user can build a custom view obtaining more profit of the results.

In order to implement interactive maps let’s consider a client-server architecture. Following this model, the server provides a service or resource, in this case a map, and the client consumes this resource. In this context appears the concept of Web Map Service, a standard protocol developed by the Open Geospatial Consortium (OGC) in 1999 to provide georeferenced maps over the internet in a neutral way. There are many client applications that can consume this type of service, amongst others: Google Earth, Esri ArcGIS, Autodesk, MATLAB, QGIS, GRASS GIS, OpenLayers, Leaflet.

From an integration point of view, using a web map server entails advantages. Consider, for example, a platform developed by a company that provides several services to their clients, including the visualization of information in a map. This content can be created by the company themselves or can be obtained from a third-party. In this latter case, if the third-party provides access to their maps through a web map server the integration with the platform is much more easy, fast and agile, because it is a standard protocol that completely defines the queries. The only thing required will be an URL and some credentials or authentication method if it is needed. The service itself provides methods to discover what information is stored on the server and in which formats can be consumed.

In order to provide access to the information generated by the models, Meteosim have two channels: a web map server to provide maps and an API to consume the rest of data (time series at points of interest, vertical profiles, wind roses, on-demand simulations, etc.). The Meteosim web map server is an implementation of the open source platform Mapserver. Mapserver supports several OGC standards, including:

  • Web Map Service (WMS/WMTS). This service produces georeferenced maps formatted as images (png, jpg, …)
  • Web Feature Service (WFS). Provides direct access to geographical features in vector format (GML, Geojson, …).
  • Web Coverage Service (WCS). Provides access without filtering to coverage data in raster format (GeoTIFF, netCDF, …).

The chosen service will depend on the features required. Por example, if a temperature layer is wanted to be overlaid on the map and only contour lines and a colour palette are needed, the WMS is adequate. If in addition to this, the contour lines are desired to have the corresponding numeric value linked, so the user for example can click on the map to show these values, then the WFS will be used. Finally, if raw information from the model output at every grid point must be accessed, and create from them the maps, then the WCS provides these data. With these three services all map needs are covered and require more or less client intervention to produce the final map, sorted by increasing effort: WMS, WFS and WCS.