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").
Le 16 mai 2016 à 16:13, Christian Quest <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>:
>
>> 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
>> 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
