Itinérance / Détail des points de référence

[irisinteractive]

Bonjour à tous,

IRIS Interactive est une agence web spécialisée dans le domaine du tourisme. La plupart de nos clients nous demande de connecter leur site de destination avec des SIT tel que Tourinsoft, APIDAE, Cirkwi, Geotrek… Nous avons donc développé des connecteurs qui permettent d’importer cette donnée au sein du site.

Sur les projets en exemple ci-dessous, nous avons été en mesure de réaliser un bloc fonctionnel type "parcours" :

• TOURINSOFT : https://www.destination-fougeres.bzh/randonnee/circuit-de-lepinay/
• TOURINSOFT : https://www.tourisme-corbieres-minervois.com/balades-et-randonnees/au-milobre-de-massac/
• CIRKWI : https://www.bastides-gorges-aveyron.fr/randonnee/petit-tour-vers-toulongergues-saint-remy/ 

Nous souhaiterions réaliser ce même travail pour nos clients ayant de la donnée itinéraire sous Geotrek : https://www.ardennes.com/randonnee/boucle-de-la-chambre-aux-loups/  Cependant aujourd’hui avec les flux de donnée que nous avons (cf. captures), il est impossible de réaliser ce travail. D’une part, les champs description et étapes sont décorrélés, d’autre part, les données dans le champ description arrivent sans séparateur ce qui rend la manipulation difficile.

Notre demande aujourd’hui est de savoir si vous envisagez une évolution qui permettrait de lier des données de localisation avec une description (voir titre et image) pour reproduire cette brique fonctionnelle « parcours ».

Merci par avance :).

---

[camillemonchicourt]

Bonjour,

En effet actuellement on a un seul champs texte unique pour la description du parcours pas à pas. Et par ailleurs, on peut localiser sur la carte des points de référence auxquels on peut faire référence dans le texte, mais basiquement avec une liste numérotée directement dans le texte :

Donc, en effet, on n'a pas d'infos séparées actuellement du texte correspondant à chaque point de référence.

Ce n'est planifié ni financé actuellement de le faire, mais ce serait intéressant de le faire, d'autant que d'autres avant vous ont eu le même soucis en récupérant les randos à partir de la route /trek de l'API de Geotrek-admin.

C'est le cas par exemple de Visorando, qui a besoin des points de référence du pas à pas, dissociés. Actuellement, ils parcourent le texte brut et les listes numérotées pour éclater les infos des points de référence, mais c'est pas idéal.

Idem pour IGNrando qui récupère les randos depuis l'API Geotrek-admin et pourrait avoir besoin des points de référence séparés : https://ignrando.fr/fr/parcours/26440-le-circuit-des-lacs

Donc évolution intéressante et envisageable, mais non planifiée ni financée actuellement.

[irisinteractive]

Merci pour votre retour rapide !

Actuellement, ils parcourent le texte brut et les listes numérotées pour éclater les infos des points de référence, mais c'est pas idéal.

=> C'est exactement la raison de notre demande.

Vous dites que l'évolution est "intéressante et envisageable, mais non planifiée ni financée actuellement", quelle serait la marche à suivre pour justement passer à la suite :) ?

[camillemonchicourt]

Vous dites que l'évolution est "intéressante et envisageable, mais non planifiée ni financée actuellement", quelle serait la marche à suivre pour justement passer à la suite :) ?

Il faudrait étudier le sujet techniquement et fonctionnellement un plus en détail. Mais aussi analyser les conséquences de ces évolutions, notamment en terme de récupération et de migration des données existantes.

Une fois cela identifié et partagé, il faudra développer ces évolutions, soit directement, soit auprès d'un prestataire en mesure de le faire.

[babastienne]

@camillemonchicourt nous avons échangé hier avec @irisinteractive justement sur ce sujet, d'où l'ouverture de ce ticket.

Côté Makina Corpus nous allons tenter d'analyser ce sujet techniquement la semaine prochaine.

Comme ça je pense à plusieurs éléments déjà :

• Si on choisi de modifier la structure de l'API pour renvoyer des éléments qui associent Point de référence et description, quid du breaking change ? faut-il assurer une rétrocompatibilité et donc juste ajouter un nouveau "champ" dans l'API ?
• Si breaking change, comment répercuter côté Geotrek-Rando V3 ? -> devs supplémentaires ?
• Est-ce que cette modification doit s'accompagner d'une modification côté interface admin ? Je m'explique : si on choisit de lier les points de référence et les descriptions dans l'API, faut-il obliger l'utilisateur à avoir une saisie "contrôlée" dans l'interface de Geotrek-Admin ? Car aujourd'hui rien n'empêche un utilisateur de saisir 8 points d'informations sur la carte et aucune liste numérotée dans la description (ou alors une liste avec 5 éléments, ou 12). -> quid de l'API dans ce contexte ?

En fait ça soulève une questions plus générale : faut-il revoir entièrement le mécanisme de saisie des points de référence dans Geotrek-Admin ? Car si on continue en l'état (avec une saisie dans la description et sur la carte qui sont décorrélées), alors ajouter des modifications dans l'API uniquement reviendrait côté Geotrek-Rando à faire un parsing de la description (= la solution pas top que fait visorando, donc bof). Si on choisi de revoir ce mécanisme lequel adopter ? tu as une idée sur le sujet ? Et ensuite en effet si on modifie notre mécanisme il faudrait penser à la migration des données actuelles.

[irisinteractive]

@babastienne, on vous laisse avancer sur ce sujet de votre côté et revenir vers nous ;).
On reste à disposition au besoin.

Merci par avance.

[babastienne]

Quelques note sur ce qu'il faudrait mettre en place pour implémenter cette fonctionnalité :

• Un modèle ReferencePoint avec geom description order -> lié aux itinéraires en onetomany

• Formulaire dynamique qui rajoute le champ texte pour la description associée au point au moment où on l'ajoute sur la carte

• La sérialisation dans APIv2 doit être retrocompatible (un champ 'reference_points' en MultiPoint)

Dans un langage plus clair : Il faudrait pouvoir modifier l'API en assurant une rétro-compatibilité. Cela signifie qu'un nouveau champ devrait être ajouté dans l'API, et proposer un multipoint avec descriptions associées. Le fonctionnement actuel sera conservé en parallèle pour assurer la compatibilité. Côté base de données, pour éviter que Geotrek ne fasse le calcul de parsing des informations, il faudrait faire une modification du modèle pour avoir une nouvelle classe en base de données qui serait en relation avec les itinéraires (et les autres objets comme les parcours outdoor ?) : cette classe serait peuplée des données déjà existantes, il faudra donc anticiper une migration de données dans les bases Geotrek déjà existantes. Ensuite côté interface de saisie dans Geotrek, il faut pouvoir modifier le comportement. Il faut imaginer pouvoir saisir un point sur la carte et cela créé un champ à remplir dans le volet latéral pour permettre d'associer la description. Il s'agira donc de faire un formulaire généré dynamiquement en fonction des points saisis sur la carte. Plusieurs réflexions devront être menées pour prendre en compte les cas limites (que ce passe-t-il si on supprime le point de référence 3/5, comment vont réagir les autres, faut-il les décrémenter, autorise-t-on les descriptions vides associées aux points, y a t-il une limite de points de référence, une limite de caractères dans les descriptions associées, etc.).

A terme (horizon plus lointain), il faudra modifier GTR3 pour qu'il utilise ce nouveau endpoint d'API.

[camillemonchicourt]

En effet, en y réfléchissant rapidement, je n'avais pas envisagé d'autres pistes que d'ajouter un champs texte, en plus du champs géométrie dans la table des points de référence. Mais :

• Il n'y a pas de table des points de référence. C'est uniquement un champs de type géométrie nommé points_reference, dans la table trekking_trek qui contient des géométries de type multipoints.
• Il y a potentiellement des pistes intermédiaires plus simples comme tu évoques
• Quand on a une liste numérotée dans la description, correspondant à des points de référence localisés sur la carte, on a quasiment tout le temps du texte avant, et parfois du texte après. Donc si on extrait et sépare les descriptions des points de référence, ça sera pas évident de remettre correctement du texte, avant et/ou après. Exemples :

Donc si on voulait faire la solution complète et globale que je propose, il faudrait :

• Créer une vraie table des points de référence avec un champs géométrie, un champs description, un champs ordre et un champs clé étrangère id_trek
• Faire une migration complexe pour récupérer les points de référence actuels, simple pour leur géométrie et leur ordre, mais plus complexe pour récupérer leur texte dans le champs Description actuel
• Enlever les textes des points de référence du champs Description actuel, mais arriver à les replacer après, avant ou au milieu de la description...
• Prévoir un mécanisme ergonomique pour saisir les textes de chaque point de référence localisé, mais aussi permettre d'ajouter du texte de description générale avant et/ou après les descriptions de chaque point de référence.

Donc en effet, pas anodin et assez complexe. Et je sais pas si ça serait mieux et simple pour les utilisateurs qui saisissent, même si le mécanisme actuel des listes numérotées est assez discutable et un peu bricolage.

Mais, dans un premier temps, je serais pas contre, l'idée simple et sans grands changements, de parser le contenu de la description, si il contient une liste numérotée, la parser et l'éclater dans l'ordre pour associer le texte aux points de référence.

Donc faire uniquement un changement au niveau de l'API. Mais je sais pas si ça va plaire que dans 'API on continue à avoir la liste numérotée dans le champs description, et le détail éclaté des descriptions des points de référence dans la propriété points_reference.