Le 22 octobre 2012 13:20, sly (sylvain letuffe) <li...@letuffe.org> a écrit : >> La >> validité du tag source dans OSM sera toujours sujette à caution, quel >> que soit l'endroit où on le stocke. > Je ne peux rien répondre à ça, si ce n'est que c'est aussi le cas pour > absolument tout ce qui se trouve dans OSM, où que ce soit : "c'est sujet à > caution"
Certes, mais la validité sera encore pire si on le stocke dans l'objet, car cette information va s'appliquer automatiquement à toutes les versions suivantes et toutes les autres modifications faites à l'objet, dont pourtant les sources n'ont rien à voir avec la source initiale. Si on veut être précis, la source ne concerne QUE chaque modification entre deux versions d'un même objet. Autrement dit cette source n'est pas non plus l'utilisateur lui-même, mais c'est bien un attribut du changeset, dans lequel le contributeur qui le soumet devra mentionner les sources utilisées au delà de son propre travail personnel sur ces données, où le contributeur est implicitement aussi une source). Si je prend un exemple : on utilise le cadastre une année pour importer un bâtiment. Il est source de ce tracé. Plus tard, le bâtiment est entièrement modifié pourtant la source lui survit dans l'objet ou dans certaines de ses versions historiques, mais on met alors la nouvelle source. Plus tard encore, le cadastre est réutilisé dans un nouveau millésime (parfois le même) et redéfinit à nouveau la plupart des caractéristiques de l'objet : comment doit-on interpréter les différentes sources entre les versions successives ? Evidemment la seule interprétation possible c'est version par version. Le changeset est le seul lieu approprié pour mettre les infos spécifiques à chaque version. La base de données reste interrogeable objet par ojet pour voir la liste des versions, et pour chacune le changeset concerné qui mentionne la ou les sources utilisées et qui permet aussi de ce qui est ajouté, modifié ou supprimé par rapport à la version précédente par l'utilisateur qui l'a soumis (cet utilisateur s'ajoutant aux autres sources qu'il indique dans son changeset). S'il faut continuer sur cette voie, il faudra automatiser et systématiser d'avantage dans les éditeurs le renseignement des changeset afin que ces sources puissent être facilement indiquées (par des simple cases à cocher, ou automatiquement si on utilise certaines couches visibles dans l'éditeur à l'endroit où l'objet était modifié dans sa géométrie, mais ce ne sera pas automatique pour les tags textuels dont la source n'a le plus souvent rien à voir avec celle des autres fonds de carte utilisés : les éditeurs devraient alors pouvoir inclure un petit onglet de navigation web, mémorisant les URLs ou domaines visitées, afin de permettre un copier-coller éventuel depuis cet onglet, si la source web est autorisée comme source libre pour ces éléments textuels, de même l'utilisateur devrait avoir dans son carnet perso de sources une liste de sources qu'il lui suffit d'activer d'un clic pour que cela figure dans les propriétés du changeset qu'il va soumettre). Chaque changeset contiendra donc une liste de sources (de même qu'il contient déjà le nom de l'utilisateur), uniquement celles concernées par la modification. Les autres sources des parties non modifiées ou des anciennes versions persistent dans la base dans les changesets associés aux versions dans lesquelles sont apparues les données. Cette liste de sources est facilement intérrogeable, mais si on veut faciliter leur affichage, on peut développer dans l'API un type de requête simple permettant de les avoir de façon exhautives pour toutes les données et attributs d'un objet qui sont encore visibles, simplement en groupant ces données visibles par changeset, en ordre antéchronologique où elles sont apparues, le serveur alors générant dans ses résultats une liste de versions pertinentes d'un objet, où celle-ci mentionne les sources du changeset associé). _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr