In GIS raster data and vector data both represent features in a map. Vector data does this by creating lines, points and polygons, the vertices of which are digitised as accurately as possible to outline or pinpoint the feature. It can be an accurate way of representing map features. The downside is if a large number of features need to be mapped the files can become large in size. Large vector files can consume a lot system resource in order to render on screen, also, editing and spatial queries can become memory intensive.
Enter raster data. In these situations raster data can be used to speed up rendering and querying dramatically. In this example, the vector data represents a network coverage map. The prediction used to generate these maps also work using raster data for the aforementioned reason. Generally these raster coverage maps will be vectorised so they can be used in GIS systems as this is generally considered the default format to use. This creates a much larger file that may need to be split and tiled for different regions in order for the GIS to handle the entire dataset effectively.
Using raster handlers means this raster data can be opened in its native format without the requirement for conversion to vector format. This on its own reduces the workflow steps.
As an example below, the vector map opens quickly and can be drawn on screen in seconds, but performance degrades when zooming and panning. In this case point in poly queries are not practical without splitting the dataset in to smaller regions as the map is made up of nearly half a million complex polygons and will be run against 1.5 million address points. The result would be a point in poly query showing all addresses that fall within a polygon with the attribute “No Coverage”. This allowing a sum of the population not covered to be calculated. Unfortunately using these two vector files it is not feasible to return the result in a practical time.
The same coverage map as a raster file is not only much smaller in terms of physical file size, but far more efficient to render on screen and query.
The raster version takes less than one second to render in the map window. To run the equivalent of a point in poly query the Raster operation Point Inspection can be used. The Point Inspection operation applies the underlying raster cell value to the overlying point. So in this example, it will assign the predicted coverage value for that address to a new column in the address point file. The vector address file can then be queried easily using SQL Select to find only the addresses not covered by the network and the count.
In this example the Point Inspection takes 42 seconds to assign 1.5 million addresses a network coverage reading of either No Coverage or Good Indoors and Outdoors. A quick Filter using the browser can then be applied to query only the addresses not covered by the network.
The resultant query shows the addresses in green, they can be clearly seen to sit inside the areas of the coverage map that indicate No Coverage in red.
This process takes less than a minute, using vector data the process needs to broken down it to multiple steps and processed over a much longer period of time. The raster method opens up new ways to query large datasets without complex work processes.
(The network used in this example is fictitious data)
Thanks Chris for showing the immense potential in the Raster formats.
I’ve been working with coverage maps for mobile and fixed telecoms for many years. It is certainly true that raster has come on a long way over the past decade. Several industries have needed to work with larger rasters, so better methods of handling them (tiling, pyramids, compression, etc.) have been developed and implemented. Computers with ever-increasing working memory has also helped.
The choice between using vector and raster for telco coverage is often a fine line. While the output from radio planning tools is usually raster, there are operations such as reprojection which are computationally expensive. So, if someone’s use case needs that (perhaps aggregating international coverages normalised for roaming purposes), vector may still be a better choice.
The complexity of coverage data is also down to the maturity of a network. Several years ago, I presented a session at GITA which talked about this. During the early stages of a network deployment (a new provider or perhaps new generation of technology), coverage is minimal – perhaps a few a small number of city islands. Vector is better for that. During widespread rollout, those islands join up and you get rather complicated patterns. Raster is perhaps now a better option. A “bumpy” country where physical features and population distribution means that even “finished” coverage has these complications. Small, flat, dense countries end up almost being a single polygon and vector once again becomes best. e.g. Singapore, where the local regulator makes it a requirement for 100% coverage by all operators.
Thanks for your insight Warren. I agree, it is a horses for courses type situation as you say, the end application should always be considered when making the choice between data types.
Thanks for sharing and interesting discussion.
Not only the output from? planning tools usually are in raster format, but also the input data. Terrain/height data and clutter (landuse) data are often in raster format to get a continous data. With higher frequencies and denser networks the need for better resolutions has lead to larger and larger file sizes. The demand in the market is going towards at least 10m raster for whole countries. Until the introduction of the mrr-format this was becoming a real obstacle for us to handle. But as you mention Warren, this has greatly improved in the last couple of years
@Johan Frossling? thanks for your comment, this is what we see from our customers too. The land class/use data raises an interesting discussion too, what is deemed relevant accuracy from this point of view, what granularity is required? What would be too much/too little detail, what would be considered the appropriate scale going forward looking at ever increasing deployment of small scale networks? At the other end of the of the spectrum there is the narrow band IOT deployments. Lot's of different technologies and more coming online as we go forward, is the multi resolution raster format that has the ability to hold multiple rasters in a single file be potentially useful here? The ability to handle multiple different datasets together in multi-banded raster file?
@Chris Jenkins? Yes there is always the balance to find the most cost-effective data for each scenario. We really do not want more detail than needed, since details usually are connected to higher cost and production time?. So as you say we are a looking at using different resolutions for different areas (core urban area, suburban, rural) where one can deploy different types of networks/technologies, in which case the multi-resolution capability is very handy.