[OSM-talk-fr] Frontière et/ou eaux territoriales Guyane française

Jeu 7 Mar 11:37:54 UTC 2013

Merci Vincent !

A cette liste je rajouterai, cette capacité qu'a Philippe à détourner 
chaque sujet afin qu'il puisse ensuite parler de CES sujets de 
prédilection. Combien de discussions ont été tuées dans l’œuf à cause de 
ses interventions?

Dommage que toute son énergie soit, à mon sens, déployée dans de 
mauvaises directions.

A.

On 13-03-07 06:31 AM, Vincent Pottier wrote:
> @ Philippe
> Je crois que tu ne comprends pas que nous sommes quelques uns, 
> nombreux probablement, à être lassés de ce ton péremptoire, 
> pseudo-doctoral et donneur de leçon, que tu utilises trop souvent dans 
> nombre de tes messages.
>
> Nous sommes quelques-uns, nombreux peut-être, à être lassés de tes 
> affirmations non accompagnées d'exemples ou de références quand bien 
> même elles te sont demandées, et qui permettraient à chacun de 
> vérifier la véracité de tes dires. Non, bien souvent, tes affirmations
>
> Nous sommes quelques-uns, nombreux peut-être, à être lassés de tes 
> critiques des méthodes, des outils, des logiciels mais rarement 
> accompagnés de contributions, rapports de bugs, lignes de code.
> Nous sommes quelques-uns, nombreux peut-être, à être lassés de ton 
> aptitude à te mettre au dessus de la mêlée, avec un regard judiciaire, 
> un discours accusateur lorsque chacun cherche à construire une 
> communauté des contributeurs, avec ce que cela comporte nécessairement 
> d'approximations successives, d'hésitations, d'ajustements, d'erreurs 
> et d'excuses. Mais t'es-tu déjà excusé de t'être trompé sur cette 
> liste, Philippe ? Je n'en ai pas le souvenir.
>
> En travail social on dit "le 'tu' tue". Et pour une fois, je vais 
> employer ce "tu qui tue" à ton égard.
> Tu es le seul à employer avec cette intensité, ce ton directement 
> accusateur, polémique, sans te remettre toi-même en question :
> * "Tu n'as strictement rien prouvé, je ne juge que" : il ne s'agissait 
> pas pour Christian, de prouver, on n'est pas au tribunal, mais de dire 
> ses observations
>
> * "tu vas conclure que" : bien malin celui qui sait ce que l'autre 
> pense ou bien imprudent celui qui ose énoncer à la place d'un autre.
>
> * "Tu fais juste confiance à la théorie et refuse de regarder" : que 
> sais-tu de la confiance et du refus de Christian ? "Le tu tue" et ce 
> genre de propos, d’affirmation, ne fait pas droit à l'altérité de la 
> personne puisque c'est toi, Philippe, qui te fais énonciateur et juge 
> de ce qui est en l'autre.
>
> * "tu fais partie des personnes qui..." Et voila, l'autre est épinglé 
> comme un papillon au milieu d'une boite par un entomologiste. Où est 
> le respect de la personne ? Ou est la prudence dans l'affirmation ?
>
> * "toi tu regarde à un endroit microscopique du code pour conclure que 
> ce code est correct sans même te demander si c'est à cet endroit 
> qu'est l'erreur" Que sais-tu de la méthode employée par Christian pour 
> annoncer son résultat, son observation, son avis ? "sans même te 
> demander si..." T'es-tu toi-même demandé si Christian avait regardé 
> ailleurs ? Connais-tu le niveau de compétence de Christian dans ces 
> logiciels ? Comment t'es-tu construite cette certitude qu'il ne s'est 
> pas demandé ? Comment est fondée ton affirmation ? Si Christian pose 
> des affirmations sur du logiciel, toi, tu poses des affirmations sur 
> les personnes. Ce qui est bien plus grave !
>
> * "Je te laisse donc à ta théorie fumeuse, puisque tu lui fais une 
> confiance aveugle" Quel mépris ! Le mépris ne dit pas la valeur 
> intrinsèque de l'objet méprisé, mais l'incapacité de l'auteur à 
> apporter du prix. Ce mépris ne t'honore pas, Philippe !
>
> * "Quelle impolitesse" Qui est le plus impoli ? Qui a le moins de 
> "savoir vivre" ? Celui qui dit son agacement et sa lassitude, ou celui 
> qui méprise ?
>
> Philippe,
> Au delà de la longueur de tes messages, je crois bien que ce qui lasse 
> certains d'entre nous, c'est bien plus le ton de ceux-ci.
> Quand parviendras-tu à ne pas te poser en juge ? Quand parviendras-tu 
> à ne pas monter sur tes grands chevaux ? Quand parviendras-tu à 
> laisser entendre que tu as entendu telle critique qui t'était faite ? 
> Quand parviendras-tu à présenter des excuses ? Quand parviendras-tu à 
> mettre plus d'humanité dans ton propos ?
> Oui, il est difficile d'être humain. Mais une communauté de 
> contributeurs c'est une communauté humaine. Et cette communauté n'a 
> que faire d'un juge en son sein. Elle n'a que faire d'une critique qui 
> n'étaye pas son propos d'exemples concrets, référencés. Elle n'a que 
> faire d'un énonciateur d'affirmations péremptoires.
> Cette communauté, humaine, recherche des humains bienveillants aux 
> niveaux de compétence variées.
>
> Voila que moi-aussi, j'ai été trop long, que moi aussi, j'ai jugé, que 
> moi-aussi, j'ai utilisé le "'tu' qui tue"...
> -- 
> FrViPofm
>
> Le 07/03/2013 05:49, Philippe Verdy a écrit :
>> Le 6 mars 2013 20:18, Christian Quest <cquest at openstreetmap.fr> a 
>> écrit :
>>> 1) le code d'osm2pgsql c'est pas de la théorie, c'est du concret, qui
>>> tourne sur les serveurs.
>>> Ce code redécoupe clairement les way composant une relation boundary
>>> en n objets dans planet_osm_line et planet_osm_roads
>>>
>>> 2) la feuille de style Mapnik utilise planet_osm_line et
>>> planet_osm_roads pour tracer les limites admin, donc les redécoupages
>>> des ways membres des relations et c'est bien donc de là que provient
>>> le admin_level.
>>>
>>> Ce sont tes affirmations non étayées qui sont dans la théorie... et 
>>> l'erreur.
>>> Vu que le jour où tu reconnaitra t'être trompé n'est sûrement pas pour
>>> aujourd'hui, je passe à autre chose.
>> Vu que tu n'as rien prouvé du tout par tes affirmations mais juste
>> énoncé une théorie et que les bogues sont bel et bien visibles, je te
>> laisse à ta conclusion contredite par les résultats obtenus. Tu n'as
>> strictement rien prouvé, je ne juge que sur les résultats obtenus, pas
>> sur un morceau de commentaire dans un code source.
>>
>> Mapnik a des bigues de rendus un peu partout, facile à trouver, et ce
>> ne sera pas le premier.
>>
>>> Dernier message pour moi car perdre mon temps à corriger tes
>>> appoximations me lasse... mais je persiste à les corriger pour éviter
>>> que trop de monde ne reste sur celles-ci.
>> Quelle impolitesse. Même si la théorie dit que 2 et 2 font 4, et qu'on
>> obtient 3, tu vas conclure que la théorie est juste mais même pas te
>> poser la question si les données traitées sont bien 2 et 2 là où le
>> code est sensé agir parce qu'il calcule une addition. On voit pourtant
>> 3, et on sait que les données sources sont justement 2 et 2.
>>
>> Quelque chose t'échappe (à moi aussi d'ailleurs et je n'ais
>> certainement pas envie de regarder et comprendre pourquoi le code rend
>> ce résultat, tout bonnement parce que ce n'est peut-être même pas ce
>> code qui est concerné ici dans le résultat obtenu). Tu fais juste
>> confiance à la théorie et refuse de regarder les résultats tels qu'ils
>> sont.
>>
>> Je ne reproche rien aux concepteurs de ce programme, tous les
>> programmes ont des bogues, des cas particuliers oubliés et non traités
>> ou des conditions initiales non clairement spécifiées et oubliées. Le
>> code est assez complexe pour en avoir des tas. Mais toi tu regarde à
>> un endroit microscopique du code pour conclure que ce code est correct
>> sans même te demander si c'est à cet endroit qu'est l'erreur.
>>
>> Des bigues de rendus il y en a pour différentes raisons, y compris
>> diverses sources de désynchronisations des données entre ce qui est
>> dans la base et ce qui est dans les tables de cache internes. Le
>> problème n'est pas là : si on a des données contradictoires dans la
>> base, la façon dont se débrouille les algos pour lever les ambiguités
>> reste seulement une heuristique qui va juste régler les cas les plus
>> courants.
>>
>> Mais voilà, tu fais partie des personnes qui font une confiance
>> aveugle dans ce que produit un programme, sans doute parce que tu l'as
>> écrit toi-même et que tu penses que c'est déshonorant d'admettre que
>> ton bijou peut avoir des anomalies. Je me fiche totalement de savoir
>> comment fait le programme en interne, et en fait je ne devrais même
>> pas avoir à le savoir.
>>
>> Pour évaluer un programme on regarde ses résultats, rien d'autre. Si
>> le résultat n'est pas celui attendu, on isole le problème en repérant
>> les cas qui ne marchent pas se lon quelques règles simples. Et on
>> commence par d'abord relever les contradictions dans les données
>> sources pour éviter de les mettre. Et c'est en procédant ainsi qu'on
>> arrive à isoler des problèmes en fait dans les données sourves, que
>> l'heuristique du programme ne parbient pas à isoler et corriger
>> lui-même. Et on voit que ces corrections aussitôt faite non seulement
>> résolvent le problème du résultat mais aussi clarifient les données
>> sources (il n'y a pas que Mapnik qui doivent interpréter les données,
>> les contributeurs aussi.
>>
>> Je te laisse donc à ta théorie fumeuse, puisque tu lui fais une
>> confiance aveugle, moi je reste à ma méthode pratique qui est souvent
>> bien plus fiable et permet d'avancer (et surtout ne dépend pas de la
>> seule interprétation faite par Mapnik, mais peut aussi servir à
>> d'autres rendus, sans compter aussi que la version déployée peut aussi
>> être différente de celles qui est dans le code source).
>>
>> _______________________________________________
>> Talk-fr mailing list
>> Talk-fr at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr