J'ai un peu de mal à appréhender cette API, comme par exemple cette syntaxe :
area [name="France"][admin_level="2"]->.zone; je pensais qu'à ce niveau là, je ne remontais pas une quantité phénoménale de données mais juste le polygone d'emprise. Quant à area je ne trouve pas spécialement de doc ici, et je suis preneur si plus d'infos : http://wiki.openstreetmap.org/wiki/Overpass_API/Language_Guide Sinon, effectivement si je priorise la requête : node["name"~"^Toulouse"](area.zone); mais comment lui dire ensuite d'appliquer un filtre area Michel Le 14 mai 2014 04:46, Philippe Verdy <verd...@wanadoo.fr> a écrit : > 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 > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
