[OSM-talk-fr] Données historique et historiques des données...

[Philippe Verdy]

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
<francois.lacombe at telecom-bretagne.eu> 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.