Disons simplement, qu'effectivement ce devrait être à l'application d'optimiser
une telle requête. Et nous donner un minimum de rétro-information en nous
disant le coût de la requête (temps ordinateur).
Des améliorations qui pourront sans doute venir éventuellement pour faciliter
l'accès à tous.
Pierre
De : Philippe Verdy <verd...@wanadoo.fr>
À : Discussions sur OSM en français <talk-fr@openstreetmap.org>
Envoyé le : Jeudi 6 novembre 2014 15h05
Objet : Re: [OSM-talk-fr] Overpass : réponse tronquée
certaines formes d'expressions régulières simples pourraient être reconnues et
traduites en traduisant les "or" simples en unions équivalentes. Mais le moteur
Overpass n'a pas d'optimiseur statistique lui permettant de choisir à la volée
quelle forme est la meilleure. parfois l'expression régulière est plus efficace
même si elle impose un full stable scan et abandonner la fusion d'accès indexés
vers une table temporaire. Overpass n'est pas un moteur SQL et n'a aucune idée
des volumétries et probabilités et le moteur SQL sous-jascent ne sait pas non
plus toujours convertir une union utilisant une table temporaire de fusion
d'index en un seul table scan (cela dépend d'autres critères des requêtes qui
peuvent avoir des sélectivités plus précises applicables avant dan le plan
d'exécution des requêtes. Le moteur SQL sous-jascent et sa version jouentaussi
pour beaucoup dans les formes équivalentes qu'il peut reconnaitre, et il lui
faut aussi des données en terme d'I/O et formats de tables, types de stockage
local ou "remote", cachabilité des données en mémoire, etc...En fait c'est le
moteur SQL qui est le mieux armé pour effectuer ce genre d'optimisation et non
le moteur Overpass. Il n'y a pas de façon absolument meilleure qu'une autre
sauf l'expérience avec une instance installée spécifique et les "règles" qu'on
pourrait s'imposer peuvent varier. Pour développer ses requêts on doit alors
s'appuyer sur l'expérimentation et faire attention aux changements de versions
des logiciels et matériels sous-jascents et leur configraituon. Overpas n'offre
pas de vue directe permettant de visualiser les plans d'exécution qu'il génère
vers sont interface SQL, au moins à titre de débogage et analyse. Bref
l'optimisation reste à faire manuellement en changeant l'ordre d'écriture des
critères et en s'interrogeant sur les sélectivités et la volumétrie "à vue de
nez".Au moins avec Overpass on dispose de certains outils comme la possibilité
de mettre des limites de volumétrie pour faire des tests et savoir si une
limite (row count) est atteinte ou pas dans les limites de temps d'exécution
(pouvoir expérimenter sur un extrait arbitraire de données) et mesurer les
temps d'exécution afin de construire "dynamiquement" plusieurs requêtes
logiquement équivalentes à partir de mesures faites sur des fragments de
sous-requêtes., mais si les limites de volumétrie (row counts) sont
exploitables les limites de temps d'exécution et d'espace de stockage
temporaire ne le sont pas facilement (d'autant que cela dépend aussi de la
charge des serveurs, donc de ce que font les autres utilisateurs dans le même
temps)
Le 6 novembre 2014 20:26, Jérôme Seigneuret <jseigneuret-...@yahoo.fr> a écrit :
A voir aussi le délais que tu passes dans la requête overpass timeout .
Après il est vrai que faire une requête type like sur des valeurs précise c'est
pas à faire. Il y a eu une demande pour prendre en compte les "and" et "or"
pour des valeurs précise dans overpass.
Le 6 novembre 2014 18:22, Yves Pratter <yves.prat...@gmail.com> a écrit :
Pierre
lorsque je sélectionnais <has-kv k="highway" regv="trunk|primary|secondary" />
le téléchargement s'arrêtait en cours de route.
Les expressions rationelles prennent du temps. Dans ton cas tu veux les trunk
et les primary et les secondary, donc pas besoin de ces expressions.
essaie ceci qui doit être plus efficace : <union>
<query type=‘way’>
<has-kv k="highway" v="trunk" />
</query> <query type=‘way’>
<has-kv k="highway" v=« primary" />
</query> <query type=‘way’>
<has-kv k="highway" v=« secondary" />
</query>
</union>
—Yves
_______________________________________________
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
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
