France/Tracer les limites administratives/Mise au point du modele des EPCI

From OpenStreetMap Wiki
Jump to navigation Jump to search

En juin 2011 la décision a été prise d'utiliser une relation boundary pour entourer les EPCI (Établissements publics de coopération intercommunale, parfois appelés intercommunalités) avec les tags suivants :

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

Voir aussi la page France/Limites administratives/Tracer les limites administratives#Établissements publics de coopération intercommunale.

Les informations qui suivent sont la trace des réflexions qui ont eu lieu auparavant, elles sont conservées à titre historique.

Préambule

Cette page a pour objet la poursuite de la discussion amorcée sur talk-fr (voir ce fil puis celui-ci). La finalité est multiple :

  • la mise au point concertée d'une modélisation pour les EPCI
  • en ricochet, la définition des tags pour les limites d'arrondissements départementaux

A noter que d'autres sujets (connexes) ont été abordés dans ce fil : la définition de limites cantonales (limites de circonscription électorale), la prise en compte des communes associées, la définition du contenu à placer en admin_level=10.

État des lieux

OSM

Wiki (pages établies)

Actuellement, la documentation du wiki sur l'étiquetage des limites administratives Françaises est :

  • Cette proposition n'est pas beaucoup (du tout ?) utilisée. Bien que le concept soit intéressant et novateur, la pratique est bien plus celle des type=boundary ou type=multipolygon sletuffe 10:05, 30 September 2010 (BST)

Wiki (autres pages)

Données citées en exemples

Sources WEB citées dans la discussion

Wikipédia

Légifrance

INSEE

Autres sources

Modèle de données et tags

Sur la page « Tag:boundary=administrative », il est noté pour la France que les niveaux administratifs suivants doivent être utilisés :

  • 1 : non utilisé
  • 2 : la France entière (y compris les DOM/ROM, les COM et les territoires à statut particulier)
  • 3 : la France métropolitaine ; extensions territoriales maritimes des départements/régions d'outre-mer ; COM ; territoires à statut particulier
  • 4 : (équivalent NUTS 2) les régions métropolitaines (les anciennes régions fusionnées restent au niveau 4 mais avec un tag "disused:") ; la collectivité de Corse ; les régions d'outre-mer.
  • 5 : les circonscriptions départementales (cas particulier, actuellement seulement utilisé depuis janvier 2015 pour l'adminsitration préfectorale de l'ancien département du Rhône).
  • 6 : (équivalent NUTS 3) les départements métropolitains ; la métropole de Lyon ; les départements d'outre-mer ; les subdivisions de la Polynésie française ; les provinces de la Nouvelle-Calédonie.
  • 7 : intercommunalités (ancienne proposition) les arrondissements départementaux ; les royaumes coutumiers (à Wallis-et-Futuna) ; les districts administratifs (dans les TAAF)
  • 8 : les communes simples ; les communes nouvelles (depuis 2012) ; les communes en fusion-association (depuis 1972) ; les villages coutumiers (à Wallis-et-Futuna où il n'y a pas de communes)
  • 9 : les arrondissements municipaux (à Paris, Lyon et Marseille) ; les communes déléguées (depuis 2012 dans une commune nouvelle) ; les communes associées (depuis 1972 dans une commune en fusion-association)
  • 10 : les quartiers administratifs ; les "grands quartiers" (dans certaines grandes villes) ; les anciennes communes fusionnées sans association ni délégation, reconverties en simples quartiers
  • 11 : les sous-quartiers (dans certaines grandes villes)

Sur la page « Tracer les limites administratives » il est proposer un schéma global ressemblant à avec quelques tags supplémentaires selon l’échelon : Sur la relation :

  • type=boundary
  • boundary=administrative
  • admin_level=[1-10]
  • name=*

En proposition :

  • admin_centre=* (Le rôle admin_centre sera positionné sur le nœud représentant la

« capitale » du territoire) Sur les chemins

  • admin_level=[1-10]
  • boundary=administrative

Cette page présente en proposition de placer les EPCI (Établissement public de coopération intercommunale) au niveau 7.

Problématique actuelle

  • certains voudraient ou appliquent déjà le COG INSEE comme référence pour le découpage administratif français en incluant cantons, quartiers, …
  • certains considèrent inapproprié le niveau 7 actuellement proposé pour les EPCI.
  • si les EPCI sont placées au même niveau que les communes, actuellement niveau 8, il pourrait y avoir confusion entre communes et EPCI,
  • certains souhaiteraient voir ajouté au découpage administratif les arrondissements départementaux, les quartiers ayants un Conseil de quartier avec pouvoirs, les communes associées.
Notes :
  • l'ancienne proposition concernant les cantons a été définitivement abandonnée, surtout depuis le nouveau découpage cantonal de 2014 où les cantons ne sont plus contraints par les limites d'arrondissement, et n'ont plus aucun rôle administratif autre qu'au plan électoral (pour les élections des représentants des nouvelles assemblées départementales). Les cantons sont marqués avec boundary=political (de même que les circonscriptions législatives) avec d'autres attributs complémentaires de classification.
  • historiquement (mais c'est maintenant très ancien) les communes ont fait partie de cantons (dont le rôle était d'abord judiciaire), mais le découpage cantonal fractionne de nombreuses communes depuis près de 60 ans et cela n'a fait que s'accentuer avec le temps, car leur découpage obéit à une logique de représentation équitable et évolutive de la population et non celle des limites territoriales des collectivités ni celle de l'administration déconcentrée de l'Etat aujourd'hui établie au niveau des préfets et sous-préfets, lesquels n'exercent pas leur compétence exactement sur les limites territoriales des collectivités locales, et l'administration judiciaire fonctionne aujourd'hui à une échelle essentiellement départementale pour la majorité des juridictions, voire régionale ou nationale pour certaines instances ou certains domaines).

Le COG INSEE comme référence au découpage administratif

Pour

  • On utilise le découpage intuitif que chacun utilise dans la vie de tous les jours comme les quartiers.
  • Le Code Officiel Géographique a une valeur officielle en France et peut donc servir de référence absolue.

Contre

  • Le COG INSEE est un découpage à vocation statistique qui ne représente en aucun cas le seul découpage administratif. Le découpage administratif doit se limiter à un réel découpage basé sur administratif des territoires ayants un « administrateur légal», alors que le COG intègre aussi le découpage électoral et d'autres. Le découpage administratif « général » est mentionné ici pour le découpage global, ici pour les arrondissements départementaux (sous-préfectures), ici et ici pour les EPCI et ici et ici pour les Conseils de quartier.
  • Ne pas confondre avec le découpage électoral qui est représenté sous l'étiquette « boundary=political: ». Pour exemple, les conseillers généraux élus dans les cantons siègent au Conseil général qui est un organe d'administration au niveau départemental. Rien n'est géré ou décidé au niveau des cantons. Les conseillers sont élus comme représentants de ces fractions du territoire départemental au Conseil général.
  • Les cantons et les communes n'ont pas de relation d'ordre évident : il existe des cantons contenant plusieurs communes (en campagne), des communes contenant plusieurs cantons (en ville), et des mélanges (exemple : le canton de Besançon Est qui contient une fraction de la commune de Besançon et deux autres communes entières, la commune de Besançon étant elle-même divisée entre plusieurs cantons.)

Attribuer le niveau 7 aux EPCI

Remarque : il n'est pas toujours précisé dans les discussions si l'on parle seulement des EPCI à fiscalité propre (Communauté Urbaine "CU", Communauté d'Agglomération "CA", Communauté de Communes "CC", et Syndicat d'Agglomération Nouvelle "SAN") ou de tous les EPCI (donc avec Syndicats Intercommunaux à Vocation Unique "SIVU", Syndicats Intercommunaux à Vocation Multiple "SIVOM", et Syndicats Mixtes "SM" ouverts ou fermés). Une commune appartient souvent à un seul EPCI à fiscalité propre et parfois, en plus, à jusqu'à plus de 7 syndicats.

Pour

  • C'est indiqué dans le wiki.
  • Un EPCI est forcément "au-dessus" d'une commune (car constitué de communes entières), donc son numéro doit être inférieur à 8. Et il est plus petit qu'un département (même si pas forcément strictement inclus dans un seul département), donc son numéro doit être supérieur à 6.

Contre

  • Les EPCI ne sont pas des institutions à un niveau supérieur aux communes même si le fait quelles regroupent plusieurs communes pourrait à première vu le laisser supposer. Les EPCI se voient déléguer un certains nombre de tâches « communales » à l'initiative de plusieurs communes qui se regroupent. Je cite cette page ici : « le principe de spécialité signifie que les EPCI n’exercent que les compétences que leur ont attribuées les communes qui en sont membres. ». Les EPCI exercent donc des tâches « communales », elles devraient donc être placées au même niveau que les communes (actuellement niv. 8) et pas à un niveau supérieur (actuellement niv. 7).
  • Les contours des EPCI pourraient être décrits uniquement par une simple relation père au niveau 8 (voir proposition n°1 ici), ainsi elles libéreraient le niveau 7. Ce d'autant plus qu'à (long) terme les communautés de communes devraient se substituer aux communes.

Conclusion

Cette proposition a été abandonnée. Elle ne fonctionne pas avec les EPCI qui peuvent être à cheval sur plusieurs arrondissements départementaux (voire plusieurs départements ou même plusieurs régions), dont les limites ne sont modifiées que si l'EPCI est promu en "commune nouvelle" (depuis 2012) ou fusionne en une seule commune unique, ou pour la création d'une métropole à statut particulier (pour permettre le transfert de compétences issues des départements et/ou régions).

Les EPCI ne suivent pas le modèle administratif et utilisent à la place l'attribut boundary=local_authority avec d'autres tags complémentaires pour leur typologie (et pour leurs éventuelles propres subdivisions).

EPCI placés au même niveau que les communes

Pour

  • Pourquoi pas, si l'on utilise un tag supplémentaire permettant de les distinguer des communes ? Il a été proposé le tag « nature=EPCI », mais un tag existe ici (obsolète ?) et a déjà été utilisé : « border_type=* ». Il permettrait de distinguer des institutions de même nature au même niveau administratif. Par exemple, en ajoutant border_type=EPCI à la relation qui regroupe les contours de l'EPCI.

Contre

  • Non ! Chaque niveau ne doit correspondre qu'a un seul type car ils sont répertoriés au niveau international (voir admin_level=*). Avoir 2 interprétations pour un niveau jetterai le flou sur la nature des données à ce niveau. Plus encore pour des utilisateurs étrangers qui n'ont pas la connaissance détaillée des institutions administratives françaises. De part l'usage international qui est fait de cette étiquette, un niveau = une institution représentée, doit rester la règle pour une interprétation sans ambiguïté.
  • Les contours des EPCI pourraient être décrits uniquement par une simple relation père au niveau 8 (voir proposition n°1 ici), ainsi elles libéreraient le niveau 7. Ce d'autant plus qu'à (long) terme les communautés de communes devraient se substituer aux communes.
  • I oppose this proposal I oppose this proposal. Il faut impérativement éviter de mélanger, et plus généralement je suis contre que l'ajout de tag ultérieurement à une proposition initiale en transforme le sens. Les outils utilisants les données OSM sont nombreux et on ne ferait que casser des choses qui marchent en faisant ça. sletuffe 10:11, 30 September 2010 (BST). Parfois, il peut être urgent, d'attendre ; nous avons bien assez à faire pour l'instant dans d'autres domaines.
  • Un niveau (level) comme admin_level devrait permettre de reconstituer l'ensemble du territoire de façon à ce que tout point soit situé dans un unique objet de chaque niveau admin_level. C'est la traduction OSM de la notion de couche. Si les EPCI sont mis au niveau 8, un point pourrait être dans 2 objets de niveau 8.

Conclusion

Cette proposition a été abandonnée.

Ajouter des niveaux oubliés

Contre

  • Ca n'apporte pas grand chose.
  • On manque de niveaux libres si l'on veux se conformer à l'usage international. Les usages répertoriés (voir admin_level=*) montrent que l'essentiel des pays indiquent choisissent le niveau 8 pour l'équivalent de nos communes :
    • 1 pays au niveau 5,
    • 2 au niveau 6,
    • 5 au niveau 7,
    • 40 au niveau 8,
    • 1 au niveau 9 (l'Australie),
    • 1 au niveau 10.
    • Le solde contient ceux que je n'ai pas pu déterminer (comme la Chine) ou qui est inapplicable ou indéterminé. Le niveau administratif inférieur est souvent le "suburb" qui se trouve mieux répartit entre les admin_level 9 et 10.
  • Il faut conserver cette correspondance de niveaux pour rester cohérent avec l'usage international.
  • Dans l'actuelle réforme territoriale a pour ambition de supprimer le canton et de le remplacer par un territoire et il a été avancé que les communautés de communes (après des fusions obligatoires après 2013) pourraient être cette circonscription. Pourquoi faire maintenant ce que nous devrions avoir à refaire en 2013 ? C'est une perte de temps.

Pour

  • Les arrondissements départementaux avec les sous-préfectures sont des territoires administrés. Ils auraient logiquement leur place aujourd'hui en admin_level=7, étant chacun une portion du territoire d'un département (admin_level=6) et une somme de territoires de communes (admin_level=8). Mais dans cette hypothèse, ils seraient en "conflit" avec les EPCI, qui actuellement utilisent la valeur admin_level=7.
  • Les quartiers ayants un Conseil de quartier avec pouvoirs sont des territoires administrés.
  • Les communes associées avec leurs maires délégués, sont des territoires administrés. Voir ici : « Le maire délégué remplit dans la commune associée les fonctions d'officier d'état civil et d'officier de police judiciaire ».
  • Il n'y a pas de raison à ne pas décrire correctement notre découpage administratif en ajoutant des niveaux comme en Allemagne par exemple. Dépasser le niveau 10 permettrai de conserver la hiérarchie internationale in-touchée.
  • Et qui a dit que les admin_level devaient impérativement appartenir à l'ensemble des Entiers Naturels ? Si les EPCI sont juste un peu plus grosses que les communes, mais plus petites que les arrondissements de département, pourquoi pas utiliser admin_level=7.5 ? sletuffe 10:15, 30 September 2010 (BST)
    Pour la même raison qu'elles ne devraient pas être étiquetées niveau 7 ou 9. Théoriquement, elles sont rigoureusement au même niveau administratif que les communes et devraient être étiquetées au même niveau dans OSM. Les EPCI sont des émanations de communes qui les regroupent pour assurer une gestion communes sur des sujets quelles gèrent habituellement seules. --RousseauB 10:32, 2 October 2010 (BST)
  • On ne manque pas de niveaux libres si l'on veut se conformer à l'usage international. Il est ainsi possible de renuméroter tous les niveaux en gardant les niveaux 2 (nation) et 8 (unité administrative de base, la commune), en choisissant : 4 pour les régions (on conserverait ainsi une cohérence avec les autres pays), 5 pour les départements, 6 pour les arrondissements, et 7 pour les EPCI. Damouns 09:52, 4 October 2010 (BST)

Conclusion

Cette proposition a été abandonnée. Les niveaux administratifs sont uniquement des entiers, le niveau 11 apparait seulement pour certaines grandes communes très peuplées. Les niveaux administratifs en France suivent le modèle hiérarchique, et s'ils n'y obéissent pas, ne devraient pas être utilisés.

D'autres tags sont alors utilisés si nécessaires (divers EPCI, subdivisions déconcentrées de certains services de l’État qui ne respectent pas le modèle hiérarchique des collectivités locales).

Les communes de plein exercice restent toutes au niveau 8, les régions et départements aux niveau 4 et 6. Seul un niveau 5 (ne justifiant pas la création d'un tag spécifique) est apparu nécessaire et suffisant pour un cas particulier de l'administratif décentralisée de l’État (mais qui respecte le modèle hiérarchique).

Propositions

Voici les propositions faites au cours des discussions sur la liste de discussions.

Propositions n°1 - relation père au niveau 8

<relation id="1187472" visible="true" timestamp="2010-09-22T12:21:04Z" version="7" changeset="5862283" user="Xxx" uid="142978">
  <member type="relation" ref="357864" role="admin_centre"/>
  <member type="relation" ref="172173" role="subarea"/>
  <member type="relation" ref="357929" role="subarea"/>
  <member type="relation" ref="357875" role="subarea"/>
  <member type="relation" ref="173083" role="subarea"/>
  <member type="relation" ref="356306" role="subarea"/>
  <member type="relation" ref="358578" role="subarea"/>
  <tag k="address" v="MAIRIE BOULEVARD HENRI IV 13800 AUGRAS"/>
  <tag k="admin_level" v="8"/><!-- proposé au retrait par sly -->
  <tag k="local_authority:FR:EPCI" v="CC"/>
  <tag k="name" v="Communauté de Communes du Pays d'Augras"/>
  <tag k="ref:EPCI" v="136 351 105"/>
  <tag k="region_category" v="administrative"/>
  <tag k="region_type" v="EPCI"/>
  <tag k="type" v="region"/>
  <tag k="website" v="http://www.cc-augras.com/"/>
</relation>

Remarques

  1. C'est possible. Je manque d'arguments indiscutables indiquant le bien ou la mal fondé de la démarche. Je dirais donc, fait, avec le temps et à l'usage on verra bien si c'est mieux ou pas que l'approche traditionnelle. (Celle des multipolygon).
  • Par contre, je ne suis pas vraiment pour l'utilisation du admin_level=8, admin_level c'est un tag documenté pour accompagner boundary=administrative, si on part sur l'utilisation du type=region, alors il semble logique d'utiliser la structure recommandé par la proposition Relations/Proposed/Region c'est à dire region_category and region_type sletuffe 10:20, 30 September 2010 (BST)
  1. C'est une excellente proposition.
  2. Si à (long) terme les communautés devaientt se substituer aux communes l'application du même niveau 8 pour cette structure se révélerait pertinente.
  3. J'ai cru comprendre que les outils de rendu avait des problèmes avec ces structures complexes, mais est ce une raison pour ne pas les utiliser ?
  4. (mauvais positionnemnt de cette remarque à conserver temporairement)Quelles rôles (au sens JOSM) doit t'on appliquer à chaque membre (Validator ne semble pas aimer les roles vides)
  5. L'idée de relation pour les communautés de communes, les communautés d'agglomérations, ... est une bonne idée qui représente bien la structure. Ca me semble cohérent. Le même niveau d'admin rend bien compte de la situation actuelle ou ces communauté se substituent sur certains points de gestion, le ramassage des ordures, les transports en commun, ...
  6. En ce qui concerne les rôles "admin_center" : Attention à la syntaxe anglaise : admin_centre (et non admin_center). Erreur très courante, en particulier chez les français (on se demande pourquoi ;-). Concernant les EPCI je crois pas que admin_centre soit pertinent ; il n'y a pas de réel centre administratif (un adresse postale c'est tout). Aucune commune n'a d'égénomie (en théorie, car souvent c'est la ville principale qui assume ce rôle). Mais la relation proposée est très intéressante.
  7. Elle permet de "faire la place" pour les arrondissements départementaux ;o)
  8. Pour revenir sur les propositions d'aujourd'hui, je reste partisan du modèle par limite (boundary=*) plutôt que par surface (region+subarea), pour la raison invoquée hier : la capacité de définir le périmètre de la com'com même en l'absence des limites admin de certains villes constituantes. Même si, comme le dit justement Pieren, les regroupements dans ce cas concernent bien peu de communes en comparaison de ce que regroupe un département. Néanmoins, un autre point, déjà évoqué, est celui de la cohérence de modèle. Je trouve dommage de s'éparpiller sur 2 modélisations pour, finalement, la "même" chose (avec quelques guillemets) : la définition d'une zone par agrégat de communes. Je ne vois pas de raison majeure pour faire de 2 manières distinctes : somme de limites versus somme de surfaces. Et l'usage boundary=* étant un consensus pour les contours administratifs à l'échelle de toute la base OSM, je trouve que ça légitime d'autant plus de continuer pour la déclinaison com'com.

Maintenant s'il y a consensus sur region+subarea, je l'appliquerai, que ce soit clair, mais bon... en grognant :-) 2 autres points : - il faut prévoir la situation où l'on veut définir une com'com en l'absence de limites communales. Comment inclure une commune sans limites administatives tracées ? A priori en plaçant dans la relation com'com le node place=* qui représente la commune ? Le rôle subarea ne me plaît pas s'agissant d'un node. Peut-être peut-on laisser le node sans rôle ? - je vois dans l'exemple "cobaye" de Pierre ma proposition de tag "local_authority". Ca n'est qu'une proposition, faut-il le rappeler.

  1. Pour les subarea je n'ait remarqué aucun consensus, Pierre nous a proposé, comme base de travail, l'adaptation sur un modèle existant et Émilie à évoqué subarea en nous disant "ca ne me plait pas mais ça existe par ailleurs".
  2. Mis a part le modèle proposer qui reste à affiner, renommer les tags, le compléter, il n'y a pas incohérence avec le modèle actuel bien au contraire c'est un complément indispensable ! C'est le modèle actuel qui nous amène à l'incohérence. Soit en hiérarchisant de haut en bas : des éléments qui pour certains ne sont pas des limites administratives ou des élément qui devraient être au même niveau administratif sur des niveaux différents. Même si nous rajoutions une numérotation de niveau a plus de 10 échelons, ce serait faux ! Ce n'est pas parce que le modèle qui fait consensus dans la base est limité que nous devons le reproduire bêtement à l'infini en entrant des données dedans au chausse pied en considérant que c'est un fourre tout. Tagguer un admin level 7 pour une communauté de commune est une erreur si les communes sont en 8 ! Ou alors il faut compléter le modèle actuel en ajoutant des compléments d'information pour distinguer les limites administratives placées au même niveau.

La solution de la relation est très pratique et flexible puisqu'elle évite d'avoir nécessairement à ressaisir les contours en incluant les contours des communes. L'argument comment on fait s'il n'y à pas de contours de communes ne tient pas, il faut les tracer. Personne ne se pose la question de tracer une route sans ways ou d'indiquer des sorties d'autoroutes sans l'autoroute. Qui plus est la relation permet d'ajouter un contour propre à la com'com. Le plus important même si l'on tâtonne en base est d'avoir l'ensemble des informations cohérentes pour transtyper automatiquement ces éléments si nécessaire dans le futur. Ca la relation et le modèle proposé le permettent. Facile à dire, et j'aimerais être d'accord avec ça, mais il faut être lucide, la courbe de croissance des limites admin est plutôt faible. Construire une version temporaire de com'com, avec les nodes place=* permet déjà d'identifier la com'com et ses communes constituantes (via leur ref:INSEE) ainsi que, au mieux, ses domaines de compétence. Le jour où les contours de commune existent, on remplace le node place=* par la relation boundary=administrative, mais au moins comme ça on ne créé pas d'adhérence entre les objets com'com et limite admin. Utiliser le node place=* est une suggestion pour gérer une situation transitoire, pas ce qui devrait être le modèle définitif. Ne suis pas contre node "place=*", au contraire et pour les mêmes raisons que toi. Mais je ne voudrais pas que cet élément laisse pensé que le travail est fait une fois qu'il est en place et et ne devienne une "excuse" pour ne pas tracer les limites par la suite.

  1. Je viens de relire ce que je disais hier, et ça prête à confusion, je comprends ta réponse. Je ne parlais (ne voulais parler) que de la manière de construire l'objet com'com : par une relation de type boundary=*, ou par une autre de type region=*. Il est clair pour moi que dans un cas comme dans l'autre, le tag admin_level=* n'a rien à faire dans cette relation. En revanche, il est présent dans chacun des membres de la relation.

En essayant de reformuler : "quand on agrège des communes pour construire un département, on utilise boundary=*, pourquoi ne pas utiliser aussi boundary="autre chose" pour agréger des communes à l'échelle d'une com'com." 11.

Proposition n°2 – utiliser boundary=local_authority

<relation id="49584">
<member type="way" ref="24301382" role=""/>
<member type="way" ref="26167773" role=""/>
(...)
<member type="way" ref="59870386" role=""/>
<member type="way" ref="30967781" role=""/>
<member type="way" ref="30988827" role=""/>
<tag k="boundary" v="local_authority"/>
<tag k="local_authority:FR" v="CA"/>
<tag k="ref:INSEE" v="247800451"/>
<tag k="name" v="Saint-Quentin-en-Yvelines"/>
<tag k="type" v="boundary"/>
</relation>

Détail de la proposition

La proposition sur Saint-Quentin-en-Yvelines est fictive (au 30/09/10), elle s'appuie sur la relation 49584 bien réelle qui décrit l'agglo.

Type de relation

La relation proposée est de type "boundary". Sa géométrie est constituée, comme pour les limites de communes ou départements, de ways formant une boucle fermée. Ces ways sont utilisés par les limites "admin_level=*" des communes appartenant à l'EPCI, et situées en frontière entre l'EPCI et le "reste du monde". Du point de vue géométrique, la modélisation proposée est donc identique à celle des limites administratives : il s'agit d'un contour. Incidemment, pour les quelques dizaines d'EPCI déjà présents dans la base, le choix de ce nouveau modèle serait indolore pour l'aspect géométrie, puisque ces EPCI sont déjà décrits par,les ways formant la limite extérieure de son territoire.

Tags à inclure

La différence majeure avec la modélisation actuelle réside dans le choix des tags à appliquer à la relation.

  • type=boundary

Le type de la relation est bien boundary dans la mesure où les géométries qui la composent sont des ways "frontières" entre les communes de l'EPCI et le 'reste du monde' (voir ci-dessus).

  • boundary=local_authority

La valeur local_authority est une proposition. L'idée est de trouver un terme autre que administrative qui décrive la notion d'entité de gestion à un échelon local. Peut-être que le terme management aurait sa place dans la valeur à définir. Une discussion s'impose quoi qu'il arrive avant de décider d'arrêter une valeur.

La valeur administrative doit rester l'apanage des entités référencées dans les tableaux de la page admin_level=*, tableau dans lequel ne peuvent s'inscrire les EPCI. En effet, une convention, présente dans OSM aussi bien que dans les BD commerciales, consiste à décrire l'organisation administrative des pays sous forme de pyramide, avec plus ou moins de niveaux (les admin_level), et des niveaux plus ou moins remplis. La convention est la plus forte pour la description du niveau local, ou le niveau '8' est utilisé par tous les éditeurs. En France, la "pyramide" administrative est des plus régulière, au moins en métropole, car en tout point du territoire on sait assigner une appartenance à une commune > un département > une région. Les EPCI ne rentrent pas dans cette modélisation, car ils regroupent potentiellement des communes issues de plusieurs départements.

  • local_authority:FR=*

Ce tag permettrait de placer l'abbréviation du type d'EPCI décrit. L'INSEE recense 4 valeurs possibles :

  • CA : Communauté d'Agglomération
  • CU : Communauté Urbaine
  • CC : Communauté de Communes
  • SAN : Syndicat d'Agglomération Nouvelle
  • ref:INSEE=*

Sur le même principe que pour les entités en boundary=administrative, l'INSEE donne pour chaque EPCI un identifiant unique, qui pourrait être renseigné via ce tag.

  • name=*

Le nom de l'EPCI. Plusieurs noms sont candidats, peut-être faudrait-il plusieurs tags :

  • un pour le nom tel que présent dans les tableaux de l'INSEE comme celui téléchargeable en bas de cette page, par exemple : "Communauté d'Agglomération de la Vallée de Montmorency"
  • un pour l'abbréviation : "CAVAM" pour l'exemple ci-dessus
  • un pour le nom d'usage : "Val & Forêt" dans le cas de la Communauté d'Agglomération de Val & Forêt.

Tags à exclure

  • admin_level=*

Ce tag doit rester associé aux entités pour lesquelles le tag boundary prend la valeur administrative.

  • admin_centre (role)

En fonction du type d'EPCI, on doit trouver au moins une commune d'une certaine taille. Par ex. pour une communauté d'agglomération, il faut au moins une commune de plus de 15000 habitants. Malgré celà, il n'existe pas de hiérarchie (sur le papier) entre les communes composant un EPCI. La notion d'admin_centre ne s'applique donc pas ici pour désigner une commune plutôt qu'une autre.

Ceci dit, il existe une commune dans laquelle se trouve le siège de l'EPCI. Ce n'est pas forcément la plus grosse commune.

  • addr:postcode=*

Il semblerait que les seuls codes postaux assignés à un EPCI soient de type Cedex. C'est au moins le cas pour les ECPI "SAN" : Marne La Vallée, Saint-Quentin-en-Yvelines. S'il s'avère qu'aucun code non Cedex n'est attribué en propre à un EPCI, alors on ne placera pas de tag addr:postcode directement au niveau de la description de l'EPCI. Chaque commune qui le constitue porte déjà ses propres tags addr:postcode, au niveau des nodes place=* et de la relation boundary=administrative

Conclusion

Ce modèle a été adopté et tous les EPCI à fiscalité propre l'utilisent et sont tous cartographiés.

Le modèle est également utilisé pour les autres anciens EPCI sans fiscalité (SIVU, SIVOM, syndicats de pays) dont nombre d'entre eux disparaissent avec le transfert de leurs compétences vers les EPCI à fiscalité propre (qui les fusionne).

Il est également utilisé pour les nouveaux "pôles métropolitains" (syndicats mixtes regroupant diverses collectivités non limitrophes et séparées par des espaces ruraux périphériques, mais liées par des projets de développement concertés).

Certains EPCI à fiscalité propre très peuplés ont leur propre subdivisions locales pour organiser leurs propre services à la population (par exemple les "pôles de proximité" dans la métropole de Nantes, regroupant certains quartiers de la commune de Nantes et d'autres communes de la métropole).

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=France/Tracer_les_limites_administratives/Mise_au_point_du_modele_des_EPCI&oldid=1898321"