Le 24/09/2010 23:03, Vincent de Chateau-Thierry a écrit :
Bonsoir,

Le 24/09/2010 22:03, Pierre-Alain Dorange a écrit :

Pieren<pier...@gmail.com>  wrote:

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.

Oui, et à double titre, puisqu'elle permet de "faire la place" pour les arrondissements départementaux ;o)

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 Quenee ma proposition de tag "local_authority". Ca n'est qu'une proposition, faut-il le rappeler.

vincent
Pour les subarea je n'est remarqué aucun consensus, Pierre Quenee 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".
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.

Benoît R.
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Répondre à