Am 20.11.2013 03:01, schrieb Philippe Verdy: > 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:
Cette recherche ne coûte pas tant que ça, ça demande juste un peu de matière grise. Accéder aux tags de l'admin_centre pour faire le rendu de la limite administrative est probablement plus coûteux, pourtant personne propose de copier les tags de l'admin_centre sur la relation boundary. > 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. J'ai déjà cité un cas où ce n'est pas si simple que ça: nominatim. Pour pouvoir afficher les noms français dans le résultat d'une recherche, ce logiciel doit tenir compte de la localisation. Sinon, avec "fr, en" comme langues préférees du navigateur, il afficherait le nom anglais pour les lieux en France qui ont un name:en mais pas de name:fr. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
