BARRERAS DE LOS DATOS ABIERTOS

The layered diagram in figure 5.2 shows how the different technologies are built on one another to give GIS capabilities to an HTML 5 browser via WebGL. A custom overlay is created in Google Maps which contains the WebGL view. Then a 3D scene is created with the ground on the XY plane and a fixed camera at some height in the Z axis, looking directly down towards the ground plane. Figure 5.3 shows this set up, which is essential to the following discussion. While figure 5.2 shows the OGC’s “Simple 2_{Complex data sources like the positions of London Underground trains do not use data directly from the API, but require}

processing to turn the data returned from the API into a suitable format. The real time element means that this must be a work flow to pull in the latest data.

Features for SQL” standard, along with the “GeoAPI” and “Web Features” standard any consistent representation for the data will suffice. The modular approach chosen here is key to this, allowing any of the modules to be replaced with a different standard when required. As standards are continually changing, any reliance on a specific standard is a bad approach to take, so being standard agnostic where possible is desirable. However, standards allow for inter-operability between users and internal components, so the standards that are exposed to the outside world are important. Having said this, though, the digram in figure 5.2 is intended to show how the realisation of an actual system was constructed, so the standards used internally will never be exposed and can be chosen on the basis of system efficiency.

All geographic data is rendered on the Z = 0 plane, with the camera positioned at Z = 400 and using an orthographic projection. The near and far clip planes are at Z = 1 and Z = 1000 respectively. Equation 5.1 shows the orthographic projection formula, consisting of scaling and translation. The symbols ‘L’, ‘R’, ‘T’ and ‘B’ are the left, right, top and bottom coordinates of the viewport. The distance to the near clip plane is given by ‘N’, while the far clip plane is ‘F’. The projection matrix, P , is calculated from the scaling and translation matrices as follows:

P =        2 R−L 0 0 −R+L R−L 0 _{T −B}2 0 −T +B_{T −B} 0 0 _{F −N}−2 F +N_{F −N} 0 0 0 1        =        2 R−L 0 0 0 0 _{T −B}2 0 0 0 0 _{F −N}2 0 0 0 0 1        +        1 0 0 −L+R₂ 0 1 0 −T +B₂ 0 0 −1 F +N₂ 0 0 0 1        (5.1) Geographic data is initially specified in WGS84 and then projected into Spherical Mercator coordinates which is the coordinate system of the Google Map layer beneath the data. x = Rλ, y = R 2 ln  1 + sin φ 1 − sin φ  (5.2) This is extractable from the source code of the ‘map.getProjection().fromLatLng ToPoint()’ function in the Google ‘maps.js’ library. The example in equation 5.2 was taken from version 20.2 of the V3 API and is liable to implementation changes. What has been omitted here for clarity is that the Mercator coordinates are then scaled to

5.1. Example 1: Data Exploration and Web GIS 179

Figure 5.2: MapTube WebGL System Diagram.

X

Y

Z

a 256x256 unit box to simplify the conversion to pixel coordinates at arbitrary zoom levels. The tiles are also 256 pixel square boxes, starting with the whole world fitting the single top level tile, then the size doubling at each successive zoom level. This means that the coordinates are multiplied by 2z at each zoom level, z, in order to map them onto the pixel canvas.

The geographic bounds of the data form a box, which is projected onto the Google Map and then used to create the rendering canvas (frame buffer) for the geographic data to be drawn on. This defines the size in pixels of the drawing surface. As the map is zoomed in, this canvas doubles in size in both the X and Y dimensions. The main issue with this system is that it also requires the inclusion of a clip rectangle to limit the rendering canvas to the size of the screen. Otherwise, the x and y frame buffer dimensions for the whole world are defined by x = 2z _{for zoom, z, between 0 and 20.}

This can obviously become very large, so a clip rectangle which fits the screen viewport needs to be included, along with the required offsets to ensure the data is rendered in the correct place on the map.

The diagram in figure 5.4 shows the calculations required to transform the original data into the 3D world space and render it in the correct position on the Google Map ‘div’container for the custom overlay. The first box, labelled 1, shows data in WGS84 geodetic coordinates projected into the world space of box 2. Taking the bounding box of (55.8, 2.0), (49.8, −6.5) used in the example, which encloses England and Wales, the coordinates projected into the Mercator world space occupy X = {0..256}, Y = {0..256}. The camera is always placed at the centre of the data bounds, which in this case equates to (126.4, 83.5). This projection is performed using the Google maps function, ‘map.getProjection().fromLatLngToPoint()’. In order to calculate the position that the overlay’s ‘div’ container occupies on the map, the original data bound- ing box from (1) is projected onto the current visible map overlay using the Google Maps function, ‘overlay.fromLatLngToDivPixel()’. This is how the scaling is handled between different zoom levels, as the camera scale is calculated from the ratio of the ordinates of the bounding boxes calculated in (2) and (1). This takes care of the camera position and scale, but, due to the map canvas doubling in size at each zoom level, clip- ping of the frame buffer to the visible viewport is required. This is accomplished using the ‘overlay.fromLatLngToDivPixel()’ function again, but this time on the geographic bounds of the map. Step 4 shows this process, which results in the data bounds enve-

5.1. Example 1: Data Exploration and Web GIS 181 WGS84 (55.8,2.0) (49.8,-6.5)

Frame

Buffer

Screen

Clip Frame Buffer

to Screen

lope from (3) being clipped by the screen extents envelope from (4). The final frame buffer size is shown in (5), with the chessboard pattern intended to represent the parts of the data frame clipped by the visible viewport. The offsets here are required for ren- dering, otherwise the data would be translated on the map due to the viewport clipping. The camera projection matrix is recalculated using the revised (offset X, offset Y) and (width, height) ordinates, after which the scene can be rendered in the correct position on the map’s frame buffer which fills the Google Map overlay ‘div’.

For similar reasons to the ‘need for a renderer’ covered with the 3D globe system later in section 6.3.1, the ‘THREE.js’ library is used here to manage the WebGL context and provide scene and object creation functions which the geographic data layers use to draw their data on the map. Objects in the scene are created using Google’s projection of the original WGS84 coordinates into the ‘Google Mercator’ projection where the world is normalised to fit in a box measuring 256x256 units. Figure 5.5 shows an example of this system.

Comparisons between this system and the AgentScript system from section 3.9 are inevitable as the basic code pattern is very similar. The difference is in the use of the faster 3D graphics hardware for rendering the maps and some additional projection calculations in the frame buffer clipping. While this was something that was explored in section 4.2 on the background to tiled vector maps, the Cartagen and MapBox sys- tems mentioned did not use a Google Maps base layer and were intended for use with cartography. The focus here is to provide visualisation of intangible data rather than tangible cartography, which is aided by the ability to handle more data, animation and a pre-built base map in the form of Google Maps. Recent advances in MapBox GL JS since October 2015 are significant here, providing an open source project which can be used for vector maps on the browser.

While this is a useful test, some questions still remain about how 2D and 3D GIS can be integrated. The system diagram in figure 5.2 shows two OGC blocks, where the ‘Web Feature Service’ is used to query data on a server and the ‘Simple Features for SQL’ and ‘GeoAPI’ block handles the scene creation from the data. Unfortunately, these standards are not quite usable yet for 3D GIS. Points and lines can be easily rep- resented, but polygons require a triangulation step which is computationally expensive. While the client side library is able to handle this, it makes more sense to perform this step on the server and pass triangulated data directly to the client. Geospatial standards

5.1. Example 1: Data Exploration and Web GIS 183

Figure 5.5: MapTube WebGL Layer inserted into Google Maps. The data shows a test of commuter flow lines from the centroid of every one of the 7,201 MSOA areas in England and Wales in the direction of the average flow (blue arrows). The geographic bounds of the data are marked with the black box containing a blue cross. The red wire frame 3D cube was added to show that this is a ‘live’ scene graph, with the cube slowly rotating over the map. The potential exists here for animated data on web based maps.

for this type of operation have yet to become fully accepted, so an interim solution is the most likely solution. In addition to this, the ‘Web Feature Service’ is intended to be used with GML data, although there is a provision in the standard for advertising alternative data formats. GML is a form of XML mark-up for geographic modelling and is not a natural candidate for use with web browsers, which are extremely limited in the data formats that they can handle. An obvious choice is to create a WFS service that returns JSON3_{which is more efficiently handled by the browser. Then the problem}

of the format of the data needs to be tackled, as a form of GeoJSON containing triangu- lated data does not exist and any visual representation of the polygon’s outline would still require the outer boundary as a linestring. At present, Google’s implementation of the OGC features specification uses points, linestrings, polygons and their respective ‘multi’ containers. Polygons are specified using one outer boundary and zero or more holes, which is the standard practice. The ‘google.data.feature’ object contains prop- erties and geometry data, which is used to render styled features on the map, but uses a 2D canvas to draw the data. In order to draw the shape, this uses a technique called a ‘Path Geometry’, which is based on drawing scan lines from top to bottom with hor- izontal spans between two outer boundary points split by intersections with the inner boundaries. The two diagrams in figure 5.6 show the difference between the scan line approach and full triangulation.

(a) Scan line algorithm, with three scan lines taken through the object shown in red.

(b) Triangulation algorithm, showing one of a number of valid triangulations.

Figure 5.6: A geographic object containing two holes, showing the ‘scan line’ method for rendering a 2D shape, compared to the triangulation required for 3D rendering.

5.1. Example 1: Data Exploration and Web GIS 185