Ces découpage de cantons ne sont pas que électoraux, ils entrent aussi dans la législation; notamment pour l'urbanisme, l'environnement, les catastrophes naturelles, les zones de compétence des services publics comme la justice. Ils ont des tas de références et tellement d'usages (même si souvent les conmunes découpées en fractions cantonales sont listées part des autres cantons ou du reste des cantons découpés ne comprenant que les communes entières). Ces données sont des briques essentielles aussi pour les données statistiques, et les statistiques imposent aussi une continuité temporelle pour permettre au moins des un rapprochement comparatif d'une année à l'autre. Bref ne garder QUE le dernier découpage est un non sens, même en terme de base de données (d'autant plus qu'ils ne sont pas si nombreux et volumineux que ça dans la base si on compare à tout le reste). Bref je suis très favorable à la conservation dans OSM des historiques; pendant un moins 5 ans ou un peu plus (le temps d'une législature). On a les outils pour ça : start_date et end_date. En plus ça permet des transitions tout en douceur pour les données à venir déjà connues mais pas encore effectives sans avoir à subir le "big bang" qui perturbera n'importe quel utilisateur de ces données. Si vous ne voulez garder que l'existant à un instant T, non seulement on ne sera jamais synchrone, mais en plus on sera trop incomplet et alors autant ne plus rien mettre du tout car ces données parcellaires qui changent du jour au lendemain sans aucun contrôle qualité préalable sont inutilisables. Supprimer ces données "obsolètes" est aussi un mauvais service à la communauté: qui vous dit que ces données ne sont plus utiles du tout ? Rien que pour les statistiques on a besoin de les garder d'une années à l'autre: Personnellement je ne supprimerais rien du tout à moins de 10 ans (ce qui n'exclue pas de pouvoir publier des extraits séparés archivés année par année (années d'effets, pas années d'archivage car ces données sont encore corrigeables)
Le 20 février 2014 10:21, Pieren <pier...@gmail.com> a écrit : > Ces découpages électoraux changent trop souvent (à chaque > législature). On peut même se demander si leur présence dans OSM est > opportune. Je m'y suis longtemps opposé pour cette raison. Personne ne > se demande s'il faut garder l'ancien découpage d'une commune ou d'un > département. Et lorsqu'ils y a des changements, ils sont limités et il > ne faut pas une équipe de 10 personnes pour préparer la transition un > an à l'avance tellement il y a de travail... > Je ne vais sans doute pas interférer dans vos contributions sur ce > sujet mais je voudrais cependant rappeler certains principes de base > largement répandus dans OSM : > - "one feature, one OSM element". Il n'y pas concevable qu'un même > canton soit représenté deux fois dans OSM, même avec des "start_date" > pas suffisament discriminants. > - on mappe le présent. Les données historiques vont dans une base > séparée. Les "start_date", "end_date" sont au mieux supportés par > quelques utilisateurs, au pire ignorés par la plupart des autres "data > consumer" qui verront donc plusieurs fois les mêmes entités. Les > objets qui disparaissent physiquement sont simplement supprimés de la > base (en fait, ils sont encore là mais invisibles). OSM conserve ses > anciens fichiers planet pour archivage et ceux que ça intéresse. > - les objets "futurs", "plannifiés" ou "désaffectés" ont des tags > spécifiques suffisament discrimant pour ne pas être confondus avec les > éléments actifs aujourd'hui. C'est pour cette raison que le tag > "disused=yes", par exemple, a été remplacé par le préfixe "disused:" > comme "disused:amenity=parking". Ou qu'une route en construction est > toujours "highway=construction" (ou "proposed"), quel que soit la > catégorie de route, "motorway" ou "residential". > Si vous voulez préparer la transition, faites-le avec des tags > suffisamment discrimant pour ne pas être confondus avec les données > actuelles. Quelque chose comme, par exemple, > "planned:boundary=political". Avec une note quelque part dans le wiki > pour l'expliquer, bien entendu. > > Pieren > > _______________________________________________ > 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
