Le 3 février 2012 07:27, Pierre-Alain Dorange <[email protected]> a écrit : > sly (sylvain letuffe) <[email protected]> > wrote: > >> Il y a la proposition du role admin_centre qui a pour but de "faire remonter >> dans la relation" >> >> Mais la question du double nom entre la relation administrative et le tag >> place est pour moi un faux problème. > > C'est faux problème qui a un impact réel tout de même, on voit sur la > carte 2 fois le même nom dans la majorité des cas et sans aucune > véritable raison.
Le tag place sert à autre chose: il indique l'importance relative d'un lieu par rapport aux autres. Il sert surtout à fixer des priorités d'affichage et à éliminer (par exemple dans le rendu d'une carte à échelle grossière) des noms en excès qu'on ne peut pas tous afficher en même temps sans rendre la carte totalement illisible, pour ne faire apparaître que les éléments importants (par exemple les chef-lieux de région mais pas tous ceux de départements, les capitales de pays mais pas les autres villes du pays, les villes de plus de 100 000 habitants mais pas les villes de plus de 10 000 ou les villages). C'est un critère finalement subjectif qui présuppose une utilisation dans un type de carte et présuppose l'importance d'un lieu à afficher (label et/ou symbole centré sur un point "central" désigné ou calculé) selon un critère unique et finalement arbitraire (town=city, town=village, town=hamlet...) alors que cette sélection devrait se baser sur des critères plus explicitement tagués (par exemple les rôles admin_center pour désigner les chef-lieux de chaque niveau administratif, ou la population chiffrée). Noter que le critère d'importance donné par le tag place est fortement lié au niveau de zoom: les critères de sous-sélection changent, mais pas la valeur du tag place, ce qui finalement ne permet plus de faire de meilleures sélections plus pertinentes. Ce tag "place" ne devrait contenir que l'indication du statut ou type officiel de lieu (par exemple pour indiquer que c'est un chef-lieu de région ou une capitale de pays, ou bien une "ville libre" si on les distingue d'une "cité' selon la classification administrative officielle d'un pays et le statut de fonctionnement, ou bien pour indiquer que le niveau 2 désigne une collectivité territoriale unique avec les attributions à la fois d'un département et d'une région, et pas seulement un département. Mais cela remettrait en cause trop de données actuellement. Un meilleur système de classification c'est le "boundary_type" (administrative, maritime...) ou, pour la France, le tag permettant de désigner et séparer les différents types d'EPCI à fiscalité propre (métropole, CA, CC, SAN) ou non (SIVU, SIVOM...), et leurs éventuelles subdivisions (par exemples les "pôles de proximité" actuellement cartographiés dans Nantes Métropole et auxquels on vient de supprimer l'admin_level=9 car ce ne sont pas des quartiers de la commune, même si ce sont bien des subdivisions administratives): Ce dernier exemple est un cas qui soulève le problème actuel de l'impossibilité de créer plusieurs hiérarchies indépendantes de zones administratives, des hiérarchies superposées, que "l'admin_level" actuel ne permet pas de gérer au delà d'une seule hiérarchie "principale" définie de façon uniforme pour tout le pays et même le monde entier). Un cas qui montrait encore l'utilité des membres de type "subarea:*" qui ont été fortement critiqués à cause de prétendus problèmes de rendus inexistants, alors que cela permettait de taguer très proprement (et de façon non arbitraire) les différents types de subdivision ou de partitionnement qui peuvent exister dans une zone donnée, et qu'on distinguerait par leur rôle "subarea:*" sans même créer aucune relation supplémentaire ni aucun noms ou traductions supplémentaires dans les relations (certains y ont vu une tentative de passer à la modélisation par surface, alors que ce n'était clairement pas équivalent, même mathématiquement au sens topologique; malheureusement, vous ne l'avez pas compris du tout quand je vous ai dit que cela ne remettait pas du tout en cause la modélisation géométrique par frontières et non par surfaces, et que cela ne faisait absolument PAS "doublon"). _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
