Up

OpenLayers Viewer

Introduction

This is a completely new single page web application utilizing the latest version of the OpenLayers online mapping library.

Concept
Version 2.x of OpenLayers held sway for many years. All BRERC OpenLayers pages used it. Eventually version 3 appeared and the flood gates were opened. It was a complete rewrite and we are currently up to v8.x and counting. So this work is my first 'Next Generation' OpenLayers offering. Instead of writing the same app over and over again "until I get it right" the intention is to do most if not all of what came before in a single page. At the same time the aim is to make everything more elegant (efficient, functional, simple).

Context
There is now a database table containing controlling information for viewer applications. This contains things like extent and map view centre for 'contexts' such as BRERC and SW, which can be derived from the first parameter in the invoking URL. This widens the scope of the solution and obviates the need for hard-coding in the page and/or complicated URL parameters.

Local Sites
This application demonstrates a practical use of the viewer as a replacement for BRERC Sites. Data comes directly from MapInfo TAB/DAT files uploaded daily to the PostgreSQL database. Two widely-differing layers are targetted - RIGS contains a modest number of relatively small sites, SNCI many more much larger ones. Compare for example Severn Estuary, River Avon, and tiny Cotham Park! Most routine source file changes can be accommodated automatically by the OpenLayers app and its infrastructure.

Overlays
The 'viewer' treatment can be applied to almost any GIS dataset of small to medium proportions. Potential overlays need only be identified by location (on a network or maybe even on the web). GDAL handles many GIS formats and of course uploads to PostgreSQL. It generates its own internal key, and we take the first text column as a feature 'name'. Backend processing to accommodate new/altered layers is totally automated. For each target layer we generate an extra layer for geometry errors. A geometry error appears as a tiny black square on the map, which you can click on for feature info (reason and co-ordinates). Only one error at a time exists for each overlay because PostGIS stops checking after the first one.
There is currently a limit of 1000 features per overlay.

Feature Info Formatting
Feature info is retrieved from the server by WMS GetFeatureInfo which is pre-formatted html. The only two data types currently recognised are text (including numbers) and dates. Dates are formatted 'YYYY-MM-DD' but this can be changed if necessary. There is also another 'pseudo type' - site assessment, which needs special treatment. Currently this type of data is a peculiarity of the sites layers but the principle of specially treated data types could have more general application. Site assessment requires table formatting inside the feature info table. A demo/interim solution has been implemented. Data from the now obsolete BRERC Sites is appended to the sites layers each time they are reloaded. Features are matched by sitename only. This take-on includes pre-formatting the table-within-a-table, but only the html elements. All styling of feature info is controlled in the viewer app.

Technical Highlights
Notable elements of infrastructure (from the top down) are as follows.


Web Service Endpoints
The term can mean (among other things) the URLs by which services are exposed, in this case by an application and its infrastructure. A few examples follow.
Explore BRERC region boundaries.
View BRERC Local Sites via a simplified URL redirected by Apache.
Try some other contexts eg ERCCIS, LONDON, WALES, SW.

Comments Please!
Please direct all feedback, questions, etc to my email address.

Up