Tes conditions exposées sont encore trop simples, tu oublies de parler dans
les polygones que tu fusionnes le fait qu'ils puissent être membres de
relations différentes (et n'ont pas à être fusionnés même si tous les
attributs sont identiques).

La boite de résolution de conflits me semble pratiquement toujours
indispensable pour informer l'utilisateur de ce qui va se passer dans les
autres relations référentes dont les membres vont être modifiés). Et plus
on essaye de combiner par une seule commande les opérations (qu'on fait
actuellement en plusieurs étapes) en une seule, plus le nombre de cas de
conflits à résoudre augmente et est compliqué à interpréter pour
l'utilisateur dans la boite de résolution de conflits.

Le résultat obtenu n'est alors plus du tout une simplification mais bien
une complication qui va produire encore plus d'erreurs ou
d'incompréhensions car le nombre d'objets (noeuds, chemins, relations, y
compris les référents) distincts modifiés simultanément augmente avec pour
chacun leurs propres attributs et rôles.

Sinon on peut toujours augmenter le nombre de commandes différentes pour un
certain nombre de cas particulier, mais là encore ça n'est pas simple non
plus de comprendre et distinguer les plus nombreuses commandes disponibles
et de leur donner un nom ou une description signifiante et assez précise
pour les distinguer.

Les opérations de fusion sont encore plus sensibles en terme de complexité
que les opérations de scission (mais même une scission pose une difficulté
selon la façon de les faire : intersections à calculer et effectuer,
conservation de l'intersection ou d'une des deux différences possibles).

Même si on départ la sélection n'est qu'un seul noeud, le fait qu'il puisse
être membre de plusieurs relations ou chemins nécessite une désambiguation
(comme actuellement déjà) de l'action à effectuer et il faut alors un
second objet pour préciser un contexte. Mais alors comment interpréter la
sélection de deux objets ? (un sur lequel effectuer l'action, l'autre pour
préciser le contexte) : il faudrait des sélections asymétriques avec encore
un critère à comprendre.


Le 15 novembre 2012 19:05, Balaitous <balait...@mailoo.org> a écrit :

> Non, je pense qu'un tel outil est réalisable.
> La plupart des cas d'utilisations concernent des polygones simples, je
> pense en particulier au landuse.
>
> Plus de détail sur un début de spécification possible :
>
> Fusion de polygones :
>
> Condition d'utilisation : Sélection de 2 polygones avec au moins 1 point
> commun (simple pas des multipolygones)
>  => Les polygones n'appartiennent à aucune relation : fusion avec
> éventuellement boite de dialogue pour gérer les tags en conflits
>  => Les polygones appartiennent tous les deux à une même relation
>     => Les polygones ont le même rôle : fusion, il n'en reste qu'un
>        dans la relation
>     => Les polygones ont des rôles différents : message d'erreur
>  => Les polygones appartiennent à deux relations différentes :
>     message d'erreur
>
> Scission d'un polygone :
>
> Condition d'utilisation : Sélection d'un polygone (simple) et d'un way
> dont les extrémités appartiennent au polygone et n'ayant aucun attribut
> (way créé dans le seul but de la scission)
>  => Le polygone n'appartient à aucune relation : création de deux
>     nouveaux polygones héritant des mêmes tags, et suppression du way
>  => Les polygones font partie d'une relation : idem, et de plus les deux
>     polygones créés font partie de la relation avec le même rôle.
>
> Je ne pense pas que cela puisse introduire des incohérences.
>
> En l'état actuel, je me refuse à modifier Corinne (même si j'ai fait
> quelques tentatives), alors qu'il y a beaucoup à faire de ce côté là.
>
> Si quelqu'un trouve ma proposition intéressante, ça serait bien qu'il la
> relais à un endroit adéquat.
>
> Balaitous
>
>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Répondre à