Flux Cirkwi : évolutions à venir

babastienne commented 4 months ago

Le département 62 a financé le développement d'évolutions relatives à Cirkwi et Geotrek.

Le CD62 exporte déjà certaines données vers Cirkwi. Toutefois, il souhaite également importer des itinéraires et POI provenant de Cirkwi dans Geotrek (mode sans segmentation dynamique).

Les développements à venir seront donc les suivants :

Ajout d'un parser permettant d'intégrer dans Geotrek des itinéraires provenant de Cirkwi (mode NDS only). Modèle du flux utilisé
Ajout d'un parser permettant d'intégrer dans Geotrek les POI provenant de Cirkwi. Modèle du flux
Ajout d'un filtre sur l'API Cirkwi de Geotrek, qui permettra de choisir si on souhaite filtrer les données afin de ne pas renvoyer les itinéraires ou POI qui proviennent d'autres flux. Concrètement une méthode regardera pour les modèles si les objets ont des eid et si oui le filtre ne renverra pas les données, afin d'éviter des boucles d'import infinies.

Les développements ont étés spécifiés en accord avec Cirkwi et devraient démarrer dans les prochaines semaines.

camillemonchicourt commented 4 months ago

OK intéressant.

Pour ne pas renvoyer à Cirkwi les données reçues de Cirkwi ne faudrait-il pas plutôt utiliser le champs "provider" plus générique, précis et fiable ?

babastienne commented 4 months ago

L'idée du filtre était aussi d'alléger le contenu des réponses du serveur pour avoir moins de résultats et pas renvoyer des itinéraires complets qui ne seront pas exploités.

C'était un choix de développement : soit on continue d'envoyer de grosses requêtes en ajoutant en plus du reste le contenu du champ provider, soit on pré-filtre en limitant les résultats. Ca aurait été sur une autre API j'aurai plutôt dis non mais là comme dans tous les cas c'est une API spécifique pour Cirkwi ça ne me choque pas d'ajouter ce comportement.

camillemonchicourt commented 4 months ago

Oui je parlais d'ajouter un filtre par "Provider", pas de retourner tout et de filtrer après.

Mais là il faudrait exclure un Provider donc certainement plus complexe.

Je me demandais juste si il ne pourrait pas y avoir des contenus ayant un EID mais venant d'ailleurs que Cirkwi et qu'on voudrait donc leur envoyer, mais peut-être que ce n'est pas le cas dans votre contexte.

Selon moi exclure un Provider serait plus propre et plus solide mais peut-être plus complexe et pas utile dans votre contexte.

babastienne commented 4 months ago

Ah oui ok je comprends mieux. Pertinent en effet, à réfléchir. Avoir la possibilité peut-être de paramétrer dans le custom.py un ou plusieurs providers qui serviraient de filtres ajoute une plus grande personnalisation, mais à voir en terme de complexité aussi.

Là l'usage qui avait été identifié c'était de ne retourner aucun contenu venant d'une source externe (cirkwi mais potentiellement aussi apidae, tourinsoft, etc.) pour ne conserver que les contenus d'origine Geotrek mais peut-être qu'on pourrait rendre le développement plus générique. J'essayerai d'en discuter avec cirkwi pour voir s'ils imaginent des cas d'usages où ils seraient intéressés pour récupérer des contenus venant d'autres sources ou s'ils ont déjà des passerelles avec ces sources.

camillemonchicourt commented 3 months ago

Filtre ?include_externals=false ajouté à l'API Cirkwi dans la version 2.102.2.

GeotrekCE / Geotrek-admin

Flux Cirkwi : évolutions à venir #3947