Les versions d'objets ne sont pas satisfaisantes. Elles traitent toutes sortes de situations de modifications ou suppression/scission/fusions d'objets, parfois aussi des reverts, ou des modifs annulées ou rendues invisibles par un problème d'incompatibilité de licences ou de violation de droits.
La date de ces modifications n'a rien à voir avec la validité historique de ces objets. On ne pourrait donc pas se passer des tags pour mentionner les fates de validité des données historiques. Quelque chose comme historic:start=yyyy-mm-dd" et "historic:end=yyyy-mm-dd". Mais on doit alors toruver un moyen clair de les cacher automatiquement et facilement pour un rendu actuel avec "hidden=historic" pour qu'il n'y ait pas de confusion avec les objets actuels. A mon avis ces données historiques devraient être clairement accessibles uniquement avec une requête spécifique qui les demande, et masquées automatiquement par l'API standard, sinon on n'évitera pas une base de données séparée, car ces données peuvent être très perturbantes pour plein d'outils. Il faudrait donc que l'API permette de faire non pas une suppression simple, mais permette de transformer un objet en objet historique, gardé par la base mais non accédé par défaut. L'autre problème à régler est l'intégrité référentielle (des membres de relation ou des noeuds de chamin) si on masque ces données historiques, et l'intégrité géométrique (si des noeuds ont été déplacés sans être effacés ou gardés à part dans l'historiques sous un ID différent, masqué par défaut). Tout cela mériterait une réflexion générale sur le schéma et sur la possibilité de le rendre compatible avec un déploiement employant des bases de données "parallèles" (pour ne pas surcharger trop non plus la base principale), et ne pas trop compliquer non plus le travail pour les nouveaux contributeurs qui seront tentés de supprimer des objets qui n'existent plus ou bien ne sont plus au même endroit. La solution des versions d'objets n'est pas adaptée à ces usages pour produire des cartes historiques. Je pense que cela devrait se faire dans une base d'un projet séparé. Ce sera bien quand les éditeurs sauront travailler sur plusieurs bases en même temps, dans des calques séparés (sans fusion possible de l'un vers l'autre, uniquement des copies d'une base vers l'autre mais pas nécessairement avec les mêmes id's, mais avec une possibilité d'un objet d'une base de référencer des objets d'une autre base via les ref:*=*). Le 4 janvier 2013 15:06, François Lacombe <francois.laco...@telecom-bretagne.eu> a écrit : > Bonjour, > > Je suis plutôt pour conserver un historique en effet. > > Par contre non pas l’implanter dans les tags, il est possible d'utiliser les > versions. > Ces dernières ont déjà une dimension temporelle, plus temporelle que les > tags par exemple. > > Le problème est qu'on ne sait pour l'instant pas si le passage d'une version > à l'autre reflète une modification de la carte uniquement ou une édition > suite à une modification du terrain. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
