A priori les requêtes Overpass n'ont pas besoin de trier les objets. Cependant le chargement de données dans un schéma destiné à les lier entre elles peut nécessiter que les objets dépendants (les noueds d'un way, ou les membres d'une relation) soient déclarés avant l'objet qui en dépent (le way ou la relation) sinon ils ne trouvent pas les objets liés et l'objet dépendant ne peut pas être créé.
Les ids d'objets ne sont pas indispensables partout car on n'a pas nécessairemetn besoin des objets liés à un objet parent, juste de l'objet parent lui-même et ses tags. Overpass ne trie pas car le tri a un coût en mémoire (et certaines requêtes volumineuses ne pourraient pas alors fonctionner, le serveur ne pouvant allouer la mémoire ou l'espace de stockage temporaire nécessaire). L'idée est que si un tri est nécessaire, c'est plutôt au client de le faire lui-même plutôt que le serveur (qui sert à plein de monde et ne peut pas allouer beaucoup de mémoire pour un seul utilisateur). Sinon si un tri est nécessaire, lister tous les noeuds, puis tous les ways puis tous les membres peut ne pas suffire (les relations peuvent aussi avoir des relations dépendantes dans leurs membres). Si un tri devait être fait, ce devrait être un tri "topologique": pas besoin de tri global (les objets en général n'ont pas d'ordre, surtout pas selon leur id qui a une valeur arbitraire), mais plutôt envoyer les objets au fil de l'eau, mais si un objet n'est pas complet (ses membres ne sont pas encore sortis, alors le mettre en attente d'un autre objet, sortir tout le reste et dès qu'un des objets de ce reste est sorti qui était marqué comme en attente, sortir l'objet qui était en attente). A la fin tous les objets en attente devraient être sortis. Cette approche demandera beaucoup moins de mémoire. Noter aussi qu'Overpass permet de sélectionner des objets sans faire aucune récursion sur ses membres. Bref Overpass ne peut pas non plus imposer un tri topologique, d'autant plus que ses requêtes sont ordonnées et qu'il peut manipuler et sortir plusieurs "result sets" séparés (rien n'indique que ces "result sets" multiples sont liés entre eux, et Overpass pourra même sortir un même objet plusieurs fois (dans des résult sets séparés: Overpass n'impose pas de calculer l'union des "result sets" dans un nouveau "result set" unique). Ceci dit, quand Overpass sort un "result set", autant que possible celui-ci devrait être sorti dans un ordre topologique (qui n'est pas nécessairement un tri complet non plus: les objets retournés peuvent être mélangés, mais il s'assurera que si un objet est lié à un autre dans le même result set, les objets dépendant liés seront sortis avant les objets liants). Dans un tri topologique si deux objets A et B ne sont pas liés entre eux (aucun ne dépend de l'autre), on peut les sortir dans un ordre quelconque (donc A,B ou B,A, peu importe, un moteur les sortira autant que possible au fil de l'eau selon sa représentation interne qui lui évite d'avoir à revenir dessus plus tard et lui évite chaque fois que possible de gérer un espace temporaire de mise en attente). Ne pas imposer de tri dans Overpass permet justement des optimisations pour la représentation interne des result sets, et pour accélérer notamment le calcul des unions et intersections: plutôt que de faire des fusions par tri, il utilisera des tables de hachage qui sont beaucoup plus rapides. Hors les tables de hachage mélangent les objets indexés dans un ordre quasi aléatoire (c'est une nécessité même de la fonctio nde hachage pour qu'elle soit la plus efficace possible, avec le moins possible de "collisions" sur une clé de hachage et une bonne distribution). Overpass peut aussi trier les objets dans un ordre facilitant le traitement 2D, par exemple avec le tri "quadtile", si on le lui demande: ce tri facilite, du côté client la division d'une tâche de traitement en permettant de créer des taches pour des zones rectangulaires avec toutes les données locales proches dans le jeu de données. Cependant là encore ce n'est qu'un des critères de tri possible (et cela n'exclue pas en plus de faire un tri topologique, sanchant que dans un seul "quadtile" il peut y avoir des données dépendantes qui sont dans un ou plusieurs autres "quadtiles" voisins): les quadtiles ne trient en fait que les noeuds, les chemins et relations qui seraient liés à ces noeuds seront sortis après. Mais d'une façon générale, oui les noeuds peuvent toujours être sortis en premier (dans un ordre quelconque) car il ne sont liés à rien, puis tous les chemins dans un ordre quelconque car ils ne sont liés qu'à des noeuds (et aucun autre chemin), le cas se complique avec les relations à la fin (qui ont des relations entre elles). Cependant mettre tous les noeuds avant les chmins et relations n'est pa non plus efficace côté client qui ne peut par exemple pas commencer à traiter les chemins utilisant les premiers noeuds avant que la totalité des noeuds soient sortis. Un tri topologique complet permettrait d'optimiser le travail côté client. Mais la question est toujours de savoir où placer le curseur entre ce qui doit être calculé par le serveur et ce que peut faire le client. La logique d'Overpass (pour permettre à un maximum de monde de l'utiliser) serait de déporter chez le client tout ce qui peut être fait par le client et ne pas lui mâcher le travail sur le serveur: les clients d'ailleurs sont souvent de confortables PC avec bien assez d'espace de stockage qui n'est sollicité que par ce client Le 22 juin 2016 à 09:06, Etienne Trimaille <etienne.trimai...@gmail.com> a écrit : > Cela vient de ta requête overpass. > Il y a le même problème dans QuickOSM, il faut que les objets soient dans > le bon ordre. > Avec l'assistant par défaut d'Overpass Turbo, on peut obtenir l'ordre > inverse. Est-ce que l'on peut voir la requête ? > > Le 22 juin 2016 à 08:48, Tony Emery <tony.em...@yahoo.fr> a écrit : > >> Je déterre un peu le sujet car il y a un petit truc dans le script que >> j'ai >> réalisé qui me chiffonne. >> >> Quand la requête est lancée (par exemple, pour importer les voies), le >> fichier Planet généré contient bien les objets demandé mais il ne sont pas >> forcément classés (ou alors, je ne sais pas avec quelle ordre de tri). >> >> Le fait d'ouvrir le fichier avec JOSM et d'enregistrer à nouveau le >> fichier >> fait que les données sont triées. Cela veut dire que JOSM lit le fichier >> et >> remet de l'ordre dans tout ça. >> >> Or, FME ne sait pas faire ça et, du coup, n'arrive pas a interpréter le >> fichier Planet brut. >> >> Du coup, je me demandais s'il n'y avait pas une option a indiquer dans la >> requête pour trier les objets (d'abord les nodes, puis les ways et enfin >> les >> relations) ? >> >> >> >> ----- >> Tony EMERY >> Administrateur OpenStreetMap.fr >> Mandataire Grand Sud-Est >> Géomaticien & chef de projets >> -- >> View this message in context: >> http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5876134.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 >> > > > _______________________________________________ > 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
