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. Bon week end à tous. Le 4 janvier 2013 19:41, Philippe Verdy <verd...@wanadoo.fr> a écrit : > Bref c'est exactement ce que je proposais plus haut qui résoud tous > les problèmes, sauf que le slide suggère l'addition de champs > start_date/end_date pour chaque attribut, ce que je trouve plutôt > redondant, on peut très bien se débrouiller avec des objets distincts, > avec juste cette parire d'attributs pour une objet. Leur idée de dater > les attributs est que pour eux il s'agit du même objet (mais l'ennui > ce sont les références depuis un autre objet : il faudrait alors dater > chaque noeud inclus dans un chemin, et chaque membre d'une relation. > > Il me semble plus propre de ne mettre qu'une paire par objet, pas pour > chacun de ses membres, et de considérer que ce sont des objets > différents, comme si c'était des couches d'une autre dimension : > > - imaginons qu'une communauté de communes référence deux communes mais > que ces communes fusionnent > - on crée une nouvelle relation pour la nouvelle commune (même si elle > conserve le même nom et même numéro INSEE, mais probablement pas le > même numéro ref:SIREN=21depCOMx qui a des incidences comptables car > les comptes de chaque entité coexistent pendant un certain temps le > temps que les transferts de responsabilité et engagements financiers > ou contractuels se terminent). > - on crée une nouvelle relation pour la nouvelle communauté de > communes puisque ses membres ont changé et sa géométrie a pu changer > - les anciennes relations de la commune et de la communauté de > communes persistent mais on leur met une date de fin de > validité.L'ancienne communauté de commune continue de référencer > l'ancienne relation : la contrainte est que les membres de la relation > de communauté de communes doivent avoir des dates de validité > totalement incluses dans la période de validité de la communauté de > communes. > > Le problème est : que faire quand il y a des incertitudes de dates, en > terme de validité référencielle ? Il faut une règle permettant une > tolérance. > Par exemple quand on a "start_date=c1890" (circa 1890) dans une objet > référent, il s'agit d'une tolérance de l'ordre de la décennie, comme > si la date de début validité du référent commençait en 1895, 5 ans > plus tart (sans aller au delà de la date indiquée en end_date) ; dans > l'objet référé la date de début de validité "c1890" est étendue 5 ans > plus tôt à partir de 1885, de sorte que la validité de l'objet > référent est entièrement incluse dans l'objet référencé. Toutefois un > validateur en mode strict fera un test de date sans tolérance et > affichera un "warning" pour vérifier si les dates sont compatibles. > > Même chose si une date mentionne une décennies sous la forme > "start_date=1890s". > > Si la date de début mentionne juste une année, on peut réduit la > tolérance à moins d'un an; si la date mentionne le mois, on réduit la > tolérance à moins d'un mois. Si la date mentionne le jour la tolérance > est de moins de quelques heures ; je ne suis pas sûr qu'il faille > prendre en compte les heures dans les champs date, mais le format > ISO8601 standard (yyyy-mm-ddThh:mi:ssZ) le permet. > > Si l'incertitude de la date de début (ou de fin) est différente, on > pourrait encore avoir start_date=1890-02-28+7d pour préciser un > intervalle d'incertitude de plus ou moins 7 jours autour de cette date > (donc ici dans 14 jours ou 15 dates). start_date=1890+2y indiquerait > une tolérance de plus ou moins 2 ans avant ou après 1890. > > L'autre solution étant de traduire directement cet intervalle de dates > en deux attributs donnant des dates précises si cela facilite les > requêtes SQL : start_date=1890-02-21..1892-03-07 et > start_date=1888..1892 pour les deux cas précédents. > > Les incertitudes de dates peuvent exister pour la date de début comme > pour la date de fin de validité (les 4 dates sont alors en ordre > croissant ; la paire à utiliser pour les tests de référence sont de > prendre le plus plus grand intervalle des dates 1 et 4 pour l'objet > référencé, et le plus petit intervalle des dates 2 et 3 pour l'objet > référent). > > Certes cela duplique les objets et les attributs, mais il est plus > simple de gérer l'intégrité référentielle au niveau de chaque objet > ayant un ID unique qu'avec un seul objet avec des attributs dont les > valeurs sont datés et deviennent des listes de valeurs. Mais des > solutions peuvent être développées pour les éditeurs qui veulent > vouloir pouvoir saisir un même objet avec des attributs (et membres de > relation) datés individuellement. Il est même possible de lier ces > objets à un objet maître liant les ID d'objets entre eux dans une > liste odonnée par date avec une relation spéciale de type "history" > comme une relation normale, sauf que les relations elles-mêmes ou > autres objets ne sont pas modifiés, il n'y a que la nouvelle relations > spéciale qui au lieu de contenir des listes d'objets quelconque > contient une liste d'ID d'objets avec chacun leurs intervalles de date > de validité au lieu du rôle (cette relation spéciale appliquant des > contraintes : les intervalles ne doivent avoir aucune intersection > hors des intervalles de tolérance). > > Bref aucune modification du schéma des objets actuels : noeuds, > chemins et relations, mais l'ajout d'une primitive "history" > permettant de lier un objet à ses dates de validité et ses versions > successives dans des ID différents. L'intégrité référencielle reste > conservée par les IDs comme actuellement, et il devient possible alors > de ne pas tout charger et travailler sur une date précise (par défaut > aujourd'hui, ou de demander à charger les autres dates et d'avoir > dfférentes vues successives d'un objet qui a changé d'état. > > Maintenant si on commence à historiser les attributs ou membres d'une > relation ou nœuds membres d'un chemin, on va se retrouver à modifier > toutes les 3 primitives et là ça risque d'être compliqué et risqué à > gérer car on aura des listes de valeurs pour chaque attribut ou > membre/rôle d'une relation, ainsi que chaque nœud d'un chemin (c'est > surtout là que le modèle va exploser, d'autant plus que ces noeuds > forment déjà une liste ordonnée et connectée qui ajoute d'autres > contraintes pour la validité géométrique). > > La solution avec des tags supplémentaires ajoutés aux objets me semble > aussi plus fragile qu'une solution utilisant une primitive > relationelle nouvelle liant les objets datés entre eux (et n'offira > pas une bonne compatibilité avec les éditeurs et entrainera des > confusions dans les données, sauf si le moteur assure que ces tags de > date sont bien réservés à cet usage, et sont stockés en interne dans > des primitives cachées, grace à une convention de nommage réservées au > tags internes spéciaux de même nature que le tag du type d'objet > node/way/relation ou du tag de l'id, renforcée par un test de > cohérence côté serveur et une indexation spéciale à part). > > 2013/1/4 Pieren <pier...@gmail.com>: > > Tout ce que vous suggérez (et plus encore) est présenté dans ce > > slideshare montré au SOTM de ... 2009: > > http://www.slideshare.net/frankieroberto/mapp-history-on-open-street-map > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > -- *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
