[OSM-talk-fr] tuiles vectorielles et internationales

Dim 26 Juil 20:33:41 UTC 2015

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=<zoom>&lat=<lat>&lon=<lon> ou 
#map=<zoom>/<lat>/<lon>).
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 - cquest at 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 je pensais à un alphabet latin (mais si c'est un autre 
puisque c'est le nom international, il devrait être utilisé) et un texte 
unique (par nature), c'est vrai qun nom peut être dans un autre alphabet 
et que le nom international donne en plus le nom latinisé.

>
>> (...)
>> 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% ;)
Actuellement, mais si on suit la logique "Paris c'est bien Paris dans 
telle ou telle langue", on arrivera à 99% !

> 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.
+1
ça me semble être un bon point d'entrée : si le nom existe dans le 
wikidata, basta !

>> Question post SOTM 2015 : "Brest-même" c'est loc_name ou alt_name ? ;-)
>
> Pas compris
Alors un peu d'histoire. Brest est né en 1938 de la fusion de Brest 
(l'actuel centre-ville), Lambézellec, Saint-Pierre-Quilbignon et Saint-Marc.
Après guerre... et nous sommes toujours après-guerre ;-), les gens 
disaient qu'ils étaient de Brest, et pour savoir s'ils étaient de 
l'ancienne commune, précisaient de Brest même.
Depuis il y a eu la CUB puis BMO, maintenant Brest-Métropole 
(l'agglomération brestoise) et du coup est-ce que être de Brest-Même 
c'est être de la ville actuelle de Brest ou de la ville d'avant 38 ?

D'ailleurs quand tu es en dehors de Brest, quelqu'un ayant vécu à Brest 
de demandera malicieusement si tu es de Brest-même.
Je suis Saint-Marcois d'origine ;-).

 > nom alternatif "Montpellier 3M"
et en short_name 3M sauf que Scotch avait un copyright !
Oui Brest-Même est un loc_name.

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