Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête
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
Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête
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 : _
Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête
Le 14 mai 2014 09:04, Mides mides@gmail.com 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. Ça dépend ce que tu veux dire par remonter. Si par là tu entends que tu va recevoir une grosse quantité de données, effectivement ce n'est pas le cas (exemple de Monaco). En fait, l'overpass va commencer par sélectionner tout les noeuds dans l'area... et remonter ça en RAM, sauf que là, sur la France entière... ça dépasse les 512Mo qui sont sa limite et c'est pour ça que tu as une erreur. Ca n'a rien à voir avec ce qui sera transféré au final. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête
Je pensais que l'on pouvait travailler sur une emprise du style inside_polygon. (admin_level = 2) sans pour cela remonter toutes les données existantes dans ce polygone. Je peux biaiser le problème en définissant une bbox mais ce n'est pas le top non plus (résultats en UK) node[name~^Police](42.33194,-4.79556,51.07167,8.230); Michel Le 14 mai 2014 09:55, Christian Quest cqu...@openstreetmap.fr a écrit : Le 14 mai 2014 09:04, Mides mides@gmail.com 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. Ça dépend ce que tu veux dire par remonter. Si par là tu entends que tu va recevoir une grosse quantité de données, effectivement ce n'est pas le cas (exemple de Monaco). En fait, l'overpass va commencer par sélectionner tout les noeuds dans l'area... et remonter ça en RAM, sauf que là, sur la France entière... ça dépasse les 512Mo qui sont sa limite et c'est pour ça que tu as une erreur. Ca n'a rien à voir avec ce qui sera transféré au final. -- 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
Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête
overpass n'est tout simplement pas conçu pour faire des requêtes sur des zones aussi grandes. Le 14 mai 2014 10:36, Mides mides@gmail.com a écrit : Je pensais que l'on pouvait travailler sur une emprise du style inside_polygon. (admin_level = 2) sans pour cela remonter toutes les données existantes dans ce polygone. Je peux biaiser le problème en définissant une bbox mais ce n'est pas le top non plus (résultats en UK) node[name~^Police](42.33194,-4.79556,51.07167,8.230); Michel Le 14 mai 2014 09:55, Christian Quest cqu...@openstreetmap.fr a écrit : Le 14 mai 2014 09:04, Mides mides@gmail.com 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. Ça dépend ce que tu veux dire par remonter. Si par là tu entends que tu va recevoir une grosse quantité de données, effectivement ce n'est pas le cas (exemple de Monaco). En fait, l'overpass va commencer par sélectionner tout les noeuds dans l'area... et remonter ça en RAM, sauf que là, sur la France entière... ça dépasse les 512Mo qui sont sa limite et c'est pour ça que tu as une erreur. Ca n'a rien à voir avec ce qui sera transféré au final. -- 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 -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête
Peut être effectivement que ce n'est pas conçu pour cela mais partant donc du principe que c'est le area qui pose problème, en englobant une zone trop important, je serai curieux de savoir pourquoi avec ces deux requêtes, une fonctionne très bien alors que l’autre lève une erreur. L’approche est certes différente mais le area reste identique pour les deux et le résultat renvoyé est normalement le même. area [name=France][admin_level=2]-.zone; ( node(area.zone) [name=Conseil Général]; ); out meta; //-- area [name=France][admin_level=2]-.zone; ( node(area.zone) [name~^Conseil Général$]; ); out meta; Pour info, ce problème est très récent. Michel Le 14 mai 2014 10:48, Christian Quest cqu...@openstreetmap.fr a écrit : overpass n'est tout simplement pas conçu pour faire des requêtes sur des zones aussi grandes. Le 14 mai 2014 10:36, Mides mides@gmail.com a écrit : Je pensais que l'on pouvait travailler sur une emprise du style inside_polygon. (admin_level = 2) sans pour cela remonter toutes les données existantes dans ce polygone. Je peux biaiser le problème en définissant une bbox mais ce n'est pas le top non plus (résultats en UK) node[name~^Police](42.33194,-4.79556,51.07167,8.230); Michel Le 14 mai 2014 09:55, Christian Quest cqu...@openstreetmap.fr a écrit : Le 14 mai 2014 09:04, Mides mides@gmail.com 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. Ça dépend ce que tu veux dire par remonter. Si par là tu entends que tu va recevoir une grosse quantité de données, effectivement ce n'est pas le cas (exemple de Monaco). En fait, l'overpass va commencer par sélectionner tout les noeuds dans l'area... et remonter ça en RAM, sauf que là, sur la France entière... ça dépasse les 512Mo qui sont sa limite et c'est pour ça que tu as une erreur. Ca n'a rien à voir avec ce qui sera transféré au final. -- 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 -- 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
Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête
Visiblement le regv prend toutes les données, mais pas le v normal et ça produit un dépassement de capacité. Sûrement une question d'optimisation de la requête. As-tu essayé de croiser les filtres ? A voir aussi : [maxsize:1073741824] (je parle de la requête en version xml). Le 14 mai 2014 13:49, Mides mides@gmail.com a écrit : Peut être effectivement que ce n'est pas conçu pour cela mais partant donc du principe que c'est le area qui pose problème, en englobant une zone trop important, je serai curieux de savoir pourquoi avec ces deux requêtes, une fonctionne très bien alors que l'autre lève une erreur. L'approche est certes différente mais le area reste identique pour les deux et le résultat renvoyé est normalement le même. area [name=France][admin_level=2]-.zone; ( node(area.zone) [name=Conseil Général]; ); out meta; //-- area [name=France][admin_level=2]-.zone; ( node(area.zone) [name~^Conseil Général$]; ); out meta; Pour info, ce problème est très récent. Michel Le 14 mai 2014 10:48, Christian Quest cqu...@openstreetmap.fr a écrit : overpass n'est tout simplement pas conçu pour faire des requêtes sur des zones aussi grandes. Le 14 mai 2014 10:36, Mides mides@gmail.com a écrit : Je pensais que l'on pouvait travailler sur une emprise du style inside_polygon. (admin_level = 2) sans pour cela remonter toutes les données existantes dans ce polygone. Je peux biaiser le problème en définissant une bbox mais ce n'est pas le top non plus (résultats en UK) node[name~^Police](42.33194,-4.79556,51.07167,8.230); Michel Le 14 mai 2014 09:55, Christian Quest cqu...@openstreetmap.fr a écrit : Le 14 mai 2014 09:04, Mides mides@gmail.com 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. Ça dépend ce que tu veux dire par remonter. Si par là tu entends que tu va recevoir une grosse quantité de données, effectivement ce n'est pas le cas (exemple de Monaco). En fait, l'overpass va commencer par sélectionner tout les noeuds dans l'area... et remonter ça en RAM, sauf que là, sur la France entière... ça dépasse les 512Mo qui sont sa limite et c'est pour ça que tu as une erreur. Ca n'a rien à voir avec ce qui sera transféré au final. -- 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 -- 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 -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête
A dire vrai, je vais avoir quelques difficultés à optimiser quoique ce soit. J'utilise cette syntaxe, area [name=France][admin_level= 2]-.zone; donc je comprends le fonctionnement mais je ne trouve pas de doc concernant le area, du moins ici : http://wiki.openstreetmap.org/wiki/Overpass_API/Language_Guide D'ailleurs si tu as un point de chute doc, je suis preneur. Michel Le 14 mai 2014 14:02, Marc SIBERT m...@sibert.fr a écrit : Visiblement le regv prend toutes les données, mais pas le v normal et ça produit un dépassement de capacité. Sûrement une question d'optimisation de la requête. As-tu essayé de croiser les filtres ? A voir aussi : [maxsize:1073741824] (je parle de la requête en version xml). Le 14 mai 2014 13:49, Mides mides@gmail.com a écrit : Peut être effectivement que ce n'est pas conçu pour cela mais partant donc du principe que c'est le area qui pose problème, en englobant une zone trop important, je serai curieux de savoir pourquoi avec ces deux requêtes, une fonctionne très bien alors que l’autre lève une erreur. L’approche est certes différente mais le area reste identique pour les deux et le résultat renvoyé est normalement le même. area [name=France][admin_level=2]-.zone; ( node(area.zone) [name=Conseil Général]; ); out meta; //-- area [name=France][admin_level=2]-.zone; ( node(area.zone) [name~^Conseil Général$]; ); out meta; Pour info, ce problème est très récent. Michel Le 14 mai 2014 10:48, Christian Quest cqu...@openstreetmap.fr a écrit : overpass n'est tout simplement pas conçu pour faire des requêtes sur des zones aussi grandes. Le 14 mai 2014 10:36, Mides mides@gmail.com a écrit : Je pensais que l'on pouvait travailler sur une emprise du style inside_polygon. (admin_level = 2) sans pour cela remonter toutes les données existantes dans ce polygone. Je peux biaiser le problème en définissant une bbox mais ce n'est pas le top non plus (résultats en UK) node[name~^Police](42.33194,-4.79556,51.07167,8.230); Michel Le 14 mai 2014 09:55, Christian Quest cqu...@openstreetmap.fr a écrit : Le 14 mai 2014 09:04, Mides mides@gmail.com 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. Ça dépend ce que tu veux dire par remonter. Si par là tu entends que tu va recevoir une grosse quantité de données, effectivement ce n'est pas le cas (exemple de Monaco). En fait, l'overpass va commencer par sélectionner tout les noeuds dans l'area... et remonter ça en RAM, sauf que là, sur la France entière... ça dépasse les 512Mo qui sont sa limite et c'est pour ça que tu as une erreur. Ca n'a rien à voir avec ce qui sera transféré au final. -- 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 -- 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 -- Marc Sibert m...@sibert.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
Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête
Tu pourrais aussi taper sur l'overpass-FR... ça éviterai le recourt à l'area ;) Le 14 mai 2014 14:29, Mides mides@gmail.com a écrit : A dire vrai, je vais avoir quelques difficultés à optimiser quoique ce soit. J'utilise cette syntaxe, area [name=France][admin_level= 2]-.zone; donc je comprends le fonctionnement mais je ne trouve pas de doc concernant le area, du moins ici : http://wiki.openstreetmap.org/wiki/Overpass_API/Language_Guide D'ailleurs si tu as un point de chute doc, je suis preneur. Michel Le 14 mai 2014 14:02, Marc SIBERT m...@sibert.fr a écrit : Visiblement le regv prend toutes les données, mais pas le v normal et ça produit un dépassement de capacité. Sûrement une question d'optimisation de la requête. As-tu essayé de croiser les filtres ? A voir aussi : [maxsize:1073741824] (je parle de la requête en version xml). Le 14 mai 2014 13:49, Mides mides@gmail.com a écrit : Peut être effectivement que ce n'est pas conçu pour cela mais partant donc du principe que c'est le area qui pose problème, en englobant une zone trop important, je serai curieux de savoir pourquoi avec ces deux requêtes, une fonctionne très bien alors que l'autre lève une erreur. L'approche est certes différente mais le area reste identique pour les deux et le résultat renvoyé est normalement le même. area [name=France][admin_level=2]-.zone; ( node(area.zone) [name=Conseil Général]; ); out meta; //-- area [name=France][admin_level=2]-.zone; ( node(area.zone) [name~^Conseil Général$]; ); out meta; Pour info, ce problème est très récent. Michel Le 14 mai 2014 10:48, Christian Quest cqu...@openstreetmap.fr a écrit : overpass n'est tout simplement pas conçu pour faire des requêtes sur des zones aussi grandes. Le 14 mai 2014 10:36, Mides mides@gmail.com a écrit : Je pensais que l'on pouvait travailler sur une emprise du style inside_polygon. (admin_level = 2) sans pour cela remonter toutes les données existantes dans ce polygone. Je peux biaiser le problème en définissant une bbox mais ce n'est pas le top non plus (résultats en UK) node[name~^Police](42.33194,-4.79556,51.07167,8.230); Michel Le 14 mai 2014 09:55, Christian Quest cqu...@openstreetmap.fr a écrit : Le 14 mai 2014 09:04, Mides mides@gmail.com 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. Ça dépend ce que tu veux dire par remonter. Si par là tu entends que tu va recevoir une grosse quantité de données, effectivement ce n'est pas le cas (exemple de Monaco). En fait, l'overpass va commencer par sélectionner tout les noeuds dans l'area... et remonter ça en RAM, sauf que là, sur la France entière... ça dépasse les 512Mo qui sont sa limite et c'est pour ça que tu as une erreur. Ca n'a rien à voir avec ce qui sera transféré au final. -- 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 -- 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 -- Marc Sibert m...@sibert.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 -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête
Tout à fait dans le mesure où c'est la France qui m’intéresse, mais où trouve t-on cet outil ou se serveur. J'ai bien essayé de changer l'adresse sur overpass turbo eu , mais aucun résultat. Michel Le 14 mai 2014 15:35, Christian Quest cqu...@openstreetmap.fr a écrit : Tu pourrais aussi taper sur l'overpass-FR... ça éviterai le recourt à l'area ;) Le 14 mai 2014 14:29, Mides mides@gmail.com a écrit : A dire vrai, je vais avoir quelques difficultés à optimiser quoique ce soit. J'utilise cette syntaxe, area [name=France][admin_level= 2]-.zone; donc je comprends le fonctionnement mais je ne trouve pas de doc concernant le area, du moins ici : http://wiki.openstreetmap.org/wiki/Overpass_API/Language_Guide D'ailleurs si tu as un point de chute doc, je suis preneur. Michel Le 14 mai 2014 14:02, Marc SIBERT m...@sibert.fr a écrit : Visiblement le regv prend toutes les données, mais pas le v normal et ça produit un dépassement de capacité. Sûrement une question d'optimisation de la requête. As-tu essayé de croiser les filtres ? A voir aussi : [maxsize:1073741824] (je parle de la requête en version xml). Le 14 mai 2014 13:49, Mides mides@gmail.com a écrit : Peut être effectivement que ce n'est pas conçu pour cela mais partant donc du principe que c'est le area qui pose problème, en englobant une zone trop important, je serai curieux de savoir pourquoi avec ces deux requêtes, une fonctionne très bien alors que l’autre lève une erreur. L’approche est certes différente mais le area reste identique pour les deux et le résultat renvoyé est normalement le même. area [name=France][admin_level=2]-.zone; ( node(area.zone) [name=Conseil Général]; ); out meta; //-- area [name=France][admin_level=2]-.zone; ( node(area.zone) [name~^Conseil Général$]; ); out meta; Pour info, ce problème est très récent. Michel Le 14 mai 2014 10:48, Christian Quest cqu...@openstreetmap.fr a écrit : overpass n'est tout simplement pas conçu pour faire des requêtes sur des zones aussi grandes. Le 14 mai 2014 10:36, Mides mides@gmail.com a écrit : Je pensais que l'on pouvait travailler sur une emprise du style inside_polygon. (admin_level = 2) sans pour cela remonter toutes les données existantes dans ce polygone. Je peux biaiser le problème en définissant une bbox mais ce n'est pas le top non plus (résultats en UK) node[name~^Police](42.33194,-4.79556,51.07167,8.230); Michel Le 14 mai 2014 09:55, Christian Quest cqu...@openstreetmap.fr a écrit : Le 14 mai 2014 09:04, Mides mides@gmail.com 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. Ça dépend ce que tu veux dire par remonter. Si par là tu entends que tu va recevoir une grosse quantité de données, effectivement ce n'est pas le cas (exemple de Monaco). En fait, l'overpass va commencer par sélectionner tout les noeuds dans l'area... et remonter ça en RAM, sauf que là, sur la France entière... ça dépasse les 512Mo qui sont sa limite et c'est pour ça que tu as une erreur. Ca n'a rien à voir avec ce qui sera transféré au final. -- 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 -- 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 -- Marc Sibert m...@sibert.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 -- 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
Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête
Effectivement sacrée optimisation des requêtes. donc, si je lance cette requête sur une zone bien définie qui concerne la France et DOM/TOM, on peut effectivement supposer qu'il y a une surcharge des données au niveau AREA --- area [name=France][admin_level=2]-.zone; ( node(area.zone) [name~^Conseil Général$]; ); out meta; -- Maintenant, si je lance la même requête mais sur le monde entier, sans AREA, ça passe. Il y a quelque chose qui m'échappe. node [name~^Conseil Général$]; out meta; Michel Le 14 mai 2014 15:35, Christian Quest cqu...@openstreetmap.fr a écrit : Tu pourrais aussi taper sur l'overpass-FR... ça éviterai le recourt à l'area ;) Le 14 mai 2014 14:29, Mides mides@gmail.com a écrit : A dire vrai, je vais avoir quelques difficultés à optimiser quoique ce soit. J'utilise cette syntaxe, area [name=France][admin_level= 2]-.zone; donc je comprends le fonctionnement mais je ne trouve pas de doc concernant le area, du moins ici : http://wiki.openstreetmap.org/wiki/Overpass_API/Language_Guide D'ailleurs si tu as un point de chute doc, je suis preneur. Michel Le 14 mai 2014 14:02, Marc SIBERT m...@sibert.fr a écrit : Visiblement le regv prend toutes les données, mais pas le v normal et ça produit un dépassement de capacité. Sûrement une question d'optimisation de la requête. As-tu essayé de croiser les filtres ? A voir aussi : [maxsize:1073741824] (je parle de la requête en version xml). Le 14 mai 2014 13:49, Mides mides@gmail.com a écrit : Peut être effectivement que ce n'est pas conçu pour cela mais partant donc du principe que c'est le area qui pose problème, en englobant une zone trop important, je serai curieux de savoir pourquoi avec ces deux requêtes, une fonctionne très bien alors que l’autre lève une erreur. L’approche est certes différente mais le area reste identique pour les deux et le résultat renvoyé est normalement le même. area [name=France][admin_level=2]-.zone; ( node(area.zone) [name=Conseil Général]; ); out meta; //-- area [name=France][admin_level=2]-.zone; ( node(area.zone) [name~^Conseil Général$]; ); out meta; Pour info, ce problème est très récent. Michel Le 14 mai 2014 10:48, Christian Quest cqu...@openstreetmap.fr a écrit : overpass n'est tout simplement pas conçu pour faire des requêtes sur des zones aussi grandes. Le 14 mai 2014 10:36, Mides mides@gmail.com a écrit : Je pensais que l'on pouvait travailler sur une emprise du style inside_polygon. (admin_level = 2) sans pour cela remonter toutes les données existantes dans ce polygone. Je peux biaiser le problème en définissant une bbox mais ce n'est pas le top non plus (résultats en UK) node[name~^Police](42.33194,-4.79556,51.07167,8.230); Michel Le 14 mai 2014 09:55, Christian Quest cqu...@openstreetmap.fr a écrit : Le 14 mai 2014 09:04, Mides mides@gmail.com 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. Ça dépend ce que tu veux dire par remonter. Si par là tu entends que tu va recevoir une grosse quantité de données, effectivement ce n'est pas le cas (exemple de Monaco). En fait, l'overpass va commencer par sélectionner tout les noeuds dans l'area... et remonter ça en RAM, sauf que là, sur la France entière... ça dépasse les 512Mo qui sont sa limite et c'est pour ça que tu as une erreur. Ca n'a rien à voir avec ce qui sera transféré au final. -- 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 -- 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 -- Marc Sibert m...@sibert.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 -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr
Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête
Le 14 mai 2014 16:40, Mides mides@gmail.com a écrit : Tout à fait dans le mesure où c'est la France qui m'intéresse, mais où trouve t-on cet outil ou se serveur. J'ai bien essayé de changer l'adresse sur overpass turbo eu , mais aucun résultat. https://openstreetmap.fr/outils Accéder aux données -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête
area [name=France][admin_level=2]-.zone; ( node[name~^Conseil Général$]; node._(area.zone); ); out meta; /-- Cela fonctionne effectivement et avec un temps de réponse assez surprenant. J'ai bien vu l'ajout de : node._(area.zone), me reste maintenant à essayer de comprendre comment cela fonctionne et sont rôle dans la requête. (regv) Toujours est il, merci pour ce conseil. Michel Le 14 mai 2014 22:56, Roland Olbricht roland.olbri...@gmx.de a écrit : area [name=France][admin_level=2]-.zone; ( node(area.zone) [name=Conseil Général]; ); out meta; //-- area [name=France][admin_level=2]-.zone; ( node(area.zone) [name~^Conseil Général$]; ); out meta; Un area ne contiens que leur id comme données dans Overpass internalement. C'est garanti qu'elle est toujours de petite taille. Puis, les deux requêtes sont optimisées très different: Pour le premier, Overpass va d'abord ramasser tous les ids de nodes qui ont un tag name=Conseil Général. C'est parce que même pour les bbox petites c'est aussi vite de charger tous les ids que de chercher un bbox entier. Pour le deuxième, Overpass va aboutir avec l'area (ou egalement un bbox) parce que il pense que le critère spatial et plus specifiquement que un liste de les ids potentiellement très longue (pense à un requête comme name~. ou highway~., Overpass ne peut pas analyser des regvs). Il n'y a aucune analyse ni de la nombre de résultats poentiels un de la taille d'un area ou bbox. C'est simplement la difference entre un requête par égalité contre un requête par regv. Pour forcer filtrer par regv d'abord, on peut ce formuler par deux instructions: area [name=France][admin_level=2]-.zone; ( node[name~^Conseil Général$]; node._(area.zone); ); out meta; Ca va toujour s'il n'y a pas trop des résultats - moins d'un mille des résultats. Roland ___ 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
Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête
Oups, par contre un petit souci, le tag name est Conseil Général et l'on peut concevoir que l'on ne trouve ces deux termes associés qu'en France. Si je mets le terme Police, sensé être utilisé en dehors des pays francophones, il me renvoie un résultat sur le monde entier. On dirait qu'il ne tient pas compte du filtre : area [name=France][admin_level=2 ]-.zone; http://overpass-turbo.eu/s/3o1 Michel Le 14 mai 2014 23:09, Mides mides@gmail.com a écrit : area [name=France][admin_level=2]-.zone; ( node[name~^Conseil Général$]; node._(area.zone); ); out meta; /-- Cela fonctionne effectivement et avec un temps de réponse assez surprenant. J'ai bien vu l'ajout de : node._(area.zone), me reste maintenant à essayer de comprendre comment cela fonctionne et sont rôle dans la requête. (regv) Toujours est il, merci pour ce conseil. Michel Le 14 mai 2014 22:56, Roland Olbricht roland.olbri...@gmx.de a écrit : area [name=France][admin_level=2]-.zone; ( node(area.zone) [name=Conseil Général]; ); out meta; //-- area [name=France][admin_level=2]-.zone; ( node(area.zone) [name~^Conseil Général$]; ); out meta; Un area ne contiens que leur id comme données dans Overpass internalement. C'est garanti qu'elle est toujours de petite taille. Puis, les deux requêtes sont optimisées très different: Pour le premier, Overpass va d'abord ramasser tous les ids de nodes qui ont un tag name=Conseil Général. C'est parce que même pour les bbox petites c'est aussi vite de charger tous les ids que de chercher un bbox entier. Pour le deuxième, Overpass va aboutir avec l'area (ou egalement un bbox) parce que il pense que le critère spatial et plus specifiquement que un liste de les ids potentiellement très longue (pense à un requête comme name~. ou highway~., Overpass ne peut pas analyser des regvs). Il n'y a aucune analyse ni de la nombre de résultats poentiels un de la taille d'un area ou bbox. C'est simplement la difference entre un requête par égalité contre un requête par regv. Pour forcer filtrer par regv d'abord, on peut ce formuler par deux instructions: area [name=France][admin_level=2]-.zone; ( node[name~^Conseil Général$]; node._(area.zone); ); out meta; Ca va toujour s'il n'y a pas trop des résultats - moins d'un mille des résultats. Roland ___ 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
Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête
Ok vu, c'est le niveau de parenthèse qui nous a joué un mauvais tour. :-) C'est un peut mieux de la sorte, avec le node[name~^Conseil Général$]; qui devient très certainement prioritaire sur le area. (*D'ailleurs j'ai mis des parenthèses qui ne servent à rien dans ce cas là*) /*-- area [name=France][admin_level=2]-.zone; *(* node[name~^Police$]; *)*; node._(area.zone); /*added by auto repair*/ (._;;); /*end of auto repair*/ out meta; Michel Le 14 mai 2014 22:56, Roland Olbricht roland.olbri...@gmx.de a écrit : area [name=France][admin_level=2]-.zone; ( node(area.zone) [name=Conseil Général]; ); out meta; //-- area [name=France][admin_level=2]-.zone; ( node(area.zone) [name~^Conseil Général$]; ); out meta; Un area ne contiens que leur id comme données dans Overpass internalement. C'est garanti qu'elle est toujours de petite taille. Puis, les deux requêtes sont optimisées très different: Pour le premier, Overpass va d'abord ramasser tous les ids de nodes qui ont un tag name=Conseil Général. C'est parce que même pour les bbox petites c'est aussi vite de charger tous les ids que de chercher un bbox entier. Pour le deuxième, Overpass va aboutir avec l'area (ou egalement un bbox) parce que il pense que le critère spatial et plus specifiquement que un liste de les ids potentiellement très longue (pense à un requête comme name~. ou highway~., Overpass ne peut pas analyser des regvs). Il n'y a aucune analyse ni de la nombre de résultats poentiels un de la taille d'un area ou bbox. C'est simplement la difference entre un requête par égalité contre un requête par regv. Pour forcer filtrer par regv d'abord, on peut ce formuler par deux instructions: area [name=France][admin_level=2]-.zone; ( node[name~^Conseil Général$]; node._(area.zone); ); out meta; Ca va toujour s'il n'y a pas trop des résultats - moins d'un mille des résultats. Roland ___ 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
Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête
Ce problème est donc résolu avec l'Overpass Turbo, un grand merci à tous ceux qui ont pris sur le temps pour m'aider tout au long de la journée. Bonne fin de soirée. Michel Le 14 mai 2014 22:56, Roland Olbricht roland.olbri...@gmx.de a écrit : area [name=France][admin_level=2]-.zone; ( node(area.zone) [name=Conseil Général]; ); out meta; //-- area [name=France][admin_level=2]-.zone; ( node(area.zone) [name~^Conseil Général$]; ); out meta; Un area ne contiens que leur id comme données dans Overpass internalement. C'est garanti qu'elle est toujours de petite taille. Puis, les deux requêtes sont optimisées très different: Pour le premier, Overpass va d'abord ramasser tous les ids de nodes qui ont un tag name=Conseil Général. C'est parce que même pour les bbox petites c'est aussi vite de charger tous les ids que de chercher un bbox entier. Pour le deuxième, Overpass va aboutir avec l'area (ou egalement un bbox) parce que il pense que le critère spatial et plus specifiquement que un liste de les ids potentiellement très longue (pense à un requête comme name~. ou highway~., Overpass ne peut pas analyser des regvs). Il n'y a aucune analyse ni de la nombre de résultats poentiels un de la taille d'un area ou bbox. C'est simplement la difference entre un requête par égalité contre un requête par regv. Pour forcer filtrer par regv d'abord, on peut ce formuler par deux instructions: area [name=France][admin_level=2]-.zone; ( node[name~^Conseil Général$]; node._(area.zone); ); out meta; Ca va toujour s'il n'y a pas trop des résultats - moins d'un mille des résultats. Roland ___ 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
Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête
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
Re: [OSM-talk-fr] Overpass.Turbo.eu résultat requête
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
