A mon avis la création d'une version historique ne va pas entrainer une profusion de données. Le plus gros des modifs de versions est dans la branche principale (celle de la version actuelle, et cela restera celle qui sera le plus contribuée. A un instant donnée on ne crée un objet historique que pour conserver une de ces versions à peu près stable. D'autant plus qu'on peut faire en sorte que l'éditeur par défaut ne charge pas ces objets historiques sauf si on en fait la demande explicitement.
Je suis d'accord avec toi que mettre cela dans des tags standards n'est pas la bonne solution et qu'il vaut mieux une primitive séparée pour créer une méta-relation listant les objets liés à un même intervalle historique daté. Un même id d'objet ne doit servir qu'à un seul intervalle de validité de date, cet objet pouvant être chargé ou pas (mais pas par défaut par l'API quant on ne précise pas une date de validité ou qu'on ne précise pas un intervalle de date à rechercher ou pas de requête pour charger toutes les dates. Ce sera d'autant plus important que pour les versions historiques, se posera la question des sources différentes, et de droits intellectuels distincts, des problèmes de licences distinctes. Imaginons ensuite qu'on veuille créer une nouvelle version historique d'un objet actuel pour en garder une archive datée, on devrait avoir un bouton permettant d'ajouter cette version en mentionnant seulement la date de fin de l'objet actuel et de début du nouvel objet. Les deux objets sont alors soumis au serveur. L'ancien objet change de statut (il est modifié) ce qui oblige les autres éditeurs à en tenir compte comme une modif puisque l'ancien objet sera versionné comme une modif standard. Mais il deviendra invisible ensuite pour ceux qui chargent les objets référents ou la zone : ils obtiendront le nouvel objet à la place, mais en chargeant l'objet, le serveur peut aussi indiquer que cet objet dispose de versions datées différentes et permettre d'effectuer une requête pour charger ces autres versions datées à la demande. Dans JOSM on aurait alors en dessous de la liste des attributs ou membres une autre liste en table mentionnant une liste d'autres IDs d'objets de même nature de primitive (noeud/chemin/relation), avec 3 colonnes : ID des autres objets, date de début, date de fin, cette liste étant ordonnée et mettant en gras la version actuelle dont les attributs et membres sont affichés. Si on clique une des lignes de cette table, on sélectionne le nouvel objet. On doit aussi pouvoir sélectionner plusieurs lignes pour effectuer ou pas des fusions d'attributs ou membres communs. Ce sera un peu plus compliqué pour les noeuds membres d'un chemin car ils sont ordonnés et connectés : il peut y avoir des noeuds communs entre deux versions d'un chemin, ou bien tous les noeuds différents, ou tous identiques, les chemins ne différent que par les attributs voire sans aucune autre différence que les dates de validité (par exemple quand deux anciens chemin pour une zone ont été fusionnés puis rescindés à nouveau, ou quand une ligne de transport est aménagée pendant un certain temps différemment, puis restaurée à son ancien état, ou quand deux communes fusionnent pendant un certain temps puis se reséparent, la commune ayant cessé d'exister de façon autonome pendant une période donnée ; cependant je pense qu'il sera rare que la restauration soit totalement à l'identique, sauf si la version intermédiaire n'était que temporaire pour durer que quelques mois ou moins de 2 ou 3 ans ; mais là tout est possible, et il est probable que l'ancienne version ne corresponde pas exactement à ce qu(on trouve à l'heure actuelle et que celle-ci de toute façon conservera un ID séparé demandant des corrections et contributions distinctes à ne pas apporter à la version actuelle). Il est aussi très probable que les anciennes versions n'aient pas le niveau de précision géométrique des versions actuelles : la Terre bouge, les rivières bougent, les terrains bougent, il y a des inondations, des glissements de terrain, des arrangements légaux pour certaines parties, des échanges de parcelles qui ne feront pas l'objet de retour en arrière. Le 4 janvier 2013 20:55, François Lacombe <[email protected]> a écrit : > Même après avoir lu les slides, m'est avis qu'il vaut mieux gérer ça au > niveau de la primitive plutôt que ses tags... > Le tags sont des données particulières de la primitive, gérer un historique > à ce niveau c'est se condamner à devoir le refaire pour toute autre donnée > rattachée à l'objet. > > Qu'on appelle ça une version ou autre chose, c'est nettement plus navigable > et manipulable que d'avoir à parser des chaines de texte pour faire une > sélection. > La version a le mérite de relier logiquement plusieurs historiques du même > objet sans avoir à créer une liaison "history" justement. > Dans ce cas on aurait un entier supplémentaire au lieu d'une table avec > plusieurs entiers nécessaires. > > Ce qui m'interpelle aussi, c'est que la problématique du nombre > "gigantesque" d'enregistrements que cela va entrainer ressorte alors que > moult versions obsolètes (tant sur le terrain que pour d'éventuels reverts) > sont conservées par ailleurs. > D'expérience je créé des "vues" restreintes sur les enregistrements actuels > (plus peut-être à d'autres points de temps fortement fréquentés) pour > obtenir non seulement une vision actuelle et un accès direct aux > historiques. > > Concernant les liaisons entre primitives, une référence aux objets logiques > (dont le numéro ne change jamais au cours du temps) consolidées par les > dates de part & d'autre pour connaitre la bonne version à utiliser > fonctionnerait. > Ceci à condition de restreindre la conservation d'un objet à sa stricte > existence... on revient à la question philosophique des slides. _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
