User:Vincent 95/draft/Conversion admin level=7

From OpenStreetMap Wiki
Jump to: navigation, search

Arrondissements départementaux (sous-préfectures)

Sur la relation
  • type=boundary
  • boundary=administrative
  • admin_level=7
  • ref=* (Le numéro de l'arrondissement, par ex. Arrondissement d'Antony dans les Hauts-de-Seine: ref=921)
  • admin_centre=* (Le rôle admin_centre sera positionné sur le nœud place=* représentant la ville sous-préfecture de département, donc chef-lieu de l'arrondissement ; par ex. Antony pour l'arrondissement 921)

Le tag name=* n'est pas utilisé, les arrondissements n'ayant pas de nom en propre.

Sur les chemins

EPCI

Cette nouvelle modélisation remplace celle qui utilisait le niveau admin_level=7 pour les EPCIs.

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

Tags à inclure sur la relation

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.
  • local_authority:FR=* Ce tag permet 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.
  • 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 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