INGENIERIA DIRIGIDA POR MODELOS MDE

Using the techniques explored so far, this section builds a weather data viewer for the web using OGC compliant web services4. In addition to using real-time data, archive data can also be explored, for example the storm of the 27th and 28th Oc- tober 2013. The ‘HadCRUT 4’ dataset is also available for download and contains climate information for the whole world spanning 1850 to the present day. Global Telecommunications System (GTS) data is also freely available from some organisa- tions that have access to a GTS feed and can be decoded using the following software: https:// github.com/ maptube/ WxDecoder. Linking back to the flooding example in sec- tion 3.2, in March 2015 the Environment Agency released a new real-time API for river level data and flood warnings, so the inclusion of hydrological information is now a possibility. All these sources of data contain multiple variables for points in space and time, fulfilling the criteria of multivariate exploratory data analysis.

Table 5.1 lists the map based products available on the UK Meteorological Office’s DataPoint site for real-time weather data. Table 5.2 lists the forecasts that are available, excluding text only forecasts and other non-mappable products like fax charts. One of the problems with integrating weather data into modern geographic display software is that these weather forecasting data sources have existed since the 1940s and are designed to remain accessible in remote parts of the world where computing power is scarce. Some of the primary resources for weather forecasting, for example ASXX surface pressure observation charts and FSXX surface pressure forecast charts, are in raster formats originally designed for dissemination by fax machine.

Table 5.1: Met Office DataPoint Observations.

Name Availability Format Spatial Extents Projections Surface Pressure Chart every 6 hours png Northern Polar Polar Stereographic Rainfall Radar (Single Tile) every 15 mins at T+15 png (48.0,-12), (61.0,5.0) WGS84 Mercator Image Rainfall Radar (WMTS) WMTS EPSG:4258, ETRS89, EPSG:27700,

EPSG:29903, EPSG:2157

Satellite (Visible) every 3 hours at T+15 png (48.0,-12), (61.0, 5) WGS84 Mercator Image Satellite (IR) every 3 hours at T+15 png (48.0,-12), (61.0, 5) WGS84 Mercator Image Radar and Sat Composites every 30 mins png (48.0,-12), (61.0,5.0) WGS84 Mercator Image Temperature Colour fill every 6 hours png (48.0,-12), (61.0,5.0) WGS84 Mercator Image Hourly Observations Hourly at T+10 XML UK (WMO 03) WGS84 Marine Observations Hourly at T+10 XML UK (WMO 03) WGS84 Monthly Climate Averages Daily table of data csv n/a n/a

Lightning Strikes every 15 mins at T+15 png (48.0,-12), (61.0, 5) WGS84 Mercator Image UK Climate Averages Daily table of data csv n/a n/a

Historic Station Observations Table of data csv n/a n/a

4_{UK Government Agencies are directed to follow the European INSPIRE directive for the dissemination of geospatial data.}

Table 5.2: Met Office DataPoint Forecasts.

Name Availability Format Spatial Extents Projections Precipitation Forecast every 6 hours png (48.0,-12), (61.0,5.0) WGS84 Mercator Image Surface Pressure every 6 hours png Northern Polar Polar Stereographic UK 3 Hourly Forecast 3 hourly at T+30 XML UK WGS84 UK Site Specific Forecast 3 hourly XML UK sites WGS84 Forecast Radar hourly png, WMTS (48.0,-12), (61.0,5.0) WGS84 Mercator Forecast Sites forecasts for 5000 sites xml n/a WGS84 Total Cloud every 6 hours png (48.0,-12), (61.0,5.0) WGS84 Mercator Image MSLP Forecasts T+0 to T+36 (+3) updated every 6

hours

png (48.0,-12), (61.0, 5) WGS84 Mercator Image Temperature Forecast every 6 hours png (48.0,-12), (61.0, 5) WGS84 Mercator Image

For the purposes of geospatial visualisation, the data can be categorised into either image or synoptic data. The synoptic data can be handled using the MapTube We- bGL system outlined in the previous section 5.1.2, while image, or ‘coverage’ data from satellite and radar instruments needs to be handled differently. The reason for this example is that it demonstrates custom rendering of data on web-based maps us- ing weather data, which is rich in custom symbolisation, as an example. The wind fleches, cloud type symbols, oktas of sky coverage and past and present weather sym- bols all require custom rendering code, which is accomplished by drawing onto the frame buffer. Although the synoptic data is point based, while the coverage data is im- age based, the custom code required to draw the meteorological data on the frame buffer is accomplished by “MapTube.ImageOverlay” class in figure 5.8. Figure 5.5 showed a more complex example using the THREE.js library to show flow lines, which could be adapted for any of the synoptic observation data in tables 5.1 and 5.2. The pre- vious discussion in section 5.1.3 contains references to the system architecture which shows how all of the custom rendering code is reduced to calls of the form, “move x,y”, “draw x,y”, or “draw text at x,y”. The architecture presented in the GitHub code abstracts away the tile rendering complication and makes the rendering of custom data more like drawing to a screen canvas in a desktop application. This is essential to the following discussion in the later chapters on agent based models running on web-based maps, as the requirement here is identical. What follows in this section is a discussion about the problems of the canvas size, which multiplies by four at every subequent zoom level.

The temporal element also adds an additional dimension to both types of data, but, by using the full area ‘png’ images, which are already projected into the EPSG:900913 coordinate system, the data is representable using a bounding box overlay on top of either a Google Map or using OpenLayers. The documentation for the Google Maps library includes an example of data from the USGS, overlayed on top of a Google

5.1. Example 1: Data Exploration and Web GIS 187 Map using this technique. Internally, the web browser represents the image overlay as an HTML image element, ‘<img>’, contained within the Document Object Model. This raises the same performance issues which were explored in the previous WebGL section, namely the doubling of the image X and Y dimensions each time the user clicks the map’s zoom in button. In this situation, the image scaling and clipping is handled natively by the browser and operating system, so this problem has not been experienced to the same degree as the WebGL overlays. However, with a sufficiently large bitmap image, this is a potential problem, so a proposed solution is to use the same WebGL system for the image data by texturing a polygon covering the data’s bounding box. This idea raises an interesting possibility, as more detailed rainfall and satellite data is available in the OGC’s WMTS format, but not in the web Mercator projection required. The equations used by the virtual globe system detailed in Chapter 4 of [CR11] take the NASA Blue Marble texture for the world in EPSG:4385 and wrap this around the spheroid using the programmable GPU shaders to do the coordinate mapping. From this it is possible to conceive of a browser based system that could do a similar reprojection from the WMTS tiles in EPSG:4385 to the Transverse Mercator base map in EPSG:900913 using WebGL. At the present time, no examples of any systems of this type can be found.

Figures 5.7a, 5.7b and 5.7c show rainfall radar data from the storm of Sunday Octo- ber 10th 2013. The source code for this example is available from the MapTube GitHub account at the following address: https:// github.com/ maptube/ meto.

(a) Sunday 27th October 17:15Z (b) Sunday 27th October 19:00Z (c) Sunday 27th October 21:30Z

Figure 5.7: Rainfall radar data for the storm of Sunday 27th October 2013. Data is taken from the UK Met Office’s DataPoint service. Data copyright Met Office.

The class diagram in figure 5.8 shows the basic ‘ImageOverlay’ class, extended to handle the animated radar sequences shown in figure 5.7a,b,c. This is achieved through

Figure 5.8: MapTube overlay classes for the animated image overlay capable of being added as a data layer on a Google Map.

the ‘AnimatedImage.getImageUrl()’ method which is overloaded to supply the URL of the relevant RadarNet image frame given its date and time. The animation code on the html page simply takes the start time and adds fifteen minutes to obtain the next frame, looping back to the start when the end time is reached.

Moving on to the synoptic data, due to the quantity and custom display format, a variant of the previously outlined WebGL overlay is used. The requirements for this section are for exploratory data analysis, which implies data handled in its native format and visualised directly. The world ‘Global Telecommunications feed’ (GTS) contains 1160 synoptic observations, while the UK Met Office’s DataPoint site has 121 official stations for the UK, with the feed from their ‘Weather Observation Website’ (WOW) network containing an aggregate of 1304 worldwide, UK and volunteered community observations. The data contains information on wind speed and direction, temperature, dew point, relative humidity, visibility, gusts, weather type and surface pressure. In order to be able to implement functions like thresholding and de-cluttering, which are necessary for data exploration, the map overlay needs to be able to handle the required complexity of the graphics. Additional functions like contouring are also desirable as, applied to the temperature or pressure fields, this will highlight weather fronts as discontinuities in the pressure field.

The diagram in figure 5.9 shows a standard World Meteorological Organisation sta- tion circle containing information for wind speed and direction, total cloud, air temper-

5.1. Example 1: Data Exploration and Web GIS 189

Figure 5.9: World Meteorological Organisation (WMO) Station Circle, METO Form 7, showing wind, total cloud, air temperature, dew point, pressure, visibility and present weather.

ature, dew point, mean sea level pressure (MSLP), visibility and present weather, along with the name of the station or ship making the observation. Using the WebGL system outlined previously for plotting geographic data as a Google Maps layer, this type of synoptic data can be plotted by writing a subclass containing the rendering code. The advantage of using the WebGL system is in the higher quantity of data it can handle and the fact that, with data stored locally, there is a higher level of interactivity. The disadvantage is that the station plot is made using a screen space pixel scale rather than a geographic scale, as the size of the plot does not change as the user zooms in and out. Figure 5.10 shows the synoptic data overlay based on the WebGL code. This library is available for download from: https:// github.com/ maptube/ meto.

While the meteorological data viewer is one example of exploratory data visualisa- tion, an obvious extension is to handle the OGC’s ‘Simple Features’ geometry, which is based on points, lines and linear rings forming polygons and holes. By handling general polygons, the framework is now in place for a ‘Web GIS’ which can load data in from shapefiles and perform similar functions to a conventional desktop GIS. Two approaches exist to the polygon problem: render all the data onto the canvas as a single block, or tile the geometry and reduce the complexity dynamically based on zoom level. The single block of data approach can favour certain types of data visualisation, while the tiling approach favours cartography which covers the entire Earth. The following section completes the WebGL tool kit by adding complex custom geometry using a hybrid approach known as ‘vector tiling’.

5.1. Example 1: Data Exploration and Web GIS 191