Refonte technique Atlas - Suppression VM - Récupération des données via API

[Adrien-Pajot]

Bonjour à tous,

Bien que le sujet soit dans les cartons depuis longtemps, celui-ci est de plus en plus discuté récemment : repenser l'Atlas pour que les données ne soient pas récupérées via des VM mais via des API de GeoNature.

Contexte : historiquement les VM ont été créées afin de faire un tampon entre une base de données contenant des données d'observations et l'Atlas. Cette base pouvant être autre qu'un GeoNature. Dans la pratique, ce tampon, fonctionnel, permet à deux structures identifiées parmi les plusieurs dizaines qui utilisent l'atlas de fonctionner avec une autre base qu'un GeoNature. Un avantage qui s'accompagne aussi d'une lourdeur et de difficultés à l'installation de la base de l'atlas.

L'idée proposée, créant une dépendance à GeoNature ou à la nécessité de savoir mettre à disposition une API depuis son outil de gestion des données, permettrait un allègement de l'installation et s'accompagnerait :

• du développement de l'API GeoNature mettant à disposition les données déjà utilisées par GeoNature
• d'une couverture de test sur cette API afin d'éviter de casser l'Atlas quand GeoNature est touché
• de réflexion sur les informations pré-calculées (synthèse par maille, etc.) produites par l'Atlas

Ce ticket ouvert doit permettre une discussion sur les éléments à prendre en compte.

Actuellement, et dans le cadre du développement d'un module observatoire par Natural Solutions (#323) qui pourrait être lié à celui d'un système de recherche avancé (#313), cette interaction avec l'API de GeoNature est envisagée et pourrait faire office d'un début de structuration.

N'hésitez pas à partager vos retours.

[DonovanMaillard]

Est-ce qu'il serait pertinent de réfléchir à ces questions en parallèle des développements de GN2PG ?

On pourrait imaginer que l'atlas se base toujours sur une table distante ou d'une VM,mais qui puisse etre alimentée via GN2PG à l'aide des API du module d'export ? Ca permettrait à la fois d'utiliserles API de geonature et s'épargner les FDW quand on est dans un contexte "tout geonature". Mais de pouvoir utiliser cette solution quand on veut utiliser une autre source ?

C'est davantage une question qu'un souhait, mais mettre les 2 sujets en parallèle pourrait apporter des pistes

[gildeluermoz]

Le sujet est intéressant. Certaines structures ont le besoin de publier un atlas de leur territoire mais elles ne sont pas productrices de données. Une grosse commune par exemple, une agglo ou pourquoi pas un département. Les sources de données sont donc multiples et l'enjeu est alors d'alimenter l'atlas depuis plusieurs sources en organisant des flux.

De mon point de vue, peut-être déjà un peu trop lointain ;) le sujet me fait penser aux outils de métadonnées qui disposent d'un système de moissonnage de sources diverses. Le fonctionnement de ce moissonnage repose sur une norme ou un standard (dans le cas des métadonnées). Le standard SINP occurence de taxon a permis de grosses avancées en terme de partage et de structuration des données naturalistes. Créer un stantdard "geonature-atlas" (bcp plus basique que occurence de taxon) pourrait être une première étape pour permettre à GeoNature de l'exposer sous forme d'API et à l'atlas de le consommer/moissoner. L'intérêt serait évidement de pourvoir moissonner pls sources.

Sauf à ce que qq chose m'échappe, il ne me semble pas que cette approche rende l'atlas totalement dépendant de GN. L'atlas devrait garder SA propre base de données et le moissonnage d'API serait juste une source supplémentaire et optionnelle pour l'alimenter. Cette approche me parait plus souple. Mais tu cherches peut-être à supprimer totalement la base de l'atlas pour que l'atlas ne repose que sur GeoNature. Si c'est l'idée, elle est discutable car dans le contexte cité en introduction, le but serait que la struture en question ne dispose que d'un atlas mais pas de GeoNature (même si on peut toujours envisager d'installer la base de GN uniquement pour l'atlas). A noter que l'identifiant unique sera un sujet important dans un contexte multisourcé.