[OSM-talk-fr] Label et rendu linguistique
osm2pgsql traite les noeuds avant les relations Le noeud a le rôle label dans la relation, mais c'est avant tout un noeud de type place Ici pour Jeju http://www.openstreetmap.org/browse/node/1900155946 où apparaît la description place = state Les noms traduits renseignés dans description de la relation n'apparaissent pas sur le rendu, tout simplement parce que la place est déjà prise par le nom inscrit sur le noeud place ? Je les sentais pas trop, ces noeuds avec un rôle label. Maintenant j'ai une bonne raison ... Le 19 décembre 2012 12:16, Christophe Merlet red...@redfoxcenter.org a écrit : Le mercredi 19 décembre 2012 à 12:02 +0100, Christophe Merlet a écrit : Le mercredi 19 décembre 2012 à 11:46 +0100, Ab_fab a écrit : Je n'arrive pas à visualiser le résultat de mes ajouts du 27/11 (avec Nomino) de la balise name:fr pour les relations des provinces de Corée (niveau 4) http://www.openstreetmap.org/browse/changeset/14064905 http://tile.paulla.asso.fr/openlayers.html?zoom=7lat=36.02407lon=127.7179layers=B000FF même souci sur le toolserver http://toolserver.org/~osm/locale/fr.html?zoom=7lat=36.02407lon=127.7179layers=BT Une idée de ce qui peut clocher ? Je viens de regarder pour la relation Jeju http://www.openstreetmap.org/browse/relation/2398560 La traduction n'apparait pas sur la carte car cette relation utilise un noeud label qui lui n'est pas traduit http://www.openstreetmap.org/browse/node/1900155946 Or c'est ce label qui est affiché sur la carte... donc pas de traduction en français. J'imagine que c'est la même chose pour tes autres relations traduite avec Nomino. En fait j'ai un doute. Je viens de greper les sources d'osm2pgsql et des feuilles de styles mapnik, à la recherche du mot label et je n'ai rien trouvé oO Donc j'ignore a quel moment le label est pris en compte... Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Label et rendu linguistique
Le 19 décembre 2012 15:25, Ab_fab gamma@gmail.com a écrit : osm2pgsql traite les noeuds avant les relations Le noeud a le rôle label dans la relation, mais c'est avant tout un noeud de type place Ici pour Jeju http://www.openstreetmap.org/browse/node/1900155946 où apparaît la description place = state Les noms traduits renseignés dans description de la relation n'apparaissent pas sur le rendu, tout simplement parce que la place est déjà prise par le nom inscrit sur le noeud place ? Je les sentais pas trop, ces noeuds avec un rôle label. Maintenant j'ai une bonne raison ... Je trouve plutôt que ces place=state n'ont pas lieu d'exister lorsqu'une relation décrit l'emprise de ce niveau administratif et indique par un node label où mettre le nom sur le rendu. Par contre, il faudrait peut être rajouter un place=state sur les relations elles même car si on retire ce place=state le rendu mapnik n'indique plus les noms de nos régions françaises... je sais c'est limite tagguer pour le rendu, ou plutôt pour contourner les bugs du rendu ;) Voir aussi les impacts côté nominatim... car là aussi c'est pas forcément très cohérent. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Label et rendu linguistique
Dans ce que j'ai compris la valeur qu'on donne à place=* sert : - à guider le style d'apparence du label (taille de police, gras, italique, grandes capitales ou petites capitales, voire soulignement... pour différencier les communes des lieux dits, des zones commerciales ou quartiers, noms de parcs ou autres entités géographiques comme les îles, ou archipels, sommets de montagne ou nom de massifs) - ou a guider son apparition ou non sur la carte (selon l'échelle de rendu) car on ne peut pas tous les afficher : il faut faire des choix arbitraires basés sur limportance relative (mais avec un critère pas clair : s'agit-il de la population su lieu seul, ou de son agglomération entère, ou de son statut adminsitratif par rapport à un niveau administratif donné ?) Souvent ce n'est pas clair et pas toujours objectif (par exemple entre place=island et place=islet : on passe à la comparaison des surfaces mais on ne sait pas toujours ce qui est inclus dans la surface : seule la partie toujours émergée ou le plateau attenant avec ses rochers et plages découvertes à marée basse). La valeur de ce place=* est donc assez qualititatif et très subjectif (et trop souvent guidé en fonction du rendu attendu sur un moteur de rendu particulier)... En revanche le membre de rôle label dans une relation est non subjectif : il décrit d'abord une position adéquate dans la surface où il est approprié de placer le label pour qu'il ne puisse pas être confondu avec la désignation d'autre chose. Là où il se justifie le plus c'est pour nommer des surfaces fortement convaves, ou enserrant des enclaves, ou éclatées en pusieurs sous-zones écartées les unes des autres : le label doit se positionner dans la zone effective et le calcul d'un centroïde est faux. En théorie le membre de rôle label n'est pas nécessairement restreint à désigner un seul noeud et pourrait prendre la forme d'un chemin continu, permettant d'indiquer comment orienter un label au lieu de ne pouvoir l'afficher par défaut qu'horizontalement, et à préciser la longueur selon laquelle il devrait s'étaler (au lieu d'utiliser des caractères avec une approche normale et de restreindre arbitrairement la largeur de rendu de ce label en urilisant des sauts de ligne) : ce serait utile pour les massifs de montagne, dont les relations ont aussi des frontières floues, à condition que la feuille de style l'autorise (c'est généralement le cas pour les labels qui devraient recourir une zone très étendue de la carte affichée, avec des polices très grandes et des caractères assez gras pour rester lisibles mais semi-transparents pour ne pas cacher le reste en dessous. Les noms indiqués dans le label n'ont souvent guère d'importance : mais ils peuvent cependant être différents du nom classique utilisé pour désigner (hors du contexte de la carte elle-même) une région. En effet la carte fournit un contexte qu'il n'est pas nécessaire de rappeler, au contraire du nom utilisé pour désigner une région toute seule (ce nom doit être assez précis et descriptif, même si on a ôté de ce nom des éléments qui sont rappelés dans d'autres attributs, notamment le type générique d'objet). L'exemple typidque de simplification du nom dans un label est la suppression des prévisions qui lèvent l'ambiguité sur une homonymie simple. Pour ces raisons, les noms indiqués dans un label sont prioritaires sur ceux de la relation quand on devra choisir un nom signifiant pour un rendu cartographique (où ces noms seront aussi spatialement géolocalisés, et donc déjà différenciables sans ambiguïté par leur position). Les noms indiqués dans un label n'ont en revanche aucune utilité dans un rendu de type tableau de données (où figure ensuite un lieu vers la carte, ou bien une minicarte où les noms de zones sont remplacés par un petit numéro d'index dans chaque zone, le tableau de données référençant ensuite ce numéro, mais donnant le nom assez précis (sans homonymie) de la relation. Mais dans la plupart des cas, le label et le nom de la relation n'ont pas à être différents : si une relation a un membre label nommé, les noms données à la relation deviennent redondants, et il vaut mieux alors le mettre (avec ses traductions) dans le label. Attention : certains noms peuvent être homonymes dans une langue et pas dans une autre : il ne faudrait pas créer de nouvelles homonymies en transférant systématiquement les noms de relations vers leur label, et supposer alors que la relation est clairement (et uniquement) nommée d'après seulement son label (ce sera vrai pour un rendu cartographique, pas pour un rendu de ces noms dans un tableau de données) : on peut y copier des noms de la relation vers le label mais pas faire l'inverse du label vers la relation. Le 19 décembre 2012 15:59, Christian Quest cqu...@openstreetmap.fr a écrit : Le 19 décembre 2012 15:25, Ab_fab gamma@gmail.com a écrit : osm2pgsql traite les noeuds avant les relations Le noeud a le rôle label dans la relation, mais c'est avant tout un noeud de
Re: [OSM-talk-fr] Label et rendu linguistique
Le 19/12/2012 19:22, Philippe Verdy a écrit : Dans ce que j'ai compris la valeur qu'on donne à place=* sert : - à guider le style d'apparence du label (taille de police, gras, italique, grandes capitales ou petites capitales, voire soulignement... pour différencier les communes des lieux dits, des zones commerciales ou quartiers, noms de parcs ou autres entités géographiques comme les îles, ou archipels, sommets de montagne ou nom de massifs) - ou a guider son apparition ou non sur la carte (selon l'échelle de rendu) car on ne peut pas tous les afficher : il faut faire des choix arbitraires basés sur limportance relative (mais avec un critère pas clair : s'agit-il de la population su lieu seul, ou de son agglomération entère, ou de son statut adminsitratif par rapport à un niveau administratif donné ?) Souvent ce n'est pas clair et pas toujours objectif (par exemple entre place=island et place=islet : on passe à la comparaison des surfaces mais on ne sait pas toujours ce qui est inclus dans la surface : seule la partie toujours émergée ou le plateau attenant avec ses rochers et plages découvertes à marée basse). La valeur de ce place=* est donc assez qualititatif et très subjectif (et trop souvent guidé en fonction du rendu attendu sur un moteur de rendu particulier)... En revanche le membre de rôle label dans une relation est non subjectif : il décrit d'abord une position adéquate dans la surface où il est approprié de placer le label pour qu'il ne puisse pas être confondu avec la désignation d'autre chose. Là où il se justifie le plus c'est pour nommer des surfaces fortement convaves, ou enserrant des enclaves, ou éclatées en pusieurs sous-zones écartées les unes des autres : le label doit se positionner dans la zone effective et le calcul d'un centroïde est faux. Rien de plus subjectif que les objets label : ils sont clairement là pour la représentation de l'information, et en premier lieu pour la carte (placer le label, comme tu dis). Ce sont des objets cartographiques plus que géographiques, dont la position n'est pas déterminée par la situation géographique de ce qu'ils nomment, mais par l'anticipation d'une représentation carto. Autrement dit : je place le point label ici plutôt que là parce que j'ai en tête comment cela rendra sur une carte. Pour l'objectivité...on repassera. En théorie le membre de rôle label n'est pas nécessairement restreint à désigner un seul noeud et pourrait prendre la forme d'un chemin continu, permettant d'indiquer comment orienter un label au lieu de ne pouvoir l'afficher par défaut qu'horizontalement, et à préciser la longueur selon laquelle il devrait s'étaler (au lieu d'utiliser des caractères avec une approche normale et de restreindre arbitrairement la largeur de rendu de ce label en urilisant des sauts de ligne) : ce serait utile pour les massifs de montagne, dont les relations ont aussi des frontières floues, à condition que la feuille de style l'autorise (c'est généralement le cas pour les labels qui devraient recourir une zone très étendue de la carte affichée, avec des polices très grandes et des caractères assez gras pour rester lisibles mais semi-transparents pour ne pas cacher le reste en dessous. C'est déjà limite avec les points labels, ça devient flagrant avec des lignes label : on n'est plus dans la description du terrain mais dans la mise en forme d'une représentation, et par suite, en dehors d'OSM. Ce que tu décris a sa place sur une carte (la ligne de base d'un texte, etc.) mais pas dans la base _géographique_ OSM. Sans parler du fait qu'une telle ligne sera adaptée à une représentation à une échelle (ou plage d'échelles) donnée. On est bien là les deux pieds dans la carte. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Label et rendu linguistique
Pas vraiment, fixer un label pour qu'il se place correctement SUR la zone qu'il désigne et pas aritrairement en un seul point (souvent mal placé et parfois en dehors si on n'utilise que le centroïde) donne une information fausse sur la carte. Déterminer un endroit qui couvre bien la zone est facile à faire indépendamment du type de rendu : cela ne fixe rien concernant l'obligation de placer le label uniquement à un seul point arbitraire, c'est indépendant de l'échelle de rendu. La seule alternative ce sont les labels le long de la frontière, mais là le label est encore plus flou sur ce qu'il désigne puisqu'on les affiche tous mélangés (à droite ou à gauche. La seule chose qu'on cherche à déterminer c'est une zone convexe située dans la surface et qui n'en déborde pas. Si la surface est concave, que faut-il couper pour que cela devienne convexe ? (1) Il existe bien un algo simple, déterminant un UNIQUE surface convexe MINIMALE englobant une surface concave (cette surface est la surface donnée elle-même si elle est convexe, c'est visiblement à partir de lui qu'on détermine le centroïde qui sort trop souvent des surfaces concaves, notamment des surfaces constituées de plusieurs parties exclavées — ce qui n'est acceptable que si le label qu'on centre dessus couvrira une partie essentielle de la surface qu'il désigne, ce qui ne se produit à faible niveau de zoom où on ne voit pratiquement pas que la surface est concave et s'assimile à un seul point central visible) (2) Mais il n'y a pas d'UNIQUE surface convexe MAXIMALE inscrite dans une surface concave : c'est pourtant là qu'on devrait y placer un label, qui devrait être le plus couvrant possible. On peut chercher à couper du polygone concave la plus petite aire possible (pour que la surface convexe restante ait l'aire la plus grande possible), mais dans certains cas, on aura encore le choix (si deux découpes possibles pour rendre la surface convexe ont la même aire). Si on n'a pas d'algorithme, où veux-tu placer le label, et comment le placer qu'il soit le plus représentatif possible de la zone qu'il recouvre et de celle qu'il désigne ? Le 19 décembre 2012 23:02, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 19/12/2012 19:22, Philippe Verdy a écrit : Dans ce que j'ai compris la valeur qu'on donne à place=* sert : - à guider le style d'apparence du label (taille de police, gras, italique, grandes capitales ou petites capitales, voire soulignement... pour différencier les communes des lieux dits, des zones commerciales ou quartiers, noms de parcs ou autres entités géographiques comme les îles, ou archipels, sommets de montagne ou nom de massifs) - ou a guider son apparition ou non sur la carte (selon l'échelle de rendu) car on ne peut pas tous les afficher : il faut faire des choix arbitraires basés sur limportance relative (mais avec un critère pas clair : s'agit-il de la population su lieu seul, ou de son agglomération entère, ou de son statut adminsitratif par rapport à un niveau administratif donné ?) Souvent ce n'est pas clair et pas toujours objectif (par exemple entre place=island et place=islet : on passe à la comparaison des surfaces mais on ne sait pas toujours ce qui est inclus dans la surface : seule la partie toujours émergée ou le plateau attenant avec ses rochers et plages découvertes à marée basse). La valeur de ce place=* est donc assez qualititatif et très subjectif (et trop souvent guidé en fonction du rendu attendu sur un moteur de rendu particulier)... En revanche le membre de rôle label dans une relation est non subjectif : il décrit d'abord une position adéquate dans la surface où il est approprié de placer le label pour qu'il ne puisse pas être confondu avec la désignation d'autre chose. Là où il se justifie le plus c'est pour nommer des surfaces fortement convaves, ou enserrant des enclaves, ou éclatées en pusieurs sous-zones écartées les unes des autres : le label doit se positionner dans la zone effective et le calcul d'un centroïde est faux. Rien de plus subjectif que les objets label : ils sont clairement là pour la représentation de l'information, et en premier lieu pour la carte (placer le label, comme tu dis). Ce sont des objets cartographiques plus que géographiques, dont la position n'est pas déterminée par la situation géographique de ce qu'ils nomment, mais par l'anticipation d'une représentation carto. Autrement dit : je place le point label ici plutôt que là parce que j'ai en tête comment cela rendra sur une carte. Pour l'objectivité...on repassera. En théorie le membre de rôle label n'est pas nécessairement restreint à désigner un seul noeud et pourrait prendre la forme d'un chemin continu, permettant d'indiquer comment orienter un label au lieu de ne pouvoir l'afficher par défaut qu'horizontalement, et à préciser la longueur selon laquelle il devrait s'étaler (au lieu d'utiliser des caractères avec une approche normale et de restreindre
Re: [OSM-talk-fr] Label et rendu linguistique
Le 19 décembre 2012 23:02, Vincent de Chateau-Thierry v...@laposte.net a écrit : Rien de plus subjectif que les objets label : ils sont clairement là pour la représentation de l'information, et en premier lieu pour la carte (placer le label, comme tu dis). Ce sont des objets cartographiques plus que géographiques, dont la position n'est pas déterminée par la situation géographique de ce qu'ils nomment, mais par l'anticipation d'une représentation carto. Autrement dit : je place le point label ici plutôt que là parce que j'ai en tête comment cela rendra sur une carte. Pour l'objectivité...on repassera. Je vois ça comme une aide au placement de texte, mais c'est vrai que c'est une info destinée uniquement au rendu et à utiliser ou pas en fonction... du rendu ;) Le placement de texte est un casse tête passionnant quand on veut produire une carte utile et lisible. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
