[OSM-talk-fr] Retrouver les contributeurs d'un tag

[Philippe Verdy]

Je "plussoie", un tri par id ne sert pas à grand chose sauf pour des
recherches par id ou pour créer une table de données à indexer sur le même
critère.
Le tri "quadtile" est nettement plus pratique et même souvent plus rapide
(quand on a fait une recherche par bbox car c'est déjà l'ordre où on
récupère nativement les données trouvées et aussi un ordre proche de
l'ordre de stockage physique dans la base si celle-ci est organisées avec
des index en "cluster" géographiques, comme c'est fait pour la base
utilisée pour le rendu afin d'augmenter les performances en réduisant
siginificativement les I/O car cela regroupe naturellement les données
d'objets proches dans beaucoup mois de pages dispersées sur disque et
indépendamment de leur date de création qui détermine l'ID qui leur a été
attribué: les IDs sont totalement dispersés).
Il n'y a pas d'option de tri personnalisé selon les colonnes personnalisées
du CSV généré. Le but d'Overpass est d'abord de fournir des données le plus
rapidement possible aux clients (sans surcharge excessive et non nécessaire
sur le serveur) à charge pour eux de trier comme ils veulent les données
obtenues: un tri sur serveur est en effet couteux en espace de stockage
temporaire car on ne peut rien retourner aux client avant d'avoir le jeu de
données complet.

Je pense même que toutes les options de tri dans Overpass (par id comme par
quadtile) devraient être supprimées pour ne retourner que les données
obtenues au fil de l'eau en fonction des meilleurs index utilisés selon la
requête ou des infos statistiques sur leur densité ou sélectivité qui peut
varier selon les régions et la quantité de mises à jour qui y ont été
faites que la requette finisee par utiliser un index plutot qu'un autre ou
faire des fusions de sous-sélections ou des accès indexés récursifs, et
quelque soit la méthode d'indexation des fusions de sous-sélections et leur
représentation interne ou la présence éventuelle de caches sur le serveur
et d'autres contraintes que le moteur SQL est seul à maîtriser (en
association avec les systèmes de fichiers utilisés et les matériels de
stockage qui fournissent aussi des statistiques de performance), et en
fonction aussi des autres usages concurrents: le but est avant tout de
répondre au plus grand nombre et ne pas privilégier un utilisateur au
détriment des autres qui se partagent la même ressource.

Je note toutefois qu'Overpass maintenant a des contraintes d'usage plus
élevées: je tombe régulièrement sur des erreurs fatales disant que j'aurait
dépassé un certain quota, qui me semble maintenant très bas, et même peut
être dépassé par une seule requête simple retournant des données peu
volumineuses et à priori très sélectives. On doit faire avec. Mais si
l'usage augmente, gérer des tris sur le serveur est une option inutile, le
tri est toujours ce qui coûte le plus cher.

Le 19 juillet 2017 à 19:47, <osm.sanspourriel at spamgourmet.com> a écrit :

> asc trie par type d'objet puis par id croissant :
>
> http://overpass-turbo.eu/s/qu0
> Évite de trier au niveau d'Overpass, le retour sera plus rapide.
> Hormis à te proposer -u pour éviter les doublons ;-), non je n'ai rien
> proposer. Même sur Windows tu as des portages de sort.
>
> N.B. : la doc dit par id croissant.
>
>
> Le 19/07/2017 à 13:22, marc marc - marc_marc_irc at hotmail.com a écrit :
>
> Le 18. 07. 17 à 23:33, osm.sanspourriel at spamgourmet.com a écrit :
>  > http://overpass-turbo.eu/s/qsd
>
> http://wiki.openstreetmap.org/wiki/FR:Overpass_API/Overpass_QL#Personnalisation_du_format_CSV
>
> Merci !
>
> J'ai également cherché la date de dernière modif
> mais je n'arrive pas à la trier.
> D'après la doc c'est le paramètre asc mais je l'utilise visiblement malhttp://overpass-turbo.eu/s/qtg
> c'est pas trop grave, un petit coup de "|sort" sous linux me l'a fait
> mais si tu as une piste, je suis preneur
> _______________________________________________
> Talk-fr mailing listTalk-fr at openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20170719/e481e42c/attachment.htm>