Structure des objets géographiques
Pour la création et le stockage des objets géographiques, le projet OpenStreetMap utilise une structure un peu particulière qui a été avant tout pensée pour permettre à tout le monde de pouvoir contribuer facilement. On peut ainsi ajouter et éditer des données sans avoir à connaître les concepts habituels manipulés par les professionnels de l'information géographique. Mais la force de ce modèle c'est que cette simplicité permet quand même de faire beaucoup de choses ! Et pour les contributeurs plus aguerris qui souhaitent aller plus loin et passer à la description d'objets plus complexes, il y a aussi des solutions qui sont proposées. Dans la suite de cet article, je vais entrer dans le détail de tous ces éléments en les illustrant avec des exemples concrets d'utilisation.
Le format osm et la structure générale des données
Si vous téléchargez des données brutes depuis OpenStreetMap, vous récupérerez un fichier au format .osm qui est le format par défaut proposé pour les données OSM. Il existe également d'autres formats qui peuvent être utiles mais je reviendrais dans un autre article sur ces cas particuliers. Un fichier .osm utilise le formalisme XML pour décrire tous les objets géographiques contenus dans la base de données d'OpenStreetMap. On peut directement visualiser son contenu à l'aide d'un simple éditeur de texte.
En parcourant le contenu, on retrouve les balises qui décrivent les valeurs attributaires des différents objets. En ce qui concerne la description géographique des éléments on peut remarquer que tous les éléments contenus sont décrits à partir de seulement 3 types de structures :
Et c'est tout ? Hé bien oui c'est tout ! Avec ça on peut vraiment créer tous les objets géographiques présents sur le monde entier dans OpenStreetMap. De plus, en analysant en détail le fichier on remarquera que les seules coordonnées géographiques présentes sont associées uniquement aux nodes. Il n'y en a pas dans les objets de type ways ou relations.
En fait la structure des objets géographiques dans OpenStreetMap est une structure hiérarchique : les nodes sont les primitives de base et sont positionnés géographiquement, les ways sont des ensembles de nodes et sont donc positionnés directement grâce aux nodes qu'ils contiennent et les relations sont des ensembles composites de nodes et de ways donc également positionnés grâce à leurs sous-éléments.
Les nodes 
Mais concrètement que représentent ces nodes, ways et relations ? Prenons un exemple en lien avec les objets traditionnels que l'on peut trouver dans le domaine de l'information géographique et des logiciels SIG : les points, les lignes et les polygones. Première analogie, la plus simple en fait : les nodes d'OSM = les points d'une couche SIG. Ce sont des objets ponctuels qui portent une information de positionnement grâce à deux coordonnées X,Y qui sont exprimées en latitude, longitude (système de projection EPSG:4326). Pour le moment, le modèle OSM ne diffère donc pas du modèle traditionnel.
Les ways 
Passons maintenant à l'analyse des ways. L'erreur serait ici de penser qu'un way = une ligne du monde SIG. Ils peuvent servir à ça en effet (on représentera une route par un way), mais pas que. Un way est en fait un objet linéaire qui passe par différents nodes positionnés géographiquement. La première différence avec une ligne d'une couche SIG c'est que le way en lui-même ne porte pas de coordonnées géographiques, il ne porte que les références des nodes par lesquels il passe. Si vous retirer ses nodes du fichier osm, le way ne sera plus géolocalisé. Deuxième différence : les ways servent également à représenter les polygones simples du modèle traditionnel ! En effet, il n'y a pas d'objets de types polygones dans OpenStreetMap. Si vous voulez représenter un polygone, vous dessinez un way fermé dont le premier node est égal au dernier. Mais cela n'est pas suffisant pour en faire un polygone. C'est en fait la sémantique des balises utilisées dans les valeurs attributaires qui donne automatiquement la nature de polygone à un way fermé. Si je met une balise junction=roundabout (un rond-point) sur mon way fermé, il représentera une ligne fermée pour un SIG. Si je lui affecte une balise building=yes le way est alors automatiquement considéré comme un polygone par OSM.
Les relations 
Il semblerait que l'on ai déjà décrit tous les objets possibles dans une couche SIG. A quoi peuvent donc servir les relations qui sont le dernier type de structure OSM ? En fait, ces relations n'ont pas d'analogie directe avec les objets du monde des SIG. Ce sont des objets composites qui vont permettent de décrire des choses plus complexes qui peuvent être de natures très diverses. On peut résumer une relation de la façon suivante : elle permet de regrouper dans un ensemble cohérent des nodes et des ways (ou même d'autre relations, on parlera alors de super-relations) dont l'ensemble forme un nouvel objet. On peut ensuite lui associer des valeurs attributaires qui servent à décrire cet ensemble.
Prenons un exemple : je souhaite ajouter dans OSM une ligne de bus. Pour faire ce travail, je vais commencer par créer les nodes qui représentent tous les arrêts de la ligne, puis je vais créer les ways qui représentent chaque petit bout de rue parcourue par la ligne de bus (dans les deux sens du parcours). Je vais ensuite sélectionner tous ces nodes et ces ways et créer une nouvelle relation dans laquelle je vais pouvoir tous les regrouper. Les balises qui indiquent qu'il s'agit d'une ligne de bus seront bien entendu associés à cette relation (type=route et route=bus). On pourra aussi y ajouter le nom de la ligne (balise name=), l'opérateur de transport (balise operator=) et éventuellent la couleur officielle associée à la ligne par l'opérateur (balise colour=). Toutes ces balises ne pouvaient pas être portées par un des sous-élément de la relation puisqu'elles n'ont une signification que dans le cadre de l'ensemble décrit par la relation.
Les relations sont des objets très puissants qui permettent de réaliser beaucoup de choses. Un autre exemple d'utilisation c'est le cas des frontières d'entités administratives. Si nous souhaitons tracer les frontières d'une commune A entourées par les communes B, C et D ; nous allons commencer par tracer des ways différents qui marquent la séparation de chaque couple de communes : un way pour le bout commun entre A et B, un autre entre A et C et un dernier entre A et D. Pour représenter la frontière de A, il me reste plus qu'à faire une relation qui regroupe chaque bout et de lui ajouter les balises qui vont bien : type=boundary, boundary=administrative, admin_level=8 (pour les communes), name=le nom de la commune A et ref:INSEE=le numéro INSEE de la commune. L'avantage de ce système c'est sa cohérence. Quand je tracerai les frontières de la commune B, je n'aurai plus besoin de tracer le way commun avec A. Je ferai simplement une nouvelle relation avec ce morceau commun déjà tracé comme sous-élément. Nous avons là un modèle topologique : impossible de créer un trou ou une superposition entre les frontières des communes A et B ! De plus, pour tracer les frontières d'une entité administrative supérieure (par exemple un département) le travail à faire est très léger : rien de plus à tracer, il suffit de prendre les bouts de ways utilisés par les frontières des communes en bordure de département et de créer une nouvelle relation. Simple et efficace n'est ce pas ?
Une autre possibilité d'utilisation des relations c'est le cas des polygones complexes. Nous avons déjà vu comment créer un polygone simple directement avec un seul way. Mais qu'en est-il si nous souhaitons représenter dans OSM un multi-polygone qui peut comporter plusieurs morceaux séparés ou des trous dans son intérieur ? Il suffit de sélectionner les différents ways, les regrouper dans une relation qui porte une balise type=multipolygon, et pour chaque way lui affecter ce qu'on appelle son rôle dans la relation. Les ways qui représentent les parties extérieures du multi-polygone seront en rôle outer, et les ways qui représentent les trous seront en rôle inner.
Enfin, un usage très répandu des relations concerne le système de représentation des numéros d'adresses postales, en lien avec leurs rues associées. Je reviendrai plus tard sur ce cas particulier dans un autre article dédié à cette problématique.