<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Le 08/07/2020 à 17:42, Florian LAINEZ a
      écrit :<br>
    </div>
    <blockquote type="cite"
cite="mid:CALZSDKJKa+Rz-wMzz_hBbmPAXNrFBtfiPWNoseA4v8ZFAge1jA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <p>Merci pour la prise de recul qui me paraît également
          nécessaire Christian.<br>
          J'ai tout comme toi un problème avec l'info dupliquée qui pose
          indubitablement problème. Dans un monde idéal, l'adresse
          n'apparaîtrait qu'une fois et qu'une seule. Malheureusement le
          seul moyen d'y parvenir me semble être de créer des relations,
          ce qui complique vraiment le modèle et que l'on devrait donc
          éviter dans la mesure du possible.</p>
        <p>On est d'accord que pour l'usage "adresse", le point tel
          qu'il est défini et utilisé aujourd'hui fait le taff. Ce que
          nous essayons maintenant de trouver, c'est donc le moyen de
          gérer au mieux l'utilisation "contact".</p>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
          0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Pourquoi
          dupliquerai-t-on l'adresse sur chaque entrée/accès et pas le
          type de POI (c'est une entrée... de cinéma, un sortie de
          secours... de cinéma, etc) ? Où est la cohérence globale ?
          Pourquoi répéter l'un mais pas l'autre ?</blockquote>
        <div>C'est un bon point. J'ai toujours été embêté par ces
          entrées qui ne sont pas reliées au bâtiment et il me
          paraissait que l'adresse soit un moyen élégant d'y parvenir
          mais tu as raison, je dois faire fausse route en associant les
          deux problématiques. Tant pis pour les pompiers qui ne seront
          pas guidés vers l'issue de secours</div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>Un noeud entrance=* se situe sur le polygone du building=*... tu
      oublies qu'OSM c'est de la donnée géo ?</p>
    <p>L'abus de relation vient souvent du manque d'exploitable
      géographique des données OSM. Les multipolygones qui entourent une
      commune (relations par commodité pour segmenter les boundary et
      non par besoin sémantique), font qu'on ne met plus de is_in=*
      partout depuis un bon bout de temps ;)<br>
    </p>
    <p>C'est quand on ne peut plus résoudre sans ambiguïté un lien entre
      deux par la géographie qu'on passe à la relation où qu'on ajoute
      des tags pour lever l'ambiguïté (par exemple les forward/backward
      sur les stop).<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CALZSDKJKa+Rz-wMzz_hBbmPAXNrFBtfiPWNoseA4v8ZFAge1jA@mail.gmail.com">
      <div dir="ltr">
        <div>On en revient donc à l'usage "contact". Dans le use case
          que j'ai exposé, il s'agit d'exporter tous les cinémas de
          France accompagnés de leur adresse sur <a
href="https://www.data.gouv.fr/fr/datasets/cinemas-issus-dopenstreetmap/"
            moz-do-not-send="true">data.gouv</a></div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <p>Je sent qu'on va créer une nouvelle règle... "ne pas taguer pour
      faciliter un export" ;)<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CALZSDKJKa+Rz-wMzz_hBbmPAXNrFBtfiPWNoseA4v8ZFAge1jA@mail.gmail.com">
      <div dir="ltr">
        <div><b>On a 3 solutions :</b></div>
        <div><b>1. </b>on considère que l'adresse ne doit pas être
          dupliquée : on la laisse donc sur un node flottant</div>
        <div>C'est plus avantageux pour la maintenance, c'est parfait
          pour l'usage "adresse" mais c'est un cauchemar pour l'export
          et l'usage "contact".</div>
        <div>Quel node avec la bonne adresse associer au POI ? C'est
          très difficile de retrouver cette info non explicite.</div>
        <div><br>
        </div>
        <div><b>2. </b>on utilise <font face="monospace">contact:XXX</font>
          pour dupliquer l'adresse sur le POI.</div>
        <div>Pas top pour la maintenance, incompatible avec les outils
          d'édition internationaux mais l'utilisation est très claire
          car les tags sont différents pour les 2 usages. Parfait pour
          les 2 usages donc.</div>
        <div>C'est la solution que nous avons choisi à Montrouge pour
          l'instant.</div>
        <div><br>
        </div>
        <div><b>3. </b>on duplique l'adresse du point sur le POI en lui
          rajoutant <span style="font-family:monospace">addr:role=contact</span></div>
        <div>Pas top pour la maintenance, compatible avec les outils
          d'édition internationaux, bien adapté pour tous les lieux où
          il n'existe aucun point adresse (ce qui représente la majorité
          des cas pour les cinémas), mais il est nécessaire de faire une
          évolution pour l'utilisation "adresse" afin que ce nouveau tag
          soit pris en compte.</div>
        <div><br>
        </div>
        <div>Cette dernière option a ma préférence, qu'en pensez-vous ?</div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>J'ai regardé le fichier CNC, je ne vois pas d'adresse dedans.
      Comment ont-elles été ajoutées dans OSM ?</p>
    <p>A-t-on 100% des adresses correspondantes aux cinémas déjà dans
      OSM ? (Et correctement mappées en tant que telles ?)</p>
    <p>J'ai regardé celui près de chez moi, aucune info d'adresse
      dessus, quelle adresse aura-t-il dans l'export ? La plus proche
      qu'on trouve (donc un simple géocodage inverse) ?</p>
    <p>Je ne comprends pas trop le processus...</p>
    <p><br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Christian Quest - OpenStreetMap France</pre>
  </body>
</html>