Ok concernant le futur qu'on ne peut pas anticiper réellement avant que ces recours légaux soient achevés. La réforme des collectivités est un chantier qui dure depuis des années et ne se terminera pas non plus aux prochaines élections.
En revanche le maintien de la continuité statistique des limites territoriales pour ce qui est du passé récent (10 ans ce n'est pas trop) est un "must-have" sur lequel OSM refuse encode de prendre ça en charge, alors que ça concerne une partie infinitisémale des données: n'importe quelle commune de plus de 5000 habitants accumule sur son propre territoire beaucoup plus de données que l'ensemble des limites territoriales existantes. Et sur une échelle de temps de 10 ans (la durée que je suggère de conserver, et qui devrait suffire pour faire n'importe quelle trnasition tout en douceur sans avoir à gérer ça dans l'urgence, ni sacrifier la continuité statitique, ni interdire les corrections dans des archives qui ne sont ensuite plus maintenues du tout faute de données à la source), chaque collectivité ne connait tout au plus qu'un (peut-être deux) réformes de ses limites territoriales, et c'est une minorité d'entre elles. Ce ne sont pas nos quelques centaines de cantons qui vont changer la volumétrie de la base ou ajouter de la complexité réelle à son utilisation si on y ajoute des "start_date" et "end_date" pour distinguer plusieurs versions de leur découpage ! Le Luxembourg par exemple (et d'autres pays) continue à préserver ses découpages passés il y a plusieurs années et ça ne le gène pas du tout, quand le gros du travail est en fait ailleurs et beaucoup plus local, allant jusqu'au micromapping. Il est temps de voir qu'on n'a aucune raison de limiter ce qui est une base de données ouverte à cause de quelques rendus qu'il est facile de corriger pour qu'ils sachent tenir compte des champs start_date et end_date (ou d'autres attributs de classification s'ils sont nécessaires): on l'a fait pour des tas d'autres objets **beaucoup** plus nombreux et disséminés dans la base (par exemple les "building"; les "landuse"; les routes, etc. ainsi que la toponymie et les divers numéros de référence.) Le 21 février 2014 20:30, lenny <lenny.li...@orange.fr> a écrit : > > Le 20/02/2014 10:07, Vincent de Château-Thierry a écrit : > > Bonjour, >> >> Le 20/02/2014 09:36, Christian Quest a écrit : >> >>> >>> Le 20 février 2014 09:21, Damouns <damo...@gmail.com >>> <mailto:damo...@gmail.com>> a écrit : >>> >>> Il est toujours possible de sauvegarder l'état actuel ailleurs (je >>> l'ai fait pour l'Isère) pour pouvoir faire des comparaisons etc. >>> >>> >>> Autant sauvegarder ça dans OSM... >>> >>> Les découpages servent souvent à représenter des données statistiques, >>> donc souvent non actuelles et pour cela si on n'a pas les découpages >>> correspondants OSM ne sert à rien. >>> Ca coûte quoi de garder quelques relations ? >>> >> >> Euh, on marche sur la tête, non ? >> Supprimer des découpages actuels au prétexte qu'ils ne sont pas complets, >> et les remplacer par d'autres qui ne seront effectifs que dans un an... >> Je rejoins la première proposition de Christian : on ne touche pas à >> l'existant, tout simplement car il représente la réalité des découpages à >> aujourd'hui. Et si on veut anticiper un peu, on trouve un formalisme pour >> définir les _futurs_ cantons avec des tags non ambigus : nouveaux tags, ou >> tag start_date=*, etc. On peut aussi ajouter des end_date=* sur les actuels >> voués à disparaître. >> Le jour de la bascule, on a un moyen simple, grâce à la différence de >> formalisme, pour passer les actuels en anciens, et les futurs en actuels. >> On pourra aussi sortir les obsolètes de la base, mais en les archivant sur >> data.gouv.fr par exemple (personnellement je préfère ça à la >> conservation en base, mais on n'en est pas là). >> >> + 1 pour ne pas toucher l'existant, d'autant plus qu'il y a un certain > nombre de recours en annulation de décret on été faits devant le Conseil > d'État. > > Lenny > > > _______________________________________________ > 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
