-
Notifications
You must be signed in to change notification settings - Fork 23
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.
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:
- Parts which needs to be configurable per user who is running the server in his/hers infrastructure.
- 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:
- Parts which needs to be configurable per user who is running the server in his/hers infrastructure.
- Address
- Municipality
- Real estate
- Glossary
- Exclusion of liability
- 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.
- 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.
The only thing you have to do is to configure these sources inside of the yaml file so that they (the sources) can access your maybe special organized data (how this can be done we will have a look at later). To be able to do so you need to understand what is delivered with this app. We designed it to work in a standard configuration out of the box. There are only a few steps to a up and running app. Since the specification is really clear we provided a database representation of every part mentioned in the specification.
You see the prepared database schema content for a plr:
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.
- get a running pyramid application
- install this package via pip
- get the pyramid_oereb.yml file out of this repository (choose version same as installed)
- add parameters to *.ini files
- create database (manual)
- run create_standard_tables command
- fill in your data
- start server
- have fun