<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Le 16/05/2016 17:59, Philippe Verdy a
      écrit :<br>
    </div>
    <blockquote
cite="mid:CAGa7JC1XmrBKoc49ND5fMb9b7JpRq13RJrUjnT-KBCkVkqNa7g@mail.gmail.com"
      type="cite">
      <div dir="ltr">personnelmement je trouve que la façon dont est
        géré le paramètre bounding box est plutôt mal fichu: globalement
        ça fait deux sélections d'objets puis une intersection, mais sur
        une bounding box très grande c'est ridicule car une des listes
        d'objets est beaucoup trop volumineuse.
        <div><br>
        </div>
        <div>Au delà d'une certaines surface (à déterminer, laquelle
          peut aussi s'appuyer sur des données statistiques partiellles
          précalculées sur la densité d'un certain nombre de
          "quad-tiles" pour estimer le nombre d'objets ou juste de
          noeuds inclus dans la bounding box), il ne faudrait pas
          procéder par fusion de deux listes mais par récursion en
          filtrant directement la première liste obtenue par la
          sélection des autres tags.</div>
        <div><br>
        </div>
        <div>Il manque à OverPass ce qui est fait dans les bases de
          données relationnelles : un optimiseur statistique de requêtes
          pour estimer la sélectivité et calculer ce qu'on appelle un
          "plan d'exécution" adéquat.</div>
        <div><br>
        </div>
        <div>Les optimiseurs statistiques de bases relationnelles ne
          font pas que ça, ils estiment aussi la sélectivité des index
          quand on a le choix pour une table, et savoir s'il est
          nécessaire de faire une jointure entre l'index et la table
          pour trouver les autres colonnes nécessaires aux filtres
          (clauses WHERE, GROUP BY/aggrégats) puis au tri final (ORDER
          BY: faut-il créer un index temporaire contenant les clés de
          tri, ou une table temporaire contenant aussi les colonnes de
          résultat), il estiment aussi le volume en I/O (tailles moyenne
          des rangées de données).</div>
        <div><br>
        </div>
        <div>[ De tels optimiseurs sont très compliqués à écrire, les
          règles sont d'autant plus complexes que cela dépend aussi de
          la représentation interne des tables et index, de leur codage
          en terme de compression, etc : il faut de bons estimateurs, et
          parfois aussi maintenir des données statistiques de
          sélectivité (ce qui nécessite un petit peu de stockage en plus
          pour chaque index). Certains moteurs SQL tiennent compte aussi
          de l'usage fait et gèrent des caches statistiques pour
          s'adapter à la demande (ce n'est pas parce qu'un index existe
          qu'il est souvent utilisé, certaines mises à jour d'index
          peuvent être retardées pour aller plus vite sur les mises à
          jour de tables ou d'autres index). ]</div>
        <div><br>
        </div>
        <div>En absence de tel optimiseur statistique (au moins minimal
          sans aller jusqu'à l'estimation exacte des I/O, car les
          données élémentaires manipulées ont des tailles très peu
          variables, hormi le nombre de noeuds dans un chemin), OverPass
          devrait uniquement s'appuyer sur la façon dont on écrit la
          requête pour savoir si on fait des intersections de listes ou
          des récursions par filtre et pour ordonner les filtres
          (l'utilisateur écrivant la requête ayant alors une meilleure
          connaissance de la sélectivité des différents filtres.</div>
        <div><br>
        </div>
        <div>Un bon optimiseur pour OverPass en revanche devrait
          s'appuyer directement sur les "quadtiles", en précédant par
          division successive de l'espace rectangulaire de la sélection
          pour déterminer s'il faut procéder dans chaque quadtile par
          fusion de listes ou par récursion sur les quadtiles de niveau
          inférieur et filtrage à ce niveau. Cependant cela demanderait
          aussi d'intégrer une partie de ce traitement directement sur
          la base SQL d'objets OSM (ou sa copie locale), cela
          demanderait une modification du schéma physique (surtout
          concernant les relations et chemins qu devraient intégrer leur
          propre "bounding box" précalculée sans nécessiter une
          récursion; sinon gérer un cache de "bounding box", pour chaque
          chemin ou relation).</div>
        <div><br>
        </div>
        <div>Actuellement Overpass ne gère qu'un seul cache précalculé :
          les "areas" (qui ont le défaut d'être souvent désynchronisés
          car ça dépend d'un bot de mise à jour qui peut parfois avoir
          plusieurs jours de décalage avec les données réelles, il n'y a
          pas de calcul à la demande avec des caches ayant des durées
          d'expiration raisonnables, et le bot fait en fait trop de
          travail pour rien sur des areas que personne ou presque
          n'utilise dans des requêtes). Mais ça ne répond pas
          correctement aux besoins. Ces "areas" d'OverPass sont plus
          souvent une gêne qu'elles ne sont utiles, leur coût en terme
          de charge des serveurs Overpass est disproportionné : ces
          "areas" précalculées devraient être abandonnées pour utiliser
          à la place une génération "à la demande" (avec un cache
          raisonnable d'au moins quelques heures afin de prévenir les
          surcharges serveur du fait de requêtes répétées sur des
          géométries complexes comme les frontières de pays, ou de
          grandes régions, ou d'Etats d'une fédération).</div>
        <div><br>
        </div>
        <div>Il faut bien voir que la façon dont les données OSM sont
          stockées "en vrac" dans une base SQL ne leur permet pas
          d'utiliser les filtres classiques SQL permettant à
          l'optimiseru statistique de fonctionner (les différents "tags"
          d'OSM" ne sont pas des colonnes séparées en SQL), et en fait
          les jointures sont faites à l'aide de tables temporaires
          construites par OverPass, dans l'ordre qu'il détermine
          lui-même (un ordre qui est un peu trop fait "à l'arrache").</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
    Bonjour,<br>
    <br>
    Pour ma part je pense qu'une base NoSQL sur une architecture
    distribuée serait une solution plus perenne, plus performante et
    avec moins de contraintes de schéma préétabli que les bases SQL.<br>
    <br>
    Bruno.<br>
    <br>
    <blockquote
cite="mid:CAGa7JC1XmrBKoc49ND5fMb9b7JpRq13RJrUjnT-KBCkVkqNa7g@mail.gmail.com"
      type="cite">
      <div class="gmail_extra"><br>
        <div class="gmail_quote">Le 16 mai 2016 à 16:13, Christian Quest
          <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:cquest@openstreetmap.fr" target="_blank">cquest@openstreetmap.fr</a>></span>
          a écrit :<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div dir="ltr">
              <div>
                <div>
                  <div>Sur un très grand BBOX un timeout de 60 est très
                    très insuffisant.<br>
                    <br>
                  </div>
                  Deux solutions:<br>
                </div>
                - l'augmenter (beaucoup)<br>
              </div>
              - ne pas mettre de BBOX... dans ce cas overpass ne
              cherchera que via les tags et sur un type d'objet aussi
              peu fré"quent que les centrales nucléaires ça sera
              beaucoup plus rapide (testé, ça prend 20s)<span class=""><br>
                <br>
                <br>
                [out:json][timeout:60];<br>
                (<br>
                  // query part for: “"generator:source"=nuclear”<br>
              </span>  node["generator:source"="nuclear"];<br>
                way["generator:source"="nuclear"];<br>
                relation["generator:source"="nuclear"];<br>
              );<br>
              out center;<br>
              <br>
              <br>
              <br>
            </div>
            <div class="gmail_extra">
              <div>
                <div class="h5"><br>
                  <div class="gmail_quote">2016-05-16 14:55 GMT+02:00
                    Shohreh <span dir="ltr"><<a
                        moz-do-not-send="true"
                        href="mailto:codecomplete@free.fr"
                        target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:codecomplete@free.fr">codecomplete@free.fr</a></a>></span>:<br>
                    <blockquote class="gmail_quote" style="margin:0 0 0
                      .8ex;border-left:1px #ccc solid;padding-left:1ex">Bonjour<br>
                      <br>
                      Je voulais récupérer la liste des centrales
                      nucléaires en Europe et les<br>
                      importer dans une carte Umap, mais OT fait un
                      time-out:<br>
                      <br>
                      ============<br>
                      [out:json][timeout:60];<br>
                      (<br>
                        // query part for: “"generator:source"=nuclear”<br>
                        node["generator:source"="nuclear"]({{bbox}});<br>
                        way["generator:source"="nuclear"]({{bbox}});<br>
                       
                      relation["generator:source"="nuclear"]({{bbox}});<br>
                      );<br>
                      out body;<br>
                      >;<br>
                      out skel qt;<br>
                      <br>
                      ============<br>
                      <br>
                      An error occured during the execution of the
                      overpass query! This is what<br>
                      overpass API returned:<br>
                      runtime error: Query timed out in "query" at line
                      12 after 61 seconds.<br>
                      <br>
                      ============<br>
                      <br>
                      Y a-t-il une autre solution?<br>
                      <br>
                      Merci.<br>
                      <br>
                      <br>
                      <br>
                      --<br>
                      View this message in context: <a
                        moz-do-not-send="true"
href="http://gis.19327.n5.nabble.com/Timeout-avec-OverpassT-alternative-tp5873617.html"
                        rel="noreferrer" target="_blank"><a class="moz-txt-link-freetext" href="http://gis.19327.n5.nabble.com/Timeout-avec-OverpassT-alternative-tp5873617.html">http://gis.19327.n5.nabble.com/Timeout-avec-OverpassT-alternative-tp5873617.html</a></a><br>
                      Sent from the France mailing list archive at
                      Nabble.com.<br>
                      <br>
                      _______________________________________________<br>
                      Talk-fr mailing list<br>
                      <a moz-do-not-send="true"
                        href="mailto:Talk-fr@openstreetmap.org"
                        target="_blank">Talk-fr@openstreetmap.org</a><br>
                      <a moz-do-not-send="true"
                        href="https://lists.openstreetmap.org/listinfo/talk-fr"
                        rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-fr</a><br>
                    </blockquote>
                  </div>
                  <br>
                  <br clear="all">
                  <br>
                </div>
              </div>
              <span class="HOEnZb"><font color="#888888">-- <br>
                  <div>
                    <div dir="ltr">Christian Quest - OpenStreetMap
                      France</div>
                  </div>
                </font></span></div>
            <br>
            _______________________________________________<br>
            Talk-fr mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
            <a moz-do-not-send="true"
              href="https://lists.openstreetmap.org/listinfo/talk-fr"
              rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-fr</a><br>
            <br>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Talk-fr mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-fr">https://lists.openstreetmap.org/listinfo/talk-fr</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>