Discussion modèle:Tableau population d'article de commune de France

Discussions connexes et plus générales sur l'ensemble de la section Démographie: Discussion modèle:Section démographie d'article de commune de France

Les sources des populations post-2006

Actuellement toutes les années post-2006 sont indiquées (2007, 2008, 2009, 2010), ce qui est incohérent avec le fait que l'on n'affiche que certaines années selon la charte (les recensements exhaustifs). Il parait souhaitable de ne citer que les sources des années affichées, à savoir des recensements exhaustifs pour les communes de moins de 10000 habitants et les années 2006, 2011, 2016, etc pour les plus de 10000.

Plusieurs solutions sont possibles :
1. Tester dans le modèle l'année du ou des recensements exhaustifs:
On peut utiliser le paramètre "recens1", nouveau paramètre qui va donner l'année du premier recensement. Il suffit de faire des additions modulo 5 et de reconstituer l'adresse à partir de source2. Il faut aussi gérer le cas de recens1=A (populations > 10000 habitants)

2. Introduire dans le modèle l'année des recensements exhaustifs intermédiaires:
En sus de recens1 on peut ajouter recens2, recens3, recens4, cela permet d'éviter de faire des tests complexes dans le modèle. Il suffit alors de tester l'existence de recens2, recens3, etc , et on reconstitue la source à partir de source2. Avec 4 lignes de if, on tient pour 20 ans! (d'ici là peut-être que Wikidata ou un autre système aura supplanté le dispositif!).

3. Introduire directement dans le modèle la source :
avec un texte comme :
[http://www.insee.fr/fr/ppp/bases-de-donnees/recensement/populations-legales/commune.asp?annee=2008&depcom=45008 2008]
là c'est encore plus simple, avec ifexist recens2, recens3, recens4, on renvoie direct les sources.
Pour ma part je pencherais pour cette dernière solution, mais en affichage dans le modèle, la solution 2 serait la meilleure.Roland45 (discuter) 31 décembre 2013 à 08:57 (CET)

Bon, je viens d'opter pour les deux paramètres recens1 (1er recensement exhaustif) et recens2 (2ème recensement exhaustif). Il suffira d'adapter le modèle de tableau avec ces paramètres.Roland45 (discuter) 31 décembre 2013 à 12:51 (CET)

Il restera quelques communes qui sont passées de moins de 10 000 à plus de 10 000 habitants pendant cette période, ou l'inverse, pour lesquelles il faudra réfléchir à une personnalisation de la légende (manuellement, je pense). Père Igor (discuter) 31 décembre 2013 à 14:52 (CET)

Oui. Effectivement.

Bon après différents tâtonnements, j'ai retenu la règle suivante pour les paramètres recens :.
recens1 représente l'année du recensement initial (2004, 2005, 2006, 2007 ou 2008).
recens2 représente l'année du 2ème recensement, mais il n'est affiché dans le modèle que s'il est différent de 2006 et 2011.
Ainsi pour la citation des sources, il suffira de citer toujours 2006 et 2011 et recens2 lorsque le paramètre est défini dans le modèle de données. Pour le modèle c'est beaucoup plus facile.Roland45 (discuter) 31 décembre 2013 à 15:47 (CET)

Oui mais si l'on met 2004 ou 2005 en recens1 (ce qui signifie automatiquement 2009 ou 2010 en recens2), cela n'a pas véritablement d'intérêt technique car on ne dispose pas des données de 2004. Il me semblerait préférable d'indiquer 2009 ou 2010 directement en recens1. De ce fait, recens2 ne servira qu'à partir des données 2012 disponibles dans un an. — S t a r u s – ¡Dímelo! – 31 décembre 2013 à 17:14 (CET)

Pour ceux qui n'ont pas suivi les épisodes précédents, les chiffres de 2004 et 2005 existent, soit d'après les archives wikiwix d'un tiers des départements (je peux fournir la liste), soit à partir des chiffres de la base cassini de l'EHESS indiqués systématiquement avec la date 2006, qu'ils aient eu lieu en 2004, 2005 ou 2006). Lorsque j'automatise la démographie sur une commune qui a été relevée en 2004 ou 2005, je modifie le modèle adéquat en conséquence (exemple : modèle:Données/Champeix/évolution population). Père Igor (discuter) 31 décembre 2013 à 17:27 (CET)

Je crois me rendre compte que mes modifs dans les modèles peuvent perturber le fonctionnement du bot. Pour toutes les communes du 04, j’ai supprimé toutes les recensements non-exhaustifs (en plus d’ajouter des recensements d’Ancien Régime proche). J’ai aussi ajouté en commentaire Recensement réel, ainsi qu’un recensement supplémentaire pour 2010 (afin d’avoir l’affichage dans le graphique). La mise en place de recens1, recens2, etc. y serait perturbé. Je peux le faire à la main.

Pour le 04, j’ai ajouté les données de 2004, et il me semble que PèreIgor aussi pour la Dordogne.. azoée (discuter) 31 décembre 2013 à 17:33 (CET)

Est-ce que ce genre de modif que j'ai faite peut perturber l'automatisation qu'envisage Roland45 (d · c · b) ? Père Igor (discuter) 31 décembre 2013 à 17:39 (CET)

Avec le programme que j'avais préparé, cela ne posait pas de problème, puisque je repartais du code existant. Néanmoins, du fait d'un pb technique, je suis en train de m'orienter vers une autre voie, et là je n'avais pas prévu de récupérer les populations postérieures à 1999, ni les sources correspondantes, les reconstituant à partir de bases que j'ai (or mes bases commencent à partir de 2006). Toutefois ta remarque tombe bien à propos, car en fait je pourrais ajouter aussi automatiquement ces années 2004 et 2005 pour les départements où on a des sources. Peux-tu me communiquer à nouveau les url des départements que l'on a (en sus du 63) ? Et bonne année 2014, à plusieurs l'union fait la force!Roland45 (discuter) 1 janvier 2014 à 21:40 (CET)

Bon, en fait je viens de voir qu'en changeant le code du département dans l'url, on trouve les sources en question (03, 04, etc). Roland45 (discuter) 1 janvier 2014 à 21:49 (CET)

Départements 03, 04, 06, 12, 14, 19, 21, 24, 31, 33, 34, 35, 36, 37, 45, 50, 51, 52, 53, 58, 61, 62, 63, 65, 72, 79, 83, 88, 89, 91 et 92. Pour les autres, voir l'année 2006 sur la base Cassini, à croiser avec les calendriers de relève de l'Insee par département (voila celui de l'Ain). Hein ? Père Igor (discuter) 1 janvier 2014 à 22:16 (CET)

Paramètre titre

Est-il possible d'ajouter un paramètre titre? Cela éviterait à la fois d'avoir systématiquement des titres imprécis et à la fois d'avoir des titres faux (car s'ils sont imprécis ils sous-entendent qu'il s'agit de la population de la commune actuelle, or en pratique dans les articles ce n'est pas toujours le cas par exemple dans le cas très répandu de communes issues d'une fusion avec une autre commune). Voir la discussion à ce sujet dans Discussion modèle:Graphique population d'article de commune de France. -- Carfois (d) 15 janvier 2014 à 11:21 (CET)

Je plussoie. azoée (discuter) 15 janvier 2014 à 13:22 (CET)

En attendant, comme "workaround" provisoire, j'ai traité le cas de Cherbourg-Octeville en ajoutant une note grâce au paramètre "sources". Mais c'est bien sûr une solution provisoire en l'état actuel du modèle. En plus de pouvoir adapter le titre, il serait bien aussi dans le modèle de permettre d'ajouter non seulement des sources mais aussi des notes, comme c'est le cas avec le modèle {{Démographie}} (avec son paramètre "notes", en plus de ce que ce modèle accepte les références dans les champs de données de population).

(à noter au passage dans l'exemple de Cherbourg-Octeville que j'ai également rajouté manuellement un graphique de la population sur son territoire actuel, mais c'est un autre sujet et il faudrait avoir une réflexion globale sur la ou les manières de traiter les communes dont le territoire a évolué au cours du temps, ce sur quoi les modèles actuels font l'impasse) -- Carfois (d) 15 janvier 2014 à 13:54 (CET)

Voici déjà un premier pas ! Le problème des notes est un peu plus complexe car il existe une version figée, celle-ci va certainement très vite évoluer afin que l'on puisse intégrer les nouvelles sources qui ont été ajoutées aux « fichiers de données » (/évolution population) ces derniers jours. — S t a r u s – ¡Dímelo! – 15 janvier 2014 à 14:25 (CET)

Super, merci Starus! Te serait-il possible aussi d'ajouter le paramètre titre de la même façon pour l'histogramme {{Graphique population d'article de commune de France}}?

Pour ajouter un paramètre notes, avec la contrainte des notes figées existantes que tu as indiquée, je pense qu'il suffirait de concaténer les notes "figées" avec les notes passées en paramètre, par exemple changer:

|notes = {{Tableau population d'article de commune de France/notes}}

en

|notes = {{Tableau population d'article de commune de France/notes}}{{#if:{{{notes|}}}|{{{notes|}}}|}}

On pourrait éventuellement mettre un saut de ligne <br> entre les deux mais je pense a priori que le mieux serait de laisser le contributeur ajouter ce saut de ligne si nécessaire (par exemple si le contributeur rajoute juste une référence <ref> supplémentaire il n'y aura pas besoin de saut de ligne). -- Carfois (d) 15 janvier 2014 à 14:59 (CET)

Centrage du tableau et du graphique

Bonjour. Je signale ici que sur la page des Questions techniques est posée la question du centrage automatique du tableau et du graphique dans l'article, en fonction de l'infobox. L'adaptation ne serait-elle pas à faire ici ? Père Igor (discuter) 29 mars 2014 à 12:19 (CET)

Arguments dupliqués

Bonjour,

Ce modèle génère des dizaines de milliers d'entrée dans Catégorie:Page_utilisant_des_arguments_dupliqués_dans_les_appels_de_modèle, ce qui rend la catégorie impossible à maintenir. De ce que j'ai réussi à comprendre, cela vient du fait que si le paramètre « recens » de chaque ligne des tableaux n'est pas à 1, on génère un argument vide (sans nom). Mais le wikicode des modèles étant complètement imbitable assez difficile à appréhender dès que ça devient un peu complexe, mes tentatives de correction se sont soldées par des échecs cuisants. Est-ce que quelqu'un a une idée pour résoudre ce problème ? Est-ce qu'il serait temps que j'apprenne le Lua ? Merci ! El pitareio (discuter) 27 décembre 2016 à 00:23 (CET)

 El pitareio : bonjour. Le plus simple est de notifier Roland45 (d · c · b), qui connait bien tous les tableaux liés aux communes françaises. Père Igor (discuter) 27 décembre 2016 à 15:45 (CET)

Eh oui. Désolé. C'est bien moi qui ai commis ce forfait! Le paramètre recensn permet d'afficher ou non une donnée (popn et ann) dans le tableau mais aussi dans le graphique (on a retenu le principe de n'afficher que les recensements réels, car certains ne sont qu'estimés). On teste donc si le paramètre est égal à un pour afficher. Le code paraît complexe car il faut pouvoir utiliser le modèle dans la page de l'article de la commune (Subpagename) mais aussi dans n'importe quel autre article (via le paramètre nom). Ce problème d'arguments vides dupliqués avait déjà été détecté car un message d'erreur s'affiche en prévisualisation lorsqu'on modifie une section contenant le modèle mais disparaît à l'enregistrement. Si quelqu'un a une autre solution qui permette d'aboutir au même résultat (afficher uniquement certaines valeurs dans le tableau ou le graphique), je suis bien entendu preneur.Roland45 (discuter) 27 décembre 2016 à 16:33 (CET)

Bonjour Roland45. J'ai essayé de comprendre le problème reporté par El pitareio car cette situation empêche la maintenance de la catégorie Catégorie:Page_utilisant_des_arguments_dupliqués_dans_les_appels_de_modèle. Le code est effectivement très complexe : est-ce que tu vois une façon pour que lorsque recensn ne vaut pas 1, soit on ne crée rien du tout (encadrer tout ce qui concerne recensn par un {{#ifeq:…}}), soit créer des arguments avec des noms différents dans ce cas ? Merci. --NicoV (discuter) 3 janvier 2017 à 08:36 (CET)

Il faut effectivement trouver un subterfuge pour ne pas avoir cette création d'argument "vide". Pour l'instant je n'ai pas la solution. Désolé.Roland45 (discuter) 3 janvier 2017 à 09:45 (CET)

@Roland45 : hello. Je sais que Lua n'est pas un langage que tout le monde maîtrise mais est-ce que ça ne vaudrait pas le coup de tenter une bascule ? Quand on n'arrive plus à comprendre un modèle c'est que c'est peut-être qu'on dépasse les capacité du langage des modèles de mediawiki (et surtout quand je vois 46 fois quasiment la même ligne répétée dans un modèle je me dis qu'il est temps de passer à un langage qui possède la notion de boucle ). Si ça t'intéresse je peux te donner un coup de main. Cordialement, Hexasoft (discuter) 3 janvier 2017 à 09:57 (CET)

Je pense aussi que Lua serait une bonne solution pour simplifier le modèle et le rendre plus compréhensible, avec probablement en prime une amélioration sur les performances du modèle (en chargeant les données de la commune une fois, en évitant de faire de nombreux appels à des sous-modèle...). Je veux bien aider aussi, même si mes compétences en Lua sont modestes. --NicoV (discuter) 3 janvier 2017 à 11:11 (CET)

C'est sûr que ne pas pouvoir utiliser de boucles limite singulièrement le langage des parser functions. Outre la répétition des lignes, cela conduit également périodiquement à modifier le modèle : ... quand le nombre de données dépasse le nombre de lignes d'appel du modèle. Mais on ne peut pas dire par contre que le lua rendrait plus compréhensible le code. Au contraire, peu de contributeurs non informaticiens en maitrisent son langage (... dont moi, même si je peux quand même le lire plus ou moins!) alors que les parser functions on peut s'y mettre (et puis si ce n'est pas clair en affichage standard, avec des couleurs dans Word, on y voit beaucoup plus clair). En tout cas,  Hexasoft :, si tu veux t'y atteler, je suis à ta disposition pour tout éclairage sur le contexte et les résultats attendus. On peut commencer par le tableau, ce doit être plus simple (même si il y a des subtilités particulièrement en ce qui concerne les appels de notes qui sont différentes selon qu'il s'agit de communes standard ou de communes nouvelles, cas d'ailleurs pour lesquelles le contenu n'est pas encore complètement stabilisé). Cordialement.Roland45-Bot (discuter) 3 janvier 2017 à 14:02 (CET)

Je jetterai un œil dans la semaine.

Note : le problème principal des modèles c'est qu'on leur demande de faire ce pour quoi ils n'ont jamais été fait . Hexasoft (discuter) 3 janvier 2017 à 14:15 (CET)

OK.Roland45-Bot (discuter) 3 janvier 2017 à 14:23 (CET)

J'ai jeté un œil vite-fait. Pour un passage en module, l'idéal serait de créer des modules de données (en lieu et place des modèles de données type Modèle:Données/XXXX/évolution_population). Ceci afin d'éviter les 10aines (ou 100aines) d'appels de modèles par le (les) modèle, car c'est très coûteux en temps.

Mais c'est un boulot énorme… Ceci dit ça pourrait être fait par bot je pense, mais c'est à laisser pour plus tard à mon avis, il faudrait discuter de tout ça plus en profondeur.

Ce qu'il est possible de faire c'est de créer un module qui fabrique − comme le modèle actuel − l'appel au modèle Démographie (et même on pourrait appeler directement le module, ça évite un intermédiaire, à voir). C'est pas optimal mais c'est toujours un début. Hexasoft (discuter) 3 janvier 2017 à 17:25 (CET)

L'avantage de ces modèles de données, c'est qu'il y en a un par commune (pour une commune donnée on n'appelle qu'un modèle) et que je peux les actualiser par un bot écrit en VBA, langage que je maitrise assez bien et qui présente l'avantage, pour l'actualisation des modèles, de coupler de la programmation classique avec des calculs intermédiaires qui sont faits directement dans les feuilles de calcul. Maintenant tout dépend quelle est la forme de ces modules de données. Peut-être qu'on peut les actualiser en VBA aussi.Roland45-Bot (discuter) 3 janvier 2017 à 18:00 (CET)

Dans mon idée il faut conserver un module par commune. Le format est assez simple, c'est juste de la déclaration de tableaux avec des champs/valeurs. On peut « charger » de tels modules depuis un autre module, ce qui permet d'avoir les infos accessibles en un coup, sans devoir faire N appels au même modèle pour avoir N valeurs.

Je vais d'abord commencer par tester un remplaçant de l'existant. Il doit aussi être possible de faire un module qui teste la présence d'un module de données et l'utilise, sinon il retombe sur le principe actuel des modèles. Ça permettrait de tester et de faire évoluer en douceur. À voir. Hexasoft (discuter) 3 janvier 2017 à 18:14 (CET)

 Roland45 et Roland45-Bot : (et d'autres que ça intéresse) → je propose d'aborder ce sujet sur la page de discussion du module de test que j'ai commencé, à savoir ici : Discussion module:Tableau population d'article de commune de France. Hexasoft (discuter) 3 janvier 2017 à 22:39 (CET)

 Roland45, Roland45-Bot et Hexasoft : Je pense que le problème d'argument dupliqué vient des lignes suivantes :

• |{{#ifeq: {{Données/{{#if:{{{nom|}}}|{{{nom|}}}|{{SUBPAGENAME}}}}/évolution population|recens1}}|1| {{Tableau population d'article de commune de France/case année|nom={{{nom|}}}|1}}}}={{Tableau population d'article de commune de France/case population|nom={{{nom|}}}|1}}

où j'ai mis en gras souligné la fin du test sur recens1 qui est avant le égal. Si recens1 est différent de 1 alors, on a une ligne |=....

Je pense qu'une modification de ce type sur toutes les lignes devrait probablement régler le problème :

• |{{#ifeq: {{Données/{{#if:{{{nom|}}}|{{{nom|}}}|{{SUBPAGENAME}}}}/évolution population|recens1}}|1| {{Tableau population d'article de commune de France/case année|nom={{{nom|}}}|1}}|inutile1}}={{Tableau population d'article de commune de France/case population|nom={{{nom|}}}|1}}

pour que soit créé un paramètre nommé inutilen lorsque recensn est différent de 1, on aurait donc |inutile1=... au lieu de |=.... Je n'ai pas les droits pour tester si ça marche, est-ce quelqu'un peut essayer ? --NicoV (discuter) 4 janvier 2017 à 14:59 (CET)

Non J'avais une accolade fermante à la suite du premier chiffre de population (et seulement celui-là) et, en-dessous du tableau, le texte suivant en rouge : Liste des erreurs : • Le paramètre >><hr style<< (9/9 est inconnu. J'ai annulé la correction. — S t a r u s – ¡Dímelo! – 4 janvier 2017 à 15:40 (CET)

Merci S t a r u s pour l'essai (au fait, il est possible de tester ce que donnera un modèle sur une page sans enregistrer la modification : en bas il y a un champ permettant de dire quelle page on veut visualiser avec la version en cours de modification du modèle). Bon, je ne sais pas trop ce qu'il peut se passer... Zut.

Autre idée, mais je ne sais pas comment le modèle {{Démographie}} se comportera : au lieu de tester la valeur de recens1 pour mettre le nom du paramètre (qui est l'année si je comprends bien), est-ce que l'on pourrait le tester pour mettre la valeur du paramètre (qui est la population si je comprends bien) avec une ligne du type :

• |{{Tableau population d'article de commune de France/case année|nom={{{nom|}}}|1}}={{#ifeq: {{Données/{{#if:{{{nom|}}}|{{{nom|}}}|{{SUBPAGENAME}}}}/évolution population|recens1}}|1| {{Tableau population d'article de commune de France/case population|nom={{{nom|}}}|1}}}}

Si recens1 est différent de 1, on devrait avoir |année1= au lieu de |=population1. --NicoV (discuter) 4 janvier 2017 à 15:59 (CET)

Notes : il est possible de créer (quand il n'existe pas déjà) un modèle/module de test. Par ex. Module:Démographie/Test (ajouter /Test est la "norme") existe, et n'est pas protégé. Et effectivement on peut tester sur une page sans sauvegarder. C'est doublement intéressant car ça invalide le cache (au moins pour soi) donc on voit vraiment ce qu'il se passe.

Pour le module démographie : je doute qu'il aime des paramètres de type "ANNÉE=". Par ailleurs il n'aurait pas dû aimer "=POP" mais pour d'autres raisons ce cas précis était (et est toujours) ignoré par le module. À noter aussi que le module signale via une erreur les paramètres qu'on lui passe et qui n'existent pas.

Il reste que sur le fond la « bonne » façon de faire c'est de passer correctement les paramètres au modèle Hexasoft (discuter) 4 janvier 2017 à 16:12 (CET)

 NicoV et Roland45 : j'ai baissé la protection en SPE pour que vous puissiez faire des essais. À noter que je ne suis pas convaincu par la possibilité de tester sans enregistrer. Ça ne fonctionne pas toujours, surtout avec les modèles en cascade comme cela. Il y a d'ailleurs le même problème avec les filtres. — S t a r u s – ¡Dímelo! – 5 janvier 2017 à 01:29 (CET)

 Starus, NicoV et Roland45 : [1] L’idée était bonne, mais il fallait (1) ne pas décaler d’une « } » à la ligne 15 et (2) utiliser des noms d’argument factice commençant par « _» pour éviter que Module:Démographie ne le signale comme argument invalide. —C.P. 5 janvier 2017 à 04:18 (CET)

 Cépey, NicoV et Roland45 : clap clap clap ! Désolé pour le décalage en ligne 15, j'ai pourtant vérifié 200 fois… Peux-tu continuer de briller en essayant de supprimer l'espace dans l'année de ce modèle ? Ma modification de décembre faisant suite à une suggestion de Roland n'a pas été probante. J'ai réduit le niveau de protection aussi. — S t a r u s – ¡Dímelo! – 5 janvier 2017 à 04:25 (CET)

 Starus et Roland45 : [2] Avec un éditeur de texte pour vérifier le balancement des {{ ... }}, j’ai remarqué que le {{formatnum: ... }} s’appliquant au nombre précédent n’était pas fermé. —C.P. 5 janvier 2017 à 05:08 (CET)

 Cépey : Bravo pour la solution. En tout état de cause, grâce à  Hexasoft :, ces problèmes feront bientôt partie du passé avec la transformation du modèle en fonction parser en module en lua. Avec à la clé, une facilitation accrue de l'actualisation du module de données (quand on aura fait la migration modèle -> module pour toutes les données).Roland45-Bot (discuter) 5 janvier 2017 à 08:28 (CET)

Merci à tous, la catégorie des arguments dupliqués est à nouveau utilisable . El pitareio (discuter) 5 janvier 2017 à 21:26 (CET)

Bonjour et bonne année à tous, je ne sais pas si c'est le bon endroit, mais il y a un problème pour les Références qui se chevauchent voir Fonsorbes#Notes et références, cordialement --Paternel 1 (discuter) 6 janvier 2017 à 09:57 (CET)