Homogénéiser et clarifier les filtres "trek" et "near_trek"

[marcantoinedupre]

Les filtres "trek" et "near_trek" présents sur plusieurs endpoints de l'API v2 permettent de sélectionner uniquement les entités (points d'intérêt, zones sensibles, contenu touristique, etc) présentes à proximité d'un itinéraire donné.

Ce qui nécessite une clarification est que ces deux filtres font sensiblement la même chose (mais pas exactement) et sont tous les deux présents sur certains endpoints (ce qui est confusant, lequel utiliser ?).

Ticket parent #3398.

[marcantoinedupre]

Voici un tableau récapitulatif de l'état actuel de l'implémentation de ces filtres avec des pistes d'actions.
filters_state_table.ods

[marcantoinedupre]

Ma proposition est de faire exactement le même traitement pour "trek" et "near_trek" et de marquer l'un des deux paramètres comme obsolète dans la doc de l'API.

[marcantoinedupre]

Suite à un point avec @camillemonchicourt et @submarcos la proposition d'unifier le traitement de "trek" et "near_trek" et de marquer "trek" comme obsolète est validée.

Pour guider le dev sur les filtres "near" de l'API, l'objectif long-terme est que les entités liées filtrées sur l'API soient les mêmes que celles affichées dans le Geotrek Admin.

Autres points abordés :

• L'important gain en terme de performance obtenu pour les zones sensibles en pré-calculant le "buffer d'intersection" ne peut pas être reproduit pour les autres entités car les proximités dépendent de multiples paramètres distances/margins (distances d'intersection définies par types de pratique et paramètres intersection_margins définis dans la configuration).
• Pour les entités non-topologiques on conserve le fonctionnement actuel basé sur ST_DWITHIN/INTERSECTS avec les différents paramètres de distance ("margins"). On s'est dit qu'il serait souhaitable de faire un état des lieux de ces paramètres de distance/margin et des parties de Geotrek Admin où ils sont utilisés.
• Dans le code Geotrek Admin on utilise alternativement à ST_DWITHIN la création d'un buffer dynamique basé sur une distance à un objet suivie d'une intersection. Les 2 techniques sont relativement égales en terme de performance, on laisse tel quel.

ping @amandine-sahl

[camillemonchicourt]

Dans un premier temps, on va faire en sorte d'utiliser les topologies (et non plus des ST_Dwithin) sur les objets où elles sont disponibles (POI, aménagements, signalétique, itinéraires et services) et quand la segmentation dynamique est activée, pour gagner en performances et en cohérence.

[marcantoinedupre]

Concernant la clarification des filtres "near" de l'API je suis en train de faire en sorte que les filtres "near" de l'API utilisent le même code de filtre de proximité que l'interface utilisateur de geotrek-admin. Je rencontre 2 problèmes :

• que faire pour les Lieux de renseignements qui sont associés explicitement par une relation avec les Itinéraires et les Sites outdoor ? Dans l'objectif d'avoir qqchose d'identique entre randov3 et l'admin il faut utiliser la relation mais ça ne colle pas trop avec le terme "near" pour le filtre. J'implémente tout de même cette approche pour le moment.
• Le code de proximité côté interface utilisateur de geotrek-admin est absent dans le cas des Lieux d'événement touristique et des Lieux d'information puisque l'admin n'affiche pas de liens de proximité pour ces entités dans les pages détails. Je vais l'ajouter.

[camillemonchicourt]

OK merci.
Il faut aussi vérifier ce qui est utilisé par Geotrek-rando-v3 pour pas qu'il y ait de breaking change. Ou alors bien les anticiper et les indiquer.

[marcantoinedupre]

Je ne prévois pas de breaking changes au niveau de l'ensemble de l'API même si, comme nous l'avions évoqué, les filtres pourront retourner des résultats différents (ce qui est attendu : si dans le cas d'un objet topologique on détermine les objets liés par le réseau de tronçons alors qu'avant c'était avec un calcul de distance, les résultats peuvent changer).

[marcantoinedupre]

Finalement il a été décidé de retirer les filtres "near" des endoints pour lister les Lieux de renseignement et les Lieux d'événement touristique.

[marcantoinedupre]

PR draft créée