On mercredi 3 octobre 2012, Christian Quest wrote: > Je préfère une source claire à l'aide de tags sur les objets, plutôt > que sur les changeset car l'accès est immédiat.
Je suis de cet avis dans l'état actuel des éditeurs et exports de la base, toutefois, mon avis changerais si les informations du changeset (tags, dont source=* et comment=*) étaient accessible de manière plus simple à l'utilisateur. Il avait été évoqué que, si les tags de tous les changesets, par ordre chronologiques, ayant changé un objet apparaissaient de manière clair dans les éditeurs, genre juste à coté des tags propres à l'objet, Et que des exports disons "étendus" entre les full historique et les "juste maintenant" pouvaient exister, fournissant cette information accompagnant les données. Et qu'un format "simili osm" puise exister dans lequel on puisse indiquer des tags aux changesets de sorte qu'ils ne soient pas oubliés (comme on le fait dans les fichiers bâtis et le tag source redondant) Alors oui, là, le changeset serait le bon endroit, tant en terme de place que de logique pour mettre les infos de sources tout en étant pas une contrainte de plus. Mais pour l'heure, je suis contre. > Le principe de l'id pour raccourcir la valeur est intéressant mais je > pense qu'on devrait plutôt mieux gérer le stockage des tags/valeur > dans les différentes bases de données et formats de fichiers (je pense > par exemple aux formats .o5m/.o5c qui sont une forme binaire des > formats .osm/osc qui gère très bien la redondance d'info mais > malheureusement peu utilisé bien qu'aussi compact que le pbf et plus > simple à manipuler). +1 On ne devrait pas perturber la ressource la plus importante (les contributeurs) pour résoudre un problème qui peut l'être de manière technique et complètement transparente pour l'utilisateur. <techos avis="le mien"> L'argument de la taille, récurent est à mon avis un argument de mauvaise foi, ou, tout du moins, majoritairement de mauvaise foi. Je n'ai pas fait de tests, mais les exports en .osm.bz2 dispose d'un algo de compression (bz2) qui sait réduire la taille d'une redondance, idem pour le reste. Donc le dowload "plus long" n'est à mon avis que minime. En ce qui concerne les bases type osm2pgsql, la place sur disque est sans objet car le tag source est exclue dans la majorité des cas. Seul cette histoire de passage en id 64bit au lieu de 32bit est vrai, mais les conjectures données disent que à 18mois prêt, il aurait de toute façon fallu y passer. Il reste donc le temps de traitement du xml qui peut, peut-être prendre quelques % de plus, mais comme ce traitement n'est lui même que 10% du total, c'est à mon avis peanuts au final. Pour ce qui est du reste, on parle, pour le planète, de taille de l'ordre de 300Go sur disque, et de temps d'import de dizaines d'heures sur de gros serveur. Quand on se prépare à faire ça, les à 3Go pour le cadastre, c'est de la nioniotte et il faudra de toute façon des gros disques et des gros serveur. Celui qui veut vraiment optimiser la taille, pourra toujours factoriser les tags (id relationnel) et puisqu'il le fera, il économisera autant sur les 40 Millions de fois ou les mots "residential", "unclassified", "service", "track" et "footway", ... apparaissent dans la base que pour le source cadastre </techos> -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
