Gestion des noms dans les réseaux de carrefours pédestres

Sur le canal Telegram / Matrix OSM Plein Air de nombreuses discussions sont en cours sur la façon de cartographier sur OSM les sentiers balisés en France.
Je pense qu’il est important de faire de temps en pemps un point d’étape et éventuellement d’élargir le débat à d’autres contributeurs pas forcément actifs sur ce canal de discussion.

Comme indiqué dans le titre, je pense qu’il serait bien de limiter dans un premier temps la discussion aux réseaux de carrefours (node networks) quitte à élargir après.
Le but serait d’arriver à un consensus sur la façon de nommer les différents éléménts d’un réseau : routes (relations), carrefours (nodes de jonction entre routes) et éventuellement panneaux (guideposts).

Une position commune permettrait

  • de savoir comment continuer le travail (il reste encore beaucoup à faire)
  • de clarifier la page du wiki concernant la France, ce qui serait important pour les nouveaux contributeurs.
  • et éventuellement d’avoir du poids sur les développeurs d’appli de rendu on de validation pour qu’ils essaient de prendre en compte nos idées.

Les éléments à considérer sont

  • la représentation et les informations que le randonneur lambda verra sur une carte (ce qui dépend des développeurs d’appli mais on peut aussi faire avec ce qui existe)
  • les relations avec les opérateurs de réseau
  • la facilité de saisie pour les contributeurs

Les applis qui me semblent importantes actuellement (non limitatif) sont Waymarkedtrails (WMT), Thunderforest et Knooppuntnet (KPN). WMT et Thunderforest sont reprises en fond de cartes on en surcouches dans des applis de randos utilisées dans le grand public (SityTrail, Visorando…), KPN est surtout intéressant pour la validation des réseaux. Une autre appli est aussi en développement, OSM Panneaux Multidirectionnels.

Il ne faut pas perdre de vue que l’idée de cartographier les réseaux de carrefours vient de régions où ces réseaux sont construits sur des carrefours numérotés d’où la préférence des ref alors qu’en France, la plupart des réseaux ont des carrefours portant des noms de village ou de lieux-dits.

Pour ouvrir le débat, quelques propositions :

  • pour les routes (ou trajets, ou tronçons, le terme liaison employé dans le wiki est un peu trompeur, je l’utiliserais plutôt pour les liaisons entre réseaux ). Dans le wiki on lit :

    • ref / ref1-ref2 / obligatoire / ref1 et ref2 sont le numéro ou l’abréviation du nom des deux carrefours aux extrémités de la liaison.
      Bien que marqué obligatoire, je ne l’ai jamais mis dans les relations et KPN n’a pas l’air de s’en offusquer => on oublie ? ou au moins on met optionnel.
    • name / nom / optionnel / Nom de la liaison. Peut être constitué en combinant les noms des deux carrefours, séparés par un tiret. C’est ce que je fais pour les réseaux sur lesquels je travaille.
      Avantages que j’y vois:
      • pour le randonneur, ce nom apparaît sur le fond de carte Thunderforest quand on zoome assez, il apparaît aussi en clair sur WMT.
      • pour le contributeur, le nom apparaît en clair quand on ouvre la relation réseau dans iD ou dans Josm, sinon on n’a qu’une liste d’identifiants OSM, peu explicite
      • pour les discussions avec les opérateurs de réseau, c’est ce nom qui caratérise un trajet
  • pour les carrefours (nodes), toujours dans le wiki :

    • rXn_name optionnel, rXn_ref obligatoire. Pas de tag name prévu.
      • pour le randonneur, pas de problème WMT et Thunderforest n’utilisent ni l’un ni l’autre.
      • pour la validation, KPN utilise l’un ou l’autre mais ne reconnaît pas name
      • pour le contributeur, là aussi, si pas de name, le carrefour n’apparaît qu’avec son identifiant OSM quand on ouvre la relation réseau dans iD ou dans Josm, d’où une liste illisible.

Solutions ? dupliquer rXn_name en name ? Suggérer fortement à KPN de reconnaître name ?

  • pour les panneaux (poteaux signalétiques, guideposts) : Il me semble important de distinguer le carrefour et le panneau. Quand le panneau existe et a un nom, le carrefour a le même nom. Mais il arrive que le panneau ait disparu (vandalisme ou autre) dans ce cas, soit on le supprime soit on le tague avec un préfixe removed pour qu’il n’apparaisse pas sur les cartes (WMT). Le carrefour lui, existe toujours et son nom peut se déduire du nom de la route (sur Thunderforest).

Ayant donné mon avis sur ce sujet sur télégramme je me devais de le redonner ici.

Premièrement question de sémantique je parle de réseau pour la relation qui coiffe et organise les itinéraires. Le mot liaison peut être ambigu je pourrais employer segment ou tronçon pour la relation entre chaque node sans en être plus satisfaisant. Le carrefour me semble le plus approprié pour les nodes

Je suis un fervent partisan de l utilisation de REF et NAME chaque fois que rien ne s y oppose. Et il me semble superflu de vouloir utiliser xyn_ref ou xyn_name. Les seuls cas seraient un nom différent pour des activités différentes.

Ensuite que choisir entre REF et NAME.

1 un numéro bien visible sur un poteau peu être considéré comme son nom pour l activité Vélo. Et un segment 23-78 ou ET 32 - GB 64 ne me choque pas plus que ça. Même si je lui préfère le Jas - la Bergerie. Dans ces cas nous avons un identifiant unique dans le réseau. J utilise NAME

2 le cas où il n y a pas de nom pas de numéro mais une référence au dos des lames qui de devient alors l identifiant du carrefour je prends REF.

Pour être compatible avec KPN je vais renseigner xyn_name ou réf mais on ne cartographie pas pour une application ou une autre…

J ai déjà été très long je ferais un autre post sur mon process de cartographie des nodes network et poteau et signe

J ajouterais que le poteau supporte des lames qui ne sont pas forcément directionnelles indiquant une ou des destinations une distance et ou un temps de parcours.

Bonjour,
C’est peut-être l’occasion d’expliquer pourquoi, malgré mon attrait pour l’aspect activités de plein air d’OSM, j’ai rapidement refermé la porte de KPN. Ce qui m’a repoussé est le choix de tagguer le node des « highways » correspondant au croisement.
Je comprends l’intérêt du développeur (ben le node est sur tous les ways nécessaires pour faire du routage), mais je le trouve peu compatible avec l’approche du contributeur, où j’aurais eu le réflexe de cartographier le poteau indicateur des directions (l’objet lui-même). Le developpeur un peu sérieux n’aura pas de mal à trouver le croisement le plus proche (oui, la requête est plus longue à écrire), le contributeur débutant ne se demandera pas ce que sont ces tags étranges (voir incompréhensibles) sur un node de chemin.
Ça m’a toujours repoussé sans que j’en parle, c’était l’occasion de le faire.

C’est parfois bien quand c’est l’humain qui décide à la place d’un programme informatique. Le node (même si il y a un croisement de plusieurs way) le plus proche d’un guidepost nest pas forcement l’emplacement du carrefour.