.. _initialization:
Initialization
==============
In order to set up an instance of VS, the ``pvs_starter`` utility is
recommended. It is distributed as a Python package, easily installed via
``pip``.
.. code-block:: bash
pip3 install pvs_starter # TODO: git url
Now the VS instance can be set up like this:
.. code-block:: bash
python3 -m pvs_starter.cli config.yaml out/ -f
This takes the initialization configuration ``config.yaml`` to generate
the structure in the ``out/`` directory.
Initialization config
---------------------
The important part of the initialization is the configuration. The format is
structured in YAML and will be detailed here. It contains the following
sections:
``database``
~~~~~~~~~~~~
Here, access credentials of the database are stored. It defines the
internal database name, user and password that will be created when the stack
is deployed. Note that there is no ``host`` setting, as this will be handled
automatically.
.. code-block:: yaml
database:
name: vs_db
user: vs_user
password: Go-J_eOUvj2k
``django_admin``
~~~~~~~~~~~~~~~~
This section deals with the setup of a Django admin account. This is used to
later access the admin panel to inspect the registered data.
.. code-block:: yaml
django_admin:
user: admin
mail: office@eox.at
password: jvLwv_20x-69
``preprocessor``
~~~~~~~~~~~~~~~~
Here, the preprocessing can be configured in detail.
TODO
``products``
~~~~~~~~~~~~
This section defines ``product_type`` related information. The two most important
settings here are the ``type_extractor`` and ``level_extractor`` structures
which specify how the product type and product level should be extracted from
the metadata. For this, an XPath (or multiple) can be specified to retrieve
that information.
The ``types`` section defines the available ``product_types`` and which ``browse``
and ``mask`` types are to be generated.
.. code-block:: yaml
products:
type_extractor:
xpath:
namespace_map:
level_extractor:
xpath:
namespace_map:
types:
PL00:
default_browse: TRUE_COLOR
browses:
TRUE_COLOR:
red:
expression: red
range: [1000, 15000]
nodata: 0
green:
expression: green
range: [1000, 15000]
nodata: 0
blue:
expression: blue
range: [1000, 15000]
nodata: 0
FALSE_COLOR:
red:
expression: nir
range: [1000, 15000]
nodata: 0
green:
expression: red
range: [1000, 15000]
nodata: 0
blue:
expression: green
range: [1000, 15000]
nodata: 0
NDVI:
grey:
expression: (nir-red)/(nir+red)
range: [-1, 1]
masks:
validity:
validity: true
``collections``
~~~~~~~~~~~~~~~
In the ``collections`` section, the collections are set up and it is defined
which products of based on ``product_type`` and ``product_level`` will be inserted into them. The
``product_types`` must list types defined in the ``products`` section.
.. code-block:: yaml
collections:
COLLECTION:
product_types:
- PL00
product_levels:
- Level_1
- Level_3
``storages``
~~~~~~~~~~~~
Here, the three relevant storages can be configured: the ``source``,
``preprocessed`` and ``cache`` storages.
The ``source`` storage defines the location from which the original files will be
downloaded to be preprocessed. Preprocessed images and metadata will then be
uploaded to the ``preprocessed`` storage. The cache service will cache images on
the ``cache`` storage.
Each storage definition uses the same structure and can target various types
of storages, such as OpenStack swift.
These storage definitions will be used in the appropriate sections.
TODO: improve example
.. code-block:: yaml
storages:
source:
auth_type: keystone
auth_url:
version: 3
username:
password:
tenant_name:
tenant_id:
region_name:
container:
preprocessed:
auth_type: keystone
auth_url:
version: 3
username:
password:
tenant_name:
tenant_id:
region_name:
container:
cache:
type: swift
auth_type: keystone
auth_url: https://auth.cloud.ovh.net/v3/
auth_url_short: https://auth.cloud.ovh.net/
version: 3
username:
password:
tenant_name:
tenant_id:
region_name:
container:
``cache``
~~~~~~~~~
This section defines the exposed services, and how the layers shall be cached internally.
.. code-block:: yaml
cache:
metadata:
title: PRISM Data Access Service (PASS) developed by EOX
abstract: PRISM Data Access Service (PASS) developed by EOX
url: https://vhr18.pvs.prism.eox.at/cache/ows
keyword: view service
accessconstraints: UNKNOWN
fees: UNKNOWN
contactname: Stephan Meissl
contactphone: Please contact via mail.
contactfacsimile: None
contactorganization: EOX IT Services GmbH
contactcity: Vienna
contactstateorprovince: Vienna
contactpostcode: 1090
contactcountry: Austria
contactelectronicmailaddress: office@eox.at
contactposition: CTO
providername: EOX
providerurl: https://eox.at
inspire_profile: true
inspire_metadataurl: TBD
defaultlanguage: eng
language: eng
services:
wms:
enabled: true
wmts:
enabled: true
connection_timeout: 10
timeout: 120
expires: 3600
key: /{tileset}/{grid}/{dim}/{z}/{x}/{y}.{ext}
tilesets:
VHR_IMAGE_2018__TRUE_COLOR:
title: VHR Image 2018 True Color
abstract: VHR Image 2018 True Color
VHR_IMAGE_2018__FALSE_COLOR:
title: VHR Image 2018 False Color
abstract: VHR Image 2018 False Color
VHR_IMAGE_2018__NDVI:
title: VHR Image 2018 NDVI
abstract: VHR Image 2018 NDVI
style: earth
VHR_IMAGE_2018_Level_1__TRUE_COLOR:
title: VHR Image 2018 Level 1 True Color
abstract: VHR Image 2018 Level 1 True Color
VHR_IMAGE_2018_Level_1__FALSE_COLOR:
title: VHR Image 2018 Level 1 False Color
abstract: VHR Image 2018 Level 1 False Color
VHR_IMAGE_2018_Level_1__NDVI:
title: VHR Image 2018 Level 1 NDVI
abstract: VHR Image 2018 Level 1 NDVI
style: earth
VHR_IMAGE_2018_Level_1__TRUE_COLOR:
title: VHR Image 2018 Level 3 True Color
abstract: VHR Image 2018 Level 3 True Color
VHR_IMAGE_2018_Level_1__FALSE_COLOR:
title: VHR Image 2018 Level 3 False Color
abstract: VHR Image 2018 Level 3 False Color
VHR_IMAGE_2018_Level_1__NDVI:
title: VHR Image 2018 Level 3 NDVI
abstract: VHR Image 2018 Level 3 NDVI
style: earth
# grids? cache options?