Pour moi, l'idée serait que tout ce qui est téléchargé depuis une base donnée l'est uniquement dans son propre calque (mentionnant sa source), ce calqué étant toujours en lecture seule, alors que tout ce qu'on crée ou modifie cas dans un calque séparé.
Les calques sont alors comparables. En cas de conflits d'édition, les données venant de la base sont mises à jour dans le calque en lecture seule, rien n'est mis dans notre calque. De même on doit pouvoir séparer la sauvegarde locale de ces calques: les données en lecture seule vont dans un fichier cache, mais rien n'y est sauvé concernant nos données créées modifiiées. Un autre fichier est utilisé pour nos données créées ou modifiées, ce ficier contenant une référence éventuelle (pas nécessaire) au fichier de cache. Si on charge notre fichier en cours de modification, il peut toujours régénérer à tout moment le fichier de cache du calque en lecture seule. Ainsi, on pourrait travailler avec plusieurs bases simultanément: chaque base ayant son calque en lecture seule. Puisque ce sont des calques séparés, les comparaisons sont possibles. Et si les bases mentionnent des licences permettant un import compatible, on peut transférer dans l'éditeur automatiquement les données d'un calque vers notre calque de modification (qui contient la référence du calque d'origtine de chaque objet). Mais pour faire ça, il faut que la référence d'un objet (son identifiant unique) soit distingué calque par calque: les identifiants uniques utilisés dans une base ne sont pas les mêmes que les idnetifiants uniques dans une autre, meˆme si c'est le même objet. De même les identifiants uniques locaux créés par nos objets crées ou modifiés, n'ont rien à voir avec les identifiants des calques d'origine. Pour gérer cela, il sufffirait que notre cache local de modification contienne pour chaque objet un tag spécial mentionnant une liste d'identifiants, un pour chaque base d'origine). Gérer les conflits se fait alors sur la carte directement, en comparant les calques. Et non plus dans une liste d'objets très difficile à interpréter (cette liste ne permet pas réellement de comparer les géométries, uniquement les valeurs d'attributs; les références des membres de relation sont trop difficiles aussi à vériifier). Pire: dans JOSM il est impsosible de sauvegarder des modifs en cours tant qu'il y a des conflits. Si on ne fait et qu'on recharge le fichier, on aboutit à des incohérences graves (plus des tonnes de bogues tels que des pointeurs nuls, ou références introuvables, ou des chemins sans noeuds, relations sans membres) et encore plus de conflits ensuite lors d'une tentative de sauvegarde. Le problème vient en fait du format des fichiers OSM. Il y manque pour chaque objet (noeud, relation, chemin) un sous-élément contenant une liste des identifiants externes, indiquant l'origine réelle d'un objet qui aurait été modifié ou importé aussi dans une autre base, sous forme d'une courte URN (par exemple en XML, cela peut être un court préfixe de namespace attribué symboliquement, suivi d'un ":", suivi de la valeur de l'identifiant externe, le namespace étant défini par un autre objet dans l'entête du fichier OSM pour l'associer à l'URL de la source avec éventuellement aussi des notes personnelles librement modifiables tels qu'une liste de tâches à faire avec cette source). Pour l'instant on mentionne les identifiants externes (par exemple les CLC_ID de la base Corine, ou les autres identifiants venant de divers bases GIS, au format OSM ou non) en tant qu'attributs, mais à mon avis c'est une erreur et ça pollue en fait les attributs, et il n'y a pas de garantie de conserver les sources comme l'impose les licences: ces identifiants externes ne sont PAS librement modifiables et ne devraient être supprimables non plus dans JOSM. En utilisant des calques séparés poru chauqe source (qu'on peut visualiser ensemble par transparence ou alternativement), plus besoin de la liste des conflits: c'est un calque calculé automatiquement (lui aussi non modifiable) qui permet d'afficher un fitlre de comparaison pour recolorer certains objets en rouge ou d'entourer les noeuds en jaune. Dès qu'on touche au calque de travail sur un objet en conflit, le calque de conflits se remet à jour tout seul (il faut un calque de conflit par base d'origne, donc si on veut synchroniser avec deux bases différentes, cela ferait 5 calques en tout (les 2 calques de cache en lecture seule, notre calque de travail, et les deux calques calculés automatiquement des conflits entre notre claque et les bases qu'on voulait synchroniser). Pour cimplifier l'interface, au lieu d'avoir 5 calques listés, on pourrait n'en lister que 3 (mais les deux calques des caches en lecture seule aurait un petit menu déroulant contextuel avec des cases à cocher, indiquant les comparaisons à faire entre ce calque et un des autres calques, pour que soit marqué en rouge ou entouré ceux des objets du calque courant à mettre en avant, ou pour masquer ou atténuer la visibilité les autres objets de ce calque en lecture seule qui ne sont pas en conflit, et pour rendre ces objets masqués non sélectionnables par un clic sur la carte). La "résolution des conflits" n'est alors qu'une opération permettant, d'un simple clique sur la carte, d'afficher les versions d'un calque et d'un autre simultanément. Chaque calque est visionnable et navigable séparément, un seul est modifiable, le nôtre. Qui peut toujours être sauvegardé dans l'état indépendamment des conflits existants ou des soumissions incomplètes sur l'une des bases. Si un objet modifié localement est correctement soumis à l'une des bases distantes, il sort ne sort pas de notre claque de travail, mais on lui ajoute l'identifiant de référence à l'objet externe avec lequel il est synchronisé, (une référence qu'on marque comme "à jour et non modifié"), et le calque en lecture seule du fichier cache de cette base dostante reçoit alors une copie de l'objet Si on remodifie l'objet ou si on modifie un objet qu'on vient de charger, le calque local commence par recevoir une copie intégrale de l'objet source, avec tous ses identifiants externes, aucune référence externe n'est supprimée ni supprimable. Mais cette référence est marquée comme modifiée par nous. Et à tout moment on doit pouvoir choisir de synchroniser tout ou partie de notre calque avec la base distante. Et même choisir de synchroniser vers les bases distantes tous les objets sauf ceux en conflits, sans avoir à s'y reprendre plusieurs fois (en cas de conflit, la soumission des données devrait continuer pour tous les autres objets, pour qu'il ne reste alors dans notre calque local. Avec un tel comportement, il devient alors possible de comparer des fichiers OSM entre eux (chacun dans leur calque), et de les synchroniser entre eux (il suffit de traiter chaque fichier source comme une base externe différente). Avant de soumettre cette idée (et de la traduire en anglais) aux développeurs de JOSM, j'aimerais bien qu'on évalue cette solution ici, destinée à complètement revoir le système de gestion des conflits et la comparaison des sources externes non modifiables et locales (celles-là seraient modifiables ou non, selon qu'on veut créer un nouveau fichier local sans modifier les fichiers locaux exsitants, ou modifier ce fichier local chargé pour être modifié). Bref c'est vers la suppression totale de l'onglet "conflits" qu'on doit aller, puisque c'est l'onglet "calques" qui gérera ça. Le 1 avril 2012 21:22, Vincent Privat <[email protected]> a écrit : > > Le 1 avril 2012 20:41, Philippe Verdy <[email protected]> a écrit : > >> notamment JOSM dont le système de gestion des conflits est encore très >> mauvais > > > Si tu as des patchs à proposer on prend avec plaisir hein. Il y a encore > beaucoup de problèmes avec le système de gestion des conflits, je ne le nie > pas, mais de là à le qualifier de "très mauvais"... > > Par contre, pour la gestion multi-bases des informations, c'est en partie > possible avec le tout récent plugin SDS de Frederik Ramm: > http://lists.openstreetmap.org/pipermail/josm-dev/2012-March/006099.html > > où l'idée est de séparer les tags selon leur provenance: la base OSM ou un > serveur SDS (utilisé pour HOT). Il est peut-être possible que les mécanismes > qui ont été intégrés dans le noyau JOSM pour ce plugin soient réutilisables > pour de la duplication d'envoi vers FOSM, si quelqu'un d'aventureux était > prêt à réaliser un plugin pareil (j'avertis de suite, ça ne m'intéresse > pas). _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
