Geotrek-admin
Geotrek-admin copied to clipboard
GeotrekCE
Perturbations / Fermeture de sentiers
Le sujet des fermetures temporaires de sentiers est souvent évoqué. Une fermeture de sentiers peut amener à ce que certains itinéraires ne soient pas praticables. On ne peut pas renseigner spécifiquement cette information dans Geotrek, donc certains dépublient les randos quand elles empruntent un sentier fermé, ou alors ajoutent un message temporaire dans le descriptif et/ou sur la photo principale de celui-ci.
Il est souhaité avoir une solution plus structurer et pouvant être mieux valorisée et mise en avant sur les outils de diffusion public comme Geotrek-rando.
Il a d'abord été envisagé d'ajouter un champs "Fermé (Oui / Non)" ou similaire sur les itinéraires. Mais cela serait assez lourd à renseigner sur chaque rando tout en étant peu précis sur la raison et la localisation exacte du problème. Il a ensuite été envisagé de renseigner les tronçons qui sont fermé mais la saisie et mise à jour serait lourde et fastidieuse. Sinon de travailler sur les "sentiers" mais il ne sont pas exhaustifs et là aussi on n'aurait pas la localisation précise de la perturbation.
Il est donc proposé de renseigner précisément la perturbation et d'en déduire automatiquement les itinéraires (et autres) concernés.
Pour cela, on propose d'ajouter un sous-module "Perturbations" au module "Statut". On pourrait ainsi localiser précisément la perturbation sur les tronçons, sans se soucier du nombre de tronçons (complets ou partiels) concernés, ni si il y a des sentiers ou des itinéraires. Cela permettrait aussi d'avoir une cartographie précise des portions de tronçons perturbés/fermés. Et bien sur de calculer automatiquement les itinéraires non praticables et de renvoyer cette info directement dans l'API dans la route /trek, pour pouvoir indiquer cette info précisément.
Pour bien renseigner ces perturbations, on imagine y associer ces infos :
- État (ou statut) : Fermé / Perturbé mais passage possible
- Causes : Crue / Éboulement / Passerelle emportée / Travaux / Incendie / ...
- Date début / Date fin (permettant d'anticiper des travaux de fermeture à venir, d'annoncer la potentielle date de fin quand elle est connue et de n'afficher l'info sur les perturbations que si la date de fin n'est pas encore passée)
Question naïve, mais est-ce que ce ne serait pas mieux de tracer un polygone / rond / ligne ... bref une géométrie libre (comme pour le module outdoor), plutôt que de tracer une perturbation à la manière d'un statut ? Je me dis que dans le cas d'un éboulement par exemple (ou d'une avalanche, ou autre), la zone de perturbation est plus de l'ordre d'une zone justement (polygone) que d'un linéaire, non ?
Oui ça se réfléchit mais ce qui nous intéresse c'est ce qui concerne le linéaire et les sentiers. Et on a toute la logique de segmentation dynamique et d'intersection de linéaire en place qui est idéale pour cette problématique. Ce que l'on veut ce sont les portions de tronçons perturbées et les objets liés concernés.
Selon moi, c'est le linéaire de tronçons qui sera facile et intéressant de localiser et pas un polygone.
Et ainsi on sera précis sur le linéaire concerné et les objets liés alors qu'avec un point où polygone, on ne sera pas trop comment le localiser, le dessiner et l'intersecter.
Selon moi, le module Statuts est idéal, mais à discuter.
Ok je vois. J'aimerai bien en discuter à l'occasion ouais, car là j'ai peur qu'en se basant exclusivement sur le réseau de tronçons on créé un type d'objet qui dès le début ne sera pas super compatible avec des objets comme les sites et parcours Outdoor (alors que ce sont des objets tout à fait concernés par des perturbations à mon avis).
Bonjour, Intéressé également par la fonctionnalité. Impacté par 2 tempêtes majeures en 2020 et 2023, on a eu à gérer pas mal de fermeture de sentiers, avec des prévisionnel de travaux et de réouverture à communiquer.
Je n'avais à ce moment pas eu le temps de le gérer dans Geotrek, j'ai créé un projet Umap et copiant ma base de données tronçons. (https://www.mercantour-parcnational.fr/fr/des-decouvertes/ou-sinformer/info-sentiers)
Une option pour pouvoir afficher graphiquement l'état des sentiers sous Geotrek-rando serait très utile.
Oui assez d'accord avec l'idée de pouvoir en un coup d'oeil localiser les perturbations sur une carte pour les usagers sur Geotrek-Rando.
J'ai repris connaissance du sujet en lisant les échanges précédents et je réalise que la solution basée sur les statuts ne permettra pas à tous les Geotrek sans segmentation dynamique de bénéficier de cette fonctionnalité, ce qui selon moi est problématique. Je pense qu'il faudrait trouver une autre solution plus générique. Pourquoi pas étendre le module Signalement en module "Perturbation" ? Pour pouvoir ainsi avoir lier ensuite des interventions aux perturbations, permettre aux usagers de déclarer des perturbations, étendre la diversité des géométries possibles dans ce module.
Proposition à débattre bien entendu
OK merci pour ces retours.
- Selon moi, il est important que cela puisse s'appuyer sur les tronçons et la segmentation dynamique qui apporte beaucoup d'avantage, une intersection avec tous les autres objets sur le linéaire, etc... Si on doit redessiner les portions de tronçons concernés par des fermetures, on perd tout l'intérêt de Geotrek.
- Mais je retiens surtout l'argument que cela met de côté le module OUTDOOR et c'est à bien réfléchir en effet.
- Je ne sais pas si il faut afficher les linéaires de perturbations sur Geotrek-rando, à voir, mais il faut en tout cas intersecter les perturbations avec les itinéraires pour pouvoir indiquer ceux qui sont ouverts ou non, sans ressaisir cette info au niveau de chaque itinéraire
- En tout cas, de notre côté, on a déjà imaginé pouvoir se brancher sur l'API de Geotrek-admin pour récupérer dynamiquement le GeoJSON des perturbations et l'afficher sur une petite Leaflet ou autre. Pourquoi pas aussi pouvoir faire remonter ça comme une couche annexe dans Geotrek-rando.
- En en discutant avec les collègues au PNE, pour eux le sujet central en cas de perturbations sont la planification, le suivi et l'inventaire des interventions. Et ils se voient mal aller inventorier et localiser toutes les perturbations, puis refaire le travail en saisissant ensuite toutes les interventions liées à ces perturbations. Donc il faut réfléchir l'articulation entre perturbations et interventions. Au final ils ont référencé toutes les perturbations récentes dans le module Interventions car pour eux 1 perturbation = 1 intervention à prévoir ou à réaliser
En effet, avec ces différentes questions et propositions, il faut prendre un temps pour échanger sur le sujet.
Comme évoqué, notre enjeu central est de pouvoir diffuser une carte des perturbations en cours, mais aussi de pouvoir identifier les itinéraires concernés par des perturbations et donc le remonter dans l'API (/trek/) et l'afficher sur Geotrek-rando.
Comme évoqué aussi, pour mes collègues au PNE, le sujet des perturbations est étroitement lié aux interventions. Ils ont créé des interventions (planifiées ou souhaitées) à chaque perturbation. Et ils ne se voient pas compliquer l'usage et la saisie en allant créer les perturbations dans un module à part, puis les interventions dans un autre. Une nouvelle proposition plus simple serait donc d'ajouter un champs "Sentier non praticable" (oui/non) au niveau des interventions et donc de renseigner l'info directement au niveau des interventions. Une fois l'intervention terminée, je la bascule en "Terminée", je complète ses dates, le temps agent ou les couts, et je décoche "Sentier non praticable". Pour identifier les itinéraires fermés, on identifierait les tronçons concernés par des interventions dont le champs "Sentier non praticable" est à "OUI".
Bonjour l'idée de lier les fermetures avec les perturbations me semble intéressante. Nous rencontrons également des fermetures pendant une période de nidification par exemple ou pour écobuage donc pouvoir renseigner les causes et les dates pour le grand public est nécessaire. La mise en avant par une fenêtre pop-up pourrait attirer l'attention de l'internaute à voir comment cela fonctionnerait sur smartphone avec la version responsive. C'est vrai qu'une fermeture peut concerner un itinéraire comme le module outdoor.
le sujet des perturbations est étroitement lié aux interventions
Oui, mais pas seulement. Le sujet des fermeture de sentiers devraient selon pouvoir être adressé sans avoir à forcément renseigner des interventions. Certains territoires n'utilisent que très peu les modules de gestion avancés comme le module "Intervention", et pourtant souhaitent pouvoir valoriser auprès de leurs usagers la notion de fermeture d'un sentier.
En plus cela empêche tous les territoires sans segmentation dynamique de pouvoir bénéficier d'une notion qui les concerne proutant également : avertir les visiteurs qu'un itinéraire est inaccessible.
Donc pour moi il faut quelque chose de plus simple :
- Soit on trace quelque part (dans l'admin ?) une zone qui correspond à la perturbation et tout ce qui passe dans cette zone est marqué comme "perturbé"
- Soit sur les objets de type itinéraire et outdoor il faut ajouter un champ booléen "Fermé" avec éventuellement un texte explicatif optionnel. Cette dernière solution offre aussi la possibilité pour deux itinéraires qui passent au même endroit d'en fermer un et pas l'autre (cas d'usage assez rare je pense mais qu'il pourrait être intéressant de couvrir, par exemple en fermant le sentier de randonnée familial mais en laissant ouvert l'itinéraire d'alpinisme considérant que les usagers de cette pratique sont équipés et aguerris pour passer la difficulté).
Hum hum, de notre côté :
- Si il faut saisir d'un côté les perturbations, puis de l'autre les interventions, c'est clairement redondant et bloquant
- L'enjeu est avant tout de localiser les perturbations et d'en déduire automatiquement les itinéraires non praticables, surtout pas de les saisir un par un, itinéraire par itinéraire. 🤔
Ok avec l'idée de ne pas avoir à saisir sur l'ensemble des itinéraires un par un, c'est tout à fait entendable.
Par contre un des enjeux très important (le plus important ?) c'est d'avertir les visiteurs qui consultent le Geotrek-Rando/Widget, donc que ce soit aussi une fonctionnalité utilisable sans l'aspect gestion complet avec date d'intervention et tout le workflow associé. Cela veut dire aussi proposer la fonctionnalité sans segmentation dynamique. Par conséquent je ne suis pas trop d'accord avec l'implémentation uniquement via le module intervention, ça me semble être trop complexe pour beaucoup de territoires.
Si on a un module "Perturbation" :
- L'utilisateur dans ce module trace la zone / le linéaire correspondant à la perturbation
- Par défaut la perturbation créée est au statut "ouverte"
- Ça calcul automatiquement les objets trek / outdoor qui sont rattachés par intersection et ça affiche un message d'alerte pour les visiteurs.
- Lorsque la perturbation est terminée, il suffit que l'utilisateur change son statut en "clôturée" ou la supprime et le message n'est plus affiché
Avantages : simple et pas de workflow compliqué avec des dates d'intervention ou de planification pour les territoires qui n'utilisent pas ce module ; disponible sans segmentation dynamique pour les territoires qui font uniquement de la valorisation, les agrégateurs, etc.
Pour les territoires qui souhaitent une gestion plus complete :
- Sur une perturbation qui vient d'être créée il est possible de créer une intervention associée.
- Dans ce cas on passe en mode "workflow de perturbation" et le statut de la perturbation est verrouillé car corrélé à l'intervention, ce sera mis à jour en fonction du workflow qui vous semble pertinent (date de résolution et/ou statut de l'intervention par exemple).
- Bien sur pas besoin de re-tracer la géométrie de l'intervention puisque ce sera celle de la perturbation, c'est simplement un moyen de passer dans la partie "gestion avancée" et de bénéficier des champs déjà existants sur les interventions, du lien avec les chantiers, etc.
- Ca ne me semble pas redondant mais juste la continuité de l'action. Dans ton cas pour tes gestionnaires ils n'ont qu'à créer la perturbation puis cliquer sur "Lier une intervention", ce qui revient presque même que de créer l'intervention et dessiner sa géométrie, il n'y a que deux clics à faire en plus (sauvegarder la perturbation puis créer l'intervention associée) et aucune info à saisir en double.
Bonjour à tous, je me permet de mettre un exemple d'affichage de ce que nous faisons actuellement au CD06 en mode manuel sur le site Randoxygène. Cela pourrait vous donner des idées.
Pour cet été, on a testé une solution expérimentale et temporaire qui s'appuie sur l'existant dans Geotrek-admin, en utilisant notamment les signalements.
Pour cela, on a quand même du en amont, faire quelques corrections et améliorations du module Signalement : https://github.com/GeotrekCE/Geotrek-admin/issues/4085
Mais pour le moment, on n'a ajouté aucun champs, aucun module, aucune nouveauté dans Geotrek-admin. On a composé avec l'existant en créant des vues dans la BDD intersectant les signalements (non traités, seulement de certains types...) avec les itinéraires, pour identifier et remonter les itinéraires perturbés.
Ça donne ça : https://umap.openstreetmap.fr/fr/map/randos-perturbees-parc-national-des-ecrins_1080947#10/44.7570/6.3391
C'est assez expérimental et bricolage pour le moment, mais ça permet de tester les concepts, affiner les besoins et avoir une solution d'urgence fonctionnelle.
Dans le détail, je créée donc des vues dans la BDD de Geotrek, puis j'ai des scripts OGR qui génère automatiquement des fichiers GeoJSON sur un serveur chaque heure. Ensuite mon projet UMAP tape directement et dynamiquement sur ces fichiers GeoJSON qui sont regénérés chaque heure à partir de vues tapant sur la BDD de Geotrek.
Détail des vues dans la BDD
--- Vue basique de toutes les randos
CREATE OR REPLACE VIEW public.v_treks_basic
AS SELECT e.geom,
e.id,
e.uuid,
i.name,
i.name_en,
i.name_fr,
i.name_it,
i.departure,
i.departure_en,
i.departure_fr,
i.departure_it,
i.arrival,
i.arrival_en,
i.arrival_fr,
i.arrival_it,
i.description_teaser,
i.description_teaser_en,
i.description_teaser_fr,
i.description_teaser_it,
i.description,
i.description_en,
i.description_fr,
i.description_it,
i.ambiance,
i.ambiance_en,
i.ambiance_fr,
i.ambiance_it,
i.duration,
i.advised_parking,
i.public_transport,
i.advice,
i.advice_en,
i.advice_fr,
i.advice_it,
i.route_id,
i.difficulty_id,
i.parking_location,
i.accessibility_infrastructure,
i.accessibility_infrastructure_en,
i.accessibility_infrastructure_fr,
i.accessibility_infrastructure_it,
i.topo_object_id,
i.published,
i.access,
i.access_en,
i.access_fr,
i.access_it,
i.public_transport_en,
i.public_transport_fr,
i.advised_parking_en,
i.advised_parking_fr,
i.publication_date,
i.published_en,
i.published_fr,
i.public_transport_it,
i.published_it,
i.advised_parking_it,
i.points_reference,
i.practice_id,
i.structure_id,
i.review,
i.eid,
i.eid2,
i.reservation_id,
i.reservation_system_id,
i.ratings_description,
i.gear,
i.accessibility_level_id,
i.accessibility_advice,
i.accessibility_covering,
i.accessibility_exposure,
i.accessibility_signage,
i.accessibility_slope,
i.accessibility_width,
i.accessibility_signage_fr,
i.accessibility_signage_en,
i.accessibility_signage_it,
i.accessibility_covering_fr,
i.accessibility_covering_en,
i.accessibility_covering_it,
i.accessibility_advice_fr,
i.accessibility_advice_en,
i.accessibility_advice_it,
i.ratings_description_fr,
i.ratings_description_en,
i.ratings_description_it,
i.gear_fr,
i.gear_en,
i.gear_it,
i.accessibility_slope_fr,
i.accessibility_slope_en,
i.accessibility_slope_it,
i.accessibility_width_fr,
i.accessibility_width_en,
i.accessibility_width_it,
i.accessibility_exposure_fr,
i.accessibility_exposure_en,
i.accessibility_exposure_it,
i.provider
FROM trekking_trek i,
core_topology e
WHERE i.topo_object_id = e.id AND e.deleted = false;
--- Vue des signalements en cours de certaines catégories avec un buffer de 50m autour, uniquement provenant de Geotrek-admin
CREATE OR REPLACE VIEW public.v_reports_perturbations_50
AS SELECT fr.id,
date_part('YEAR'::text, fr.date_insert) AS annee,
fr.date_insert,
fr.date_update,
fr.comment,
frc.label AS categorie,
frp.label AS utilisation,
frs.label AS statut,
fr.problem_magnitude_id AS niveau,
st_transform(st_buffer(fr.geom, 50::double precision), 4326) AS geom_50
FROM feedback_report fr
LEFT JOIN feedback_reportproblemmagnitude frp ON frp.id = fr.problem_magnitude_id
LEFT JOIN feedback_reportstatus frs ON frs.id = fr.status_id
LEFT JOIN feedback_reportcategory frc ON frc.id = fr.category_id
WHERE (fr.problem_magnitude_id = 2 OR fr.problem_magnitude_id = 3) AND (fr.status_id = 1 OR fr.status_id = 2 OR fr.status_id = 3) AND fr.provider::text = 'Geotrek-admin'::text AND fr.deleted = false;
--- Vue des randos perturbés du PNE uniquement, sans les itinérances (donc intersectant des signalements en cours)
CREATE OR REPLACE VIEW public.v_randos_perturbees
AS WITH communes AS (
SELECT t_1.topo_object_id AS tid,
string_agg(z.name::text, ', '::text) AS communes
FROM zoning_city z,
v_treks_basic t_1
WHERE st_intersects(t_1.geom, z.geom)
GROUP BY t_1.topo_object_id
)
SELECT t.topo_object_id AS id_source,
t.name AS nom,
tp.name AS pratique,
tr.route AS type,
c.communes,
t.departure AS depart,
t.arrival AS arrivee,
t.duration AS duree,
e.length AS longueur,
td.difficulty AS difficulte,
st_transform(e.geom, 4326) AS geometrie,
CASE
WHEN max(vr.niveau) = 3 THEN 'Utilisation impossible'::text
WHEN max(vr.niveau) = 2 THEN 'Utilisation difficile'::text
ELSE NULL::text
END AS niveau_signalement,
to_char(max(vr.date_insert), 'DD/MM/YYYY'::text) AS date_signalement
FROM v_treks_basic t
LEFT JOIN authent_structure ats ON ats.id = t.structure_id
LEFT JOIN trekking_practice tp ON tp.id = t.practice_id
LEFT JOIN trekking_route tr ON tr.id = t.route_id
LEFT JOIN core_topology e ON e.id = t.id
LEFT JOIN trekking_difficultylevel td ON td.id = t.difficulty_id
LEFT JOIN communes c ON c.tid = t.topo_object_id
JOIN v_reports_perturbations_50 vr ON st_intersects(st_transform(e.geom, 4326), vr.geom_50)
WHERE t.published = true AND t.structure_id = 1 AND t.route_id <> 5 AND t.route_id <> 6 AND e.deleted = false
GROUP BY t.topo_object_id, t.name, tp.name, tr.route, c.communes, t.departure, t.arrival, t.duration, e.length, td.difficulty, (st_transform(e.geom, 4326))
ORDER BY t.name;
Ensuite pour générer automatiquement les fichiers GeoJSON chaque heure en interrogeant dynamiquement ces vues, on s'appuie sur la méthode qu'on a décrit ici : https://si.ecrins-parcnational.com/blog/2021-06-publier-opendata-continu.html
Cela nous a permis de voir les possibilités ainsi que les limites de déduire les randos perturbés depuis les signalements. Et ainsi d'alimenter la réflexion sur les évolutions de Geotrek-admin pour pouvoir vraiment répondre à cette problématiques de perturbations / fermetures de sentiers.