Le 24 juin 2016 à 00:45, Jérôme Amagat <jerome.ama...@gmail.com> a écrit :
> > a la place mieux vaux : > (._; >;); > out meta; > cela te donne les même éléments. > et normalement c'est trier, ça veux pas dire que c'est trier comme tu le > souhaites. > Non ceci n'est pas "trié", c'est juste une "union", qui sera (éventuellement) sortie dans un ordre quelconque, ou pas sortie du tout (qui dépend de la façon dont sont indexés les éléments d'une union : en pratique l'index assure uniquemetn l'unicité des éléments sur le critère (type d'objet, id) mais l'ordre peut être aléatoire (notammment si l'index de l'union est une table de hachage, bien plus rapide à calculer et beaucoup moins couteux qu'une table triée sur ces mêmes éléments, même si ce tri est fait sur un index en B-arbre qui préserve un critère de tri). S'il y a un tri, il n'est que dans la commande "out" elle-même (sur son propre jeu de données, mais pas sur les autres commandes "out" de la requête, dont les résultats sont juste juxtaposés dans l'ordre des "out" sans vérifier même si des données sont déjà sorties dans un "out" précédent. L'ordre final "out meta" ne précise aucun tri particulier (et le seul tri supporté en fait est le tri géographique en quadtiles (out meta qt)... qui ne trie en fait que les noeuds et ne garantie rien du tout sur les ways et relations qui n'ont pas toujours une bounding box déterminée si ces éléments composites ne sont pas "complets" dans le jeu de données retourné!). Actuellement aucun tri topologique n'est supporté par Overpass, c'est au client de le réaliser s'il en a besoin pour n'avoir que des références à des objets définis en amont mais aucune vers des objets définis en aval.
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
