En pratique, y a-t-il dans la cartographie actuelle une route européenne dont la structure puisse servir de modèle pour les autres?
2016-01-26 16:00 GMT+01:00 Otourly Wiki <otou...@yahoo.fr>: > Les spécificités du Québec ne répondent pas à la problématique des routes > européennes qui sont multiculturelles et multilingues, je pense. > > Florian Farge aka Otourly > #WeAreFairphone > > > Le Mardi 26 janvier 2016 14h54, Pierre Béland <pierz...@yahoo.fr> a écrit > : > > > La langue officielle en France est le français. > donc pour le territoire français, name contient la dénomination française, > portion allemande, l'allemand. et si vous le voulez, name:en peut être > ajouté. > > Nous procédons ainsi au Canada. Québec en français. > > > > Pierre > > > > ------------------------------ > *De :* Damouns <damo...@gmail.com> > *À :* Discussions sur OSM en français <talk-fr@openstreetmap.org> > *Envoyé le :* mardi 26 janvier 2016 2h53 > *Objet :* Re: [OSM-talk-fr] Problème de langue > > Moi je suis assez d'accord avec Jean-Yvon : je ne vois pas l'intérêt du > name= dans le cas d'un objet international comme ça. A la limite je verrais > bien des name:fr=, name:de=... mais pas de name= car en plus il est > redondant avec le ref. > > > Damouns > > Le 26 janvier 2016 à 07:33, Dominique Faure <dominique.fa...@gmail.com> a > écrit : > > 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 > > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > > > > _______________________________________________ > 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
