Le 10/10/2012 21:07, Eric SIBERT a écrit :
Le rôle subarea ? Vade retro satanas :-)

Plus sérieusement, tu voudrais composer un "arbre administratif"
malgache via une / des relations qui agrégeraient les différents nodes
place=*, la subtilité étant dans le rôle de chacun ?

Oui, c'est bien ça. J'ai juste du mal à construire des relations
type=boundary en l'absence de frontière. Ça me paraît contre nature.


Je ne sais pas si tu as un usage en tête pour ce que tu vas modéliser ?
Si c'est juste pour fixer l'organisation administrative et organiser des relations d'inclusions sans géométrie, personnellement je pencherais plus pour des relations imbriquées que pour le recours au tag is_in et à ses déclinaisons, pour plusieurs raisons :
- la relation lie des IDs d'objets (plus fiable)
- le is_in donne comme clé de rattachement du texte, plus ambigü (fautes de frappe possibles, divergences sur l'orthographe) - la relation donne une vue synthétique, ne serait-ce que par la capacité à lister les membres d'une même relation - le is_in ne met en relation que des couples d'objets : celui qui porte le tag, et celui référencé dans la valeur du tag. On ne voit pas facilement ensemble plusieurs objets ayant le même tag is_in.

Concrètement, j'imagine par exemple :
- pour chaque commune, une relation de type "commune" avec comme membres tous les nodes place=* dont tu sais qu'ils sont dans le périmètre de la commune. La relation a pour valeur de tag name le nom (administratif) de la commune, qui peut être distinct de chacun des noms de lieux "place". Un des nodes place porte le rôle admin_centre, les autres ont un rôle à définir (place, village, hameau, etc.) ou pas de rôle du tout. - pour chaque district, une relation de type district, avec comme membres les relations de type "commune" des communes formant le district. On peut éventuellement coller à chacune un rôle, par exemple "commune". - idem un niveau au dessus avec pour chaque région, une relation de type region regroupant ses districts, sauf à utiliser les limites actuelles (admin_level=4) pour composer directement des relations de type boundary.

L'idée est de permettre temporairement la description de la hiérarchie administrative sans géométrie surfacique, pour au moins les districts et communes. On remplace l'inclusion spatiale (celle dont on bénéficie en France avec nos niveaux région et département complets) par l'inclusion dans des relations. Le jour où tu disposes des limites de districts, tu peux remplacer les relations "district" par des relations "boundary" avec admin_level=6. Idem pour les communes.

vincent

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

Répondre à