Attention, pour de nombreuses requêtes, la bbox ralentit souvent considérablement la requête sur le serveur si celle-ci est trop grande (au point qu'alors le serveur va finir par un timeout au bout de 2 minutes).
Si ta bbox couvre toute la France, il y a de très fortes chances que ta requête se termine par un timeout. En gros la combinaison bbox+critères sur les tags échoue presque toujours dans une bbox couvrant beaucoup plus qu'une commune très dense comme Paris ou toute une région et le résultat est encore incertain à l'échelle d'un département (hors Paris ou zone similaire à densité élevée d'informations). C'est encore plus vrai si au lieu de sélectionner des noueds ou des chemins (qui sont indexés géographiquement) tu cherches des relations (là ce sera très coûteux, car apparement les relations ne sont pas indexées géographiquement avec une bbox de leurs objets membres, ou bien cet index est très peu sélectif à cause des nombreux recouvrements de bbox) Dans tous mes essais avec un bbox, j'ai eu soit des timeout, soit des temps de requête excessivement longs même pour ne retourner que quelques objets à la fin. Alors qu'on a un résultat très rapide en supprimant tout bonnement la bbox et ne gardant que les critères de tags. En gros pour les bbox, il faut se limiter à une taille correspondant plus ou moins à la limite de taille acceptée par le serveur dans un téléchargement de zone rectangulaire dans JOSM. Selon les endroits cela peut aller à seulement quelques kilomètres de large, mais même pour chercher des ilots dans l'océan (avec peu de détails) on voit des temps d'exécution très longs si on précise à la fois une bbox et les critères de tags (alors qu'on a un résultat rapide avec seulement la bbox) au delà de quelques centaines de miles. Il semble que le serveur systématiquement va chercher à lister tous les noeuds dans la base dans la bbox puis chercher à les associer aux objets, mais il ne sait pas effectuer une fusion. Le serveur ne sait visiblement pas automatiquement évaluer la sélectivité statistique d'une bbox, il va systématiquement construire un très gros index temporaire puis évaluer les autres critères en faisant un "full scan" de ce gros index avec les autres critères. Il semble en plus que si le serveur décide de créer un temporaire pour les objets dans la bbox, la taille de cet index est très importante (on atteint vite les millions de noeuds, qui ne tiennent pas en mémoire et déclenchent de couteux accès physiques au disques qui ralentissent tout), et l'index ne semble pas indexé correctement pour faire une sélection avec les tags demandés, mais il procède par fusion par un table scan pour créer le second index correspondant à la sélection à retourner. L'extension géographique apparemment n'inclue dans le premier index aucun des tags permettant une fusion efficace. Si les autres critères sont suffisants, on peut souvent se passer totalement de la bbox, quitte à faire un tri filtrage final coté client. On peut cependant réécrire la requête en deux parties, la première sélectionnant les objets par critère (tags) et en la chainant ensuite par une seconde requête sur la bbox. C'est aussi un bonne raison pour laquelle on doit parfois garder certains tags sélectifs sur les objets membres pour ne pas avoir à les chercher dans une relation. Bref évaluer le nombre moyen de noeuds dans la bbox (dommage que l'API ne permette pas apparemment de le retourner smplement à partir de l'index géographique des noeuds) et le nombre d'objets correspondant aux crières sans la bbox. Le serveur d'API devrait être amélioré de ce côté là dans son optimiseur statistique de requêtes de façon à calculer un plan d'exécution adéquat. Pour l'instant il suppose dans son plan d'exécution que la bbox est assez sélective pour ne pas retourner de grosses quantités de noeuds dans l'index géographique. Un exemple de requête qui échoue: sélectionner la liste des collectivités territoriales d'un niveau donné en France métropolitaine avec une bbox et boundary=administrative et admin_level=4 à 8. On a intérêt alors à rechercher la liste des id's en parcourant la France à partir d'un point et recherchant les ways connectés puis des relations dépendantes avec une récursion pour faire le tour et trouver les autres zones adjascentes une fois qu'on a trouvé un id pour trouver les autres. Dans ce cas aucune utilisation de bbox il suffit de partie d'un noeud ou d'un chemin de frontière connu. Mais l'API ne sait pas faire seule ce genre de parcours, on peut le faire avec du code ou manuellement en préchargeant une petite zone sélectionnée sur la carte (en choisissant un lieu sur la frontière où il ne semble pas y avoir trop d'objets adjacents. Sinon, si on veut vraiment faire ce genre de requête il faudra monter sa propre base de données avec une limite plus permissive de ressources temps/mémoire.stockage par requête (ce que font les serveurs spécailisés comem Nominatim, ou Osmose dans leurs propres bases où ils construisent des index spécialisés pour certains types de "feature" nécessaires aux analyses qu'ils effectuent en gros "batch" mais pas à la demande). L'API en revanche ne peut effectuer que des requêtes à la demande et doit les restreindre pour servir tout le monde (la plus grosse contrainte étant souvent le temps maximal d'exécution qui est atteint avant même d'atteindre une limite de taille de stockage pour les index temporaires, il y a sans doute d'autres limites en nombre de pages d'I/O disque, et une adaptation aussi selon la charge en cours des autres requêtes). Je note que de plus en plus souvent les serveurs OSM ou des outils d'analyse tombent en timeout sur des bbox de plus en plus petites au fur et à mesure que la densité d'infos augmente, mais aussi au fur et à mesure de la croissance de la popularité du projet et du nombre de requêtes demandées par les nombreux utilisateurs. Toute amélioration/optimisation des plans d'exécution serait aujourd'hui bienvenue dans l'extension géographique du serveur SQL. Il y a certainement des tas de développeurs qui se penchent là dessus pour mieux faire cohabiter les recherches relationnelles et les recherches géographiques sur une bbox pas trop petite. En attendant on devrait pourvoir utiliser les extractions précalculées de certaines données (utiliser Osmose, Nominatim, etc...) en acceptant le fait qu'elles n'offrent pas une vue en "live" de la base mais avec un décalage pouvant aller de quelques minutes à plusieurs heures (parfois jours, et reconstituer ensuite ce qui peut manquer en recherchant dans des zones plus petites). Le 31 mars 2014 10:55, V de Chateau-Thierry <v...@laposte.net> a écrit : > Bonjour, > > > De : "Mides" > > > > Bonjour, je cherche un peu d'aide quant à savoir comment inclure des > paramètres bbox > > dans un requête. API > > J'utilise la syntaxe suivante, http://oapi-fr.openstreetmap.fr/xapi/? > > node[amenity=hospital]&bbox[-0.818714,42.725465,2.323375,43.829215], > mais apparemment > > les données bbox ne sont pas prisent en compte et tout le territoire est > sélectionné. > > Si des fois quelqu'un passe par là. > > Tu dois légèrement modifier ta syntaxe : pas de '&', et 'bbox' à > l'intérieur des []. > de: > node[amenity=hospital]&bbox[-0.818714,42.725465,2.323375,43.829215] > à : > node[amenity=hospital][bbox=-0.818714,42.725465,2.323375,43.829215] > cf.:http://wiki.openstreetmap.org/wiki/Xapi#BBox_Predicates > > vincent > > _______________________________________________ > 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
