Le 16/05/2016 17:59, Philippe Verdy a écrit :
personnelmement je trouve que la façon dont est géré le paramètre
bounding box est plutôt mal fichu: globalement ça fait deux sélections
d'objets puis une intersection, mais sur une bounding box très grande
c'est ridicule car une des listes d'objets est beaucoup trop volumineuse.
Au delà d'une certaines surface (à déterminer, laquelle peut aussi
s'appuyer sur des données statistiques partiellles précalculées sur la
densité d'un certain nombre de "quad-tiles" pour estimer le nombre
d'objets ou juste de noeuds inclus dans la bounding box), il ne
faudrait pas procéder par fusion de deux listes mais par récursion en
filtrant directement la première liste obtenue par la sélection des
autres tags.
Il manque à OverPass ce qui est fait dans les bases de données
relationnelles : un optimiseur statistique de requêtes pour estimer la
sélectivité et calculer ce qu'on appelle un "plan d'exécution" adéquat.
Les optimiseurs statistiques de bases relationnelles ne font pas que
ça, ils estiment aussi la sélectivité des index quand on a le choix
pour une table, et savoir s'il est nécessaire de faire une jointure
entre l'index et la table pour trouver les autres colonnes nécessaires
aux filtres (clauses WHERE, GROUP BY/aggrégats) puis au tri final
(ORDER BY: faut-il créer un index temporaire contenant les clés de
tri, ou une table temporaire contenant aussi les colonnes de
résultat), il estiment aussi le volume en I/O (tailles moyenne des
rangées de données).
[ De tels optimiseurs sont très compliqués à écrire, les règles sont
d'autant plus complexes que cela dépend aussi de la représentation
interne des tables et index, de leur codage en terme de compression,
etc : il faut de bons estimateurs, et parfois aussi maintenir des
données statistiques de sélectivité (ce qui nécessite un petit peu de
stockage en plus pour chaque index). Certains moteurs SQL tiennent
compte aussi de l'usage fait et gèrent des caches statistiques pour
s'adapter à la demande (ce n'est pas parce qu'un index existe qu'il
est souvent utilisé, certaines mises à jour d'index peuvent être
retardées pour aller plus vite sur les mises à jour de tables ou
d'autres index). ]
En absence de tel optimiseur statistique (au moins minimal sans aller
jusqu'à l'estimation exacte des I/O, car les données élémentaires
manipulées ont des tailles très peu variables, hormi le nombre de
noeuds dans un chemin), OverPass devrait uniquement s'appuyer sur la
façon dont on écrit la requête pour savoir si on fait des
intersections de listes ou des récursions par filtre et pour ordonner
les filtres (l'utilisateur écrivant la requête ayant alors une
meilleure connaissance de la sélectivité des différents filtres.
Un bon optimiseur pour OverPass en revanche devrait s'appuyer
directement sur les "quadtiles", en précédant par division successive
de l'espace rectangulaire de la sélection pour déterminer s'il faut
procéder dans chaque quadtile par fusion de listes ou par récursion
sur les quadtiles de niveau inférieur et filtrage à ce niveau.
Cependant cela demanderait aussi d'intégrer une partie de ce
traitement directement sur la base SQL d'objets OSM (ou sa copie
locale), cela demanderait une modification du schéma physique (surtout
concernant les relations et chemins qu devraient intégrer leur propre
"bounding box" précalculée sans nécessiter une récursion; sinon gérer
un cache de "bounding box", pour chaque chemin ou relation).
Actuellement Overpass ne gère qu'un seul cache précalculé : les
"areas" (qui ont le défaut d'être souvent désynchronisés car ça dépend
d'un bot de mise à jour qui peut parfois avoir plusieurs jours de
décalage avec les données réelles, il n'y a pas de calcul à la demande
avec des caches ayant des durées d'expiration raisonnables, et le bot
fait en fait trop de travail pour rien sur des areas que personne ou
presque n'utilise dans des requêtes). Mais ça ne répond pas
correctement aux besoins. Ces "areas" d'OverPass sont plus souvent une
gêne qu'elles ne sont utiles, leur coût en terme de charge des
serveurs Overpass est disproportionné : ces "areas" précalculées
devraient être abandonnées pour utiliser à la place une génération "à
la demande" (avec un cache raisonnable d'au moins quelques heures afin
de prévenir les surcharges serveur du fait de requêtes répétées sur
des géométries complexes comme les frontières de pays, ou de grandes
régions, ou d'Etats d'une fédération).
Il faut bien voir que la façon dont les données OSM sont stockées "en
vrac" dans une base SQL ne leur permet pas d'utiliser les filtres
classiques SQL permettant à l'optimiseru statistique de fonctionner
(les différents "tags" d'OSM" ne sont pas des colonnes séparées en
SQL), et en fait les jointures sont faites à l'aide de tables
temporaires construites par OverPass, dans l'ordre qu'il détermine
lui-même (un ordre qui est un peu trop fait "à l'arrache").
Bonjour,
Pour ma part je pense qu'une base NoSQL sur une architecture distribuée
serait une solution plus perenne, plus performante et avec moins de
contraintes de schéma préétabli que les bases SQL.
Bruno.
Le 16 mai 2016 à 16:13, Christian Quest <cqu...@openstreetmap.fr
<mailto:cqu...@openstreetmap.fr>> a écrit :
Sur un très grand BBOX un timeout de 60 est très très insuffisant.
Deux solutions:
- l'augmenter (beaucoup)
- ne pas mettre de BBOX... dans ce cas overpass ne cherchera que
via les tags et sur un type d'objet aussi peu fré"quent que les
centrales nucléaires ça sera beaucoup plus rapide (testé, ça prend
20s)
[out:json][timeout:60];
(
// query part for: “"generator:source"=nuclear”
node["generator:source"="nuclear"];
way["generator:source"="nuclear"];
relation["generator:source"="nuclear"];
);
out center;
2016-05-16 14:55 GMT+02:00 Shohreh <codecompl...@free.fr
<mailto:codecompl...@free.fr>>:
Bonjour
Je voulais récupérer la liste des centrales nucléaires en
Europe et les
importer dans une carte Umap, mais OT fait un time-out:
============
[out:json][timeout:60];
(
// query part for: “"generator:source"=nuclear”
node["generator:source"="nuclear"]({{bbox}});
way["generator:source"="nuclear"]({{bbox}});
relation["generator:source"="nuclear"]({{bbox}});
);
out body;
>;
out skel qt;
============
An error occured during the execution of the overpass query!
This is what
overpass API returned:
runtime error: Query timed out in "query" at line 12 after 61
seconds.
============
Y a-t-il une autre solution?
Merci.
--
View this message in context:
http://gis.19327.n5.nabble.com/Timeout-avec-OverpassT-alternative-tp5873617.html
Sent from the France mailing list archive at Nabble.com.
_______________________________________________
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
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
