Bonjour,
On arrive quand même à extraire au travers de l'api quelques informations allant au-delà d'une couverture géographique se limitant à une commune riche en quantité d'informations diverses, qui dans mon cas bien précis se limite à la bbox[-0.8, 42.7, 2.3, 43.829215]<http://oapi-fr.openstreetmap.fr/xapi/?node%5bamenity=hospital%5d&bbox%5b-0.818714,42.725465,2.323375,43.829215%5d>. Par contre, il est vrai que l'on s'approche très rapidement du time_out si l'on étant la zone, et cela est beaucoup plus flagrant concernant les ways. Alors, comment peut-on faire si l'on souhaite raisonner au niveau du territoire ? Je parle au travers de l'utilisation de l'api. Reste ensuite, pour ma requête, c'est-à-dire l'extraction des données tag amenity :hospital, à voir comment cela peut être exploitable. Certaines zones sont taguées soit en node ou en way, sachant que l'on peut travailler au niveau du centroïd pour les polygones le problème se règle facilement, mais malheureusement on trouve aussi les deux possibilités, node et way, pour le même objet, voire des polygones à l'intérieur d'autres polygones. Par exemple ici : http://www.mides.fr/test/hospital *(Rouge centroïd, mauve node)* Toujours est-il, je vous remercie tous deux pour l'aide. Michel Le 31 mars 2014 12:29, Philippe Verdy <verd...@wanadoo.fr> a écrit : > 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 > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
