Gestion des relations dans JOSM

Les Libres Géographes

v1.0, 27/05/2020

Licence CC-BY-SA 2.0 - Partage dans les mêmes conditions avec attribution 2.0 International

Ce chapitre fait partie du Guide de la Géomatique Libre et de donnée Ouverte,

dirigé par Nicolas Chavent et Séverin Ménard pour Les Libres Géographes,

avec le soutien de

Auteur principal du chapitre : Séverin Ménard

Ce chapitre a été réalisé en faisant la synthèse de connaissances personnelles et des ressources principales suivantes :

• https://wiki.openstreetmap.org/wiki/FR:Relations pour les aspects généraux des relations

• https://wiki.openstreetmap.org/wiki/FR:Relation:boundary pour les tags des relations sur les limites admin

• https://wiki.openstreetmap.org/wiki/FR:Tag:boundary%3Dadministrative#Valeurs_sp.C3.A9cifiques_par_pays_pour_admin_level centralise les admin level de tous les pays

• La section sur les autres types de relation multipolygone est largement reprise d’un document sous licence CC-BY SA 2.0 intitulé "Relations OSM - Exemples de relations OSM de type multipolygon" réalisé par Rafael Avila Coya

• Introduction

Ce chapitre est dédié à la gestion dans JOSM des relations OSM, dont le concept et les propriétés génériques ont déjà été présentés dans le chapitre consacré aux principes fondamentaux de la donnée OSM. Il va s’attacher aux types de relations les plus susceptibles d’être mis en œuvre au sein des communautés OSM du Sud, celles de type multipolygone et celles de délimitations territoriales, en partant à chaque fois des exemples les plus simples avant aborder les plus complexes. Le chapitre s’achève sur un aperçu et des ressources documentaires concernant les relations de type itinéraires et réseaux hydrographiques.

• Relations OSM de type multipolygone

Editer des relations OSM de type multipolygone dans JOSM

Pour aborder l’édition des relations dans JOSM, cette section va d’abord traiter le cas le plus fréquent : celui d’un polygone percé d’un trou, comme peut l’être un bâtiment pourvu d’un patio. Cet objet va être créé pas-à pas à l’aide de l’outil CTRL+B, puis sera analysé afin de comprendre comment fonctionne la relation de type multipolygone.

Un deuxième pas-à-pas va ensuite détailler les étapes de création d’une relation où deux zones partagent un segment de contour, cette fois à l’aide de l’éditeur de relations de JOSM. Des actions courantes d’édition de relations de type multipolygone seront également abordées : couper, sélectionner, visualiser ou ajouter des membres de la relation. Elle pourront être employées également pour éditer tout type de relations dans JOSM.

Afficher le panneau Relations

Le travail sur des objets relations dans JOSM nécessite d’afficher le panneau Relations sur la droite.

| Si le panneau Relations n’est pas encore affiché, cliquer sur le bouton ​​ dans la barre d’outils verticale à gauche ou se rendre dans le menu Fenêtres>Relations

Créer une relation de type multipolygone à trou avec l’outil CTRL+B

| Ouvrir le fichier GLEDO_tuto_JOSM_relations_1.osm avec la méthode de son choix et sélectionner le bâtiment

| Ajouter un bâtiment à l’intérieur avec l’outil B pour le rendre parallèle avec les côtés du bâtiment externe

| Sélectionner les deux bâtiments puis presser les touches CTRL+B ou se rendre dans le menu Outils, ​​ Créer un multipolygone

On remarque que la couleur de l’objet change et que la fenêtre des attributs ne montre plus l’attribut building=yes. Désormais les deux objets sélectionnés sont membres de "multipolygone ("bâtiment", 2 membres)". Une relation intégrant les deux objets bâtiments a donc été créée par l’outil.

Quant au panneau Relations, il n’est désormais plus vide :

| Double-cliquer sur ​​ ou cliquer sur ​​ puis sur le bouton

La fenêtre suivante s’ouvre :

On remarque les points suivants :

• C’est la relation qui porte l’attribut building=yes qui était commun aux deux objets formant le bâtiment avec un trou.

• La relation est de type multipolygon.

• Le chemin de 6 noeuds constituant la forme extérieure du bâtiment a un rôle outer (externe) tandis que le chemin de 4 noeuds constituant la forme intérieure du bâtiment a un rôle inner (interne).

• Le symbole ​​ pour les deux chemins, qui montre qu’ils ne sont pas jointifs.

| Cliquer sur le bouton pour sortir de la fenêtre d’édition de la relation

Pas-à-pas de création d’une relation où deux zones partagent un segment de contour

Cette section couvre toutes les étapes de création d’une relation dans JOSM, à travers l’exemple d’une relation entre deux zones jointives.

| Ouvrir le fichier GLEDO_tuto_JOSM_relations_zones_jointives.osm avec la méthode de son choix et sélectionner les deux objets qu’il contient

Le fichier contient à l’ouest un chemin fermé portant l’attribut natural=scrub (qui correspond à une zone de broussailles) et à l’est un chemin ouvert sans attribut.

Le scénario est le suivant : la zone de broussailles préexiste et il s’agit de créer à l’est une zone résidentielle. La méthode employant l’outil contourmerge (cf. la section consacrée à l’outil) pourrait tout à fait être utilisée, mais une alternative est de créer deux relations. Dans le cas d’objets géométriquement moins complexes comme des bâtiments juxtaposés, l'usage est plutôt que chaque bâtiment soit un chemin fermé et donc que le segment commun soit présent deux fois (cf. la section du guide consacrée à la cartographie des bâtiments dans JOSM).

Couper la ou les parties jointives du contour des zones pour en faire des chemins ouverts

Cette étape est un préalable nécessaire avant la création des relations. Dans cet exemple, il n’y a qu’une seule partie jointive dans les contours des deux zones, qui appartient pour le moment au chemin fermé de la zone de broussailles.

| Sélectionner les noeuds aux extrémités de la partie jointive ainsi que le chemin auquel ces noeuds appartiennent

| Utiliser l’outil Couper (P)

Dans les cas où il y aurait plusieurs parties jointives, il faudra alors répéter les précédentes actions autant de fois que nécessaire.

Créer la relation de la première zone jointive

| Sélectionner tous les chemins ouverts constituant ensemble le contour de la zone de broussailles, puis se rendre dans le menu Préréglages>Relations>Multipolygone

| Si la zone a un nom, le saisir, puis cliquer sur le bouton

On remarque que :

• il manque encore l’attribut principal de la relation.

• les rôles outer (dans la mesure où cette zone n’a pas de trous) des membres ne sont pas indiqués.

• les deux membres constituent ensemble un chemin fermé.

| Saisir dans la fenêtre le ou les attributs à ajouter et le rôle de chacun des différents membres

| Cliquer sur le bouton Valider

Le panneau Relations n’est plus vide et affiche désormais la relation présente dans le calque.

Il reste ici l’attribut natural=scrub qui était porté par chacun des chemins ouverts de l’ancien objet qui a été coupé. Comme cet attribut est désormais intégré aux attributs de la relation multipolygone, il convient de le supprimer sur chacun des chemins constituant la relation.

| Sélectionner et supprimer le ou les attributs portés par les chemins ouverts constituant la relation, rendus non nécessaires car désormais porté(s) par la relation

Créer la relation de la deuxième zone jointive

| Sélectionner tous les chemins ouverts constituant ensemble le contour de la zone

| Se rendre dans le menu Préréglages>Relations>Multipolygone

| Si la zone a un nom, le saisir, puis cliquer sur le bouton

| Saisir dans la fenêtre le ou les attributs à ajouter et le rôle de chacun des différents membres

Dans notre exemple, l’attribut principal est landuse=residential et les deux membres ont un rôle outer.

| Cliquer sur le bouton Valider et désélectionner tous les objets

| Sélectionner le chemin qui constitue la partie jointive entre les deux zones

Ce chemin de 7 noeuds est bien membre de deux relations de type multipolygone, une zone de broussailles et une zone résidentielle.

Couper l’un des membres d’une relation

S’il est besoin de couper en deux l’un des membres d'une relation, il ne sera pas nécessaire d'éditer celle-ci, car elle va automatiquement intégrer cette modification et ajouter le nouveau membre à la relation.

| Sélectionner le noeud où va s’effectuer la coupure

| Couper le chemin

Le chemin est désormais coupé en deux et la relation passe à trois membres.

Sélectionner une relation et visualiser ses membres

Sélectionner une relation et afficher ses attributs

| Dans le panneau Relations, double-cliquer sur la relation désirée ou faire un clic droit sur la relation désirée>Sélectionner la relation

Le panneau des Attributs affiche alors les attributs de la relation sélectionnée. Dans le cas de la relation de la zone de broussailles, le panneau des Attributs affiche ceci :

Visualiser les membres d’une relation

| Sélectionner la relation désirée

Sélectionner cette fois la relation de zone résidentielle avec les étapes vues dans la section ci-dessus.

| Cliquer sur le bouton ​​ de la fenêtre des Relations

| Sélectionner un membre dans la liste

Le membre sélectionné apparaît avec un halo sur la carte. Il est possible de visualiser ainsi tous les membres d’une relation.

Alternativement :

| Cliquer sur l’un des chemins de la relation à visualiser puis sur le bouton

Le chemin sélectionné apparaît dans la zone Sélection à droite et il est également surligné dans la liste des membres à gauche.

| Cliquer sur un autre membre dans la liste des membres

Le membre sélectionné à l’origine reste surligné comme tout objet sélectionné dans JOSM, mais un halo apparaît sur le membre sur lequel un clic vient d’être effectué dans la fenêtre de modification des relations.

Ajouter un membre à une relation existante

Dans l’exemple, une zone de broussailles localisée à l’intérieur de la zone résidentielle va être ajoutée en tant que trou à la relation de cette zone.

| Sélectionner l’objet à ajouter à la relation, cliquer sur la relation concernée dans le panneau Relations et cliquer sur le bouton

Dans l’exemple, il s’agit de :

• Sélectionner l’objet au centre de la zone résidentielle

• Sélectionner la relation multipolygone à 3 membres

• Cliquer sur le bouton

La fenêtre suivante s’ouvre :

| Ajouter le membre sélectionné dans la relation et lui ajouter un rôle

Dans cet exemple, il faut insérer l’objet dans le volet Membres à gauche, soit en haut avec le bouton , soit en bas avec le bouton, et lui ajouter le rôle inner.

Les boutons intermédiaires sont grisés car ils nécessitent de sélectionner d’abord un membre dans le volet Membres.

Attention, dans cet exemple, il n’est pas possible d’insérer le nouveau membre de la relation au milieu des membres existants de rôle outer car le chemin qu’ils forment ensemble ne serait alors plus fermé, ce que reflèterait la zone des symboles géométriques (marquée 1).

L'insertion correcte est celle-ci (ou bien avec le nouvel objet en haut de la liste des membres) :

| Cliquer sur le bouton Valider

La relation multipolygone résidentielle a désormais 4 membres. Il est nécessaire ici de laisser son attribut natural=scrub à l’objet qui a le rôle inner dans la relation, sinon cette zone interne n’aurait pas d'attribut.

Autres types de relations de type multipolygon

Dans cette section sont présentées d'autres types de relation de type multipolygone, cette fois sans les étapes de leur création, mais avec les caractéristiques de chacun de leurs membres. Le wiki OSM fournit quelques autres exemples¹.

Exemples de zones entourées par une zone d’un autre type

Zone commerciale entourée d’une zone résidentielle

Ce cas de figure comporte une seule relation, qui est similaire à la relation créée pas-à-pas dans le précédent exemple, à la différence que la zone localisée à l'intérieur n’est pas une zone de broussailles, mais une zone commerciale.

Attributs de la relation

type=multipolygon

landuse=residential

Membres de la relation et rôles

way 1 -> outer

way 2 -> inner

Attributs des chemins

Le chemin extérieur (way 1) n’a besoin d’aucun attribut obligatoire.

Par contre, il est nécessaire d’ajouter au chemin intérieur (way 2) l’attribut qui indique qu’il est une zone commerciale :

landuse=retail

D’autres attributs complémentaires peuvent aussi être ajoutés au besoin sur la relation ou sur les chemins, par exemple source=*.

Lac entouré par une zone humide

Ce cas de figure comporte aussi une seule relation, similaire à la relation précédente, à la différence que la zone externe est une zone humide et celle localisée à l'intérieur est un lac.

Attributs de la relation

type=multipolygon

natural=wetland

Membres de la relation et rôles

way 1 -> outer

way 2 -> inner

Attributs des chemins

Le chemin extérieur (way 1) n’a besoin d’aucun attribut obligatoire.

Par contre, il est nécessaire d’ajouter au chemin intérieur (way 2) les deux attributs qui combinés indiquent qu’il s’agit d’un lac :

natural=water

water=lake

D’autres attributs complémentaires peuvent aussi être ajoutés au besoin sur la relation ou sur les chemins, par exemple source=*.

Deux zones juxtaposées entourées par une troisième

Ce cas mixe les caractéristiques des cas vus précédemment. Dans l’exemple, une zone commerciale juxtapose un lac, et les deux objets se trouvent à l’intérieur d’une zone résidentielle.

Il y a ici besoin de créer trois relations : une pour la zone résidentielle, une pour la zone commerciale et une pour le lac.

Zone résidentielle

Attributs de la relation

type=multipolygon

landuse=residential

Membres de la relation et rôles

way1 -> outer

way2 -> inner

way4 -> inner

Dans cet exemple, il est important que les deux chemins avec un rôle inner (way2 et way4) se suivent dans la liste des membres de la fenêtre d’édition de la relation :

Si way1 se trouvait entre les deux, way2 et way4 apparaîtraient alors comme des chemins ouverts.

Lac

Attributs de la relation

type=multipolygon

natural=water

water=lake

Membres de la relation et rôles

way2 -> outer

way3 -> outer

Zone commerciale

Attributs de la relation

type=multipolygon

landuse=retail

Membres de la relation et rôles

way3 -> outer

way4 -> outer

Attributs des chemins

Aucun des chemins n’a besoin d’un attribut obligatoire.

D’autres attributs complémentaires peuvent cependant être ajoutés au besoin sur les relations ou sur les chemins, par exemple source=*.

Imbrication de plus de deux zones

Zones imbriquées correspondant à des objets tous différents

Dans cet exemple, il y a trois objets : un lac à l’intérieur d’un bois, et une petite île dans le lac.

Il y a besoin ici de deux relations : une pour le bois et une autre pour le lac.

Bois

Attributs de la relation

type=multipolygon

natural=wood

Membres de la relation et rôles

way1 -> outer

way2 -> inner

Ainsi, le chemin intérieur (way2) détermine la zone qui ne fait pas partie du bois. Le fait qu’il existe un autre objet à l’intérieur de way2 est indifférent.

Lac

Attributs de la relation

type=multipolygon

natural=water

water=lake

Membres de la relation et rôles

way2 -> outer

way3 -> inner

Attributs des chemins

Les chemins 1 et 2 (way 1 et 2 ) n’ont besoin d’aucun attribut obligatoire.

Par contre, il est nécessaire d’ajouter au chemin intérieur (way 3) l’attribut qui indique qu’il s’agit d’une petite île :

place=islet

D’autres attributs complémentaires peuvent aussi être ajoutés au besoin sur les relations ou sur les chemins, par exemple source=*.

Deux zones imbriquées dans un même objet

Dans cet exemple, il y a seulement deux objets : une zone agricole à l’intérieur d’un bois, et une partie du bois à l'intérieur de la zone agricole.

Il y a besoin ici de deux relations : une pour le bois et une autre pour la zone agricole. Si la zone agricole était une zone vide, il ne serait pas nécessaire de créer cette relation.

Bois

Attributs de la relation

type=multipolygon

natural=wood

Membres de la relation et rôles

way1 -> outer

way2 -> inner

way3 -> outer

Ainsi, le chemin intérieur (way2) détermine la zone qui ne fait pas partie du bois. La partie de bois à l'intérieur de la zone agricole (way3) fait partie de la relation avec un rôle outer.

Zone agricole

Attributs de la relation

type=multipolygon

landuse=farmland

Membres de la relation et rôles

way2 -> outer

way3 -> inner

Les rôles des deux chemins sont donc ici inversés par rapport à ceux dans la relation du bois.

Attributs des chemins

Aucun des chemins n’a besoin d’un attribut obligatoire.

D’autres attributs complémentaires peuvent aussi être ajoutés au besoin sur les relations ou sur les chemins, par exemple source=*.

Objet divisé en plusieurs zones

Objet divisé sans partie jointive avec un autre objet

Dans cet exemple, un bois est divisé en trois parties non jointives. Il suffit d’une seule relation pour le cartographier.

Bois

Attributs de la relation

type=multipolygon

natural=wood

Membres de la relation et rôles

way1 -> outer

way2 -> outer

way3 -> outer

Attributs des chemins

Aucun des chemins n’a besoin d’un attribut obligatoire.

D’autres attributs complémentaires peuvent aussi être ajoutés au besoin sur les relations ou sur les chemins, par exemple source=*.

Objet divisé avec une zone interne vide et partie jointive avec un autre objet

Dans cet exemple qui repart du précédent, l’une des zones du bois est cette fois jointive avec une zone agricole et elle comporte une zone interne vide.

Il y a besoin ici de deux relations : une pour le bois et une autre pour la zone agricole.

Bois

Attributs de la relation

type=multipolygon

natural=wood

Membres de la relation et rôles

way2 -> outer

way3 -> outer

way1 -> outer

way5 -> outer

way4 -> inner

Dans cet exemple, il est préférable que le chemin avec un rôle inner (Way4) soit placé au début ou à la fin de la liste des membres de la fenêtre d’édition de la relation. Les deux chemins formant ensemble une des parties du bois (Way1 et Way5) doivent également se suivre dans la liste, qui ne doit montrer aucun symbole de chemin ouvert :

Zone agricole

Attributs de la relation

type=multipolygon

landuse=farmland

Membres de la relation et rôles

way5 -> outer

way6 -> outer

Attributs des chemins

Aucun des chemins n’a besoin d’un attribut obligatoire.

D’autres attributs complémentaires peuvent aussi être ajoutés au besoin sur les relations ou sur les chemins, par exemple source=*.

Grandes zones de plus de 2000 noeuds

Dans OSM, un chemin ne peut avoir plus de 2000 noeuds, or certains très grands objets ne peuvent être représentés avec précision sans nécessiter un nombre de noeuds plus important. Il est alors nécessaire de les créer en tant que relation de type multipolygone.

Dans cet exemple, un lac est cartographié avec 4500 nœuds, divisés en un chemin (way1) de 2200 nœuds, un chemin (way2) de 1500 nœuds et un chemin (way3) de 800 nœuds.

Il suffit d’une seule relation pour le cartographier.

Lac

Attributs de la relation

type=multipolygon

natural=water

water=lake

Membres de la relation et rôle

way1 -> outer

way2 -> outer

way3 -> outer

Attributs des chemins

Aucun des chemins n’a besoin d’un attribut obligatoire.

D’autres attributs complémentaires peuvent aussi être ajoutés au besoin sur les relations ou sur les chemins, par exemple source=*.

• Relations OSM de délimitations territoriales

Les relations type=boundary servent à regrouper des frontières afin de délimiter des territoires, y compris leurs éventuelles enclaves. Le recours à des relations pour ce type d’objet évite de devoir superposer dans OSM les parties communes des délimitations appartenant à des entités territoriales de même niveau hiérarchique ou de niveaux hiérarchiques différents.

Les territoires cartographiés peuvent être de nature différente, comme en atteste la page Taginfo² de la clé boundary=* : aires protégées, parcs nationaux, zones d'exploitation forestière, territoires administratifs religieux...

Cependant, les territoires dans OSM sont en très grande majorité des entités administratives dépendant d’une autorité publique, le plus souvent subdivisées depuis l’échelle nationale en différents échelons emboîtés qui, dans le monde francophone, prennent le nom de régions, provinces, districts, départements, préfectures, cercles, cantons, communes, villages, etc. selon le pays.

Cette section sur les relations OSM de délimitations territoriales va d’abord expliquer les spécificités de ce type de relations, puis détailler leur édition dans JOSM à travers différents exemples existants sur des territoires d'Afrique subsaharienne (Guéckédou, Togo, Ouagadougou, Bangui, Conakry), avant de décrire les différentes manières de les télécharger en fonction du besoin. Elle se conclura par la présentation d’un exemple existant de relations particulièrement complexes impliquant des enclaves emboitées.

Spécificités des relations de délimitations territoriales

Les limites administratives intégrées dans OSM émanent de préférence de données de référence officielles, dont la licence les rend compatibles avec la licence ODbL. Ce n’est qu’en l’absence de telles données et dans les cas où ces données s’avèrent incomplètes ou de mauvaise qualité qu’il sera nécessaire aux contributeurs OSM de les constituer.

Si le premier échelon administratif est déjà présent dans OpenStreetMap, il n’en va pas nécessairement de même au-delà, et donc a fortiori pour les niveaux administratifs les plus fins, en particulier ceux dépendant des autorités locales, moins habituées à rendre disponibles des jeux de données de référence sous licence libre ou en manque de capacités pour les produire.

La méthodologie de cartographie présentée par la suite va s’attacher en particulier sur la cartographie des niveaux administratifs au sein des agglomérations urbaines, en s'appuyant sur l’exemple de Ouagadougou, qui montre une intégration des noms de délimitations dont la géométrie reste encore inconnue.

Membres, attributs et rôles

Dans OSM, les délimitations administratives sont identifiées par les attributs suivants :

• type=boundary

• boundary=administrative

• admin_level=* qui indique l’échelon administratif de la délimitation au sein du pays considéré.

• name=*

• source=* dont l’indication est toujours recommandée

Les valeurs pour admin_level=* font l’objet de discussions et décisions pour chaque pays au sein de la communauté OSM et sont indiquées dans le tableau de la page wiki suivante (en anglais, celle en français étant incomplètement traduite) :

https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative

Au cas où les échelons administratifs d’un pays ne seraient pas encore renseignés dans ce tableau, il convient alors de discuter au sein de la communauté OSM locale pour décider quels attributs admin_level=* employer, puis de mettre à jour le tableau.

admin_level=2 correspond toujours aux frontières nationales des pays définis dans la liste ISO 3166³. Souvent, admin_level=8 correspond au dernier niveau administratif géré par l'administration centrale nationale, les deux suivants correspondant à des subdivisions gérées par les autorités locales, comme par exemple les quartiers à l’intérieur des agglomérations urbaines. Les niveaux non utilisés sont indiqués N/A.

En ce qui concerne les échelons administratifs supérieurs, en plus de leurs délimitations, il est recommandé d'intégrer dans la relation OSM leur chef-lieu, c'est-à-dire l’objet OSM cartographié sous forme de noeud et comportant l’attribut place=*. Un chef-lieu possède alors dans la relation le rôle spécifique admin_centre. Les relations d’échelons inférieurs (quartiers urbains notamment) qui n’ont pas de chefs-lieux n’en seront alors logiquement pas pourvus. Parmi les autres types de rôles possibles⁴, il est possible de rencontrer parfois sur certaines relations existantes les rôles subarea, désormais déconseillé (car contesté et redondant) ou label, destiné à positionner une étiquette pour un rendu OSM.

Attributs des chemins

A la différence des relations type=multipolygon, il est demandé⁵ que les chemins de délimitations administratives portent toujours certains attributs :

• boundary=administrative

• admin_level=* qui indique l’échelon administratif le plus élevé du chemin lorsqu'il est partagé par différents échelons administratifs

• source=* dont l’indication est toujours recommandée

En dehors de ces attributs propres à leurs propriétés de délimitation administrative, les chemins incluent parfois d’autres attributs comme par exemple waterway=* lorsqu’un cours d’eau constitue une délimitation territoriale.

Éditer dans JOSM des relations de délimitations territoriales administratives

Dans cette sous-section, un pas-à-pas permettra de détailler la création de relations de délimitations territoriales administratives en s'appuyant sur l’exemple relativement simple de la ville de Guéckédou qui comporte deux échelons hiérarchiques. Ensuite, des relations plus complexes avec de nombreux échelons hiérarchique et des chefs lieux seront abordées à travers l’exemple du Togo, puis le rôle subarea qui est désormais déconseillé, mais néanmoins toujours présent dans beaucoup de relations de délimitations territoriales. Enfin, sera présentée la méthodologie employée sur la ville de Ouagadougou pour intégrer des chefs-lieux de d’échelons administratifs dont les délimitations territoriales ne sont pas encore cartographiées dans OSM.

Pas-à-pas de création

L'apprentissage pas-à-pas qui suit s’appuie sur l’exemple existant de la ville de Guéckédou dans le sud-est de la Guinée.

A partir de l’ensemble des chemins OSM constituant les délimitations de la commune et de ses quartiers, d’une carte indiquant le nom de chaque quartier et des indications du wiki OSM concernant les admin_level=* de Guinée, vont être créées deux relations de délimitations administratives : une de l’un des quartiers de Guéckédou et une de la délimitation de la commune.

Le wiki OSM indique les attributs suivants pour les échelons administratifs en Guinée :

• Régions : admin_level=4

• Préfectures : admin_level=6

• Communes : admin_level=8

• Villages : admin_level=9

• Quartiers : admin_level=10

Guéckédou prendra donc l'attribut admin_level=8 et ses quartiers admin_level=10.

| Ouvrir le fichier GLEDO_relations_delimitations_Gueckedou.osm avec la méthode de son choix

Les données se présentent ainsi :

| Ouvrir le fichier GLEDO_relations_delimitations_Gueckedou_nom.pdf

Ce document permet de connaître les noms des différents quartiers de Guéckédou.

La première étape du pas-à-pas va consister à créer une relation de type boundary=administrative du quartier de Nongolo situé au nord de la ville.

| Sélectionner un par un, dans l’ordre de leur succession dans le sens horaire ou dans le sens anti-horaire (au choix), tous les chemins ouverts constituant le contour du quartier

La limite ouest du quartier correspond à une partie du fleuve Ouaou. La sélection doit aboutir à ceci :

Comme expliqué plus haut, l’usage veut que les chemins composant une relation de limites administratives comprennent aussi les attributs boundary=administrative et admin_level=* du plus grand échelon administratif à laquelle appartient chaque chemin. Dans notre exemple, la plupart des chemins seront également des délimitations d’échelons administratifs supérieurs à celui du quartier de Nongolo. Néanmoins, afin de s’assurer au terme d’une session d’édition qu’aucun chemin de délimitation territoriale soit sans attribut admin_level=*, une bonne pratique peut être d’indiquer l’attribut admin_level=* de la relation en cours de création et de modifier cet attribut au moment de la création d’une autre relation d'échelon administratif supérieur.

| Ajouter aux chemins sélectionnés l’attribut boundary=administrative et l’attribut admin_level=* correspondant à l'échelon administratif de la relation

Dans notre exemple, l'échelon administratif du quartier a pour attribut admin_level=10. Le résultat doit aboutir à ceci :

| Se rendre dans le menu Préréglages>Relations>Multipolygone

| Saisir le nom du quartier puis cliquer sur le bouton

| Ajouter les attributs boundary=administrative et admin_level=10

| Ajouter le rôle de chaque membre de la relation

Tous les membres ont ici un rôle outer. La fenêtre devrait ressembler à ceci :

Attention : au cas où la zone des symboles géométriques (marquée 1 ci-dessus) n’affiche pas une boucle mais des chemins non connectés, cela signifie que la sélection des différents membres n’a pas été faite dans l’ordre où ils se connectent. Exemple de zone des symboles géométriques présentant ce cas de figure :

​​ 

Dans ce cas précis, les chemins des membres à 5 et 13 noeuds ne sont pas connectés entre eux. Il faut alors soit utiliser la souris pour attraper-déplacer-relâcher l’un d’entre eux, soit sélectionner l’un d’entre eux et utiliser les boutons et pour le déplacer jusqu'à faire apparaître le symbole de boucle réunissant les 4 membres de la relation.

| Cliquer sur le bouton Valider

Le calque comporte désormais une relation multipolygone de délimitation administrative d'échelon 10 (indiqué entre crochets dans le panneau Relations) comportant 4 membres nommée "Nongolo".

La deuxième étape du pas-à-pas va permettre de créer une relation de type boundary=administrative pour les délimitations de la ville de Gueckédou.

| Sélectionner un par un, dans l’ordre de leur succession dans l’un des deux sens (au choix), tous les chemins ouverts constituant ensemble le contour de la ville

La limite ouest du quartier correspond à une partie du fleuve Ouaou. La sélection doit aboutir une sélection de 11 chemins, dont l’un d’entre eux (au sud) est particulièrement court :

Seuls deux membres possèdent l’attribut boundary=administrative et admin_level=10, alors que leur plus grand échelon administratif va désormais être admin_level=8. Nous allons donc ajouter ces deux attributs aux 11 chemins qui vont composer la relation.

| Ajouter aux chemins sélectionnés les attributs boundary=administrative et admin_level=8

| Se rendre dans le menu Préréglages>Relations>Multipolygone

| Saisir le nom de la ville puis cliquer sur le bouton

| Ajouter les attributs boundary=administrative et admin_level=8

| Ajouter le rôle de chaque membre de la relation

Tous les membres ont ici un rôle outer. La fenêtre devrait ressembler à ceci :

A nouveau, il faut bien s'assurer que la zone des symboles géométriques montre une boucle entre les 11 membres. Si ce n’est pas le cas, résoudre le problème comme indiqué plus haut pour le quartier de Nongolo.

| Cliquer sur le bouton Valider

Le calque comporte désormais deux relations de délimitations administratives. Certains chemins appartiennent aux deux.

| Sélectionner l’un des chemins appartenant aux deux relations

Ce chemin appartient bien aux deux relations multipolygones de délimitations administratives présentes dans le calque, l’une avec 11 membres d’échelon 8 (la commune de Guéckédou), l’autre avec 4 membres et d’échelon 10 (le quartier de Nongolo), comme indiqué dans le panneau Relations. De fait, il comporte l’attribut admin_level=8 (et non admin_level=10).

Pour qui souhaite s'entraîner à créer des relations de quartiers, il est bien sûr possible de poursuivre la création des autres quartiers de Guéckédou. Le résultat final doit correspondre au fichier GLEDO_relations_delimitations_Gueckedou_final.osm.

Cartographie d'échelons administratifs comportant des chefs-lieux

Si les quartiers et certaines communes ne comportent pas de chefs-lieux, les échelons administratifs supérieurs (départements, cercles, districts, etc.) en possèdent. L’exemple qui suit va montrer comment les chefs-lieux sont intégrés dans les relations des régions du Togo. Outre ses frontières nationales, ce pays possède comme échelons administratifs des régions, des préfectures, des communes, et pour la capitale Lomé, également des arrondissements et des quartiers, soit un total de 96 relations de type boundary=administrative.

| Ouvrir le fichier GLEDO_relations_delimitations_Togo.osm

| Zoomer sur Lomé au sud du pays

| Sélectionner la frontière entre Ghana et Togo au sud du quartier Soviépé, sélectionner la relation "5e arrondissement" et l’ouvrir en cliquant sur le bouton

Le chemin est indiqué par la flèche de la souris sur l’aperçu ci-dessous :

On voit dans la fenêtre des Attributs que ce chemin est membre à la fois de la frontière entre Togo et Ghana (admin_level=2), de la région de Lomé (admin_level=4), du 5e arrondissement (admin_level=9) et du quartier Soviépé (admin_level=10).

Le panneau Relations montre que la relation du 4e arrondissement comprend non seulement des membres de rôle outer, mais aussi un membre admin_centre, placé en haut de ​​ la liste. Il s’agit d’un ponctuel portant les attributs place=district et name="5e Arrondissement".

Relations comportant des membres avec le rôle subarea

Comme vu plus haut, il est désormais déconseillé d'ajouter comme membres d’une relation type=boundary des relations d'échelons inférieurs et donc d'utiliser le rôle subarea, néanmoins un grand nombre de relations de délimitations administratives conservent ce type de membres créés par le passé. De fait, tous les échelons administratifs du Togo de niveau 2 à 9 ont parmi leurs membres les relations d’échelon inférieur avec le rôle subarea.

Par conséquent, pour ces relations, les onglets "Relations parentes" et "Relations enfants" ne sont pas vides.

| Si besoin, ouvrir à nouveau le fichier GLEDO_relations_delimitations_Togo.osm, sélectionner la relation "5e arrondissement" et l’ouvrir en cliquant sur le bouton

| Cliquer sur l’onglet Relations parentes

La fenêtre affiche :

| Cliquer sur l’onglet Relations enfants

La fenêtre affiche les relations frontière[10] listées également avec le rôle subarea dans l'onglet Attributs et membres.

Méthode de cartographie d'échelons administratifs dont le nom est connu mais pas les délimitations

Un cas de figure relativement courant est de connaître le nom de certains échelons territoriaux cartographiés via des contributions trouvant leur source dans une connaissance du terrain ou une enquête de terrain, sans pour autant connaître leurs délimitations précises. C’est notamment le cas pour les quartiers de grandes agglomérations urbaines. Ajouter ces délimitations fait généralement partie des objectifs de la communauté OSM locale, mais en attendant, il est possible d’indiquer les noms connus de ces délimitations au sein de leurs relations parentes. Cette section décrit la méthode utilisée au Burkina Faso⁶.

| Ouvrir le fichier GLEDO_Ouagadougou_relations_OSM_20200228.osm

| Zoomer sur Ouagadougou

Les délimitations territoriales sont présentes sur le territoire jusqu’à l'échelon administratif des communes (admin_level=6), et comprennent plusieurs localités.

| Sélectionner la localité de Zékounga à l’ouest de Ouagadougou

Zékounga est un village de l’échelon administratif admin_level=8, comme Tinsouka ou Dondoulma à proximité.

| Sélectionner la délimitation à l’ouest de la commune de Ouagadougou

Cette délimitation territoriale correspond à l'échelon administratif des communes (admin_level=6).

| Sélectionner au bas de la fenêtre des Attributs la frontière [6] ("Tanghin-Dassouri"), faire un clic droit et cliquer sur Modifier

La fenêtre d'édition de la relation montre les informations suivantes :

Sont présents dans la relation :

• Le chef-lieu de la commune (Tanghin-Dassouri) avec son rôle admin_centre

• Les différentes délimitations territoriales qui réunies et ordonnées constituent un chemin fermé

• Les différents chefs-lieux des villages présents sur la commune, dont le rôle est subarea:FIXME

subarea:FIXME, qui en 2020 n’est pas documenté dans le wiki OSM, combine le rôle subarea et la clé FIXME. Ce rôle temporaire a vocation à être supprimé de la relation lorsque seront intégrées dans OSM les délimitations de l’échelon territorial dépendant de ces chefs-lieux. Dans la mesure où le rôle subarea est désormais déconseillé, il conviendra alors de supprimer également ces chefs-lieux de villages comme membres des relations de niveau admin_level=6.

Télécharger des relations de délimitations territoriales

Plusieurs manières de télécharger dans JOSM des objets relations de délimitations territoriales peuvent être envisagées, en fonction des objectifs (analyse, édition, etc.) et de l’échelle de travail.

Télécharger une zone de travail et filtrer des relations de délimitations territoriales

Au cas où la zone de travail n’est pas trop grande et où l’on veut pouvoir afficher au besoin tous les objets OSM de la zone, il est possible de télécharger toutes les données et activer un filtre permettant d’isoler les délimitations territoriales.

| Télécharger la zone de travail contenant la ou les relations désirées

| Activer un filtre excluant les autres données autres que les délimitations territoriales, en les laissant apparaître en noir ou en les masquant totalement

Ce filtre laisse apparaître les autres objets en noir :  

Ce filtre masque totalement les autres objets :  

Télécharger les membres incomplets d'une relation

Au cas où la zone de téléchargement n’a couvert qu’une partie de l’espace couvert par les membres de la relation, certains membres n’ont pas téléchargés. La fenêtre de modification des relations liste bien tous les membres appartenant à la relation éditée, mais indique comme "Incomplet" chacun des membres non présents dans le calque. Le téléchargement des membres manquants va être illustré via un exemple sur la délimitation territoriale de la commune de Bangui en République centrafricaine.

| Ouvrir le fichier GLEDO_Bangui_relation_incomplete.osm avec la méthode de son choix et sélectionner la délimitation territoriale au milieu de la zone

Dans l’exemple ci-dessous, la zone téléchargée ne comprend qu’une petite partie de la délimitation territoriale de la commune de Bangui :

La fenêtre de modification de la relation montre les membres incomplets :

Pour autant, les membres incomplets sont partiellement connus. Quand un objet appartenant à une relation est téléchargé, certaines informations concernant cette relation sont donc également téléchargées : identifiant de la relation, attributs de la relation, liste ordonnée de ses membres avec leur identifiant (celui-ci n'apparaît pas dans la fenêtre), leur type d’éléments OSM et leur rôle respectif. Mais pour les membres qui ne sont pas présents dans le calque, le détail de leur géométrie et le nombre de leurs noeuds ne sont pas connus. Il convient de ne pas éditer une telle relation incomplètement téléchargée, mais de télécharger au préalable les membres incomplets.

| Faire un clic droit sur la relation dont le téléchargement doit être complété dans le panneau Relations et choisir Télécharger les membres incomplets

Le panneau Relations affiche désormais :

La fenêtre Modifier la relation contient désormais l’ensemble des informations des membres de la relation de la délimitation de la commune de Bangui :

Télécharger une relation ou des relations spécifiques par leur identifiant

Au cas où l’on souhaite ne télécharger qu’une seule relation et pas les autres objets aux alentours, il est possible de la télécharger via son identifiant, qu’il faut connaître au préalable.

| Se rendre sur openstreetmap.org, rechercher ou zoomer jusqu’à la délimitation territoriale

| Cliquer sur l’outil de requête sur les objets puis sur le contour de la délimitation territoriale

Dans l’exemple ci-dessus, la relation recherchée est celle de la commune de Dubréka (en Guinée). Le premier objet indiqué "Limite communale #420106572" correspond au chemin membre de cette relation, non à la relation elle-même qui apparaît comme "Limite communale Dubréka".

| Dans les résultats de la colonne de gauche, cliquer sur la délimitation territoriale désirée, qui sauf exception comporte un nom

| Dans la fiche d'information, sélectionner l’identifiant et le copier avec les touches CTRL+C

Dans l'exemple, l’identifiant de la relation de l’exemple est 6251938 :

| Dans JOSM, se rendre dans le menu Fichier>Télécharger un objet... ou utiliser les touches CTRL+MAJ+O

| Dans la fenêtre qui s’est ouverte, choisir Relation dans la liste déroulante Type, coller l’identifiant de la relation et cocher les cases désirées

Le bas de la fenêtre explique comment télécharger plus d'un objet.

| Cliquer sur le bouton Télécharger un objet

Télécharger l’ensemble des relations de délimitations territoriales à l'intérieur d’un territoire

Pour être sûr de télécharger une relation de délimitation territoriales et l'ensemble des relations d’échelon inférieur au sein de son territoire, le plus efficace est d’utiliser une requête Overpass. Le résultat peut contenir des relations de rang égal ou supérieur si elles partagent un membre (en général un chemin de délimitation commun) et ces relations seront alors incomplètes.

Dans l'assistant de JOSM ou du site overpass-turbo⁷, il suffit d’utiliser la requête suivante :

boundary=administrative in Nom_de_ la_delimitation

Si Nom_de_ la_delimitation comprend au moins un espace, il convient de le placer entre des guillemets doubles :

boundary=administrative in "Nom de la delimitation"

Pour la ville de Conakry, le script Overpass QL est le suivant :

[out:xml][timeout:90];

{{geocodeArea:Conakry}}->.searchArea;

(

​​ nwr["boundary"="administrative"](area.searchArea);

);

(._;>;);

out meta;

Par exemple, la requête boundary=administrative in Lomé utilisée dans l’outil JOSM Télécharger depuis l'Overpass API aboutit aux données contenues dans le fichier GLEDO_relations_delimitations_Lome_20200508.osm.

On remarque que ce résultat contient une relation Togo marquée incomplète : il s’agit de la frontière nationale dont l’un des segments correspond à un segment de la délimitation de Lomé.

Exemple de relations territoriales complexes avec enclaves emboîtées

Certaines délimitations territoriales sont enclavées ou possèdent une enclave au sein d’autres délimitations territoriales. Le cas le plus complexe est la commune belge de Baerle-Duc en Flandre, située en partie et de manière discontinue (avec des petites enclaves dispersées) dans la commune hollandaise de Baerle-Nassau située dans la province hollandaise du Brabant Septentrional. Baerle-Duc possède en plus sur son propre territoire des enclaves de Baerle-Nassau⁸.

Le fichier GLEDO_relations_Baerle-Nassau_Baerle-Duc.osm montre cette situation complexe. L’enclave hollandaise sélectionnée ci-dessous intervient à la fois dans un rôle inner pour les relations de la Flandre et de la commune de Baerle-Duc belge et dans un rôle outer pour la province hollandaise du Brabant septentrional et la commune de Baerle-Nassau :

• Ressources vers d’autres types de relations OSM

Cette section propose un bref aperçu et des ressources documentaires pour la cartographie de deux autres grandes catégories de relations OSM, listées dans la page https://wiki.openstreetmap.org/wiki/FR:Relations.

Itinéraires

Le type de relation route permet de cartographier dans OSM toutes sortes d'itinéraires : de bus, routiers, de randonnées cyclables, pédestres, de ferries, de vélos de montagne, d’énergie, de trains, de skis, etc. (classés par ordre de fréquence dans Taginfo⁹). Ces itinéraires peuvent être composés de très nombreux objets traversant plusieurs régions voire plusieurs pays, comme dans le cas de grandes infrastructures autoroutières.

La page wiki https://wiki.openstreetmap.org/wiki/FR:Relation:route présente un rapide panomara de ces types de relations et de leurs attributs les plus courants.

Les itinéraires de transport en commun constituent un type de relations de type route. La page https://wiki.openstreetmap.org/wiki/FR:Transports_publics présente différents types de transport public et introduit leur cartographie dans OSM. Celle-ci utilise le modèle dit public_transport v2 qui prend en compte toutes les variantes et directions de la ligne, ainsi que les informations communes aux différents services. Ce modèle utilise les conventions suivantes :

• Les différents trajets (par exemple : trajet aller, trajet retour) d’une ligne de transport constituent chacun une relation route à part

• Dans la relation route de chaque trajet, sont regroupés à la fois les différentes sections de voie empruntées par les véhicules, l’emplacement des arrêts des véhicules sur les voies (attribut public_transport=stop_position) et l'emplacement des voyageurs en attente en retrait des voies (attribut public_transport=platform), tous ordonnés en respectant scrupuleusement l’ordre de parcours des véhicules

• Il est nécessaire de découper les sections de voies OSM existantes si un itinéraires ne les empruntent pas en totalité

• Les zones d'attente des voyageurs peuvent être décrites avec précision comme le montre la page https://wiki.openstreetmap.org/wiki/FR:Tag:public_transport%3Dplatform

• L'ensemble des trajets d’une même ligne est regroupé au sein d’une relation de type route_master

La page https://wiki.openstreetmap.org/wiki/FR:Bus détaille cette approche pour les lignes de bus.

La liste de discussion https://lists.openstreetmap.org/listinfo/talk-transit est anglophone, mais l’association OSM France a créé une liste de discusion francophone sur le sujet, accessible depuis la page http://listes.openstreetmap.fr/wws/info/transport.

La page https://wiki.openstreetmap.org/wiki/FR:Public_transport/Tools présente les différents outils OSM pouvant être utilisés pour la cartopraphie des transports en commun. Pour l'édition dans JOSM, le greffon PT_assistant¹⁰ est l’outil de référence. Concernant les besoins de contrôle de qualité, peuvent notamment être utilisés des règles de validation Jungle Bus à activer dans les préférences de JOSM et des services en lignes comme Osmose et OSM Inspector, qui intègrent tous deux des règles de validation spécifiques à cette thématique.

Réseaux hydrographiques

La relation de type waterway permet de regrouper en une relation les différents objets OSM composant un même cours d’eau : sections linéaires orientées dans le sens de l’écoulement, polygones représentant le lit mineur, îles éventuelles. La cartographie des cours d’eau est expliquée dans la page https://wiki.openstreetmap.org/wiki/FR:Cours_d'eau du wiki OSM que complète la page https://wiki.openstreetmap.org/wiki/Rivers (seulement disponible en anglais). La communauté OSM française a créé une page wiki qui peut être reprise pour être adaptée à un contexte géographique différent : https://wiki.openstreetmap.org/wiki/France/Cours_d'eau.

La relation de type waterway est composée de rôles spécifiques : main_stream, side_stream et spring servant à caractériser respectivement les membres constituant le cours principal, les cours secondaires et la source du cours d'eau¹¹. Il n’existe pas encore de proposition pour constituer des relations de bassins-versant à partir de relations de cours d’eau, ni de proposition acceptée¹² pour la classification des cours d’eau, qui prendrait en compte notamment le nombre de Strahler¹³.

Par conséquent, il n’existe pas jusqu’à présent de relation route_master (comme pour les relations de type public_transport) ou d'emboitements de relations en fonction d’échelons (à la manière des admin_level des délimitations territoriales). Seul l’attribut optionnel spécifique (destination=*) permet d’indiquer le nom de la rivière, fleuve ou océan dans lequel se jette le cours d'eau.