Le 3 février 2012 07:27, Pierre-Alain Dorange <pdora...@mac.com> a écrit : > sly (sylvain letuffe) <li...@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. > >> [...] >> Je continue de dire qu'il s'agit de deux noms pour deux choses différentes, >> donc normal. Coïncidence, en France, les communes portent souvent le nom de >> leur chef lieu (mais ce n'est pas tout le temps le cas)
On ne parle pas du rôle "admin_center", indication de la position et du nom du chef-lieu/capitale/siège de la zone concernée (laquelle peut être une commune, un département, une région, un pays, un EPCI, etc. et pourrait ne pas être retreinte géomatriquement à un seul nœud mais pourrait être une zone entière, avec aussi un nom affichable, l'utilisation d'une zone offrant un avantage car elle indique aussi une tolérance de placement du label de ce chef-lieu/capitale/siège au sein de la zone qui le désigne avec le rôle "admin_center"). On parle du rôle "label" qui n'a pas d'autre fonction que de préciser une position plus fine de placement du label pour 1 seule zone concernée. Le label indique aussi le nom de cette zone. Il n'est pas nécessairement placé à l'emplacement de l'admin_center. Son rôle pricipal est d'améliorer le placement du label pour aider les outils de rendu, mais au delà de ça, les noms qui y sont ceux bien ceux de la relation (une et une seule) qui référence cet objet avec le rôle "label". Que l'objet référencé comme "label" ait lui-même une géométrie, cette géométrie est arbitraire (mais devrait être DANS la géométrie de la relation. Cette géométrie est actuellement uniquement un nœud, mais cela n'indique aucune zone de tolérance pour le placement du label. Alors que cela pourrait indiquer un chemin (permettant d'orienter le label en diagonale ou sur une courbe) ou une zone fermée entière (à charge pour le monteur de rendu de trouver une place libre dans cette zone sur la carte pour éviter les collisions ou l'élimination du label qu'on préfère faire apparaître. Un label pourrait aussi avoir d'autres propriétés, telles que l'indication de son importance relative par rapport à d'autres labels de zones différentes voisines, afin de permettre de faire un choix en cas de collisions. Mais il n'y a aucune raison pour que l'objet de rôle label ait un nom affiché différent de celui de la relation qui le désigne avec ce rôle. Le label désigne bien la même zone géographique que la relation qui l'utilise avec ce rôle. Un objet créé pour être désigné comme membre de rôle 'label" d'une relation, ne peut être membre que d'1 et 1 seule relation. Il ne doit pas exister sans être membre d'une relation, et ne peut pas être partagé. De même une relation ne peut avoir plus d'1 objet label par zone connexe, mais éventuellement pourrait avoir 1 membre label pour chaque zone connexe (la zone "principale" et chacune de ses exclaves). Cependant, dans le cas de zones comme les archipels, la relation mère a une géométrie souvent trop compliquée avec de nombreuses exclaves, et mettre un label sur chaque partie est illisible, alors qu'on peut aussi désigner comme zone pour le label un polygone large connexe renfermant toutes les îles et îlots ou rocs, même si ce polygone inclut des zones de mer qui ne sont pas formellement partie de la relation mère (ce n'est normalement pas un problème s'il n'y a rien à labeller de façon significative pour les interstices. Bref là encore, l'objet label permet de remplacer la géométrie de la relation qui le désigne comme label,par une géométrie plus simple et mieux adaptée à la représentation graphique de la carte. Le label n'est donc qu'une information destinée au rendu de la carte, mais pas fondamental pour la géométrie logique et la cohérence de la base de données. Disons que c'est une annotation, une métadonnée optionnelle (qui pourrait ne pas être stocké dans la base OSM elle-même, mais dans une base annexe, comme une couche séparée. Les noms qu'on met dans les labels font donc effectivement doublons. La donnée essentielle, qui doit faire foi, est l'indication du nom (et ses traductions et noms alternatifs utiles aux recherches, ou noms longs formels et officiels utiles pour certains états statistiques ou pour une carte "diplomatique", ou noms non officiels "common_name:*" utilisés par les habitants locaux ou dans d'autres pays, y compris des translitérations approximatives et souvent encore plus ambigus qu'utilisent pourant couramment les russophones) par la relation mère elle-même. Les noms présents dans les labels ne devraient pas être utilisés du tout par un moteur de rendu sur une carte, sauf si ces objets "label" sont ajoutés par eux dans leur propre base de toponymes modifiés pour un rendu spécifique (par exemple des noms abrégés, ou avec des sauts de ligne et indicateurs de césure). > Les non-cas sont assez réduit vis à vis du cas général tout de même... > Si le moteur de rendu pouvait ommettre le nom de la relation quand il y > a un admin_centre qui porte le même nom ça serait un peu plus clair au > niveau de la lisibilité tout de même... Là je ne suis pas d'accord du tout : l'admin_center, qui désigne un autre objet n'a rien à voir ! Et effectivement il peut même être géométriquement en dehors de la relation qui le désigne (c'est courant pour les cantons et EPCI français, quand le même admin_center regroupe géographiquement les administrations de plusieurs entités administratives différentes (plusieurs cantons ont le même siège dans les batiments administratifs de la commune hôte du chef-lieu, les entités existent cependant avec des personnes responsables et des élus différents, mais travaillant au même endroit, ou se partagent du personnel administratif pour l'accueil du public par exemple). Il reste cependant un cas fréquent: même si une zone (par exemple un département) a plusieurs exclaves, et désigne bien une seule commune (la commune chef_lieu du département) comme admin_center, et en plus désigne même un label pour aider au placement du nom du département (à un endroit distinct de celui du chef-lieu), Mapnik va systématiquement ajouter de lui-même autant de labels pour cette zone (le département) qu'il y a de zones connexes (la partie principale du département et chaque exclave) en le plaçant systématiquement sur une position calculée (apparemment au centre de la bounding box de chaque partie connexe, c'est-à-dire une partie faite de chemins interconnectés avec un rôle "outer" ou vide). Mapnik n'omet pas ces labels (complètement parasites à mon avis) QUE si une partie connexe désigne la totalité des contours (autrement dit si la zone n'a aucune exclave, les éventuelles enclaves "inner" étant ignorées pour ce test). Pour moi cela est bien un bogue de Mapnik. C'est le cas où son emploi du label (positionné explicitement dans la base) et du nom (positionné automatiquement selon les chemins) fait doublon. Autrement dit: s'il y a un label dans une relation, et si Mapnik choisit de l'utiliser pour l'afficher, Mapnik ne devrait PAS utiliser autre chose pour la relation qui le désigne, mais devrait continuer à utiliser les noms de la relation (à moins qu'un label vienne le modifier pour des raisons purement esthétiques). Raison de plus pour que les labels disparaissent de la base OSM principale, et aillent plutôt dans une base séparée propre à Mapnik, dans laquelle il pourra aussi stocker des préférences de tailles ou de styles de polices de caractères (avec des attributs qui lui seront propres). En revanche les admin_center sont à garder dans la base principale, avec leurs propres noms bel et bien différents de ceux de la relation : ils sont essentiels et utiles même pour autre chose que la représentation graphique de cartes (par exemple pour Nominatim qui cherche les noms des zones mères pour afficher des précisions permettant de distinguer des homonymes, tels que deux communes homonymes dans des départements (ou régions, pays...) différents et qui apparaissent dans une liste de lieux trouvés en cherchant juste le nom de la commune). _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
