Weather maps meteorology Stephan Siemen Stephan Siemen is the Head of the Graphics Section at ECMWF and works on the Magics graphics library. Head of Graphics Section European Centre for Medium-Range Weather Forecasts (ECMWF) Graphics Section

Reading Shinfield Park RG2 9AX United Kingdom ++44 118 9499 375

.

For over 25 years the European Centre for Medium-Range Weather Forecasts (ECMWF) has provided and maintained the Magics graphics library to plot meteorological data. The library, freely available under the Apache license, understands many data formats common in meteorology, such as GRIB, BUFR and netCDF. Magics offers various forms of displays to visualise data: for example geographical plots with contours and shading in various projections or complex (statistical) graph plots, such as meteograms and climateograms. Until recently this library was streamlined for printing with its main output format, PostScript. Over the past years the focus has shifted from print-oriented to web-oriented graphics production. Magics with its flexible design allows output in different formats through so-called output drivers. SVG is one of the newly supported output formats and this article will give an update on the developments and its possible usage. A more detailed introduction to Magics can be found in [1] and [2]. Example of a SVG plot generated by Magics and visualised in Firefox.

With the focus switching to web oriented outputs, new output formats were investigated for Magics. Currently the main format for web graphics is PNG. Offering good quality plots with antialiasing for text and contours makes the PNG very large without delivering high quality output. An additional output format, such as PostScript or PDF needs to be supported to allow good quality printing. SVG looked like a promising candidate to address the quality/size issue. The possibility of integrating SVG output directly into web pages and its use as a possible print format made it seem ideal for our purpose. An added bonus was the ability to add interactivity to the displays through JavaScript; the format's openness is also an advantage. SVG as an XML based format is directly editable and scriptable, and is widely supported by many open source and commercial professional graphics editing tools such as Adobe Illustrator, OpenOffice and Inkscape. SVG allows the definition of metadata as loose text description and/or as RDF to be used in semantic web applications. This and the fact that SVG files contain searchable strings make it possible to search and catalogue the graphics. SVG documents can also be analysed by a hosting web page through JavaScript to use its contents, such as the metadata, for generating titles and menus. Snapshot showing the strength of SVG to scale dynamically. The same SVG graphic is displayed in two Firefox windows of different sizes.

Magics’ design is modular and an output driver can be added without changes to the meteorological part of the library. Two drivers were added to investigate SVG support. The first one is based on the Cairo graphics library [2] and supports beside SVG also PostScript, EPS, PDF and PNG. The second driver is our own effort to write SVG code directly. The Cairo library is used in many open source projects, such as Firefox and Inkscape, and with this its continued maintenance should be safe. The coding was fast and easy and the quality of the output was good. However the generated SVG is static without animation and interactivity. There is no option to make the SVG plot scalable by excluding the size definition in the main SVG tag. The Cairo based output driver will remain part of Magics to make use of the good quality output in PostScript and PDF. For SVG output however, it was decided to develop our own output routine to make the output more flexible. Implementation of Magics’ native SVG output driver was again straightforward, with the exception of supporting fonts and raster satellite data which can be of large volume. To avoid the generation of large SVG files, satellite and other raster based data were written into PNGs through the libgd graphics library [3] and then imported as external files or in base64 encoding. The use of external files is unfortunate for the handling of plots. From our tests with various tools and browsers, we decided to avoid some parts of the SVG specification which were not widely implemented or which show different results on various tools. SMIL based animation was one of the features we decided not to use. Colour gradients were not used, but this was more because technical plots make no use of this feature.

The user can choose at the time of the plot generation to enable a user interface. If this option is enabled, JavaScript code is embedded to offer buttons on the top of the plot to enable the toggling on and off of different layers of information and a button to enable a magnifier glass facility. The latter is intended for users to inspect various details of the map or graph. There are also plans to enlarge parts of the plots if a user hovers with the mouse over an object.

Writing our own SVG driver also had the advantage that it was very easy to add metadata about the content. The tag is used to store in RDF format information about the document which can be read by viewers. Inkscape for example uses this information to display them as document properties. Listing 1 shows an example of the data stored in an SVG document. Figure 3 shows how Inkscape displays the data. image/svg+xml Magics++ plot stephan on orion Fri Jul 30 23:42:20 2010 en-GB Meteorological plot generated by Magics++ 2.11.1 (64 bit) Magics++ 2.11.1 (64 bit) Plot of meteorological data ]]> Listing 1: Example RDF data written in Magics SVG documents. Since meteorological maps have a geospatial domain, it was hoped to also store metadata about the projection. While this is discussed in the SVG 1.1 standard specification, no examples and usage in applications could be found. Having a mapping between SVG coordinates and geographical position could open up possibilities to link different services through their geographical location.

The speed of implementation was increased through the fact that new SVG code could be tested first in a plot before being coded in the output driver. Also was it helpful to be able to study other SVG code to learn from. One large part of a generated SVG file can be background GIS information, such as coastlines and political borders. While the coastlines can be simplified to a degree, political borders are sometimes too sensitive to be simplified or might even be omitted. In comparison to PostScript, SVG's files are generally smaller, but not by much. However, SVG supports compression which makes an improvement of about 80%. The native SVG output is on average 60% smaller than SVG plots generated by the Cairo based driver.

An advantage of SVG is that there are many powerful tools to edit the documents. For example Inkscape can be used to edit the generated maps and graphs to add comments, highlight features or change colours. SVGs generated by Magics contain the Inkscape namespace and use this extension to mark layers of contents in the document. This allows the editor to select a layer of information and edit it separately from the other information in the maps. In Figure 3 the layer containing the menu buttons are hidden through the layer editor, while the background layer and the layers containing the wind arrows and contour lines stay visible. Inkscape also allows the simplification of paths to reduce the size of SVGs and export to other vector formats, such as PDF & EPS, for publications. : A Magics generated weather map, opened in Inkscape, showing the integrated metadata (left – see Listing 1), the layers of the plot (right) and a box and text added with Inkscape (middle). One contour line is selected and the path is highlighted (middle top). Many professional tools such as Adobe Illustrator and Scribus support SVG directly. Docbook supports inclusion of SVG, as does OpenOffice but Microsoft Office has no SVG import yet.

An important duty of ECMWF is to make forecast plots available to its customers through its web page. The plots displayed on the web are generated by Magics. Currently weather maps are available in three graphical file formats on the web. A GIF of the plot is displayed on the page while the same plot is also offered for download as a PostScript or PDF from a side menu. The reason for this is that users require the map in a vector format in order to zoom in and for high quality print-outs. PostScript is the format in which all maps are generated in the first place and the GIF and PDF versions are generated by using the convert command of the ImageMagick package. This setup has its drawbacks. Often the time to convert the PostScript into GIF and PDF takes longer than generating the map in the first place and extra storage space is needed to store all three formats. As part of a restructuring and redevelopment of its web pages showing meteorological maps, ECMWF is developing a more on-demand plot service with an interactive user interface for the users to overlay layers of meteorological parameters and navigate the maps. In its current form, for each user’s request a new map in PNG is rendered by Magics. This generates many calls to Magics to redraw maps and an increased amount of network traffic. In an ideal setup, SVG maps could be used; when certain kinds of requests are issued, these maps could be reused within the client instead of sending requests to the servers. This subset of requests could be limited to changing of contour colours, small zooms and pan operations. The operations could be handled by JavaScript code in the client. There will be of course requests which still need communications with the server, such as requests for new data and recalculating thresholds. The usage of SVG in operations still needs testing. There has been no urgency since even with the support of SVG in Internet Explorer 9 it is unlikely for most of ECMWF’s web users to change soon to a native SVG supporting browser. Tests will start soon and will centre first on a one-to-one replacement of PNG followed by an evaluation of the possible optimisations through using SVG. The use of SVG will be expected to make the client side scripts heavier for a reduction of load on the server side.

The OGC Web Map Service (WMS) specification defines that a service can serve maps in picture format (raster image) or graphics element format (vector formats). ECMWF plans as part of its web-reengineering project to offer a WMS service to its customers. This service will be part of the above described on-demand web plot framework. Thanks to the use of Magics it was easy to add SVG as one of the formats to serve maps through the WMS and this is already available to users. Unfortunately there is currently a lack of GIS clients supporting SVG. There is an active community working within OpenLayers to extend the already static support for WMS with a more dynamic use of SVG features. We might want to explore this direction as a test client for our service. Also the parameters X and Y of the GetFeatureInfo request, which is part of the WMS standard, are more suitable for raster formats than for vector formats such as SVG.

From the beginning it became clear that a major weakness was the limited support in web browsers. Even though over the last two years we have seen huge improvements in the support of SVG in many web browsers and software, Internet Explorer from Microsoft was so far an exception to these developments. This is important since our web statistics shows that 53% of users of our web plots use various versions of Internet Explorer. Announcements that version 9.0 of Internet Explorer will support SVG natively are therefore very welcome. Another weakness is the missing support of importing SVG graphics in Microsoft Word and PowerPoint. Another concern is the file size. In general slightly smaller than PostScript, it is still larger than PNG. For most of our SVG plots the majority of the data stored is for the coastlines. These would not be needed if SVGs were only used as overlays as done by Google Maps and OpenLayers clients.

The implementation of an SVG output driver within Magics has shown the potential the format has for a richer user experience. The quality of maps is very good and all graphical features of Magics could be easily supported plus some simple interactions. Regarding the web plot production, there are still tests required to establish if SVG can replace the current output formats of PNG and PDF/PS/EPS for printing. The increasing native support of SVG in web browsers, especially the upcoming Internet Explorer 9, will mark a turning point to reach potential users.

Thanks go to other members of the Graphics Section working on Magic: Sylvie Lamy-Thepaut, Iain Russell, Sandor Kertesz and Fernando Ii. Thanks also go to the web group at ECMWF supporting these studies.

[1] Generating SVG weather maps and meteorological graphs using Magics, SVGOpen 2008. [2] Magics homepage: http://www.ecmwf.int/publications/manuals/magics/. [3] CairoWeb Cairo graphics library: http://www.cairographics.org. [4] GDWeb GD graphics library: http://www.libgd.org.