Re: [OSM-talk-fr] Quelles fonctionnalités techniques vous manquent ? Mode d'édition polygone
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). Tu n'as pas du lire correctement ce que je propose, car j'ai bien précisé que deux polygones membres de deux relations différentes n'ont pas à être fusionné. 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. J'ai au contraire cherché à proposer quelque chose de simple avec 2 commandes fusion/scission, en précisant clairement le contexte d'utilisation possible, et respectant la logique des raccourcis c et p. ... intersections à calculer et effectuer J'avais pourtant écrit : 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) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Quelles fonctionnalités techniques vous manquent ? Mode d'édition polygone
Philippe, tu devrais prendre un carnet de 10 tickets enhancement sur http://josm.openstreetmap.de/newticket ! Certaines idées me semble intéressantes, mais noyées dans un long mail sur une mailing list francophone elles n'ont aucune chance d'être implémentées :( ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Quelles fonctionnalités techniques vous manquent ? Mode d'édition polygone
J'ai déjà envoyé les tickets sur ce que je considère le plus sérieux. Certains problèmes sont simples à résoudre (avec peur de modifs à faire une fois qu'on a isolé et bien identifié la source du problème) mais pour d'autres les solutions se discutent et les tickets sont mal placés pour être discutés car il y a plus de choses à écrire. Un autre constructeur statique pour les boites d'alerte de JOSM construisant une interface plus utile que la bête alerte par défaut de Swing qui n'est pas faite pour afficher des messages de contenu dynamiques au contenu imprévisible, est un projet simple à concevoir, ça s'isole bien. La gestion des focus d'entrée entre les fenêtres de JOSM (surtout quand elles le perdent face à une autre application) est aussi simple à concevoir. C'est pourtant un problème quand on a plusieurs fenêtre ouvertes dans JOSM. Il peut être nécessaire aussi de discuter le comportement qu'on devrait avoir pour savoir comment repositionner un focus utile (ce n'est pas si évident que ça). Les raccourcis trop compliqués pour mettre à jour des données suffisantes (CTRL+ALT+U ou D), et un mode de travail qui limiter les conflits ou erreurs et oublis se conçoivent très bien (même si ce mode de travail sera un peu plus lent à cause des requêtes supplémentaire au serveur) mais là les solutions à apporter se discutent avant. Le 15 novembre 2012 09:56, Christian Quest cqu...@openstreetmap.fr a écrit : Philippe, tu devrais prendre un carnet de 10 tickets enhancement sur http://josm.openstreetmap.de/newticket ! Certaines idées me semble intéressantes, mais noyées dans un long mail sur une mailing list francophone elles n'ont aucune chance d'être implémentées :( ___ 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
Re: [OSM-talk-fr] Quelles fonctionnalités techniques vous manquent ? Mode d'édition polygone
En plus c'est bien ici qu'a été lancée cette discussion, non ? Les tickets c'est surtout pour ensuite ne pas oublier qu'on a des solutions possibles, et du travail maintenant à faire pour le suivi. Une discussion c'est forcément plus long, le ticket lui reste très résumé : soit il signale un problème sérieux (que l'auteur du ticket n'explique ou ne comprend pas) et on n'a pas de solution proposée, il faut quelqu'un d'autre pour analyser le problème. Mais pour les enhancements (améliorations proposées), le ticket n'est pas la première méthode de suivi, on peut en avoir des tas sans même aucune évaluation de ce que ça représente, et les propositions ne sont ps toujours non plus les plus simples pour un même problème de base, ou peuvent se faire de façon plus graduée (ça peut aussi vite être une fausse piste si on travaille dessus tout de suite et ça peut compliquer d'autres choses qui marchent bien déjà). L'amélioration proposée doit alors avoir plusieurs objectifs: peut-être faciliter le travail pour certains mais si pour les autres plus nombreux ça le complique, il vaut mieux ne pas les inclure mais les mettre dans un autre plugin optionnel (si ça intéresse d'autres personnes pour les créer), avec aussi le mérite de faire une expérimentation à part ente plusieurs solutions possibles. Le 15 novembre 2012 09:56, Christian Quest cqu...@openstreetmap.fr a écrit : Philippe, tu devrais prendre un carnet de 10 tickets enhancement sur http://josm.openstreetmap.de/newticket ! Certaines idées me semble intéressantes, mais noyées dans un long mail sur une mailing list francophone elles n'ont aucune chance d'être implémentées :( ___ 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
Re: [OSM-talk-fr] Quelles fonctionnalités techniques vous manquent ? Mode d'édition polygone
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
Re: [OSM-talk-fr] Quelles fonctionnalités techniques vous manquent ? Mode d'édition polygone
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
Re: [OSM-talk-fr] Quelles fonctionnalités techniques vous manquent ? Mode d'édition polygone
Bonjour, Ce qui serait bien c'est un mode d'édition adapté aux polygones (JOSM). Actuellement il est assez difficile de faire des choses simples comme partager un polygone en deux (surtout si ses frontières sont communes avec un autre polygone) Donc ce qui serait pratique, c'est un mode d'édition où : * Un polygone se sélectionne par un clic à l'intérieur de celui-ci. * Deux polygones ayant au minimum 1 point commun peuvent être fusionnés (gestion des attributs comme pour les fusion de way) * Possibilité de fractionner un polygone (par exemple sélection d'un way et d'un polygone, si le way et sans attributs, il disparaît lors de la création des deux nouveaux polygones) Peut-être que cela existe déjà, mais je ne croix pas. Balaitous ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Quelles fonctionnalités techniques vous manquent ? Mode d'édition polygone
Le (multi)polygone est déjà sélectionnable lui-même (ALT+Clic permet d'alterner entre les sélection des différents objets possibles : noeuds suivants, puis ways, puis relations, puis ça reboucle) Fractionner ou fusionner un (multi)polygone est un peu plus compliqué car il faut d'abord télécharger TOUTES ses relations dépendantes (CTRL+ALT+D), et ne pas oublier de le même à jour lui-même avant (CTRL+ALT+U). De plus dans le cas du fractionnement avec une autre ligne, elle peut aussi être fermée et sans intersection non plus avec le polygone à découper (pourtant elle va produire une différence de surface : il y a plusieurs modes possibles entre une différence, ou une union des surfaces et dans le cas d'une différence il y a un ordre de priorité sur la surface à garder). Aussi, bien qu'il n'y ait pas de noeud commun, il faut chercher les intersections : ce n'est pas simple car normalement on ne fait pas des intersections avec n'importe quoi (ce peut être sur des niveaux (layer) différentes qui doivent rester séparés. Il y a tellement de cas particulier qu'automatiser cela est assez délicat : autant faire les étapes manuellement une par une : détermination des noeuds d'intersection à ajouter, fermeture éventuelle (s'il faut fusionner des noeuds), détermination de ce qu'il advient des relations dépendantes, insertion prélable d'un polygone dans une relation multipolygone... La fusion de deux polygones souffre aussi de pas mal d'exceptions : les attributs à fusionner nécessite un écran préalable pour éditer les conflits même pour les cas les plus simples, d'autant plus que même s'ils ont des attributs identiques, ils ne sont pas nécessairement non plus enfants des mêmes relations : si on les fusionne, un des parents différents référencera alors un polygone agrandi et ce n'est pas toujours correct ! Alors oui c'est un peu longuet, mais je ne me lancerai pas dans ce genre d'aventure. En revanche un mode d'édition où systématiquement avant TOUTE opération sur un chemin (scission ou fusion) ou une relation, et même sur un nœud, JOSM commence par mettre à jour automatiquement l'objet à modifier (CTRL+ALT+U) et ses référents (CTRL+ALT+D) serait bienvenu (tant pis si cela fait des requêtes souvent : on peut optimiser en évitant que ces requêtes automatiques n'interroge le serveur trop souvent en gardant en cache local la date de dernier rafraîchissement depuis le serveur de l'objet et celle de ces référents : au delà de 10 minutes le serveur est réinterrogé et cette date n'est PAS enregistrée dans le fichier osm local (toute donnée rechargée depuis un fichier sera remis à jour depuis le serveur avant de modifier). Dans ce même mode, avant tout envoi des données, la totalité des objets modifiés fait lui aussi l'objet d'un rafraichissement préalable : JOSM avertit alors que des données ont été mises à jour, et propose la résolution de conflit très tôt et non une fois commencé les envois. Sinon, pour ceux qui n'utilisent pas ce mode de requête automatique (par exempel si on travaille hors ligne) la mise à jour des modifications ET des objets référents devrait être demandée en une seule opération. De même un seul raccourci pour faire CTRL+ALT+U (mise à jour de l'objet) et CTRL+ALT+D (chargement des objets dépendants). Note: ces deux raccourcis (par défaut) sont très peu pratiques, de plus il m'est déjà arrivé de mal appuyer sur la touche ALT et donc d'exécuter CTRL+D (duplication de l'objet sélectionné) sans m'en apercevoir tout de suite (on le voit parfois plusieurs jours après dans Osmose mais pas toujours non plus si l'objet dupliqué ne crée pas d'intersections suspectes, selon l'endroti où l'objet dupliqué a été activé). Pour ces actions il vaut encore mieux utiliser des touches uniques comme F8 (mise à jour) et F9 (chargement des dépendants) ou F10 (les deux successivement), car on devrait les utiliser souvent si on n'a pas activé le mode assisté (comme c'est fait automatiquement dans Potlatch, qui ne se prive pas de faire de fréquentes requêtes au serveur, et sur de beaucoup plus nombreux objets en plus) ! Enfin les raccourcis claviers d'une seule lettre qui modifient la géométrie d'un objet ne devraient pas être utilisables si on a un formulaire ouvert : Combien de fois le focus sur le dialogue n'est pas gardé ! Déjà il suffit de passer au navigateur web (ALT+TAB) et de revenir à JOSM (ALT+TAB), le dialogue n'a plus le focus alors qu'il est resté en avant-plan dans l'application JOSM. On commence à taper du texte (par exemple la touche L qui aligne une série de points, ou la touche O qui les redispose en cercle, ou la touche B qui les répartit) et ça modifie ce qui est CACHÉ DERRIÈRE le dialogue formulaire... Ça c'est un bogue sérieux de l'interface (source de pas mal d'erreurs involontaires et pas visibles immédiatement) qui ne gère pas bien les focus sur la fenêtre active entre un dialogue et la fenêtre principale quand on passe à une autre application et quand on revient à JOSM. A la limite, si on ne
