[OSM-talk-fr] niveaux admin_level=7 (était : Limites, communales)

Vincent de Chateau-Thierry vdct at laposte.net
Jeu 23 Sep 21:21:21 UTC 2010


Bonsoir,

Le 23/09/2010 15:25, Benoît ROUSSEAU a écrit :
>   Le 23/09/2010 14:44, Pieren a écrit :
>> 2010/9/23 Benoît ROUSSEAU <adressepossible at free.fr
>> <mailto:adressepossible at free.fr>>
>>
>>     Reste à déterminer l'étiquetage ? Des propositions ?
>>     Benoît R.
>>
>>
>> Je suis d'accord qu'il faut revoir l' "étiquetage". Avec la
>> proposition actuelle:
>> http://www.openstreetmap.org/browse/relation/1187442
>>
>> je vois quelques problèmes dont le principal est de mélanger des
>> relations définissant des limites (somme de frontières extérieures
>> formant une surface) avec des regroupements de communes (somme de
>> surfaces) en utilisant la même famille de tags (type=boundary;
>> boundary=administrative). Donner un "role=relation" n'est pas
>> suffisament distinctif ce qui pourrait compliquer leur exploitation
>> par logiciel, amha (on ne tague pas pour les logiciels mais il faut
>> garder une certaine cohérence tout de même; la question s'est déjà
>> posée pour les départements, régions, etc).

Je suis d'accord avec ça. Je penche pour le recours à la même 
modélisation que celle utilisée pour les départements, à savoir une 
somme de ways qui forment un contour. Il y a la raison de cohérence que 
donne Pieren, et j'en ajouterai une autre : avoir une somme de limites / 
bordures permet de définir l'emprise complète du territoire sans 
disposer de tous ses constituants. L'exemple des départements plaide 
pour ça : on a aujourd'hui la définition des limites de tous les 
départements, tout en ayant (et de loin :-( ) pas encore toutes les 
limites de communes. Si on avait défini les départements comme des 
sommes de surfaces communales, on ne saurait pas proposer un découpage 
départemental complet de la France. Et encore pour un petit bout de 
temps...

Un autre problème dans
>> cette proposition est d'y avoir ajouter le code postal qui se trouve
>> déjà dans les sous-relations. Je ne sais pas si la création de
>> communautés de communes implique toujours la fusion en un seul code
>> postal mais les codes postaux devraient figurer dans une seule
>> relation à la fois pour éviter les risques d'incohérences ultérieures.

Autant que je sache, il n'y a pas de fusion des CPs à la création d'une 
communauté de communes. Et si cela arrive, ça n'est pas une règle. En 
France, hormis pour quelques communes avec plusieurs codes postaux, le 
niveau "commuune entière" reste le plus pertinent pour stocker cette 
info. donc dans osm la relation d'admin_level=8


> Tout a fait d'accord, le type "boundary" ne convient pas. Pour les
> surfaces il y aurait "area". De même pour le code postal qui n'a rien à
> faire ici. Par contre l'INSSE donne un code EPCI pour ces regroupement
> dans le document téléchargeable ici :
> http://www.statistiques-locales.insee.fr/esl/baseTelechProduit.asp?strProd=1637&IdSousTheme=2&IdSource=&NomThemeOuSource=R%C3%A9gions%2C+d%C3%A9partements+et+villes+de+France
> <http://www.statistiques-locales.insee.fr/esl/baseTelechProduit.asp?strProd=1637&IdSousTheme=2&IdSource=&NomThemeOuSource=R%C3%A9gions%2C+d%C3%A9partements+et+villes+de+France>.
> Ce code pourrait être inclu.

Chouette, un nouveau ref:INSEE :-)

> Il faudrait, a discuter, voir en terme de groupement, car relation
> exprime un regroupement administratif de territoires. Ce n'est pas une
> description géométrique qui est déjà définie par les limites des
> communes concernées. Je ne pense donc pas qu'il faille définir un
> contour pour les communautés de communes car 1- il est intrinsèque 2 -
> les communauté de communes changes relativement rapidement. Utiliser une
> relation permet d'inclure ou d'exclure des communes facilement.
Plutôt pas d'accord (voir + haut)

> J'arrête le franglish => un truc type=groupe ou groupement_administratif
> seraient ils trop simples et pas assez descriptif ?>

En modélisant le contour plutôt que la surface, je proposais hier 
boundary=local_authority,
qui se traduit plus ou moins par "collectivité locale", ce qui, j'en 
conviens, ne tombe pas pile sur ce qu'on veut décrire. Ce sera bien de 
trouver autre chose.
Je pense par ailleurs qu'on n'échappera pas à un espace de noms du style
local_authority:FR un peu sur le modèle de school:FR si on veut 
introduire la typologie des EPCI (cf. doc de l'INSEE ci-dessus) :
"Les communautés urbaines (CU), communautés d'agglomération (CA), 
communautés de communes (CC), syndicats d'agglomération nouvelle (SAN)"

Donc tout ça nous fait au moins 2 points à trancher : modélisation par 
limites ou par surface, et vocabulaire des tags.

A vous lire,
vincent




Plus d'informations sur la liste de diffusion Talk-fr