On a l'air d'être sur une longueur d'onde plus commune :)<br><br>Cependant, et ca doit aller dans le sens d'Ista Pouss, il faut trouver une solution générale et reproductible à de multiples situations.<br>Pour toute primitive, hormis les champs id, version, changeset, user, éventuellement les dates, tout n'est que donnée. Si il y a une modification => une nouvelle version est créée.<br>
Il faut partir de là et ne pas prendre les tags pour ce qu'ils ne sont pas.<br>Les sources, les noms, comme les informations terrain, restent des données pour la base et l'API. Il n'y a pas de raison d'établir des critères dessus pour gérer non seulement les versions et par extension le système d'historique.<br>
Un objet (chaque version d'une primitive) est atomique et on ne peut pas le morceler. Sinon on ne peut pas s'assurer correctement de l'intégrité et de la "requêtabilité" du bazar.<br><br>Si le système est suffisamment général, qui peut le plus peut le moins, on pourra adopter certains fonctionnements qui sont propres aux cas particuliers soulevés ici.<br>
Sinon ca va marcher, mais il faudra faire de constantes adaptations pour aller toujours plus loin dans le détail (vu le potentiel d'une communauté comme celle d'OSM).<br><br>Et quelque chose de tout à fait intéressant dans ce que dit Philippe est que lorsque l'on prononce l'archivage d'un objet, toutes les versions intermédiaires qui le constituent jusque là sont "regroupées" en une seule (ça a sa limite : un tel archivage ne peut pas être annulé au delà de la dernière version connue).<br>
<br><br>Enfin c'est ma vision des choses, j'ai implémenté un tel système directement sous la forme d'un ORM et certaines de ces problématiques se sont présentées.<br>La leçon que j'en tire c'est qu'il faut s'abstenir de donner aux champs un sens particulier. Il en faut un minimum (id, changeset, version...) et gérer le reste de manière transparente.<br>
<br>Un petit exemple avec ça : <a href="http://www.infos-reseaux.com/apps/ADSLObs/dataPLayout/props/com.infosReseaux.common.networks.IPNode/?obj_id=24314">http://www.infos-reseaux.com/apps/ADSLObs/dataPLayout/props/com.infosReseaux.common.networks.IPNode/?obj_id=24314</a><br>
<br>Pour les dates j'aime bien les timestamp unix en secondes. Ca permet de traiter des entiers plutôt que des chaines de texte mais après c'est très personnel.<br><br><br><div class="gmail_quote">Le 4 janvier 2013 22:26, Philippe Verdy <span dir="ltr"><<a href="mailto:verdy_p@wanadoo.fr" target="_blank">verdy_p@wanadoo.fr</a>></span> a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A mon avis la création d'une version historique ne va pas entrainer<br>
une profusion de données. Le plus gros des modifs de versions est dans<br>
la branche principale (celle de la version actuelle, et cela restera<br>
celle qui sera le plus contribuée. A un instant donnée on ne crée un<br>
objet historique que pour conserver une de ces versions à peu près<br>
stable. D'autant plus qu'on peut faire en sorte que l'éditeur par<br>
défaut ne charge pas ces objets historiques sauf si on en fait la<br>
demande explicitement.<br>
<br>
Je suis d'accord avec toi que mettre cela dans des tags standards<br>
n'est pas la bonne solution et qu'il vaut mieux une primitive séparée<br>
pour créer une méta-relation listant les objets liés à un même<br>
intervalle historique daté. Un même id d'objet ne doit servir qu'à un<br>
seul intervalle de validité de date, cet objet pouvant être chargé ou<br>
pas (mais pas par défaut par l'API quant on ne précise pas une date de<br>
validité ou qu'on ne précise pas un intervalle de date à rechercher ou<br>
pas de requête pour charger toutes les dates.<br>
<br>
Ce sera d'autant plus important que pour les versions historiques, se<br>
posera la question des sources différentes, et de droits intellectuels<br>
distincts, des problèmes de licences distinctes.<br>
<br>
Imaginons ensuite qu'on veuille créer une nouvelle version historique<br>
d'un objet actuel pour en garder une archive datée, on devrait avoir<br>
un bouton permettant d'ajouter cette version en mentionnant seulement<br>
la date de fin de l'objet actuel et de début du nouvel objet. Les deux<br>
objets sont alors soumis au serveur. L'ancien objet change de statut<br>
(il est modifié) ce qui oblige les autres éditeurs à en tenir compte<br>
comme une modif puisque l'ancien objet sera versionné comme une modif<br>
standard. Mais il deviendra invisible ensuite pour ceux qui chargent<br>
les objets référents ou la zone : ils obtiendront le nouvel objet à la<br>
place, mais en chargeant l'objet, le serveur peut aussi indiquer que<br>
cet objet dispose de versions datées différentes et permettre<br>
d'effectuer une requête pour charger ces autres versions datées à la<br>
demande.<br>
<br>
Dans JOSM on aurait alors en dessous de la liste des attributs ou<br>
membres une autre liste en table mentionnant une liste d'autres IDs<br>
d'objets de même nature de primitive (noeud/chemin/relation), avec 3<br>
colonnes : ID des autres objets, date de début, date de fin, cette<br>
liste étant ordonnée et mettant en gras la version actuelle dont les<br>
attributs et membres sont affichés. Si on clique une des lignes de<br>
cette table, on sélectionne le nouvel objet. On doit aussi pouvoir<br>
sélectionner plusieurs lignes pour effectuer ou pas des fusions<br>
d'attributs ou membres communs.<br>
<br>
Ce sera un peu plus compliqué pour les noeuds membres d'un chemin car<br>
ils sont ordonnés et connectés : il peut y avoir des noeuds communs<br>
entre deux versions d'un chemin, ou bien tous les noeuds différents,<br>
ou tous identiques, les chemins ne différent que par les attributs<br>
voire sans aucune autre différence que les dates de validité (par<br>
exemple quand deux anciens chemin pour une zone ont été fusionnés puis<br>
rescindés à nouveau, ou quand une ligne de transport est aménagée<br>
pendant un certain temps différemment, puis restaurée à son ancien<br>
état, ou quand deux communes fusionnent pendant un certain temps puis<br>
se reséparent, la commune ayant cessé d'exister de façon autonome<br>
pendant une période donnée ; cependant je pense qu'il sera rare que la<br>
restauration soit totalement à l'identique, sauf si la version<br>
intermédiaire n'était que temporaire pour durer que quelques mois ou<br>
moins de 2 ou 3 ans ; mais là tout est possible, et il est probable<br>
que l'ancienne version ne corresponde pas exactement à ce qu(on trouve<br>
à l'heure actuelle et que celle-ci de toute façon conservera un ID<br>
séparé demandant des corrections et contributions distinctes à ne pas<br>
apporter à la version actuelle).<br>
<br>
Il est aussi très probable que les anciennes versions n'aient pas le<br>
niveau de précision géométrique des versions actuelles : la Terre<br>
bouge, les rivières bougent, les terrains bougent, il y a des<br>
inondations, des glissements de terrain, des arrangements légaux pour<br>
certaines parties, des échanges de parcelles qui ne feront pas l'objet<br>
de retour en arrière.<br>
<br>
Le 4 janvier 2013 20:55, François Lacombe<br>
<<a href="mailto:francois.lacombe@telecom-bretagne.eu">francois.lacombe@telecom-bretagne.eu</a>> a écrit :<br>
<div class="HOEnZb"><div class="h5">> Même après avoir lu les slides, m'est avis qu'il vaut mieux gérer ça au<br>
> niveau de la primitive plutôt que ses tags...<br>
> Le tags sont des données particulières de la primitive, gérer un historique<br>
> à ce niveau c'est se condamner à devoir le refaire pour toute autre donnée<br>
> rattachée à l'objet.<br>
><br>
> Qu'on appelle ça une version ou autre chose, c'est nettement plus navigable<br>
> et manipulable que d'avoir à parser des chaines de texte pour faire une<br>
> sélection.<br>
> La version a le mérite de relier logiquement plusieurs historiques du même<br>
> objet sans avoir à créer une liaison "history" justement.<br>
> Dans ce cas on aurait un entier supplémentaire au lieu d'une table avec<br>
> plusieurs entiers nécessaires.<br>
><br>
> Ce qui m'interpelle aussi, c'est que la problématique du nombre<br>
> "gigantesque" d'enregistrements que cela va entrainer ressorte alors que<br>
> moult versions obsolètes (tant sur le terrain que pour d'éventuels reverts)<br>
> sont conservées par ailleurs.<br>
> D'expérience je créé des "vues" restreintes sur les enregistrements actuels<br>
> (plus peut-être à d'autres points de temps fortement fréquentés) pour<br>
> obtenir non seulement une vision actuelle et un accès direct aux<br>
> historiques.<br>
><br>
> Concernant les liaisons entre primitives, une référence aux objets logiques<br>
> (dont le numéro ne change jamais au cours du temps) consolidées par les<br>
> dates de part & d'autre pour connaitre la bonne version à utiliser<br>
> fonctionnerait.<br>
> Ceci à condition de restreindre la conservation d'un objet à sa stricte<br>
> existence... on revient à la question philosophique des slides.<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><b>François Lacombe</b><br><br>francois dot lacombe At telecom-bretagne dot eu<br><a href="http://www.infos-reseaux.com" target="_blank">http://www.infos-reseaux.com</a><br>