Ceci dit on voit tout de même des infos pertinentes concernant les erreurs de cet utilisateur, notamment avec des détections assez précises comme "relations à 1 seul membre" qui indique qu'il a retracé par exemple des carrefours mais omis les relations de restriction d'accès, vraiment très locales): il découpe n'importe comment, ne se soucient pas du tout de remettre les relations d'aplomb: il retrace, supprime ce qui le gêne ou fait doublon pour lui sans jamais se préoccuper des dépendances de ce qu'il supprime. Au passage il omet pas mal de tags ou les remet mal sur les objets de remplacement. Il ne se soucie pas non plus de la précision et ses tracés sont vite faits à la louche, très anguleux, de fait inévitablement ils vont entrer en intersection avec des bâtiments dans les villes aux rues étroites. Le résultat c'est une carte de Caen qui maintenant ressemble à un patchwork découpé à grand coup de ciseaux, il n'y a plus aucun angle correct, ce n'est plus un plan, c'est un schéma. Visiblement il se fouit pas mal de la précision. On se retrouve aussi avec des équipements du mauvais côté de la rue. Je pense qu'il utilise l'éditeur à très mauvais escient et va beaucoup trop vite, qu'il manque de formation. C'est acceptable pour des utilisateurs occasionnels, mais là avec son usage fréquent, il s'attaque à des choses qu'il ne maitrise vraiment pas assez pour faire des modifs aussi massives et fréquentes que les autres ont du mal à suivre ensuite pour corriger ses nombreux "oublis". Mais comme il fait tout dans son coin et ne paarticipe à aucune discussion, il n'apprend rien de plus. On doit donc le freiner et lui apprendre à collaborer et écouter les enseignements. Sinon il ne s'améliorera jamais et laisse tous les dégâts à la charge des autres qui doivent ensuite passer beaucoup plus de temps pour corriger chacune de ses erreurs que le temps très rapide avec lequel il modifie quantité d'objets. Pour des cas comme ça, il serait souhaitable qu'OSM dispose d'une option permettant de freiner un utilisateur en limitant le nombre de changesets et d'objets: s'il y a trop d'erreurs laissées derrière, il vaudrait mieux avoir un moyen de dire que des modifs hors d'une zone précise sont proscrite, afin de l'obliger à passer du temps à corriger ce qui reste en fonction d'un certain nombre de rapports d'anomalies ou de signalements laissés sans réponse de sa part.
Le mar. 3 déc. 2019 à 23:08, Philippe Verdy <verd...@wanadoo.fr> a écrit : > Attention: les erreurs associées à un utilisateur ne sont pas de son fait > pour la plupart, cela se produit notamment indirectement pour des > modifications locales (correctes) de relations dont d'autres membres > avaient déjà des problèmes ailleurs mais n'ont pas été modifiés pour > autant. Cas typique: > - les relations de transport où on peut trouver des intersections > route/rivière (sans pont ou tunnel) ou route/bâtiment: il y en a encore des > tas dans la base et pas attribuées à l'utilisateur correct ayant créé ces > intersections. > - des tags laissés de côté mais pas retirés/modifiés car cela aurait > conduit à des modifs en cascade et des changesets gigantesque pour fouiller > chacune des dépendances sur des problèmes très éloignés de la zone qui a > été réellement modifiée. > Bref concernant les erreurs de "niveau1" sur les relations, ce n'est pas > si critique que ça, sauf concernant la géométrie des relations elles-mêmes > (chemins membres polygones qui doivent être fermés, et tronçons manquant > sur les relations linéaires (mais bien souvent les anomalies viennent de > tronçons qui étaioent déjà retirés ailleurs, et les longues relations de > transport sont souvent concernées par ces tronçons mal reliés quand > quelqu'un d'autre a redessiné un carrefour mais omis de relier les segments > de connexion. L'utilisateur suivant qui vient faire une modif ailleurs mais > ne touche pas à la géométrie ou fait une modif correcte ailleurs ne verra > pas toujours qu'il manque des éléments (et faire le tri pour corriger ce > qui manque ailleurs prend un temps fou: l'erreur était déjà là, elle > subsiste, mais l'attribution donnée au dernier modificateur n'indique pas > qu'il est responsable de cette erreur qui était déjà là avant lui. > N'importe qui travaillant beaucoup sur OSM et correctement se voit > automatiquement "attribué" ensuite des erreurs sans même rien toucher, à > cause des dépendances sur d'autres objets qu'il n'a même pas touché > lui-même mais ont été touchés par d'autres. > Bref ce n'est qu'une indication mais pour le détail il faut revoir > l'historique et visiblement peu de gens savant interpréter les historiques > (même les outils automatiques ont du mal à s'y retrouver tellement c'est > compliqué): c'est un problème inhérent au modèle de données OSM. Là pas le > choix il faut s'y coller erreur par erreur, localement mais celui qui s'y > colle et vient corriger chacune une par une se voit ensuite attribuer des > erreurs qu'il n'a pas encore traitées mais concernant d'autres problèmes > ailleurs sur les mêmes relations touchées. > Bref ne pas trope se fier aux attributions d'auteurs qui n'indiquent que > l'auteur de la dernière modif effectuée sur un objet, mais rarement > l'auteur de la modif plus ancienne qui a produit cette erreur. C'est pour > ça qu'on ne devrait pas appeler cela "erreur" mais juste "signalement. Oui > il y a un problème, mais rarement de l'auteur indiqué, l'outil de neis-one > ne faisant pas dans le détail pour fouiller les hiostoriques des modifs > pour en trouver l'origine réelle avec l'analyse poussée des diffs. > > > Le mar. 3 déc. 2019 à 21:16, <osm.sanspourr...@spamgourmet.com> a écrit : > >> Stéphane et David, vu que vous êtes ceux qui avez le plus investi dans la >> vérification des modifications et que toutes les remarques sur les >> modifications sont restées sans réponse : >> >> http://resultmaps.neis-one.org/osm-discussion-comments?uid=2322305, je >> crois que vous êtes les mieux placés pour demander un blocage au DWG le >> temps que cette personne réponde à vos interrogations. >> >> Je vois aussi parmi les métriques : Osmose issues >> <http://osmose.openstreetmap.fr/en/byuser/Chlc>: Level 1=96, Level 2=999, >> Level 3=1870. >> >> Oui près de 100 erreurs de niveau 1. >> >> Sinon effectivement j'ai compris pourquoi OSMand déconnait : il ne passe >> pas par où passent OSRM, GraphHooper ou Bibi : il préfère doubler la >> distance que de prendre un raccourci par une route moins importante. Donc >> c'est une question de poids de certains éléments pour le calcul du trajet >> et non un mauvais comptage des sorties. >> >> N. B. : Stéphane en fait je vois que tu le suis (subis !) depuis un >> moment, quant au bout d'une "certain temps" le contributeur ne répond pas >> et continue ses mauvaises pratiques, ça ne sert à rien de continuer sur le >> même mode il faut essayer un autre canal. >> >> Jean-Yvon >> Le 02/12/2019 à 21:09, David Crochet - david.croc...@free.fr a écrit : >> >> Bonjour >> >> Le 29/11/2019 à 21:46, osm.sanspourr...@spamgourmet.com a écrit : >> >> Je pense naïvement que si c'était si mauvais on s'en serait aperçu plus >> tôt. mais pas sûr du tout. >> >> >> >> C'est achavi qui m'a donné " l'alerte " car je surveille une zone, et il >> vient seulement d'y contribuer et mal, et c'est en regardant l'historique >> que j'ai vu qu'il cartographier mal depuis un moment. >> >> Cordialement >> >> _______________________________________________ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
