[FrontPage] [TitleIndex] [WordIndex

deegree 3 datastore configuration concepts

Status: TMC proposal (2009-08-28)

This page describes relevant technical concepts to be considered in the configuration of datastores in deegree 3.

1. The general concept "datastore"

A basic observation is that the two most important categories of geospatial data are coverages and features and that most OGC services are based on providing access to -- or operations on -- stored datasets of these kinds.

1.1. OGC services and geospatial data

Beside these three services, other services use access to stored coverages and features as well:

It should be noted that the SOS and the CSW don't fit here 100%, as their native object model is neither coverage nor feature based. The TMC currently opts for providing specialized data access mechanisms for these two services, although the possibilities to back the SOS by coverage/feature datastores should still be considered and evaluated. The deegree 3 WPVS uses a specialised data type as well: it uses multi-resolution triangle meshes to provide efficient rendering of high-volume DEMs.

1.2. Datastores

In the following, the term "datastore" is used to refer to stored geospatial data, i.e. coverages or features. For an efficient implementation, it is vital to use datastores as an abstraction layer between data providers (backends) and the deegree 3 OGC web services. This way, the implementation as well as the higher levels of the service configurations do not need to cope with the details of the specific source of the data.

1.2.1. Coverage datastore backends

Coverage datastores can be backed by different storage formats / technologies. Some examples:

1.2.2. Feature datastore backends

Feature datastores can be backed by different storage formats / technologies. Some examples:

2. Configuration of datastores in deegree 3

In order to provide a consistent and reusable way of accessing stored coverage and feature data, it is crucial that all services can use the same code and configuration mechanisms.

2.1. Requirements of different datastores

Some tests have been performed for different kinds of backends and it has been recognized, that the user-friendliness of the configuration can be improved a lot over deegree 2, if the configurations of the different backends only require the information that is specific for this certain type:

The TMC favors to custom-tailor the configuration process to the different backends, so the setup becomes as easy and hassle-free as possible.

2.2. Local datastore configuration

It should be possible to configure datastores as part of a service configuration, e.g. inside the WMS configuration document or as datastore configuration documents that are located inside or below the WMS configuration directory. These datastores are only relevant for the specific service.

2.3. Global datastore configuration

Besides configuring datastores individually for certain services, a second (global) way is recommended by the TMC as well, which would be used to define datastores that can be referenced in the different service-configurations using a unique identifier. Some use-cases:

In both cases, duplication of configuration as well as errors/inconsistencies are avoided.

Here's an example for a file based configuration of global datastores. The configuration files would be placed below the datastores folder in the WEB-INF/conf directory of the services webapp and scanned on startup or dynamically.

`-- datastores
    |-- coverage
    |   |-- rasterstore1.xml
    |   |-- rasterstore2.xml
    |   `-- rasterstoreN.xml
    `-- feature
        |-- featurestore1.xml
        |-- featurestore2.xml
        `-- featurestoreN.xml

If the plans for a web-based service configuration are realized in a later phase, the service/datastore configuration process can of course be integrated in a guided and user-friendly way.

2.4. Relation between datastore and service configuration

For a clean technical implementation, it is important to separate the datastore concepts from details that are specific to the configuration of a certain service.

Originally, it has been planned to provide bbox and scale in the configuration of coverage datastores. However, during the development of the WPVS, it turned out that both introduce fundamental problems here and cannot be used as a solid means of switching between different resolutions and datasets. In the case of the WPVS, the WMS-motivated 2D scale constraint does not work, as no single scale exists for a 3D scene. The bounding box constraint also proved to be rather unusable as a dataset/LOD selection means as it has to be deeply integrated with WPVS datastructures in order to work as expected.

In order to make the datastores and configuration safely reusable in different contexts, the TMC advises to avoid these kinds of constraints on the datastore level, but to move these to the service configurations.

3. Summary of TMC recommendations


2018-04-20 12:04