> 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
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
