FR:Proposed features/Hierarchies route=bicycle

From OpenStreetMap Wiki
Jump to: navigation, search
Langues disponibles — Proposed features/Hierarchies route=bicycle
Afrikaans Alemannisch aragonés asturianu azərbaycanca Bahasa Indonesia Bahasa Melayu Bân-lâm-gú Basa Jawa Baso Minangkabau bosanski brezhoneg català čeština dansk Deutsch eesti English español Esperanto estremeñu euskara français Frysk Gaeilge Gàidhlig galego Hausa hrvatski Igbo interlingua Interlingue isiXhosa isiZulu íslenska italiano Kiswahili Kreyòl ayisyen kréyòl gwadloupéyen kurdî latviešu Lëtzebuergesch lietuvių magyar Malagasy Malti Nederlands Nedersaksies norsk norsk nynorsk occitan Oromoo oʻzbekcha/ўзбекча Plattdüütsch polski português română shqip slovenčina slovenščina Soomaaliga suomi svenska Tiếng Việt Türkçe Vahcuengh vèneto Wolof Yorùbá Zazaki српски / srpski беларуская български қазақша македонски монгол русский тоҷикӣ українська Ελληνικά Հայերեն ქართული नेपाली मराठी हिन्दी অসমীয়া বাংলা ਪੰਜਾਬੀ ગુજરાતી ଓଡ଼ିଆ தமிழ் తెలుగు ಕನ್ನಡ മലയാളം සිංහල ไทย မြန်မာဘာသာ ລາວ ភាសាខ្មែរ ⵜⴰⵎⴰⵣⵉⵖⵜ አማርኛ 한국어 日本語 中文(简体)‎ 吴语 粵語 中文(繁體)‎ ייִדיש עברית اردو العربية پښتو سنڌي فارسی ދިވެހިބަސް
Hierarchies route=bicycle
Statut : Draft (under way)
Proposé par : Axelos
Balisage : route=bicycle

Cette page est en stade brouillon, néanmoins n’hésitez pas à y participer.

Ce genre de manipulation est plutôt à destination des utilisateurs avancés, et non des débutants. En effet, découper les relations proprement n'est pas forcément facile lorsqu'on débute dans OpenStreetMap.

Concept

Les itinéraires cyclables sont représentés sur OpenStreetMap sous forme de relations. Il existe de nombreux itinéraires officiels qui sont déjà présents dans la base, ou qui peuvent l’être. Et enfin, il existe plusieurs types d’itinéraires, locaux, régionaux, nationaux et enfin internationaux.

À savoir, souvent, les itinéraires internationaux, se basent en partie sur des itinéraires nationaux, qui quant à eux se basent sur des itinéraires régionaux/locaux. Parfois les régionaux se basent sur les locaux. En clair, avec le système de relations, on peut arriver dans des situations ou jusqu’à 4 (peut-être plus ?) itinéraires se partagent le même cheminement. En cas de modification de ce cheminement (par exemple, une nouvelle voie verte sur 2 km le long de la route anciennement utilisée par l’itinéraire), c’est alors les 4 relations qui doivent être éditées pour prendre en compte cette mise à jour !

Le concept des hiérarchies, permet justement d’éviter ce type de situation, ou seule une relation est modifiée, et cette modification est automatiquement appliquée sur les 3 autres itinéraires.

Paradoxalement, ce procédé hiérarchique peut complexifier la gestion des itinéraires cyclables lorsque ceux-ci sont denses. Son usage est donc réservé principalement pour les itinéraires réalisant de grand parcours, plusieurs centaines de kilomètres.
Il reste possible, et même bien souvent conseillé, de continuer à créer plusieurs relations parallèles lorsque les itinéraires se rencontrent sur de courtes distances, 10, 20, voir 30 km.

Regardez ici pour d'autres explications.

Comment faire ?

Le concept de hiérarchies se base principalement sur le système des relations parents/enfants. À vrai dire, ce système est déjà en parti utilisé, pour notamment découper les grandes véloroutes nationales et internationales, car sans ce procédé, les relations pourraient contenir plus de 1000 membres … Par exemple l’EuroVelo6 qui contient une relation enfant pour chaque pays traversé.

Le concept de hiérarchies ne fait donc que décupler les possibilités que propose le système des relations parents/enfants. Pour y parvenir efficacement, ne tournons pas autour du pot, il vous faudra avant tout utiliser un éditeur puissant : JOSM.

Cas concret

Nous allons prendre un cas existant, ou deux véloroutes nationales se croisent et empruntent le même cheminement sur une certaine longueur, chacune des deux exploitant un itinéraire régional. Les itinéraires nationaux sont la V50 et la V52, et l’itinéraire régional la Boucle de la Moselle.

Par souci de facilité de compréhension du concept, nous partons du principe que les deux véloroutes 50 et 52 n'empruntent aucun autre aménagement local-régional jusqu'à leurs destinations (Apach, Strasbourg, Lyon, Paris), ce qui n'est pas le cas dans la réalité. Aussi, la V52 est entièrement exploitée par un réseau international … mais on omet cette information pour simplifier le cas.


Hierarchies route bicycle.png


En visualisant ce plan, on constate que :

  • Le segment A est constitué de deux itinéraires : La boucle de la Moselle et la V50
  • Le segment B est constitué de trois itinéraires : La boucle de la Moselle, la V50 et la V52
  • Le segment C est constitué de deux itinéraires : La boucle de la Moselle et la V52

Les segments sont indicatifs, ils ne doivent pas être notifiés dans les relations.


Nous commençons par la relation représentant l’itinéraire cyclable du plus bas niveau, dans notre cas, il s’agit de la Boucle de la Moselle. Nous nous attaquerons aux véloroutes 50 et 52 plus tard.

Relations La Boucle de la Moselle

La Boucle de la Moselle est donc constituée de 5 relations au total :

  • Une relation parente reprenant la totalité du cheminement en listant ses enfants
  • Une relation enfant Toul - Pompey
  • Une relation enfant Pompey - Laneuveville (Segment A)
  • Une relation enfant Richardménil - Laneuveville (Segment B)
  • Une relation enfant Toul - Richardménil (Segment C)

Chacune d'elle doit utiliser exclusivement la balise network=rcn, la même ref=* et roundtrip=yes car il s'agit d'une boucle. Pas de from=* et to=* car il n'y a pas de point de départ ou d'arrivée (cela diffère en fonction des cas, certaines boucles touristiques en ont, exemple).

En revanche le nom peut être différent sur chacune de ces relations. Bien évidement, nous utiliserons name=La Boucle de la Moselle sur la relation parente, mais il est possible de décrire les relations enfants. Exemple name=La Boucle de la Moselle : Toul - Pompey ou encore name=La Boucle de la Moselle : Pompey - Laneuveville.

Ainsi réalisé, un système de rendu ou de réutilisation de ces données respectant le concept des hiérarchies, sera en mesure d’intégrer directement les relations enfants dans la parente, ce qui fait que l'utilisateur final ne sera informé que d'une unique relation qui contiendra toutes les informations nécessaires pour son exploitation.

Relations Véloroute 50

La V50 est constituée de 5 relations :

  • Une relation parente représentant la totalité du cheminement en listant les enfants
  • Une relation enfant Apach - Pompey
  • La relation enfant de la Boucle de la Moselle : Pompey - Laneuveville (Segment A)
  • La relation enfant de la Boucle de la Moselle : Richardménil - Laneuveville (Segment B)
  • Une relation enfant Richardménil - Lyon

En mettant de coté les deux relations issues de la Boucle de la Moselle, les trois restantes doivent utiliser exclusivement les balises network=ncn, ref=V50, from=Apach et to=Lyon. Comme précédemment, nous utiliserons un nom explicite pour la relation parente name=Véloroute 50, et de préférence des noms descriptifs pour ses deux relations enfants : name=Véloroute 50 : Apach - Pompey, name=Véloroute 50 : Richardménil - Lyon.

Ainsi réalisé, un système de rendu ou de réutilisation de ces données respectant le concept des hiérarchies, sera en mesure d’intégrer directement les relations enfants utilisant network=ncn dans la parente, et en parallèle laissera visibles les relations utilisant network=rcn, le but étant de laisser à disposition ces deux itinéraires qui se superposent certes, mais restant indépendants.

Relations Véloroute 52

Le principe est le même que pour la V50, elle est donc constituée de 5 relations :

  • Une relation parente représentant la totalité du cheminement en listant les enfants
  • Une relation enfant Paris - Toul
  • La relation enfant de la Boucle de la Moselle : Toul - Richardménil (Segment C)
  • La relation enfant de la Boucle de la Moselle : Richardménil - Laneuveville (Segment B)
  • Une relation enfant Laneuveville - Strasbourg

En mettant de coté les deux relations issues de la Boucle de la Moselle, les trois restantes doivent utiliser exclusivement les balises network=ncn, ref=V52, from=Paris et to=Strasbourg. Comme précédemment, nous utiliserons un nom explicite pour la relation parente name=Véloroute 52, et de préférence des noms descriptifs pour ses deux relations enfants : name=Véloroute 50 : Paris - Toul, name=Véloroute 50 : Laneuveville - Strasbourg.

Exemple

Dans le tableau ci-dessous, est représentée toute l'arborescence des relations constituantes le segment 1 de la véloroute internationale Paneuropa-Radweg. Elle est longue d'environ 1500 km, le segment 1 représentant la partie française est lui long d'environ 500 km. Elle exploite quasiment tout du long la Véloroute 52 Paris - Strasbourg, qui quant à elle utilise de multiples plus petits itinéraires.

Du fait que le concept hiérarchique n’est pas validé, la relation PAM Segment 1 reste pour le moment indépendante. La Véloroute 16 (Dieppe - Strasbourg) utilise partiellement la Véloroute 52 (V16 est partiellement implémentée sur OSM).

icn icn child ncn / icn child-child ncn child rcn / rcn child lcn / rcn-lcn child others ncn / icn
relation Paneuropa-Radweg (PAN) relation PAN Segment 1 : French Paris – Strasbourg/Kehl (Hierarchical relations is not enabled) relation Véloroute 52 (V52) : Paris – Strasbourg Paris – Crouttes-sur-Marne No
relation V52 : Claye-Souilly – Crouttes-sur-Marne (proposed)
relation V52 : Crouttes-sur-Marne – Trélou-sur-Marne/Dormans (proposed)
->
relation Véloroute de la Vallée de la Marne (proposed)
relation V52 : Condé-sur-Marne – Recy (proposed)
->
relation Voie Verte du canal latéral à la Marne
relation V52 : Moncetz-Longevas – Sermaize-les-Bains (proposed)
relation V52 : Sermaize-les-Bains – Fains-Véel (proposed) V16
->
relation Voie Verte de la Vallée de l’Ornain
relation V52 : Saint-Amand-sur-Ornain – Void-Vacon (proposed)
relation V52 : Void-Vacon – Toul (proposed)
->
relation La Boucle de la Moselle : Toul - Richardménil
relation La Boucle de la Moselle : Toul - Chaudeney-sur-Moselle
2 variantes
relation La Boucle de la Moselle : Chaudeney-sur-Moselle par les chemins
relation La Boucle de la Moselle : Chaudeney-sur-Moselle par les routes
relation La Boucle de la Moselle : Chaudeney-sur-Moselle - Richardménil
relation La Boucle de la Moselle : Richardménil - Laneuveville
relation V52 : Laneuveville – Maixe (proposed)
->
relation Véloroute voie verte du Sânon
relation V52 : Xures – Réchicourt-le-Château (proposed)
relation V52 : Réchicourt-le-Château – Gondrexange
relation V52 : Gondrexange V16
EV5
2 variantes
relation V52 : Gondrexange – Hesse via Bébing
relation V52 : Gondrexange – Hesse via Lorquin (proposed)
relation V52 : Hesse – Saverne
relation V52 : Saverne – Strasbourg
relation V52 : Strasbourg V16
EV5
EV15
PAN Segment 1 : Strasbourg – Kehl No description No description
relation PAN Segment 2 : Deutschland-Baden-Würtemberg No description
relation PAN Segment 3 : Deutschland-Bayern
relation PAN Segment 4 : Tschechien

Possibilités

Les étapes

Certains itinéraires cyclables touristiques proposent des étapes. Dans le concept des relations hiérarchiques, deux itinéraires empruntant le même chemin ne proposent pas forcement les même étapes. La solution est donc de créer une relation enfant listant chaque étape. Cette relation reprend les même balises que les relations cyclables habituelles ( type=route , route=bicycle , network=* , ref=* , from=* et to=* ) mais utilise un nom explicite ( name=Véloroute 50 : Étapes ). Les membres de cette relation enfant sont exclusivement des étapes, des nœuds situés sur les chemins de l’itinéraire portant le rôle stage.

Ce type de relation sera éventuellement amené à évoluer avec le temps en fonction des besoins. En y ajoutant par exemple les panneaux d'information propre à l’itinéraire, ou des auberges en partenariat avec l'opérateur ...

Les balises from et to

Il était écrit précédemment que les balises from=* et to=* sont obligatoires, ce n'est pas le cas. Cependant, leur usage reste fortement conseillé car peuvent être déterminantes pour certains cas spécifiques. Imaginez qu'un département crée le long d'un canal une voie verte de 30 km, et décide d'y faire transiter deux itinéraires locaux. Dans ce cas, la solution est de créer une relation enfant pour l'un des deux itinéraires, qui sera ensuite incluse dans le second itinéraire. Puisque les deux itinéraires emploient network=lcn, ce sont alors les balise from=* et to=* qui les différencient.

Statut de proposition

Concernant la gestion des relations enfants désignées comme étant des propositions avec l'usage de la balise state=proposed (généralement des itinéraires en projet et donc non existant sur le terrain), elles peuvent être inclue de la même manière que les autres n’ayant pas ce statut. Un système de rendu ou de réutilisation de ces données respectant le concept des hiérarchies, saura les différencier, soit en les ignorant, soit en les traitant d'une façon différente. Ainsi, lorsque cet aménagement sera existant sur le terrain, il suffira de retirer cette balise.

Les variantes

De nombreux itinéraires proposent le long de leurs parcours des variantes : Il s'agit de plusieurs chemins alternatifs, partants du même lieu puis se retrouvent sur un autre même lieu. Actuellement il n'existe pas de méthodologie standardisé concernant le balisage à apporter sur ces variantes, cependant un groupe de travail étudie actuellement la question suite au SOTMFR 2018.

Sont utilisés à des fins de tests ces balises :

  • via=*

Indiquez ici une ville ou autre nomination possible, qui permet de la différencier des autres variantes, n’hésitez pas à utiliser des noms officiels s'ils existent.

  • alternate=variant/main/no

variant : indique qu'il s'agit d'une variante.
main : est à utiliser si une variante est considérée comme étant la principale.
no : indique qu'il ne s'agit pas d'une variante, c'est la valeur implicite mais pourra peut être utile à préciser dans certains cas.

Exemples : relation V52 : Gondrexange – Hesse via Bébing ; relation V52 : Gondrexange – Hesse via Lorquin

Concernant l'introduction de ces itinéraires dans le concept des hiérarchies, la pratique consiste à créer une relation distincte pour chacune des variantes disponibles, référencé au plus bas niveau (rappel : lcn < rcn < ncn < icn). Ces relations représentant des variantes, en général au nombre de deux, sont ensuite à intégrer dans la relation parente correspondante.

En cas d'ajout d'un itinéraire ayant un référencement de même niveau ou supérieur, s'il utilise les mêmes variantes, alors celui-ci peut exploiter tel quel ces relations. Aussi, dans le cas où l’itinéraire de même niveau ou supérieur, exploite uniquement l'une des variantes, n'ayant pas d'alternative, cette variante devient de fait le parcours unique disponible (c'est aussi le cas s'il n’utilise que deux variantes sur trois).

Liens externes

Relation hierarchies concept appliqué par Waymarked Trails