-
Notifications
You must be signed in to change notification settings - Fork 9
Gridviz tiling
This page presents Gridviz tiling mecanism.
It is not always pertinent and efficient to download and render an entire gridded dataset: only the part of the dataset which concern the space portion that is being visualised is really necessary. Tiling mechanism offers the solution for that, by decomposing the dataset into chunks which relate to different portions of space. This mechanism is crucial especially for very larger datasets (with high resolution), which are usually shown only for large scale, and thus only for small portions of space. See this document.
Implementing tiling requires the following components:
- A tiling scheme, which defines how a grid is decomposed into chunks. The chunks should have a pertinent size, neither too large, nor too small. The tiling scheme should be described in such a way that it is known by gridviz tool (that is it should be able to get the necessary data for each space portion). It should be independant from the CRS, so that it can be used with different datasets.
- A format, that is thin enough for data transfer and fast to parse/decode on the client side
- A tiling library to tile some input gridded datasets and publish them on the server side so that it can be consumed by a gridviz client.
- Enhanced capabilities of the client to be able to retrieve, decode and render gridded tiled data. A cache structure on the client side might be necessary, to store and index the downloaded tiles and avoid requesting them several times.
The tiling scheme relies on the following information:
- A predefined CRS, which does not need to be explicitelly defined but should be documented. Example: ETRS89-LAEA CRS.
- The geographic coordinates of the bottom left point of the tiling grid (x0, y0).
- The resolution of the grid R, in ground unit. Example: 1000m
- The size of the tiles S, in number of grid cells by raw/column. The tiles are supposed to be squared. Example: 256.
The tiles are numbered from 0, starting from the first tile on the top right of the origin point, and is incremented going north and east. Each tile thus has a pair of coordinates (xT, yT) in the tiling scheme, which allows locating and retrieving it it.
For a tile (xT, yT), the geographic extent is then:
- xMin = x0 + R.S.xT
- xMax = x0 + R.S.(xT+1)
- yMin = y0 + R.S.yT
- yMax = y0 + R.S.(yT+1)
For a geographic extent (xMin, xMax, yMin, yMax), the tiles to retrieve are within [xTMin,xTMax] * [yTMin,yTMax] where:
- xTMin = Floor( (xMin-x0)/(R.S) )
- xTMax = Floor( (xMax-x0)/(R.S) )
- yTMin = Floor( (yMin-y0)/(R.S) )
- yTMax = Floor( (yMax-y0)/(R.S) )
For the tile format, a first simple encoding would be CSV, with the following columns:
- 2 columns x and y, giving the coordinates (xt,yt) of the grid cell within the tile. These coordinate values should thus be within [0,S-1].
- One or several columns with statistical values for each cell. These values do not have necessarly to be numerical.
The geographical coordinates of a grid cell can thus be retrieved with:
- x = xMin + xt.R
- y = yMin + yt.R
Note 1: Not all cells need to be provided in each tile. The meaning of a missing cell has however to be agreed - it could mean "absence of data" or "0" value.
Note 2: Existing format and tools for tiled data are cogeo which could be used with geotiffjs. See also flatgeobuf
For the tiled structure, the tiles are organised to be retrieved easily, indexed by coordinate. A tiled dataset is published under a baseURL, and each tile under the URL baseURL/xT/yT.csv, where (xT, yT) is the coordinates pair of a tile in the tiling scheme. In addition to the tile data, information on the tiling sheme are published in a baseURL/index.json file. This file contains all information required by the client to interpret the tiled data. It includes:
- The CRS
- The geographic coordinates of the bottom left point of the tiling grid (x0, y0).
- The grid resolution R.
- The tile size S.
- The list of statistical values provided, and any useful information on them.
This section describes the process and tools to make tiled grids from input grids.
This section describes the mechanisms allowing the client to handle such tiled grid data.
A tiled gridded dataset is set to the client with a predefined zoom range. The client thus need to be able to store information on which dataset has to be shown for which zoom range. When the client zoom level changes, the datasets defined for this particular zoom level should be retrieved and displayed.
When a tiled gridded dataset is set, the first step is to retrieve the information provided in the baseURL/index.json file, which will allow displaying the gridded data.
The client should have a cache structure for tiled datasets, allowing to keep some downloaded tiles on the client side. Not all data should be kept, to ensure the client memory is not filled. Thus this cache should have a limited size and rely on a FIFO structure in order to release the least recently used tiles.
The management of tiled data should work in the following way:
- When the zoom level and/or x,y position of the viewshed changes then:
- Get the geographic extent of the viewshed (xMin, xMax, yMin, yMax)
- Get the coordinates of the tiles corresponding to this extent (see formula above) [xTMin,xTMax] * [yTMin,yTMax]
- For each tile (xT,yT), check if it is in the cache. If it is, display it else:
- Get the missing tile from baseURL/xT/yT.csv. Once received, check cache size: If cache full, clear oldest unused tile. Then store newly downloaded tile and display it.
- For the display of tiles, decode the position of all cells using the formula above and send the retrieved cells to the rendering engine. The rendering engine should thus be asked to handle one the cells within the view, which should not be so numerous thanks to the tiling and thus relativelly fast to render.
For the rendering, see this page