Re: [OSM-talk-fr] tuiles vectorielles et internationales
De deux choses l'une : - soit le "name" doit être considéré comme valable pour toutes les langues sauf celles précisées explicitement. Je croyais que c'était ce que tu suggérais depuis le début. Dans ce cas le logiciel affichera le "name" si mon premier choix (name:fr) n'est pas renseigné, puisqu'il suppose que c'est la même chose. Et je ne verrai pas le nom anglais (mon second choix) pour les villes chinoises. - soit, comme tu sembles le dire ici, le logiciel affiche le nom dans la seconde langue lorsqu'il n'est pas renseigné dans la première langue. Alors le problème inverse se pose pour le nom allemand de Paris. Celui qui choisit "allemand, italien" verra "Parigi" et non "Paris" si "name:de" n'est pas renseigné. Indiquer le nom allemand (ou anglais) de Paris, ce n'est pas simplement pour la beauté du savoir : cela a forcément un effet concret sur l'utilisation de la base et il faut bien l'indiquer d'une manière ou une autre. (Wikidata, évoqué par Christian, est peut-être la meilleure solution pour éviter la duplication de travail sur des données non strictement cartographiques, mais c'est un débat bien plus large...) Thierry Le 27/07/2015 00:29, osm.sanspourr...@spamgourmet.com a écrit : Tu l'as effectivement dit mais ce n'est simplement pas vrai. Si le nom en anglais existe, name:en sera renseigné. Ton logiciel pourra en tirer partie o(u pas). Tu connais beaucoup de villes en Chine dont la version en anglais est la même qu'en Chinois ? Si tel est le cas alors ton rendu "fr sinon en sinon zh" rendra en qui sera égal à zh, le mien rendra zh c'est à dire... la même chose. J'ai aussi précisé que si ça peut être utile on peut ajouter mais à part (dans le sens moins visible car moins pertinent) les données. Ton name:equals_default=, c'est ce que je dis dans "Bien-sûr un champ de bits suffit pour dire indiquer dans une tuile vectorielle les noms identiques au nom local : ça se comprime bien". Jean-Yvon Le 26/07/2015 23:28, Thierry Bézecourt - thie...@thbz.org a écrit : Le 26/07/2015 22:33, osm.sanspourr...@spamgourmet.com a écrit : Je n'ai jamais dit de ne pas garder les tags qui sont différents. name:br=Pariz, on garde ! Je dis juste que name:de=Paris (qui existe actuellement dans la base) n'a pas grand intérêt. Comme je crois l'avoir déjà dit, ton système me paraît incompatible avec une fonctionnalité utile des logiciels, à savoir la possibilité pour l'utilisateur de choisir deux ou trois langues et non pas une seule. (Cette fonctionnalité n'est peut-être guère implémentée, mais c'est une autre question.) Supposons que mes langues favorites soient, dans l'ordre, le français et l'anglais. Avec ton système, je ne verrai jamais le nom anglais (name:en) pour les villes ou rues chinoises ou japonaises, car le système, ne trouvant pas un nom français (name:fr), affichera le nom par défaut en chinois (name). Qui ne m'est guère utile... Une "solution" serait de créer un champ spécial contenant la liste des langues pour lesquelles le nom est identique au nom par défaut : name=Paris name:it=Parigi name:ko=파리 name:equals_default=fr;en;de... Mais le jeu en vaut-il la chandelle ? La situation actuelle ne pose pas vraiment de difficulté. Thierry ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tuiles vectorielles et internationales
Tu l'as effectivement dit mais ce n'est simplement pas vrai. Si le nom en anglais existe, name:en sera renseigné. Ton logiciel pourra en tirer partie o(u pas). Tu connais beaucoup de villes en Chine dont la version en anglais est la même qu'en Chinois ? Si tel est le cas alors ton rendu "fr sinon en sinon zh" rendra en qui sera égal à zh, le mien rendra zh c'est à dire... la même chose. J'ai aussi précisé que si ça peut être utile on peut ajouter mais à part (dans le sens moins visible car moins pertinent) les données. Ton name:equals_default=, c'est ce que je dis dans "Bien-sûr un champ de bits suffit pour dire indiquer dans une tuile vectorielle les noms identiques au nom local : ça se comprime bien". Jean-Yvon Le 26/07/2015 23:28, Thierry Bézecourt - thie...@thbz.org a écrit : Le 26/07/2015 22:33, osm.sanspourr...@spamgourmet.com a écrit : Je n'ai jamais dit de ne pas garder les tags qui sont différents. name:br=Pariz, on garde ! Je dis juste que name:de=Paris (qui existe actuellement dans la base) n'a pas grand intérêt. Comme je crois l'avoir déjà dit, ton système me paraît incompatible avec une fonctionnalité utile des logiciels, à savoir la possibilité pour l'utilisateur de choisir deux ou trois langues et non pas une seule. (Cette fonctionnalité n'est peut-être guère implémentée, mais c'est une autre question.) Supposons que mes langues favorites soient, dans l'ordre, le français et l'anglais. Avec ton système, je ne verrai jamais le nom anglais (name:en) pour les villes ou rues chinoises ou japonaises, car le système, ne trouvant pas un nom français (name:fr), affichera le nom par défaut en chinois (name). Qui ne m'est guère utile... Une "solution" serait de créer un champ spécial contenant la liste des langues pour lesquelles le nom est identique au nom par défaut : name=Paris name:it=Parigi name:ko=파리 name:equals_default=fr;en;de... Mais le jeu en vaut-il la chandelle ? La situation actuelle ne pose pas vraiment de difficulté. Thierry ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tuiles vectorielles et internationales
Le 26/07/2015 22:33, osm.sanspourr...@spamgourmet.com a écrit : Je n'ai jamais dit de ne pas garder les tags qui sont différents. name:br=Pariz, on garde ! Je dis juste que name:de=Paris (qui existe actuellement dans la base) n'a pas grand intérêt. Comme je crois l'avoir déjà dit, ton système me paraît incompatible avec une fonctionnalité utile des logiciels, à savoir la possibilité pour l'utilisateur de choisir deux ou trois langues et non pas une seule. (Cette fonctionnalité n'est peut-être guère implémentée, mais c'est une autre question.) Supposons que mes langues favorites soient, dans l'ordre, le français et l'anglais. Avec ton système, je ne verrai jamais le nom anglais (name:en) pour les villes ou rues chinoises ou japonaises, car le système, ne trouvant pas un nom français (name:fr), affichera le nom par défaut en chinois (name). Qui ne m'est guère utile... Une "solution" serait de créer un champ spécial contenant la liste des langues pour lesquelles le nom est identique au nom par défaut : name=Paris name:it=Parigi name:ko=파리 name:equals_default=fr;en;de... Mais le jeu en vaut-il la chandelle ? La situation actuelle ne pose pas vraiment de difficulté. Thierry ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tuiles vectorielles et internationales
OK pour que osm.org ne soit pas LE point d'entrée. Mais on pourrait aussi faciliter le passage d'un site à l'autre. Même le codage de la position et du niveau de zoom diffèrent maintenant entre les différents sites (&zoom=&lat=&lon= ou #map=//). J'aimerais passer facilement d'un site à l'autre pour prendre le meilleur de chaque. Operator (sur FireFox), c'est bien, mais il faut un microformat et je suis sans doute le seul sur la liste à l'utiliser (et pourtant c'est un public globalement avisé). Le web sémantique a encore du pain sur la planche ! Là dès que tu passes sur openseamap par exemple, tu dois te recoltiner les transformations en &lat=... (bon, je devrais proposer la modif à openseamap pour favoriser le passage de l'un à l'autre). > 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. C'est le fait d'avoir ajouté le calcul d'itinéraire qui a éclairé les initiatives autour plus qu'il ne les a entravées. Maintenant je n'hésite pas à donner une url pointant sur la page directions. On peut penser à suggérer des sites en fonction du niveau de zoom. Les gens regardent du côté de Lorient ? Allez, on propose le site du calcul d'itinéraire avec handicap qui marche bien sur Lorient. Près de la côte ? Allez, www.openseamap.org. Ta liste de courses pour osm.fr me plait. Le 26/07/2015 18:47, Christian Quest - cqu...@openstreetmap.fr a écrit : 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. Je n'ai jamais dit de ne pas garder les tags qui sont différents. name:br=Pariz, on garde ! Je dis juste que name:de=Paris (qui existe actuellement dans la base) n'a pas grand intérêt. S'il y a plusieurs langues locales, soit il y en a une prédominante (par zone), soit il n'y en a pas. Le name reflète la situation de terrain. Donc éventuellement plusieurs langues. name=Rennes mais name:br=Roazhon 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... name=Paris me dit que Paris sera toujours Paris sauf si explicitement dit autrement. 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. Là le problème c'est plus que c'est effectivement le même. > /- 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. oui et non : les contours ne changent pas beaucoup. Allez, faisons des geohash des zones, déjà dans la plupart des zones tu auras une seule langue (ou une liste pour les zones comme la Suisse). 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é. Mettre un name= dans la langue qui n'est pas la langue locale c'est une faute de goût. name:en= si la personne récupère le nom en anglais est ce qu'il faut faire. Je n'ai rien contre les name:*, je parlais juste des name:*= qui sont identiques au name= J'aurais plus tendance à écrire une méta donnée disant que le nom de Paris c'est Paris en allemand, papou, etc... En général ce sont les noms différents qui nous intéressent, seul le contributeur en papou veut savoir que le nom de Paris est bien renseigné en papou. Je dis papou, histoire de rappeler qu'il n'y a pas que le français, l'anglais et l'allemand et que si chacun fait ça, ça va faire beaucoup. Bien-sûr un champ de bits suffit pour dire indiquer dans une tuile vectorielle les noms identiques au nom local : ça se comprime bien. Mais si on veut aller dans cette direction (qui n'est pas ce qui est indiqué dans le wiki), il faut que l'affichage des tags soit plus fin (on met par exemple les noms différents et un plus pour afficher les noms identiques au name). 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 OK, bêtement
Re: [OSM-talk-fr] tuiles vectorielles et internationales
> > > > > 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 ? ;-) > > On pourrait dire que le alt_name remplace officiellement le name d'où le fait que Nominatim renvoi des résultats. On a l'exemple de la métropole de Montpellier qui est :"Montpellier Méditerranée Métropole" et en nom alternatif "Montpellier 3M" en nom local "l'agglo de Montpel" Le cas que tu cites est un loc_name. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tuiles vectorielles et internationales
Le 26/07/2015 15:44, osm.sanspourr...@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: 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
Re: [OSM-talk-fr] tuiles vectorielles et internationales
à rapprocher de :
http://wiki.openstreetmap.org/wiki/Proposed_features/Language_of_this_element
sauf que je pense utiliser l'inclusion pour avoir des valeurs par défaut.
Jean-Yvon
Le 26/07/2015 15:44, osm.sanspourr...@spamgourmet.com a écrit :
> /- 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.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] tuiles vectorielles et internationales
> 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: 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 Nürnberg
name:de
Nürnberg
name:en
Nuremberg
name: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.
