Main flow

The basic configuration of this package is made inside a yaml file. Please see the README.md of your dedicated version.

To understand how the yaml is written and how the whole thing works we need to start on a higher level.

The Parts

basically the application pyramid_oereb (called the "app" in the following texts) is nothing else then a big script which gets an identifier for a real estate (egrid, etc.) finding the corresponding dataset using its geometry to intersect with some other data (call it topic, theme, whatever) and delivers the found elements. Ok ok... We have several extra services and different response formats but in a high level view this is it. What sounds simple here starts getting complex when we add a component of free configuration. And that's what we did.

As pointed out before we have only some simple parts which are the core of the extract. These parts can be classified as follows:

1. Parts which needs to be configurable per user who is running the server in his/hers infrastructure.
2. Parts which needs to be configurable per user who is running the server in his/hers infrastructure and which needs to be configurable per theme.

To fit this pattern we developed a layer architecture which enables us to separate this configuration from the core application. The layer we are talking about now is the source layer. It is the lowest one. Basically every thing which is data and needs to be read from somewhere is defined as a source. A source is a little piece of code which handles the talking to the data bucket (database, file system, webservice, etc.). Every part mentioned above (doesn't matter if 1 or 2) is represented in such a source.

Thats why we can specify them more exactly. So following and completing the scheme above it looks as follows:

1. Parts which needs to be configurable per user who is running the server in his/hers infrastructure.
   1. Address
   2. Municipality
   3. Real estate
   4. Glossary
   5. Exclusion of liability
2. Parts which needs to be configurable per user who is running the server in his/hers infrastructure and which needs to be configurable per theme.
   1. Public law restriction (in the code often shortened to plr)

Since we do not have a single public law restriction but several and since they have to follow all the same rules in the end we can provide an iterable list of public law restriction sources.

Looking at the scheme above you will find exactly this inside of the pyramid_oereb.yml file inside of this repository.

Putting the parts together

The only thing you have to do is to configure these sources inside of the yaml file so that they can access your maybe special organized data. To be able to do so you need to understand what is delivered with this app. We designed it to work out of the box in a standard configuration. Since the specification is really clear we provided a database representation of every part mentioned in the specification. We call this the standard database configuration. This standard configuration provides easy access to both above mentioned parts. You can imagine these like ready to use buckets where you can throw your data in (you need to fit your data in the model of course with FME, etc.). We provide this standard configuration for all 17 standard public law restrictions (see the pyramid_oereb.yml) and the above mentioned sources under part 1. This includes the sqlalchemy models, a source which can deal with the standard database scheme (defined by the specification) and a handy script to create this structures in your own database out of the box.