[OSM-talk-fr] role=label

[Philippe Verdy]

Le 3 février 2012 07:27, Pierre-Alain Dorange <pdorange at mac.com> a écrit :
> sly (sylvain letuffe) <liste at letuffe.org>
> 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").