Le 5 décembre 2013 12:15, Pieren <pier...@gmail.com> a écrit : > Je suis contre le maintien d'anciennes limites administratives, même > avec un admin_level farfelu. On peut toujours récupérer d'anciennes > données dans la base. Si ça n'est pas trivial, surtout pour des > relations, le plus simple serait des dump à intervalle régulier > (tient, ça me rappelle les fichiers "planet"). > Je pense qu'un principe largement partagé autour d'OSM est que la base > reflète la géographie "actuelle". Ce qui fait par exemple qu'on pousse > les données "historiques" (routes romaines, ancien bâti, etc) dans des > projets parallèles. Si on conserve d'anciennes limites disparues > depuis 5 ou 10 ans, pourquoi refuser celles qui auraient disparu > depuis 100 ou 1000 ans ? >
Pas du tout d'accord avec toi, car vouloir refléter la géographie "actuelle" sera totalement illusoire et irréalisable. Je ne demande pas qu'on maintienne des historiques très longtemps mais juste d'assurer une transition permettant la compatibilité avec d'autres sources de références "actuelles", avec un délai raisonnable pour la transition (2 ans me parait suffisant). Car même les administrations officielles françaises ne font pas les transitions toutes en même temps et de façon immédiate alors que ces modifs s'imposent. L'Insee d'ailleurs s'oblige elle-même à assurer cette transition pour permettre la continuité statistique. Sinon on ne peut plus rien comparer d'une année sur l'autre. Garder des relations administratives qui ont changé pendant 2 ans ne représentera presque rien dans la base car 2 ans reste assez court pour permettre le ménage presque partout. Et cela permet d'être prêt aussi le jour J lors d'un changement officiellement annoncé (comme ceux du 1er janvier 2014 : on peut être prêt le jour J à zéro heure sans avoir à envoyer tout un tas de modifs à minuit et donc faciliter le travail de suivi. Bref il vaut mieux une transition en douceur permettant à tout le monde de se synchroniser dans un délai raisonnable qui leur est déjà imposé (les changements du 1er janvier 2014 ont 6 mois pour s'imposer dans les administrations, même si légalement (au cas où cela irait en justice pour prendre une décision contraignante) la date de bascule s'impose à l'heure dite à tout le monde, il est irréaliste que tout le monde disposera des mises à jour des différentes bases de données utilisées. Je suis donc totalement contre ta stratégie de "Big Bang" qui ne marchera en fait JAMAIS sur OSM : on n'est tout bonnement pas capable de la réaliser avec nos bénévoles sur leur temps libre, même ceux les plus assidus. Si on le pouvait, on n'aurait pas non plus des pannes sur les serveurs qui peuvent durer des semaines, et OSM proposerait une garantie contractuelle de service (par exemple en 4h après incident, généralement c'est une option assez chère comme pour les abonnements internet pro d'OVH). On le sait, une telle garantie de service continu avec des délais très courts implique une grosse obligation de moyens, et a un coût non négligeable qu'il sera impossible de réaliser sans rendre OSM payant avec un abonnement, et aussi sans transformer OSM en un service propriétaire et fermé (pire que Google Maps alors, car lui au moins il est gratuit pour bon nombre d'usages, mais donc aussi sans garantie de service continu) ! Franchement, on se complique la vie sans obtenir aucun bénéfice (on n'a QUE des inconvénients) à ne vouloir accepter aucun historique minimum mais facilement utilisable (les historiques OSM sont inutilisables sauf pour faire du revert rapidement (des délais trop courts en fait, qui fragilisent la base de données : on sait les ressources de calcul que cela demande pour les analyser, on l'a vu lors du changement de licence qui a demandé des années de préparation et des mois de correction après tellement cela entraînait d'incohérences), alors que cela représentera une infime partie des données et que c'est facilement gérable (sur des objets séparés) pour expliquer et résoudre des différences entre dates de références de diverses bases de données utilisées comparativement pour les tests de qualité.
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
