User:Vincent 95/draft/synthese limites administratives

From OpenStreetMap Wiki
Jump to navigation Jump to search

Si j'ai bien compris, cette page sera supprimée/oubliée prochainement et remplacée par WikiProject France/Tracer les limites administratives/Mise au point du modele des EPCI

Tout à fait. Ce sera plus lisible pour tout le monde. Reste à Benoît à transférer ses derniers edits -- Vincent 95 09:28, 1 October 2010 (BST)

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 : contour de la France
  • 3 : non utilisé
  • 4 : Régions (équivalent NUTS 2)
  • 5 : non utilisé
  • 6 : Départements(équivalent NUTS 3)
  • 7 : Intercommunalités (proposition)
  • 8 : Communes
  • 9 : Arrondissements municipaux
  • 10 : Quartiers

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 noeud 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.

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.

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.

Attribuer le niveau 7 aux EPCI

Pour

  • C'est indiqué dans le wiki.

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.

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)

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.

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)

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

note : L'ensemble des remarques n'est pas encore importé et trié.

  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. 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, ...
  5. 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.
  6. Elle permet de "faire la place" pour les arrondissements départementaux ;o)
  7. 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 : 1 - 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 ? 2 - je vois dans l'exemple "cobaye" de Pierre ma proposition de tag "local_authority". Ca n'est qu'une proposition, faut-il le rappeler.
  8. 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".
  9. 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.
  10. 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 en place de boundary=administrative -

<relation id="49584" visible="true" timestamp="2010-07-18T18:53:48Z" version="24" changeset="5253787" user="ToineToine" uid="313558"> 

 <member type="way" ref="24301382" role=""/> 
 <member type="way" ref="26167773" role=""/> 
 (...) 
 <member type="way" ref="30967781" role=""/> 
 <member type="way" ref="30988827" role=""/> 
 
 <tag k="type" v="boundary"/>
 <tag k="boundary" v="local_authority"/> 
 <tag k="local_authority:FR:EPCI" v="CC"/>
 <tag k="admin_level" v="8"/>

 <tag k="name" v="Saint-Quentin-en-Yvelines"/> 
 <tag k="address" v="MAIRIE BOULEVARD HENRI IV 13800 AUGRAS"/>
 <tag k="name" v="Communauté de Communes Saint-Quentin-en-Yvelines"/>
 <tag k="ref:EPCI" v="136 351 105"/>
 <tag k="website" v="http://www.cc-augras.com/"/>

</relation>

Remarques

note : L'ensemble des remarques n'est pas encore importé et trié.

  1. Quels rôles (au sens JOSM) doit t'on appliquer à chaque membre ? Validator ne semble pas aimer les roles vides.

Proposition n°3 - utiliser border_type pour distinguer les découpages au même niveau -

<relation id="49584" visible="true" timestamp="2010-07-18T18:53:48Z" version="24" changeset="5253787" user="ToineToine" uid="313558"> 
 
 <member type="way" ref="24301382" role=""/> 
 <member type="way" ref="26167773" role=""/> 
 (...) 
 <member type="way" ref="30967781" role=""/> 
 <member type="way" ref="30988827" role=""/> 
 
 <tag k="type" v="boundary"/>
 <tag k="boundary" v="administrative"/> 
 <tag k="border_type" v="FR:EPCI"/>
 <tag k="admin_level" v="8"/>
 
 <tag k="name" v="Saint-Quentin-en-Yvelines"/> 
 <tag k="address" v="MAIRIE BOULEVARD HENRI IV 13800 AUGRAS"/>
 <tag k="name" v="Communauté de Communes Saint-Quentin-en-Yvelines"/>
 <tag k="ref:EPCI" v="136 351 105"/>
 <tag k="website" v="http://www.cc-augras.com/"/>
 
</relation>

Remarques

note : L'ensemble des remarques n'est pas encore importé et trié.

  1. Quels rôles (au sens JOSM) doit t'on appliquer à chaque membre ? Validator ne semble pas aimer les roles vides.
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=User:Vincent_95/draft/synthese_limites_administratives&oldid=539388"