<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="transparent" text="#000000">
    OK pour que osm.org ne soit pas LE point d'entrée.<br>
    Mais on pourrait aussi faciliter le passage d'un site à l'autre.<br>
    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>).<br>
    J'aimerais passer facilement d'un site à l'autre pour prendre le
    meilleur de chaque.<br>
    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 !<br>
    <br>
    Là dès que tu passes sur openseamap par exemple, tu dois te
    recoltiner les transformations en &lat=...<br>
    (bon, je devrais proposer la modif à openseamap pour favoriser le
    passage de l'un à l'autre).<br>
    <br>
    > Il y a eu de longues discussions avant d'ajouter le calcul
    d'itinéraires.<br>
    > Ce site sert surtout à montrer ce qu'on peut faire avec OSM,
    mais sans vouloir faire trop d'ombre à toutes les initiatives
    autour.<br>
    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.<br>
    Maintenant je n'hésite pas à donner une url pointant sur la page
    directions.<br>
    <br>
    On peut penser à suggérer des sites en fonction du niveau de zoom.<br>
    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.<br>
    Près de la côte ? Allez, <a class="moz-txt-link-abbreviated" href="http://www.openseamap.org">www.openseamap.org</a>.<br>
    <br>
    Ta liste de courses pour osm.fr me plait.<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Le 26/07/2015 18:47, Christian Quest -
      <a class="moz-txt-link-abbreviated" href="mailto:cquest@openstreetmap.fr">cquest@openstreetmap.fr</a> a écrit :<br>
    </div>
    <blockquote cite="mid:55B50F1D.2070905@openstreetmap.fr" type="cite">
      Si il n'y a qu'une langue locale ça marche... mais c'est pas le
      cas partout !<br>
      Belgique, Suisse, etc... sans oublier aussi les langues
      régionales.<br>
    </blockquote>
    Je n'ai jamais dit de ne pas garder les tags qui sont différents.<br>
    name:br=Pariz, on garde !<br>
    Je dis juste que <br>
    name:de=Paris (qui existe actuellement dans la base) n'a pas grand
    intérêt.<br>
    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.<br>
    Donc éventuellement plusieurs langues.<br>
    name=Rennes<br>
    mais <br>
    name:br=Roazhon<br>
    <br>
    <blockquote cite="mid:55B50F1D.2070905@openstreetmap.fr" type="cite">
      <blockquote cite="mid:55B4E444.1080500@gmx.net" type="cite"> 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>
      </blockquote>
      name=Paris ne me dit pas que Paris en allemand s'écrit aussi
      Paris...<br>
    </blockquote>
    name=Paris me dit que Paris sera toujours Paris sauf si
    explicitement dit autrement.<br>
    <br>
    <blockquote cite="mid:55B50F1D.2070905@openstreetmap.fr" type="cite">
      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.<br>
    </blockquote>
    Là le problème c'est plus que c'est effectivement le même.<br>
    <blockquote cite="mid:55B50F1D.2070905@openstreetmap.fr" type="cite">
      <br>
      <blockquote cite="mid:55B4E444.1080500@gmx.net" type="cite"> >
        <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>
      </blockquote>
      <br>
      Ouille... bonjour le préprocessing, et ce n'est pas toujours le
      cas.<br>
    </blockquote>
    oui et non : les contours ne changent pas beaucoup.<br>
    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).<br>
    <br>
    <blockquote cite="mid:55B50F1D.2070905@openstreetmap.fr" type="cite">
      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).<br>
      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é.<br>
    </blockquote>
    Mettre un name= dans la langue qui n'est pas la langue locale c'est
    une faute de goût.<br>
    name:en= si la personne récupère le nom en anglais est ce qu'il faut
    faire.<br>
    Je n'ai rien contre les name:*, je parlais juste des name:*= qui
    sont identiques au name=<br>
    J'aurais plus tendance à écrire une méta donnée disant que le nom de
    Paris c'est Paris en allemand, papou, etc...<br>
    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.<br>
    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.<br>
    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.<br>
    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).<br>
    <br>
    <blockquote cite="mid:55B50F1D.2070905@openstreetmap.fr" type="cite">
      <br>
      <blockquote cite="mid:55B4E444.1080500@gmx.net" type="cite">
        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>
      </blockquote>
      <br>
      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<br>
    </blockquote>
    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é.<br>
    <br>
    <blockquote cite="mid:55B50F1D.2070905@openstreetmap.fr" type="cite">
      <br>
      <blockquote cite="mid:55B4E444.1080500@gmx.net" type="cite"> (...)<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>
      </blockquote>
      <br>
      Donc plus proche de 6% que de 90% ;)<br>
    </blockquote>
    Actuellement, mais si on suit la logique "Paris c'est bien Paris
    dans telle ou telle langue", on arrivera à 99% !<br>
    <br>
    <blockquote cite="mid:55B50F1D.2070905@openstreetmap.fr" type="cite">
      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.<br>
    </blockquote>
    +1<br>
    ça me semble être un bon point d'entrée : si le nom existe dans le
    wikidata, basta !<br>
    <br>
    <blockquote cite="mid:55B50F1D.2070905@openstreetmap.fr" type="cite">
      <blockquote cite="mid:55B4E444.1080500@gmx.net" type="cite">
        Question post SOTM 2015 : "Brest-même" c'est loc_name ou
        alt_name ? ;-)<br>
      </blockquote>
      <br>
      Pas compris</blockquote>
    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.<br>
    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.<br>
    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 ?<br>
    <br>
    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.<br>
    Je suis Saint-Marcois d'origine ;-).<br>
    <br>
    <small>> <span
style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;line-height:18.2000007629395px">nom
        alternatif </span><span
style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;line-height:18.2000007629395px">"</span></small><span
style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;line-height:18.2000007629395px"><small>Montpellier
        3M" <br>
        et en short_name 3M sauf que Scotch avait un copyright !<br>
        Oui Brest-Même est un loc_name.</small><br>
    </span><br>
    Jean-Yvon<br>
  </body>
</html>