Sinon tu peux regarder aussi la république tchèque, totalement achevée et blindée elle aussi par des subareas.
Encore tant pis pour la France qui s'y refuse pour des mauvaises raisons ou des incompréhensions qui n'ont pas lieu sur le prétendu "modèle surfacique" alors que les relations parent/enfant ne déterminent PAS les surfaces totales, juste une couverture complète ou partielle de la surface d'une relation enfant, représentée par ses frontières, par la surface de son/ses parents qu divent être le plus exhaustif possible mais peuvent ne pas couvrir QUE leurs seuls enfants). Les subareas sont là pour l'exhaustivité du modèle hiérarchique et recouvre une relation de dépendance, partielle ou totale, même lorsque des morceaux de surface du parent ne sont inclus dans AUCUNE des relations enfants, puisque le parent peut être plus grand que l'union de ses enfants, et puisque leurs enfants peuvent aussi avoir des intersections de surface non nulle. Le 10 octobre 2012 23:20, Philippe Verdy <verd...@wanadoo.fr> a écrit : > 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
