<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="transparent" text="#000000">
> L'autre solution est un rendu purement vectoriel comme le
projet de Google en WebGL ce qui est généralement horriblement lent.<br>
Purement vectoriel ne veut pas dire laisser le client tout gérer, il
peut y avoir du pré-calcul.<br>
Mais oui, il y a du boulot (comme pour l'internationalisation).<br>
Si on regarde <a
href="http://demo.f4map.com/#lat=38.8883621&lon=-77.0171328&zoom=19&camera.phi=-119.519"><a class="moz-txt-link-freetext" href="http://demo.f4map.com/#lat=38.8883621&lon=-77.0171328&zoom=19&camera.phi=-119.519">http://demo.f4map.com/#lat=38.8883621&lon=-77.0171328&zoom=19&camera.phi=-119.519</a></a>
(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.<br>
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 ? ;-).<br>
Par contre, pas de soucis pour le WebGL en soit.<br>
<br>
> Le rendu FR est disponible autrement que via umap: <a
class="moz-txt-link-freetext" href="http://tile.openstreetmap.fr/"><a class="moz-txt-link-freetext" href="http://tile.openstreetmap.fr/">http://tile.openstreetmap.fr/</a></a><br>
Merci, je m'en suis rappelé après avoir posté le message.<br>
<br>
> Nous n'avons cependant jamais fait le pas pour finaliser un
site avec tout les services utiles...<br>
> (recherche d'adresse ou POI, calcul d'itinéraire, différents
rendus, etc).<br>
> Ce n'est pas par choix, mais plus par manque de disponibilité
et d'huile de coude.<br>
<br>
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.<br>
Les deux possibilités sont intéressantes.<br>
La seconde solution nécessite essentiellement une machine qui
accepte le trafic, on utilise toujours OSM.org pour les outils.<br>
L'un n'empêche pas l'autre : renforcer la structure puis la suite
logicielle.<br>
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 <span
class=" ">Accept-Language</span> ? 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).<br>
<br>
<blockquote cite="mid:55B3655D.9030605@gmx.net" type="cite"> <i>Sinon
une question marginale : je vois que pas mal de villes/pays ont
un attribut name:<lg> qui est identique à l'attribut name.</i><i><br>
</i><i> Certes ça permet de savoir que Paris s'écrit Paris en
allemand, mais est-ce bien utile ?</i><i><br>
</i><i> 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).</i><i><br>
</i><i> 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.</i><i><br>
</i><i> </i></blockquote>
<i> </i><i><br>
</i><i> On gagnerait très peu (un seul tag de moins) et on perdrait
beaucoup:</i><i><br>
</i><i> - impossible de savoir dans quelle lanque est le name par
défaut (ou alors il faudrait ajouter un tag pour l'indiquer)</i><i><br>
</i><i> - 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 !<br>
<br>
</i>Soit tu n'as pas compris ma proposition soit je n'ai pas compris
ta réponse.<br>
Car sur l'exemple ça voudrait dire que le name de Paris est en
allemand, pas en français ;-(.<br>
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.<br>
Tu me dis (je pense) que name:en=London est utile. Soit.<br>
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.<br>
<br>
> <i>- impossible de savoir dans quelle lanque est le name par
défaut (ou alors il faudrait ajouter un tag pour l'indiquer)</i><i><br>
</i>
Est-ce que la langue de "name" ne devrait pas être déterminée par la
relation / les polygones (de type boundary ?) englobants ?<br>
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.<br>
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 " - ").<br>
<br>
Mais mettre l'info sur les objets englobants suffit.<br>
<br>
Bon, pour des règles comme langue X et Y par ordre alphabétique
international ça ne marche pas.<br>
<br>
L'ordre "fr, à défaut en, à défaut international, à défaut name"
c'est pour les pays à alphabet non latin ?<br>
Je pensais que l'ordre était <i>name:fr</i>, i<i>ntl_name</i>, <i>name</i>.<br>
<br>
Si je prends Nuremberg:<br>
<table class="browse-tag-list">
<tbody>
<tr>
<th class="browse-tag-k"><a title="La description de
l’attribut <code>name</code> sur le wiki"
href="http://wiki.openstreetmap.org/wiki/FR:Key:name?uselang=fr">name</a></th>
<td class="browse-tag-v">Nürnberg</td>
</tr>
<tr>
<th class="browse-tag-k"><a title="La description de
l’attribut <code>name:de</code> sur le wiki"
href="http://wiki.openstreetmap.org/wiki/Key:name:de?uselang=fr">name:de</a></th>
<td class="browse-tag-v">Nürnberg</td>
</tr>
<tr>
<th class="browse-tag-k"><a title="La description de
l’attribut <code>name:en</code> sur le wiki"
href="http://wiki.openstreetmap.org/wiki/Key:name:en?uselang=fr">name:en</a></th>
<td class="browse-tag-v">Nuremberg</td>
</tr>
<tr>
<th class="browse-tag-k"><a title="La description de
l’attribut <code>name:fr</code> sur le wiki"
href="http://wiki.openstreetmap.org/wiki/Key:name:fr?uselang=fr">name:fr</a></th>
<td class="browse-tag-v">Nuremberg</td>
</tr>
</tbody>
</table>
<br>
Ça me semble correct : le nom en français n'est pas le nom en langue
officielle locale (l'allemand), donc on le met.<br>
C'est ce que je disais.<br>
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.<br>
Car si les 6 000 langues sont renseignées (et dans 90 % identiques à
la langue locale), ça va faire du peuple.<br>
<br>
Si je prends Paris : 144 infos de langues.<br>
Là un filtre en fonction du user agent va être utile !<br>
Dans 8 langues, Paris=Paris.<br>
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.<br>
Et c'est la raison de ma question : va-t-on ajouter dans x langues
name:<i>lg</i>=Paris ?<br>
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.<br>
<br>
> Attention, loc_name=* correspond à une appelation "locale", non
officielle.<br>
J'entends bien. name c'est le nom dans la langue officielle locale,
ce qui est différent.<br>
Question post SOTM 2015 : "Brest-même" c'est loc_name ou alt_name ?
;-)<br>
<br>
Jean-Yvon<br>
</body>
</html>