Up
Supercharged Online Data Access
History
BRERC data is mainly accessible via our own online apps. These leverage tailored middleware in a database (PostgreSQL) and application server (GeoServer). Some limited facilities existed for other users. But that is changing! In future we will offer comprehensive OGC standards-based options for all users. The GeoPackage format plays a key role in this.
Initiative
One or more customised GeoPackages will be created for each partner organisation. A zipped copy of this may be downloaded from our website for use locally in whatever way desired, for example in any modern GIS application (ArcGIS, MapInfo, etc). To unzip the archive the user needs an authentication key (authkey). Alternatively, Web Service requests can be made to any of the GeoPackage's layers, which are all published in GeoServer. In this case an 'authkey=...' parameter must be added to each request to authenticate. It isn't recommended to download large amounts of data by WFS but that is possible too. The only limitation is a scheduling restriction of one job at a time (per user) to prevent overloading of our servers. You can even develop your own apps incorporating standard WMS or WFS requests. Don't forget that GeoPackages are actually SQLite databases and can be optimised for your own application(s).
Technical
LIVE Services is designed for speed and security and therefore memory-based. For this initiative, which can involve large amounts of data, we add secondary storage on the frontend server. It is secured by kernel-based encryption. There is a folder for each user (BRERC partner). Each folder contains the GeoPackage(s), and their corresponding zipped version(s), for that user. At regular intervals the backend server mounts the secondary storage using SSHFS. It then executes a series of GDAL ogr2ogr commands to stream data into GeoPackages on the frontend server. GeoPackage layers can be generated from PostgreSQL tables and/or views, or from other GIS file formats (Shapefile, MapInfo TAB/DAT, etc). The backend server then uses SSH to remotely zip up the GeoPackages and creates links to both in the appropriate places on the frontend server. These are the GeoServer data directory and the website download folder. Finally it publishes each GeoPackage in GeoServer, that is, it creates a 'featuretype' for each layer in the GeoPackage, using the GeoServer REST interface. This is possible because a GeoPackage can be treated as a 'store' in GeoServer. Once the backend (database) server has set up the GeoPackages, off-peak, it is then freed up to concentrate on its primary role - supporting applications.
Web Services
These include WMS (Web Map Service) and WFS (Web Feature Service). They are quite different, but complementary. WMS delivers raster tiles which make up a map image already styled on the server. Typically you can then click on the map to get detailed feature info. WFS is feature-orientated at the outset, delivering geometry and associated attributes for local processing, including complex geospatial analysis. These services return exactly the same data that you can download in a zipped GeoPackage.
First check out the GeoServer WMS reference and WMS vendor parameters, and the WFS reference and WFS vendor parameters.
The GeoServer 'Catalog Mode' is set to HIDE to ensure that users only see featuretypes (layers) that they have access to. This is crucial because there will be many users and therefore many GeoPackages, each having many layers, and not all layer names will be unique.
Enter your authkey to view the layers available to you. Prospective users can just accept the default for a demo.
Click to start
Up