[OSM-talk-fr] tuiles vectorielles et internationales

Dim 26 Juil 16:47:25 UTC 2015

Le 26/07/2015 15:44, osm.sanspourriel at spamgourmet.com a écrit :
> > Nous n'avons cependant jamais fait le pas pour finaliser un site
> avec tout les services utiles...
> > (recherche d'adresse ou POI, calcul d'itinéraire, différents rendus,
> etc).
> > Ce n'est pas par choix, mais plus par manque de disponibilité et
> d'huile de coude.
>
> Tu es dans l'optique OpenStreetMap.org redirige vers OpenStreetMap.fr,
> j'avais en tête osm.org va chercher les tuiles chez osm.fr.
> Les deux possibilités sont intéressantes.
> La seconde solution nécessite essentiellement une machine qui accepte
> le trafic, on utilise toujours OSM.org pour les outils.
> L'un n'empêche pas l'autre : renforcer la structure puis la suite
> logicielle.
> Dans le second cas il faudrait que les serveurs de tuiles (osm.fr)
> puissent s'enregistrer auprès d'osm.org pour apparaître dans les
> couches disponibles (en fonction du user agent plus exactement du
> Accept-Language ? Si je dis que j'accepte fr/de/en, des couches
> produites par osm.fr, osm.de et celles produites en utilisant
> l'anglais m'intéressent potentiellement).
>

J'avais bien compris, mais c'est un choix qui se fait au niveau de la
fondation et l'objectif du site openstreetmap.org n'est pas de devenir
LE point d'entrée pour fournir des services à partir des données OSM (ce
qu'Emilie décrivait en parlant d'un map.openstreetmap.com).

Il y a eu de longues discussions avant d'ajouter le calcul
d'itinéraires. Ce site sert surtout à montrer ce qu'on peut faire avec
OSM, mais sans vouloir faire trop d'ombre à toutes les initiatives autour.

Dans les services que je verrai bien sur un map.openstreetmap.fr il y a:
- des tuiles "FR"
- un géocodage qui s'appuie sur BANO/BAN+POI OSM et avec
l'autocomplétion que permet addok
- d'autres couches de tuiles
- un calcul d'itinéraire (comme osm.org)
- un accès facilité à uMap avec un bouton "Personnaliser cette carte"
etc...

Certains de ces ajouts trop spécifiques n'iront pas sur osm.org.

>> /Sinon une question marginale : je vois que pas mal de villes/pays
>> ont un attribut name:<lg> qui est identique à l'attribut name.//
>> //Certes ça permet de savoir que Paris s'écrit Paris en allemand,
>> mais est-ce bien utile ?//
>> //name=Paris ne veut-il pas dire que le nom est Paris dans toutes les
>> langues sauf celles précisées (name:br=Pariz par exemple).//
>> //Pour le Mont Blanc, on peut imaginer qu'un jour name= change et que
>> l'on veuille avoir dans tous les cas name:it et name:fr.//
>> ///
> ///
> //On gagnerait très peu (un seul tag de moins) et on perdrait beaucoup://
> //- impossible de savoir dans quelle lanque est le name par défaut (ou
> alors il faudrait ajouter un tag pour l'indiquer)//
> //- complication pour le rendu... sur FR, un simple coalesce permet de
> prendre le name:fr si présent, puis name:en, puis intl_name puis
> name... sans name:fr sur Londres ça compliquerai énormément !
>
> /Soit tu n'as pas compris ma proposition soit je n'ai pas compris ta
> réponse.
> Car sur l'exemple ça voudrait dire que le name de Paris est en
> allemand, pas en français ;-(.
> Le name c'est le nom dans la langue locale, c'est à dire pour Londres
> l'anglais (name=London), figure aussi name:fr=Londres et name:en=London.

Si il n'y a qu'une langue locale ça marche... mais c'est pas le cas
partout !
Belgique, Suisse, etc... sans oublier aussi les langues régionales.

> Tu me dis (je pense) que name:en=London est utile. Soit.
> Je disais que name:de=Paris est inutile puisque name=Paris et que si
> on ajoute le nom dans toutes les langues du monde alors que c'est le
> nom dans la langue locale, ça va alourdir inutilement.
>

name=Paris ne me dit pas que Paris en allemand s'écrit aussi Paris...

Il faut penser au fait que de nombreux name ne sont disponibles que dans
la langue locale par défaut et que toutes les traductions n'ont peut
être pas été ajoutées. Si name:de n'est pas là c'est peut être qu'il n'a
pas encore été renseigné plutôt que dire que c'est la même graphie que
le name.

> > /- impossible de savoir dans quelle lanque est le name par défaut
> (ou alors il faudrait ajouter un tag pour l'indiquer)//
> / Est-ce que la langue de "name" ne devrait pas être déterminée par la
> relation / les polygones (de type boundary ?) englobants ?

Ouille... bonjour le préprocessing, et ce n'est pas toujours le cas.
Il y a beaucoup de name qu'on peut trouver qui n'ont pas été renseignés
dans la langue locale (par manque de contributeurs locaux).
Déterminer la langue de name est donc peu fiable alors que si on
renseigne les name:* là l'info est claire et sans ambiguïté.

> La langue principale de la France est le français, donc les name en
> France sont en français. Un peu comme on a timezone.
> Actuellement je ne trouve l'info que sur le wiki, alors que si on
> avait un default_language=fr (par exemple) voir un
> default_language={{fr}} - {{de}} (lire : le name c'est name:fr suivi
> de name:de séparés par " - ").
>
> Mais mettre l'info sur les objets englobants suffit.
>
> Bon, pour des règles comme langue X et Y par ordre alphabétique
> international ça ne marche pas.
>
> L'ordre "fr, à défaut en, à défaut international, à défaut name" c'est
> pour les pays à alphabet non latin ?
> Je pensais que l'ordre était /name:fr/, i/ntl_name/, /name/.

Je ne sais pas dans quel alphabet est intl_name et il est parfois
multilingue... j'ai eu quelques surprises d'où le name:en

>
> Si je prends Nuremberg:
> name <http://wiki.openstreetmap.org/wiki/FR:Key:name?uselang=fr>
> Nürnberg
> name:de <http://wiki.openstreetmap.org/wiki/Key:name:de?uselang=fr>
> Nürnberg
> name:en <http://wiki.openstreetmap.org/wiki/Key:name:en?uselang=fr>
> Nuremberg
> name:fr <http://wiki.openstreetmap.org/wiki/Key:name:fr?uselang=fr>
> Nuremberg
>
>
> Ça me semble correct : le nom en français n'est pas le nom en langue
> officielle locale (l'allemand), donc on le met.
> C'est ce que je disais.
> D'après ce que tu dis, s'il n'y avait pas de nom en français il
> prendrait le nom en anglais. Ça tomberait juste, mais ça me dérange.
> Car si les 6 000 langues sont renseignées (et dans 90 % identiques à
> la langue locale), ça va faire du peuple.
>
> Si je prends Paris : 144 infos de langues.
> Là un filtre en fonction du user agent va être utile !
> Dans 8 langues, Paris=Paris.

Donc plus proche de 6% que de 90% ;)

En fait il faudrait plutôt renseigner un tag wikidata pour préprocesser
en masse tout ça dans la langue de son choix... mais on en est encore
bien loin.

> Il y a name=Paris (normal), pas name:fr ou name:en (ça me va), par
> contre il y a name:de=Paris. ça me gêne.
> Et c'est la raison de ma question : va-t-on ajouter dans x langues
> name:/lg/=Paris ?
> Si d'un point de vue théorique ça permet de savoir que c'est le bon
> nom dans cette langue, ça me semble lourd.
>
> > Attention, loc_name=* correspond à une appelation "locale", non
> officielle.
> J'entends bien. name c'est le nom dans la langue officielle locale, ce
> qui est différent.
> Question post SOTM 2015 : "Brest-même" c'est loc_name ou alt_name ? ;-)

Pas compris

-- 
Christian Quest - OpenStreetMap France

-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20150726/72addb85/attachment.htm>