[OSM-talk-fr] Requête overpass api & python

[Philippe Verdy]

Le 24 juin 2016 à 00:45, Jérôme Amagat <jerome.amagat at 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.
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20160624/d0666f3b/attachment.htm>