[Question] Filtrer les secteurs par portails

[mviadere-openig]

Question de la part d'un utilisateur : est-il possible de filtrer les secteurs par portails ?

N'ayant rien trouvé dans la doc ni sur l'admin, je pose la question ici pour savoir si c'est possible sur la dernière version de Geotrek-Admin où si il y a des développements à faire ?

[camillemonchicourt]

Salut, non on ne le fait pas actuellement, mais c'est volontaire en l'état.
Ce n'est pas idéal car cela amène à renvoyer à l'API et donc à Geotrek-rando-v3 potentiellement des communes et secteurs qui n'ont aucun contenu associé.

On le fait sur les listes de typologies (pratiques, niveaux de difficulté, types de parcours, catégories de contenus touristiques, thèmes...) mais c'est déjà un peu lourd, car il faut comparer dynamiquement ces typologies aux objets publiés pour le portail concerné.

Mais pour faire pareil sur les communes et les secteurs, le calcul est encore plus lourd, vu qu'il faut INTERSECTER géographiquement la géométrie des objets publiés pour le portail concerné avec la géométrie des communes et des secteurs. Et il faut au préalable agréger les géométries des différentes catégories d'objets (randos, sites Outdoor, contenus et événements touristiques) car on peut avoir des contenus touristiques dans une commune mais pas de rando et inversement. Donc il faut bien intersecter avec toutes les catégories d'objets publiés sur le portail.
On imagine bien qu'une telle agrégation puis intersection géographique peut être assez longue, ce qui alourdirait considérablement le chargement des pages dans Geotrek-rando-v3, si on doit relancer le calcul à chaque interrogation de l'API.

Vu qu'on travaille actuellement sur la mise en place de cache au niveau de l'API (GeotrekCE/Geotrek-rando-v3#753 (comment)), on peut imaginer que cela permette de ne pas refaire ce calcul à chaque appel.
Une autre piste serait que les intersections entre les objets et les zonages soient stockés dans une table pour ne pas être calculés dynamiquement à chaque fois.

Sans au moins un de ces éléments, je pense qu'en l'état ce sera trop lourd de filtrer les communes et secteurs par portail.

[mviadere-openig]

Merci pour ce retour, je vais donc attendre les futurs développements de Geotrek.

[babastienne]

@camillemonchicourt pourquoi ne pas faire plus simple ? En fait c'est un besoin qui revient souvent d'avoir un nombre de communes / secteurs limités par portail, globalement tous les territoires qui ont plusieurs portails j'ai l'impression.

Pourquoi ne pas juste ajouter un champ "portail" sur les objets 'City' et 'District' et ensuite l'API remonte uniquement les objets rattachés au portail ? Ensuite sur les fiches détail des itinéraires ou autres objets dans la liste des communes traversées ont exclu celles qui ne sont pas liées au portail correspondant à la requête.

C'est pas parfait puisqu'on pourra toujours avoir des communes remontées qui ne sont traversées par aucun contenu mais au moins les territoires auront la main pour savoir quelles sont les communes et secteurs remontés sur leur portail.

Qu'en penses-tu ?

[camillemonchicourt]

C'est dommage que cela ne soit pas dynamique et qu'il faille aller saisir ça manuellement. Tout le monde va devoir aller associer ses communes à son (ses) portails, ce qui est un peu lourdingue et peu compréhensible/intuitif.
Et si j'ajoute une rando sur une nouvelle commune, il faut penser à aller associer son portail à cette nouvelle commune...
Bof bof...

L'idéal était le fonctionnement qu'on avait avant où les communes associées aux objets étaient stockés dans la BDD pour ne pas avoir à faire des intersections géographiques à la volée.

[babastienne]

Je me dis que c'est un compromis, l'idée n'était pas forcément de mettre à jour la liste des communes à chaque fois qu'on rajoute une nouvelle rando, mais au moins de proposer une liste plus cohérente pour le portail en question, qui corresponde au périmètre géographique du territoire.

Ca sera pas parfait mais un compromis, non ?

[camillemonchicourt]

C'esr dommage d'avoir une BDD géographique et de devoir dire manuellement quelles communes on veut pour des objets qui sont géoréférencés.

Je me demande si ce n'est pas plus pénible de devoir associer les communes à des portails et maintenir ça à jour, plutôt que d'avoir la liste de toutes les communes...

On pourrait aussi imaginer passer par la liste des randos qui inclut la liste des communes traversées par ces randos, même si c'est un peu tordu.

De mémoire historiquement on stockait en topologique les communes et zonages intersectant chaque objet, justement pour ne pas avoir à recalculer ça dynamiquement à la volée par intersection géographique.
Cela a été enlevé je ne sais pour quelle raison.

[babastienne]

Après discussion aujourd'hui on estime qu'il faudrait rattacher aux objets suivants une information sur les communes traversées :

• Itinéraires
• Sites et Parcours outdoor
• Contenus Touristiques
• Evènements Touristiques

A chaque création / modification d'un objet, on calculerai la liste des communes traversées qui serait stockées dans une table servant de many2many.

A noter que cette table permettra de retrouver la liste des communes traversées dans l'ordre y compris si on passe plusieurs fois par la commune (donc on accepte un doublon de commune car ça permettrai aussi de pouvoir retrouver la commune de fin d'un itinéraire).

Ensuite côté API :

• Si la requête vers /city est effectuée sans paramètre portal alors on renvoi tout, comme actuellement
• Si la requête vers /city est effectuée avec paramètre portal alors on récupère l'ensemble des itinéraires / outdoor / services / évènements publiés et on agrège toutes les communes traversées. Ca sera un peu plus long qu'actuellement mais pas tant que ça car aucun calcul d'intersection.

A traiter en vrac :

• Modification du modèle de données
• Développer la migration des données existantes pour peupler les tables
• Tests unitaires à réaliser. En couvrant des cas de traversées / boucles / aller-retour.
• Faire la même chose avec les secteurs

Nous estimons de notre côté le travail nécéssaire à 3-4 semaines pour développer cette solution

[camillemonchicourt]

Si on le fait sur les itinéraires alors j'aurai tendance à dire qu'il faut directement le faire sur toutes les topologies.
Car cette table de calcul et stockage des intersections pourrait servir plus globalement quand on recherche des objets dans une commune.
A voir si il faut limiter aux communes et secteurs ou aussi prendre en compte les zonages.

Dans tous les cas, il faudrait lancer ce calcul avec un trigger pour que la table soit bien peuplée et à jour dans tous les cas.

En fait, initialement on avait bien ce mécanisme et on stockait les intersections avec les zonages de toutes les intersections, mais ça a été retiré pour une raison que j'ignore.
Le seul petit défaut que je vois à stocker les intersections est la volumétrie que cela représente, mais cela reste des données nombreuses mais peu volumineuses chacunes.

Pour la route /city, je ne sais pas si il faut diverger des autres routes et tout renvoyer quand on ne passe pas de portail, mais plutôt renvoyer les communes associées à au moins un objet publié, pour être homogène avec les autres routes. 🤔