WikiProject France/Limites administratives/Tracer les limites administratives
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 (avec éventuellement des enclaves et/ou des exclaves)
- Tag:natural=coastline est le tag identifiant les lignes côtières. Ces lignes sont aussi utilisées par certaines relations.
La méthode
 |
Considérons trois zones A, B et C qui sont des entités administratives de niveau égal (des communes, par exemple). | |||||||||||||||||||||||||||||||
 |
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). | |||||||||||||||||||||||||||||||
 |
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
Membres
Il existe une proposition pour ajouter le node symbolisant le chef-lieu dans la liste des membres. A titre indicatif (pas encore officiel):
|
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
- décalage relativement faible (acceptable)
- 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 tagués place=village ou place=town et qui contiennent le nom, la référence INSEE, la population, le postal_code=*, 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, leur intérêt devient moindre et il est courant et 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. Le noeud peut alors être plus efficacement utilisé pour représenter le chef-lieu de la commune, c'est à dire le "centre" (défini à l'appéciation du contributeur) du regroupement de population qui contient 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.
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.
 |
Proposition 1Le 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. |
|
 |
Proposition 2Un 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.
 |
* 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
- type=boundary
- boundary=administrative
- admin_level=2
- name=* (Le nom du pays, qu'on pourra décliner en name:en=France name:it=Francia ...)
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 :
- border_type=nation
- left:country=France
- right:country=LautrePays
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
- type=boundary
- boundary=administrative
- admin_level=4
- name=* (Le nom de la région)
En proposition :
- Une région dispose-t-elle d'un numéro ? (voir aussi http://fr.wikipedia.org/wiki/Codes_géographiques_de_la_France).
- 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
- type=boundary
- boundary=administrative
- admin_level=6
- name=* (Le nom du département)
- ref=* (Le numéro du département, par ex. Savoie : ref=73)
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
- type=boundary
- boundary=administrative
- admin_level=8
- name=* (Le nom de la commune)
- ref:INSEE=* (le code INSEE de la commune, attention le INSEE est bien en majuscule)
- addr:postcode=* Le code postal de la commune lorsque celle-ci n'en utilise qu'un seul
É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
- type=boundary
- boundary=local_authority
- name=* avec le nom officiel, commençant par "Communauté de Communes...", "Communauté d'Agglomération...", etc.
- local_authority:FR=* avec la valeur CC pour communauté de communes, CA pour communauté d'agglomération, CU pour communauté urbaine, SAN pour un syndicat d'agglomération nouvelle ou metropole pour une métropole, pour décrire le statut exact de l'EPCI.
- ref:INSEE=* (Le code attribué par l'INSEE à l'EPCI, qui est son numéro de SIREN à 9 chiffres)
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
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)
