diff --git a/.gitignore b/.gitignore
index f9183b8..370294d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -37,11 +37,13 @@ services/postgis/pgadmin.env
.env
ansible/hosts/prod.yml
ansible/setenv.yml
-services/ldproxy/data/proj/
ansible/vars/vars.yml.old
+services/ldproxy/data/proj/
+services/admin/ghc.env
# data files
+services/ldproxy/data/
services/pygeoapi/data/
services/geoserver/data/
services/qgis/data/
diff --git a/ansible/bootstrap.yml b/ansible/bootstrap.yml
index 4bc0467..1eae72f 100644
--- a/ansible/bootstrap.yml
+++ b/ansible/bootstrap.yml
@@ -1,5 +1,5 @@
# Inspired from https://github.com/5car1z/ansible-debian-provisioning
-- name: "NGDI-20-60 OGC API Ubuntu Server Setup"
+- name: "HEIG-VD OGC API Ubuntu Server Setup"
hosts: all
become: true
gather_facts: yes
diff --git a/docs/README.md b/docs/README.md
deleted file mode 100644
index 128f8e8..0000000
--- a/docs/README.md
+++ /dev/null
@@ -1,65 +0,0 @@
-# Documentation Website
-
-The PGC API Testbed [website](https://apitestdocs.geonovum.nl) is powered
-by [MkDocs](https://www.mkdocs.org) which facilitates easy management
-of website content and publishing.
-
-## Setting up the website environment locally
-
-```bash
-# build a virtual Python environment in isolation
-python3 -m venv apitestdocs-website
-cd apitestdocs-website
-# download the website from GitHub
-git clone https://github.com/geonovum/ogc-api-testbed.git
-cd ogc-api-testbed/docs
-# install required dependencies
-pip install -r requirements.txt
-# build the website
-mkdocs build
-# serve locally
-mkdocs serve # website is made available on http://localhost:8000/
-```
-
-## Content Management Workflow
-
-### Overview
-
-To manage content you require an account on GitHub. From here you can either
-1. fork the repository, make your own changes and issue a pull request, or 2.
-edit the content directly. For option 2 the necessary permissions are required.
-
-The basic workflow is as follows:
-
-- manage content
-- commit updates
-- publish to the live site
-
-### Adding a page
-
-```bash
-vi docs/new-page.md # add content
-vi mkdocs.yml # add to navigation section
-# edit any other files necessary which may want to link to the new page
-git add docs/new-page.md
-git commit -m 'add new page on topic x' docs/new-page.md mkdocs.yml
-git push origin main
-```
-
-### Updating a page
-
-```bash
-vi content/page.md # update content
-git commit -m 'update page' content/page.md
-git push origin main
-```
-
-## Publishing updates to the live site
-
-Website updates are automatically published via GitHub Actions, but just in case:
-
-```bash
-# NOTE: you require access privileges to the GitHub repository
-# to publish live updates
-mkdocs gh-deploy -m 'add new page on topic x'
-```
diff --git a/docs/docs/CNAME b/docs/docs/CNAME
deleted file mode 100644
index 1b0322b..0000000
--- a/docs/docs/CNAME
+++ /dev/null
@@ -1 +0,0 @@
-apitestdocs.geonovum.nl
diff --git a/docs/docs/cases/INSPIRE.md b/docs/docs/cases/INSPIRE.md
deleted file mode 100644
index c8f5a0a..0000000
--- a/docs/docs/cases/INSPIRE.md
+++ /dev/null
@@ -1,66 +0,0 @@
----
-title: INSPIRE findings
----
-
-# INSPIRE findings
-
-The INSPIRE community has described an approach to provide [INSPIRE Download services using OGC API Features](https://github.com/INSPIRE-MIF/gp-ogc-api-features/blob/master/spec/oapif-inspire-download.md). This document reviews this approach for various products used in the testbed.
-
-Similar to Atom the
-[Main principles](https://github.com/INSPIRE-MIF/gp-ogc-api-features/blob/master/spec/oapif-inspire-download.md#71-main-principles-) of the approach indicate to set up a single api endpoint for this dataset. Both GeoServer and LDProxy offer capabilitiy to set up multiple endpoint within a single service, for pygeoapi we have to set up a new service.
-
-## Requirements class “INSPIRE-pre-defined-data-set-download-OAPIF”
-
-| MRCO | Aspect | pygeoapi | GeoServer | LDProxy | Comment |
-| --- | --- | --- | --- | --- | --- |
-| M | Supports OpenApi 3.0 | + | + | + | GeoHealthCheck found issues in GeoServer and pygeoapi |
-| M | /collections has metadata link for dataset | + | - | ? | pygeoapi is flexible for configuring any type of links |
-| C | If HTML endoding, /collections has metadata link as html | + | - | ? | |
-| C | For harmonised datasets, on collection level a Powered by
- {{ version }}
-
-```
-
-## pycsw
-
-The implementation of OGC API Records in pycsw is derived from the pygeoapi implementation. The templates are located at `~/pycsw/ogc/api/templates`.
-
-## QGIS
-
-QGIS uses similar jinja templates as pygeoapi, you can override the resources folder via the environment variable QGIS_SERVER_API_RESOURCES_DIRECTORY. The standard location of the templates is `~/qgis/resources/server/api/ogc/templates/wfs3`.
-
-## GeoServer
-
-GeoServer uses [Freemarker templates](https://freemarker.apache.org/) to render content in html. These `.ftl` files are persisted within `.jar` files. A basic override approach could be to extract `gs-ogcapi-features.jar` to a folder, adjust the templates, and zip the package back to a `.jar` file and deploy it. GeoServer also provides a template override mechanism from the data folder. Read more at a [dedicated blog on this topic](https://docs.geoserver.org/latest/en/user/community/ogc-api/features/index.html#service-configuration).
- Freemarker uses a similar substitution mechanism as jinja:
-
-```html
- Mail: ${contact.contactEmail}
-```
-
-To highlight the impact of skinning, we have prepared a tailored skin for geoserver at https://apitestbed.geonovum.nl/geoserver/ogc/features. We've added a layout inspired on the GeoNovum website. For this, 2 layout template overrides have been added to `~/data/templates/ogc/features`.
-
-## LDProxy
-
-The HTML encoding is implemented using [Mustache templates](https://mustache.github.io/). Custom templates are supported, they have to reside in the data directory under the relative path `templates/html/{templateName}.mustache`, where `{templateName}` equals the name of a default template (see [source code](https://github.com/search?q=repo%3Ainteractive-instruments%2Fldproxy+extension%3Amustache&type=Code) on GitHub) (taken from [ldproxy docs](https://github.com/interactive-instruments/ldproxy/blob/fb772a7c3bc9b32cdde06a1ac92bbb72414b07d1/docs/en/configuration/services/building-blocks/html.md#customization)).
-
-## GeoNetwork
-
-GeoNetwork offers an experimental OGC API Records implementation at https://github.com/geonetwork/geonetwork-microservices/tree/main/modules/services/ogc-api-records. This plugin can be installed on the latest v4 GeoNetwork. GeoNetwork uses [xslt](https://en.wikipedia.org/wiki/XSLT) to provide a html interface. The xslt templates are located at https://github.com/geonetwork/geonetwork-microservices/tree/main/modules/services/ogc-api-records/src/main/resources/xslt/ogcapir.
-
-```xml
-
-```
\ No newline at end of file
diff --git a/docs/docs/credits/index.md b/docs/docs/credits/index.md
deleted file mode 100644
index 9400cef..0000000
--- a/docs/docs/credits/index.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Credits
----
-
-# Credits
-
-The *OGC API Testbed Platform* was initially developed in May-June 2021 by [Geonovum](https://geonovum.nl).
-
-Developers were, alphabetically:
-
-* [Thijs Brentjens](https://github.com/thijsbrentjens), also team-lead, point of contact
-* [Just van den Broecke](https://github.com/justb4)
-* [Paul van Genuchten](https://github.com/pvgenuchten)
diff --git a/docs/docs/findings/index.md b/docs/docs/findings/index.md
deleted file mode 100644
index 9ea8bd4..0000000
--- a/docs/docs/findings/index.md
+++ /dev/null
@@ -1,92 +0,0 @@
----
-title: Installation findings
----
-
-# Installation findings
-This document lists some of the experiences during installation and creation of the software, for example:
-
-* what is easy to do, what not?
-* what is supported by which software?
-* configuration setup
-
-## Docker
-
-Docker (and related Cloud-technologies like Kubernetes and Cloud Foundry) are replacing the traditional
-installation and maintenance of web services, often dubbed as "[Box Hugging](https://m.subbu.org/code-the-infra-8c67a869cb89)".
-These Cloud-technologies are following the [Pets vs Cattle](https://www.hava.io/blog/cattle-vs-pets-devops-explained) paradigm.
-Many pro's and con's are documented.
-We list a number of them which came up during the project.
-
-Pro's
-
-* For setups of pygeoapi and geoserver with OGR support (used in wfs and geopackage backend) the use of Docker is attractive, due to complexity of managing dedicated dependencies.
-* Running the full platform locally doesn't require any effort. Traefik manages the change from https://domain to http://localhost transparently. But docker is the main driver of this capability.
-
-Con's
-
-* In the field there is a growing awareness that docker also has limitations. Docker images do not receieve similar efforts to keep them updated as the traditional systems. The risk of non patched vulnarabilities is higher when running a docker infrastructue.
-
-## Data management
-
-A typical use case will be that a geonovum employee arrives with some shapefiles to be published.
-The Shapefile can be deployed as part of the deployment (via github). An alternative route is to import the data into postgres. The data can then be used in various applications. Importing a shapefile into postgres requires direct connection to postgres or use the PGAdmin dump import. GeoServer (via GeoCat Bridge) has an option to upload a shapefile and import it to Postgres. See [HOWTO data](../howto/howto_database.md) on how to use both approaches.
-
-## Run infra locally
-
-The current deployment can be run locally on Linux and Mac easily, which is helpful
-to test a new development before creating the Pull Request.
-However it may be the case that this does not easily work on Windows.
-On the other hand, maybe this is not a scenario, because the Geonovum employee
-might update the configuration in `GitHub`, and deploy it to the Sandbox environment,
-and use that as a test prior to moving the configuration to the production system.
-
-## Use of attached storage
-
-Using attached storage is common for larger files with a focus on read access. Can we use it to store grids (tiff) or tile cache to make it accessible for various services? Using attached storage as backend for geopackage or postgres is not optimal on attached storage because of many concurrent requests and file locking. Attached storage is usefull for bulk downloads (inspire stored query). Read access to a tilecache can be usefull, but seeding is problematic, due to the number of write requests.
-
-## Load balancing
-Current setup does not have scaling (it is possible using traeffik, but currently not set up). It could be relevant to set up load balancing, at some point because it has its own type of challenges.
-
-Auto scaling as provided by for example Kubernetes, is not in scope for this experiment. Kubernetes generally requires a large hosting farm, such as azure, google.
-
-## Include geoserver in the experiment?
-
-We had some discussion if we should include GeoServer in the experiment. GeoServer is known to have challenges in cloud environments (memory usage, stability). But it is not explicitely known which challenges those are, and if their are ways to move around them. That's why it is usefull to include it. Also because the software has a high adoption at Dutch data providers.
-
-An aspect of GeoServer challenges in cloud is the complexity of its config files. The config files are designed around the web user interface which is commonly used to set them up, and heavily depends on relations identified by complex uuid strings. Running multiple geoservers along side requires to synchronise the config files over the instances. This gets extra challenging in case
-
-GeoServer has a jdbcconfig community module which allows to store the configuration in a database. But that plugin is not an official status yet (low TRL). Initiatives exist to define a geoserver cloud native strategy, based around an event bus.
-
-## URL configuration
-
-Products tend to include a configuration parameter to indicate the outside url in which the service is made available. This url is for example used in a getcapabilities response to indicate the endpoint of the service. In CI/CD environments this parameter is challenging, because it may vary based on how you access the service (via internal or remote). There is actually no need to persist this in a parameter, because the value is also provided by the x-forwarded-for header of the request. Mind that the gateway software should be set up to add the x-forwarded-for header to the request. GeoServer facilitates for example this use case, in the settings you can activate a setting: 'use header for proxy url'.
-
-Traeffik caused additional challenges for the CSRF token check in geoserver. Seems you have to whitelist the proxy domain or disable csrf check at all (our choice). CSRF support has been added to recent geoserver versions, it offers an additional protection against script attacks.
-
-## Log handling
-
-To set up a proper mechanism to persist and visualise (error) logs is an important aspect of a successfull SDI implementation. Logs can be evaluated to find the cause of a problem, or more general find aspects to improve on the implementation. 3 types of logs can be identified:
-
-- Error logs (generated by the application)
-- Usage logs (typically at the gateway level)
-- (un)availability (and hardware monitoring)
-
-Important aspects to evaluate is to prevent log files to grow to unexpected size and not get destructed at redeployment. Setting up proper log rotation is key. Another aspect to consider is that log files have a GDPR (AVG) aspect. Access logs typically persist ip adresses of endusers.
-
-### Error logs
-
-Within Docker it is a convention to report errors via stdout, so they are picked up by docker. LDProxy needs a dedicated configuration to set up logging to stdout.
-
-Tools like logstash are able to persist the logs from docker and visualise it in kibana. We have not implemented a central collection of error logs. Instead we delegate to [portainer](/portainer) for viewing logs.
-
-### Usage logs
-
-Traeffik needs to be set up to direct access-logs to a channel. A very basic option to persist and vizualise these logs is AWStats. More advanced tools are capable to cluster groups of requests, for example all requests within a certain bounding box or feature type.
-
-### Availability logs
-
-Various generic products exist such as pingdom, checkmk, zabbix, nagios. Cloud platforms such as kubernetes have embedded systems. A dedicated product exists for the geospatial world, called GeoHealthCheck. It monitors the availability (and to a degree the complience) of gis layers. (see [HOWTO ghc](../howto/howto_ghc.md) on how to use it)
-
-## Backup
-
-Backup (or synchronisation) should be set up for volatile data, such as databases and log files. These aspects are less relevant to this infrastructure, because we persist all configuration in GitHub and loss of the log files is not very critical. We therefore have not set up any backups or data synchronisation.
\ No newline at end of file
diff --git a/docs/docs/howto/howto_api_strategie.md b/docs/docs/howto/howto_api_strategie.md
deleted file mode 100644
index 669a3c2..0000000
--- a/docs/docs/howto/howto_api_strategie.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-title: HOWTO API Strategie
----
-
-# HOWTO set up a pygeoapi service following API Strategie
-
-
-
-
diff --git a/docs/docs/howto/howto_database.md b/docs/docs/howto/howto_database.md
deleted file mode 100644
index 37af717..0000000
--- a/docs/docs/howto/howto_database.md
+++ /dev/null
@@ -1,59 +0,0 @@
----
-title: HOWTO Database
----
-
-# HOWTO Database
-
-The infrastructure has a central [PostGreSQL](https://www.postgresql.org/) database which can be used by various services.
-
-## Managing tables
-
-A Webbased database manager (pgAdmin) has been installed at [https://apitestbed.geonovum.nl/pgadmin](https://apitestbed.geonovum.nl/pgadmin), which can be used to verify content in tables and administed tables and users. You can also create new tables and populate it using SQL queries (generated from a local database).
-
-## Uploading data to PostGreSQL from QGIS
-
-The testbed database exposes its port to the web for conveniance purposes, this is not very common in production situations. This allows QGIS to directly connect to the database. And you can use the QGIS DB manager to upload data.
-
-- Open the Data source manager to be able to add the testbed database to QGIS
-
-| key | value |
-| --- | --- |
-| service | |
-| host | apitestbed.geonovum.nl |
-| port | 5432 |
-| database | gis |
-| SSL | allow |
-| user | geopost |
-| pw | xxxxx |
-
-- Open DB Manager and select the testbed database
-- Click the 'Import Layer/File' button and complete the wizard
-
-## Connecting GeoServer to the central PostGreSQL
-
-From GeoServer admin you can create a `store` which connects to the central database. After which you can set up feature collections originating from that store.
-
-- On the stores page, create a `store`. Select a store of type PostGIS (not jndi).
-- Fill in the connection details:
-
-| key | value |
-| --- | --- |
-| host | postgis |
-| port | 5432 |
-| database | gis |
-| schema | public |
-| user | geopost |
-| pw | xxxxx |
-
-- From the layers screen, create a new layer.
-- Select the PostGreSQL store
-- Select the relevant table from the database.
-- Fill in the Layer fields, at minimum calculate the bounds of the layer.
-- Save and preview the layer
-
-## Uploading data to PostGreSQL from QGIS Bridge
-
-As part of the data publication process of QGIS Bridge, you can configure the data to be stored on PostGreSQL. Two options exist (as configuration on a server connection):
-
-- Bridge will send the data to GeoServer. And GeoServer will insert the data in PostGres.
-- Bridge will connect directly to the remote PostGreSQL and insert the data
diff --git a/docs/docs/howto/howto_deploy.md b/docs/docs/howto/howto_deploy.md
deleted file mode 100644
index f40bcd4..0000000
--- a/docs/docs/howto/howto_deploy.md
+++ /dev/null
@@ -1,137 +0,0 @@
----
-title: Service Deployment
----
-
-# Service Deployment
-
-The API testbed environment uses a configuration mechanism stored in the GitHub repository.
-Whenever GitHub detects a commit in the repository,
-a deployment on the remote server of the changed service is triggered automatically.
-Such an approach is known as [Continuous Deployment](https://en.wikipedia.org/wiki/Continuous_deployment) or "CD".
-
-The API Testbed uses Ansible and GitHub Workflows to enable CD. Effectively, new or changed Docker Containers
-and their configuration are deployed on a remote server (VM/VPS) from within GitHub.
-
-While a deployment task is running, you can follow its progress
-on [GitHub](https://github.com/Geonovum/ogc-api-testbed/actions).
-
-It is possible to directly commit your changes to GitHub, but a better practice is to
-work from [Pull Requests](https://en.wikipedia.org/wiki/Distributed_version_control#Pull_requests) often called a **PR**.
-Some discussion and an
-approval process can happen around a Pull Request, before it is merged and deployed.
-
-For your case, decide if you want to update an existing service or create a new service.
-All services in the platform are available as paths on a single domain.
-Each service contains an orchestration of one or more [Docker Containers](https://en.wikipedia.org/wiki/Docker_(software)),
-which together provide the functionality of the service. Docker containers are based on of-the-shelf
-product images from DockerHub, combined with a service-specific configuration.
-
-## Update a service
-
-Change the required files on an existing service folder.
-Either directly on GitHub, but preferably by cloning the repository locally and issuing a PR.
-Make the changes, commit, and push the changes.
-
-## Create a new service
-Firstly determine if you can instead update a service, for example with a new Collection, somewhat
-similar to a Layer.
-
-For a new service the best approach is to duplicate the entire folder of an existing service and change the required
-parameters within that folder. NB be sure to also preserve the executable properties of the `.sh` (Shell) files!
-Assumed is that the new service is using one of the existing components, thus services for
-GeoServer, pygeoapi, ldproxy etc.
-
-Creating a new service is basically the following multi-step process:
-
-### Step 1 - Duplicate Folder
-
-Duplicate the entire folder of an existing service and name it to the new service, say `xyz`.
-So it will reside in the folder `git/services/xyz/`.
-
-### Step 2 - Adapt Variables
-
-In the best case only a single line in the file `git/services/xyz/env.sh` needs
-to be adapted, i.e. the `SERVICE_NAME` variable. This will then automatically
-propagate the value for the subpath in the full service-URL plus other settings within the `docker-compose.yml` file.
-In the best case `docker-compose.yml` requires no changes.
-
-### Step 3 - Adapt Service Config and Data File(s)
-
-This step is specific to the service-component.
-For example `pygeoapi` has a single `local.config.yml`
-file. In many cases the full service URL with the subpath needs to be adapted.
-Others, like GOAF, may need var-settings in the `docker-compose.yml` file.
-Usually you will add data files like GeoPackage-files on a `/data/` subfolder.
-
-### Step 4 - Adapt Ansible Deploy File
-
-Duplicate a service definition in
-the [Ansible Playbook file deploy.yml](https://github.com/Geonovum/ogc-api-testbed/blob/main/ansible/deploy.yml).
-This file is under `git/ansible/deploy.yml`.
-
-Use the service name for the service (folder) like:
-
-```
- - name: "xyz"
- shell: "cd {{ services_home }}/xyz && ./deploy.sh && docker ps"
- tags: xyz
-```
-
-
-### Step 5 - Create a GitHub Action File
-
-This is a Action/Workflow File always to be placed under
-[.github/workflows](https://github.com/Geonovum/ogc-api-testbed/blob/main/.github/workflows)
-GitHub should execute this file (for our repo) when two conditions are met:
-
-1) a commit (direct or via a PR) to the `main` repository branch and
-2) when the change is made to the new `services/xyz` folder (or a subfolder).
-
-Also here: easiest is to copy any existing service deploy file
-like [deploy.pygeoapi.yml](https://github.com/Geonovum/ogc-api-testbed/blob/main/.github/workflows/deploy.pygeoapi.yml) and make a global
-change e.g. "pygeoapi" to "xyz".
-
-The file should look like:
-
-```
-name: xyz Deploy ⚙️
-
-# Trigger only when services/xyz subdir changed
-on:
- push:
- paths:
- - 'services/xyz/**'
-
-jobs:
- main:
- runs-on: ubuntu-20.04
-
- steps:
- - name: Checkout ✅
- uses: actions/checkout@v2
-
- - name: Run playbook ⚙
- uses: dawidd6/action-ansible-playbook@v2
- with:
- playbook: deploy.yml
- directory: ./ansible
- key: ${{secrets.ANSIBLE_SSH_PRIVATE_KEY}}
- inventory: ${{secrets.ANSIBLE_INVENTORY_PROD}}
- vault_password: ${{secrets.ANSIBLE_VAULT_PASSWORD}}
- options: |
- --tags xyz
- --verbose
-
-```
-
-Basically this file will execute the above Ansible Playbook `deploy.yml` for the tag `xyz` whenever a
-change is committed/pushed to the `services/xyz/` folder.
-
-## Testing your service
-
-You can either directly commit the service configuration in the sandbox and evaluate if it
-behaves properly. Alternatively you can clone the full repository locally and run the environment locally
-(installation of docker desktop is required) before committing. Always test your service in the sandbox
-environment before duplicating it to the production environment.
-
-Navigate to the `git/services/` folder in the project and run `./start.sh`
diff --git a/docs/docs/howto/howto_errors.md b/docs/docs/howto/howto_errors.md
deleted file mode 100644
index b68db3c..0000000
--- a/docs/docs/howto/howto_errors.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-title: HOWTO Analyse Errors
----
-
-# HOWTO Analyse Errors
-
-Error analyses is a bit hidden but the platform has various options to analyse challenges.
-
-## Errors during deployment
-
-When you push a configuration change to github, a github action will trigger
-to deploy the change to the platform. If such an action fails (the service is not available), the first step
-is to open [github actions](https://github.com/Geonovum/ogc-api-testbed/actions) and select the action related to your recent push. You can view the log of the action to look for a cause of the error.
-
-If you were not able to resolve the issue with above information, you can try to look for problems inside the
-container, as described in the runtime error section.
-
-A next step is to run the full platform locally, as described in [Run locally](./howto_platform.md). And see if the problem can be resolved locally.
-
-A final step would be to roll back the change to restore the previous state of the platform.
-
-## Runtime errors
-
-Run time errors, such as incidental error pages, page not found/unresponsive, etc are best anaylised
-via [portainer](./howto_portainer.md). It is important to know the name of the container causing the error.
-This name is assigned in the docker-compose file from which the project originates.
-
-Find the relevant container in portainer. From there you can view the logs of the conatainer, restart
-it and even open a webbased command line client to it.
-
-## Unavailability
-
-Services being unavailable can have various causes. A first place to check is [GeoHealthCheck](./howto_ghc.md) to evaluate if other services also have problems and how long the problem already exists. Usually restarting the service via portainer will resolve the issue. Else there may be a deployment problem (in a worse case scenario it is caused by the deployment of another service).
-
-
diff --git a/docs/docs/howto/howto_geoserver.md b/docs/docs/howto/howto_geoserver.md
deleted file mode 100644
index 729ceed..0000000
--- a/docs/docs/howto/howto_geoserver.md
+++ /dev/null
@@ -1,53 +0,0 @@
----
-title: HOWTO GeoServer
----
-
-# HOWTO GeoServer
-
-[GeoServer](https://geoserver.org) is a commonly used application server providing webservices based on OGC standards. GeoServer provides a web interface to set up new services, including extended authorisation options.
-
-GeoServer uses a concept of workspaces to cluster a series of collections. Each workspace in GeoServer is set up as a separate OGC API Features endpoint, e.g. https://apitestbed.geonovum.nl/geoserver/{workspace}/ogc/features, although geoserver also has an endpoint with access to all collections from all workspaces.
-
-This document lists 2 approaches to set up OGC API Features services in GeoServer. Both approaches can not be combined in a single GeoServer instance.
-
-## Dynamical setup
-
-GeoServer can be dynamically configured to add new services. 2 approaches are described:
-
-### Via Web Administrator
-
-This HOWTO describes how you can upload data and set up a new layer on GeoServer via the Web Administrator.
-
-* Most easy option to upload your data is to insert it into the PostGreSQL database using [PGAdmin](/pgadmin) or QGIS DB manager.
-* Log in to GeoServer
-* From the Stores page, create a new store
-* Select type PostGIS (not jndi), fill the connection details
-
-| key | value |
-| --- | --- |
-| host | postgis |
-| port | 5432 |
-| database | gis |
-| schema | public |
-| user | geopost |
-| pw | xxxxx |
-
-* From the layers screen, create a new layer
-* Select the PostGreSQL store and select the relevant table
-* Fill in the various tabs (at least calculate the layer bounds)
-* Test the layer via layer preview
-
-
-### Via GeoCat Bridge
-
-This HOWTO describes how you can use QGIS to setup a new layer on GeoServer. For QGIS a plugin called GeoCat Bridge is available which
-can publish a QGIS project as a workspace on GeoServer. The Bridge plugin is available via the plugins menu.
-
-We prepared a small [video about the steps involved](https://drive.geocat.net/s/PtNWacEFfP9AN7Z).
-
-
-## Scripted setup
-
-In a scripted setup the [data folder of GeoServer](https://github.com/Geonovum/ogc-api-testbed/tree/main/services/geoserver/data) is prepared locally and copied or mounted into the container as part of the deployment process. This setup is usefull when working with app-schema datasets ('complex GML'), which requires dedicated configuration which is not possible via the web administrator.
-
-A helpfull tool here is [Hale](https://github.com/halestudio/hale), which has an option to export a prepared data folder for geoserver, including the pre configured app-schema configuration
\ No newline at end of file
diff --git a/docs/docs/howto/howto_ghc.md b/docs/docs/howto/howto_ghc.md
deleted file mode 100644
index 2f2420b..0000000
--- a/docs/docs/howto/howto_ghc.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-title: HOWTO GeoHealthCheck
----
-
-# HOWTO GeoHealthCheck
-
-[GeoHealthCheck](https://geohealthcheck.org) (GHC)
-provides a monitoring service which indicates availability and compliance to the
-OGC API Features (OAFeat) standard.
-
-## GHC Model
-
-You may want to browse the [GHC Presentation Slides](https://geohealthcheck.org/presentation/index.html#/)
-to get an idea what GHC is about.
-
-The GHC conceptual model comprises the entities *Resources*, *Probes* and *Checks*.
-
-* *Resource* : basically the (URL) access/endpoint of your service instance. Example: a *WMS Endpoint*
-* *Probe* : action(s) performed on a *Resource*, for example a *WMS GetMap* request
-* *Checks*: test results/responses of a *Probe*: *Is the GetMap result an image?*
-
-In the GHC UI you will manage these three entities.
-
-## Add Monitoring for a Service
-
-- navigate to the GHC page e.g. [apitestbed.geonovum.nl/ghc/](https://apitestbed.geonovum.nl/ghc/)
-- Login
-- Click button upper right called *Add+*
-- Select *"OGC API Features (OAFeat)"* Resource Type
-- Add your full endpoint URL
-
-This brings you into the Resource Editor for your newly registered service endpoint (called a *GHC Resource*).
-By default, each new Resource gets a "Capabilities Probe" assigned which
-checks the overall health of your endpoint ("does it provide a valid Capabilities/OAS file?")
-In the editor you can set various parameters and additional "Probes" and "Checks".
-
-Be sure to have at least the following two Probes active:
-
-* **OGC API Features (OAFeat) Capabilities** - Validates OAFeat endpoint landing page
-* **OGC API Features (OAFeat) Drilldown** - Traverses all Collections in the endpoint validating if Features are returned
-
-The **OGC API Features (OAFeat) OpenAPI Validator** does a complete OAS3 JSON Schema validation on your OAS3 Endpoint JSON document.
-Most OAFeat implementations, except `pygeoapi` and `ldproxy` (as on June 30, 2021), fail this Probe.
diff --git a/docs/docs/howto/howto_goaf.md b/docs/docs/howto/howto_goaf.md
deleted file mode 100644
index 49d3568..0000000
--- a/docs/docs/howto/howto_goaf.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: HOWTO GOAF
----
-
-# HOWTO GOAF
-
-[GOAF](https://github.com/PDOK/goaf) is a OAF implementaion in Go, maintained by PDOK, originally developed as [Jivan](https://github.com/go-spatial/jivan).
-
-GOAF supports a PostGres or GeoPackage backend. Which file to serve the type of file are injected as environment variables.
-
-
-
-
-
diff --git a/docs/docs/howto/howto_inspire.md b/docs/docs/howto/howto_inspire.md
deleted file mode 100644
index 711f4e1..0000000
--- a/docs/docs/howto/howto_inspire.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-title: HOWTO INSPIRE & pygeoapi
----
-
-# HOWTO INSPIRE & pygeoapi
-
-This HOWTO describes how to set up an INSPIRE service in pygeoapi for a Dutch INSPIRE dataset, [Beschermde Gebieden - Cultuur Historie](https://www.nationaalgeoregister.nl/geonetwork/srv/dut/catalog.search#/metadata/493ab81b-75f8-4205-b030-6b2fd9eb4295), which is exposed via a [Atom download service](https://www.nationaalgeoregister.nl/geonetwork/srv/dut/catalog.search#/metadata/0080a9ce-b836-45bc-8fdf-07dcbe97101d).
-
-pygeoapi is configured using a config file. In this config file you have to add configuration for the inspire dataset. Note that one service provides access to a single dataset (having one or more feature types).
-
-Before starting verify if:
-
-- Data is in a single language or multilingual
-- Data is harmonised or as-is
-
-
diff --git a/docs/docs/howto/howto_ldproxy.md b/docs/docs/howto/howto_ldproxy.md
deleted file mode 100644
index f710ff4..0000000
--- a/docs/docs/howto/howto_ldproxy.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: HOWTO LDProxy
----
-
-# HOWTO ldproxy
-
-LDProxy currently supports 2 backends, postgres and WFS.
-
-Before adding a layer, upload some data to the PostGreSQL database as described in the [HOWTO Database](./howto_database)
-
-Then open the [LDProxy Manager](/ldproxy/manager) and login as admin/*****.
-
-Create a new service
-
-Read more at
-
-
-
diff --git a/docs/docs/howto/howto_passwords.md b/docs/docs/howto/howto_passwords.md
deleted file mode 100644
index a32585c..0000000
--- a/docs/docs/howto/howto_passwords.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-title: HOWTO passwords
----
-
-# HOWTO passwords
-
-Current setup does not have a single sign-on solution. All services have a dedicated password.
-All passwords are stored encrypted on Ansible Vault and injected into containers during deployment.
-
-## HOWTO extract passwords
-
-You can decrypt the passwords from the Ansible Vault using the master password, which is circulated separately.
-You need Python and pip to decrypt:
-
-```
-pip install Ansible
-
-ansible-vault decrypt git/ansible/vars/vars.yml
-```
-
-**BE SURE TO NEVER CHECK-IN DECRYPTED FILES IN GITHUB!!**
-
-Always be sure to encrypt after:
-
-```
-ansible-vault encrypt git/ansible/vars/vars.yml
-```
-
-## HOWTO add or change a password
-
-TODO
-
-## HOWTO reference a ansible password from YAML
-
-TODO
diff --git a/docs/docs/howto/howto_platform.md b/docs/docs/howto/howto_platform.md
deleted file mode 100644
index df73442..0000000
--- a/docs/docs/howto/howto_platform.md
+++ /dev/null
@@ -1,312 +0,0 @@
----
-title: HOWTO Platform
----
-
-# HOWTO Platform
-
-Describes how to setup your own instance of the OGC API Testbed platform.
-As a real-world example, the OGC API Sandbox (Playground) instance is presented below step-by-step.
-
-See also another example: a [pygeoapi server developed by the EU JRC](https://jrc.map5.nl).
-
-## 1. Ubuntu Server
-
-Info:
-
-* setup or acquire a Linux Ubuntu server, minimal Ubuntu 20.4 LTS
-* can be a VM/VPS or bare metal server, even a local VirtualBox (with Vagrant) instance
-* Sandbox specs: 4CPU, 16RAM, 100GB but also strongly depends on the services one needs to run
-* root access via SSH required
-* DNS: create A-record `apisandbox.geonovum.nl` for IP address `109.237.219.249`
-* OPTIONAL: DNS: if you need docs (not for Sandbox) create CNAME and set in `git/docs/docs/CNAME`
-* copy your SSH public key to `/root/.ssh/authorized_keys`, e.g. `scp ~/.ssh/id_rsa.pub root@apisandbox.geonovum.nl:.ssh/authorized_keys`
-* test login with SSH key: `ssh root@apisandbox.geonovum.nl`
-* upgrade server to latest: `apt-get update && apt-get -y upgrade`
-
-## 2. Generate GitHub Repo
-
-Create a GitHub repository from the Template repo [github.com/Geonovum/ogc-api-sandbox](https://github.com/Geonovum/ogc-api-sandbox).
-
-Creating a repository from a template is similar to forking a repository, but there are important differences:
-
-* A new fork includes the entire commit history of the parent repository, while a repository created from a template starts with a single commit.
-* Commits to a fork don't appear in your contributions graph, while commits to a repository created from a template do appear in your contribution graph.
-* A fork can be a temporary way to contribute code to an existing project, while creating a repository from a template starts a new project quickly.
-
-Steps (see also [here](https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/creating-a-repository-on-github/creating-a-repository-from-a-template):
-
-* login on GitHub
-* go to [github.com/Geonovum/ogc-api-testbed](https://github.com/Geonovum/ogc-api-testbed)
-* above file list press green button "Use this template"
-* follow the steps indicated, if you want to serve docs on a separate domain indicate "Include all branches"
-
-## 3. Prepare Local System
-
-On your local system:
-
-### Install Ansible:
-
-* have Python 3 (3.7 or better) installed
-* OPTIONAL (but recommended) create a Python Virtualenv (for Ansible)
-* install [Ansible](https://www.ansible.com/) with `pip install ansible` 2.9.* or higher
-* test: `ansible --version` - shows *ansible 2.9.19 ...*
-* test: `ansible-vault --version` shows *ansible-vault 2.9.19 ...*
-
-More on Ansible below.
-
-### Install `Git` client.
-
-## 4. Clone New GitHub Repo
-
-* `git clone https://github.com/Geonovum/ogc-api-sandbox.git`
-
-We will call the root dir of the cloned git repo on your system just `git/` from here.
-
-## 5. Setup Ansible
-
-Most of the configuration that is specific to your new server
-is stored under `git/ansible/hosts` (Ansible inventories)
-and `git/ansible/vars` (variables and SSH keys).
-
-Most files are encrypted with `Ansible Vault`. You will need to
-create your own (encrypted) version of these encrypted files.
-For many files an example file is given.
-
-### Ansible Modules
-
-Called "Roles" these are third-party Ansible components that help with specific tasks.
-Install these as follows:
-
-```
-cd git/ansible
-ansible-galaxy install --roles-path ./roles -r requirements.yml
-```
-
-### Ansible Hosts
-The hostname is crucial to services functioning. Two steps:
-
-* set content of `git/ansible/hosts/prod.yml` (Inventory) to
-
-```
-ogcapi:
- hosts:
- apisandbox:
- ansible_port: 22
- ansible_host: apisandbox.geonovum.nl
- ansible_user: root
-
-```
-
-* set content of `git/services/env.sh` to:
-
-```
-#!/bin/bash
-# Sets global env vars based on host-name
-# Needed for various host-dependent configs, especiallly Traefik SSL-certs.
-
-# Export and Defaults
-
-# Assume a local deployment
-export DEPLOY_ENV="local"
-export TRAEFIK_SSL_ENDPOINT=
-export TRAEFIK_SSL_DOMAIN="apisandbox.geonovum.nl"
-export TRAEFIK_SSL_CERT_RESOLVER=
-export TRAEFIK_USE_TLS="false"
-export HOST_UID=$(id -u)
-export HOST_GID=$(id -g)
-export HOST_UID_GID="${HOST_UID}:${HOST_GID}"
-
-# Set host-dependent vars
-case "${HOSTNAME}" in
- "apisandbox.geonovum.nl")
- DEPLOY_ENV="prod"
- ;;
- "apisandbox")
- DEPLOY_ENV="prod"
- ;;
- *)
- echo "Default Local Host ${HOSTNAME}"
-esac
-
-if [[ ${DEPLOY_ENV} = "prod" ]]
-then
- source /etc/environment
- TRAEFIK_SSL_ENDPOINT="https"
- TRAEFIK_SSL_CERT_RESOLVER="le"
- TRAEFIK_USE_TLS="true"
-fi
-
-```
-
-So `DEPLOY_ENV=prod` here is to discern with a deployment on `localhost` (`DEPLOY_ENV=local`, where .e.g. no https/SSL is used).
-
-### Create SSH Keys
-
-These are used to invoke actions on the server both from GitHub Actions (via GitHub Sercrets)
-and from your local Ansible setup. Plus a set of authorized_keys for the admin SSH user.
-
-* cd `git/ansible/vars`
-* create new SSH keypair (no password): `ssh-keygen -t rsa -q -N "" -f gh-key.rsa`
-
-### Create authorized_keys
-
-Create new `git/ansible/vars/authorized_keys` with your public key and for others you want to give access to the admin SSH account,
-plus `gh-key.rsa.pub` .
-
-```
-cat gh-key.rsa.pub > authorized_keys
-cat ~/.ssh/id.rsa.pub >> authorized_keys
-cat id.rsa.pub.of.joe >> authorized_keys # etc
-
-```
-
-### Adapt vars.yml
-
-Create new `git/ansible/vars/vars.yml` from example `vars.example.yml` in that dir.
-
-The first part of `vars.yml` contains generix, less-secret, values.
-Use variables where possible. Format is Python-Jinja2 template-like:
-
-
-```
-my_ssh_pubkey_file: ~/.ssh/id_rsa.pub
-my_email: my@email.nl
-my_admin_user: the_admin_username
-my_admin_home: "/home/{{ my_admin_user }}"
-my_git_home: "{{ my_admin_home }}/git"
-my_github_repo: https://github.com/Geonovum/ogc-api-sandbox.git
-var_dir: /var/ogcapi
-logs_dir: "{{ var_dir }}/log"
-services_home: "{{ my_git_home }}/services"
-platform_home: "{{ my_git_home }}/platform"
-pip_install_packages:
- - name: docker
-timezone: Europe/Amsterdam
-ufw_open_ports: ['22', '80', '443', '5432']
-```
-
-The second part deals with more secret values, like usernames and passwords for services.
-For most services indicated below with comment after `#`. `GHC_` denotes GeoHealthCheck (GHC) vars.
-If you don't use GHC you can skip those.
-
-
-```
-etc_environment:
- PG_DB: the_db # PostGIS service
- PG_USER: the_user # PostGIS service
- PG_PASSWORD: the_pw # PostGIS service
- PGADMIN_EMAIL: the_user@the_user.nl # PGadmin service
- PGADMIN_PASSWORD: the_pw # PGadmin service
- GHC_SQLALCHEMY_DATABASE_URI: postgresql://the_user:the_pw@the_db:5432/the_db # PGadmin service
- GHC_ADMIN_USER_NAME: the_user
- GHC_ADMIN_USER_PASSWORD: the_pw
- GHC_ADMIN_USER_EMAIL: the_user@the_user.nl
- GHC_NOTIFICATIONS_EMAIL: the_user@the_user.com
- GHC_SMTP_EMAIL: the_user@the_user.com
- GHC_SMTP_SERVER: smtp.gmail.com
- GHC_SMTP_PORT: 587
- GHC_SMTP_TLS: True
- GHC_SMTP_SSL: False
- GHC_SMTP_USERNAME: the_user@the_user.com
- GHC_SMTP_PASSWORD: the_pw
-
-```
-
-### Create Ansible Vault Password
-
-* global replace `~/.ssh/ansible-vault/ogc-api-testbed.txt` with `~/.ssh/ansible-vault/ogc-api-sandbox.txt` in `git/ansible/README.md`
-* create strong password
-* store in `~/.ssh/ansible-vault/ogc-api-sandbox.txt` for convenience
-
-### Set GitHub Secrets
-
-Three secrets need to be set:
-
-Go to GH repo Settings|Secrets and create these three secrets
-
-* ANSIBLE_INVENTORY_PROD - with value from `git/ansible/hosts/prod.yml`
-* ANSIBLE_SSH_PRIVATE_KEY - with value from `git/ansible/vars/gh-key.rsa`
-* ANSIBLE_VAULT_PASSWORD - value from `~/.ssh/ansible-vault/ogc-api-sandbox.txt`
-
-
-### Encrypt Ansible Files
-
-VERY IMPORTANT. UNENCRYPTED FILES SHOULD NEVER BE CHECKED IN!!!
-
-Using `ansible-vault` with password encrypt these:
-
-```
-ansible-vault encrypt --vault-password-file ~/.ssh/ansible-vault/ogc-api-sandbox.txt vars.yml
-ansible-vault encrypt --vault-password-file ~/.ssh/ansible-vault/ogc-api-sandbox.txt gh-key.rsa
-ansible-vault encrypt --vault-password-file ~/.ssh/ansible-vault/ogc-api-sandbox.txt gh-key.rsa.pub
-ansible-vault encrypt --vault-password-file ~/.ssh/ansible-vault/ogc-api-sandbox.txt authorized_keys
-
-```
-
-### Globally Replace apitestbed.geonovum.nl
-
-Under `git/services` replace all occurrences of `apitestbed.geonovum.nl` with `apisandbox.geonovum.nl`
-
-### Disable GitHub Workflows
-
-We do not want that workflows take effect immediately.
-So disable them temporary by renaming the dir.
-
-```
-git mv workflows workflows.not
-git add .
-git commit -m "disable workflows"
-git push
-
-```
-
-## 6 Prune Repo Tree for Unneeded Services
-
-At this step you may want to delete services you don't need:
-
-* `rm -rf git/docs` . Documentation is already maintained and available via [https://apitestdocs.geonovum.nl/](https://apitestdocs.geonovum.nl/)
-* for each service you want to delete, delete these 3 resources, e.g. for service `xyz`
- * `rm -rf git/services/xyz`
- * `rm git/.github/workflows/deploy.xyz.yml`
- * in `git/ansible/deploy.yml` delete the three Ansible `task` lines with `xyz` name and tag.
-
-## 7 Bootstrap/provision Server
-
-Moment of truth! Bootstrap (provision the server) in single playbook.
-
-* `ansible-playbook -v --vault-password-file ~/.ssh/ansible-vault/ogc-api-sandbox.txt bootstrap.yml -i hosts/prod.yml`
-
-If all goes well, this output should be shown at end:
-
-```
-PLAY RECAP ***********************************************************************************************************
-apisandbox : ok=58 changed=22 unreachable=0 failed=0 skipped=8 rescued=0 ignored=0
-
-```
-
-Observe output for errors (better is to save output in file via `.. > bootstrap.log 2>&1`).
-
-In cases of errors and after fixes, simply rerun the above Playbook.
-
-Site should be running at: [https://apisandbox.geonovum.nl](https://apisandbox.geonovum.nl)
-Check with portainer [https://apisandbox.geonovum.nl/portainer/](https://apisandbox.geonovum.nl/portainer/).
-
-## 8 Resolve Issues
-
-These are typical issues found and resolved:
-
-* `/home/oadmin/git` is owned by root, change to `oadmin`
-* delete (or change) CNAME `git/docs/docs`
-* permissions in services/qgis/data , make datadir writeable for all: `chmod 777 services/qgis/data`
-
-## 9. Enable GitHub Workflows
-
-Enable by renaming:
-
-```
-git mv workflows.not workflows
-git add .
-git commit -m "enable workflows"
-git push
-
-```
diff --git a/docs/docs/howto/howto_portainer.md b/docs/docs/howto/howto_portainer.md
deleted file mode 100644
index 71e5ae1..0000000
--- a/docs/docs/howto/howto_portainer.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: HOWTO Portainer
----
-
-# HOWTO Portainer
-
-[Portainer](https://www.portainer.io/) is a webbased tool which allows to manage running docker containers. You can view logs of a container, evaluate hardware usage, restart it or even ssh into it.
-
-Portainer is available at https://apitestbed.geonovum.nl/portainer. Credentials of portainer are circulated as part of the infrastructure credentials.
-
-
diff --git a/docs/docs/howto/howto_pycsw.md b/docs/docs/howto/howto_pycsw.md
deleted file mode 100644
index 69456fb..0000000
--- a/docs/docs/howto/howto_pycsw.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: HOWTO pycsw
----
-
-
-# HOWTO pycsw
-
-pycsw operates on a postgres or [sqlite](https://github.com/Geonovum/ogc-api-testbed/blob/main/services/pycsw/data/cite.db) backend.
-The database is configured in a [configuration file](https://github.com/Geonovum/ogc-api-testbed/blob/main/services/pycsw/pycsw.cfg), together with other common settings.
-
-## Loading data
-
-pycsw has a [tool to load data](https://docs.pycsw.org/en/latest/administration.html#loading-records) from a folder of files.
-Alternatively CSW transactions (from for example GeoCat Bridge) can be used to insert data. But transactions need to be explicitely activated and require an authentication mechanism.
\ No newline at end of file
diff --git a/docs/docs/howto/howto_pygeoapi.md b/docs/docs/howto/howto_pygeoapi.md
deleted file mode 100644
index 77fce59..0000000
--- a/docs/docs/howto/howto_pygeoapi.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
-title: HOWTO pygeoapi
----
-
-
-# HOWTO pygeoapi
-
-The pygeoapi config is the place to start when configuring a new service. The file starts with some general server configuration and then presents a list of collections. Each collection has a data store configuration referencing one of the available data backends. A common data provider is the OGR/GDAL provider which gives access to a multitude of file formats.
-
-In a minimal approach you can update the [current config file](https://github.com/Geonovum/ogc-api-testbed/blob/main/services/pygeoapi/local.config.yml) and add a new layer to it.
-
-Alternatively you can create a new instance by duplicating the [main pygeoapi service folder](https://github.com/Geonovum/ogc-api-testbed/blob/main/services/pygeoapi) under a new name and update [the main ansible orchestration](https://github.com/Geonovum/ogc-api-testbed/blob/main/ansible/deploy.yml) to add the new service. Also you have to create a new file in https://github.com/Geonovum/ogc-api-testbed/tree/main/.github/workflows, having the new name. This tells github to (re)deploy the service when changes are detected. Note that INSPIRE mandates that each dataset is exposed via a unique service endpoint and pygeoapi can only provide a single service endpoint. Duplicating the deployment is then a usual approach.
-
-## Example of a pygeoapi collection
-
-```YAML
-lakes: # name of the collection, e.g. /collection/lakes/items
- type: collection
- title: # title, keywords and description support multilingual
- en: Large Lakes
- nl: Grote meren
- description: lakes of the world, public domain
- keywords:
- - lakes
- crs: # CRS-es supported by backend
- - CRS84
- links: # list of links to more info, for example metadata
- - type: text/html
- rel: canonical
- title: information
- href: http://www.naturalearthdata.com/
- hreflang: en-US
- extents: # spatial and temporal extent of the layer
- spatial:
- bbox: [-180,-90,180,90]
- crs: http://www.opengis.net/def/crs/OGC/1.3/CRS84
- temporal:
- begin: 2011-11-11
- end: null # or empty
- providers: # list of backends
- - type: feature # service type (e.g. features, maps, styles, records, coverages)
- name: GeoJSON # type of provider (see docs for available types)
- data: tests/data/ne_110m_lakes.geojson # link to a file (or other provider specific configuration)
- id_field: id # field which contains the identifier
- title_field: name # field which contains the title of the element (can be multilingual)
-```
diff --git a/docs/docs/howto/howto_qgis.md b/docs/docs/howto/howto_qgis.md
deleted file mode 100644
index 7e1522d..0000000
--- a/docs/docs/howto/howto_qgis.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-title: HOWTO QGIS server
----
-
-# HOWTO QGIS server
-
-QGIS server is configured through QGIS Desktop. The project file generated with QGIS is then uploaded to the server (along with any data to serve).
-
-- Start a new project in QGIS, or update an existing.
-- Add the relevant layers to the project. For file based data, place the files in (or under) the folder where the project is stored, else QGIS may generate unresolvable paths in the project file.
-- If you want to use a database layer, upload any data to the remote PostGreSQL. Connect your local QGIS to the remote database and add the PostGreSQL tables as layers to the project.
-- Go to Project Properties, open the QGIS Server tab, fill in relevant fields. Make sure to check the "publish" checkbox in the WFS section, else no collections will be available.
-- Save the project as .qgs file (not .qgz) and push it to Github with all related files.
-- The project should be called project.qgs. Alternatively you can set an environment variable
-
-```
-QGIS_PROJECT_FILE:/etc/qgisserver/my-new-project.qgs
-```
-
-- Test your service via [https://apitestbed.geonovum.nl/qgis/wfs3](https://apitestbed.geonovum.nl/qgis/wfs3)
diff --git a/docs/docs/howto/howto_skinning.md b/docs/docs/howto/howto_skinning.md
deleted file mode 100644
index 371ea2d..0000000
--- a/docs/docs/howto/howto_skinning.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: HOWTO adjust the looks of OGC API Features
----
-
-# HOWTO adjust the looks of OGC API Features
-
-Tutorials on how to change the look and feel of OGC API features.
-
-## GeoServer
-
-This toturial updates the main headr and footer of GeoServer OGC API Features, [other templates](https://docs.geoserver.org/latest/en/user/community/ogc-api/features/index.html#service-configuration) can be overridden in a similar way.
-
-- In the data directory which is mounted into geoserver add files [templates/ogc/features/common-header.ftl](https://github.com/Geonovum/ogc-api-testbed/blob/main/services/geoserver/data/templates/ogc/features/common-header.ftl) and [templates/ogc/features/common-footer.ftl](https://github.com/Geonovum/ogc-api-testbed/blob/main/services/geoserver/data/templates/ogc/features/common-footer.ftl)
-- Adjust the files to your needs and push the changes to github
-- Tip, you can preview your changes without updating the platform by adjusting the html and css directly in the web page with the browser developer panel (F12)
-
-
-
diff --git a/docs/docs/howto/howto_system.md b/docs/docs/howto/howto_system.md
deleted file mode 100644
index 4e61148..0000000
--- a/docs/docs/howto/howto_system.md
+++ /dev/null
@@ -1,59 +0,0 @@
----
-title: HOWTO System Maintenance
----
-
-# HOWTO System Maintenance
-
-Once a platform instance, as in [HOWTO Platform](howto_platform.md), has
-been installed the host system needs to be maintained. In our case the (remote) host
-system runs Ubuntu. A Debian/Ubuntu system is composed of software "Packages". These can
-become outdated and need to be updated. Also packages may contain security fixes.
-In some cases all the Docker Containers may need a restart (Service Management).
-
-Below is described how the above is organized and how these tasks are enabled
-for a maintainer.
-**NB all this applies to the host/VM system-OS, not the OS-es that run within the Docker Containers!!*
-
-`~/.ssh/ansible-vault/ogc-api-sandbox.txt` is the file containing your Ansible Vault password.
-
-## Security Updates
-
-Automatic updates of (Ubuntu) security fixes/patches is already done automatically.
-During the [Ansible Bootstrap](https://github.com/Geonovum/ogc-api-testbed/blob/main/ansible/bootstrap.yml) phase,
-the Ansible Module [justb4.ubuntu-base](https://github.com/justb4/ansible-ubuntu-base) will enable
-automatic security updates.
-
-Details: the specific Ansible Task [can be found here](https://github.com/justb4/ansible-ubuntu-base/blob/master/tasks/main.yml#L41).
-
-## Service Management
-
-All Docker containers can be started/stopped by a Ubuntu `systemd` service called `ogcapi`.
-
-The following Ansible tasks are available:
-
-```
-ansible-playbook -v --vault-password-file ~/.ssh/ansible-vault/ogc-api-sandbox.txt service.yml -i hosts/prod.yml --tags status
-
-ansible-playbook -v --vault-password-file ~/.ssh/ansible-vault/ogc-api-sandbox.txt service.yml -i hosts/prod.yml --tags stop
-
-ansible-playbook -v --vault-password-file ~/.ssh/ansible-vault/ogc-api-sandbox.txt service.yml -i hosts/prod.yml --tags start
-
-```
-
-
-## System Management
-
-The Ubuntu "APT" packages can be maintained remotely with Ansible. The host system can even be rebooted remotely.
-The systemd service `ogcapi` (see Service Management) and thus all Docker Containers will be started
-automatically.
-
-The following Ansible tasks are available:
-
-```
-# Update outdated Packages
-ansible-playbook -v --vault-password-file ~/.ssh/ansible-vault/ogc-api-sandbox.txt system.yml -i hosts/prod.yml --tags update_packages
-
-# Reboot - all services should come back up
-ansible-playbook -v --vault-password-file ~/.ssh/ansible-vault/ogc-api-sandbox.txt system.yml -i hosts/prod.yml --tags reboot
-
-```
diff --git a/docs/docs/howto/index.md b/docs/docs/howto/index.md
deleted file mode 100644
index 8268fb1..0000000
--- a/docs/docs/howto/index.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: HOWTOs
----
-
-# HOWTOs
-
-The following sections of HOWTOs exist.
-
-## HOWTO Platform
-
-The Platform section describes how to deploy and maintain
-your own instance of the OGC API Testbed platform.
-
-* [HOWTO Platform](howto_platform.md) - setting up a new platform
-* [HOWTO System Maintenance](howto_system.md) - maintaining the host system
-* [HOWTO Error Analysis](howto_errors.md)
-
-## HOWTO Services
-
-The deployment section describes how to deploy services, like OAFeat instances.
-
-* [HOWTO Deploy](howto_deploy.md) - create or update a service
-* [HOWTO Deploy pygeoapi](howto_pygeoapi.md)
-* [HOWTO Deploy GeoServer](howto_geoserver.md)
-* [HOWTO Deploy LDProxy](howto_ldproxy.md)
-* [HOWTO Deploy pycsw](howto_pycsw.md)
-* [HOWTO Deploy qgis](howto_qgis.md)
-* [HOWTO Deploy GOAF](howto_goaf.md)
-
-## HOWTO Cases
-
-The cases section describes how to manage certain use cases.
-
-* [HOWTO INSPIRE in pygeoapi](howto_inspire.md)
-* [HOWTO API Strategie](howto_api_strategie.md)
-
-## HOWTO Admin
-
-The admin section describes various supporting tools for administration
-and monitoring.
-
-* [HOWTO GeoHealthCheck](howto_ghc.md) - monitoring OGC web-services
-* [HOWTO Database](howto_database.md)
-* [HOWTO Portainer](howto_portainer.md) - monitoring Docker Containers
diff --git a/docs/docs/images/schema.png b/docs/docs/images/schema.png
deleted file mode 100644
index ca42d83..0000000
Binary files a/docs/docs/images/schema.png and /dev/null differ
diff --git a/docs/docs/images/services-stack.png b/docs/docs/images/services-stack.png
deleted file mode 100644
index 9861403..0000000
Binary files a/docs/docs/images/services-stack.png and /dev/null differ
diff --git a/docs/docs/index.md b/docs/docs/index.md
deleted file mode 100644
index f5998b4..0000000
--- a/docs/docs/index.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: OGC-API-Testbed Documentation
----
-
-# OGC-API-Testbed Documentation
-
-This documents the [Geonovum](https://geonovum.nl) OGC API Testbed Platform. Focus is on
-the Platform's design/setup, how it is provisioned (bootstrapped) and its continuous deployment/integration (CI/CD).
-
-Initially, the main goal of the Platform is to experiment with, and evaluate
-various implementations of the [OGC API Features (OAFeat) Standard](https://ogcapi.ogc.org/features/). Given the generic nature
-of the Platform's web-services deployment architecture, additional services and OGC APIs may be added.
-The stable version of the Platform is provided as an [Open Source GitHub Template](https://github.com/Geonovum/ogc-api-testbed), allowing any party to
-derive and customize their own.
-
-Find a quick intro in the project [README](https://github.com/Geonovum/ogc-api-testbed#readme).
-
-The documentation is split up as follows:
-
-* [Setup](setup/index.md) describes the platform architecture and setup (admin manual)
-* [HOWTO](howto/index.md) has a number of tutorials on how to operate the system (user manual)
-* [Findings](findings/index.md) design choices, identified challenges and solutions
-* [Cases](cases/index.md) contains some experiments performed on the platform, and may be extended to capture future outcomes of the testbed
-
-## Get in Touch
-
-[](https://gitter.im/Geonovum/ogc-api-testbed)
-
-## Services
-
-To access and interact with the (OGC web-) services, go to
-one of the two server instances:
-
-* Stable (production) server at [apitestbed.geonovum.nl](https://apitestbed.geonovum.nl/)
-* Sandbox (experimental) server at [apisandbox.geonovum.nl](https://apisandbox.geonovum.nl/)
-
-## Links
-
-* [Project GitHub Repo](https://github.com/Geonovum/ogc-api-testbed)
-* [Geonovum](https://geonovum.nl) - Geonovum home
-* [pygeoapi](https://pygeoapi.io) - `pygeoapi` project home
-* [ldproxy](https://github.com/interactive-instruments/ldproxy) - `ldproxy` project home
-* [GeoServer](https://geoserver.org) - `GeoServer` home
-* [OGC API Features](https://ogcapi.ogc.org/features/) - OGC Home OAFeat
diff --git a/docs/docs/setup/geoserver.md b/docs/docs/setup/geoserver.md
deleted file mode 100644
index b736faa..0000000
--- a/docs/docs/setup/geoserver.md
+++ /dev/null
@@ -1,54 +0,0 @@
----
-title: Setup GeoServer
----
-
-# Setup GeoServer
-
-A docker hub image is provided by [oscarfonts](https://github.com/oscarfonts/docker-geoserver) is extended with OGC API plugin. The binaries of the plugin, as well as the data folder are mounted into the container. The `Oscar Fonts` image runs as a tomcat user, which by itself is a good practice from security prespective, but files are created on the data folder by a user unknown to the docker host, which causes problems at redeployment. We have overridden this behaviour and run as root user.
-
-The data folder is created by deploying geoserver locally, setting up the required services and commit the changes to github. You can either embed a data file inside the data folder, alternatively you can upload data to the PostGreSQL database and configure a layer on data from the database.
-
-The OGC API is available from the geoserver homepage at /ogc/features, or on the workspace endpoint /{workspace}/agc/features.
-
-## OGC API Community module
-
-The GeoServer community has been involved in the OGC sprints while the standards were shaped to its current form. The implementation of OGC API currently has the form of a [community plugin](https://docs.geoserver.org/latest/en/user/community/ogc-api/index.html), which can be installed on recent versions of GeoServer.
-
-## Scripted configuration vs dynamic configuration
-
-GeoServer has an extended web user interface as well as a rest api to configure the publication of datasets. These configurations are persisted as xml files in the config folder. Alternatively you can use a scripted approach to configure the server, the xml files in the conig folder are deployed as part of the deployment. Both approaches can however not easily be combined. It means you have to decide for a server if you set it up scripted or dynamically. The scripted approach is mostly used in advanced setups such as App Schema INSPIRE.
-
-Most challenging is a sequential update number which is updated with every dynamic update of the configuration via the api.
-
-The configuration with xml files is also a challenge when scaling out and load balancing GeoServer. When these files are updated by one instance, the other instances need to be synchronised. Some community plugins are available, such as jdbc-config, which enables the storage of configuration in a central database.
-
-## GeoServer behind a gateway (traefik)
-
-Running GeoServer behind a gateway, which exposes geoserver at an alternative domain, requires a proxy url to be configured on GeoServer. You need to manage this in an xml file, because the admin interface (which offers an option to configure this also) doesn't work correctly if the proxy url is not correctly set up.
-
-Recent versions of GeoServer have added a CSRF protection against script attacks. This CSRF leads to unexpected results when running GeoServer via a gateway. The gateway domain needs to be whitelisted or CSRF vealidation deactivated. Read more at https://docs.geoserver.org/stable/en/user/security/webadmin/csrf.html
-
-## GeoServer and docker
-
-The installation of GeoServer requires to add the OGC API plugin (check a matching version number). It is quite common that GeoServer is extended with plugins. We used the docker image provided by [oscarfonts](https://github.com/oscarfonts/docker-geoserver), which has a nice mechanism to place plugins (and data folder) on a mounted volume.
-
-In order to configure a new resource on GeoServer we added the required configuration files to the geonovum github repository. GeoServer also has a web interface and rest api to configure resources, but note that any resource added manually may be overwritten from github with the new deployment of the software.
-
-An alternative for manual setup us the [GeoCat bridge](https://geocat.net/bridge) tool, which is a typical tool to configure new resources on GeoServer from within the QGIS or ArcMAP Desktop application.
-
-## Template overrides
-
-We experimented with [template overrides](https://docs.geoserver.org/latest/en/user/community/ogc-api/features/index.html#service-configuration) to add the geonovum corporate identity to the OGC API endpoints. We found some interesting behaviour, which we reported to the GeoServer community. To override common-header.ftl for /collections, you need to add the override in /data/templates/ogc/features. To override it for /items you need to place it in data/workspaces.
-
-## GeoPackage support
-
-GeoPackage is often mentioned as a replacement for (appschema) GML to share larger datasets efficiently. GeoServer has support for GeoPackage as output format after installing a dedicated community plugin. The plugin also requires the wps plugin to be installed. Both plugins are installed and verified that these can be used as export format for OGC API Features.
-
-## Issues
-Some issues found during deployment
-
-* [Issue #22](https://github.com/Geonovum/ogc-api-testbed/issues/22) - Permission Issue for mounted dirs: the GeoServer Container permanently changes the ownership of mounted dirs
-* [Issue #21](https://github.com/Geonovum/ogc-api-testbed/issues/21) - OGC API Plugin: running on subpath with https does not render linked resources correctly
-* [GEOS-10125](https://osgeo-org.atlassian.net/browse/GEOS-10125) - GeoServer currently does not add the (meta)data linksto the links section in /collections endpoint
-* [GEOS-10126](https://osgeo-org.atlassian.net/browse/GEOS-10126) - GeoServer uses deprecated mediatype application/x-gpkg.
-
diff --git a/docs/docs/setup/ghc.md b/docs/docs/setup/ghc.md
deleted file mode 100644
index 5958d05..0000000
--- a/docs/docs/setup/ghc.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-title: GeoHealthCheck
----
-
-[GeoHealthCheck](https://geohealthcheck.org/) (GHC) is an
-availability and Quality-of-Service (QoS) monitoring solution
-dedicated to OGC (web-) services. GHC supports both the
-standard protocols like WMS, WFS, WMTS, CSW etc, APIs in general and
-the recent OAFeat OGC standard. To learn more, best is to
-follow a [GHC presentation as HTML slides or video](https://geohealthcheck.org/).
-
-## OAFeat Support
-GHC supports the
-OGC OAFeat standard with two basic checks (called "Probes"):
-
-- OAFeat endpoint traversal, check if all required resources/links are available
-- full OAS schema validation
-
-## Deployment
-
-GHC is part of the
-[Admin Stack](https://github.com/Geonovum/ogc-api-testbed/tree/main/services/admin) in the testbed.
-
-GeoHealthCheck has Docker Images available at
-[DockerHub](https://hub.docker.com/r/geopython/geohealthcheck)
-and uses a standard PostgreSQL/PostGIS database for persistence.
-
-GHC runs with three Docker containers:
-
-* GHC Web Application (`ghc_web`)
-* GHC Runner (runs the actual checks) (`ghc_runner`)
-* GHC Postgres database stores check config and results (`ghc_db`)
-
-## Configuration
-
-GHC needs quite some variables (around 31, though many defaults apply).
-These are all configured once in
-[ghc.env](https://github.com/Geonovum/ogc-api-testbed/blob/main/services/admin/ghc.env).
-Many variables represent credentials like email and
-database configuration. These are bundled as `etc_environment`
-in and forwarded from the encrypted Ansible file `vars.yml`.
-
-```
- - name: "admin"
- shell: "cd {{ services_home }}/admin && ./deploy.sh && docker ps"
- tags: admin
-
-```
-
-## Links
-* [docker-compose.yml](https://github.com/Geonovum/ogc-api-testbed/blob/main/services/admin/docker-compose.yml) - the Docker Compose file
diff --git a/docs/docs/setup/goaf.md b/docs/docs/setup/goaf.md
deleted file mode 100644
index de61087..0000000
--- a/docs/docs/setup/goaf.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: Setup GOAF
----
-
-# Setup GOAF
-
-[GOAF](https://github.com/PDOK/goaf) is a OAF implementaion in Go, maintained by PDOK, originally developed as [Jivan](https://github.com/go-spatial/jivan).
-
-GOAF image used from https://hub.docker.com/r/pdok/wfs-3.0, this is an older version, but PDOK has not updated yet. Alternative could be to build the image from sources.
-
-GOAF supports a PostGres or GeoPackage backend. Which file to serve the type of file are injected as environment variables.
-
-We have added the default BRT image provided by PDOK as example.
-
diff --git a/docs/docs/setup/index.md b/docs/docs/setup/index.md
deleted file mode 100644
index 40869db..0000000
--- a/docs/docs/setup/index.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-title: Setup
----
-
-# Setup
-
-This section describes the setup/installation details of the platform.
-
-## Platform setup
-
-This section introduces the setup of the platform and
-components used in the platform infrastructure.
-
-* [Platform setup](platform.md)
-
-## Operational Services
-
-A number of services is deployed on the platform:
-
-* [pygeoapi](pygeoapi.md)
-* [pycsw](pycsw.md)
-* [GeoServer](geoserver.md)
-* [ldproxy](ldproxy.md)
-* [QGIS Server](qgis.md)
-* [GOAF](goaf.md)
-* [postgis / pgadmin](postgis.md)
-
-## Admin tools
-
-Some admin tools are made available to monitor the platform.
-
-* [portainer](portainer.md)
-* [GeoHealthCheck](ghc.md)
\ No newline at end of file
diff --git a/docs/docs/setup/ldproxy.md b/docs/docs/setup/ldproxy.md
deleted file mode 100644
index a436237..0000000
--- a/docs/docs/setup/ldproxy.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: LDProxy installation experiences
----
-
-# LDProxy installation experiences/hints
-
-ldproxy started out as a prototype in the GeoNovum Geo4Web testbed in 2016.
-Over the years LDProxy has followed the developments around OGC API
-and is currently the most complete implementation of the latest developments in OGC API.
-
-## Installation
-
-A docker hub image is provided by [Interactive Instruments](https://hub.docker.com/r/iide/ldproxy).
-
-We are using the latest image provided by Interactive Instruments,
-which is a bit behind from the latest version on their docker repository,
-but that repository is not available publicly yet. We found (and reported)
-some issues with the latest public release, which should be solved in the main branch.
-
-We are mounting the config folder to a local volume, the configuration in the
-folder is taken from github. The configuration includes a config file in which logging
-to stdout has been set up.
-
-For this moment we only expose a feature service with a RCE WFS as backend.
-We intend to also add a service with a postgres backend.
-
-The data folder is created by deploying ldproxy locally, setting up the required services and commit the changes to github. You can upload data to the PostGreSQL database and configure a layer on data from the database.
-
-The OGC API's are available via /ldproxy/services.
-
-Configure logging to stdout
-
-Challenges when exposing ldprocy on a subpath
-
-## Issues
-
-* running `ldproxy` on a subpath does not provide proper URLs to internal e.g. CSS resources
-* [Issue](https://github.com/interactive-instruments/ldproxy/issues/454) error on accessing collection for RCE WFS
-
-```
-Client error, HTTP status 406, Request path : MessageBodyWriter not found for media type=image/avif,
-type=class java.util.ArrayList, genericType=class java.util.ArrayList.
-
-```
\ No newline at end of file
diff --git a/docs/docs/setup/platform.md b/docs/docs/setup/platform.md
deleted file mode 100644
index f0c12f9..0000000
--- a/docs/docs/setup/platform.md
+++ /dev/null
@@ -1,175 +0,0 @@
----
-title: Platform setup
----
-
-# Platform setup
-
-The project repository contains contains components to bootstrap, configure ("provision") and maintain a remote
-deployment of an OGC API web-service stack using modern "DevOps" tooling.
-
-
-
-See also a [presentation of the platform on OpenGeodag 2021](https://files.justobjects.nl/presentation/opengeodag-2021/opengeodag-2021-just.pdf).
-
-## Design Principles
-
-The main design principles are:
-
-* starting point is an empty VPS/VM with Ubuntu and root (key) access
-* any action on the server/VM host is performed from a client host
-* i.e. no direct access/login to/on the server/VM is required, only for problem solving
-* remote actions can be performed manually or triggered by GitHub Workflows
-* all credentials (passwords, SSH-keys, etc) are secured
-* two operational stack instances 1) production, *"Stable"* and 2) playground, *"Sandbox"*
-
-## Components
-
-The components used to realize this design are:
-
-* [Docker](https://www.docker.com/) *"...OS-level virtualization to deliver software in packages called containers..."* ([Wikipedia](https://en.wikipedia.org/wiki/Docker_(software)))
-* [Docker Compose](https://docs.docker.com/compose) *"...a tool for defining and running multi-container Docker applications..."*
-* [Ansible](https://www.ansible.com/) *"...an open-source software provisioning tool"* ([Wikipedia](https://en.wikipedia.org/wiki/Ansible_(software)))
-* [GitHub Actions/Workflows](https://docs.github.com/en/actions) *"...Automate, customize, and execute software development workflows in a GitHub repository..."*
-* [Traefik](https://traefik.io/) a frontend proxy/load-balancer and SSL (HTTPS) endpoint.
-
-The Docker-components are used to run the operational stack, i.e. the OGC API web-services and supporting services like for monitoring.
-Ansible is used to provision (bootstrap) both the server OS-software
-and the operational stack. Ansible is executed on a local client/desktop system to invoke operations on a remote server/VM.
-These operations are bundled in so-called Ansible Playbooks, YAML files that describe a desired server state.
-GitHub Actions are used to construct Workflows. These Actions will invoke these Ansible Playbooks, effectively configuring
-and provisioning the operational stack on a remote server/VM.
-
-Security is guaranteed by the use of [Ansible-Vault](https://docs.ansible.com/ansible/latest/user_guide/vault.html)
-and [GitHub Encrypted Secrets](https://docs.github.com/en/actions/reference/encrypted-secrets).
-
-Traefik manages the routing of remote requests to relevant containers. Traefik listens to Docker Engine to be aware of available containers. Containers include a dedicated configuration which is picked up by traefik to enable the route.
-
-## Services
-
-A number of services has been deployed within the platform, which can act as a template to add additional services.
-The image below shows the operational service stack with the [Traefik](https://traefik.io/) frontend.
-
-
-
-* [pygeoapi](https://pygeoapi.io/) - a Python server implementation of the OGC API suite of standards.
-* [pycsw](https://pycsw.org/) - a Python server implementation of OGC API Records.
-* [GeoServer](http://geoserver.org/) - a Java server implementation of the OGC API suite of standards.
-* [ldproxy](https://interactive-instruments.github.io/ldproxy/) - a Java server implementation of the OGC API suite of standards.
-* [QGIS Server](https://www.qgis.org/) - server component of QGIS with OGC OAFeat support.
-* [GOAF](https://www.github.com/pdok/goaf) - OAF service developed in Go, maintained by PDOK.
-* [PostgreSQL/PostGIS](https://postgis.net) - geospatial database
-
-For administration, documentation and monitoring the following components are used:
-
-* [mkdocs](https://www.mkdocs.org/) for live documentation and landing pages
-* [PGAdmin](https://www.pgadmin.org/) - visual PostgreSQL manager
-* [GeoHealthCheck](https://geohealthcheck.org) to monitor the availability, compliance and QoS of OGC web services
-* [Portainer](https://www.portainer.io/) visual Docker monitor and manager
-
-## Production and Sandbox Instance
-
-Two separate server/CM-instances are managed to provide stable/production and
-sandbox/playground environments. As to control changes these instances are mapped to two GitHub repositories:
-
-* https://github.com/Geonovum/ogc-api-testbed for the stable/production instance, nicknamed **Stable**
-* https://github.com/Geonovum/ogc-api-sandbox the playground instance, nicknamed **Sandbox**
-
-The **Stable** repo is a so called [GitHub Template repo](https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/creating-a-repository-on-github/creating-a-template-repository)
-from which the **Sandbox** is cloned.
-
-*NB initally [GitHub Protected Branches](https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches) were considered, but*
-*it felt that those would be less transparent and even confusing for selective access and chances of mistakes.*
-
-## Other Instances
-
-When other instances are known they are added here.
-
-### EC JRC
-
-The European Commission Joint Research Centre (EC JRC, Ispra It.) has also used the
-Template GitHub repo to create a server instance with OGC Data APIs:
-see their landing page at [jrc.map5.nl](https://jrc.map5.nl) and the GitHub repo at:
-https://github.com/justb4/ogc-api-jrc .
-
-## Selective Redeploy
-
-When changes are pushed to the repo, only the affected services are redeployed.
-This is effected by a combination of GitHub Actions and Ansible Playbooks as follows:
-
-* each Service has a dedicated GitHub Action "deploy" file, e.g. [deploy.pygeoapi.yml](https://github.com/Geonovum/ogc-api-testbed/tree/main/.github/workflows/deploy.pygeoapi.yml)
-* the GitHub Action "deploy" file contains a trigger for a `push` with a `paths` constraint, in this example:
-
-```
- on:
- push:
- paths:
- - 'services/pygeoapi/**'
-```
-
-* the GH Action then calls the Ansible Playbook [deploy.yml](https://github.com/Geonovum/ogc-api-testbed/tree/main/ansible/deploy.yml) with a `--tags` option related to the Service, e.g. `--tags pygeoapi`
-* the [deploy.yml](https://github.com/Geonovum/ogc-api-testbed/tree/main/ansible/deploy.yml) will always update the GH repo on the server VM via the `pre_tasks`
-* the Ansible task indicated by the `tags` is then executed
-
-## Security
-
-Maintaining a public repository and providing secured access to services can be a challenge.
-Complex solutions exist in the Docker space using Docker Secrets, `/etcd` service etc
-We tried to keep it simpler, using [Ansible Vault](https://docs.ansible.com/ansible/latest/user_guide/vault.html)
-and [GitHub Secrets](https://dev.to/n3wt0n/how-secrets-work-in-github-and-how-to-manage-them-p4o) are the two main
-mechanisms used for bootstrap and deploy.
-
-The [bootstrap.yml](https://github.com/Geonovum/ogc-api-testbed/blob/main/ansible/bootstrap.yml) also applies various Linux hardening components like
-IP-blacklisting on multiple login attempt, key-only logine etc.
-
-## Steps and Workflows
-
-Below is a shortened version how
-to setup and maintain a testbed server instance from zero.
-In a [dedicated HOWTO](/howto/howto_platform/)
-all steps are expanded/described in very great detail.
-
-### Prerequisites
-
-This is what you need to have available first.
-
-#### Access to a server/VM
-This implies acquiring a server/VM instance from a hosting provider.
-Main requirements are that server/VM runs an LTS Ubuntu (20.4 or better) and that SSL-keys are available for root access
-(or an admin user account with sudo-rights).
-
-#### Python 3 and Ansible
-You need a Python 3 installation and install Ansible and `git` (client).
-
-### Clone template repo
-
-Clone from the template repo: https://github.com/Geonovum/ogc-api-testbed.git.
-See [how to do this](https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/creating-a-repository-on-github/creating-a-repository-from-a-template).
-
-### Setup Ansible
-
-Adapt the files under `git/ansible/vars`, following the README there.
-
-Adapt the inventory file under `git/ansible/hosts`, following the README there.
-
-### Bootstrap the server/VM
-"Bootstrap" here implies the complete provisioning of a remote server/VM that runs the operational service stack.
-This is a one-time manual action, but can be executed at any time as Ansible actions are idempotent.
-By its nature, Ansible tasks will only change the system if there is something to do.
-
-Startpoint is a fresh Ubuntu-server or VM with root access via SSH-keys (no passwords).
-The Ansible playbook [bootstrap.yml](https://github.com/Geonovum/ogc-api-testbed/tree/main/ansible/bootstrap.yml) installs the neccessary software, and hardens
-the server security, e.g. using [fail2ban](https://www.fail2ban.org/).
-In this step Docker and Docker Compose are installed and a Linux [systemd](https://en.wikipedia.org/wiki/Systemd) service is run
-that automatically starts/stops the operational stack, also on reboots.
-The software for the operational stack, i.e. from this repo, is cloned on the server as well.
-
-### Maintain the server/VM
-This step is the daily operational maintenance.
-The basic substeps are:
-
-* make a change, e.g. add a data Collection to an OGC API OAFeat service
-* commit/push the change to GitHub
-* watch the triggered GitHub Actions, check for any errors
-* observe changes via website
-
-As indicated, a [dedicated HOWTO](/howto/howto_platform/) describes the above steps in very great detail.
diff --git a/docs/docs/setup/portainer.md b/docs/docs/setup/portainer.md
deleted file mode 100644
index b7a852d..0000000
--- a/docs/docs/setup/portainer.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Setup portainer
----
-
-# Setup portainer
-
-[Portainer](https://portainer.io) is a comprehensive webbased tool to monitor running containers in a Docker environment. It connects to Docker enginge to be notified of changes in running containers and hardware usage. From the user interface you can view logs, restart containers, even ssh into a container.
-
-Portainer is deployed from https://hub.docker.com/r/portainer/portainer. The portainer data folder is mounted from the host.
-
-Portainer is clustered with GeoHealthCheck in a single orchestration.
-
-Portainer is available at [/portainer/](/portainer/). Do not skip the trailing slash.
\ No newline at end of file
diff --git a/docs/docs/setup/postgis.md b/docs/docs/setup/postgis.md
deleted file mode 100644
index 440b780..0000000
--- a/docs/docs/setup/postgis.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: Setup PostGIS
----
-
-# Setup PostGIS
-
-TO BE SUPPLIED.
diff --git a/docs/docs/setup/pycsw.md b/docs/docs/setup/pycsw.md
deleted file mode 100644
index 0ca230e..0000000
--- a/docs/docs/setup/pycsw.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title: pycsw setup
----
-
-# pycsw installation experiences/hints
-
-pycsw is a python implementation of Catalogue Service for the Web as well as OGC API Records.
-
-## Installation
-
-A docker hub image is provided by [geopython](https://hub.docker.com/r/geopython/pycsw). The data folder and the main config file are mounted into the container.
-
-The data folder contains a datafile, alternatively you can upload data to a PostGreSQL database.
-
-The configuration file has main details such as contact information. Check [the documentation](https://docs.pycsw.org) to know which properties are supported.
-
-Installation on the platform has some challenges because we install the software in a subpath. You can mimic running as root via:
-
-- set a stripprefix directive in compose.yml "traefik.http.middlewares.portainer-stripprefix.stripprefix.prefixes=/pycsw"
-- tell pycsw to use /pycsw/py.csw as scriptname
-
-Note that /pycsw throws a 500 error for now, but /pycsw/csw.py works fine
\ No newline at end of file
diff --git a/docs/docs/setup/pygeoapi.md b/docs/docs/setup/pygeoapi.md
deleted file mode 100644
index e8b7601..0000000
--- a/docs/docs/setup/pygeoapi.md
+++ /dev/null
@@ -1,57 +0,0 @@
----
-title: pygeoapi setup
----
-
-# pygeoapi installation experiences/hints
-
-pygeoapi is a python implementation of the OGC API Suite of standards.
-
-## Installation
-
-A docker hub image is provided by [geopython](https://hub.docker.com/r/geopython/pygeoapi).
-The data folder and the main config file are mounted into the container.
-
-The data folder contains the datafiles, alternatively you can upload data to the PostGreSQL database and configure a layer on data from the database.
-
-The configuration file contains references to the collections which are exposed via the OGC API's.
-Check [the documentation](https://docs.pygeoapi.io/en/latest/data-publishing/index.html#providers-overview) to know which backends are supported.
-
-You need to set up an instance of pygeoapi for each series of collections you want to serve on an endpoint.
-
-## BRT background tiles
-
-To find out if BRT background tiles hosted by PDOK can be used, we configured this service to have a map background of WMTS tiles hosted by PDOK. BRT is hosted in epsg:28992 and epsg:3857, the latter is a requirement. Configuration is set up as:
-
-```
- map:
- url: https://service.pdok.nl/brt/achtergrondkaart/wmts/v2_0/standaard/EPSG:3857/{z}/{x}/{y}.png
- attribution: 'Map data © PDOK Kadaster '
-```
-
-## INSPIRE
-
-We used this installation of pygeoapi to research the INSPIRE use case. Adding several types of links as suggested by INSPIRE is doable in pygeoapi. The software doesn't help much, but also doesn't limit you in the type of links you want to add, our configuration is:
-
-```
- links:
- - type: text/html
- rel: describedby
- title: Metadata as HTML
- href: https://www.nationaalgeoregister.nl/geonetwork/srv/metadata/45eaae76-874a-4fe1-88f4-820517e3de73
- hreflang: nl
- - type: application/xml
- rel: describedby
- title: Metadata as iso19139 xml
- href: https://www.nationaalgeoregister.nl/geonetwork/srv/metadata/45eaae76-874a-4fe1-88f4-820517e3de73/formatters/xml
- hreflang: nl
- - type: text/html
- rel: tag
- title: Referentie naar het concept beschermde gebieden (inspire registry)
- href: http://inspire.ec.europa.eu/featureconcept/ProtectedSite
- hreflang: nl
- - type: application/gml+xml
- rel: enclosure
- title: Download volledige dataset Werelderfgoed als GML
- href: https://service.pdok.nl/rce/ps-ch/wfs/v1_0?request=GetFeature&service=WFS&version=1.1.0&typeName=ps-ch:rce_inspire_polygons&outputFormat=text%2Fxml%3B%20subtype%3Dgml%2F3.1.1
- hreflang: nl
-```
\ No newline at end of file
diff --git a/docs/docs/setup/qgis.md b/docs/docs/setup/qgis.md
deleted file mode 100644
index 5ceef73..0000000
--- a/docs/docs/setup/qgis.md
+++ /dev/null
@@ -1,47 +0,0 @@
----
-title: Setup QGIS Server
----
-
-# Setup QGIS Server
-
-[qgis](https://qgis.org) is a desktop as well as a server solution. The server solution provides typical OGC services sucha as WMS, WFS. Since recently also OGC API Features is available.
-
-Deployed docker image from
-https://hub.docker.com/r/camptocamp/qgis-server.
-Following the hints from
-https://www.qcooperative.net/blog/ogcapif/ and https://docs.qgis.org/testing/en/docs/server_manual/services.html#wfs3-ogc-api-features
-
-## Issues
-
-I had a hard time finding in documentation what the
-url is to open ogc api features endpoint,
-it appears to be '[/qgis/wfs3](/qgis/wfs3)'.
-I assume this will likely be changed in upcoming versions.
-
-Somehow the feature collections are not loaded,
-although the [WMS](/qgis?request=getcapabilities&service=WMS) is able to display them
-
-### Container Write Permission
-Could not use the default `/etc/qgisserver/project.qgs` Docker volume mapping, as the
-referenced GPKG files needed write access (for WAL files) in that dir.
-The solutions was to set `QGIS_PROJECT_FILE` explicitly. However it resulted in a working situation, but the project file could not be located by the service. So I restored the situation. It means we still have no write privileges in the data folder.
-
-```
- environment:
- # Must override default to allow write access e.g. GPKG WALs for www-data user
- - QGIS_PROJECT_FILE:/myqgisserver/project.qgs
-
- #- QGIS_SERVER_LOG_LEVEL:0
- #- PGSERVICEFILE:If you want to change the default of /etc/qgisserver/pg_service.conf
- #- QGIS_PROJECT_FILE:If you want to change the default of /etc/qgisserver/project.qgs
- #- MAX_REQUESTS_PER_PROCESS:The number of requests a QGIS server will serve before being restarted by apache
- #- QGIS_CATCH_SEGV:1
-
- volumes:
- # Map data and config into container
- - ./data:/myqgisserver
-```
-
-### Publish layers as WFS on the project
-
-I ran into the problem that the layers were displayed on the WMS capabilities, but not as collections on ogc api features. I requested help from the qgis mailinglist, but no direct solution. Until Allesandro Pasotti pointed me on the fact that I have to activate WFS on layers before they are available via WFS and OGC API Features. You can set WFS access via project properties > QGIS Server > WFS.
diff --git a/docs/mkdocs.yml b/docs/mkdocs.yml
deleted file mode 100644
index 99276ba..0000000
--- a/docs/mkdocs.yml
+++ /dev/null
@@ -1,27 +0,0 @@
-site_name: Geonovum OGC API Testbed
-site_description: "Geonovum OGC API Testbed"
-site_author: Geonovum
-copyright: "© 2021 Geonovum"
-site_url: https://apitestdocs.geonovum.nl
-repo_url: https://github.com/Geonovum/ogc-api-testbed
-docs_dir: docs
-nav:
- - Home: index.md
- - Howto: howto/index.md
- - Setup: setup/index.md
- - Cases: cases/index.md
- - Findings: findings/index.md
- - Credits: credits/index.md
- - Code: https://github.com/Geonovum/ogc-api-testbed
-
-# use_directory_urls: true
-
-theme:
- name: material
- palette:
- # See https://squidfunk.github.io/mkdocs-material/setup/changing-the-colors/#color-scheme
- # Default is indigo (blue)
- primary: light green
-
-plugins:
- - search
diff --git a/docs/requirements.txt b/docs/requirements.txt
deleted file mode 100644
index 9a8a4ca..0000000
--- a/docs/requirements.txt
+++ /dev/null
@@ -1,2 +0,0 @@
-mkdocs
-mkdocs-material
diff --git a/services/admin/docker-compose.yml b/services/admin/docker-compose.yml
index 372b2b4..79db94c 100644
--- a/services/admin/docker-compose.yml
+++ b/services/admin/docker-compose.yml
@@ -124,5 +124,4 @@ volumes:
networks:
default:
- external:
- name: service-network
+ name: service-network
diff --git a/services/admin/ghc.env b/services/admin/ghc.env
deleted file mode 100644
index 8758d8f..0000000
--- a/services/admin/ghc.env
+++ /dev/null
@@ -1,29 +0,0 @@
-# See also ansible/vars/vars.yml
-TZ=Europe/Zurich
-GHC_PROBE_HTTP_TIMEOUT_SECS=90
-GHC_MINIMAL_RUN_FREQUENCY_MINS=15
-GHC_RETENTION_DAYS=30
-GHC_NOTIFICATIONS=True
-GHC_NOTIFICATIONS_VERBOSITY=False
-GHC_RUNNER_IN_WEBAPP=False
-GHC_SELF_REGISTER=False
-GHC_LOG_LEVEL=20
-GHC_SITE_TITLE=NGDI-20-60 OGC API Testbed - GeoHealthCheck
-GHC_SITE_URL=https://`hostname -f`/ghc
-GHC_WWW_LINK_EXCEPTION_CHECK=True
-LC_ALL=nl_NL.UTF-8
-LANG=nl_NL.UTF-8
-LANGUAGE=nl_NL.UTF-8
-SCRIPT_NAME=/ghc
-SQLALCHEMY_DATABASE_URI=${GHC_SQLALCHEMY_DATABASE_URI:-'postgresql://ghc:ghc@ghc_db:5432/ghc'}
-ADMIN_NAME=${GHC_ADMIN_USER_NAME:-admin}
-ADMIN_PWD=${GHC_ADMIN_USER_PASSWORD:-admin}
-ADMIN_EMAIL=${GHC_ADMIN_USER_EMAIL:-ghc@ghc.com}
-GHC_NOTIFICATIONS_EMAIL=${GHC_NOTIFICATIONS_EMAIL}
-GHC_ADMIN_EMAIL=${GHC_SMTP_EMAIL}
-GHC_SMTP_SERVER=${GHC_SMTP_SERVER}
-GHC_SMTP_PORT=${GHC_SMTP_PORT}
-GHC_SMTP_TLS=${GHC_SMTP_TLS}
-GHC_SMTP_SSL=${GHC_SMTP_SSL}
-GHC_SMTP_USERNAME=${GHC_SMTP_USERNAME}
-GHC_SMTP_PASSWORD=${GHC_SMTP_PASSWORD}
\ No newline at end of file
diff --git a/services/geoserver/data/README.md b/services/geoserver/data/README.md
deleted file mode 100644
index 684b60c..0000000
--- a/services/geoserver/data/README.md
+++ /dev/null
@@ -1,43 +0,0 @@
-Default Data Directory
-======================
-
-A default empty GeoServer OGC API Experiment GeoNovum data directory.
-
-This data directory requires provides default configuration for:
-
-* csw
-* wcs
-* wds
-* wms and wmts
-* wps
-* control-flow
-
-Several folders are created and populated as needed by GeoServer:
-
-* data
-* gwc
-* logs
-* security
-* styles
-
-FAQ
----
-
-Q: How to update GeoServer data directory contents?
-
-Updates to GeoServer data directory occur very infrequently, with new settings and configuration options being the most common change.
-
-Updates are performed automatically by GeoServer during application startup.
-
-For additional guidance please see:
-
-* https://www.geonovum.nl/docs/geoserver-enterprise/
-* https://my.geonovum.nl/knowledgebase/130/GeoServer-Enterprise
-
-Q: Where to storing large data files?
-
-The GeoServer Data Directory is easy to access with the Browse button setting up a new Data Store or Coverage Store.
-The REST API and Importer will create a folder `data` when content is uploaded.
-
-When working with large files we recommend choosing a high performance file system and managing this information
-outside of the data directory (allowing backups of application configuration to be smaller and more easily managed).
\ No newline at end of file
diff --git a/services/geoserver/data/controlFlow.properties b/services/geoserver/data/controlFlow.properties
deleted file mode 100644
index f3d00e1..0000000
--- a/services/geoserver/data/controlFlow.properties
+++ /dev/null
@@ -1,21 +0,0 @@
-# if a request waits in queue for more than 60 seconds it's not worth executing,
-# the client will likely have given up by then
-timeout=60
-
-# don't allow the execution of more than 100 requests total in parallel
-ows.global=100
-
-# don't allow more than 10 GetMap in parallel
-ows.wms.getmap=10
-
-# don't allow more than 4 outputs with Excel output as it's memory bound
-ows.wfs.getfeature.application/msexcel=4
-
-# don't allow a single user to perform more than 6 requests in parallel
-# (6 being the Firefox default concurrency level at the time of writing)
-user=6
-
-# don't allow the execution of more than 16 tile requests in parallel
-# (assuming a server with 4 cores, GWC empirical tests show that throughput
-# peaks up at 4 x number of cores. Adjust as appropriate to your system)
-ows.gwc=16
\ No newline at end of file
diff --git a/services/geoserver/data/csw.xml b/services/geoserver/data/csw.xml
deleted file mode 100644
index d0ccd53..0000000
--- a/services/geoserver/data/csw.xml
+++ /dev/null
@@ -1,23 +0,0 @@
-
- csw
- true
- NGDI-20-60 OGC API Testbed Geoserver CSW
- NGDI-20-60 OGC API Testbed Geoserver Catalogue Service
- https://heig-vd.ch/rad/instituts/mei/mediamaps
- Catalogue Services (CSW) describing server contents as records.
- NONE
- NONE
-
-
- 2.0.2
-
-
-
- CSW
- GeoServer
-
- false
- https://ogc.heig-vd.ch/geoserver/web
- http://schemas.opengis.net
- false
-
\ No newline at end of file
diff --git a/services/geoserver/data/demo/WCS_getCapabilities_1.0.0.xml b/services/geoserver/data/demo/WCS_getCapabilities_1.0.0.xml
deleted file mode 100644
index 5c85793..0000000
--- a/services/geoserver/data/demo/WCS_getCapabilities_1.0.0.xml
+++ /dev/null
@@ -1,18 +0,0 @@
-
-
-
-
- SettingsInfoImpl-14e8eba4:171a545ba94:-8000
-
- HEIG-VD Centre St-Roch Avenue des Sports 20
- Yverdon-les-Bain
- Switzerland
- 1401
- Vaud
- maxime.collombin@heig-vd.ch
- Mediamaps
- Mediamaps
- +41 (0)24 557 76 04
-
- UTF-8
- 8
- http://geonovum.nl
- https://ogc.heig-vd.ch/geoserver
- true
- false
-
-
-
- quietOnNotFound
- false
-
-
-
- false
- false
- false
-
-
- false
- true
- 5
- 7
- 0.5
- 0.75
- false
- false
- false
- false
- false
-
-
- Affine
- BandCombine
- BandMerge
- BandSelect
- Binarize
- Border
- ColorConvert
- Crop
- ErrorDiffusion
- Format
- ImageFunction
- Lookup
- Mosaic
- Null
- OrderedDither
- Rescale
- Scale
- Stats
- Translate
- Warp
- algebric
- operationConst
-
-
-
-
- 5
- 5
- 30000
- UNBOUNDED
- 10240
-
- 1066
- 0
- true
- true
- 1024
- false
- memoryLockProvider
- DEFAULT
-
\ No newline at end of file
diff --git a/services/geoserver/data/gwc-gs.xml b/services/geoserver/data/gwc-gs.xml
deleted file mode 100644
index 448afb7..0000000
--- a/services/geoserver/data/gwc-gs.xml
+++ /dev/null
@@ -1,42 +0,0 @@
-
- 1.1.0
- false
- true
- true
- false
- false
- true
- class org.geowebcache.storage.blobstore.memory.guava.GuavaCacheProvider
-
-
- class org.geowebcache.storage.blobstore.memory.guava.GuavaCacheProvider
-
- 16
- NULL
- 4
- 120
-
-
-
- true
- true
- 4
- 4
- 0
-
- EPSG:4326
- EPSG:900913
-
-
- image/png
- image/jpeg
-
-
- image/png
- image/jpeg
-
-
- image/png
- image/jpeg
-
-
\ No newline at end of file
diff --git a/services/geoserver/data/gwc/geoclimate_Building_urban_typology/EPSG_4326_03/2_1/08_06.geojson b/services/geoserver/data/gwc/geoclimate_Building_urban_typology/EPSG_4326_03/2_1/08_06.geojson
deleted file mode 100644
index a874874..0000000
--- a/services/geoserver/data/gwc/geoclimate_Building_urban_typology/EPSG_4326_03/2_1/08_06.geojson
+++ /dev/null
@@ -1 +0,0 @@
-{"type":"FeatureCollection","totalFeatures":"unknown","features":[]}
\ No newline at end of file
diff --git a/services/geoserver/data/gwc/geoclimate_Building_urban_typology/EPSG_4326_03/2_1/08_06.topojson b/services/geoserver/data/gwc/geoclimate_Building_urban_typology/EPSG_4326_03/2_1/08_06.topojson
deleted file mode 100644
index 44acfd2..0000000
--- a/services/geoserver/data/gwc/geoclimate_Building_urban_typology/EPSG_4326_03/2_1/08_06.topojson
+++ /dev/null
@@ -1 +0,0 @@
-{"type":"Topology","count":0,"transform":{"scale":[0.087890625,-0.087890625],"translate":[0.0,67.5]},"arcs":[],"objects":{}}
\ No newline at end of file
diff --git a/services/geoserver/data/gwc/geowebcache.xml b/services/geoserver/data/gwc/geowebcache.xml
deleted file mode 100644
index 157a932..0000000
--- a/services/geoserver/data/gwc/geowebcache.xml
+++ /dev/null
@@ -1,135 +0,0 @@
-
-
- 1.20.0
- 120
-
-
- EPSG:21781
- EPSG:21781
-
- 21781
-
-
-
- 485014.05245137925
- 74188.69437769346
- 837016.9329778461
- 299782.76349412405
-
-
- false
-
- 881.226832486057
- 440.6134162430285
- 220.30670812151425
- 110.15335406075712
- 55.07667703037856
- 27.53833851518928
- 13.76916925759464
- 6.88458462879732
- 3.44229231439866
- 1.72114615719933
- 0.860573078599665
- 0.4302865392998325
- 0.2151432696499163
- 0.1075716348249581
- 0.0537858174124791
- 0.0268929087062395
- 0.0134464543531198
- 0.0067232271765599
- 0.0033616135882799
- 0.00168080679414
- 8.4040339707E-4
- 4.20201698535E-4
-
- 1.0
- 2.8E-4
-
- EPSG:21781:0
- EPSG:21781:1
- EPSG:21781:2
- EPSG:21781:3
- EPSG:21781:4
- EPSG:21781:5
- EPSG:21781:6
- EPSG:21781:7
- EPSG:21781:8
- EPSG:21781:9
- EPSG:21781:10
- EPSG:21781:11
- EPSG:21781:12
- EPSG:21781:13
- EPSG:21781:14
- EPSG:21781:15
- EPSG:21781:16
- EPSG:21781:17
- EPSG:21781:18
- EPSG:21781:19
- EPSG:21781:20
- EPSG:21781:21
-
- 256
- 256
- false
-
-
- EPSG:2056
- EPSG:2056 (CH1903+ / LV95) tile matrix set.
-
- 2056
-
-
-
- 2485014.052451379
- 1074188.6943776933
- 2837016.9329778464
- 1299782.763494124
-
-
- false
-
- 4000.0
- 2000.0
- 1000.0
- 500.0
- 250.0
- 100.0
- 50.0
- 20.0
- 10.0
- 5.0
- 2.5
- 1.0
- 0.5
- 0.25
- 0.1
- 0.05
-
- 1.0
- 2.8E-4
-
- EPSG:2056:0
- EPSG:2056:1
- EPSG:2056:2
- EPSG:2056:3
- EPSG:2056:4
- EPSG:2056:5
- EPSG:2056:6
- EPSG:2056:7
- EPSG:2056:8
- EPSG:2056:9
- EPSG:2056:10
- EPSG:2056:11
- EPSG:2056:12
- EPSG:2056:13
- EPSG:2056:14
- EPSG:2056:15
-
- 256
- 256
- false
-
-
-
\ No newline at end of file
diff --git a/services/geoserver/data/gwc/metadata.properties b/services/geoserver/data/gwc/metadata.properties
deleted file mode 100644
index e69de29..0000000
diff --git a/services/geoserver/data/gwc/r-pod-imagery_131031_Yverdon_Heig_10cm/metadata.properties.gz b/services/geoserver/data/gwc/r-pod-imagery_131031_Yverdon_Heig_10cm/metadata.properties.gz
deleted file mode 100644
index 1fb8d3a..0000000
Binary files a/services/geoserver/data/gwc/r-pod-imagery_131031_Yverdon_Heig_10cm/metadata.properties.gz and /dev/null differ
diff --git a/services/geoserver/data/layouts/style-editor-legend.xml b/services/geoserver/data/layouts/style-editor-legend.xml
deleted file mode 100644
index 1095a87..0000000
--- a/services/geoserver/data/layouts/style-editor-legend.xml
+++ /dev/null
@@ -1,3 +0,0 @@
-
-
\ No newline at end of file
diff --git a/services/geoserver/data/logging.xml b/services/geoserver/data/logging.xml
deleted file mode 100644
index b4e4d03..0000000
--- a/services/geoserver/data/logging.xml
+++ /dev/null
@@ -1,5 +0,0 @@
-
- DEFAULT_LOGGING.properties
- logs/geoserver.log
- true
-
\ No newline at end of file
diff --git a/services/geoserver/data/styles/default_generic.sld b/services/geoserver/data/styles/default_generic.sld
deleted file mode 100644
index a08a68f..0000000
--- a/services/geoserver/data/styles/default_generic.sld
+++ /dev/null
@@ -1,86 +0,0 @@
-
-
-
- generic
-
- Generic
- Generic style
-
-
- raster
- Opaque Raster
-
-
- true
-
-
-
- 1.0
-
-
-
- Polygon
- Grey Polygon
-
-
-
-
- 2
-
-
-
-
- #AAAAAA
-
-
- #000000
- 1
-
-
-
-
- Line
- Blue Line
-
-
-
-
- 1
-
-
-
-
- #0000FF
- 1
-
-
-
-
- point
- Red Square Point
-
-
-
- square
-
- #FF0000
-
-
- 6
-
-
-
- first
-
-
-
-
diff --git a/services/geoserver/data/styles/default_point.sld b/services/geoserver/data/styles/default_point.sld
deleted file mode 100644
index c02a54e..0000000
--- a/services/geoserver/data/styles/default_point.sld
+++ /dev/null
@@ -1,37 +0,0 @@
-
-
-
-
- default_point
-
-
- Red Square Point
- A sample style that draws a red square point
-
-
-
-
- rule1
- Red Square Point
- A 6 pixel square with a red fill and no stroke
-
-
-
- square
-
- #FF0000
-
-
- 6
-
-
-
-
-
-
-
\ No newline at end of file
diff --git a/services/geoserver/data/styles/default_polygon.sld b/services/geoserver/data/styles/default_polygon.sld
deleted file mode 100644
index 82916a2..0000000
--- a/services/geoserver/data/styles/default_polygon.sld
+++ /dev/null
@@ -1,35 +0,0 @@
-
-
-
-
- default_polygon
-
-
- Default Polygon
- A sample style that draws a polygon
-
-
-
-
- rule1
- Gray Polygon with Black Outline
- A polygon with a gray fill and a 1 pixel black outline
-
-
- #AAAAAA
-
-
- #000000
- 1
-
-
-
-
-
-
-
\ No newline at end of file
diff --git a/services/geoserver/data/styles/default_raster.sld b/services/geoserver/data/styles/default_raster.sld
deleted file mode 100644
index 83ad95a..0000000
--- a/services/geoserver/data/styles/default_raster.sld
+++ /dev/null
@@ -1,29 +0,0 @@
-
-
-
-
- default_raster
-
-
- Opaque Raster
- A sample style that draws a raster, good for displaying imagery
-
-
-
-
- rule1
- Opaque Raster
- A raster with 100% opacity
-
- 1.0
-
-
-
-
-
-
\ No newline at end of file
diff --git a/services/geoserver/data/styles/generic.xml b/services/geoserver/data/styles/generic.xml
deleted file mode 100644
index e102eeb..0000000
--- a/services/geoserver/data/styles/generic.xml
+++ /dev/null
@@ -1,9 +0,0 @@
-
\ No newline at end of file
diff --git a/services/geoserver/data/styles/line.xml b/services/geoserver/data/styles/line.xml
deleted file mode 100644
index fb1accd..0000000
--- a/services/geoserver/data/styles/line.xml
+++ /dev/null
@@ -1,9 +0,0 @@
-
\ No newline at end of file
diff --git a/services/geoserver/data/styles/point.xml b/services/geoserver/data/styles/point.xml
deleted file mode 100644
index 8ee85d4..0000000
--- a/services/geoserver/data/styles/point.xml
+++ /dev/null
@@ -1,10 +0,0 @@
-
\ No newline at end of file
diff --git a/services/geoserver/data/styles/polygon.xml b/services/geoserver/data/styles/polygon.xml
deleted file mode 100644
index 422f0b1..0000000
--- a/services/geoserver/data/styles/polygon.xml
+++ /dev/null
@@ -1,10 +0,0 @@
-
\ No newline at end of file
diff --git a/services/geoserver/data/styles/raster.xml b/services/geoserver/data/styles/raster.xml
deleted file mode 100644
index 6cce488..0000000
--- a/services/geoserver/data/styles/raster.xml
+++ /dev/null
@@ -1,10 +0,0 @@
-
\ No newline at end of file
diff --git a/services/geoserver/data/templates/ogc/features/common-footer.ftl.bkp b/services/geoserver/data/templates/ogc/features/common-footer.ftl.bkp
deleted file mode 100644
index 962b7cc..0000000
--- a/services/geoserver/data/templates/ogc/features/common-footer.ftl.bkp
+++ /dev/null
@@ -1,70 +0,0 @@
-
-
-
-
-
-
-
-