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(en), 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
 |
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=*). | |||||||||||||||||||||||||||||||
 |
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
On peut, si on le souhaite, ajouter le node symbolisant le chef-lieu dans la liste des membres:
|
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
- En zone montagneuse (et particulièrement en altitude, où les sommets et crêtes servent de frontières naturelles), il y a peu ou pas d'habitants ou d'installations l'accès à ces endroits étant particulièrement difficile. De fait le cadastre recense peu de besoin de délimiter des zones privées ou des zones d'aménagement communal. Des règles de protection de l'environnement n'autorisent pas non plus la délivrance par les seules communes de permis de construire pour certains aménagements, sans concertation à un niveau supérieur ni sans agrément préfectoral, voire une décision de l’État.
De fait les frontières intercommunales en zone montagneuse suivent les frontières naturelles dont la haute précision n'est souvent pas pas nécessaire (il en est de même de la séparation des communes sur les cours d'eau dont l'étendue varie avec le temps et la météo et où les communes doivent assurer conjointement une protection et surveiller leur aménagement). Les communes ayant géré chacune leur propre cadastre ont rarement besoin de définir des limites précises, sauf pour certains usages privés (par exemple des exploitations agricoles ou forestières, ou des aménagements de réseaux comme les lignes électriques sur lesquelles porte une fiscalité locale selon la surface occupée ou des obligations d'information de leur usage de par les exploitants autorisés).
Les lignes naturelles de crêtes et les sommets sont souvent imprécis et non marquées physiquement sur le terrain (surtout en hiver ou sur les glaciers), lequel est en évolution constante au cours de l'année. Des points de référence peuvent avoir été mesurés et dans certains cas des bornes géodésiques installées pour les marquer, mais leur observation à distance est souvent difficile en raison du masquage par le relief, la végétation, ou la couverture neigeuse.
Ces frontières sont donc assez floues et il est naturel que les planches cadastrales de deux communes ne s'accordent pas exactement dans ces zones où les communes ne peuvent même pas exercer seules leur compétence (ou bien les ont transférées à un organisme de gestion de parc naturel auquel adhère un ensemble de communes concernées).
Autant que possible on évitera de toucher aux points géodésiques importés dans la base de données: ceux qui y sont sont normalement marqués sur le terrain mais souvent il n'y en a pas assez pour couvrir précisément la totalité de la frontière. Un conflation est donc nécessaire pour raccorder les tracés de limites intercommunales (qui restent plus flous de toute façon que les lignes réellement tracées dans la base.
Pourtant on souhait représenter le plus fidèlement possible la réalité physique du terrain (par exemple pour les randonneurs ou sportifs) d'autant plus que les zones montagneuses sont des zones dangereuses où une bonne précision de la représentation permet de mieux prévenir certains dangers : les lignes de crêtes doivent donner une représentation fidèle de leur forme même si tout les points autour sont légèrement décalés (mais de façon homogène) par rapport aux relevés GPS ou aux positions géodésiques exactes.
Cela est d'autant plus nécessaire que les points géodésiques sont établis avec une précision élevée alors que l'imagerie aérienne ou satellitaire ne corrige pas toujours correctement toutes les déformations induites par le relief (les photos ne sont pas prises exactement à la verticale des lieux) et que d'une version à la suivante de l'imagerie, on peut voir ces corrections évoluer avec le temps.
Pour éviter de toucher aux points géodésiques sur ces frontières naturelles (qu'il peut être nécessaire de réviser souvent), il est déconseillé de coller ces frontières en les faisant passer exactement sur ces points géodésiques. On peut se contenter d'un tracé utilisant un nœud voisin : OSM permet de facilement poser un nœud distinct à quelques centimètres d'un autre, de sorte qu'il reste possible de ne pas toucher aux points géodésiques). Maintenir un léger écart de quelques centimètres entrez une frontière et un point géodésique ne changera pas significativement l'exploitation de la carte, la différence étant non significative sur le terrain. Garder les points géodésiques détachés de tout contour évite leur déplacement accidentel lors de la mise à jour des contours naturels. De plus les frontières naturelles peuvent facilement bouger avec le temps alors que les points géodésiques marqués conservent un rôle réglementaire: il ne suffit pas de replacer ce point géodésique là où il était, car même le point marqué a pu bouger un peu avec le temps.
On ne déplacera les points géodésiques que lors de leur mise à jour sur leur fiche de référence réglementaire: suite à cette modification on pourra procéder à un réalignement plus global des zones situées autour mais cela peut être gênant pour continuer l'exploitation des données cadastrales existantes ou de l'imagerie aérienne, ou pour des mises à jour provenant de relevés réalisés par des visites sur le terrain. Tant que les réajustements nécessaires sur un grand nombre de points proches ne sont pas nécessaires et n'atteignent pas des distances significatives, il vaut mieux ne rien ajuster et essayer de coller à la fidélité de l'imagerie aérienne (là où elle semble n'avoir pas de gros défauts souvent très visibles de raccordement).
De plus laisser les points géodésiques inchangés permettra de les vérifier : ils peuvent avoir été eux-mêmes mal saisis ou mal converti d'un système de référence à un autre (la géodésie réglementaire utilise un référentiel légal différent du référentiel mondial WGS84 utilisé dans OSM et calé sur l'observation satellitaire d'un géoïde modélisé qui ne change pas globalement même si localement le terrain s'est décalé avec le temps, alors que le référentiel géodésique légal s'appuie sur des points physiques au sol, qui conservent mieux les positions relatives sur leur triangulation). Les sources de données étant en fait différentes, et établies à des moments différents, il n'est pas possible de les accorder en totalité. On peut donc accepter des légers écarts inévitables entre la géodésie réglementaire et la géodésie observée.
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.
 |
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 :
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 :
- 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 :
- 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 :
- 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 municipaux ou communes associées
Il s'agit ici des arrondissements municipaux (urbains) de Paris, Lyon et Marseille, disposant d'une mairie d'arrondissement et d'un maire d'arrondissement.
Ailleurs ce sont des communes associées au sein d'une même commune, ou communes déléguées au sein d'une même commune nouvelle : elles disposent d'une mairie annexe, d'un maire délégué, de leur propre état-civil et d'un code INSEE spécifique (encore visible dans la codification des zones cadastrales dans le cadastre de la commune parente, ainsi que dans plusieurs fichiers officiels de l'INSEE ou le FANTOIR pour la nomenclature de la voirie et des lieux-dits mentionnant les "types de communes", et d'un code SIREN pour leur établissement) bien que ce ne soient plus des collectivités locales dotées d'un budget et d'une fiscalité propre et n'aient plus leur propre conseil municipal). Les communes associées conservent leur nom (y compris la commune principale siège du conseil municipal si la commune fusionnée a changé de nom). Les anciennes communes fusionnées sans le régime d'association ne sont pas représentées dans OSM.
Ces deux types de subdivision administrative d'une commune ne peuvent coexister au sein d'une même commune.
Les arrondissements départementaux qui sont une subdivision du département sont classés en admin_level=7.
Note: puisque les zones de service et commissions locales des intercommunalités (tels que les pôles de proximité de Nantes Métropole) peuvent regrouper plusieurs communes ou parties de communes (elles-même pouvant regrouper plusieurs quartiers administratifs ou zones d'aménagement), il n'est pas possible de leur attribuer un admin_level cohérent hiérarchiquement (ce découpage se fera dans le schéma des intercommunalités).
Sur la relation
Propositions :
- admin_type:FR=arrondissement municipal (à Paris, Lyon et Marseille) ou
- admin_type:FR=commune déléguée (dans une commune nouvelle) ou
- admin_type:FR=commune associée (dans une commune en fusion-association)
- ref:INSEE=* (le code INSEE de l'arrondissement municipal, attention « INSEE » est bien en majuscule)
Sur les membres
Chemins
Établissements publics de coopération intercommunale (EPCI) à fiscalité propre
Pour les EPCI (communautés de communes, communautés d'agglomération, communautés urbaines et métropoles) 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 (ancien statut supprimé depuis janvier 2016), EPT pour un établissement public territorial (EPCI au sein de la métropole du Grand Paris) ou metropole pour une métropole, pour décrire le statut exact de l'EPCI. Note : la métropole de Lyon (Grand Lyon) n'est pas une métropole stricto sensu mais une collectivité territoriale à statut particulier .
- 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
- 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 :
- 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
- name=* avec le nom officiel, sans la mention "Canton de".
- political_division=canton
- ref:INSEE=* : le code attribué par l'INSEE au canton
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 :
- admin_centre (Le rôle admin_centre sera positionné sur le nœud représentant la commune chef-lieu de canton)