<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Le 28/09/2020 à 11:02, Axel Listes a
      écrit :<br>
    </div>
    <blockquote type="cite"
      cite="mid:24686a52-d3fa-db60-71a6-14abff6b3369@broman.fr">
      <pre class="moz-quote-pre" wrap="">Bonjour,

Le 28/09/2020 à 09:40, Éric Gillet a écrit :
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre class="moz-quote-pre" wrap="">Donc, dans le schéma d'origine que je découvre, il faudrait trois
</pre>
          </blockquote>
          <pre class="moz-quote-pre" wrap="">relations.

Mais les éditeurs facilitent la création de telles relations.
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">
Exactement ça me semble être une question d'éditeurs plus qu'une
question de tags/objets OSM.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Alors voici globalement les « défauts » qui en découlent :
- Les multiples césures des chemins, il faut les couper à l'emplacement
du point « via » de la relation.</pre>
    </blockquote>
    <p>Dans la plupart des cas l'intersection sera composée de 2 voies
      de la manière suivante : -|-, donc ça fait 2 coupures au maximum.
      J'ai l'impression que les intersections plus complexes avec + de
      voies (donc plus dangereuses) n'ont pas de cédez-le-passage
      tout-droit ou à gauche.
    </p>
    <blockquote type="cite"
      cite="mid:24686a52-d3fa-db60-71a6-14abff6b3369@broman.fr">
      <pre class="moz-quote-pre" wrap="">- La maintenance, comme toutes relations, celles-ci sont susceptibles
d’être cassées lorsque qu'un contributeur débutant ou non vigilant
intervient sur l'un des éléments intégrés dans la relation.</pre>
    </blockquote>
    <p>Oui en effet, mais ça malheureusement il n'y a pas de solution.
      Même avec une myriade d'avertissement des contributeurs arrivent
      régulièrement à fusionner des nœuds de routes 1km plus loin sur
      iD. Pourtant ce sont des opérations simple (fusion de nœuds) sur
      des "données simples" (nœuds, pas de relation), donc je ne suis
      pas sûr que ce soit un problème de complexité du modèle de
      données. </p>
    <p>Si l'éditeur a une vue dédiée aux cédez-le-passage, il serait
      sûrement  facile de mettre cette vue lors d'erreurs de validation
      pour faire corriger le contributeur.<br>
    </p>
    <blockquote type="cite"
      cite="mid:24686a52-d3fa-db60-71a6-14abff6b3369@broman.fr">
      <pre class="moz-quote-pre" wrap="">Les systèmes
de suivi d’éditions ont plus de difficultés à donner des informations
concernant des éditions de relations que de points (Achavi, OSMcha ...)</pre>
    </blockquote>
    Oui en effet. Je pense que c'est l’œuf et la poule, il y a beaucoup
    plus de modifications (et donc d'erreurs à surveiller) sur les nœuds
    et voies, donc plus d'attention est portée à leur rendu.
    <blockquote type="cite"
      cite="mid:24686a52-d3fa-db60-71a6-14abff6b3369@broman.fr">
      <pre class="moz-quote-pre" wrap="">- La complexité de l'usage des relations, honnêtement pourquoi
obligatoirement passer par un système hyper complexe alors que l'on peut
juste ajouter une balise sur un point pour arriver au même résultat ?
L'exemple d'Éric est intéressant, car il permet de se poser cette
question : Une balise sur un point déjà existant ou trois relations ?</pre>
    </blockquote>
    <p>C'est plus complexe qu'un seul tag sur un seul nœud, de là à dire
      "hyper-complexe" pas sûr. Le monde est complexe, pas tout n'est
      forcément cartographiable facilement. Par exemple on pourrait dire
      qu'il serait plus simple de cartographier les arbres de la manière
      suivante :</p>
    <p>natural=tree<br>
      espece=platane</p>
    <p>Au lieu de :</p>
    <p>natural=tree<br>
      genus=Platanus<br>
      species=Platanus × hispanica<br>
      deciduous=leaf_cycle<br>
      leaf_type=broadleaved</p>
    <p>Mais ça me semble pas pertinent pour une base de données.<br>
    </p>
    <p>Pour revenir sur les panneaux, il faut se demander ce que l'on
      veut cartographier : le panneau (ce que tu suggères si j'ai bien
      compris) ou son effet.</p>
    <p>Panneau :</p>
    <ul>
      <li>Plus simple à cartographier</li>
      <li>Ne représente que le panneau, et nécessite donc une
        interprétation pour savoir quelle voie sont concernées. Cette
        interprétation est potentiellement différente par pays/état.<br>
      </li>
    </ul>
    <p>Relations:</p>
    <ul>
      <li>Plus complexe à cartographier</li>
      <li>Pas d'ambiguïté pour les utilisateurs<br>
      </li>
    </ul>
    <p>Certains pourraient suggérer une approche hybride (panneau quand
      pas d'ambiguïté, relation quand ambiguïté possible), mais ça veut
      dire implémenter logiciellement (et faire comprendre aux
      contributeurs) les deux manières de cartographier, ce qui me
      semble empirer le problème.<br>
    </p>
  </body>
</html>