Discussion Projet:Communes de France/Diagrammes

Débats : Les diagrammes

Page de débats sur le choix des diagrammes et histogrammes... à inclure dans les articles de communes françaises.

Les débats sur l'Histogramme

Propositions de graphiques

Graphique 0

C'est le graphique actuellement en place, il présente le défaut d'avoir une graduation irrégulière sur l'échelle des temps et induit une interprétation visuelle fausse sur la vitesse d'évolution.

Graphique 1

Modèle issue de la page de [du 11 décembre 2008] ajouté par wikialine

Diagramme de Pougues-les-Eaux

La construction de ce graphique demande une conversion à effectuer sur le nombre d'habitants et est expliqué dans la page du projet

Graphique 2

Ce graphique est plus simple à mettre en place. C'est une variante de celui actuellement utilisé mais pour que l'échelle de temps soit régulière il a fallu créer ... plus de 200 barres ! Le code va gravement polluer l'article sauf si on crée un modèle par commune (mais alors on multiplie par 2 le nombre de pages du projet) Si quelqu'un peut programmer un modèle modifiable ce serait super mais il faut un spécialiste des modèles et de timeline

Graphique 3

C'est une variante du graphique 2 avec des points au lieu de bâtons. Il offre le même défaut (code très long) que le graphique 2

C'est la base du "x" qui indique le nombre d'habitants et pas le centre de la croix. C'est un autre défaut, il faudrait trouver un autre symbole centré sur la ligne d'écriture.

Graphique 4

Double échelle

Courbe d'évolution démographique de Pougues-les-Eaux depuis 1793
(Élaboration graphique par Wikipédia, interpolation linéaire entre les recensements)

Cette courbe utilise la couleur rgb(0,0.6,0.4) qui a été proposée plus bas. L'utilisation de traits fins en échelle nécessite de faire attention à la hauteur de l'image (la hauteur de l'image doit être égale à 31 plus un multiple du nombre de graduations de l'échelle - en l'occurrence 27 graduations ici -)

Simple échelle

Courbe d'évolution démographique d'Antony depuis 1901
(Élaboration graphique par Wikipédia)

ou Courbe d'évolution démographique d'Antony depuis 1793
(Élaboration graphique par Wikipédia)

Graphique 5

Graphique adoptant une forme de courbe avec pour chaque date de resencement un point bien distinct. Graphique inspiré de ceux de l'insee.

Courbe d'évolution démographique de Pougues-les-Eaux depuis 1793
(Élaboration graphique par Wikipédia, interpolation linéaire entre les recensements)

Même courbe que le graphique 4 mais avec les points en plus, représentés sous la forme de carrés de 3x3 pixels, et échelle principale de population grise au lieu de noire.

Idem avec un trait plus fin pour la courbe (1 pixel au lieu de 2). Carfois (d) 16 janvier 2009 à 00:05 (CET)

Même courbe que le graphique 4 mais avec les points en plus, représentés sous la forme de carrés de 3x3 pixels, et échelle principale de population grise au lieu de noire.

Idem avec points en vert comme la courbe au lieu de noir. Carfois (d) 16 janvier 2009 à 00:16 (CET)

Variantes avec les points de même taille que la largeur de la courbe...

Courbe d'évolution démographique de Pougues-les-Eaux depuis 1793
(Élaboration graphique par Wikipédia, interpolation linéaire entre les recensements)

En largeur 3px

Idem en largeur 2px (et hauteur toujours 3px pour les points)

Idem en largeur 1px (et hauteur toujours 3px pour les points)

 

Graphique 6

Idem que le graphique 5 mis à part que les points sont remplacés par des histogrammes (idée de Wikialine). Carfois (d) 16 janvier 2009 à 01:26 (CET)

Variante du précédent en bicolore. Carfois (d) 16 janvier 2009 à 01:50 (CET)

Diagrammes (suites)

Discussion issue de la PdD du projet communes de France du décembre 2008

Maintenant que le bug d'easy timeline est réparé, je peux vous proposer des diagrammes en bâtons plus juste pour l'évolution l'évolution démographique : regarder une exemple sur ma page utilisateur. La difficulté est de choisir la bonne graduation sur l'axe des ordonnées et de calculer la hauteur des bâtons. Mais si cela vous intéresse, je peux expliquer ma méthode sur une page dédiée comme Projet:Communes de France/Ateliers/Diagrammes. Je pourrais aussi expliquer comment construire à peu de frais une pyramide des âges par tranche de 15 ans. Mais j'aimerais votre feu vert pour créer cette page. HB (d) 11 décembre 2008 à 10:07 (CET)

1^re appréciation : il est plus élégant que le modèle que j’utilise, et en plus prend moins de place ;

<questions de néophyte>Pourquoi préférer des barres fines ?</questions de néophytes>

Questions techniques : apparemment ne pas définir de limites à ScaleMinor limite le diagramme à 2500 ; il te faudrait définir une bar:6 à 3000, car actuellement ton diagramme est faux pour après 1990. Épiméthée (d) 11 décembre 2008 à 10:36 (CET)

J'oubliais : Modèle:Feu vert :-) Épiméthée (d) 11 décembre 2008 à 10:37 (CET)

Ça me paraît pas mal pour ma part .

Pour la question d'Épiméthée concernant les barres fines, je suppose que 1) c'est en rapport avec la précédente discussion d'octobre au sujet des diagrammes avec aires, et 2) que cela permet de faire tenir l'histogramme sur une largeur respectable tout en permettant de visualiser clairement les périodes durant lesquelles la population n'est pas connue car sans recensement, non ?

LeMorvandiau ^[blablater] 11 décembre 2008 à 13:45 (CET)

Et du coup il est plaçable en entier, avec tous les paramètres présents dès le début, même si on a pas toutes les données ? Du coup, on le met une fois pour toutes, et on remplit ou on laisse remplir au fur et à mesure ? Épiméthée (d) 11 décembre 2008 à 19:41 (CET)

Il y a des ajustement nécessaires si la taille de la population se met à dépasser la valeur max choisie. De même, le diagamme présenté est peut-être trop large si le nombre de date est faible par exemple 6 recensement seulement. Je peux ajouter une section sur ce qu'il faut faire dans ce cas.HB (d) 11 décembre 2008 à 19:56 (CET)

Intéressant. Deux petites remarques, six graduations me semblent un peu juste pour les communes très peuplées récemment (une ville nouvelle qui aurait 300 habitants en 1790 et 60 000 aujourd'hui, comment faire ?) et la largeur des barres me paraît un peu faible, ou alors, il faudrait mettre une couleur plus foncée pour améliorer la lisibilité.
Sinon, c'est une autre piste, sur le modèle actuel, ne pourrait-on pas placer des paliers ou des points plutôt que des barres ? Ça résout le problème de la largeur fausse et ça évite des « trous » peu esthétiques et qu'il faut expliquer.--Cyrilb1881 (d) 11 décembre 2008 à 20:00 (CET)

Dans le cas de ton exemple, il n'y a a pas grand chose à faire 300 représente 0,5 % de 60 000. Si un graphique de 400 px veut représenter les deux valeurs, la première aura une taille de 2 px .Bref, tout petit, et cela indiquera bien que la ville a commencé presque à 0.

Largeur et couleur adaptable, il suffit de se mettre d'accord.

Concernant ta seconde suggestion, c'est une autre piste qui résoudrait probablement les pbs de visualisation sans devoir monter mon usine à gaz. Mais je ne me suis pas penchée sur cette solution et ne sais pas si elle est réalisable. HB (d) 11 décembre 2008 à 20:12 (CET)

Les barres moins larges que le modèle actuel permet d'aérer la présentation. Pour ce qui est de la création d'un modèle, je penses pouvoir m'y coller HB. Mais dans l'immédiat avant de se lancer, il faut tomber d'accord sur une forme de graphique. Pour l'instant j'ai un faible pour le 1 et le 2. Pour le 1, il serait intéressant d'élargir légèrement plus les barres... Autrement je ne vois rien d'autres de choquant dans tes propositions qui me sembles respecter beaucoup de contraintes, ce qui est une bonne chose. amicalement--Wikialine (d) 13 décembre 2008 à 15:29 (CET)

Pour ma part, je préfère le 2 : les graduations intermédiaires permettent de plus rapidement se donner une idée de la valeur de chaque barre (même si le graphiques accompagnera le tableau de valeurs). Il paraît donc mieux que le 1.

Quant au 3, on a vraiment beaucoup de mal à voir quel point correspond à quelle année.

LeMorvandiau ^[blablater] 13 décembre 2008 à 16:57 (CET)

Bon, on semble donc s'orienter pour l'instant sur le diagramme 2.Son inconvénient est la longueur du code, son avantage est qu'il est par aillerus très semblable au diagramme 0. Wikialine, ne cherche pas trop longtemps à faire un modèle modifiable, l'aide timeline semble dire que ce n'est pas possible. Il reste encore des points à décider

• couleur et largeur des bandes
• Conservation dans le corps de l'article ou incorporation dans une page de modèle à part comme c'est le cas déjà pour les frises chronologiques (voir Catégorie:Modèle frise chronologique) et pour certain graphique (voir Catégorie:Graphique démographique de commune des Yvelines). Avantage : (1) regroupe tous les graphiques dans une même catégorie donc plus utile pour un changement de masse à faire par un robot en cas de changement de norme dans le projet. (2) évite la pollution de l'article par un code difficile à lire. Inconvénient : (1) multiplie par 2 le nombre de pages consacrées aux communes, (2) rend plus difficile la modification par le néophyte. (3) rend plus difficile le contrôle des vandalismes (les pages de modèles sont moins suivies que les pages de commune).

J'attends vos avis (nombreux). Il serait dommage que la décision se fasse à 3 personnes. HB (d) 14 décembre 2008 à 16:45 (CET)

Clairement pour le modèle 2 mais hors de question de créer une sous-page ou un modèle par commune. Certains le font déjà inutilement pour des listes de maires, on ne s'en sortira jamais à ce train. Ce n'est quand même pas une grosse « pollution ». Couleurs et largeurs sont convenables pour moi. Par contre, il faut déjà prévoir les dates futures, notamment 2008.--Cyrilb1881 (d) 14 décembre 2008 à 18:51 (CET)

Concernant les couleurs : le choix ci-dessus est remarquablement peu contrasté, et ces diagrammes seront difficilement perceptibles aussi bien pour certains utilisateurs ayant un handicap visuel que pour tout le monde dans des conditions de rendu peu favorables (mauvaise éclairage ambiant sur un écran, par exemple). S'il était possible de veiller à un contraste conforme aux normes internationales d'accessibilité, ce serait bien . Cordialement, --Lgd (d) 14 décembre 2008 à 19:11 (CET)

Est-ce que le bleu utilisé ici est mieux ?--Cyrilb1881 (d) 14 décembre 2008 à 19:19 (CET)

Un léger mieux : un ratio contraste/luminosité de 2 au lieu de 1.4, mais on est encore loin du 4 qu'il faudrait idéalement atteindre. Dans les deux cas, le contraste devrait au moins être relevé significativement. --Lgd (d) 14 décembre 2008 à 20:08 (CET)

Quel vert atteindrait ce ratio ?--Cyrilb1881 (d) 14 décembre 2008 à 21:00 (CET)

Par exemple #729272 (#729272 rgb(0.44,0.57,0.44) pour la timeline) atteint 3.5, ce qui est déjà nettement mieux et pourrait être considéré comme suffisant. #617C61 (#617C61) dépasse 4... Mais les variations possibles sont nombreuses, vous pouvez faire des essais en vérifiant le ratio à l'aide du Colour Contrast Analyser (utiliser l'algorithme « luminosité »). Cordialement, --Lgd (d) 15 décembre 2008 à 05:33 (CET)

-------------- rgb(0,0.6,0.4) offre un coefficient de 3,6 et correspond semble-t-il mieux aux teintes choisies. D'autres propositions ? HB (d) 15 décembre 2008 à 14:40 (CET)

Sur la page de discussion du projet communes de France, suite aux propos de Cyril, moi même et d'autres étions tombé d'accord sur l'usage du vert comme celui utilisé actuellement. ça permet de respecter la charte graphique général qui s'est dégagée sur les articles de communes. Les infobox sont vertes, le modèle des élus est vert, certains tableau démographiques sont verts. J'ai abandonner la couleur bleu suite aux arguments de Cyril et d'autres. Utiliser une couleur bleuté est à éviter. Si l'on veut absoluement respecter une charte graphique minimale pur nos article, les couleurs dominantes devraient être de préférences les tons verdatres ou alors neutre comme le blanc et le gris. Poour ce qui est des modèles pour chaque commune, totalement d'accord avec Cyrilb1881. Ces modèles sont inutiles. A la rigueur lorsque on aura fini de définir l'historgrammes ici alors on peut toujours tenter de créer le modèle de cet histogrammes. On peut toujours essayé. Et si le modèle est iréalisable, ça n'empêche pas pendant ce temps de mettre sur les articles l'histogrammes directement... amicalement--Wikialine (d) 14 décembre 2008 à 20:01 (CET)

Alors est ce que l'on est tous d'accord pour utiliser le diagramme 2 ? Qu'en pensez-vous ? Moi personnellement je suis éventuellement partante par contre j'avoue que je trouve ce graphique un peu long. N'y a t'il pas moyen de réduire sa taille? amicalement--Wikialine (d) 20 décembre 2008 à 02:58 (CET)

J'ai ajouté un autre type de diagramme sur Discussion_Projet:Communes_de_France#Diagramme de l'évolution démographique, qu'en pensez-vous? Je l'avais fait déjà pour quelques communes : voir Silly-en-Gouffern, Alençon, Argentan. Cela donnerait ça par exemple pour Antony depuis 1901 :

Voir l'exemple avec une courbe...

Courbe d'évolution démographique depuis 1901
(Élaboration graphique par Wikipédia)

 

Et si on l'on veut faire un histogramme plutôt qu'une courbe:

Voir l'exemple avec des bâtons...

Histogramme d'évolution démographique depuis 1901
(Élaboration graphique par Wikipédia)

 

La difficulté est qu'il faut faire les calculs du nombre de pixel, et également faire l'échelle verticale plus ou moins manuellement. A la base Timeline n'a pas été conçu pour faire des courbes, c'est pour ça que c'est moins simple, mais ça ne rend pas si mal malgré tout. Si cela vous parait intéressant je peux probablement en faire un modèle qui ferait les calculs automatiquement ainsi que la courbe ou l'histogramme. Carfois (d) 3 janvier 2009 à 11:29 (CET)

Sauf qu'il est encore plus faux de réaliser une courbe plutôt que l'histogramme actuel, puisque l'on est incapable de connaître l'évolution entre les années de recensement. S'il y a eu des accidents, la courbe ne le montrera pas, elle sera donc fausse. Accessoirement, ça me semble très compliqué comme procédé, surtout si l'on doit l'appliquer à plus de trente-six mille articles...--Cyrilb1881 (d) 3 janvier 2009 à 11:55 (CET)

Je suis d'accord avec Cyrilb1881, je crois que l'on peut sagement décider de laisser tomber l'idée d'utiliser des courbes. Car ces courbes ne reflètes pas la réalité, car elle ne peut pas prendre en compte les périodes de temps entre chaque recensement. Il faut donc se concentré sur les histogrammes avec des batons. A mon avis, il devrait y avoir consensus ce p^remier aspect. amicalement--Wikialine (d) 3 janvier 2009 à 15:17 (CET)

Superbe tes graphiques d'évolution de population ! Bon les calculs sont aussi pénibles que dans le graphique 1 mais pas insurmontables car tu les expliques très bien. Je trouve qu'une courbe est plus judicieuse qu'un diagramme en bâtons même si l'on fait des interpolations entre les différentes mesures. C'est traditionnellement une courbe qui est présentée dans ce cas là (voir par exemple la base Cassini comme ici) mais je ne suis pas un membre actif du projet et il semble difficile de vaincre certaines certitudes. Dans cette discussion, Cobber et Droop ont opté pour la courbe. Attendre et voir. (choisir aussi la couleur). Concernant le modèle, il semble que Timeline est incompatible avec la notion de modèle mais qui ne tente rien n'a rien.HB (d) 6 janvier 2009 à 11:36 (CET)

Bonjour HB et bonne année, contente que tu sois dans le coin pour que l'on continue ce débat, on a la chance de ne pas être dans l'urgence pour la mise en place de nouveaux diagrammes. Je trouve que peu à peu nous avançons. Niveau couleur, je crois que l'on est un peu près d'accord (voir dans la conclusion), on peut au pire voter pour l'une des 2 teintes de vert (j'ai créé une section ci-dessous pour que l'on tranche définitivement la question)... Donc là on peut aisément dire que sur ce point, on a bouti. A présent, je crois qu'il serait intéressant que l'on se mette d'accord sur le choix que l'on doit faire entre un diagramme en forme de courbe ou un diagramme avec des batons. Ainsi je lances une nouvelle section pour que l'on discute exclusivement de cette aspect (Aller à cette section). Tu penses que le choix d'une courbe est un choix judicieux, pourquoi pas reste à argumenter tous celà et à peser le pour et le contre. Moi je n'ai pas d'avis tranché sur la question, même si le choix des baton me semblait plus logique car il n'extrapole pas les périodes entre chaque recensement, mais bon suivant les arguments et le fils des discussion, des avantages peuvent être en faveur de courbes. Donc rien de tranché. Ensuite, une fois que l'on sera tombé d'accord sur la forme, on pourra discuter tranquilement sur la possibilité ou non de mettre en place un modèle. Mais sache qu'il existe déjà des modèles intéressant qui pourraient nous servir d'exemple comme {{Histogramme}}, {{Histogramme2}}, {{Pyramide des âges}} et {{Pyramide des âges 2}}... Donc à présent décidons-nous sur la couleur (c'est rapide dans la discussion suivante) puis sur la forme à choisir entre courbe et batons (dans la section dédiée). amicalement--Wikialine (d) 6 janvier 2009 à 18:26 (CET)

Fautes de rendu

Les barres sont fausses : par exemple, après 1982, on devrait avoir des barres qui dépassent le 2500, or ce n’est pas le cas. Épiméthée (d) 11 décembre 2008 à 19:43 (CET) Je n’ai rien écrit, par contre ce n’est pas très wikilove comme technique : divisez la population par 10, arrondissez, ajoutez 40... Épiméthée (d) 11 décembre 2008 à 19:45 (CET)

c'est sûr que seul un prof de math peut inventer un truc aussi tordu mais... c'est la seule façon de faire que j'ai trouvée. HB (d) 11 décembre 2008 à 19:53 (CET)

Choisir entre une courbe ou des bâtons

La première étape pour la mise en place d'un diagramme unique consiste à définir la forme la plus adéquate, ensuite suivra le choix d'une couleurs définitive et enfin il faudra étudier la possibilité de créer un modèle.

Avantages de chacune des formes

Liste des avantages de chacune des formes d'histogrammes :

Diagramme à bâtons	Diagramme à courbe
Les fluctuations démographiques entre 2 dates de recensement ne sont pas faussées.	Les courbes ont tendances à avoir une meilleure lisibilité.

Discussion sur les formes

Il s'agit de prendre ici une décision sur le choix à adopter concernant la forme de nos digrammes concernant l'évolution de la population en utilisant soit un histogrammes avec des batons soit en utilisant un diagrammes avec une courbe. Personnellement, pour le moment je trouve le choix des histogrammes à bâtons plus logique. En effet, une courbe ne peut pas prendre en compte les fluctuations démographiques entre deux dates de recensement. Maintenant reste à voir si il y a d'autres arguments qui viendraient apporter d'autres aspects qui viendrait faire pencher la balance plutot en faveur d'une courbe. En tout cas à nous de choixir la forme de diagrammes la plus juste dans sa représentation et la plus logique également dans les standards employé ailleurs. Mon avis n'est pas tranché définitivement, à vous de donner votre avis. amicalement--Wikialine (d) 6 janvier 2009 à 18:37 (CET)

L’avantage de la courbe est qu’elle est plus facilement lisible par le lecteur.

Le désavantage de la courbe est qu’elle est plus difficile techniquement, donc c’est pour nous, mais ça ne doit pas nous freiner : il faut penser au lecteur. L’autre désavantage est l’impression visuelle fausse. À mon avis, sur une courbe avec plus de trente points sur 200 ans, c’est du détail. La courbe est lue dans tout les cas rapidement, donc le détail apparaît peu. On garde une impression rapide : hausse importante à telle époque, baisse longue et continue, etc. Épiméthée (d) 15 janvier 2009 à 00:45 (CET)

J'ai ajouté en graphique 4 une courbe de la même population que les autres exemples et avec aussi la couleur verte, afin que l'on puisse mieux comparer.

Personnellement je trouve comme Épiméthée que la représentation de l'évolution démographique sous forme de courbe est plus adaptée que celle sous forme d'histogramme. C'est vrai qu'entre deux dates la "courbe" n'est qu'une interpolation linéaire donc ne donne pas le nombre exact d'habitants mais simplement un nombre interpolé. Mais le lecteur qui s'intéresse à la courbe peut, je pense, comprendre que les points entre les recensements ne sont que des interpolations. Peut-être faudrait-il faire ressortir les points pour que ce soit davantage visible?

Si l'on regarde les graphiques d'évolution de population qui sont utilisés par les organismes de démographie, ce sont en général des courbes et non pas des histogrammes (personnellement je n'ai même jamais vu d'histogrammes de ce genre émanant d'un organisme d'études démographique), et parfois ce sont aussi de simples interpolation linéaires qui sont faites pour la représentation. Exemples de courbes: INED: pop. européenne, INED : pop. mondiale, INSEE: Évolution de la pop. des dépt. picards, INSEE : pop. d'une commune (en p. 5/40) (ici l'échelle temporelle n'est pas respectée).

En ce qui concerne la difficulté pour nous de faire les courbes avec un outil Timeline qui n'est pas adapté, il est possible d'automatiser certaines choses. J'avais essayé de créer un modèle qui génère les timelines mais effectivement timeline ne permet pas l'utilisation de modèles à données variables. On pourrait toutefois créer un modèle à utiliser juste en prévisualisation et qui fournirait le code timeline à utiliser. Carfois (d) 15 janvier 2009 à 08:30 (CET)

La représentation de l’INSEE utilise une ligne qui relie de gros points. Visuellement, cela signifie bien que la courbe est là pour relier les points, pour faciliter une lecture, donc le trompage de client est atténué. Mais c’est moche. Épiméthée (d) 15 janvier 2009 à 09:15 (CET)

La description de la représentation de l’INSEE que tu donnes Épiméthée, pourrait bien être la solution. On permettrait ainsi de réunir les 2 points forts qu'on les diagrammes bâtons et les courbes, à savoir la lisibilité et un nombre non interpolé des populations entre chaque points. En plus de celà, l'acceptation de ce modèle sera plus simple à obtenir de la part des wikipédiens car en définitive on s'aligne sur les conventions graphiques de l'INSEE. On évite les choix dicté par les gouts personnel de chacun, on respecte la réalité des nombres et la lisibilité est parfaite. Carfois, toi qui semble t'y entendre en timeline, si tu pouvais nous produire une 5ème proposition de diagrammes qui puisse se rapprocher des courbes de l'INSEE, se serait bien. Et pour la couleur de la courbe continuer à utiliser le vert pour faciliter la comparaison des différents diagrammes... En tout cas si ce diagrammes est réalisable, il me semble que ce serait un choix sage et difficilement contestable par la suite. amicalement--Wikialine (d) 15 janvier 2009 à 18:25 (CET)

Merci Wikialine pour tes idées. J'ai mis ci-dessus les diagrammes auxquels Épiméthée et toi avez pensé. Le plus joli à mon goût, purement sous l'aspect esthétique, est le dernier (le 6, histogramme + courbe), qui est également le plus original, mais a priori je penche plutôt pour la dernière des courbes 5, probablement car pour moi le 6 évoque des surfaces et des intégrales mathématiques et celles-ci n'ont à ma connaissance pas tellement de signification dans le cas de la population sur une durée. Mais c'est assez personnel comme impression, je n'ai au fond pas d'avis très tranché pour le choix d'un diagramme entre le 5 et le 6. Carfois (d) 16 janvier 2009 à 01:38 (CET)

Et merci Carfois pour le boulot. Là on a du choix. Je ne sais pas ce que, d’un point de vue scientifique, vaut le système courbe+bâtons, je trouve (AMHA) qu’il fait bien ressortir les vides entre deux recensements (comme entre 1936 et 1946, ou 1806-1821). Par contre ça peut faire penser à une représentation de deux données différentes (comme pour les diagrammes ombro-thermiques du climat). Sinon, sur une série complète de données 1793-2006, je trouve l’idée du point moins pertinente, vu qu’il se trouve forcément moins gros que sur celui de l’INSEE. Mais le 5 effectivement est bien. Épiméthée (d) 16 janvier 2009 à 09:34 (CET)

Idem qu'Épiméthée sur tous les points  :

• Bravo Carfois
• Le graphique 6 me choque un peu à l'œil avec le mélange bâtons/courbe
• Le graphique 5 a le mérite d'une part, de montrer et interpréter facilement l'évolution avec la courbe, d'autre part d'indiquer ainsi que les dates de calcul des différents recensements.

-- LeMorvandiau ^[blablater] 16 janvier 2009 à 10:23 (CET)

Merci Carfois pour ce travail. Mon sens de l'esthétique me fait pencher pour le 6 mais ma rigueur mathématique me fait préférer le 5 (avec dans l'ordre 5b - 5c - 5a mais sans préférence marquée). Les choses commencent à se dessiner (c'est le cas de le dire). HB (d) 16 janvier 2009 à 11:14 (CET)

A la vue des différents graphiques, je pencherais également pour le graphique 5 pour sa sobriété et sa prise en compte des dates de recenssement graces au points on a ainsi les avantages des bâtons et ceux de la courbe. A présent, je propose qu'on lance un petit vote histoire que tout le monde se prononce sur la forme la plus adequat. On aura ainsi une meilleurs adhésion au nouveau graphique et les contestataires sauront pourquoi tel choix a été fait plutot qu'un autre. Croyez moi si l'on veut tendre vers l'harmonisation des articles, il faut mettre toutes les chances de notre coté. amicalement--Wikialine (d) 16 janvier 2009 à 11:55 (CET)

L’EHESS, avec le site Cassini, utilise aussi le courbe+points [1]. Épiméthée (d)

Qu'est ce que l'on fait ? Est ce que l'on considère que l'on est d'accord, on adopte le graphique 5, c'est celui qui respecte le plus de conventions et qui semble être adopté par tous les organismes officiels. Est ce que on lance un sondage ou on décide ici d'adopter le graphique 5. amicalement--Wikialine (d) 19 janvier 2009 à 02:26 (CET)

Quelle couleur pour nos diagrammes

Pour le moment les couleurs susceptibles de convenir et respectant les normes d'accessibilité sur les couleurs sont :

Culeurs vertes

1. Code couleur : #729272 ; Pour la Timeline : #729272 rgb(0.44,0.57,0.44) ; Coefficient : 3,5
2. Code couleur : #009966 ; Pour la Timeline : #729272 rgb(0,0.6,0.4) ; Coefficient : 3,6

Couleurs neutres

1. Code couleur : #gray ou autres tons de gris...
2. Code couleur : #black ou autres tons noiratres...

Si on n'arrive pas à dégager un consensus sur le choix d'une couleur alors on lancera un petit vote ici même pour trancher la question simplement.--Wikialine (d) 6 janvier 2009 à 18:30 (CET)

Ma petite remarque en passant : je suis pour une ligne graphique homogène, et les verts peu marqués utilisés jusqu’à présent me vont tout à fait. Cependant, pour une courbe, il faut peut-être rechercher l’efficacité. Je m’explique : la courbe n’est qu’une ligne, qu’on choisisse du rouge ou du noir ne modifie pas l’aspect de la page, car la ligne occupe peu de place sur la page. Par contre, le noir (ou autre couleur) a un fort contraste, ce qui apparemment (je n’y connais rien) joue pour l’accessibilité. L’intégration à la ligne graphique peut passer par des plaques de couleur à d’autres endroits, ou par les lignes de suite (le vert 729272, que je trouve laid, serait idéal pour ça (et dans cette utilisation, sa laideur ne joue plus)). Épiméthée (d)

Il semblerais qu'il y ait un consensus sur le choix d'une couleurs qui soit dans les tons verdâtres. Maintenant reste à déterminer la couleur exactes. Tout ce que l'on peut dire c'est que niveau accessibilité, je cites : « il est recommandé de conserver un ratio de contraste de couleurs d'avant-plan et d'arrière-plan au moins supérieur à 4 ». Donc si on trouve un vert qui tourne autour des 3.6 à +4 alors pas de soucis majeur on est tout bon. amicalement--Wikialine (d) 19 janvier 2009 à 02:26 (CET)

Création d'un modèle

Lorsque l'on sera d'accord sur la forme et sur la couleur, il noufaudra étudier la possibilité de mettre en place un modèle qui puisse être utiliser facilement sur les articles. Voir si c'est faisaible... amicalement--Wikialine (d) 15 janvier 2009 à 18:38 (CET)

Je ne pense pas qu'il soit possible de faire un modèle qui affiche le diagramme avec Timeline. Cependant on peut faire un modèle qui affiche en prévisualisation le code Timeline à utiliser. J'en ai fait un: {{Démographie2/Courbe}}. Je l'ai testé avec deux exemples pris au hasard.

Le fonctionnement me semble assez simple et cela marche très bien (mis à part pour le deuxième exemple que j'ai pris où la population dépasse le million et où du coup la marge de gauche n'est pas suffisante pour afficher l'échelle sans qu'elle soit tronquée. Je corrigerai ça cette semaine si j'ai le temps, à vrai dire il n'y a aucune commune en France à part Paris qui atteigne le million donc cette limitation actuelle ne devrait pas être très gênante). Carfois (d) 19 janvier 2009 à 01:50 (CET)

Bonsoir Carfois, attends avant de te lancer dans la création d'un modèle. Car tant que l'on ne s'est pas prononcé sur le choix d'un graphique, on ne pourras pas concevoir un modèle cohérent. On devrais lancer un sondage soit au sein du projet communes de France soit au sein de la communauté afin de définitievement clore le débat sur les formes. Ensuite, tu auras tous le loisir de mettre en place un modèle. Mais pour le moment la priorité c'est le choix de la forme de graphique et ensuite le choix d'une couleur, après quoi, tu vas avoir du pain sur la planche niveau création d emodèle. amicalement--Wikialine (d) 19 janvier 2009 à 02:20 (CET)

Bonsoir Wikialine, c'était surtout pour vérifier la faisabilité d'un tel modèle. Il peut bien sûr être refait sur d'autres bases. Il me semblait important, avant de décider d'utiliser un type de diagramme qui demande quelques calculs avec Timeline, de vérifier que l'on pouvait faire un modèle pour nous simplifier la vie avec ce diagramme, car si cela avait été impossible, le choix d'un diagramme compliqué à coder aurait peut-être été à exclure. Carfois (d) 19 janvier 2009 à 02:29 (CET)

Si tu veux commencer à te pencher sur la création d'un modèle, à mon avis (je ne m'avances pas trop non plus) orientes toi de préférence vers une forme proche du graphique 5, il semblerait que ce soit celui qui réponde le plus au cahier des charge. amicalement--Wikialine (d) 19 janvier 2009 à 02:38 (CET)

C'est précisément ce que j'ai fait: {{Démographie2/Courbe}} ;-) Carfois (d) 19 janvier 2009 à 02:42 (CET)

C'est pas mal du tout. Le modèle semble efficace. Par contre, est ce que les paramètres « nb éléments échelle », « hauteur image » et « année max » sont vraiment nécessaires si ils sont calculés automatiquement, autant ne pas les afficher dans la syntaxe à mettre dans les articles. Pour le reste, la couleur verte et les carrés en noir, c'est parfait. Pour la population, il serait préférable d'inclure directement dans le modèle le formatnum afin que sur les articles on ait juste à ajouter le nombre de la population sans espace. ça évitera les différences de présentations et les données seront automatiquement bien présenté. Personnellement, moi je signe tout de suite pour l'adoption de ce modèle. félicitation Carfois. amicalement--Wikialine (d) 19 janvier 2009 à 15:43 (CET)

Clap, clap

Mais quand je vois la discussion qu'il y actuellement sur le Bistro, je sens que pas mal de monde va tiquer quant l'utilisation de ce modèle (qui est en fait plus un outil de conversion qu'un modèle)... mais bon, c'est surtout le code timeline qui serait en cause, et non cet éventuel nouvel outil .

En tous cas, bravo Carfois -- LeMorvandiau ^[blablater] 19 janvier 2009 à 16:29 (CET)

Merci pour vos commentaires. Wikialine: Oui, en effet, ces paramètres sans intérêt encombraient inutilement la doc du modèle. J'en ai supprimé 4 de la doc et ai laissé « année max » car cela peut être utile si jamais on veut faire des projections après 2010. De manière générale la doc du modèle {{Démographie2/Courbe}} est à améliorer.

En ce qui concerne le formatnum dans le modèle {{Démographie2/Courbe}}, si on l'intègre par défaut cela à l'inconvénient d'empêcher de mettre des notes (<ref></ref>) sur des chiffres particuliers. Un moyen de permettre tout ça serait d'activer le formatnum par défaut et de le désactiver en option, par exemple avec un paramètre « no formatnum » à utiliser si on veut mettre des notes sur certains chiffres. Si cela parait une bonne idée (si l'utilité compense l'inconvénient d'avoir un nouveau paramètre) je peux l'implémenter.

LeMorvandiau, oui, c'est vrai que le code Timeline n'est pas beau du tout dans les articles (ce pourrait être bien comme l'écrit Moez sur la discussion du bistrot que tu cites, si l'on pouvait inclure des sous-pages de la page de contenu dédiées au code Timeline, mais il n'est pas possible d'inclure une sous-page d'article comme on peut cependant le faire dans le domaine de nom des utilisateurs ou des modèles). Je pense qu'en attendant de trouver une solution à ça on pourrait encadrer le code Timeline par des lignes du type:
<!---------- début de graphique en code Timeline, suite de l'article plus loin ------->
blabla Timeline ici
<!---------- fin du graphique en code Timeline --------------------------------------->
Ainsi le code Timeline serait plus isolé et perturberait moins les rédacteurs. Carfois (d) 19 janvier 2009 à 17:06 (CET)

Il faut éviter d'ajouter un paramètre « no formatnum », ce n'est pas nécessaire. Je reste convaincu qu'il vaut mieux l'intégrer directement car il ne faut pas oublier que ce graphique ne sera qu'une extension des données démographiques présentent dans le tableau d'évolution graphique où là on peut déjà ajouter des références. Sans compter que si quelques dates ont besoins d'un référencement particuliers c'est que vraiment elles sortes de l'ordinaire et donc celà vaudra un développement au sein d'un paragraphe dans la section démographie. Surtout que au niveau des références, il y de plus en plus d'intégration de modèles pour références avec donc un sérieux risque potentiel de faire buguer inutilement la timeline qui reste toujours un peut senssible dans son fonctionnement, il faut donc éviter les conflits de scripts, n'autoriser que l'ajout de données numériques c'est amplement suffisant et ça nous met à l'abris de certains disfonctionnements. Ensuite je serais d'avis de conserver donc les couleurs que tu as choisi, elles sont parfaites. Par contre tu devrais les mettre par défaut et ajouter un paramètre couleur comme ça, le modèle pourra servir pour d'autres sorte d'articles autres que ceux de communes françaises. amicalement--Wikialine (d) 19 janvier 2009 à 17:56 (CET)

+1 à ce que dit Wikialine sur l’ajout de notes dans le graphique, d’une part ce n’est pas courant, d’autre part il y a deux usages possibles : le sourçage du chiffre, qui normalement l’est dans le tableau, donc cet usage est exclu ; un commentaire, qui a plus sa place dans un paragraphe en-dessous de la courbe. Donc sauf raison supplémentaire d’inclure des notes, ne le faisons pas. Épiméthée (d) 19 janvier 2009 à 20:22 (CET)

Wikialine et Épiméthée, je ne suis pas sûr de comprendre ce dont vous parlez : aucun chiffre de population n'est affiché dans le graphique, seuls les points sous forme de carré, les traits qui les relient, ainsi que l'échelle à gauche sont affichés. Je ne comprends pas ce que tu veux dire, Wikialine, en parlant de formatnum pour le graphique et j'avais cru initialement que tu parlais du modèle Démographie2 de tableau. N'était-ce pas pour le tableau que tu parlais de formatnum à 15:43? C'est uniquement concernant le modèle Démographie2 (tableau) et non pas le modèle Démographie2/Courbe (courbe) que j'avais répondu en suggérant de pouvoir désactiver un éventuel formatage automatique des chiffres pour le cas où l'on voudrait mettre des notes, au moyen d'un paramètre « no formatnum ». Il est vrai que l'on devrait discuter du modèle de tableau plutôt sur Tableau démographique.

Concernant le modèle Démographie2/Courbe, il ne supporte pas les données de population avec références. Si l'on fait du copier-coller des données d'un tableau, pour un bon fonctionnement il faut d'abord supprimer les éventuelles références présentes sur les chiffres de population avant de pouvoir lancer le modèle Démographie2/Courbe. Ce modèle Démographie2/Courbe ne supporte pas non plus les données de population qui contiennent des espaces. Seuls les chiffres de population sans espace, ou bien ceux qui sont sous la forme {{formatnum:123456}} sont acceptés pour générer le code Timeline du graphique. Tout autre format est ignoré et les points concernés ne seront pas inclus dans le code Timeline généré, ils ne seront donc pas affichés par le Timeline, ni non plus la courbe à l'endroit de ces points. Concernant les espaces dans les chiffres, j'aurais aimé que le modèle les accepte mais je n'ai pas trouvé comment faire. Carfois (d) 19 janvier 2009 à 22:11 (CET)

Je ne parlais pas du tabeau démographique, mais bien du Modèle:Démographie2/Courbe. Mes propos portaient sur le formatnum suite à ce que tu as inscrit sur le modèle, à savoir :

Il suffit de copier-coller les lignes du tableau {{Démographie2}} puis de modifier ainsi:

• utiliser le modèle Démographie2/Courbe à la place de Démographie2 ,
• ajouter les 3 paramètres obligatoires ci-dessous et éventuellement les paramètres facultatifs ,
• modifier si nécessaire le format des chiffres de population afin qu'ils soient tous ou bien sans espace ou bien de la forme {{formatnum:1234567}}, et sans autre texte (pas de références).

Pour le 3ème point, il ne faut pas mettre d'alternative et inclure directement le formatnum. C'est ce dont j'ai voulu expliquer. Pour les références on est d'accord, il ne faut absolument pas utiliser de références dans le modèle Démographie2/Courbe. On est donc bien d'accord je ne parle pas du modèle du tableau démographique qui est un autre débat, je l'ai juste évoquer pour préciser mes propos concernant le non ajout de références dans le modèle Démographie2/Courbe. Mais sur ce point là on est tous d'accord. En tout cas, il faut éclaircir ce 3ème point, les utilisateurs ne devront mettre que le nombre de population sans espace du genre 1234567 et non {{formatnum:1234567}}, pour les raisons que j'ai évoqué plus haut. C'est un détails qui permettra une meilleur homogénité du modèle sur les articles. Pour les la permission d'espace entre les chiffres, ne te complique pas la vie, les nombre doivent tous être mis sans espace, on l'écrit clairement sur la page du modèle, et il n'y a pas de raison que les utilisateurs ne le comprennent pas. Pour un autre modèle j'avais fait comme ça et il n'y a jamais eut de véritables incompréhensions. Par contre comme je te l'ai dit il est impératif d'ajouter un paramètre que l'on pourrait appeler « couleur » afin que les utilisateurs puisse mettre la couleur de leur choix pour la courbe. Par contre, il faut laisser le vert que tu as choisi comme couleur par défaut (voir l'exemple que j'ai faire sur {{Démographie2/Courbe/Code Timeline}}, je te l'aisse peaufiner). Ainsi le modèle sera utilisable non seulement sur les articles de commune mais également sur d'autres articles traitant d'un autre sujet. amicalement--Wikialine (d) 20 janvier 2009 à 00:53 (CET)

Wikialine, je comprends maintenant ce que tu voulais dire. Pour ce qui est de laisser le choix à l'utilisateur entre la syntaxe sans espace des chiffres de population ou celle du type {{formatnum:1234567}}, à mon sens il est préférable de laisser ce choix, l'une ou l'autre des syntaxes pouvant être plus pratique selon l'utilisateur. Cela n'impacte absolument pas l'homogénéité du modèle sur les articles puisque ce modèle n'est pas destiné à être mis dans les articles. C'est seulement le code Timeline généré par le modèle qui est destiné à être mis dans les articles. Que l'utilisateur utilise la syntaxe 1234567 ou qu'il utilise {{formatnum:1234567}} ne change rien: le même code Easytimeline est généré.

Pour la couleur en paramètre, sachant que la couleur de la courbe n'est définie qu'à un seul endroit dans le code Timeline, et qu'elle est sous une syntaxe spéciale type rgb(0,0.6,0.4),je pense qu'il est préférable d'indiquer dans la doc du modèle comment modifier cette couleur directement dans le code Timeline, plutôt que de mettre un paramètre supplémentaire qui devrait de toutes les façons être aussi de la forme rgb(0,0.6,0.4) (je ne sais pas faire une conversion automatique de #009966 en rgb(0,0.6,0.4) dans le modèle). J'ai ajouté ceci dans la doc du modèle et ai renommé la couleur Timeline en "couleurcourbe" au lieu de "vert", ce qui montre mieux qu'on peux modifier ce paramètre de couleur dans le code Timeline qui a été généré. Qu'en pense-tu?

Dans le modèle, c'est la couleur d'affichage du texte du code Timeline que tu as mis sous forme de paramètre, pas celle de la courbe, je ne pense pas que c'est ce que tu voulais faire. Amicalement, Carfois (d) 20 janvier 2009 à 15:10 (CET)

Pour le formatnum, on peut laisser tel quel, c'est pas un soucis, c'était histoire d'alléger la syntaxe dans les articles. Pour ce qui est de la modification de la couleur, à la rigueur on pourrait étudier l'idée d'ajouter 3 paramètres du genre <code>rgb({{{couleur-rgb1|0}}},{{{couleur-rgb2|0.6}}},{{{couleur-rgb3|0.4}}})</code>. Disons quelque chose dans cet esprit, là ausi c'est un détails mais si on a la possibilité de rendre ce modèle plus générique au passage, c'est pas plus mal. amicalement--Wikialine (d) 20 janvier 2009 à 16:04 (CET)

J'ai ajouté un paramètre "couleur de la courbe" qui permet à tout utilisateur de modifier la couleur de la courbe sans même retoucher le code EasyTimeline généré. Si je n'ai mis qu'un seul paramètre plutôt que trois, c'est à la fois pour plus de simplicité et à la fois pour permettre à l'utilisateur de choisir aussi une des couleurs EasyTimeline prédéfinies (blue, red, black, etc.). Ce modèle permet en réalité de faire à peu près n'importe quelle courbe à interpolation linéaire dont l'échelle verticale commence à zéro, population mais tout aussi bien n'importe quoi que l'on voudrait mettre à la place. Carfois (d) 21 janvier 2009 à 00:07 (CET)

Le modèle est PARFAIT. Cette fois on tient le bon bout. Par contre, je n'aime pas trop la parenthèse suivante, placé en dessous du titre du diagramme : « (Élaboration graphique par Wikipédia, interpolation linéaire entre les recensements) ». En effet, c'est comme si je faisais un graphique avec un tableur du genre excel et que j'en fasse une impression écran afin d'en faire une image que je mets sur WP et que ensuite sur l'article où j'ai mis mon image de graphique issus d'excel, et bien je marque sur l'article cette courbe a été faite avec Excel.... Cela n'a pas d'intérêt majeur semble-t'il. ça allourdi inutilement la page de l'article. Ce serait souhaitable de retirer cette parenthèse. Autre chose, je serais d'avis de changer le nom du Modèle:Démographie2/Courbe en un nom plus explicite du genre (c'est un exemple) Modèle:Générateur de courbe démographique. Car pour un novice, il risque de mal comprendre que ce modèle n'est pas un simple copier-coller des paramètres avec le remplissage de ceux-ci. En tout cas encore bravo pour ce modèle. amicalement--Wikialine (d) 21 janvier 2009 à 01:33 (CET)

Je suis mauvais juge pour la perfection du modèle, mais bravo également. Je suis Wikialine sur le texte entre parenthèses, mais je ne le supprime pas quand je le trouve... si ça fait plaisir à certains. Et pour le titre du modèle, ce ne serait pas plutôt Modèle:Générateur de code de courbe démographique si j’ai bien compris ? Épiméthée (d)

Je propose de renommer le modèle en Modèle:Code de courbe démographique qui est plus court et presqu'autant explicite, qu'en pensez-vous? Modèle:Démographique2/Courbe ne sera plus alors qu'une redirection qui fournira un raccourci pratique dans le cadre d'un copier-coller depuis un tableau fait avec Modèle:Démographique2. Par ailleurs je prévois d'ajouter un paramètre optionnel pour le nombre de pixel par année (par défaut 3px), ce qui permettra de faire des courbes plus larges lorsque la plage temporelle est courte. Carfois (d) 21 janvier 2009 à 13:12 (CET)

Très bien. Je l’ai testé sur Saint-André-les-Alpes et Thorame-Haute, ça m’a l’air de fonctionner, mais il manque l’année 1831 dans le modèle. J’ai corrigé (mes 2 ¢). Épiméthée (d)

Je crois que l'on devrait adopter le nom {{Générateur de code de courbe démographique}} proposé par Épiméthée. Il est légèrement long mais au moins il est très explicite et évitera donc que certains le considère comme un modèle classique qui ferait aparaître une courbe en remplissant des simples paramètres. N'oublions pas qu'il faut toujours se placer dans la peau de nouveaux utilisateurs découvrant le modèle ou étant peu habitué. C'est ce que recommande les conventions portant sur les noms. Il vaut mieux un nom un peu long mais très explicite qu'un nom trop court et moins compréhensible. Autre détail également et après ce sera définitivement parfait, je crois que l'on devrait modifier la présentation du code généré. En effet, lorsque l'on met et rempli le modèle dans un article, il apparait donc le code de la courbe à recopier dans l'articles mais avant cela il y a toutes les recommandations. A mon avis, ces recommandations mériteraient d'être placées en dessous du script de la courbe. Et pour éviter les incompréhensions, écrire seulement en haut juste avant le script à copier-coller et bien écrire en gros en caractère gras (par exemple) : « COPIEZ-COLLEZ LE SCRIPT SUIVANT DANS L'ARTICLE POUR OBTENIR UNE COURBE DEMOGRAPHIQUE : ». C'est une sécurité supplémentaire pour éviter que certains ne comprennent pas comment fonctionne ce modèle. amicalement--Wikialine (d) 21 janvier 2009 à 20:15 (CET)

J’ai toujours pensé que quelqu’un de pédagogue dans une équipe, c’était utile. Encore mes 2 ¢ (aujourd’hui, ça fait 4). Épiméthée (d)

J'ai modifié et renommé selon vos suggestions. Pour l'année 1831, je n'ai pas réussi à voir où elle manquait : quand j'ai essayé sur Saint-André-les-Alpes et Thorame-Haute elle y était. Sinon que veut dire "mes 2 ¢", c'est la première fois que je rencontre cette expression? Il y aurait-il une allusion au c barré musical? Carfois (d) 22 janvier 2009 à 00:16 (CET)

C'est tout bon, le modèle est parfait à présent. Carfois félicitation. amicalement--Wikialine (d) 22 janvier 2009 à 00:44 (CET)

mes deux ¢ : mes deux centimes, ma petite contribution . L’année 1831 manquait dans la page du modèle, à l’endroit où tu met à disposition une syntaxe complète pour exemple et copier-coller. Je l’ai ajoutée. Épiméthée (d) 22 janvier 2009 à 08:47 (CET)

ok, merci Épiméthée! De mon côté je viens de corriger une erreur dans la formule qui calcule pour quelles graduations il faut afficher la légende à gauche. Cela marchait dans le cas des exemples (un peu par hasard) mais pas dans le cas général. Carfois (d) 22 janvier 2009 à 10:24 (CET)

La possibilité pour le contributeur de modifier la couleur par défaut de la courbe/du point est à la fois inutile et source à fort potentiel de soucis d'acessibilité et de conflits éditoriaux tous aussi inutiles. --Lgd (d) 22 janvier 2009 à 12:23 (CET)

Je m'étais fait la même remarque sans pour autant réagir car de toute manière, l'utilisateur du code généré aura toujours la possibilité de modifier ladite couleur... Mais pour suivre l'idée de Lgd, insérer la couleur en variable rappelle, et met en valeur, la possibilité de modifier la couleur de la courbe, et ainsi de voir apparaître des couleurs différentes d'un article à l'autre, voire des couleurs plus que fantaisistes .

Ne pas mettre ce paramètre laisserait cette possibilité plus discrète, et donc moins utilisée, non ?

-- LeMorvandiau ^[blablater] 22 janvier 2009 à 13:24 (CET)

Sans le paramètre couleur, ce modèle devient un modèle spécifique au projet commune de France. Et ceux qui voudront produire les mêmes courbes mais pour d'autres sorte d'article avec une charte graphique différente et avec donc des couleurs différentes, alors ils risquent d'avoir plus de mal à modifier la couleur. Certains ont du mal à modifier les couleurs exprimées en RGB... Disons qu'on avait une occasion de produire un modèle général pour tous. En tout cas je ne m'opposes pas à son retrait, si c'est ce que la majorité souhaites. Par contre, on devrait garder une trace du modèle actuel pour les autres projets qui pourraient être tentés de faire comme nous. À l'avenir, il y aura surement des participants d'autres projets qui seront intéressés par ce modèle et qui voudront, comme nous, produire facilement leurs courbes avec leurs propres couleurs. Pour ce qui est du nom du modèle du coups, là aussi, le nom peut également être remis en cause. Alors on peut lui donner un nom du genre modèle:courbe démographique pour commune. On évitera ainsi le risque de voir appraître comme cela est le cas pour plein de modèle proches, une liste de modèle intitulé modèle:courbe démographique 1, puis courbe démographique 2, modèle générateur courbe démographique pour pays, courbe démographique pour département (on peut imaginé un tas de de modèle dérivé suivant les projets concernant par des aspect démographiques... Pour moi, le modèle actuel est abouti, mais si on revient en arrière sur l'aspect généraliste du modèle et bien ce n'est pas graves, je suivrai la tendance majoritaire. Je tiens à voir aboutir ce modèle même si ça devient du coup un modèle spécifique pour les communes uniquement. amicalement--Wikialine (d) 22 janvier 2009 à 17:17 (CET)

Je ne voyais pas vraiment de raison de bloquer ou non la colorisation, mais je suivrais le raisonnement de Wikialine. Faire un modèle de générateur de courbe, au moins pour les courbes démo, seul et unique avec une bonne publicité est le meilleur moyen de centraliser les améliorations. Épiméthée (d) 22 janvier 2009 à 17:37 (CET)

Arf, j'aurais dû rester sur ma non réaction alors , car j'avais oublié la possibilité de rendre ce générateur général et non dédié aux communes/à la démographie...

À la rigueur, on peut maintenir le paramètre ; et dans la documentation, on peut inciter à utiliser une couleur précise pour telle ou telle utilisation.

-- LeMorvandiau ^[blablater] 22 janvier 2009 à 18:05 (CET)

+1 avec la proposition de LeMorvandiau. Sur la documentation du modèle mais aussi sur les articles types du projet commune de France, on peut citer le modèle en retirant le paramètre couleur, ce qui fait qu'il sera présent pour les autres projets qui veulent l'utiliser mais pas pour les articles de communes qui n'en ont pas besoin puisque on utilisera la couleur par défaut du modèle qui est verte, ça donnera la syntaxe présente ci-dessous sur la documentation par exemple. amicalement--Wikialine (d) 22 janvier 2009 à 18:12 (CET)

== Pour les articles de communes ==
{{Générateur de code de courbe démographique
 | max échelle                         = 
 | incrément échelle                   = 
 | une gradation principale toutes les = 
 | hauteur additionnelle               = 
 | année min                           = 
 | année max                           = 
 | marge de gauche                     = 
 | année |population
 | année |population
 | année |population
 | année |population
}}

Non. En termes de charte graphique, il n'y a aucune raison que les courbes soient vertes ici et roses là-bas. Ou alors, vous me trouvez une argumentation en béton là-dessus. Et vous la développez quelque-part en dehors du projet Communes de France, puisque c'est un modèle de portée plus générale dont la mise en forme concerne d'autres projets.

Tout ce que ces paramètres vont faire en réalité (parce que vous n'allez sans doute pas comprendre ni donc modifier le modèle), c'est aller à l'encontre de WP:COULEUR. C'est à dire concrètement créer des occasions supplémentaires de perdre du temps et de dépenser des ressources wikimedia en discussions stériles sur celui préfère le rose et celle qui préfère le moins rose. Mais bon, c'est vous qui voyez si vous voulez vraiment produire un modèle utile ou juste vous faire plaisir. --Lgd (d) 22 janvier 2009 à 19:02 (CET)

Lorsque j'avais rajouté le paramètre "couleur de la courbe" dans le modèle, cela ne me paraissait pas très utile mais je l'avais fait pour répondre à un besoin, ou du moins une demande qui avait été exprimée. Etant données les nouvelles réflexions sur le sujet je l'ai supprimé (pour l'instant uniquement de la documentation donc il reste pour l'instant là mais tout à fait caché). J'ai juste mentionné en remarque comment modifier la couleur, ce qui permet d'avertir que c'est vivement déconseillé, qu'il existe des chartes graphiques et fournir les liens sur l'accessibilité et la recommandation Wikipédia sur les couleurs. La pédagogie me semble être le mieux à faire. Si une couleur est officiellement adoptée pour la courbe dans le cadre d'une charte graphique des communes française, il serait possible aussi d'ajouter dans le code Timeline, à côté de définition la couleur, un commentaire du type "# NE PAS MODIFIER : couleur de la charte graphique des communes de France".

A noter que le modèle {{Pyramide des âges 2}}, très utilisé dans les articles de communes, possède un paramètre de couleur et que l'on observe des couleurs variées avec deux grandes tendances d'utilisation: le bleu-gris, exemple Marseille#La_population_marseillaise et le vert clair, exemple Vannes#Pyramide_des_âges. (on trouve également souvent le bleu vif, cf. Toulouse#Pyramide des âges, Guimiliau#Démographie, parfois le violet Talmont-sur-Gironde#Pyramide_des_âges, Fouras#Évolution_de_la_population, le vert moins clair cf. Beauvais#Démographie, le bleu moyen cf. Mende_(Lozère)#Pyramide_des_âges, etc.).

A propos d'homogénéité entre les articles, sur ce premier exemple de Marseille, le tableau d'évolution démographique réalisé sans modèle montre que lorsque les modèles ne permettent pas d'avoir la couleur désirée, certains choisissent de se passer du modèle afin d'utiliser leurs couleurs, ce qui au final n'est pas forcément mieux pour l'homogénéité globale et la maintenance des articles. Donc forcer les choix de présentation dans un modèle a sur ce plan des avantages mais aussi des inconvénients.

Ce modèle n'étant qu'un outil, je pense qu'il peut rester tel quel avec la couleur adaptée à la charte graphique des communes françaises. Dans l'usage annexe et quantitativement marginal qui pourra en être fait pour des populations de département, de région, d'entités géographiques non françaises, etc., la couleur pourra être modifiée manuellement par un contributeur averti. Carfois (d) 23 janvier 2009 à 03:16 (CET)

Désolé, mais j'ai essayé cet outil, c'est vraiment trop compliqué, trop de manipulations pour un rendu pas réellement meilleur au diagramme d'origine mis à part la correction des écarts entre dates. Pas d'avancée justifiant d'adopter ce modèle pour moi, il vaut mieux garder l'histogramme pour l'instant.--Cyrilb1881 (d) 22 janvier 2009 à 19:26 (CET)

Merci pour cet avis, même si je ne partage pas ton opinion sur l'intérêt de continuer à mettre des histogrammes plutôt que des courbes. J'ai créé ce modèle de courbe car les histogrammes d'évolution démographique sont à mon sens inadaptés à ce qu'ils représentent, contraires à l'usage habituel des représentations d'évolution d'une population, peu esthétiques (gros blocs verts, peut-être beaux toutefois pour les gens qui adorent cette couleur), et, à mon avis, abaissent l'image de qualité de Wikipédia. Sans compter qu'avec les pyramides des âges que l'on trouve généralement juste ensuite dans les articles cela fait beaucoup de diagrammes à bâton à la suite et que c'est moins lourd de varier avec une courbe.

Pour la complexité il est sûr que ce nouveau modèle-outil n'est pas la panacée tout comme d'ailleurs EasyTimeline n'est pas la panacée pour faire autre chose que des frises chronologiques. D'ailleurs je ne sais pas ce qui s'éloigne le plus de la conception d'origine d'EasyTimeline, les histogrammes (où l'échelle de temps est utilisée pour mettre des populations et où le temps n'est quant à lui plus à l'échelle), ou bien les courbes (où l'échelle de temps reste l'échelle de temps mais où le reste est un peu fastidieux).

Je suis loin d'être le seul à préférer les courbes aux histogrammes, cf. par exemple la courbe en .svg sur Royan#Évolution_de_la_population. Cette dernière courbe a ses avantages et qualités propres mais on peut noter au passage qu'elle est peu accessible (vert très clair) et bien plus compliquée à créer. D'autres cherchent visiblement à faire des courbes avec l'histogramme, par exemple en le compactant, cf. Villennes-sur-Seine#Evolution démographique ou Vaux-Marquenneville#Démographie, ou encore en supprimant la légende de certaines années cf. Champlan#Évolution démographique (ce qui est ici désastreux en termes d'exactitude puisque ces histogrammes ne sont pas à l'échelle sur le temps).

Ce nouveau modèle répond donc, je pense, à un réel besoin. Les contributeurs qui le trouveront trop compliqué ne l'utiliseront pas, tout simplement, de même que ceux qui trouvent la création d'histogramme trop compliquée ne créent pas d'histogramme. Carfois (d) 23 janvier 2009 à 03:16 (CET)

Sans Timeline

Je rejoins cette discussion en cours de route car je viens d'être confronté récemment au problème des diagrammes dont il est question ici. Ma proposition est peut-être hors-sujet et cela a peut-être déjà été débattu ailleurs mais au moins j'aurai votre avis. Ma proposition est d'utiliser des graphiques déposés sur Commons et réalisés avec un logiciel de tracé de graphique libre tel que Gnuplot. Voici donc une liste d'arguments reprenant la plupart des points soulevés dans cette discussion :

Difficulté

La réalisation du graphique sera peut-être un petit peu plus technique qu'avec Timeline et le modèle {{Générateur de code de courbe démographique}} présenté plus haut, mais d'un autre côté, la quasi totalité des graphiques, images, schémas, etc. de Wikipédia nécessite souvent l'intervention de contributeurs ayant quelques connaissances en la matière.

De plus, l'utilisation d'un script « type » permettrait par un simple copier-coller de réaliser le graphique avec Gnuplot sans avoir besoin de trop s'y connaître. Quelques commentaires dans le script permettraient aussi de modifier aisément un ou deux paramètres.

Charte graphique

L'utilisation du script « type » permet de réaliser des graphique respectant tous par défaut la charte retenue (tout en laissant la possibilité de faire des modifications pour une utilisation différente).

Pour faciliter l'homogénéité des diagrammes, il est possible de copier le script sur la page du diagramme sur Commons (cela pourrait être fait par l'ajout sur Commons d'un petit modèle précisant par exemple : « ce graphique a été réalisé pour le projet Communes de France avec Gnuplot en utilisant le script suivant : »).

D'autre part, une fois la charte choisie, il ne devrait pas être trop difficile d'écrire un script qui permette de la reproduire correctement.

Courbe versus histogramme

L'utilisation de graphiques déposés sur Commons permet de switcher facilement entre l'affichage en courbe et celui en histogramme (en présentant la courbe par défaut) grâce au modèle {{Animation}}. De plus, il est possible de réaliser les deux courbes d'un seul coup avec le même script Gnuplot en ajoutant deux lignes supplémentaires.

Lisibilité du code de l'article

Évidemment, cette méthode permet d'éclaircir considérablement la source de l'article par rapport à Timeline. Cela me semble être un point important car le graphique reprant souvent des données déjà présentes dans l'article et n'apporte pas beaucoup d'information supplémentaire par rapport au nombre de caractère qu'il ajoute à la source.

Exemple

Comme je commence à être un peu long, je termine par un exemple qui reste à améliorer évidemment. J'ai essayé tout ça sur l'article de Weitbruch.

Voilà ce que ça donne (en reprenant les couleurs proposées plus haut et l'affichage version graphique 5) :

Histogramme →

← Courbe

-- Tzeentch ✉ 22 octobre 2009 à 23:07 (CEST)

L'idée est intéressante. Reste à savoir si la rédaction d'un tutoriel clair puisse permettre la création de ces images facilement. Par ailleurs, l'un des soucis que je vois dans tous cela est le nombre de communes. Il y a pour la France environ 36 600 communes. Ce qui représente la création donc de (36 600 x 2) 73 200 images, soit 36 600 images d'histogrammes et 36 600 images de courbes. A coté de cela quand bien même on réussi à créer ces images, il faudra avec le temps toutes les mettre à jour. Car il va y avoir de nouveaux recensements... Cette solution d'image ne peut être généralisée que si on trouve un moyen de les créer automatiquement à la volé et un moyen de les mettre à jour facilement... C'est loin d'être simple tout cela. Image ou timeline, les 2 solutions se valent. Dans l'immédiat je ne vois pas de solutions miracles. Si ce n'est peut être la généralisation des timelines produites automatiquement. Ce qui est crédible vu que c'est un simple script informatique et non un fichier image. Après reste à créer un bot qui prélève les données démographiques quelques part soit dans une future base de donnée soit sur un site externe (comme l'INSEE) et que ce bot mettent à jour automatiqueme les cripts informatiques des timelines dans les articles de communes. En tout cas toutes solutions et idées sont bonnes à prendre afin de faire avancer le débat. amicalement--Wikialine (d) 23 octobre 2009 à 00:17 (CEST)

Je trouve aussi cette proposition tout à fait intéressante et qu'il faut a priori en laisser l'usage ou non à l'appréciation des contributeurs, au cas par cas.

• Le fait de pouvoir visualiser ou bien la courbe ou bien l'histogramme permet probablement d'être consensuel entre les partisans de la courbe et ceux de l'histogramme, et a même une vertu pédagogique.
• Pour le lecteur, qu'il y ait un script Timeline ou une image sur commons ne change pas grand chose, dans les deux cas son navigateur télécharge et affiche image sur la page. C'est juste à mon avis un peu mieux d'avoir un .svg (ce que créé Gnuplot) qu'un .png (ce que créé Timeline). Personnellement les deux choix, Timeline ou image, me paraissent valables. A noter que sur l'article de Royan, il y avait eu un diagramme image .svg, mais que celui-ci a ensuite été remplacé par un diagramme Timeline (par toi qui viens de répondre avant moi, Wikialine!).
• Si l'idée est avant tout d'éviter de mettre du code dans le texte des articles et qu'on se contente d'un .png, il est tout à fait possible de mettre l'image générée par le Timeline sur Commons, et il serait facile de créer un modèle similaire à {{Générateur de code de courbe démographique}} qui génèrerait des histogrammes (Générateur de code d'histogramme démographique) pour les partisans des histogrammes (en ce qui me concerne je préfère les courbes pour les évolutions démographiques).
• Concernant Gnuplot, je ne vois aucun inconvénient à ce qu'il soit utilisé, le résultat est bien, mais je suis sûr que peu de gens prendront la peine de faire des graphes avec cet outil et de mettre à jour ceux générés par cet outil. Déjà l'utilisation du modèle {{Générateur de code de courbe démographique}} est vue comme quelque chose de bien compliqué par beaucoup de contributeurs, qu'en sera t-il pour utiliser un outil comme Gnuplot, qui nécessite d'être relativement à l'aise avec l'informatique de façon générale, de prendre la peine et le temps de télécharger et d'installer ce logiciel, apprendre à s'en servir, puis ensuite pour chaque article de générer les images et les uploader sur Commons? Il me semble que l'usage de Gnuplot ne pourra de fait être que marginal sur les 36000 communes.
• Un détail: dans l'article de Weitbruch, je verrais plutôt la courbe en taille 500 que 400, pour une meilleure lisibilité et une plus grande homogénéité avec les diagrammes des autres communes. Au fait, c'est une bonne idée, je pense, d'avoir fait ce diagramme Gnuplot dans un aspect graphique très homogène avec les aspects graphiques utilisés sur les articles de la plupart des autres communes. -- Carfois (d) 23 octobre 2009 à 01:48 (CEST)

Merci pour vos commentaires.

• Concernant un tutoriel, je ne pense pas que cela soit un problème. Cela ce résumerait à expliquer comment copier-coller le script dans un fichier et lancer gnuplot sur ce fichier. Une petite remarque sur les paramètres modifiables (intervalle du tracé et échelle) ne devrait pas être trop compliqué.
• Pour le problème des mises à jour, on le retrouve pour pas mal d'autres sections des articles des communes : il faut mettre à jour les tableaux de population, les pyramides des âges, le tableau des maires, éventuellement les données économiques… comme vous le savez sûrement mieux que moi, tout ça ce fait doucement et on peut envisager que parmi les bonnes âmes qui s'y collent, certains pourront mettre les tableaux à jour au passage. D'autre part, comme le script créant le graphique génère en même temps la courbe et l'histogramme, la maintenance n'est pas tout à fait doublée. Tout ça sans compter les articles où les graphiques de démographie ne seront probablement pas nécessaires (très petites communes), où les ébauches qui n'en nécessiteront peut-être pas avant un moment.
• Comme le dit Wikialine, l'idéal serait d'automatiser tout ça. Pour la partie « création des graphiques », cela me paraît réalisable et je pense qu'en travaillant un peu dessus, il serait envisageable d'écrire un script en Perl ou Python qui récupérerait les données, soit sur les articles, soit sur une base de donnée officielle et qui créerait le script gnuplot en adaptant l'échelle et qui finalement créerait les deux images. Par contre, pour ce qui est du dépôt sur Commons, je ne connais pas le fonctionnement des Bots de médiawiki et je ne sais pas si ce dépôt est automatisable. Je ne sais pas non plus si Commons « apprécierait » de voir arriver 72 000 images similaires d'un seul coup ?
• Bien sûr avant de lancer une machinerie d'une telle ampleur, il faudrait attendre d'être sûr de la charte graphique et améliorer le script gnuplot en conséquence… et éventuellement anticiper sur certains besoins particuliers (ajout de labels…).

Voilà pour mes 2 ¢. -- Tzeentch ✉ 23 octobre 2009 à 21:47 (CEST)

Usage de modèles mis en sous-page

Quelque soit le modèle de diagrammes adopté pour l'ensemble des articles de commune. Il est à présent important de débattre sur l'opportunité d'utiliser ou non des sous page qui accueillent les scripts des graphiques afin de rendre les pages d'édition des articles de communes plus fluide et moins rebutante par les nouveaux rédacteurs sur les articles comme l'a évoqué HB plus bas. Moi personnellement je trouve l'idée assez bonne. Et cela se fait déjà, il me semble sur des WP étrangères. Et vous qu'en pensez-vous. amicalement--Wikialine (d) 12 mars 2009 à 00:09 (CET)

Résultat du sondage sur les graphiques de 0 à 6

Le sondage suivant Wikipédia:Sondage/Diagrammes démographiques est à présent terminé. Il y a eut 25 votants. Les graphiques les plus appréciés par ordre de préférence sont : 5 > 4 > 2 > 1 > 0 > 6... En conclusion, la communauté souhaite comme diagramme démographique ajouter au sein des articles de communes françaises, le graphique 5. Le modèle mis au point par Carfois, à savoir le modèle suivant {{Générateur de code de courbe démographique}}, convient pour produire des graphique de type 5. amicalement--Wikialine (d) 10 mars 2009 à 18:17 (CET)

Commentaires

Laisser un panel pertinent de modèles

Mais la pertinence des graphiques dépend aussi des communes donc laisser un choix complet serait encore mieux, non ? (copie du commentaire joint déjà à mon vote : j'étais le premier votant). Cela dépend par exemple de l'amplitude de développement démographique de la commune : par exemple les courbes me semblent plus justifiées dans le cas d'une évolution démographique très fluctuante mais beaucoup moins dans le cas d'une relative stabilité sur toute la longueur des données. GabrieL (d) 11 mars 2009 à 19:21 (CET)

en cas de faible variation, tu souhaiterais quoi ? Un autre type de graphique (pas génial pour l'homogénéité des pages) ? Pas de graphique du tout ? Il mesemble en effet que le diagramme n'a pas à être obligatoire s'il n'apporte pas d'information pertinente. HB (d) 11 mars 2009 à 19:52 (CET)

Avant de continuer, je tiens à dire que j'ai des diplômes universitaires de statistiques et j'ai travaillé dans les analyses statistiques, cela crédibilisera un minimum mon discours.

Pas de graphique du tout peut être une solution comme une autre pour une commune sans ou avec peu de variation. Pour les autres communes, les histogrammes me semblent bien plus indiqués en cas de variation passagère, je pense à des communes qui ont connu un élément particulier (guerre, reconstruction - et il y en a énormément) et n'ayant qu'un décrochement sur un ou deux recensements seulement et où une courbe lissant les données entre chaque recensement est contre-indiqué. Exemple des communes entre les deux recensements de 1936 et de 1946, elles commenceraient à baisser dès 1936 alors qu'elles ont probablement pour certaines d'entres elles connu une progression encore jusqu'à 1942 ou 1943 ou même 1944. Je pense aussi aux autres guerres de 1914-1918, 1870-1871 et même jusqu'à la révolution ou les guerres napoléoniennes. Là où les courbes me semblent les plus indiquées sont les communes dortoirs ayant grossi brutalement ou alors des communes "mortes pour la France" ayant perdu les 9/10 de leur population et n'ayant pas regrossi depuis. Je pense aussi que les analyses faites à partir de ces constructions statistiques peuvent aussi déterminer le graphique à suivre. Pour l'homogénéité des pages, on a rarement les 36 000 communes de Wikipédia sur le même écran ;-) L'idéal serait bien un graphique affiché sur la page et pour lequel on pourrait afficher l'autre modèle proposé simplement en cliquant dessus ;-) Dans tous les cas, on pourrait conserver un modèle de graphique dans deux ou trois types différents, cela respecterait une certaine homogénéité tout en permettant aux rédacteurs de choisir le graphique le plus adapté à la situation. GabrieL (d) 11 mars 2009 à 20:37 (CET)

Par expérience en tant que rédactrice sur les articles de commune, j'ai constaté que une seule forme de graphique (à courbe ou à baton, peu importe) peut parfaitement être utilisée sur tous les articles du moment que l'on adapte l'écjelle voilà tout. Pour éviter les incompréhension et avoir des articles homogène, l'usage d'un seule graphique me semble vivement recommandé. Pour autant, je peut développer une application qui reprenne l'idée de GabrieL. Donc si j'ai bien compris, tu voudrais une sorte de lien qui permette de modifier la forme du graphique. Ainsi on décide que par défaut sur tous les articles il y ait des diagrammes courbes (ou inverssement peu importe) et que en dessous il y ait un lien qui permette de faire appraitre un diagrammes bâton (ou inverssement). Ainsi tout le monde serait content en somme. Si c'est ça je pense que c'est techniquement faisable par contre on devra utiliser une sous page pour reccueillir les scripts des 2 diagrammes se sera plus simple pour la lisibilité des page d'édition des articles. amicalement--Wikialine (d) 12 mars 2009 à 00:06 (CET)

L’homogénéité des pages compte, même si on ne consulte que de temps en temps, et même surtout dans ce cas. 99 % de nos lecteurs ne sont pas habitués à lire ces courbes ; certains risquent de former leur œil à cette lecture sur Wikipédia ; si on utilise plusieurs modèles différents, alors on perd ce bénéfice. Et on perd aussi une chose : la comparaison facile entre deux communes ; avec des diagrammes bâtons de temps en temps, on perd une partie de cet avantage.

Si j’ai bien compris l’idée de GabrielL, il faudrait l’équivalent de la carte alternative de l’infobox, pour les diagrammes. Épiméthée (d) 12 mars 2009 à 08:49 (CET)

Vous avez bien compris ma proposition technique ;-) GabrieL (d) 12 mars 2009 à 22:08 (CET)

j'ai constaté que une seule forme de graphique (à courbe ou à baton, peu importe) peut parfaitement être utilisée sur tous les articles, un recensement pourrait être tenu par un (des) contributeur(s) courageux sur les différents types utilisés ? Quel article utilise tel système ? GabrieL (d) 12 mars 2009 à 22:08 (CET)

Les choses sont simple, actuellement 2 formesde graphique convienne l'une sous formede bâton en prenant soin de respecter les espaces entre les dates, et l'autre sous forme de courbe. La simplicité voudrait que l'on choisisse un seul modèle de graphique à mettre partout. Recenser tous les articles de commune soit plus de 36000 est impossible. Laisser les 2 formes de graphique en activité c'est à éviter, puisque l'ambition de cette page est de corriger les graphiques qui étaient faussé car certains extrapolaient certaines données, la seconde amibition est de rendre homogène les articles et par la même de mettre un terme aux revert à répétition des différent graphiques. Donc 2 solutions s'offre à nous soit on adopte un graphique unique et en l'occurence celui qu'a choisi la comunauté wikipédia au sein du sondage à savoir celui en forme de courbe. Soit on prend le chemin médien en mettant en place l'idée de Gabriel en utilisant les 2 graphique sur un même article avec une fonction switch. Alors qu'est ce que l'on fait ? amicalement--Wikialine (d) 12 mars 2009 à 22:21 (CET)

Un autre exemple selon moi où conviennent les histogrammes mais pas les courbes, ce sont les communes ayant subi des rattachements ou cessions d'autres communes (ou alors, il faudrait une courbe non continue avec une interruption et reprenant au recensement suivant). Et je ne suis toujours pas convaincu de la pertinence des courbes pour des communes ayant un phénomène démographique provisoire (sur uniquement un ou deux recensements consécutifs) pour une raison ou une autre (exemples de raisons dans une de mes précédentes interventions). Et au contraire, les courbes sont plus pertinentes que les histogrammes dans d'autres situations, par exemple pour des communes résidentielles ayant pour beaucoup d'entre elles subit un bond démographique définitif, je pense notamment à Antony déjà cité ou Avrillé dans le Maine-et-Loire. GabrieL (d) 15 mars 2009 à 01:05 (CET)

Pour le reste, si bien sûr, le SWITCH est possible, cela serait vraiment très bien et résoudrait la question. Mais si un seul graphique doit rester, je ne comprends pas pourquoi il faudrait à tout prix uniformiser, on peut corriger les graphiques existants sans pour autant les uniformiser et l'homogénéité totale n'est pas à suivre car ce n'est pas forcément pertinent (cf. mon précédent message), toutes les communes n'ont pas la même histoire, la même taille... et si "guerre d'édition", on laisserait le graphique qui a perduré les mois qui ont précédé. GabrieL (d) 15 mars 2009 à 01:05 (CET)

Usine à gaz

Je tiens à reporter ici des commentaires récurrents sur le bistro concernant l'illisibilité du code pour ces diagrammes qui pourrait empêcher un contributeur novice d'intervenir. En effet, s'il veut seulement ajouter un ligne de texte et s'il tombe sur 30 lignes de code noyant une ligne de texte encyclopédique, il risque de repartir dégoûté en pensant que contribuer sur wikipédia demande des compétences qu'il n'a pas. Ce reproche est légitime. Il a été aussi évoqué de transformer le graphique en modèle mis en sous-page. Celà demanderait une révolution de wikipédia qui en général place les modèles dans un espace modèle (sauf pour les portail) mais je trouve que cela pourrait être une solution élégante que je soumets ici. HB (d) 11 mars 2009 à 19:52 (CET)

L'argument portant sur la technicité n'est pas recevable véritablement. J'en suis venu à cette conclusion sur le fait que l'on doit faire ce qu'il faut. Si la représentation graphique la plus précise et juste, est par exemple une courbe (ou un histogramme à baton peu importe, je n'ai pas d'avis définitif personellement, je tiens à le préciser) alors on doit placer des courbes dans nos articles. On ne doit pas choisir une forme de graphique par rapport à sa facilité d'exécution et à son script qui peut dérouter ou pas. J'ai lancé un petit sondage et travaillé ici avec d'autres sur un générateur de courbe. On a là un exemple (que l'on peut encore chercher à améliorer si on veut simplifier encore plus) très parlant. Graces au générateur de courbe aujourd'hui, il n'est plus nécessaire pour un wikipédien de devoir chercher à comprendre les codes de la timeline. Il suffit d'utiliser le générateur qui produit un code tout fait qu'il faut ensuite copier-coller sur l'article. On voit là un moyen de simplifier la production de graphique. Après pour rendre encore plus claire la page d'édition des articles on peut parfaitement décider de créer des sous pages pour y accueillir uniquement le script des graphiques. Tout cela me semble intéressant et se fait déjà sur d'autres WP étrangères il me semble donc que ça peut fonctionner. Je dois aussi rappeler un détail, lorsqu'un rédacteur veut ajouter une phrase dans un article dans la section démographie il va devoir l'ajouter soit dans un texte avant un graphique soit après un graphique donc il y a peut de chance qu'il soit perdu surtout si l'on décide d'ajouter des commentaires dans le code du genre « Début du script de la courbe démographique » et « Fin du script de la courbe démographique ». C'est une astuce toute simple qui facilite la compréhension de la page d'édition en faisant appel aux tags de commentaires invisibles sur les articles mais visible dans sa page d'édition. En tout cas l'idée d'ajouter des sous page pour accueillir les time line j'y suis personellement favorable HB. A toi de convaincre les autres, si tu y arrives. En tout cas je lance une discussion ciblé sur cette idée de modèle en sous page. Donc pour tout ce qui touche à cette idées que les participants en discutent dans la section suivante: #Usage de modèles mis en sous-page. amicalement--Wikialine (d) 11 mars 2009 à 23:39 (CET)

Bonjour, je trouve la remarque de HB concernant les nouveaux venus pleine de sagesse. Par ailleurs, normer la réalisation de la totalité des graphiques par une charte graphique ne me semble pas raisonnable. Mais peut-être ai-je mal compris . --Bruno2wi ↗^{au zinc ♫} 15 mai 2009 à 23:41 (CEST)

Idem à propos de la remarque de HB, et +1 pour Wikialine. Ces graphiques sont plus justes, d’après la longue discussion qui a précédé, et c’est le but poursuivi par Wikipédia. AMHA, ça relève du même type de problème que les codes HTML simplifiés dans les tableaux. Aux codeurs de simplifier cela en inventant un code simple à modifier (et je ne leur fait pas de reproches, je sais qu’ils bossent). Épiméthée (d) 18 mai 2009 à 07:45 (CEST)

Les débats sur les Pyramides des âges

Classes d'amplitude constante

En page de discussion du projet, j'ai déjà indiqué qu'il était plus juste de construire des pyramides des âges avec des classes d'amplitude constante. En page de projet, j'ai proposé une méthode pour construire des pyramides des âges avec classe d'âge de tailles fixes (15 ans ou 20 ans). Faut-il normaliser la largeur de ces classes d'âges ou laisser le rédacteur choisir à sa guise le découpage (7 classes de 15 ans, ou 6 classes de 20 ans) qui lui paraît le plus pertinent ? HB (d) 14 décembre 2008 à 16:51 (CET)

Je ne suis pas très partante pour une normalisation de ce coté là. Bien que je reste ouverte à de nouvelle idées. Pour remplir les pyramides des ages je me base par exemple sur les données de L'INSEE (comme ici pour Dijon). Et dans la pyramide sous forme graphique, les colonnes sont disposées une à droite pour les femmes et une à gauche pour les hommes avec au centre de façon très précise la tranche d'age représentée par ligne. Les batons verts du graphiques représentent le nombre d'individu par tranches d'age et permet une comparaison visuelle des disparités ou égalités qu'il peut y avoir entre les 2 sexes au sein d'une même tranche d'âge. Donc techniquement le graphique n'est pas faux puisque les batons n'indiquent pas l'importance d'une tranche d'ages qui est déjà mentionné clairment au centre, mais le nombre totale d'individu par sexe dans cette tranche. Autant nos histogrammes étaient faussés jusqu'à présent autant pour les pyramides des ages, il n'y a, à mon sens, pas d'erreurs. Après, je peux me tromper et restes ouvertes aux arguments nouveaux bien entendu, l'essentiel c'est qu'il faut prendre en compte la source d'information (INSEE) et adapter le graphique aux données textes sous tableaux émises par la source... amicalement--Wikialine (d) 14 décembre 2008 à 18:42 (CET)

Je ne suis pas trop pour chambouler ce modèle pour finalement les deux dernières classes d'âges, dont une appelée à disparaître prochainement (a priori, en 2013, les nés avant 1904 « disparaîtront » dans le graphique). Ne peux-tu pas indiquer sur la page du modèle le calcul à faire pour ramener le taux sur 20 ans à un taux sur 15 (a priori, simple règle de trois) et modifier le modèle simplement pour qu'il affiche le bon taux Insee, différent du taux utilisé pour la largeur de la barre ?--Cyrilb1881 (d) 14 décembre 2008 à 18:59 (CET)

Il me semble que vous n'avez pas compris mes objections : une pyramide des âges où les classes d'âges ne sont pas de taille constante et dans laquelle on ne modifie pas la largeur et la hauteur de chaque rectangle est une pyramide des âges fausse. Vous affirmez que non mais n'avez toujours pas pu exhiber un exemple ailleurs que sur Wikipédia où une pyramide des âges est construite de votre façon. Cela devrait vous interpeler. Comparez par exemple la pyramide des âges sur l'article Londres et celle qui est mis en source dans ce même article [2]. La nôtre semble avoir subi un énorme coup de marteau. La pyramide de Wikipédia est tout simplement fausse.

Il existe pourtant un moyen très simple de construire des pyramides justes, en conservant le même modèle, en utilisant les sources INSEE et en effectuant une simple addition et une simple soustraction ou quelques additions. Bref quelque chose de très simple, que j'ai expliqué dans Projet:Communes de France/Diagrammes#Construire des classe d'âge de taille constante.

Cyril, tu dis que la dernière tranche finira bien par disparaitre mais ce n'est pas vrai : dans 10 ans, toutes les tranches auront été décalée de 10 ans, et la dernière tranche sera encore conservée : il y aura toujours des gens ayant plus de 90 ans.

Wikialine, tu dis que tu te sers de la pyramide des âges pour comparer les populations masculines et féminines pour une même classe d'âge. C'est en effet UNE des lectures possibles mais le nom même de pyramide rappelle que la lecture verticale est aussi importante (pyramide ?; toupie ? pyramide inversée ?). Attention toutefois, quand on cherche à comparer la population féminine et masculine il faut alors prendre soin de travailler avec les effectifs réels mais pas avec les pourcentages car ils ramènent à 100 la population masculine et à 100 la population féminine même dans le cas (fort improbable) où la seconde serait deux fois plus importante que la première. Or pour l'instant, les pyramides des âges semblent majoritairement données en pourcentage. Il s'agit donc là aussi de choisir judicieusement l'option effectif réel ou pourcentage.

Moi, je me contente de signaler un bug, de proposer plusieurs solutions et de vous laisser choisir. Cela m'ennuierait que vous choisissiez de ne rien faire et de laisser persister l'erreur. Cela ne m'empêchera pas, au coup par coup, avec accord des contributeurs de l'article de modifier des pyramides pour les rendre justes.

Cordialement. HB (d) 15 décembre 2008 à 14:58 (CET)

Je n'ai pas écrit que la pyramide n'était pas fausse. Mais il me semble qu'en appliquant une proportion aux deux dernières barres pour réduire la largeur, ça corrigerait le problème sans créer un tout nouveau modèle. On indiquerait ainsi 5 % au delà de 1924 mais la barre serait construite sur 3,75 %, elle devient juste puisque le taux est ramené sur la même échelle que les autres tranches. Quant à conserver en 2013 la barre supérieur à 1904, j'en doute, il semble plus logique de glisser au fur et à mesure. La dernière barre ne sera ainsi plus « né avant 1904 » mais « né avant 1924 ».--Cyrilb1881 (d) 15 décembre 2008 à 19:36 (CET)

non, réduire la largeur ne suffirait pas, il faudrait aussi augmenter la hauteur, ce que ne permet pas le modèle. En 2013, si on actualise la pyramide, on se servira de nouveau des tableaux de l'INSEE qui, s'ils ont gardé la même forme, présentera toujours 3 tranches à 20 et 2 à 15. Donc le problème restera entier et nécessitera, comme maintenant, juste un petit calcul pour redresser le truc sans changer le modèle. HB (d) 15 décembre 2008 à 19:59 (CET)

Conclusion

Histogramme

En cours de débats...

Pyramides des âges

En cours de débats...

Article connexe

• Voir le sondage - Sondage au sein de la comunauté wikipédienne portant sur les propositions de diagrammes.
• Voir les discussions - Liste de tous les débats ayant eut lieu au sein du projet communes de France.