Skip to main content

Inventory of geospatial layers and web maps provided by the BAS Mapping and Geographic Information Centre (MAGIC), visualised in Airtable.

Project description

MAGIC Web Map Inventory

Inventory of geospatial layers and web maps provided by the BAS Mapping and Geographic Information Centre (MAGIC), visualised in Airtable.

See the Data model section for more information about what this inventory holds.

Note: This project is designed for internal use within MAGIC, but is offered to anyone with similar needs.



These tasks run in a container. See the Setup section for setup instructions.

If running locally:

$ docker run --rm=true --tty --interactive --volume [path to runtime directory]:/home/geoweb/apps/web-map-inventory/data/:rw bash
$ web-map-inventory [task]

(Where [path to runtime directory] is the path to a runtime created during Setup),

If using the BAS central worksations use this instead:

$ podman run --rm=true --tty --interactive --user=root --volume ~/.config/web-map-inventory/:/home/geoweb/apps/web-map-inventory/data/:rw bash
$ web-map-inventory [task]

data fetch

Fetches information about servers, namespaces, repositories, styles, layers and layer groups from servers defined in a data sources file. Fetched information is saved to an output data file.


  • -s, --data-sources-file-path:
    • path to a data sources file
    • default: data/sources.json
  • -d, --data-output-file-path:
    • path to a data sources file
    • default: data/data.json

Note: Currently this task results in new IDs being generated for each resource, even if it already exists. This will lead to resources being removed and re-added unnecessarily but will always remain internally consistent.

data validate

Validates protocols offered by servers defined in a data sources file (by default data/sources.json).


  • -s, --data-sources-file-path:
    • path to a data sources file
    • default: data/sources.json
  • -i, --data-source-identifier:
    • identifier of a server in the data sources file
    • use special value all to select all data sources
  • -p, --validation-protocol:
    • protocol to validate
    • default: wms

Note: Currently this task is limited to the WMS (OGC Web Map Service) protocol.

airtable status

Checks local items against Airtable to check whether they are up-to-date (current), outdated, missing or orphaned.

airtable sync

Creates, updates or removes items in Airtable to match local items.

airtable reset

Removes all data from Airtable.

Managing data sources

Each data source is represented as an object in the server list in data/sources.json [1]. The structure of each source depends on its type. For more general information, see the Data sources section.

[1] This file is either in the runtime path created during Setup or ~/.config/web-map-inventory/ on the BAS central servers).

Adding new data sources

Note: See Supported data sources for currently supported data sources.

Once added use the data fetch task.

Adding a GeoServer data source

Property Required Data Type Allowed Values Example Value Description Notes
id Yes String A ULID (Universally Unique Lexicographically Sortable Identifier) 01DRS53XAJNH0TNBW5161B6EWJ Unique identifier for server/source See below for how to generate
label Yes String Any combination of a-Z, A-Z, 0-9, -, _ a-1_A Using a short, well-known identifier -
hostname Yes String Any valid hostname - -
type Yes String geoserver See allowed value - -
port Yes String Any valid port number 8080 - Usually 80 or 8080
api-path Yes String /geoserver/rest See allowed value Defined by GeoServer -
wms-path Yes String /geoserver/ows?service=wms&version=1.3.0&request=GetCapabilities See allowed value Defined by GeoServer -
wfs-path Yes String /geoserver/ows?service=wfs&version=2.0.0&request=GetCapabilities See allowed value Defined by GeoServer -
username Yes String Any valid GeoServer username admin Usually the GeoServer admin user -
password Yes String Password for GeoServer user password Usually the GeoServer admin user -

Note: Use to generate ULIDs manually.


  "id": "xxx",
  "label": "example",
  "hostname": "",
  "type": "geoserver",
  "port": "80",
  "api-path": "/geoserver/rest",
  "wms-path": "/geoserver/ows?service=wms&version=1.3.0&request=GetCapabilities",
  "wfs-path": "/geoserver/ows?service=wfs&version=2.0.0&request=GetCapabilities",
  "username": "admin",
  "password": "password"


Flask application using the airtable-python-wrapper library to interact with the Airtable API.


Data is synced to the MAGIC Maps and Layers Inventory Base in the BAS MAGIC Workspace.

Data model

This project, an inventory, consists of information held in geospatial services. The data model is intended to be generic to support different data sources and technologies.

This data model consists of:

  • Servers: Represent a source of geospatial information, such as an instance of a technology or a whole platform
  • Namespaces: Represent a logical grouping of resources within a server/endpoint
  • Repositories: Represent a data source that backs one or more layers
  • Styles: Represent a definition for how data in a layer should be represented/presented
  • Layers: Represent a logical unit of geospatial information
  • Layer Groups: Represent a logical grouping of one or more layers that should be treated as a single, indivisible unit

It can be visualised as:

data model visualisation

Data sources

Data sources are servers in the project Data model and define connection details for APIs and services each server type provides for fetching information about components they contain (e.g. listing layers).

A data sources file, data/sources.json, is used for recording these details. An example is available in data/sources.example.json. See the Adding a data source section for more information.

A JSON Schema, bas_web_map_inventory/resources/json_schemas/data-sources-schema.json, validates this file.

Supported data sources

  • GeoServer
    • Using a combination of its admin API and WMS/WFS OGC endpoints


Configuration options are set within bas_web_map_inventory/

All Options are defined in a Config base class, with per-environment sub-classes overriding and extending these options as needed. The active configuration is set using the FLASK_ENV environment variable.

Most options can be Set using environment variables or files.

Configuration options

Option Required Environments Data Type (Cast) Source Allowed Values Default Value Example Value Description Notes
FLASK_APP Yes All String .flaskenv Valid FLASK_APP value See default value See Flask documentation -
APP_ENABLE_SENTRY Yes All Boolean .flaskenv True/False False (for development/testing), True (for staging/production) True Feature flag for Error reporting -
SENTEY_DSN Yes Yes String .flaskenv Sentry DSN for this project See default value Sentry Data Source Name This value is not a secret
AIRTABLE_API_KEY Yes All String .env Valid AirTable API key - keyxxxxxxxxxxxxxx AirTable API Key -
AIRTABLE_BASE_ID Yes All String .env Valid AirTable Base ID - appxxxxxxxxxxxxxx ID of the AirTable Base to populate/use -

Options are set as strings and then cast to the data type listed above. See Environment variables for information about an options 'Source'.

Flask also has a number of builtin configuration options.

Setting configuration options

Variable configuration options can be set using environment variables or environment files:

Source Priority Purpose Notes
OS environment variables 1st General/Runtime -
.env 2nd Secret/private variables Generate by copying .env.example
.flaskenv 3rd Non-secret/public variables Generate by copying .flaskenv.example

Note: these sources are a Flask convention.

Error tracking

Errors in this service are tracked with Sentry:

Error tracking will be enabled or disabled depending on the environment. It can be manually controlled by setting the APP_ENABLE_SENTRY variable in .flaskenv.


Logs for this service are written to stdout and a log file, /var/log/app/, depending on the environment.

File based logging can be manually controlled by setting the APP_ENABLE_FILE_LOGGING and LOG_FILE_PATH variables in .flaskenv.

Note: If LOG_FILE_PATH is changed, the user in the user the container rans as must be granted suitable write permissions.

XML Catalogue

An XML Catalog is used to cache XML files locally (typically XSD's for schemas). This drastically speeds up XML parsing and removes a dependency on remote endpoints.

XML files in the catalogue are typically stored in bas_web_map_inventory/resources/xml_schemas/.

Different catalogue files are used for different container variants due to differences in the applications location:

  • :latest: ./support/xml-schemas/catalogue.xml
  • /deploy: provisioning/docker/catalog.xml

In either case, the catalogue is available within the container at the conventional path, /etc/xml/catalog, and will be used automatically by most XML libraries and tools (such as lxml and xmllint).


The application for this project runs as Docker container. It can be setup locally or on the BAS central worksations using Podman. You will need access to the private BAS Docker Registry (part of, or the ability to build images container images locally

Note: Podman support in BAS is currently experimental, contact the IT Service Desk for more information. Unless noted, docker commands listed here can be replaced with podman.

$ docker login
$ docker pull

Note: Other image tags are available if you want to run pre-release versions, or a specific previous version.

You will need to create a directory to contain required Configuration files and data output:

$ mkdir -p ~/.config/web-map-inventory

See the Data sources and Usage sections for how to use and run the application.


Development container

$ git clone
$ cd map-layer-index

The :latest Docker tag/image is used for developing this project. It can be ran using Docker and Docker Compose:

$ docker login
$ docker-compose pull app

Then create/configure required Configuration files:

$ cp .env.example .env
$ cp .flaskenv.example .flaskenv
$ cp data/sources.example.json data/sources.json

To run/test application commands:

$ docker-compose run app flask [task]

[1] You will need access to the private BAS Docker Registry (part of to pull this image. If you don't, you can build the relevant image/tag locally instead.

Code Style

PEP-8 style and formatting guidelines must be used for this project, with the exception of the 80 character line limit.

Black is used to ensure compliance, configured in pyproject.toml.

To apply formatting manually:

$ docker-compose run app black bas_web_map_inventory/

To check compliance manually:

$ docker-compose run app black --check bas_web_map_inventory/

Checks are ran automatically in Continuous Integration.

Type hinting

Python type hints should be used for this project, with the exception of missing import errors (which can be ignored).

MyPy is used to ensure types agree (where defined), configured in mypy.ini.

To check usage manually:

$ docker-compose run app mypy bas_web_map_inventory/

Checks are ran automatically in Continuous Integration.


Python dependencies for this project are managed with Poetry in pyproject.toml.

The development container image installs both runtime and development dependencies. Deployment images only install runtime dependencies.

Non-code files, such as static files, can also be included in the Python package using the include key in pyproject.toml.

To add a new (development) dependency:

$ docker-compose run app ash
$ poetry add [dependency] (--dev)

Then rebuild the development container and push to GitLab (GitLab will rebuild other images automatically as needed):

$ docker-compose build app
$ docker-compose push app

Static security scanning

To ensure the security of this API, source code is checked against Bandit for issues such as not sanitising user inputs or using weak cryptography. Bandit is configured in .bandit.

Warning: Bandit is a static analysis tool and can't check for issues that are only be detectable when running the application. As with all security tools, Bandit is an aid for spotting common mistakes, not a guarantee of secure code.

To run checks manually:

$ docker-compose run app bandit -r .

Checks are ran automatically in Continuous Integration.


Use the Flask default logger. For example:'Log message')

When outside of a route/command use current_app:

from flask import current_app'Log message')

XML Catalogue additions

If new functionality is added that depends on XML files, such as XSDs, it is strongly recommended to add them to the XML catalogue, especially where they are used in tests.

Once added, you will need to rebuild and push the project Docker image (see the Dependencies section for more information).

Editor support


A run/debug configuration, App, is included in the project.


All code in the bas_web_map_inventory module must be covered by tests.


This project uses PyTest for unit/integration testing. Tests are defined in tests/ and should be ran in a random order using pytest-random-order.

To run tests manually from the command line:

$ docker-compose run app -e FLASK_ENV=testing app pytest --random-order

To run tests manually using PyCharm use the included App (Integration) run/debug configuration.

Tests are ran automatically in Continuous Integration.

Test coverage

pytest-cov is used to measure test coverage.

To prevent noise, .coveragerc is used to omit empty files from reports.

To measure coverage manually:

$ docker-compose run app -e FLASK_ENV=testing app pytest --cov=bas_web_map_inventory --cov-fail-under=100 --cov-report=html .

Continuous Integration will check coverage automatically and fail if less than 100%.

Continuous Integration

All commits will trigger a Continuous Integration process using GitLab's CI/CD platform, configured in .gitlab-ci.yml.


Python package

This project is distributed as a Python package, hosted in PyPi.

Source and binary packages are built and published automatically using Poetry in Continuous Delivery.

Package versions are determined automatically using the support/python-packaging/ script.

Docker image

This project is distributed as a Docker/OCI image, hosted in the private BAS Docker Registry (part of

Continuous Delivery will automatically build a /deploy:latest image for commits to the master branch, as well as /deploy:release-stable and /deploy:release-[release] images for tagged commits.

Note: This image cannot be built outside of GitLab, as it relies on artifacts passed between build stages.

Continuous Deployment

All commits will trigger a Continuous Deployment process using GitLab's CI/CD platform, configured in .gitlab-ci.yml.

Release procedure

For all releases:

  1. create a release branch
  2. close release in
  3. push changes, merge the release branch into master and tag with version


The maintainer of this project is the BAS Mapping and Geographic Information Centre (MAGIC), they can be contacted at:

Issue tracking

This project uses issue tracking, see the Issue tracker for more information.

Note: Read & write access to this issue tracker is restricted. Contact the project maintainer to request access.


© UK Research and Innovation (UKRI), 2019 - 2020, British Antarctic Survey.

You may use and re-use this software and associated documentation files free of charge in any format or medium, under the terms of the Open Government Licence v3.0.

You may obtain a copy of the Open Government Licence at

Project details

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Files for bas-web-map-inventory, version 0.2.1
Filename, size File type Python version Upload date Hashes
Filename, size bas_web_map_inventory-0.2.1-py3-none-any.whl (44.0 kB) File type Wheel Python version py3 Upload date Hashes View hashes
Filename, size bas-web-map-inventory-0.2.1.tar.gz (60.8 kB) File type Source Python version None Upload date Hashes View hashes

Supported by

Elastic Elastic Search Pingdom Pingdom Monitoring Google Google BigQuery Sentry Sentry Error logging AWS AWS Cloud computing DataDog DataDog Monitoring Fastly Fastly CDN DigiCert DigiCert EV certificate StatusPage StatusPage Status page