API v2 - Lien inexistant entre POI et itinéraires lorsque la segmentation dynamique est désactivée

[IdrissaD]

Lorsque je désactive la segmentation dynamique avec le paramètre TREKKING_TOPOLOGY_ENABLED = False, j'ai l'impression que cela empêche les POI de remonter dans l'API v2 avec les itinéraires.
Dans l'interface web de Geotrek-admin, le rapprochement par distance entre les géométries des POI et des itinéraires se fait parfaitement, et les objets liés sont visibles lorsqu'on ouvre un itinéraire ou un POI.
Par contre, avec les mêmes données et pour le même Geotrek-admin, un Geotrek-rando v3 ne remonte aucun POI pour aucun des itinéraires.

Exemple :
Itinéraire Aire-de-Côte sur GTR v3 : https://gag-demo-rando.cevennes-parcnational.net/trek/87185-Aire-de-Cote
Itinéraire Aire-de-Côte sur GA :

POI mentionnés ci-dessus dans l'API v2 :

• https://gag-demo.cevennes-parcnational.net/api/v2/poi/86794/
• https://gag-demo.cevennes-parcnational.net/api/v2/poi/86795/
• https://gag-demo.cevennes-parcnational.net/api/v2/poi/86796/
• https://gag-demo.cevennes-parcnational.net/api/v2/poi/86797/

Je n'arrive pas à trouver précisément où le problème survient, mais j'ai l'impression en regardant les fichiers

Geotrek-admin/geotrek/api/v2/filters.py

Line 204 in c5aba15

class GeotrekPOIFilter(BaseFilterBackend):

et

Geotrek-admin/geotrek/api/tests/test_v2.py

Line 304 in c5aba15

if settings.TREKKING_TOPOLOGY_ENABLED:

que la désactivation de la segmentation dynamique n'est pas gérée partout, et peut empêcher certaines choses dans l'API.

[camillemonchicourt]

Dans le titre du ticket tu voulais plutôt dire "désactivée" ?
Pour remonter les patrimoines (POI) d'une rando on utilise le trek de la route /poi.

Exemple pour la rando 2 (https://gtr3demo.ecrins-parcnational.fr/trek/2-Col-de-Font-Froide) : https://geotrekdemo.ecrins-parcnational.fr/api/v2/poi/?trek=2

Et en effet on n'a certainement pas pris en compte le cas où la segmentation dynamique est désactivée car l'usage n'était pas prévu.

Mais ça serait une évolution à faire.

Sinon sur la route des POI, il y a aussi le filtre near_trek qui permet de renvoyer les POI à proximité géographique d'un itinéraire par buffer, et non pas par segmentation dynamique avec les tronçons en commun.

A voir si il faut garder ce filtre et l'utiliser quand la segmentation dynamique est désactivée, ou si il faut ne garder que le filtre trek et qu'il ait un fonctionnement différent en fonction du fait que la segmentation dynamique est activée ou non.

Je pencherai plutôt sur la solution 2 pour que cela soit transparent pour Geotrek-rando.

[IdrissaD]

Bien vu pour le titre !

Effectivement, quand j'essaie d'accéder aux POI par trek via l'URL https://gag-demo.cevennes-parcnational.net/api/v2/poi/?trek=87185 rien ne remonte, alors qu'avec https://gag-demo.cevennes-parcnational.net/api/v2/poi/?near_trek=87185, les POI remontent bien.

En termes de code la deuxième solution est sûrement plus simple à implémenter (c'est aussi via un buffer que le lien est créé dans Geotrek-admin si je ne me trompe pas), par contre c'est une opération beaucoup plus coûteuse, d'autant plus qu'elle est déjà effectuée dans Geotrek-admin, donc redondante. A voir si à l'usage ça ne ferait pas trop lent pour l'affichage via GR v3, certains longs itinéraires mettant déjà pas mal de temps à s'afficher.
La première solution ne nécessiterait un développement que dans l'Admin, tandis que la deuxième ne le nécessiterait que dans le Rando (avec activation de l'écoute de near_trek via un paramètre dans le fichier de configuration par exemple).
Edit : j'avais mal compris.

[camillemonchicourt]

Je n'ai pas compris :

En termes de code la deuxième solution est sûrement plus simple à implémenter (c'est aussi via un buffer que le lien est créé dans Geotrek-admin si je ne me trompe pas), par contre c'est une opération beaucoup plus coûteuse, d'autant plus qu'elle est déjà effectuée dans Geotrek-admin, donc redondante. A voir si à l'usage ça ne ferait pas trop lent pour l'affichage via GR v3, certains longs itinéraires mettant déjà pas mal de temps à s'afficher.

---

Quand je disais la deuxième solution, je parlais de ne garder que le filtre trek et qu'il utilise la segmentation dynamique quand elle est activée, ou un buffer quand elle est désactivée.
C'est bien cette solution que je voudrai privilégier pour que cela soit transparent au niveau de Geotrek-rando, voire d'autres outils se basant sur l'API.

[IdrissaD]

Ah d'accord, je pensais que tu suggérais que Geotrek-rando utilise le filtre near_trek, au temps pour moi.

[camillemonchicourt]

OK donc on est d'accord.

L'évolution qui serait à faire serait donc :

• Supprimer le filtre near_trek de la route /poi
• Faire en sorte que le filtre trek de la route /poi utilise la segmentation dynamique quand elle est activée, ou un buffer quand elle est désactivée

[IdrissaD]

Je ne sais pas s'il faut supprimer near_trek, est-ce que ce filtre n'a pas une utilité propre ?
D'ailleurs je vois que la description de ce filtre est la même que celle du filtre trek, mais en anglais, alors que le comportement et les données renvoyées ne sont pas toujours les mêmes :

[camillemonchicourt]

Le filtre near_trek est utilisé sur les autres objets, par exemple sur la route des contenus touristiques, des événements, des sites et parcours Outdoor...
Il permet de renvoyer les contenus touristiques à proximité d'une rando pour les afficher dans le bloc "A proximité" d'une fiche rando sur Geotrek-rando par exemple.
Il sera utilisé prochainement pour faire remonter de la même manière les événements, sites et parcours Outdoor à proximité d'une rando.

Pour les POI, le filtre near_trek fait un peu doublon et peut apporter de la confusion avec le filtre trek.
Même si en effet, quand la segmentation dynamique est activée, le filtre trek et le filtre near_trek sont différents. Le premier s'appuyant sur la segmentation dynamique, le second sur un buffer.

Est-ce qu'il y a un intérêt à garder le filtre near_trek par buffer, en plus du filtre trek basé sur la segmentation dynamique.
Je me pose la question. Car actuellement le filtre near_trek n'est pas utilisé et peut apporter de la confusion pour un utilisateur de l'API à savoir quel filtre il doit utiliser.

[IdrissaD]

De mon point de vue ce ticket est réglé par la #3069

[camillemonchicourt]

Oui le filtre trek de la route des POI a été revue dans la version 2.82.0, pour utiliser un buffer quand la segmentation dynamique est désactivée.
Par contre on a gardé le filtre near_trek qui est différent et potentiellement complémentaire, permettant d'utiliser un buffer, même avec la segmentation dynamique activée.

Il faudrait peut-être juste clarifier les descriptions de ces filtres dans la documentation de l'API.