Le 23 juin 2016 à 23:03, <osm.sanspourr...@spamgourmet.com> a écrit :
> Certes comme dit Philippe, ce n'est pas forcément encore bon, pour les > relations mais par exemple tu pourras ajouter des filtres pour sortir les > associatedStreet avant ou après si ce n'est pas exactement ce que tu > cherches. > > Comme dit pas Philippe, moins tu mets de contraintes côté serveur, mieux > c'est. > Je l'ai dit aussi... En expliquant que le tri avait un cout sur le serveur et en disant que si au final ce sont les même données et que cela ne change rien au volume final, autant faire ce tri côté client... et donc soulanger le serveur d'espaces temporaires supplémentaires. J'avais abordé les quadtiles aussi, qui ont aussi un coût (bien qu'il soit faible si la base a déjà trié ses objets par quadtiles: en sortant les objets trouvés dans la base au fil de l'eau, ils seront déjà dans cet ordre, pas besoin de retrier en fait). Le tri des quadtiles cependant ne concerne que les noeuds (les chemins et relations peuvent facilement déborder des tas de quadtiles, au pire on peut les indexer en quadtile sur leur bounding-box: possible facilement pour les ways, beaucoup moins pour les relations qui dans certains cas (souvent pathogènes) sont cycliques, mais ces cycles de références mutuelles existent dans la base qui ne les interdit pas: les bounding box des relations ne sont pas toujours définies et la cloture récursive des références est très coûteuse à calculer, elle peut parfois ramener des références sur des milleirs de relations, des dizaines de milliers de chemins et des millions de noeuds.... En revanche le tri topologique a un coût raisonnable (mineur). Le tri par ID en revanche est assez stupide et ne sert à rien (il ne sert à rien pour trier les noeuds, à rien pour trier les ways, et ne résoud pas l'ordre des dépendances pour trier les relations contrairement au tri topologique. Cependant un tri topologique strict n'est pas toujours possible sur les relations à références cycliques (exemple: relation A membre de la relation B, relation B membre de la relation A). Ce cas est rare dans la base mais cela a été l'objet d'une correction dans JOSM pour éviter des récursions infinies durant le rendu (en évitant de parcourir à nouveau une relation mère d'une fois si une des sous-relations la référence en dessous) !
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
