Le 6 mars 2013 20:18, Christian Quest <cqu...@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@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
