WikiProject France/Limites administratives/Tracer les limites administratives

From OpenStreetMap Wiki
Jump to: navigation, search

Cette page décrit la façon de définir les limites administratives dans la base d'OpenStreetMap. Notez que certaines anciennes pratiques sont en cours de discussion et qu'il est possible que de nouvelles règles soient prochainement définies, en particulier, sur la liste des tags figurant dans la relation ou sur les ways (en attendant, suivez ce guide: les changements qui seront approuvés par consensus dans le futur pourront facilement être appliqués aux données existantes à l'aide d'un script).

Bien que ces données soient fournies sans garanties, il est important de rappeler que ce projet sera sans doute l'unique fournisseur de limites administratives libres pour la France et que cela implique une certaine rigueur et responsabilité de la part de ceux qui souhaiteront y contribuer.

Le plugin cadastre-fr sur JOSM

En dehors des frontières internationales, et à moins de créer votre propre serveur WMS, vous devrez utiliser l'éditeur JOSM et le plugin cadastre-fr pour pouvoir accéder aux limites communales du cadastre en ligne. C'est à partir de cette source que l'essentiel des limites administratives pourront être mises en place dans OSM.

Les tags

  • boundary=administrative est le tag appliqué aux ways (polylignes) symbolisant une limite administrative (voir FR:Key:boundary)
  • admin_level=* combiné avec boundary=administrative donne le niveau administratif de cette limite. Consultez la page FR:Key:boundary pour voir toutes les valeurs par pays. Pour la France, les valeurs essentielles sont "2" pour le pays, "4" pour les régions, "6" pour les départements et "8" pour les communes.
  • Relation:boundary est la relation symbolisant l'entité administrative et regroupant l'ensemble des ways pour former un polygone
  • Tag:natural=coastline est le tag identifiant les lignes côtières. Ces lignes sont aussi utilisées par certaines relations.

La méthode

Boundary complete.PNG
Considérons trois zones A, B et C qui sont des entités administratives de niveau égal (des communes, par exemple).
Boundary eclate.PNG
Les ways communs aux trois entités ne sont pas dédoublés ou superposés. On segmente les ways pour isoler ceux qui font partie de plusieurs entités (en bleu sur la figure à gauche). On tague ensuite tous les ways avec :

(voir la page sur les conditions d'utilisation du cadastre pour comprendre l'importance du tag source=*).

Il existe une ancienne pratique, appliquée aux frontières internationales datant de l'époque où les relations n'existaient pas dans OSM qui est de donner le nom des pays bordant la limite. C'est pourquoi on peut retrouver sur les ways des régions, départements et même de communes:

Note : cette pratique devrait être abandonnée à terme et les noms être définis uniquement dans les relations (à l'exception des frontières internationales pour lesquelles aucune discussion n'est en cours).

Boundary polygone.PNG
Une fois tous les ways définis et tagués, on créé une relation qui symbolise l'entité administrative en liant entre eux les ways.

Tags de la relation

Key Value Remarque
type boundary
boundary administrative
admin_level 1..10 "8" pour une commune, "6" un département, "4" une région, etc.
name nom nom de la commune, département, etc.

Membres

Way Role Recurrence? Remarque
Way aucun / outer 1.. x Le polygone doit être fermé, c.à.d que chaque way est relié au suivant par son dernier node.

On peut, si on le souhaite, ajouter le node symbolisant le chef-lieu dans la liste des membres:

Way Role Recurrence? Remarque
Node admin_centre 1 Le node symbolisant le chef-lieu (dépend du niveau administratif, par exemple le node portant les tags place=city, name=Bordeaux pour la relation symbolisant le département de la Gironde).

Précision des limites communales sur le cadastre

Comme l'échelon maximal de constitution des données cadastrales est la commune, les raccords entre deux communes ne sont pas assurés par la DGFiP. Toutefois, les collectivités locales qui entreprennent la numérisation du cadastre peuvent faire coller les limites des bans communaux dans le respect des règles imposées pour le raccordement des feuilles cadastrales.

Les écarts que l'on peut constater entre deux communes adjacentes sont généralement minimes (inférieure à quelques mètres) pour peu que l'on se situe dans une zone non montagneuse (voir plus loin). La résolution de ces écarts peut se faire en privilégiant le contour d'une commune par rapport à une autre (en s'aidant éventuellement d'une troisième commune pour déterminer une moyenne), soit en établissant un tracé médian.

  • exemple de bonne superposition

Cadastre ok 1.PNG Cadastre ok 2.PNG Cadastre ok 3.PNG

  • décalage relativement faible (acceptable)

Cadastre bad 1.PNG Cadastre bad 2.PNG Cadastre bad 3.PNG

  • décalage important
à faire

Le problème peut se manifester par un décalage longitudinal ou transversal et laisse des espaces vides ou des chevauchements entre communes. Les écarts ne sont jamais constants. Ils peuvent diminuer le long de la frontière communale jusqu'à disparaître et réapparaître un peu plus loin.

Les zones de montagne

expliquer brièvement le mode de constitution des données cadastrales et l'importance du relief dans le calcul des distances

Les noeuds place=* qui contiennent déjà les informations de la commune

Dans la base de donnée OSM, vous constaterez qu'il existe déjà de nombreux noeuds taggués place=hamlet,place=village, place=town ou place=city et qui contiennent le nom, la référence INSEE ref:INSEE=*, la population, le addr:postcode=*, le "code_departement" de la commune. Ces informations proviennent en majorité d'un ancien import automatique des communes sous la forme de noeud. Mais depuis qu'il est possible d'avoir la commune sous forme de surface, il est recommandé par certains contributeurs (mais cela ne fait pas forcément consensus) de placer les informations de la commune sur la relation type=boundary de la commune et non sur le noeud. Celui-ci peut alors être plus efficacement utilisé pour représenter la position géographique du chef-lieu de la commune, c'est à dire le "centre administratif" (défini à l'appréciation du contributeur) du regroupement de population et où se trouve la mairie. Il est très courant que ce chef-lieu porte le même nom que la commune elle-même, mais comme ce n'est pas toujours le cas. Cela permet d'avoir dans OSM deux objets qui représentent des entités différentes (position de la ville/village et la commune par sa surface, l'une n'étant pas forcément au centre géométrique de l'autre).

Voir plus bas le récapitulatif des tags que l'on peut mettre sur la relation qui représente la commune.

Cas particuliers

Way appartenant à plusieurs niveaux administratifs

Un way qui fixe la limite entre deux communes peut aussi fixer la limite entre deux départements, deux régions et même deux pays. Ce way peut donc faire partie de 2,3 voir 4 relations différentes. Le tag admin_level=* porte dans ce cas le chiffre le plus bas, correspondant au niveau administratif le plus élevé (par exemple "4" pour une limite entre régions). On considère aussi que cet admin_level couvre implicitement tous les niveaux administratifs inférieurs. Donc, inutile de taguer tous les admin_level comme admin_level=4;6;8 mais uniquement admin_level=4.

Limites administratives utilisant des éléments physiques

Il est fréquent que des éléments naturels ou artificiels forment la limite entre deux communes : cours d'eau, voie de communication (routes, rues et chemins), etc. Souvent, ces éléments ne sont pas des objets cadastrés. La précision du tracé est largement indicative. Il est à noter que, dans le cas d'un cours d'eau, le tracé de parcelles en bordure peut ne plus refléter la réalité ; la rivière peut avoir significativement changé son lit sans que les limites de parcelles ne soient modifiées, ce n'est pas un signe d'erreur ou d'imprécision mais simplement la conséquence d'un mode de révision du plan cadastral qui ne tient pas compte de ce genre d'événements.

Il convient d'apprécier, dans ce cas de figure, autant la signification de la limite communale (contour d'un banc de sable, d'un îlot, par exemple) que le tracé géométrique pur.

exemples sur la Loire à l'est de Tours -> Vouvray/Montlouis-sur-Loire

Comme ces éléments doivent aussi figurer dans la base OSM avec leurs propres tags, il y a actuellement plusieurs approches pour combiner ces données physiques et administratives:

Trois entités administratives utilisent une rivière comme frontière naturelle.

With river boundary.PNG
Proposition 1

Le way symbolisant l'élément physique (rivière, route, etc) est segmenté sur la partie qui est utilisée comme frontière. Cette partie est ensuite ajoutée aux relations administratives concernées. Aucun tag spécial n'est ajouté au way, il conserve sa propriété de rivière ou de route (par exemple waterway=river).

Sur la figure à gauche, la rivière est coupée à 5 endroits et forme quatre segments utilisés comme limite administrative ("2", "3", "4" et "5") et les deux segments qui vont au-delà ("1" et "6"). Le segment "2" est ajouté à la relation de la zone B, le segment "3" aux relations de la zone B et C, etc.

With river duplicate boundary.PNG
Proposition 2

Un nouveau way doit être superposé à la rivière ou route en réutilisant les mêmes nœuds sur toute la portion de la limite administrative. Ce nouveau chemin superposé sera ensuite découpé en autant de morceaux que nécessaire pour être ensuite ajoutés aux relations. Seul le nouveau way superposé comporte les tags boundary=administrative et admin_level=x. Seul le ou les nouveaux chemins sont ajoutés dans les relations, l'élément physique ayant servi d'appui n'étant pas inclus.

Avantages et inconvénients de chaque méthode:
  • la méthode 1 présente l'avantage d'avoir un seul way, donc plus facile à éditer. L'inconvénient est qu'un way représentant une route ou une rivière va être segmenté en plusieurs morceaux sans justification à part administrative. Parfois, ces segments sont très courts. Mais il est aussi fréquent de segmenter des routes sans justification physique (par exemple, portion en sens unique ou changement de "ref")
  • la méthode 2 évite la segmentation d'une rivière ou d'une route. Les deux types d'information sont ainsi représentés dans deux entités (ou calques) séparés. On utilise les mêmes nodes pour être sûr qu'en cas d'ajustement des positions (par exemple, à partir de sources plus précises), l'entité "limite administrative" continue de longer la rivière. L'inconvénient est la plus grande difficulté d'éditer des ways superposés, surtout sur de longues distances.
Les limites administratives côtières

En France, il n'y a pas de disposition législative ou réglementaire précisant la limite en mer des frontières de commune, il a donc été décidé que le trait de côte servirait de limite aux communes, départements et régions coté mer en France voir débat. Dans certains cas, cela va à l'encontre de la représentation faite par le cadastre des frontières de communes, il faudra donc reprendre la limite coté mer pour la fusionner avec le trait de côte ou ajouter le trait de côte à la relation de l'entité administrative.

Port-admin boundary.png
* Cas des installations portuaires :

Il est très peu pratique de faire suivre à la limite administrative le contours de chaque quai et ponton situés à l'intérieur du port; de plus, certaines décisions de justice ont attribués à la commune la responsabilité et la légitimité sur ce qui se passe à l'intérieur du port (zone de mer enfermée partiellement par les limites en dur qui protègent de la houle). Il est donc proposé de choisir pour la limite de la commune le trait extérieur du port qui suit les barrières contre la houle. (Cette proposition n'est issue d'aucun consensus et uniquement proposée par sletuffe, à vous de choisir votre méthode)

(Représentation ci-contre en violet de la limite utilisée en mer pour la commune, le département, la région et la relation france "trait de côte")

La méthode appliquée aux rivières, routes, chemins, etc. précisée plus haut sera donc appliquée de la même manière au trait de côte.

Il est inutile d'adjoindre un tag admin_level=* au trait de côte. Mais on peut les ajouter comme membres des relations administratives au même titre que les autres ways.

Pour les limites de la France, il existe par ailleurs un way créé par un script à 12 milles des côtes pour délimiter les eaux territoriales (uniquement la France métropolitaine pour l'instant). Ce way qui longue les côtes françaises doit faire partie d'une relation symbolisant la France administrative. Mais pour les représentations cartographiques, une deuxième relation assemble les frontières terrestres avec les lignes côtières parce que les pays sont souvent représentés de cette manière par convention. Voir le tag land_area dans Relation:boundary.

Récapitulatif en France des tags selon le niveau administratif

29/09/2010 : Une discussion est (presque) en cours sur les niveaux et leurs usages.

Pays

Sur la relation
Sur les membres
Chemins

Les contours :

Les tags suivants, bien que toujours recommandés par le wiki anglais sur les différents chemins qui composent les frontières ont leur intérêt qui diminue avec la présence de relation :

Nœuds

Le chef-lieu :

  • role : admin_centre (Le rôle admin_centre sera positionné sur le nœud représentant la capitale : Paris)

Régions

Sur la relation

En proposition :

oui, dans le Code Officiel Géographique de l'INSEE : http://www.insee.fr/fr/methodes/nomenclatures/cog/region.asp . Mais ce numéro est-il utilisé ailleurs ?
oui, dans la nomenclature NUTS d'Eurostat. D'après wikipedia, ce numéro a tendance à remplacer le code INSEE.
voir aussi la nomenclature ISO-3166-2
Sur les membres
Chemins

Les contours :

Nœuds

Le chef-lieu :

  • role : admin_centre (Le role admin_centre sera positionné sur le nœud représentant la préfecture de région, par ex. Lyon pour Rhône-Alpes)

Départements

Sur la relation
Sur les membres
Chemins

Les contours :

Nœuds

En proposition : Le chef-lieu :

  • role : admin_centre (Le rôle admin_centre sera positionné sur le nœud représentant la préfecture de département ; par ex. Chambéry pour la Savoie)

Communes

Sur la relation

Éventuellement :

  • population=* La population de la commune (Cette information est disponible sur le site de l'INSEE est peut-être recoupée par la ref:INSEE on peut donc, ou pas, la mettre dans OSM)

Voir la page de discussion.

Voir la page décrivant l'import automatique de codes INSEE et codes postaux

Sur les membres
Chemins

Sauf si le trait est celui de la côte. Et, selon moi, sauf si le trait représente une autre réalité physique que simplement une limite de commune (route, rivière, falaise, etc.).

Nœuds

En proposition : Le chef-lieu :

  • role : admin_centre Le rôle admin_centre sera positionné sur le nœud représentant la chef-lieu de la commune, par ex. La Combe pour la commune Les Déserts, ou Paris pour la commune Paris. Pour des explications sur ce rôle, voir la page décrivant la relation boundary

Arrondissements urbains

Il s'agit ici des arrondissements municipaux (urbains) de Paris, Lyon et Marseille. Les arrondissements départementaux qui sont une subdivision du département sont classés en admin_level=7.

Sur la relation

Propositions :

  • admin_level=9
  • ref:INSEE=* (le code INSEE de l'arrondissement municipal, attention le INSEE est bien en majuscule)
Sur les membres
Chemins

Établissements publics de coopération intercommunale

Pour les EPCI (communautés de communes, communautés d'agglomération ou communautés urbaines) on n'utilise pas d'admin_level mais un autre balisage :

Sur la relation

Cette relation devra contenir comme membres les limites administratives de communes qui servent de frontière à l'EPCI, avec éventuellement le rôle outer.

En option :

  • alt_name=* pour un nom usuel s'il est différent du nom mis dans name=*
  • short_name=* pour un nom usuel s'il s'agit d'un sigle
  • website=* pour le site officiel de l'EPCI. Très utile pour comparer la liste des communes membres avec celle donnée par l'INSEE, qui est potentiellement obsolète
Sur les membres
Chemins

Les balises restent celles des limites de communes, elles ne refléteront pas le statut de limite d'EPCI.

Nœuds

En proposition :

  • role : admin_centre (Le rôle admin_centre sera positionné sur le nœud représentant la commune siège de l'EPCI)

Cantons

Les cantons ne sont pas (plus) une unité administrative mais électorale car elle sert à l'élection des conseillers généraux (conseillers territoriaux). On n'utilise pas non plus d'admin_level :

Sur la relation
Sur les membres
Chemins

Cette relation devra contenir comme membres les limites administratives de communes qui servent de frontière au canton, avec éventuellement le rôle outer. Quand il s'agit d'un canton contenant des fractions de communes, il devra s'appuyer sur un way balisé en boundary=political + political_division=canton

Nœuds

En proposition :

  • role : admin_centre (Le rôle admin_centre sera positionné sur le nœud représentant la commune chef-lieu de canton)