ref_geo optionnel ?

[camillemonchicourt]

GeoNature-citizen peut être installé de manière autonome avec sa propre BDD ou bien dans une BDD existante, notamment une BDD GeoNature.

Dans ce cas là, il dispose déjà d'un TaxHub et d'un schéma taxonomie opérationnel mais aussi d'un schéma ref_geoopérationnel.

Est-ce que ce cas a été prévu ?

[DonovanMaillard]

Et une t_role... il faudrait éviter qu'un utilisateur de GN, dans le cas d'une instance globale, doive se créer un compte distinct pour les enquêtes participatives. (je ne sais pas si ça a été discuté ailleurs, désolé d'avance si c'est le cas!)

[camillemonchicourt]

Oui discuté ailleurs (#3) et on a décidé de ne pas créer de dépendance à UsersHub et de ne pas mélanger tous les observateurs publics, avec nos utilisateurs GeoNature. Donc géré à part.

[camillemonchicourt]

Architecture simplifiée de GN-citizen autonome :

Si GN-citizen est connecté à GeoNature, alors son schéma gnc_core peut être intégré dans la BDD GeoNature (ou pas) et les observations réalisées dans GN-citizen peuvent alimenter la synthèse de GeoNature (1 programme = 1 JDD), bénéficier de la validation, des règles de sensibilité, des exports et même de la diffusion sur GeoNature-atlas :

[lpofredc]

Oui, c'est bien le schéma du fonctionnement actuel d'un point de vue frontend.

En revanche, côté backend et bdd, il existe toujours des dépendances aux schémas taxonomie et ref_geo. Pour plus d'indépendances de GeoNature-citizen et limiter les risques liés à des évolutions futures de TaxHub et GeoNature, on pourrait;

• ne stocker que le clés primaires de taxonomie (cd_nom, id_biblistes, etc.) et éliminer les références aux clés étrangères des tables du schéma taxonomie.
• Ne contenir qu'une table des municipalités dans le schema gnc_core par exemple qui permettrait récupérer l'id de la commune (code insee) sans avoir à dupliquer l'intégralité du schéma ref_geo de GeoNature, assurant ainsi une meilleure indépendance de geonature et de ses évolutions.

Il reste à mener le travail d'intégration auto à une instance GeoNature (côté bdd).

[lpofredc]

La dépendance au schéma/module ref_geo de GeoNature est un point problématique car soumis aux évolutions de GeoNature. Les communes doivent être intégrées dans gnc_core sous la forme d'une table simple t_municipalities avec a minima sa géométrie, son nom et son code insee.

[camillemonchicourt]

Le ref_geo a vocation à être autonome mais pour le moment ce n'est pas le cas.

Ça serait plus simple de ne pas dupliquer les communes mais pourquoi pas pour le moment pour faire simple.

[orovellotti]

Je pense que la bonne manière de gérer unréel découplage entre les applications c’est de mettre en place une couche de messaging/bus qui vas s’assurer de faire transiter les données d’une application vers une autres.

https://blog.xebia.fr/2015/03/09/microservices-des-architectures/

C’est un gros chantier !

Dans tous les cas répliquer les données c’est s’assurer que le découplage est possible et ça vas dans le sens d’une archi micros services.

[camillemonchicourt]

Normalement le ref_geo est totalement indépendant depuis les modifications apportées lors de cette échange : PnX-SI/GeoNature#374

Je n'ai pas non plus l'impression qu'il ait subi des modifications structurantes : https://github.com/PnX-SI/GeoNature/commits/master/data/core/ref_geo.sql

Pour l'intégrer dans une autre BDD, on peut utiliser cette partie de script : https://github.com/PnX-SI/GeoNature/blob/master/install/install_db.sh#L274-L386

A terme, il est censé avoir son propre dépôt et script de déploiement.

[lpofredc]

A priori, ça daterai d'un commit de @amandine-sahl, en septembre dernier.
PnX-SI/GeoNature@3ad8d9a

Beaucoup de nouveaux champs dans la table municipalités. Sauf si des besoins plus poussés devaient advenir (zonages autres que communes comme mailles, epci voire espaces naturels ou entité écopaysagère), je serai pour une intégration d'une table des municipalités dans le coeur de gncitizen.

[camillemonchicourt]

Non ça c'est un commit de nettoyage entre la V1 et la V2.
Le ref_geo n'a pas particulièrement changé depuis sa mise en place dans GeoNature V2 en août 2017.
On a une table l_areas de base et éventuellement une extension pour des infos complémentaires et spécifiques comme li_grids pour les mailles et li_municipalities pour les communes.
Détail ici : PnX-SI/GeoNature#245

Pour ceux qui utilisent le ref_geo ou GeoNature, c'est dommage d'imposer de dupliquer une table des communes. Donc je serais resté sur cette base.
Sinon ce qu'on est en train de faire dans GeoNature-atlas, se baser sur une vue des communes, qui tape soit directement sur une table commune, soit sur le ref_geo.

[samuelpriou]

Au final quelle solution préconisez vous de retenir ?
Merci

[lpofredc]

On conserve la structure ref_geo de GeoNature ( mettre à jour pour une correpondance de tous les champs de li_municipalities) en veillant bien à maintenir la compatibilité avec le ref_geo (informations en cas de modif de GeoNature).

[samuelpriou]

Ok. Merci !