<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="transparent">
    <p>Le 03/10/2019 à 14:24, Brice MALLET - <a class="moz-txt-link-abbreviated" href="mailto:bricemel@free.fr">bricemel@free.fr</a> a écrit :<br>
    </p>
    <blockquote type="cite"
      cite="mid:849843fb-6720-f8b4-0a17-cc9f3b3c3a6b@free.fr">Merci pour
      le travail réalisé / encore à réaliser.
    </blockquote>
    +1
    <p>> Il reste à y (re)brancher les lieux-dits</p>
    <p>Du coup avec l'interface JOSM j'ai vu qu'un lieu-dit c'était plus
      qu'un <tt>place=unknown</tt>.</p>
    <p>C'est aussi dans certains cas un périmètre.</p>
    <p>Est-ce que ça ne vaut pas le coup de tenter de faciliter leur
      intégration ?<br>
    </p>
    <p>Une intégration "brute" avec le greffon JOSM pose problème car
      les polygones sont jointifs et on abouti naturellement à des
      chemins dupliqués.</p>
    <p>Il faut donc comme pour les communes découper en segments et
      créer une relation <tt>type=boundary</tt>, <tt>boundary=place</tt>,
      <tt>place=</tt>,
      <tt> name=</tt> avec <br>
    </p>
    <ul>
      <li>en membres <tt>outer</tt> le contour découpé en segments</li>
    </ul>
    <p> Contours éventuellement sans attributs ?<br>
      Avec <tt>name:left</tt> et <tt>name:right</tt>? Ce serait
      incompatible avec des rues jouant le rôle de limite (qui ont
      souvent le même nom des deux côtés).<br>
      Avec le niveau le plus haut de place des deux <tt>place</tt> ? et
      <tt>boundary=place</tt> ? Ce serait homogène avec les <tt>boundary=administrative</tt>.
      Mais comme le nom peut être celui d'une rue et non d'un <tt>boundary</tt><tt>=place</tt>,
      ce serait peut-être déroutant.<br>
    </p>
    <ul>
      <li>en membre <tt>label</tt> le "centre" avec lui aussi les
        attributs name= et place=. C'est homogène avec les <tt>boundary=administrative</tt>.
        Note : il y a des propositions de changer <tt>label</tt> en <tt>waypoint</tt>
        ou <tt>reference_point</tt> car c'est endroit où l'on va par
        défaut quand on nous dit d'aller dans ce lieu sans plus de
        précision.<br>
      </li>
    </ul>
    <p>Christian va me dire que <tt>name=</tt> et <tt>place=</tt> ne
      sont pas nécessaires sur le nœud.<br>
      D'un point de vue théorique je suis d'accord.<br>
      D'un point de vue pratique sans cela, le style par défaut de la
      fondation n'affiche rien et il est classique que les utilisateurs
      de données s'attendent à n'avoir qu'un point prêt à l'emploi. Sur
      les <tt>admin_centre</tt> des <tt>boundary=administrative</tt>
      il y a aussi duplication des infos de la relation.<br>
    </p>
    <p>Exemples contigus :<a moz-do-not-send="true"
href="https://www.openstreetmap.org/relation/10110420#map=19/47.78696/-3.48731"><br>
https://www.openstreetmap.org/relation/10060749#map=19/47.78701/-3.48695<br>
https://www.openstreetmap.org/relation/10110420#map=19/47.78696/-3.48731</a><br>
    </p>
    <p>A priori en créant des points et en créant des segments on peut
      faire un <a moz-do-not-send="true"
        href="https://gdal.org/drivers/vector/csv.html">CSV</a> à
      transformer en pilote virtuel vrt que l'on peut exporter à son
      tour en GeoJSON.</p>
    <p><a moz-do-not-send="true"
        href="https://github.com/topojson/topojson">https://github.com/topojson/topojson</a>
      permet de transformer du GeoJSON en TopoJSON.<br>
    </p>
    <p>Dit comme ça, ça semble simple, il y a quand même un peu de
      topologie à faire, peut-être qu'une bibliothèque QGIS, python ou
      une requête PostGIS permet de partir des données récupérées par le
      greffon cadastre (les fichiers edigeo-<insee><feuille
      cadastrale>.tar.bz2), je suppose que Vincent et/ou Christian
      sauront éclairer notre lanterne.</p>
    <p>En extrayant en même temps routes et lieux-dits on doit arriver à
      éviter les doublons et à créer des segments (dans mon exemple j'ai
      dû saucissonner la rue Général De Gaulle, ça aurait pu être fait
      automatiquement par topologie.<br>
    </p>
    <p>Pour la <a moz-do-not-send="true"
href="https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/place_areas#KISS_%3A_reuse_an_existing_model_boundary.3Dplace">petite
        histoire</a> cette modélisation résout le problème d'affichage
      des places en surfacique signalé sur le style principal.<br>
    </p>
    <p>Jean-Yvon<br>
    </p>
  </body>
</html>