On a l'air d'être sur une longueur d'onde plus commune :) Cependant, et ca doit aller dans le sens d'Ista Pouss, il faut trouver une solution générale et reproductible à de multiples situations. 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. Il faut partir de là et ne pas prendre les tags pour ce qu'ils ne sont pas. 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. 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.
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. 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). 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). 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. 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. Un petit exemple avec ça : http://www.infos-reseaux.com/apps/ADSLObs/dataPLayout/props/com.infosReseaux.common.networks.IPNode/?obj_id=24314 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. Le 4 janvier 2013 22:26, Philippe Verdy <verd...@wanadoo.fr> a écrit : > 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.laco...@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. > -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
