[OSM-talk-fr] tuiles vectorielles et internationales

[osm.sanspourriel at spamgourmet.com]

 > L'autre solution est un rendu purement vectoriel comme le projet de 
Google en WebGL ce qui est généralement horriblement lent.
Purement vectoriel ne veut pas dire laisser le client tout gérer, il 
peut y avoir du pré-calcul.
Mais oui, il y a du boulot (comme pour l'internationalisation).
Si on regarde 
http://demo.f4map.com/#lat=38.8883621&lon=-77.0171328&zoom=19&camera.phi=-119.519 
(je n'ai pas regardé la techno, WebGL je suppose), on voit qu'ils 
passent la 2D, 2,5D puis la 3D (arbres, grues pour le tag construction, 
vrais modèles 3D hors OSM) pour obtenir de la 3D et c'est encore lent.
Avec des gags dus à l'inhomogénéité des données, ainsi il y a des 
bosquets qui y sont et d'autres qui n'y sont pas : n'auraient-ils 
importé que les arbres municipaux ? ;-).
Par contre, pas de soucis pour le WebGL en soit.

 > Le rendu FR est disponible autrement que via umap: 
http://tile.openstreetmap.fr/
Merci, je m'en suis rappelé après avoir posté le message.

 > 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).

> /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.
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.

 > /- 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 ?
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/.

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.
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 ? ;-)

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