Je ne suis ps d'accord sur le fait qu'on puisse déduire une information linguistique d'une donnée géographique. Donc chercher une langue applicable à partir d'un polygone est à la base une très mauvaise idée.
On n'a même pas besoin de faire cette coûteuse recherche quand les données linguistiques sont déjà toutes dans un seul objet: les champs name=* et name:xx=* suffisent totalement pour déduire ce qu'on doit afficher MÊME si name=* ne précise pas sa propre langue : c'est un fallback suffisant si le "bon" name:xx=* n'est pas trouvé et qui ser TOUJOURS meilleur que d'afficher le premier name:xx=* au hasard (donc sans non plus regarder de quelle langue il s'agit, comme le fait Nominatim de façon boguée) Implémenter correctement les "language fallbacks" ne demande pourtant aucun requête supplémentaire à la base (même sur une base interne à Nominatim convertie à partir des tags importés d'OSM). Mais si tous les tags d'un objet ne sont pas chargés par Nominatim, sa requête reste simple. Si Nominatim veut un filtre qui marche pour les name:xx=* et name=*, il peut convertir dans sa base les tags OSM name=* en name:und=* et utiliser le filtre "name:*=*" sans être gêné par l'absence de suffixe et sans activer une recherche de tags un peu plus couteuse par expressions régulière comme /name(:.*)?/, car il peut lors utiliser une recherche plus simple (et indexable) par le seul préfixe verbatim "name:". (le code langue "und", standard dans ISO 649 et BCP 47, est utilisable pour ça: une langue indéterminée) Il peut aussi éliminer de sa propre base les name:xx=* dont la valeur est identique à celle de name:und=* s'il veut faire de la place. Bref arrêtez de vous poser des questions sur le coût des recherches de langue par zone géographique, alors qu'il ne **faut** même pas le faire. Le seul cas où c'est valable, c'est si on n'a pas le bon "name:xx=*" et pas non plus de "name=*"; mais dans ce cas on peut souvent l'éviter en regardant d'autres codes langues utilisables sans prendre le premier trouvé au hasard Par exemple si on ne trouve pas "name:br=*", on cherche "name:fr=*", puis "name:en=*", puis "name=*". Et sinon seulement dans ce cas-là, on va chercher une liste de langues par défaut pour une zone géographique contenant l'objet et voir si il y en une autre que celles déjà testées pour les name:xx précédents. La seule présence d'un champ name=* coupera court à TOUTES les recherches géographiques. Bref si on veut un outil de gestion de la qualité pour OSM, celui-ci ne doit pas chercher les "name:xx:*" manquants dans une zone géographique donnée, mais plutôt les objets ayant un ou plusieurs "name:xx=*" mais aucun "name=*". On est ici dans exactement la même position que la traduction de messages dans un logiciel, ou la traduction d'un wiki ou d'un modèle inclus dans une page web (et pourtant ils n'ont strictement aucune donnée géographique, ils n'en ont JAMAIS besoin, ils sont uniquement concernés par des données linguistiques) Le 19 novembre 2013 20:43, rainerU <ra...@sfr.fr> a écrit : > Am 19.11.2013 15:36, schrieb Pieren: > > A Rainer, je répéterais que ma réponse est nuancée dans les zones qui > > ont plusieurs langues officielles (pays, cantons ou villes) (auquel > > cas le tag "name" contient généralement toutes les langues (ou parfois > > la version "coloniale" dans les anciennes colonies qui manquent de > > contributeurs locaux)). Le jour où le Corse deviendra langue > > officielle, on pourra en reparler. Mais il ne faudrait pas qu'OSM > > anticipe toute décision dans ce domaine au risque de voir proliférer > > des guerres d'édition. Je trouverais aussi bizarre qu'une règle "on > > duplique 'name' dans 'name:fr' "ne s'applique qu'à Perpignan ou que > > lorsqu'il y a un tag "name:oc". > > Je suis d'accord qu'il faut éviter de mettre des données sur un objet > qu'on peut > déduire de la position géographique de celui-ci. C'est d'ailleurs ce que > j'ai > fait pour le rendu sur http://www.openstreetmap.cat/ où j'avais besoin de > connaître la langue du tag "name". J'ai codé le choix du tag à utiliser en > dur: > name:ca dans les Pyrénées-Orientales, name en Andorre et les régions > catalanophones de l'Espagne, rien pour les autres. > > En parlant de duplication de noms: un contributeur à dupliqué les name:ca > des > communes catalanophones des Pyrénées-Orientales en name:oc parce qu'en > occitan > on utiliserait le nom catalan quand il n'existe pas de version occitane. > > > > > > _______________________________________________ > 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
