[OSM-talk-fr] Fichiers bâti cadastral ( était: "Restreignons les imports des cours d'eau")

[sly (sylvain letuffe)]

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