<div dir="ltr">Les clés dans les extractions vers Postgres peuvent être réduites même sans réutiliser les tags dans OSM. Les requêtes faites dans les tables de features Postgres n'ont strictement rien à voir, les modèles de données sont complètement différents.<div>

<br></div><div style>Très mauvais argument donc. C'est hors sujet et ne justifie en rien le fait d'avoir des tags clairement séparés dans OSM (même au prix d'une prétendue économie de stockage, si les tags surchargés deviennent ambigus, non seulement on complique les requêtes d'exportation, mais en plus elles commence à retourner des données qui n'ont rien à voir et ne devraient pas être importées dans Postgres.</div>

<div style><br></div><div style>Postgres n'a aucune obligation d'utiliser les mêmes "clés" OSM, il utilise des tables séparées pour chaque feature, et avec des colonnes dont les noms sont spécifiques à chaque table (le nom de la table elle-même les isole, même s'ils sont homonymes, ils peuvent donc y être simplifiés). Il n'y a PAS de clé dans Postgres dans un export GIS au même sens que dans OSM.</div>

<div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">Le 9 juin 2013 15:06, Vincent Pottier <span dir="ltr"><<a href="mailto:vpottier@gmail.com" target="_blank">vpottier@gmail.com</a>></span> a écrit :<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div class="im">
    <div>Le 09/06/2013 13:08, Philippe Verdy a
      écrit :<br>
    </div>
    </div><blockquote type="cite">
      <div dir="ltr">Le 8 juin 2013 16:05, Vincent de Château-Thierry <span dir="ltr"><<a href="mailto:vdct@laposte.net" target="_blank">vdct@laposte.net</a>></span>
        a écrit :<div class="im"><br>
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
              Et en toute logique, il faudrait si on l'applique, le
              propager aussi aux boundary=administrative, à la place
              d'admin_level.<br>
            </blockquote>
          </div>
        </div>
      </div></div>
    </blockquote>
    Tout à fait.<div class="im"><br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <div>Certainement pas (ou à la limite seulement
              dans les relations administratives (et qui ne sont QUE
              administratives et ne servent pas aussi de limites pour
              autre chose).</div>
            <div>L'ennui c'est pour les ways (fermés ou non)
              qui ont des utilisations multiples. Il se posera alors la
              question de savoir à quel autre tag présent sur ce way
              correspond ce "level" car justement le "level" n'est PAS
              orthogonal mais lié à un seul autre tag.<br>
            </div>
            <div><br>
            </div>
            <div>C'est bien pour ça qu'on a un tag nommé
              "admin_level" (lié très fortement à
              boundary=administrative pour lui apporter une
              sous-précision) et qu'on a relevé un problème
              d'interprétation quant on l'a appliqué (à tord) sur les
              frontières religieuses (qui n'ont rien de commun avec des
              frontières administratives).</div>
          </div>
        </div>
      </div>
    </blockquote></div>
    ON, je en l’occurrence, l'ai appliqué après réflexion.<br>
    On, Sly en l’occurrence, avait repéré un problème sur <a href="http://layers.osm.fr" target="_blank">layers.osm.fr</a>
    et a très bien réussi à le résoudre.<br>
    ON, toi en l’occurrence, ne semble pas avoir perçu comment Sly avait
    résolu le problème sur <a href="http://layers.osm.fr" target="_blank">layers.osm.fr</a><div class="im"><br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <div>Franchement je ne comprend pas l'utilité même
              de vouloir unifier des tags sous un même nom alors qu'ils
              ont des significations complètement diférentes et ne sont
              pas liés aux mêmes données (et clairement pas orthogonaux
              comme peuvent l'être "name", "url", "wikipedia",
              "natural", "landuse" et "boundary").</div>
          </div>
        </div>
      </div>
    </blockquote></div>
    Franchement je ne comprends pas l'utilité de multiplier les clefs
    alors qu'une bonne logique booléenne résout les problèmes.<br>
    Réemployer les mêmes clefs, ça permet de minimiser les clefs ! Ça
    permet d'alléger les tables dans postgres.<br>
    Ça permet d’utiliser la logique plutôt que le bavardage.<br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>Il faudrait réfléchir plus sérieusement.</div>
          </div>
        </div>
      </div>
    </blockquote>
    Tout à fait. Tu peux t'y mettre.<br>
    <br>
    Heureusement que d'autres ont déjà commencé ! Ce qui permet
    d'utiliser des mêmes clefs secondaires conjointement avec des clefs
    primaires différentes : produce, operator... orthogonaux ou pas.<br>
    --<br>
    FrViPofm<br>
  </div>

<br>_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">http://lists.openstreetmap.org/listinfo/talk-fr</a><br>
<br></blockquote></div><br></div>