Visualizing Big Coastal Geodata in Compliance with the Open Geospatial Consortium (OGC) Technical Specifications

By Luqmaan Hassim, CSIR

Appropriately visualising the coastal flood lines for the local coastal municipalities of South Africa is a challenge. The main reason that this is a challenge, is because the raw data, which consist of multiple shapefiles, are approximately 20 Gigabytes (GB) in size. This means that it may not merely be loaded into a web Geographical Information System (GIS) and queried on the client’s browser.

To overcome this challenge, various Open Geospatial Consortium (OGC) technical specifications were assessed with regard to the dataset. To realise which of these specifications are most appropriate for the use case, we first need to determine what we will be presenting on the client’s browser, how it will be presented and in what format will these be presented.

The given shapefiles for the coastal flood lines represent multiple polygons contained in multiple shapefiles for different coastal regions, where each polygon represents a different elevation at that given location. The user must be able to filter through different depths on the web browser to effectively view a ‘simulation’ of the depth at various levels of the coastal local municipalities of South Africa.

To merely use the shapefiles as a data source that is locally stored on the client-side is automatically ruled out because of the large volume of the data. This raises another option, the use of a map server software such as Geoserver. The easiest method with the use of Geoserver would be to merely store the shapefiles in a data directory and point to the location of the stored shapefile within Geoserver. This allows the shapefile to be stored on the server side and the data to be queried via the typical OGC standards (e.g. Web Map Service – WMS and/or Web Feature Service – WFS, etc.).

Loading a Web Feature Service in JavaScript Object Notation (JSON) format into the Web GIS will require a large sum of data to be downloaded prior to the web page loading. For this reason, this method is completely ruled out. Secondly, making use of the raw data shapefiles in a file system means that Geoserver has to perform complex searches upon filtering, and immense computation for rendering. Thus, this entire method, too, was ruled out.

So how can this be solved?

The next best option was to make use of a spatial database, PostgreSQL along with the PostGIS extension.  The database enables us to remove values within the shapefiles that are not required, change ‘double’ data types to ‘integer’ values, index the numeric and spatial values, and create materialized views of the data, which tremendously optimises queries and leaves the only hard work of Geoserver as a renderer.

So we did this:

We then made use of a Wep Map Service-Time (WMS-T) in order to visualize materialized views for each coastal local municipality.  Unfortunately, this change did not provide us with the desired speed required for optimal interactivity.  Hence, we dwelled a bit further down into the OGC specifications and found an interesting specification called Web Map Tile Service (WMTS) which presents the data in a vector from (mapbox-protobuf).  The use of this specification for this use case seemed ideal.  All that was required was a simple installation of the WMTS extension, available on the Geoserver community builds server (https://docs.geoserver.org/stable/en/user/extensions/vectortiles/tutorial.html).

So we did this too:

These vector tiles were extremely fast! However, the problem that exists here, is that filtering the data became a challenge. There are no distinct means to filter vector tile data by elevation, as available with the WMS-T specification. In simple words, there is no exact specification for WMTS-T!

For a few days, we thought that this means of rendering the data is no longer of importance for this use case because we cannot visualize the data interactively. Until we realised that the elevation filter and each value of the elevation which required filtering must be explicitly added. This is because vector tiles are cached on the server side. All was finally well, and we were good to go. Until we realised that this cache would become extremely large if we want the system to be running optimally. That and styling became an issue- since using this method requires a dynamic stylesheet for depth visualization.

What now?

The final and true solution, at last – it was decided that the depiction of depth is best represented as multiple raster surfaces represented at various depths. Using the Geospatial Data Abstraction Library (GDAL), the elevation was inverted to represent depth at each level of elevation respectively for each coastal local municipality. Multiple rasters at each depth for each region respectively was ‘stacked’ using the image mosaicing plugin of Geoserver. This method allows the data to be portrayed by the use of a WMS-T or WMTS with elevation and allows us to make use of a simple rule-based stylesheet, where each value represents a different shade of blue for depth. This method produced the most viable solution and has been implemented.