Évolution des tags pour la randonnée

Une proposition a été déposée sur le wiki il y a quelques jours pout introduire de nouveaux tags pour les itinéraires de randonnée (à pied, à cheval, en vélo, etc). Voir Proposed feature/basic network - OpenStreetMap Wiki

Cela tombe à un moment où d’autres choses se passent :

  • l’un d’entre nous a ouvert le débat sur la valeur rwn du tag network pour contester le schéma existant

  • un gros travail a été fait ces derniers mois pour segmenter et rendre routables les grands itinéraires de rando en France, et des applis spécialisées apparaissent (ex : superroute.org)

  • on voit aussi apparaître de plus en plus les itinéraires locaux

  • un style OsmAnd pour la rando a été développé, signe d’un usage croissant d’osm pour la rando

  • la communauté Geotrek a lancé un groupe de travail sur un schéma de données pour échanger des données de rando

  • un groupe de contributeurs français teste des simplifications sur le schéma de données existant dans osm, en particulier celui destiné aux réseaux de carrefours.

C’est sans doute le bon moment pour avoir un débat en langue française et que qq’uns d’entre nous s’en fassent le relais sur le wiki anglais.

Je me dénonce bien volontiers.
Pour compléter ce qui me préoccupe, quelle que soit finalement l’issue des discussion autour de cette proposition, c’est d’utiliser des clés et valeurs intelligible avec une définition cohérente avec leur signification.

Deux problèmes de forme :

  • rwn, lcn, etc… sont des valeurs illisibles, porteuses de 3 concepts malgré leur concision à toute épreuve : un niveau hiérarchique, un thème (cycliste, randonnée…) et la mise en réseau.
  • Le concept « node_network » alors que beaucoup de choses dans OSM sont des réseaux de nœuds. Il faut mieux définir ce qu’est un nœud sur les thèmes qui nous intéressent. Il y a forcément un terme plus adapté, je n’ai jamais parlé de nœud quand je me promène en montagne.

On a donc besoin d’une terminologie claire et efficace, qu’on cartographie ou pas les réseaux de carrefours, les itinéraires FFRP ou pas.
Je laisse donc les autres compléter leur point de vue sur la partie pure métier randonnée/cyclisme et serai vigilant sur la forme du résultat.

Quelques éléments concernant l’aspect « métier » de randonnée pédestre (dont j’imagine qu’ils sont similaires pour le VTT et l’équitation) :

  • la FFRP et quelques départements documentent trois types d’itinéraires : les linéaires, les boucles, et les « réseaux de carrefours ». Les deux premiers types sont assez proches l’un de l’autre, mais chacun des trois a probablement vocation à avoir un schéma de données différent.

  • dans rwn, lcn, etc, pas sûr que la mise en réseau ait véritablement un sens « métier ». Je dirais qu’il y a deux concepts (niveau et thème) et du bruit. S’il y a un contexte où le mot « réseau » a un sens précis en matière de rando, c’est exclusivement celui des réseaux de carrefours.

  • je n’ai connaissance d’aucune référence permettant de décider si un itinéraire est national, local, régional, etc. L’existant s’appuie sur des heuristiques plus ou moins cohérentes, mais rien de convaincant. Il s’agit plutôt d’un « tag pour le rendu », utile mais pas très satisfaisant. En plus, il peut y avoir des itinéraires qui soient à la fois locaux et internationaux…

  • il y a des points communs évidents avec les itinéraires routiers, en particulier quand on parle de panneaux directionnels.

  • il ne faut pas sous-estimer la complexité de ce qu’est un itinéraire de rando, surtout quand on prend en compte les intentions de ses gestionnaires. Par exemple, les collectivités locales créent des itinéraires en même temps qu’ils créent des parkings aux points de départs…

Des bouts de chemins, oui. Mais les relations (itinéraires) non. Dans le cadre de la randonnée pédestre, tu verras du fléchages jaune (PR) cohabiter avec du fléchage rouge et blanc (GR). Que tu utilises le chemin comme PR n’empêche pas ton voisin de l’utiliser comme GR.

Les GRT dans les Pyrénées, par ex.

Non, le fait de passer d’un pays à un autre ne transforme pas un itinéraire de portée régionale en itinéraire de portée internationale. Vas-tu utiliser ce chemin pour aller d’Espagne en France ? La réponse est non. De la même façon les trains allant de Strasbourg à Kehl sont des trains régionaux (pour ceux qui restent dans le coin comme TER A 11 : Offenburg → Kehl → Strasbourg). Il y a aussi des train internationaux qui passent par Strasbourg et Kehl (comme TGV 84 : Francfort → Marseille).

On est d’accord.

Ce tag network n’est pas adapté, pas clair.

  • local : PR
  • régional : GRP
  • national : GR
  • international : EV, chemins de pèlerinage…

@StC faisait référence au sentiers locaux inscrits au PDIPR et marqués en jaune.
Certains sont le « support » pour des GR, eux mêmes servant au tracé des sentiers européens de grande randonnée.

Nous avons homogénéisé les réseaux de carrefours « nommés » en France et écrit des tickets pour corriger ou faire évoluer le logiciel dédié knooppuntnet.

Afin de coller au plus près du terrain en France et pour faciliter la saisie, nous souhaitons maintenant simplifier certains tags (par exemple lwn_name en name), en rendre d’autres optionnels, utiliser les panneaux directionnels (information=guidepost) comme source de nom pour les carrefours…

D’où ma référence explicite à des tronçons comportant du balisage jaune et du balisage rouge et blanc.

Même si à mes yeux la destination finale est rarement un sujet d’intérêt pour les randonneurs, restons sur cette similitude avec les transports en commun. Si on en croit le wiki, la convention y est d’utiliser le tag network pour des choses plus précises : le nom du réseau. Idem pour les itinéraire routiers.

Ne pourrait-on pas s’aligner sur eux, libérer le tag network pour le nom du réseau, et changer de système pour représenter la nature des itinéraires (hiking, bicycle, mtb, etc) ? Avoir un tag hiking, un tag bicycle, etc permettrait de gérer plus facilement les itinéraires définis pour plusieurs modes de déplacements.

Tu remets en question l’intérêt de la hiérarchie icn/rcn/lcn ? Pourquoi pas mais ça existe et si ça existe c’est a priori que ça a un intérêt. Et en effet si tu prends un chemin non fléché et que tu y fais passer un GR, tu verras sa fréquentation très fortement augmentée. Tu es donc assuré de sa non appropriation par des voisins indélicats et de sa visibilité.

Sur la proposition je suggérais d’utiliser network:range car effectivement network n’est pas terrible.

Libérer OK par contre je ne vois pas de nom de réseau pour les itinéraires auxquels je pense. operator oui.

Donc bicycle=designated et foot=yes par exemple ? Itinéraire vélo empruntable par un piéton ? Pourquoi pas, ce n’est pas @InfosReseaux qui va dire du mal de généraliser :wink: et moi non plus !

Rien ne nous forcerait à le réutiliser. Mais je peux imaginer certains cas :

  • les réseaux de carrefours, qui parfois viennent en complément de circuits gérés par le même opérateur. Aujourd’hui c’est traité par une relation parente avec des nœud et des itinéraires dedans, on pourrait le traiter par un tag.
  • les chemins de Saint-Jacques. Il y a plusieurs opérateurs, mais un unique réseau.

Ou des valeurs « métier » qui décrivent le type d’itinéraire. Par exemple linéaire, circuit, réseau de carrefours.

J’ai l’impression (mais je peux me tromper) que operator suffit.

Tu en parleras à celui qui disait « Même si à mes yeux la destination finale est rarement un sujet d’intérêt pour les randonneurs » :wink: et va-t-on faire une relation comportant tous les chemins avec network=Rome parce que tous les chemins mènent à Rome ? :-), je caricature mais dans OSM on évite les listes catalogues, Overpass fait ça très bien.

Oui bien-sûr il n’y a pas obligation à utiliser cet attribut.

Typiquement les valeurs foot, bicycle ont déjà la signification que je rappelle. Surcharger pour donner une autre connotation est une mauvaise pratique.

inéaire, circuit, réseau de carrefours.

Quel intérêt ? Si tu as des chemins et que le premier point du premier chemin est le dernier du dernier chemin alors c’est une boucle. Sinon c’est linéaire (ou pas il peut y avoir des branches), si tu n’as pas de chemines alors c’est un réseau de nœuds. c’est de la topologie. Entrer de la non-information dans une base de données, c’est rarement intéressant (hormis pour des caches).

Répondre à cette remarque, concernant Saint-Jacques, m’amènerait sur un terrain glissant :slight_smile: Disons que c’est le nom d’un réseau soutenu par le Conseil de l’Europe, on devrait pouvoir s’en tenir là.

C’est tout l’inverse. Aujourd’hui, ces relations-listes existent, et utiliser le tag network pour leur nom permettrait de les supprimer.

Je l’ignore et je ne prétends pas en juger. Ce que je constate, c’est que la valeur node_network existe aujourd’hui. Si on peut s’en débarrasser au passage sans détruire de l’information, tant mieux.

OK, même si à mes yeux remplacer un yes par une valeur pertinente est un sacré cas particulier. Dans la mesure où il y aura sans doute quelques informations nouvelles à associer à un mode de parcours d’un itinéraire (à voir avec le groupe Geotrek dont je parlais : difficulté, temps), peut-être que qq tags préfixés par hiking:pourraient faire l’affaire.

Moi la coquille Saint-Jacques je la fais à la bretonne. Tu parles bien des chemins des pêcheurs draguant la coquille, hein ^^.

J’ai regardé et les Itinéraire culturel du Conseil de l'Europe — Wikipédia c’est un peu tout et n’importe quoi, par exemple un réseau de ville où l’Art Nouveau a été important. Ça n’a pas grand choses à faire dans OSM.

Aujourd’hui, ces relations-listes existent, et utiliser le tag network pour leur nom permettrait de les supprimer.

+1

Ce que je constate, c’est que la valeur node_network existe aujourd’hui. Si on peut s’en débarrasser au passage sans détruire de l’information, tant mieux.

Comme type=node_network n’appporte aucune information, supprimer l’attribut n’en supprime pas non plus :wink: .

OK, même si à mes yeux remplacer un yes par une valeur pertinente est un sacré cas particulier.

designated est déjà une valeur courante voir bicycle | Keys | OpenStreetMap Taginfo.

peut-être que qq tags préfixés par hiking:pourraient faire l’affaire.

+1, voir https://taginfo.openstreetmap.org, mais par exemple il y a peu de durées par moyen de locomotion. Assez logique : soit c’est une vitesse imposée style moyen de transport public et alors duration suffit soit c’est à la vitesse de chacun et un calculateur d’itinéraire fera le boulot pour chaque profil particulier. Si tu as beaucoup d’infos spécifiques route=hiking et duration = durée pour ce mode sera plus indiqué. Si tu prends l’exemple des chemins de Saint-Jacques de Compostelle, tu es libre (je crois) des étapes, la durée n’a pas de sens, tu vas choisir toi-même les étapes, pour les GR© c’est pareil (et là en général l’itinéraire complet n’est que pour les piétons).

Le tag roundtrip=yes permet d’indiquer si l’itinéraire et un circuit (une boucle, ou un linéaire parcouru dans les 2 sens).
Comme l’indique @bibi l’analyse de la topologie peut nous en dire plus.

Si besoin, on pourrait proposer une valeur de roundtrip pour indiquer un trajet aller/retour.

Donc pour moi utiliser les tags suivants simplifierait les requêtes overpass et homogénéiserait les relations route (ou les nœuds « carrefours ») avec le tag information=guidepost :

Et plus précisément si, au delà de la topologie, les tronçons ont des rôles différents, les attributs role permettent de préciser : main (valeur par défaut), alternative, excursion, approach, connection.
Et pour les chemins de Saint-Jacques, c’est pilgrimage=yes.

knooppuntnet ne gère que le rôle connection
D’après tag info, il n’y a que 15 nœuds et 906 chemins dans les 51.5 millions de relations routes !

Une requête overpass sur l’Europe dénombre 229 nœuds avec ce rôle, certains reliant les réseaux belges et français de part et d’autre de la frontière.

Par exemple, les 8 carrefours du réseau Monts de Flandre (France) qu’on retrouve dans le réseau Heuvelland (Belgique).