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
