Construction
How the MWPA software(s) is structured and works for M.E.E.R. e.V.
Last updated
How the MWPA software(s) is structured and works for M.E.E.R. e.V.
Last updated
This documentation is a technical overview!
MWPA is divided into two parts. The mobile app on your cell phone or tablet. And the server that collects the data.
MWPA - Server: https://github.com/M-E-E-R-e-V/mwpa
MWPA - App: https://github.com/M-E-E-R-e-V/mwpa-app
The data (sightings, tracking) is recorded on the boat using the app for the tablet. Back on site in the office (at home, etc.), the data is then transferred to the Internet (with WiFi) to the MWPA server (our MWPA Server hosting). On the server the data is collected, validated, analyzed, converted and can be exported.
The sightings data and tracking data are sent to the backend via HTTPS protocol. The backend saves this data in the database (images are stored in the file store). The backend takes care of the processing (collection, analysis, conversion and export creation). The frontend (web portal in the browser) can query data on the backend and trigger actions in the backend (exports, etc.)
The structure at M.E.E.R. e.V. was set up as follows:
MWPA Server is installed in a container on a Virtual Environment (Proxmox). The container has its own private IP and can be accessed in the private network. The Virtual Environment can create a backup of the container every evening.
The MWPA server is located in a Docker container in the container. Using an image of the MWPA server, one version can be quickly exchanged for a new version of the MWPA server.
To ensure that MWPA can be accessed securely from the Internet, it is released via HTTPS. This is done via FlyingFish (a proxy manager (reverse proxy), another software that was developed, among other things, to solve problems for the MWPA software).
FlyingFish: https://github.com/stefanwerfling/flyingfish
The FlyingFish uses LetsEncrypt to issue a valid certificate, which can be used by the mobile app without any problems and allows the front end in the browser to run in a secure connection.
An important part of working with scientific data is the correctness of the data.
A data check is already carried out both during data recording (mobile device) and during data collection (backend). That the most important fields are set in order to be able to record a sighting.
According to this check, a sighting is already displayed as yellow/red in the mobile app. The person entering the data can immediately see and correct the error. This sighting is also immediately marked in red in the portal.
Yellow: The sighting is missing data/incomplete, but the sighting is still running (the sighting end time has not yet been set).
Red: The sighting has ended, the end of the sighting time has been set, but data is still missing.
Additional data about the viewing is collected in a separate table using API via third-party services (tested services). Using existing data (e.g. time/location), further data can be collected (e.g. sea depth, weather, etc.).
A cron job (a service that starts after a certain time) is used to check new sightings and query additional data using the provider's API. This data is saved in an extra table with a reference to the sighting.
M.E.E.R. e.V. has several instances of MWPA Server (backend and database) to record sightings:
Main: In the main instance, the guides record the sightings which are later used for evaluation/exports etc.
Courses: A separate database was created specifically for the practical courses. Participants can practice data collection here in parallel and later compare it with the main MWPA.
Demo: This instance is used to check the app without the data from M.E.E.R. e.V. to release. This is an important part so that Google can test the app so that it can later publish the app in the app store.
Dev: A version that is located locally on the developer's computer. This is where errors are checked, or new functions are implemented and tested.
The development of the software is one of many projects at M.E.E.R e.V. Short, clear communication channels provide quick opportunities for action for requests for new functions or for reporting errors. The tasks are recorded in GitHub in a weekly meeting (with Tina and more and more Rolf) about requirements and problems.
If there is a problem on the boat, Rolf gets feedback from the guide (end user). Rolf (from Oceano) passes on problems and questions to Tina & Stefan. Tina and Stefan discuss the requirements/data and further development of MWPA. Inquiries from Fabian/M.E.E.R. team will also be discussed additionally (new requirements).
Tina tests the new versions of MWPA and gives feedback on errors that are then corrected by Stefan. Then there is another test run. Once the errors have been fixed, the version can be released. The new version is then installed on the tablet with Rolf. Innovations are then discussed together (user handling).
