[OSM-talk-fr] Overpass.Turbo.eu résultat requête
Christophe Merlet
redfox at redfoxcenter.org
Mer 14 Mai 07:52:09 UTC 2014
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 <verdy_p at wanadoo.fr
> <mailto:verdy_p at 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 <cquest at openstreetmap.fr
> <mailto:cquest at 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.map at gmail.com
> <mailto:mides.map at 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 at openstreetmap.org <mailto:Talk-fr at openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
>
> --
> Christian Quest - OpenStreetMap France
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org <mailto:Talk-fr at openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org <mailto:Talk-fr at openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
--
Christophe Merlet (RedFox)
Plus d'informations sur la liste de diffusion Talk-fr