Le 14/05/2014 09:04, Mides a écrit : > 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.
La France administrative de niveau 2 correspond à la France métropolitaine + DOM/TOM et autres territoires. Autant dire que si le polygone d'emprise est un simple rectangle, il couvre quasiment la terre entière ! et mieux vaut donc s'en passer. Si tu ne veut que la France métropolitaine, fait bien attention a ne prendre qu'elle : http://nominatim.openstreetmap.org/details.php?place_id=98156803 http://www.openstreetmap.org/relation/1403916 name = France métropolitaine admin_level = 3 > 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 > <mailto: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 > <mailto: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 > <mailto: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 <mailto:Talk-fr@openstreetmap.org> > https://lists.openstreetmap.org/listinfo/talk-fr > > > > > -- > Christian Quest - OpenStreetMap France > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org> > https://lists.openstreetmap.org/listinfo/talk-fr > > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org <mailto: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 > -- Christophe Merlet (RedFox) _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
