Je pense plutôt que c'est le premier filtre de la seconde requête (node(zone)à qui n'est pas assez sélectif. La "zone" (le polygone de la France adminstrative de niveaus 2) est gigantesque et contient des millions de noeuds.
La première requête (vers la variable "zone" est relativelent sélective car elle recherche des polygones ayant deux attributs très sélectifs (name=France déjà, affiné par admin_level=2 pour les homonymes peu nombreux): à priori zone ne contient qu'un polygone (assez complexe malgré tout avec quelques milliers de sommets essentiellement sur les frontières terrestres, car en mer les limites des eaux territoriales ne sont pas très compliquées, mais son on choisissait la limite côtière alors là ce sont près de 200 000 noeuds, peut-etre plus maintenant avec les cotes de plus en plus affinées et les ilots). Il vaut mieux faire des requêtes en commençant par le filtre le plus sélectif; celui sur le name élimine quasiment tout, et ne crée donc pas une table temporaire énorme, le filtre sur la zone France est à appliquer après sur ce qui reste (s'il reste quelquechose). Overpass n'a toujours pas d'optimiseur statistique des plans d'exécutions qu'il crée en interne (il ne sait pas évaluer la sélectivité des requêtes: même s'il y a des index primaires utilisables, ça peut être encore inefficace si la sélectivité de la requête est faible, et c'est pire si cela doit passer par des index secondaires n'incluant pas d'autres données nécessaires sur des éléments non sélectifs) et en stockant des tonne de données temporaires. Assez vite il tombe sur les limites de quota (en volume, ou encore plus en nombre d'I/O qui sollicite beaucoup les disques avec des caches peu efficaces, et en fin de compte aboutissant à dépasser le quota de temps d'exécution mais avec cette requête-là on doit tomber sur tous ces quotas en même temps, mais impossible ici de dire lequel tombe en premier). De fait on doit penser à une optimisation manuelle de ses requêtes en évaluant soi-même quelles quantités de données sont séletionnées à chaqué étape. Donc ici il suffit d'inverser les deux requêtes : filtrer d'abord sur les noeuds ayant ce nom puis sélectionner les points restants dans la zone retenue. La solution sera inversée si la zone est assez petite (ne dépasse pas la limite raisonnable de taille d'une zone restangulaire de téléchargement de JOSM par exemple ; toute la France c'est beaucoup trop gros si on n'a pas déjà effectué une première sélection très sélective). Le 13 mai 2014 21:46, Christian Quest <cqu...@openstreetmap.fr> a écrit : > Je pense que c'est la premier area qui cause un dépassement côté > serveur... et pas que le serveur t'a envoyé 513MB de data ;) > Sur une plus petite zone (Monaco) ça répond bien qu'il n'a rien trouvé. > > > Le 13 mai 2014 20:55, Mides <mides....@gmail.com> a écrit : > >> Bonsoir, >> >> À cette requête, pour test, sensée trouver toutes les tags name débutants >> par cette chaine, "trzetgsqgdfgqsdaze " cette réponse m’est retournée, et >> pourtant je ne pense pas qu’il y ait beaucoup de tags name où l'on trouve >> ce mot. >> >> Assez étonnant comme résultat. >> >> *Requête :* >> >> area [name="France"][admin_level="2"]->.zone; >> ( >> node(area.zone) >> ["name"~"^trzetgsqgdfgqsdaze "]; >> ); >> out skel; >> >> *Réponse : * >> >> Une erreur est survenue lors de l'exécution de la requête overpass ! >> Voici ce que l'API overpass a retourné : >> runtime error: Query run out of memory in "query" at line 4 using about >> 513 MB of RAM. >> >> Michel >> >> _______________________________________________ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> >> > > > -- > Christian Quest - OpenStreetMap France > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
