[Import module] Point d'information
Versions actuellement utilisées :
Problématique
Les années 2010 ont été marquées par l’apparition des détecteurs automatiques (enregistrement automatique des cris émis par les CS). Par la suite, des logiciels d’identification automatique ont été développés pour identifier les espèces à partir de ses enregistrements, par méthode statistique, générant de grandes quantité de données au format CSV.
Cette pratique s’étant largement répandue, il est maintenant nécessaire de développer un module d’import de ces données pour l’application dbChiro.
La donnée est structurée dans différentes tables:
- Métasites : Regroupement de localités (Niveau optionnel)
- Localités : localisation géographique des échantillonnages
- Sessions: Une date / Une méthode (session acoustique vs capture) sur une localité
- Espèces : Une espèce sur une session
- Dénombrement: Comptage détaillé par espèces (par sexe, par tranches horaires, etc.)
- Espèces : Une espèce sur une session
- Sessions: Une date / Une méthode (session acoustique vs capture) sur une localité
- Localités : localisation géographique des échantillonnages
Un MCD de la base de donnée est visible ici: https://framagit.org/dbchiro/dbchiroweb/-/blob/develop/model.png
Et ici une version focalisée sur le module observations sights
: https://framagit.org/dbchiro/dbchiroweb/-/raw/develop/sights.png
Attentes
Base de donnée
PostgreSQL/PostGIS: compatible avec PostgreSQL 14 / PostGIS 3.
A ce jour, aucune intervention en bdd n'est requise ni souhaitée, tout est géré par l'ORM de Django.
Backend
Django 3.2 (LTS).
API Rest développées avec le module django-rest-framework
.
Détail des dépendances dans le fichier pyproject.toml
Frontend
Actuellement, le frontend est généré par le moteur de rendu de Django.
Une migration progressive vers une architecture REST est en cours pour a terme passer sur un frontend distinct développé avec NuxtJS (Framework basé sur VueJS) et permettre l'intéropérabilité et le développement d'une application mobile.
Tous les nouveaux développements sont maintenant à développer en API REST et un frontend en VueJS. Les fonctionnalités javascript de l'application sont développées dans le fichier core/static/js/app.js.
Les principales dépendances du frontend sont:
- Bootstrap 3.4
- Leaflet 1.7
- VueJS 2.7
Un exemple d'implantation basé sur le moteur de rendu Django / VueJS:
-
L'API pour générer la liste en JSON: https://framagit.org/dbchiro/dbchiroweb/-/blob/develop/accounts/api.py#L69-L96
-
La vue Django pour générer la page: https://framagit.org/dbchiro/dbchiroweb/-/blob/develop/accounts/views.py#L263
-
Le template de rendu html, les doubles moustaches généralement utilisées dans VueJS sont utilisées par le moteur de rendu de Django, elles sont donc remplacées par
[[...]]
: https://framagit.org/dbchiro/dbchiroweb/-/blob/develop/accounts/templates/user_list.html -
La fonction JS/VueJS
UserListApp
: https://framagit.org/dbchiro/dbchiroweb/-/blob/develop/core/static/js/app.js#L3075-L3163
Module d'import
Le module doit être développé en tant que nouvelle application Django via la commande startapp
(cf. doc Django)
La communication entre le frontend et le backend se fera par API REST.
Les fonctionnalités du frontend seront développées en javascript avec VueJS sur le même principe que ce qui est fait actuellement.
Tous les fichiers du module seront dans son propre dossier : Voici un exemple d'architecture de module import
Django:
dbchiroweb/
├── dbchiro/
│ ├── __init__.py
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
|
├── imports
| ├── templates
| | ├── template1.html
| | └── template2.html
| ├── static
| | └── app.js
| ├── __init__.py
| ├── admin.py
| ├── api.py
| ├── app.py
| ├── models.py
| ├── serializers.py
| ├── urls.py
| ├── <others>.py
| └── views.py
|
├── sights
| ├── ...
| └── ...
|
└── manage.py
3 étapes:
Sprint 1 (16-20 mai): import d'un échantillon propre et valide (16/05 > 20/05)
Objectif
Développer un module d'import capable d'importer un échantillon standardisé et valide sur la base d'un échantillon fourni (environ 10000 lignes)
- Liste des champs prioritaires à définir (cf. #69)
- Import des données en base de donnée via l'interface Web de dbChiroWeb (cf. #71)
- Génération d'un rapport d'import précisant l'état de l'import, le statut (succès, échec (causes détaillées)) (cf. #72)
Sprint 3 (07/06 > 13/06)
Objectif
Ajout de fonctionnalités de validation des données
- Vérification de l'intégrité des données et de la bonne correspondance des valeurs fournies avec celle de l'application
- Pour les localités, faire un travail de vérification des localités existantes.
- En étape préalable, par localité identifiée dans la source, on liste les localités les plus proches de l'application (par distance croissante) pour un rattachement des données aux localités de la bdd. Et on propose aussi de créer une nouvelle localité.
Sprint 3 (14/06 > 23/06)
Objectif
Imports de sources hétérogènes
- A l'import d'un fichier, demander à l'utilisateur de faire la mise en correspondance des champs/valeurs du fichier source avec ceux de l'application.
- Offrir la possibilité d'enregistrer le gabarit de mise en correspondance pour un usage ultérieur.
- L'import standard préalablement développé passera également par ce process dans un gabarit fourni par défaut.