[OSM-talk-fr] 4 jours pour digérer le coup de fourchette

[Philippe Verdy]

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 <vincent.privat at gmail.com> a écrit :
>
> Le 1 avril 2012 20:41, Philippe Verdy <verdy_p at wanadoo.fr> 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).