From 4ffcdc6e4fc66ef2c3e7d75ae6e700f53d646ccb Mon Sep 17 00:00:00 2001 From: Michel Peltriaux Date: Wed, 11 Aug 2021 12:53:15 +0200 Subject: [PATCH] =?UTF-8?q?=E2=80=9Econcept=E2=80=9C=20=C3=A4ndern?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- concept.md | 67 ++++++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 57 insertions(+), 10 deletions(-) diff --git a/concept.md b/concept.md index 6b68008..07bd683 100644 --- a/concept.md +++ b/concept.md @@ -12,12 +12,17 @@ The following brief overview presents the most important concept ideas, which ar In the following chapters we are refering to `data`. This data has been called XY-objects in the past (~"Kompenationsobjekt", "Eingriffsobjekt", ...) which wasn't handy for people being technically uncertain. We simplifiy this by calling it (for this documentation) simply `data`. The different data types in konova are -1. `Intervention` (~"Eingriffsobjekt") -1. `Compensation` (~"Kompensationsobjekt") -1. `EcoAccount` (~"Ökokonto") -1. `Ema` (~"EMA") +1. `Intervention` - "Eingrff" (~"Eingriffsobjekt") +1. `Compensation` - "Kompensation" (~"Kompensationsobjekt") +1. `EcoAccount` - "Ökokonto" (~"Ökokonto") +1. `Ema` - "EMA" (~"EMA") -The former process object (~"Vorgangsobjekt") is no longer needed, as it caused irritation among users anyway. The chapter "Viewing data" clarifies details on the `process state` (~"Vorgangszustand"), which won't exist anymore as well. +The former `process object` (~"Vorgangsobjekt") does not exist anymore, since it caused irritation among users due to it's unclear relation to intervention. The chapter "Viewing data" clarifies details on the `process state` (~"Vorgangszustand"), which won't exist anymore as well. + +### Creating data +Data must be as easily addable and editable as possible. Therefore it is important to dismiss most of the mandatory form fields of the past. Data adding is a process, which can take up some time, since users need to aggregate their information from different sources. It must be acceptable to start with just a geometry and a title for the data and no further information. The user will come back to continue their work until they are done. + +**Please note:** By `checking` or `recording` (see chapters below) data, automatic tests will check the data on consistency or obvious logic errors. This way we won't have any published data with missing information or other issues. ### Sharing data @@ -40,13 +45,55 @@ User groups define permissions in konova. There are three main groups which a us 1. Can create new entries 1. Can share entries with other users 1. `Registration office` (~"Zulassungsbehörde") - 1. Can perform a `check` on data - 1. `Checks` perform some automatic checks on the data, like all file numbers are provided, no inconsistency detected, ... - 1. `Checks` can **not** analyze the content of the data, which means the user still has to take a look on the data - 1. `Checks` are **not** mandatory for further processing of the data. In the past, there were users who did not continue their work, ignored it and so on. This way the data was simply stuck there and an admin had to continue the process. + 1. Can perform a `check` on data (more in the related chapter) 1. `Conservation office` (~"Naturschutzbehörde/Eintragungsstelle") 1. Can perform `recording` on data (~"Verzeichnen") 1. `Recording` performs the same automatic checks on the data, as `check` and marks the data as `recorded` using a timestamp, if no errors occured -# ... +### Checking data +Checks are performed by members of the group `Registration office` (let's call them ZB users from now on). Checks are provided to mark data officially as `checked`, so other users can see that some official took a look on the data. This way the LKompVzVo can be fulfilled: ZB users are in charge of the provided data. By `checking` data, they can assure that this data is correct from their point of view. + +Due to problems in the past, the checks are not mandatory. Users of the group `Conservation office` (call them ETS users) can further process the data whether the check has been performed or not. + +`Checks` perform some automatic checks on the data, like all file numbers are provided, no inconsistency detected, and so on. +`Checks` can **not** analyze the content of the data, which means the user still has to take a look on the data. + +**Only interventions** need to be checked. Compensations are checked, if their intervention is checked. + +Past-check editing resets the check mark, so the check needs to be rerun afterwards. + +### Recording data +Recording (~"Verzeichnen") data works just as in KSP: ETS users can record data, which performs the same automatic tests in the background like checks and can be useful to detect flaws inside the data. However, by recording data, it is finally "official". + +Recorded interventions are published if they are recorded and the binding date (~"Datum der Bestandskraft") has been reached. + +Recorded ecoAccounts are published if they are recorded. + +Compensations are published if their intervention is published. + + +### Deleting data +None of the major data types (Intervention, Compensation, EcoAccount, Ema) will be deleted right away, if the user `deletes` them. Instead, they will be marked as deleted, using a timestamp. This way they can be recovered at any time, in case the deletion was a mistake. +If data has not been restored for timespan x, it can be deleted automatically, to keep the database as clean as possible. + + +### Editing data +Each data type consists of different smaller data types. Compensations for example contain geometry, dates, before-states, after-states, documents, actions (~"Maßnahmen") and so on. Instead of providing everything in a single large form, which needs to be loaded on every user edit, the user must be able to add and delete e.g. an action as easily as possible, directly from the detail view of the compensation. Therefore smaller, handy forms for each sub-data type must be provided. + +### User contact +Not being able to contact another user easily was a major problem of KSP. One user needed to clarify some thing about given objects but had no idea how to contact the initial data provider. If data has been shared with a user, it will be possible to see which other users have access as well. By clicking their usernames, a small window will open up, displaying basic contact details about the user: Person name and email. + +### Interfaces +Interfaces are an ongoing topic in KSP: Import from special XML/GML files, providing access via external API packages, and so on. +Konova will provide all import functionalities from KSP, such as the import of GML files and will extend this by the file type [XPlanung](https://xleitstelle.de/xplanung/ueber_xplanung), which becomes mandatory in 2022. + +Furthermore a user must be able to generate an API Token in the own profile settings, which can be used for accessing the konova Json API. Each token must be verified by an admin, before it can be used by a developer. The API will provide basic read/write endpoints for creating and updating data which will be explained in an open documentation. + + +### Interview mode +Despite providing the "classic" forms for creating new data, an interview mode can provide a smart and handy way to add new data to konova. This interview mode will guide the user through the process of data creation by asking questions, one after another, about the intervention/compensation/ecoAccount in a way, the user can easily answer the questions or select the correct answer from a list of given choices. A small text box may add some background information on why this question is important or which effect the answer will have. This way most of the important data can be inserted easily for beginners. + + +### Frontend +The webfrontend must be clean, self explaining and easy to use. Each form field must provide helpful information about the field and what needs to be entered. The frontend must be built using the [bootstrap library](https://getbootstrap.com/). \ No newline at end of file