Le 10 octobre 2012 20:59, Eric SIBERT <courr...@eric.sibert.fr> a écrit : >> C'est bien pour ça que le modèle utilisé en Espagne (dont les communes >> comptent de nombreuses petites localités avec chacune leur nom >> spécifique, souvent différent de la commune elle-même) marche bien : > > > Je viens de jeter un coup d’œil au modèle espagnol: > > Il y a des relations de type=boundary. Un exemple: > admin_level = 6 > place = county
dans la relation le place=* ici inutile, a priori, place c'est plutôt pour les noeuds, bien que place soit associé à la population du lieu et que cette population ne se définit pas au noeud (dont on ne sait pas quelle étendue in concerne, mais sur la surface entière donc bien sur la relation. > rank = county doublon inutile à priori de admin_level=6. Sauf que justement en Espagne le découpage administratif est en pleine mutation et la hiérarchie des niveaux va être profondément modifiée. Je pense que ce rank permet de conserver une trace du type d'entité que cela désigne, avant que la structure hiérarchique soit modifiée (donc aussi les numéros assignés en valeur d'admin_level. > is_in = Comunidad Valenciana, Spain > is_in:country = Spain > is_in:region = Comunidad Valenciana Les is-in là sont tous documentaires, pas forcément nécessaires. C'est déjà blindé autrement de façon nettement plus pratique par les relations parent/enfant de rôle subarea. > ine:provincia = 03 Comme nos références INSEE en France. > rôles outer : les limites Comme en France, mais aussi facilement cassé qu'en France (heureusement les suareas aident à restaurer les ambiguités. > rôles subarea : la liste des municipalités Liste qui doit rester exhaustive de toutes les communes (au niveau suivant) couvertes. Cela ne détermine PAS les contours qui peuvent être plus larges que ces communes. > rôle admin_centre : le(s) chef-lieu(x) Tout à fait : un ou plusieurs chef-lieux en admin_center Les subarea sont pour assurer l'exhausitivité de la liste des communes membres > Et quand je vais sur le nœud place du chef-lieu, je trouve: > admin_level = 6 Sauf là c'est une erreur, ce devrait rester admin_level=8 (voire 9) car le noeud n'est pas celui de la province mais celui de la municipalité (voire même de la localité). > capital = 6 Ça c'est bon > is_in = Alicante, Comunidad Valenciana, Spain > is_in:continent = Europe > is_in:municipality = Alacant/Alicante > is_in:province_code = 03 Là aussi uniquement documentaire, car totalement blindé par les relations parent/enfant de rôle subarea (indépendamment des chemins frontières listés dans la relation) > place = city C'est comme en France ici, mais c'est en fait pas l'endroit idéal pour mettre ça puisque ça dépend de la population. Hors les localités en Espagne ont des noms et des couvertures plus petites que la municipalité, qui n'est correctement décrite dans sa surface comme dans son nom QUE dans la relation (laquelle est l'endroit idéal pour importer les chiffres de population, ainsi que toutes les traductions). > De mon point de vue, c'est ce que j'appelle bétonner. En poussant plus loin, > les nombreuses informations redondantes peuvent poser problème pour la > maintenance de la base. Du point de vue espagnol, non, car ce qui est bétonné ce sont les relations parent/enfant entre les relations, et leurs tags donnant les noms, traductions, classifications hiérarchiques, populations. Ce sont les contours indiqués en chemins membres qui ne sont pas stables mais peuvent être régénérés récursivement. Toutes les autres données sur les chemins et les noeuds sont alors redondantes. > Et comme je l'ai déjà expliqué, faute de limites communales, mettre en place > des relations type=boundary paraît capilotracté. Sans relation, juste > capital=(admin_level) ne permet pas de couvrir tous les cas. Il faut au > moins compléter avec des is_in:*=. Si on n'a pas encore de limites communales, on peut déjà créer les relations pour y mettre en membre non pas des frontières internes et externes, mais au moins tous les noeuds de localités ou lieux-dits inclus dedans, ou pas loin de cette frontière. On distinguera le rôle 'admin_center" pour la localité chef-lieu, et pour les autres localités on pourrait utiliser en attendant un rôle "place" (qui deviendront inutiles si on a pu fermer toutes les frontières autour des localités (de rôles admin_center et place). Le modèle hiérarchique se construit quand même, on peut commencer avec des frontières grossières soit au niveau le plus grand du pays et ses provinces ou régions, soit au niveau le plus fin des localités les plus petites ou des quartiers, ou dans un ordre quelconque. On n'a aucune contrainte dans l'ordre de travail, et il est possible de dresser rapidement des listes exhaustives de toutes les relations administratives nécessaires et leur hiérarchie, même sans aucune frontière (qui viennent après et qu'on sait construire alors en analyse montante comme descendante). Les subarea évitent également les oublis de relations lors des opérations de scission ou fusion de frontières communes : grace à la liaison parent-enfant, les relations dépendantes sont TOUJOURS chargées par JOSM (sans même avoir à utiliser CTRL+ALT+D dans JOSM sur chaque chemin à modifier ou noeud à fusionner ou supprimer). Ce sont eux qui consolident le modèle, sans introduire de redondance réelle (il y a en fait beaucoup moins de redondance dans les liens parent/enfants de type subarea, que dans les copies partielles de longues listes chemins membres dans les multiples relations. Je ne trouve pas ça "satanique" (ref: le "vade retro" qu'on nous bassine ici sur cette liste franco-française et uniquement pour la France, là où les autres pays ont bien vu tous l'intérêt). _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
