Donc si je résume par rapport à mon propos initial, il faudrait finir par avoir: => Une relation "name=European route 54", référençant: ==> 2 relations "name:fr=Route européenne 54" et "name:de=Europastraße 54" pour chaque portion nationale, référençant: ===> p segments élémentaires existants, nommés ou non suivant le cas.
C'est ça? J'ai regardé un peu alentour, il semblerait que la route E60 présente déjà une structure similaire. Faut-il se caler dessus? Enfin, la question qui fâche, qui fait la modif? :) 2016-01-26 0:49 GMT+01:00 Philippe Verdy <verd...@wanadoo.fr>: > > > Le 25 janvier 2016 à 22:41, Jérôme Seigneuret <jseigneuret-...@yahoo.fr> > a écrit : > >> Bonjour, >> >> J'appui Jean-Yvon pour le name >> >> Coté relation David à raison sur le fait de gérer des relations avec des >> niveaux multiples ce qui permet d'importer des portions ou de gérer des >> itinéraires logiques par étapes avec les différents niveau (local, >> régional, national...) d'où l'utilisation du name anglais sur une >> super-relation (en Europe quand ça traverse les frontières) >> >> Pour le check d'OSM c'est pas trivial sur le test du nom. >> >> Je reprends le cas de Philippe >> *Noms dans la langue locale et dans la langue par défaut différents* >> *way 83115947 <http://www.openstreetmap.org/browse/way/83115947>* rawedit >> <http://osmose.openstreetmap.fr/fr/map/#> josm >> <http://localhost:8111/load_object?objects=w83115947> edit >> <http://osmose.openstreetmap.fr/fr/map/#> >> *highway* = living_street >> *maxspeed* = 20 >> *name* = Chemin des Bauches >> *name:fr* = Lotissement le Manoir >> >> Là on n'est vraiment pas sur une question de langue mais sur une >> incohérence de nom. C'est pas la traduction qui est testé mais juste une >> correspondance entre le territoire le name:[langue] et le name >> > > Je n'ai pas dit le contraire, seulement ton débat concernant le territoire > est hors sujet mais c'est pourtant le même test qui est fait : trouver une > correspondance entre un name:lang=* et le name=* Et Là Osmose ne teste pas > tous les name:lang=* mais se limite à chercher le name sur un seul noeud > pour lequel il détermine quelle devrait être "la" langue locale et signale > ensuite l'erreur sur la relation entière puisque alors le name=* par défaut > n'a pas la valeur du name:fr... Même si le noeud n'a qu'une langue locale, > ce n'est celle de la relation entière, hors le résultat s'affiche pour la > relation entière ou le chemin ou polygone entier. C'est ça qui est > défectueux: déterminer la langue locale d'une relation sur un seul de ses > noeuds (choisi en fait arbitrairement) ne peut pas marcher du tout et > donnera des résultats faux si l'objet n'est pas tout entier dans un > territoire linguistique unique (dans ce seul cas le noeud choisi > arbitrairement marchera puisqu'il fait partie de l'objet entièrement > contenu dans la même zone linguistique). > > Bref mon exemple (qui là concernait une rue donc un chemin (qui pourrait > lui aussi couvrir plusieurs territoires lingusitiques) est défectueux aussi > sauf que la rue entière est dans le même territoire que le noeud choisi sur > ce chemin. Mais ça marche seulement à moitié. > > Je maintiens donc ce que je disais : > > - pas besoin de déterminer une langue locale (s'il y en a une malgré tout, > il suffit qu'elle ait une valeur "name:lang=*" correspondante à cette > langue, mais nul besoin que ce soit la langue par défaut pour la valeur du > name=* qui peut rester différente (exemple courant : les noms par défaut en > Chine ou dans les pays arabes peuvent rester en anglais, même si la langue > locale est le chinois ou l'arabe, mais il faudrait autant que possible > libeller précisément ce nom anglais aussi avec name:en=*) > > - dans les pays ou régions officiellement multilingues on ne peut pas > déterminer quelle est la langue par défaut et ce n'est même pas souhaitable > (pas plus que d'imposer l'anglais dans ce cas alors que le nom anglais > serait en fait une approximation grossière et que le nom romanisé serait en > fait issu d'une transliteration latine officielle telle que le romaji > japonais, ou les transliterations officielles ou universitaires du chinois > ou du coréen, ou les romanisations BPCN utilisées sur les cartes de l'ONU > et dans les échanges cartographiques internationaux, ou les > transliterations des organisemes internationaux pour l'aviation ou la > navigation maritime) ; en revanche on n'oublira pas de mentionner les noms > dans les langues officielles mais il reste alors le choix du nom "par > défaut" qui devrait être comme c'est vu localement multilingue. Pour que ce > nom par défaut corresponde à un des "name:lang=*" il suffit de l'indiquer > aussi dans "name:mul=*", et le problème est résolu. Pas de problème ensuite > pour n'afficher que l'anglais avec un "name:en=*" si nécessaire (notamment > si le nom multilingue officiel utilise des écritures différentes telles que > latin+arabe ou latin+sinogrammes). > > - quand le nom par défaut est une romanisation adaptée à l'usage > international (BPCN, aviation civile, etc.), là on a un "int_name=*" qui > n'est pas non plus forcément le nom anglais ! C'est une (pseudo-)langue à > part (qui n'est ni "name:mul=*", ni "name:en=*"), à usage technique > spécialisé (équivalent à un "name:int=*") pour un certain nombre de normes > de toponymie (ces normes utilisent plus de diacritiques que l'anglais, > exemple avec les noms japonais en internationalisés en romaji, avec les > macrons sur les voyelles longues, autres exemples avec la romanisation du > russe, autre exemple avec la romanisation du serbe dont il existe une > transcription latine officielle avec des haceks et carons, alors que > l'anglais les supprime facilement et introduit trop d'homonymies). > > - juste tester SEULEMENT S'il y a UN OU PLUSIEURS "name:lang=*", un de > ceux-là est à la même valeur que le "name=*" par défaut. Osmose ne doit pas > aller plus loin ("int_name=*" doit être ignoré et il peut être différent du > nom par défaut quand le nom par défaut officiel est multilingue) > > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > > -- Dominique
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
