Discussion Projet:Communes de France/Nouveaux modèles démographiques

Discussions antérieures (2016)

Principes de nouveaux modèles démographiques

FDo64 (d · c · b), Zebulon84 (d · c · b), Starus (d · c · b), Hexasoft (d · c · b), Superjuju10 (d · c · b)
Pour info - AntonyB (d · c · b), Père Igor (d · c · b), Arcyon37 (d · c · b), GabrieL (d · c · b), Rehtse (d · c · b)
Bonjour à tous.

Je reviens vers vous pour les modèles démographiques (tableaux et graphiques) liés au modèle de base m:Démographie lui-même lié au module de base "Démographie" en lua.

Comme vous le savez certainement, j'actualise chaque année les données de population des communes et autres divisions administratives françaises (hormis les COM) en tenant compte la charte d'affichage retenue par le projet Communes de France : Affichage des recensements réels (tous les 5 ans) et de la dernière population pour les communes < 10000 habitants, affichage 2006, 2011, etc pour les >10000 habitants.

Comme les modèles de tableaux et de graphiques n'affichent que les données qui sont dans les modèles de données, l'actualisation nécessite de supprimer les dernières données qui n'étaient pas des recensements réels, ajouter la dernière année et actualiser les paramètres "nombre" et "max".

Une complexification est venue l'an dernier en voulant ajouter l'année n-5 (même si elle n'était pas un recensement réel), car on compare les données par pas de 5 ans (d'ailleurs dans le nouveau site de l'Insee publié ces derniers jours, avec la dernière année est désormais donnée systématiquement l'année n-5). Cela permet d'avoir un calcul automatique de l'évolution sur 5 ans.

Tout ça ne me pose pas de problème (programme en VBA couplé avec des calculs ou tests intermédiaires faits directement dans les tableaux Excel). Mais j'ai bien peur ne pouvoir être que le seul à pouvoir faire cette actualisation! D'autant que chaque année je dois adapter le programme aux données et caractéristiques de l'année.

Or je ne suis pas éternel et un tel système est trop fragile. D'où l'idée de stocker dans le modèle de données toutes les valeurs de populations légales (à savoir toutes les publications annuelles de l'Insee depuis 2006) ainsi que pour chacune d'elles un paramètre "recens" permettant de qualifier l'affichage (=1, on affiche, =0 on n'affiche pas), correspondant à la charte d'affichage.

Noter que ceci permettra aussi d'utiliser éventuellement un jour Wikidata où les données y seraient actualisées (bien que vu le début des discussions, ce soit mal parti!)

Cela alourdit singulièrement le code des modèles (voir les nouveaux modèles : {{Graphique population d'article de commune de France/Test2}} et {{Tableau population d'article de commune de France/test2}}, mais a priori cela marche. On peut aller dans le modèle de données test ({{Données/Commune-test/évolution population}}) et remplacer le paramètre de n'importe quelle donnée, les données affichées dans la page de cet article (adossée à cette pdd) seront modifiées.

Une fois les modèles actualisés, l'actualisation annuelle consistera simplement à ajouter la dernière donnée publiée par l'Insee et changer, si nécessaire, les paramètres "nombre" et "max". Et ça, ce pourra être facilement fait. Je pourrai même communiquer un bot en VBA qui sera indépendant de l'année et pourra être utilisé par n'importe quel utilisateur d'Excel (il suffira d'entrer le code du produit l'Insee correspondant aux données que l'on actualise (puisque maintenant les url sont moins intuitives qu'auparavant!)

Avant l'actualisation 2017, j'envisage de faire tourner un bot spécifique pour ajouter les années manquantes ainsi que ce fameux nouveau paramètre. Il y aura donc quelques jours où toutes les données de 2006 à 2013 seront affichées pour chaque commune, puisque ce n'est qu'après cette actualisation que les modèles seront changés.

Mais avant de lancer l'opération, je me tourne vers vous pour recueillir vos éventuelles observations tant sur le code de ces nouveaux modèles (simplification du code par exemple), que sur le principe. Notez que je n'ai pas encore réglé le problème des notes en pied de tableau (affichage des sources), mais c'est en voie. Cordialement.Roland45 (discuter) 4 décembre 2016 à 10:33 (CET)

Bonjour Roland45. Bizarre ! Ta notification me concernant n'a rien déclenché chez moi. Pour l'instant, juste une petite remarque par rapport au positionnement du tableau démographique : pourra-t-il être centré, comme l'est déjà le graphique ? Père Igor (discuter) 6 décembre 2016 à 16:36 (CET)

Il sera bien entendu centré. Je les ai mis ainsi pour que les deux versions de tableaux et graphiques soient en vis-à-vis.Roland45 (discuter) 6 décembre 2016 à 16:49 (CET)

 

Vers un nouveau système de modèles de données démographiques

Mis en place en 2012 afin de faciliter l'actualisation des données démographiques dans les articles des divisions françaises, le système combiné de modèles d'affichage et de modèles de données a atteint ses limites et est par essence fragile. Il doit être remplacé par un système plus performant.

Le nouveau système va s'appuyer sur :

• Un module unique de traitement produisant toutes les fonctionnalités attendues pour n'importe quelle division (textes, tableaux, graphiques, valeurs calculées). Il est écrit en lua, un langage adapté au traitement des données (ce que n'étaient pas les fonctions parseurs utilisées dans les modèles actuels) (Merci Hexasoft!);
• des modules de données contenant à la fois des paramètres caractérisant la division (dont celui du type de division) et des données de population. Ils sont construits à partir des modèles de données existants. (exemple : Module:Données/Adon/évolution population)
• Des modèles d'affichage permettant d'afficher du texte, des tableaux, des graphiques ou des valeurs calculées à partir des données.

Ce nouveau système, outre qu'il soit plus performant, présente l'avantage d'une actualisation facilitée.

Dans un premier temps vont être traités successivement les différentes divisions. Dans un deuxième temps, il sera souhaitable de développer en lua un ou des modules complémentaires pour traiter les modèles non démographiques utilisant les anciens modèles (ex : tableaux de listes). Les créations de modules vont être lancées très prochainement.

Merci de bien vouloir exprimer vos éventuelles observations ci-dessous. Cordialement.Roland45 (discuter) 4 septembre 2017 à 12:10 (CEST)

Éclaircissement demandé

Bonjour. Dans Projet:Communes de France/Nouveaux modèles démographiques#Division : commune, il y a deux paramètres identiques {{Dernière population commune de France}} de l'ancien modèle. Je suppose qu'un des deux est erroné ? Père Igor (discuter) 4 septembre 2017 à 18:22 (CEST)

Par ailleurs, serait-il possible de noter le nombre de « communes en COM1 » dans Projet:Communes de France/Nouveaux modèles démographiques#Divisions, même si j'ai bien vu qu'a priori elles ne seraient pas concernées. Père Igor (discuter) 4 septembre 2017 à 18:26 (CEST)

J'ai apporté quelques modifs aux tableaux en précisant en particulier les communes en COM 1 (35 = 33 communes en Nouvelle-Calédonie + 2 à Saint-Pierre-et-Miquelon. Saint-Barthélemy est divisée en 2 paroisses et 40 quartiers. Saint-Martin n'est pas divisée. Wallis-et-Futuna est divisée en 3 royaumes coutumiers et 3 districts).Roland45 (discuter) 4 septembre 2017 à 18:49 (CEST)

Salut Roland et merci. Parfait et rapide. A+. Père Igor (discuter) 4 septembre 2017 à 19:04 (CEST)

Format

Bonjour Roland45 (d · c · b) et bravo encore pour cet énorme travail entrepris depuis déjà pas mal de temps.

Une question de format : peut-on imaginer qu'une espace soit insérée là où il faut bien pour séparer les milliers ?

Bien cordialement AntonyB (discuter) 4 septembre 2017 à 21:29 (CEST)

Bonjour AntonyB. La donnée est brute car elle peut être réutilisée brute dans certains cas. Pour avoir le séparateur, il suffit d'ajouter "formatnum". La syntaxe devient alors, pour Gien par exemple, {{Formatnum:{{Population de France/dernière_pop||Gien}}}}, ce qui donne : 13 387. Maintenant il faut aussi recenser les cas où le "formatnum" est préinstallé dans le modèle (tableaux ou listes par ex), il n'y en a peut-être pas beaucoup. Cordialement.Roland45 (discuter) 5 septembre 2017 à 08:36 (CEST)

Lieu de stockage des données

Bonjour, Wikidata n'est peut être en fait pas l'endroit idéal pour stocker des données (problème d'espace disponible, et interminable débat sur les licences), mais il y a aussi maintenant la possiblité de stocker des données sur Commons, et ça permettrait de les partager pour toutes les langues. On ne pourrait pas faire ça comme pour Commons:Data:Taipei Population.tab ? --Zolo (discuter) 4 septembre 2017 à 21:36 (CEST)

Les modules de données ne sont actuellement pas stockés dans Wikidata mais bien dans Wikipédia (ex : Module:Données/Gien/évolution population) (à terme WD sera probablement utilisé quand on saura faire tableaux et graphiques à partir de données WD). Cette idée de stocker les données dans Commons est intéressante. Par contre le module de traitement (module:Population de France) est conçu différemment actuellement et est prêt à fonctionner. Je notifie néanmoins  Hexasoft : pour lui demander ce qu'il en pense. Cordialement.Roland45 (discuter) 5 septembre 2017 à 09:24 (CEST)

Hello,

oui les données sont stockées ici, sur WP. En fait c'est la même chose qu'avant avec les modèles de données, sauf que ce sont… des modules .

Pour commons je doute que ce soit faisable : autant il a été prévu des outils pour accéder aux données de wikidata (même si perso je n'utilise pas wikidata) autant je ne connais pas d'outil permettant de faire ça depuis commons. Sans moyen pour "récupérer" ces données de commons ici (accessible durant l'exécution du code d'un module) ça ne sert pas à grand chose !

Cordialement, Hexasoft (discuter) 5 septembre 2017 à 09:45 (CEST)

On peut récupérer les données de Commons avec mw.ext.data.get("Example.tab") (voir mw:Help:Tabular Data). Apparemment c'est tout ce qu'il y a, mais ça a l'air de fonctionner et de donner une table assez propre. --Zolo (discuter) 5 septembre 2017 à 11:32 (CEST)

@Hexasoft et @Roland45 en regardant Module:Données/Baie-Mahault/évolution population, je vois qu'il y a :

• Des lignes de données de population avec date et source. Pas de problème pour récupérer ça de commons avec mw.ext.data.get("Example.tab").
• Des données qui ne s'appliquent pas à une année en particulier, et qu'il est sans doute plus compliqué de mettre dans un fichier tabulaire. Il y a donc :
  • le code insee (facilement récupérable de Wikidata)
  • le nom de la commune (idem)
  • la superficie (idem)
  • le nom du département (idem, mais un petit peu problématique niveau performance, on peut aussi faire une table de correspondance numéro de département, nom de département)
  • "recens-prem", pas très sûr de comprendre ce que c'est mais ne vaudrait-il pas mieux indiquer la méthode de comptage de la population séparément pour chaque année, pour le cas où ça viendrait à changer ?
  • "sources", "source1", "source2". je sais pas trop pourquoi c'est fait, mais les données Commons peuvent contenir un optional "sources" field must be a Wiki markup string value that describes the source of the data..
  • ["division"] = "commune en DROM", peut-être plus compliqué

--Zolo (discuter) 6 septembre 2017 à 11:55 (CEST)

@Zolo : je connaissais pas ! Question : ce n'est pas vu comme une "opération coûteuse" ? Pour Lua les modules locaux sont pas chers, les données de l'article local idem (incluant le wikidata associé) mais par contre tout le reste (autre article, autre item WD) sont chers.

Après sur le fond − et bien que je sois loin d'être un fan de wikidata − n'est-ce pas un peu curieux de stocker des données "brutes" sur commons alors que wikidata est supposé être là pour ça ? Cordialement, Hexasoft (discuter) 6 septembre 2017 à 12:46 (CEST)

 Hexasoft : mw.ext.data.get a effectivement l'air de compter comme une fonction coûteuse, mais comme en on a le droit un 500, ça ne devrait pas être un gros problème.

Beaucoup plus problématique est l'utilisation de la mémoire Lua (50 Mo autorisés par page). Un élément Wikidata sur une entité administrative, c'est facilement plusieurs Mo. Si on y mettait des données démographiques, sociologiques et économiques détaillées, ça deviendrait vite ingérable.

Les fichiers de Commons sont dans un format très différent, et beaucoup plus light. On peut les relier à Wikidata via P4179 (« tableau de population »). Ca contourne aussi en pratique les questions de propriété intellectuelle (les données de l'INSEE ne sont pas forcément compatible avec la licence CC0 de Commons). Globalement, ça me parait un bon compromis. --Zolo (discuter) 6 septembre 2017 à 16:57 (CEST)

@Zolo : c'est vrai qu'on a de la marge sur les fonctions coûteuses. Ceci dit on n'est pas les seuls modèles/modules à tourner sur une page, et le max est par page, pas par modèle/module, il convient donc de viser l'économie chaque fois qu'on peut

Je veux bien faire quelques tests pour voir la faisabilité des choses. Ça permettra ensuite de se poser des questions pragmatiques en ayant les billes en main. Cordialement, Hexasoft (discuter) 6 septembre 2017 à 17:16 (CEST)

 Zolo : et  Hexasoft : - J'avais commençé à produire les modules de données (à partir des modèles existants) et ai suspendu l'opération en attente de ces tests.

Pour répondre à la question de Zolo, les paramètres en en-tête de module de données servent à produire des notes en pied de tableau ou de graphique ou interviennent dans des blocs de textes. Il est essentiel de les avoir. On pourrait à ce titre imaginer un module de données générales (ces paramètres + d'autres éventuellement) dans WP (équivalents finalement à nos modèles d'informations générales actuels) et les données proprement dites de population en tables dans Commons.

Dès lors qu'on en est à des recherches d'optimisation du système, j'en profite pour signaler à Hexasoft qu'une simplification est encore envisageable, moyennant une petite complexification du module. Pour permettre le respect de la charte d'affichage retenue dans WP, on a ajouté un paramètre "recens" : si ["recens"] = true on affiche la donnée dans le tableau ou le graphique, si ["recens"] = false, on ne l'affiche pas. Cela fonctionne, mais lors de l'actualisation des modules de données, une petite difficulté intervient : il ne suffit pas d'ajouter une ligne de données au module, mais s'interroger si la dernière donnée publiée l'année précédente correspondait à un recensement réel ou une estimation. En effet puisque la dernière donnée publiée est toujours affichée (["recens"] = true), l'année suivante s'il s'agissait d'une estimation il convient de modifier le paramètre recens pour cette donnée de true en false!

L'idéal serait, comme d'ailleurs le suggère Zolo, de faire le test à l'intérieur du module de traitement, pour ne pas revenir sur des données antérieures. Deux solutions sont envisageables (selon mon point de vue de néophyte) :
1/ Ajouter un paramètre "méthode détermination" La table comporterait ainsi quatre données :

• l'année de population (P585 (« date ») dans WD) ,
• la valeur (P1082 (« population »)),
• la méthode de détermination (P459 (« méthode de détermination »)) qui peut prendre quatre valeurs : (Q39825 (« recensement de la population ») pour un recensement réel de commune < 10 000 h, Q744069 (« extrapolation ») ou Q187631 (« interpolation numérique ») pour les communes < 10 000 h estimées , Q3490295 (« sondage ») pour les communes > 10 000 habitants)
• la source (S854). Concernant cette donnée, pour toutes les données antérieures à 2006, il convient de mettre pour le paramètre ref, la valeur de source1 (et non "nil" comme actuellement).

Il suffit alors de tester dans le module la valeur de P459 pour chaque donnée (communes < 10 000 h: on n'affiche que si P459 = Q744069; communes > 10 000 h : on affiche 2006, 2011, etc).

2/ Ne pas ajouter de paramètre Dès lors la table ne comporterait plus que les trois données :

• l'année de population (P585) ,
• la valeur (P1082_population),
• la source (S854).

Le test d'affichage des données post-2006 se ferait dès lors comme suit, à partir du seul paramètre recens-prem :

• Communes inférieures à 10 000 habitants, on affiche si (année n - recens-prem) [modulo 5] = 0
• Communes supérieurs à 10 000 habitants, on affiche années 2006, 2011, 2016, etc
• Dans tous les cas on affiche la dernière année

Bon, pour les puristes, je reconnais qu'il y a encore quelques cas particuliers en nb infime : les communes dont la population franchit le cap des 10000 habitants dans l'année! On les trouve à partir du calendrier du recensement qui est publié chaque année. Il faudrait alors modifier le paramètre rencens-prem à la main dans le module.)
Bon, ça vaut ce que ça vaut. Mais le but ultime est bien d'avoir un système facilement actualisable, à savoir que l'actualisation ne consiste qu'à ajouter une seule ligne à une base de données, sans revenir sur d'anciennes. Cordialement.Roland45 (discuter) 7 septembre 2017 à 11:13 (CEST)

Bonjour,

@Roland45 et @Hexasoft On dirait que j'ai un petit peu laissé traîner cette discussion... mais je pense que l'enjeu est important.

Pour résumer : le meilleur endroit pour stocker les données démographiques me parait être l'espace données de Commons. Par rapport à un module Wikipédia, ça permet plus de clarté dans la structuration des données, et surtout le partage avec les autres Wiki. Par rapport à Wikidata, c'est meilleur en termes de performance, et plus adapté en terme de structuration des données.

Les données de Commons sont sont un format json comportant :

• une description des données (multilingue)
• une licence
• les données elles-mêmes.

Certains champs des modules de données actuels ne sont pas vraiment compatibles, par exemple : "département", "superficie", "source2" etc. Ce n'est pas forcément un mal. La superficie et le département se récupèrent facilement sur Wikidata. Pour les sources, on ne peut mettre une source par donnée.

Pour l'exemple, j'ai créé c:Data:Population FR 01001 L'Abergement-Clémenciat.tab à partir de Module:Données/L'Abergement-Clémenciat/évolution population.

Je pense qu'il serait intéressant de passer vers un format de ce genre. Adapter les modules en conséquence demande du travail, mais ne parait pas insurmontable. Si cela vous semble une bonne solution, je veux bien essayer. -Zolo (discuter) 7 août 2020 à 19:33 (CEST)

Bonjour Zolo, Hexasoft et Zebulon84 Le transfert des modules de données vers Commons présente effectivement un avantage indéniable : celui de l’internationalisation de la mise à disposition des données.

Et l’utilisation de Commons pour stocker des tables est tout-à-fait faisable, puisqu’elle a été faite avec les données de composition communale, des différentes structures adossées au module:Composition Division de France, une table par région (voir par exemple la table d’Auvergne-Rhône-Alpes) … merci @Zebulon84 (a priori actuellement en wiki-break). En plus l’actualisation de ce type de table est relativement aisé, avec un bon mémo. @JessydeVilly a ainsi pu actualiser ces tables en 2020 alors qu’il n’était pas dans le processus de création initial.

Par contre, ce transfert vers Commons présente-t-il un avantage pour les contributeurs de la WP francophone ? Je n’en vois pas et le problème de l’actualisation des données restera toujours entier. Les inconvénients sont les suivants :

• On devait actualiser chaque année 35000 modèles, actuellement on actualise 35000 modules, demain on actualiserait 35000 tables ;
• Le nom du module (et donc de la table) comporte le nom wikifié de la commune. C’est-à-dire qu’à chaque renommage d’article de commune (une dizaine par an), il faut renommer le module et donc demain la table. Les contributeurs non expérimentés mais adeptes du projet:Communes de France ont pris le pli et le font désormais sans pb, mais est-ce aussi simple dans Commons, de renommer un fichier ? Je n’en ai pas l’impression ;
• L’actualisation annuelle de ces 35 000 modules est actuellement fait par une seule personne, moi en l’occurrence. Et je m’en passerais bien ! C’est quand même limite comme système. Le bot est écrit en VBA, j’envisage bien de mettre à dispo le code, mais d’une part le code n’est pas optimisé et d’autre part paradoxalement pas beaucoup maîtrisent le VBA ;
• Le pb d’optimisation du code porte sur une question de mémoire. J’ai l’impression qu’à chaque tour, le bot me bouffe un peu de mémoire de sorte qu’au bout d’un certain temps il se met à bugger et à planter tout. Je ne peux donc travailler que par lots de 5000 puis redémarrer l’ordi !
• Le pb du nom wikifié est aussi un pb pour l’actualisation. Je suis en effet obligé de tenir à jour une base des noms wikifiés, qui de fait n’est jamais vraiment à jour. Certes, un petit test me permet de détecter les modules en redirection, mais cela nécessite là aussi de faire repasser le bot spécifiquement pour ces articles.

Si on veut utiliser Commons, un vrai progrès serait de mettre en place un système similaire à celui des compositions communales, à savoir des tables régionales communales annuelles, indentées sur le code Insee des communes.

Les avantages :

• De 35000 fichiers à actualiser, on passerait à … 18 !
• Les bases de l’Insee sont ordonnées selon le code Insee, ce qui facilite bien entendu le traitement et la création des tables, la seule difficulté est dès lors dans la récupération du code WD qui peut se faire avec une requête adaptée ;
• On n’a plus de problème avec les renommages.

Ce que cela sous-tend :

• Adapter le module de traitement : jusqu’à une certaine année, il va chercher les données dans des modules de données, puis au-delà il va les chercher dans des tables sur Commons, pour chaque année, ce qui nécessite un mappage multiple et différencié (un du module communal puis un par année).

Telle est ma proposition. Est-ce possible ? je ne suis pas assez calé en lua (et c’est un euphémisme) pour y répondre. Mais peut-être que vous pouvez me le dire. Cordialement.Roland45 (discuter) 8 août 2020 à 11:02 (CEST)

Bonjour Zolo, Hexasoft et Roland45 ,

Effectivement, la base Commons se met à jour sans difficulté en moins d'une heure pour toutes les divisions françaises ! Un réel gain de temps.

Le passage vers une table régionale annuelle de données de population serait une bonne solution. On pourrait utiliser l'identifiant Wikidata de la commune actuelle pour faire le lien entre population et composition dans le {{Composition Division de France}} (puisque d'une année à l'autre, un même Code Insee peut être utilisé pour deux communes différentes avec les créations de communes nouvelles).

@Zolo je te conseillerais peut-être de commencer par les départements ou les régions (moins de conversions à faire) pour les tests !

Cordialement, Jessy ^Oui ? 8 août 2020 à 11:16 (CEST)

Noter que si ce mappage différencié modules/Tables Commons est difficile, on peut imaginer recréer des tables annuelles mappant toutes les communes ou autres divisions pour chaque recensement depuis 1793, ce qui permettrait de ne travailler que sur Commons. Probablement difficile, mais pas impossible.Roland45 (discuter) 8 août 2020 à 11:19 (CEST)

Merci pour votre réponses

Pour répondre sur les problèmes comprementionnés par Roland :

• Actualisation : a priori, je dirais que mettre à jour les tables Commons est un peu plus facile que les modules, car elles sont dans un format Json standard, alors qu'il faut quelques transformations ad hoc pour passer à un format Lua. Mais tout dépend bien sûr de ce qu'on a à dispositions en termes de script et de robots. L'idée serait d'avoir un format compatible avec le plus de pays possibles pour impliquer plus de monde.
• Renommage des pages : Wikidata possède la propriété "tableau de population (d)". Passer par cet intermédaire devrait simplifier les choses.

Concernant la régionalisation des données. On pourrait imaginer 18 gros fichiers qui comporteraient en moyenne 2000 communes, avec toutes les données. Mais avec une quarantaine d'années renseignées par commune, les fichiers me semblent trop gros pour être utilisables sur Wiki. Avoir un fichier par région par année, me parait encore plus compliqué en termes de réutilisation sur Wikipédia. Il faudrait alors charger tous les fichiers annuels pour pouvoir créer un tableau de population communal. En revanche, je pense qu'il existe des bots qui savent faire l'opération <trouver l'élément Wikidata d'une commune à partir de son code INSEE puis trouver le fichier Commons où sont stockées les données démographique pour cette commune> (même s'il faut étudier de plus près le cas où un même code INSEE change de signification exacte au cours du temps. -Zolo (discuter) 8 août 2020 à 11:38 (CEST)

@Zolo Il y a effectivement le problème des code Insee dont le territoire associé change, à l'occasion en général de la création d'une commune nouvelle. Un recensement avait été fait en 2017, voir ici. 303 (dont le nom associé au code a changé) sur 35000, ce n'est pas énorme. A priori cela est traité au cas par cas dans Wikidata (enfin … j'espère!)Roland45-Bot (discuter) 8 août 2020 à 14:10 (CEST)

Apparemment, le code insee du premier nom de la liste, Arbignieu n'est pas encore sur Wikidata. On a vraiment besoin d'améliorer la collaboration inteprojet... Par ailleurs, même quand Wikidata est à jour, le fait que le même code puisse être utilisé pour deux communes distinctes peut compliquer les choses pour les bots, mais sans doute rien d'insurmontable.

J'ai commencé à expérimenter une conversion des modules actuels pour utiliser Commons. Modèle:Population de France/tableau/Test utilise les données de Commons. Mais je ne suis pas sûr de tout comprendre dans les modules. Quelqu'un pourrait m'éclairer sur les deux points suivants :

• quelles années exactement faut il exactement retenir pour l'affichage dans les tableaux et graphiques ?
• Y-a-t-il des communes pour lesquelles la source à afficher n'est pas : De 1962 à 1999 : population sans doubles comptes ; pour les dates suivantes : population municipale. (Sources : Ldh/EHESS/Cassini jusqu'en 1999 puis Insee à partir de 2006. ? J'ai l'impression que le module prévoir des exceptions, mais je ne trouve pas d'exemple. -Zolo (discuter) 8 août 2020 à 15:01 (CEST)

@Zolo Avant de se lancer dans le projet, il est effectivement important de comprendre les modalités de recensement en France. Je ne vais pas trop entrer dans le détail, (il est donné de manière ultra-synthétique dans la doc du module, voir par ex L'Abergement-Clémenciat, ou en détail dans ce doc). Comme chaque année diverses communes franchissent le seuil des 10 000 habitants dans un sens ou dans l’autre, l’Insee publie chaque année un calendrier des recensements (visible dans la page donnée en lien).

Le plus simple aurait été de retenir le principe de publier toutes les populations à partir de 2006, mais comme tu l'as bien perçu il y a bien des exceptions d'affichage : on n'affiche dans le tableau comme dans le graphique que les communes dont la valeur du paramètre recens du module est "true". En effet comme on ne sait pas faire simple, le principe retenu par le projet a en fait passablement compliqué les choses :

• Jusqu'en 2006 : tous les recensements exhaustifs
• À partir de 2006 :
  • Pour les communes de moins de 10 000 habitants : tous les recensements exhaustifs + la dernière population légale publiée (n)
  • Pour les communes de plus de 10 000 habitants : 2006, 2011, 2016, etc + la dernière population légale publiée (n)

Ainsi à partir de 2006, on n’affiche que les données qui ont le paramètre ["recens"] = true

Soit dit en passant c’est une des difficultés de l’actualisation du modèle, car pour 3/5 des communes de l’année précédent le millésime d’actualisation, il faut changer le paramètre recens de true en false.

Si on fait des tables annuelles sur Commons, on a deux options :

• soit mettre le fameux paramètre recens dans la table annuelle, ce qui conduit à revenir sur 3/5 des communes de la table de l’année précédente ;
• soit traiter ce paramètre directement dans le module de traitement à partir d’une table intermédiaire annuelle des recensements (que l’on trouve ici, appelée millésime de collecte – un recensement est dit exhaustif en 2020 si le millésime de collecte est 2020 – c’est pourquoi pour L'Abergement-Clémenciat – 01001 – recens pour 2016 est true, car on a 2021 dans la table pour cette commune, les recensements étant quinquennaux).

Je le reconnais, comme je l’ai déjà dit, le plus simple serait d’afficher tous les recensements connus sans se poser de question et on n’a aucun test à faire. Mais certains piliers du projet:Communes de France tiennent mordicus à ces principes, sans se poser la question de la complexité de l’actualisation des données.

Je crois que dans un premier temps il faudrait réfléchir à un système affichant tous les recensements (sans donc se soucier de ce paramètre recens). Je me ferai fort ensuite de convaincre le projet. Si on a un nouveau système beaucoup plus simple à actualiser et ne reposant pas sur une seule personne, et en plus avec une vocation internationale, il n’y a aucune raison à vouloir s’accrocher à l’ancien système.

J'espère avoir été clair. Cordialement.Roland45 (discuter) 8 août 2020 à 17:27 (CEST)

Merci Roland45, cela me semble assez clair.

Le paramètre "recens" reposant sur un choix éditorial propre à Wikipédia en français, il me parait délicat de le mettre sur une fichier Commons partagé. Mais comme tu l'avais évoqué, on pourrait arriver à un résultat semblable en utilisant un critère "méthode de détermination" qui n'aurait pas besoin d'être mis à jour, et que d'autres utilisateurs pourraient utiliser autrement selon leurs besoins. Je l'ai mis sur c:Data:Population FR 01001 L'Abergement-Clémenciat.tab. A partir de là, il ne me semble pas très compliqué de programmer le module pour tenir compte de la méthode de dénombrement, et du fait qu'un chiffre soit le plus récent ou non . -Zolo (discuter) 8 août 2020 à 18:35 (CEST)

J'ai ajouté une fonction de sélection des donnés dans le brouillon de module. Cela fonctionne pour Modèle:Population de France/tableau/Test. --Zolo (discuter) 8 août 2020 à 19:12 (CEST)

Volets connexes à la création de tables démographiques sur Commons

@Zolo En parallèle à la création de tables sur Commons, il est essentiel d’évaluer en amont les impacts qu’un tel transfert de données peut avoir sur les différents modèles/modules existants. Sans être exhaustif, voici quelques sujets qui me viennent à l’idée.

Bot d’actualisation

Si tu optes pour une table sur Commons par commune, il conviendra de pouvoir disposer d’un bot qui permette de dispatcher chaque année les données fournies par l’Insee lors de l’actualisation annuelle. L’avantage, c’est que ces fichiers sont toujours présentés de la même manière. Les données nécessaires pour actualiser les tables sont les suivantes :

• Données de population : le fichier des populations légales 2017 est téléchargeable ici ;
• Calendrier du recensement pour définir la méthode de détermination : ici, ouvrir "Millésime de collecte des communes (campagne 2021)"

Cela peut te permettre d’entraîner un bot.

Pour info, l’url stable qui permet d’accéder aux dernières données de population est ici. Mais attention, les séries chronologiques ne sont pas exploitables car elles sont établies sur la géométrie territoriale en vigueur à n+2 (2019 dans le cas d’espèce), or dans nos articles les populations affichées correspondent aux géométries en vigueur pour chaque millésime de population (sinon, il faudrait régulièrement reprendre tous les tableaux !)Roland45 (discuter) 9 août 2020 à 10:34 (CEST)

Sur quelques paramètres des modules actuels de données

Tu as peut-être remarqué que les modules comportent certaines informations qui ne sont pas directement en lien avec la population et d’ailleurs qui ne sont pas utilisées par le module:Population de France. Ainsi sur le module de Châteauroux, on a :

["division"] = "commune",
["nom"] = "Châteauroux",
["nom-dep"] = "Indre (département)",
["superficie"] = 25.54,

Les trois premiers sont utilisés par le module:Composition Division de France. Si on bascule sur des tables sur Commons, il faut pouvoir récupérer ces infos quelque part. Plusieurs options :

• soit rajouter ces infos quelque part, dans les modèles d’informations générales, par exemple (en réalité elles y sont déjà, mais sont très loin d’être à jour)
• soit les récupérer via Wikidata
  

Mais dans les deux cas, il faudra modifier le module:Composition Division de France en conséquence.Roland45 (discuter) 9 août 2020 à 10:34 (CEST)

Bonjour Roland45 ,

Ce type de données est assez différent de celui des tables de populations : plutôt qu'un suite de données homogènes, on a un ensemble de données un peu hétérogène. Pour le coup, Wikidata mais parait beaucoup plus adapté que Commons. En fait, ces informations doivent déjà y figurer. Il y aura un gros travail de vérification, et ça ne pourra se faire que par étape. J'ai essayé de faire ci-dessous un tableau de comparaison du format Wikidata et Commons.-Zolo (discuter) 9 août 2020 à 21:09 (CEST)

@Roland45 aurais-tu par hasard le contenu des pages de category:Module de données démographiques dans un format exploitable. L'API n'a pas l'air très adapté aux modules Lua. -Zolo (discuter) 13 août 2020 à 11:19 (CEST)

@Zolo Pas directement sous la main. L'idée serait donc de disposer d'un immense fichier avec en lignes les communes et en colonnes les années et en valeurs les populations. En fait ces données ont été construites en 2013, puis actualisées chaque année. Il n'existe donc pas de fichier directement disponible. Je vois deux méthodes : soit tenter une reconstruction du fichier global à partir des fichiers annuels (mais pas facile du fait des apparitions/disparitions liées aux communes nouvelles), soit faire passer un bot pour récupérer directement les données à partir des modules. Je vais voir ce que je peux faire.Roland45 (discuter) 13 août 2020 à 11:43 (CEST)

@Zolo Après une petite réflexion, il y a quelque chose de rédhibitoire pour la reconstruction d'un fichier global à partir de fichiers élémentaires, c'est cette notion de méthode de détermination du recensement depuis 2006. Impossible à traiter automatiquement sans avoir les calendriers annuels (que je n'ai pas). La seule méthode est donc la récupération des données à partir des modules. Je vais voir.Roland45 (discuter) 13 août 2020 à 12:02 (CEST)

Sous-modules connexes

Plusieurs sous-modules du module:Population de France permettent d’obtenir diverses informations complémentaires : dernière population, dernière année de recensement, etc Il conviendra que ces sous-modules aillent bien piocher au bon endroit dans les tables de Commons.Roland45 (discuter) 9 août 2020 à 10:34 (CEST)

Module:Population de France/Introductions

@Zolo, Bonjour à toi, Ta réécriture du module d'introduction entraîne le non affichage de l'introduction pour les communes nouvelles, à la place, un "<err>" s'affiche~(voir ici ou encore là). Peux-tu y jeter un œil ?

Merci Cordialement, Jessy ^Oui ? 18 août 2020 à 13:43 (CEST)

Module:Population totale

Le module:Population totale utilise aussi des données des modules et sous-modules. Il conviendra ici aussi qu’il pointe sur les tables de Commons.Roland45 (discuter) 9 août 2020 à 10:34 (CEST)

Cette remarque concerne également tous les modèles dans lesquels est inclus le module:Population totale, comme par exemple {{Population Aire urbaine d'Hirson}}. Mais soit dit en passant, ces modèles présentent un défaut majeur : ils ne prennent pas en compte l'évolution territoriale de ces entités (création de commune nouvelle, disparition, renommage, extension de territoire, etc). En fait le module:Composition Division de France devrait pouvoir traiter toutes les entités supra-communales existantes dans l'organisation territoriale de la France (et figurant dans le fichier du découpage communal ici) et disposer d'une fonction de sommation, ce qui n'est pas formellement le cas actuellement, puisque le total figurant en bas de tableau n'est pas obtenu par sommation, mais récupération de la valeur de l'entité supérieure (département en général). Mais on s'éloigne du sujet des tables de Commons.Roland45 (discuter) 10 août 2020 à 08:47 (CEST)

Des tables de données d’informations générales sur Commons ?

Quand tout sera au point en matière de population, on pourra envisager de transférer sur Commons également les modèles de données d’informations générales (comme celui d’Adon).

Mais cela ne pourra être fait que si on dispose :

• d’un outil d’actualisation facile de ces modèles/tables (qui n’actualiserait que certains champs à chaque moulinage) ;
• d’un outil qui permette de récupérer facilement n’importe quelle valeur de ces tables en fonction du nom du paramètre (actuellement avec les parser fonctions, cela est relativement facile (pour ceux qui connaissent ces fonctions), cela l’est moins en lua. Avoir un tel outil générique serait particulièrement utile.

Je connais une des observations : mais pourquoi n'utilise-t-on pas Wikidata pour ces données ? Et ma réponse: parce que tant que Wikidata sera aussi abscons (pour le contributeur de base) en matière d'accès et d'actualisation, et d'outil d'extraction, on n'en sortira pas. Des tables sur Commons sont bien plus visuelles et manipulables, me semble-t-il (comme le sont actuellement ces modèles de données).

Bon, il y a probablement d'autres sujets à prendre en compte, mais chaque chose dans son temps.Roland45 (discuter) 9 août 2020 à 10:34 (CEST)

 Roland45 : Sauf erreur de ma part, on a déjà dans les tables régionales sur Commons, pour chaque commune, les divisions auxquelles elle appartient au 1^er janvier de l'année n. Il faudrait un script capable de convertir les numéros Insee en lien Wikipedia. Je pense que c'est possible pour toutes les divisions actuelles, exceptées les intercommunalités (mais pas sûr).

Pour être plus clair, si l'on prend la Liste des communes de l'Ain, le canton, l'arrondissement et l'intercommunalité pourraient être extrait de la table, et donc les modèles d'informations générales serait inutile pour le {{Composition Division de France}}.

Cordialement, Jessy ^Oui ? 12 août 2020 à 14:40 (CEST)

@JessydeVilly je ne vois pas exactement quel utilisation tu as en tête comme utilisation du script, mais à partir de Data:Table/Communes Auvergne-Rhône-Alpes.tab, on peut facilement utiliser l'identifiant Wikidata d'une commune lié un code INSEE donné, et à partir de là trouver l'article Wikipédia.--Zolo (discuter) 12 août 2020 à 15:46 (CEST)

@Zolo Dans la table, "arr" est le code insee de l'arrondissement, "cv" celui du canton et "epci" de celui de l'interco. Je suppose que pour la construction des lignes du tableau, on pourrait extraire ces infos pour chaque commune et les convertir en lien vers la page WP, plutôt que d'aller les chercher dans les modèles d'informations générales actuels.

Exemple : Pour L'Abergement-Clémenciat, on extrait 012, 0108, 200069193 et on affiche respectivement Bourg-en-Bresse, Châtillon-sur-Chalaronne, CC de la Dombes. Je pense qu'il est possible d'aller chercher dans les tables commons:Data:Table/Arrondissements.tab et commons:Data:Table/Cantons.tab le lien vers l'article en question (soit Canton de Bourg-en-Bresse et Arrondissement de Châtillon-sur-Chalaronne), plutôt que d'utiliser le {{Données/L'Abergement-Clémenciat/informations générales}}.

J'espère avoir été clair dans mon explication,

Cordialement, Jessy ^Oui ? 12 août 2020 à 22:53 (CEST)

Merci Utilisateur:JessydeVilly. Oui je pense que c'est clair. Il faudra vérifier le résultat en termes de performance, mais ça doit être faisable. Je pourrai essayer de faire des essais si j'arrive à comprendre comment fonctionne Module:Composition Division de France (c'est un mélange de Lua et de Wikitexte un peu difficile à cerner de prime abord). Ce sont bien les tables comme commons:Data:Sandbox/Roland45/Arrondissements.tab qu'il faut utiliser ? Il faudrait les sortir de "sandbox". -Zolo (discuter) 13 août 2020 à 09:52 (CEST)

@Zolo Je pensais à cette table commons:Data:Table/Arrondissements.tab, déjà utilisée par le module pour donner la liste des arrondissements d'une région ou d'un département. Je ne sais pas si la table en l'état peut être exploitable, peut-être faudra-t-il récupérer des infos de celle de @Roland45.

Cordialement, Jessy ^Oui ? 13 août 2020 à 10:31 (CEST)

@JessydeVilly la table est exploitable, mais en fait ce que je cherche, c'est la signification des codes d'intercommunalité (200000172 -> Communauté de communes Faucigny-Glières). La seul endroit où je les vois, c'est commons:Data:Sandbox/Roland45/Intercommunalités.tab. -Zolo (discuter) 13 août 2020 à 11:12 (CEST)

@Zolo tu touches en fait le nœud du problème. 200000172 est le code Siren de l'interco, équivalent du Code Insee. De nombreux fichiers du Ministère de l'Intérieur (Banatic ou autres) sont en fait référencés par ce code. Indexer nos données avec ce code permet de s'affranchir des noms tout le temps changeants de ces intercos. Si j'avais fait un essai de table sur les intercos, c'était pour avoir directement disponibles les noms des intercos. Mais la seule manière de disposer du nom correct des intercos est bien d'avoir une table des codes Siren de ces EPCI et des codes Wikidata en vis-à-vis (et pas d'avoir cette table avec des noms en dur). Je ne pense pas qu'elle existe pour l'instant.Roland45 (discuter) 13 août 2020 à 11:32 (CEST)

@Zolo et @Roland45 Bonjour, effectivement (et Roland m'a devancé) cette table n'existe pas à l'heure actuelle. Les intercommunalités ne sont encore pas gérée par le {{Composition Division de France}}, tout comme les Aires urbaines et les Unités urbaines. Je peux publier une table au 1^er janvier 2020, mais cette dernière ne sera pas à jour. Cependant, cela peut certainement te servir de base pour les tests ?

Je ne sais pas si les intercommunalités sont à jour sur Wikidata. À voir.

Jessy ^Oui ? 13 août 2020 à 11:41 (CEST)

S'il y a un endroit où il faut stocker les codes SIREN des intercommunalités à jour, c'est je pense Wikidata. Ce n'est pas forcément exploitable directement sur Wikipédia, mais on peut sans problème les récupérer périodiquement pour faire une table sur Commons ou Wikipédia.

Apparemment, lorsqu'un intercommunalité change de nom, la pratique est de créer un nouvel élément Wikidata avec le nouveau nom, d'indiquer une "date de dissolution" pour l'ancienne, et d'indiquer "remplacé par": nouvelle intercommunalité.

On n'a bien besoin que des EPCI à fiscalité propre ? Voici alors ce qu'on a sur Wikidata : https://w.wiki/ZSp Sinon, on peut élargir la requête, s'il y a quelques données inutiles, ce n'est pas forcément gênant.-Zolo (discuter) 13 août 2020 à 12:21 (CEST)

@Zolo Très bien cette requête. On n'a effectivement besoin que des EPCI à fiscalité propre. Il est vrai que c'est particulièrement efficace quand on maitrise Wikidata et ses requêtes. Roland45 (discuter) 13 août 2020 à 14:34 (CEST)

Les listes de communes manuelles

Le cas des listes de communes manuelles avec les modèles {{Tableau Liste commune de France}}, {{Tableau Liste commune de France 2}}, {{Composition en communes division de France}} et {{Composition Division de France}} :

• Actuellement, le premier modèle (historique) est conservé car il utilise les modèles de données de population pour les divisions antérieures à 2015. Exemples concrets d'utilisation : les listes de communes déléguées/historiques d'une commune nouvelle (Picauville#Histoire), ou encore la composition avant 2015 d'un canton (Canton de Carentan-les-Marais#Composition avant 2015).
• Le modèle {{Tableau Liste commune de France 2}} a un fonctionnement similaire à {{Composition en communes division de France}} (qui n'est autre qu'un appel au module Composition Division de France). Il a la même fonction que {{Tableau Liste commune de France}}, mais il est écrit en Lua et utilise les modules de données de population. Il est également utilisé pour les listes de communes déléguées/historiques d'une commune nouvelle, mais aussi pour les listes de communes par intercommunalité.

Dans les deux cas, la syntaxe d'appel dans les articles ne fonctionnera plus :| commune 1 = Picauville | commune 2 = Amfreville

De plus, lorsque toutes les données de population seront migrées dans des tables, les trois premiers modèles listés seront donc voués à disparaître, au profit d'un seul.

Jessy ^Oui ? 12 mars 2021 à 01:10 (CET)

Comparaison tables Commons et Wikidata

Sujet	Wikidata	Commons
Format de stockage	Wikibase	Json
Commentaire format	Structure relativement complexe. Fomat expressif, permettant d'ajouter des sources précises et diverses qualifications. Consommateur de mémoire.	Concis et léger.
Adapté pour	Données complexes ou hétérogènes.	Données homogènes séries temporelles, peut être certaines données numériques.
Organisation des données	Par élément. En gros 1 concept = 1 élément. Les relations sémantiques entre éléments permettent une exploration programmatique des données.	Par fichier. 1 fichier = 1 lot de données homogènes. Possibilité de créer deux fichiers portant sur le même sujet mais utilisant des sources ou une méthodologie différente.
Indexation et recherche des données	Moteurs de recherche puissant.	Peu de fonctionnalités de recherche. Pas de catégorisation. Documentation minimaliste. Le mieux pour retrouver les données est sans doute de lier depuis Wikidata.
Récupération sur Wiki	Facilement utilisables sur Wiki, avec des limites quantitatives dues au volume occupé par les données.	Données faciles à récupérer. Facile à utiliser si on connait la manière dont elles sont structurées.
Utilisation externe	Point Sparql et outils divers.	Données téléchargeables, mais ne semblent pas encore vraiment utilisées.
Présentation pour le lecteur	En langage naturel. Généralement facile à comprendre mais souvent fouillis sur les éléments de grande taille. Quelques outils de mise en page externes.	Table concise et propre mais l'utilisation des codes Wikidata comme valeur peut rendre la compréhension compliquée.
Edition manuelle	Editeur interactif.	Modification du code source Json.
Multilinguisme	Multilinguisme natif pour les données de type "élément".	Possibilité de traduction des textes, mais fichier par fichier. Possibilité d'utiliser les identifiants Commons pour automatiser la traduction sur le site client.
Risque de vandalisme	Modéré. Résumé et historique de modifications précis, mais la diversité des données et le grand nombre de modifs peuvent rendre le suivi en temps réel difficile. Risque de modification bien intentionnées mais contre-productives.	Sans doute faible. Données peu visibles. Contraintes formelles empêchant les modifications hâtives.
Bots et outils	Communauté importante, outils variés.	Rien pour l'instant ?
Licence	CC0 (équivalent domaine public).	CC0,CC attribution, ou CC attribution share alike.

@Zolo Ton tableau est très intéressant, mais probablement un peu trop optimiste.

Tu oublies de préciser les réticences vis-à-vis de Wikidata (et peut-être à terme vis-à-vis de Commons, mais moins je pense) qui viennent de sa complexité d'appropriation par un utilisateur lambda, précisément du fait de cette structuration par élément. Ne serait-ce qu'en actualisation, cliquer sur un des crayons pour modifier une donnée renvoie dans l'univers Wikidata où on est noyé immédiatement, ou même si on n'est pas noyé, cela prend un temps certain pour actualiser une simple donnée. Une interface visuelle (de type table directement dans Wikipédia), permettrait un meilleur accès. Quant à créer un nouvel élément, ou la valeur d'une propriété, je n'en parle pas. Et actualiser en série des valeurs, encore plus abscons. Tu dis qu'en matière de bots, il existe des outils variés. J'en ai vu quelques-uns, mais pas pléthore. Tu dis que la communauté est active, là aussi j'en doute. Car l'extraction de données WD ne peut se faire qu'en lua et le nombre de développeurs français actifs en lua n'est pas légion, je dirais même qu'ils sont moins d'une dizaine et quand j'ai posé des questions sur le projet Scribunto, je n'ai pas eu tellement d'écho.

Je ne dis pas qu'il ne faut pas se lancer dans ce changement de système. Je dis simplement qu'il faut penser très en amont à l'utilisateur occasionnel (averti quand même, mais pas expert de tel ou tel langage) et développer des outils qui soient accessibles à ce type d'utilisateur.

Si tu veux un exemple (concernant Wikidata), il suffit de considérer les données d'un modèle d'informations générales. Si on les transfère dans Wikidata, il faut au moins deux outils :

• un outil qui charge automatiquement sur Wikidata les valeurs d'un élément (et sa source) à partir d'une table de l'Insee qui est toujours indexée par le code Insee (un outil qui doit donc être facilement généricable) ;
• un outil d'extraction facile de ces données de Wikidata vers Wikipédia, en lua donc. Je ne parle pas d'un outil dédié pour telle ou telle tâche, mais bien d'un outil générique où on entrerait, pour un élément donné (ex : Toulouse/Q7880) en paramètres différentes propriétés (ex code Insee/P374, Population/P1082, Date/P585, valeur date/2013) et cela sortirait automatiquement la valeur recherchée (ici 458298).

Sauf erreur de ma part, ce type d'outil n'existe pas. Le même type d'outil doit être développé pour ces tables sur Commons. Qu'en penses-tu ?Roland45 (discuter) 10 août 2020 à 09:43 (CEST)

 Roland45 : je pense qu'il faut distinguer plus explicitement la partie chargement / entretien des données et la partie exploitation sur Wikipédia. Les difficultés ne sont pas les mêmes.

Concernant le chargement des données :

• Beaucoup de jeux de données ont été chargés sur Wikidata. On peut trouver des utilisateurs actifs dans ce domaine, même s'il est vrai que la demande est forte par rapport à l'offre. Pour les données sur Commons, ça ne parait pas plus compliqué technique, il ne semble pas y avoir grand monde travaillant là dessus pour l'instant.
• Dans l'absolu le chargement et la maintenance des données devrait être plus facile que sur Wikipédia. Mais bien sûr, sur Wikipédia il y a déjà l'expédience et tes scripts, ça demande de mettre certaines choses à jour. Si on a une fichier contenant les populations des communes sur une année avec leur code insee, on peut le charger Wikidata facilement avec quickstatements), avec juste quelques difficultés pour les cas où un code INSEE a changé de signification. Sur Commons, on a pas encore d'outil de ce genre, ce sera à développer.
• Modifier Wikidata peut-être un peu déroutant, mais là on parle de donner provenant directement d'une source externe type INSEE, qui a priori n'ont pas vocation à être modifiées individuellement par le contributeur de passage. Par ailleurs, ces données sont pour l'instant stockées dans des modèles ou dans des modules Lua, qui ne me parait pas plus simple qu'une page Wikidata.
• Créer un nouvel élément Wikidata ne me parait vraiment pas compliqué, même s'il faut intégrer quelques conventions. Pour les nouvelles propriétés, c'est assez bureaucratique.... mais si on est pas trop pressé, ça peut bien se passer.

Concernant la réutilisation sur Wikipédia :

• Réutiliser les données de Commons ou de Wikidata ne me parait pas forcément plus complexe que d'utiliser les données stockées localement dans des modules. Module:Wikidata est relativement complet je crois (corrolaire, la doc peut faire un peu peur, mais ce n'est pas si compliqué !). Pour récupérer la population de Toulouse en 2013, c'est {{Wikidata|entity=Q7880|property=P1082|atdate=2013}}->458 298 (bon en l'occurrence il y avait un bug que je viens de le réparer).
• Là où le manque de main d'oeuvre est le plus grand, c'est je crois plus sur le développement des modules que sur la gestion des données. Mais ça c'est une autre histoire... -Zolo (discuter) 10 août 2020 à 12:46 (CEST)

 Zolo : Merci pour tous ces éléments. Quelques réflexion complémentaires :

Sur le chargement

• Quickstatements m’avait été conseillé pour du travail en masse (par @VIGNERON me semble-t-il) et je l’ai essayé. Mais bizarrement ne suis pas arrivé à charger des données, probablement des questions de mise en forme et ai rapidement abandonné. D’autant que semble-t-il Quickstatements ne travaille pas comme un robot que tu lances en cliquant simplement sur un bouton, mais par des lots de commandes que tu es obligé de lancer

Sur l’exploitation des données

• le module:Wikidata , que je ne connaissais pas, répond effectivement à ma question. Il m’a l’air assez complet et semble pas mal utilisé, en mode caché. Dans les articles de communes, j’ai vu que des éléments Wikidata sont appelés, mais n’ai pas bien vu où, probablement dans le modèle d’Infobox Commune de France ou de subdivision administrative française, mais n’ai pas vu où dans le code.

• Je confirme que les développeurs actifs ne sont pas légion. J’avais posé par exemple en janvier 2019 sur le projet Scribunto une question relative à une modif du module:Composition Division de France (pour rappel actuellement le seul qui utilise des tables sur Commons) pour ajouter une simple phrase (ici). Pas de réponse. Bon, le pb a été contourné assez facilement, mais c’est pour dire qu’avant de basculer dans le nouveau système, il faudra être sûr de disposer de ces outils de chargement ou d’exploitation adaptés.

Bon, je vais te laisser réfléchir à ce système de tables. La description globale du système d'information territorial du Projet:Communes de France est décrite ici. Dans l'historique, je n'ajoute pas encore une ligne « 2020 : basculement sur Commons des données démographiques et adaptation des modules de traitement en conséquence ». Mais cela pourrait bien venir! Cordialement.Roland45 (discuter) 10 août 2020 à 16:45 (CEST)

@Roland45 effectivement quickstatements fonctionne par lot. Ca fait longtemps que je ne l'ai pas utilisé et je ne sais pas la taille maximale des fichier qu'il peut gérer en une fois. Mais il y a aussi pas mal de bots et un tutoriel pour faire le sien. J'ai fait une annonce sur le "project chat" de Wikidata pour tenter d'éveiller un peu d'intérêt pour les données Commons.

J'ai un peu regardé la doc et les modèles. Il y a beaucoup de choses. Je pense qu'il y a moyen de simplifier un peu l'organisation. -Zolo (discuter) 11 août 2020 à 10:19 (CEST)

Dénomination des futures tables

@Zolo et @JessydeVilly Pour s'affranchir de ces problématiques de noms quelquefois difficiles à gérer quand on utilise le modèle dans un article différent de celui de la commune proprement dite, il me paraîtrait souhaitable d'identifier les modèles avec le code Insee de la commune et non le nom wikifié de la commune. Roland45 (discuter) 13 août 2020 à 14:39 (CEST)

@Roland45, je ne pense pas avoir bien compris à quoi tu fais allusion. À moins que tu ne parles de {{m|Population de France/dernière pop||Code INSEE}}. Si tel est le cas, ne serait-ce pas mieux d’utiliser le code SIREN pour éviter les problèmes de communes nouvelles ?

Cordialement, Jessy ^Oui ? 13 août 2020 à 15:46 (CEST)

@Zolo et @JessydeVilly Si on veut insérer la dernière population d'une commune (par ex Ambutrix) dans un article qui n'est pas Ambutrix, le code est le suivant {{Population de France/dernière_pop||Ambutrix}} , ce qui veut dire que si un jour le nom de la commune change, le modèle renverra une erreur. En mettant le code Insee dans le nom du module (ou plutôt de la table)(Module:Données/01008/évolution population et non Module:Données/Ambutrix/évolution population), on n'a plus ce problème, l'appel se faisant avec {{Population de France/dernière_pop||01008}} qui renverra toujours vers la bonne table même en cas de changement de nom de la commune.Roland45 (discuter) 13 août 2020 à 15:58 (CEST)

@Roland45 Bien compris. Mais l'objectif n’est pas de ne plus utiliser de module de population ? Au profit d’un système plus simple à actualiser ?

Cordialement, Jessy ^Oui ? 13 août 2020 à 16:18 (CEST)

@JessydeVillyIl s'agit de remplacer les modules de populations par des tables de population par commune sur Commons, qui ont l'avantage d'être mises à dispo au niveau international (interwiki) et qui sont plus simples à actualiser (enfin bon, quand on aura un bot qui fera la jonction entre les tables en question et le fichier annuel de population de l'Insee).@Zolo me démentira si je dis une bêtise.Roland45 (discuter) 13 août 2020 à 16:26 (CEST)

@Roland45 Donc une table par commune... Dans ce cas, il faut utiliser le SIREN et non le numéro INSEE. L’idée d'une table annuelle par région n’est pas envisageable ?

Jessy ^Oui ? 13 août 2020 à 16:59 (CEST)

@JessydeVilly Oui, une table par commune comme pour les modules. L'autre solution était effectivement de conserver les modules jusqu'à une année donnée (mettons 2017) puis avoir ensuite des tables régionales par an, mais cela complique sérieusement le module de traitement et c'est toujours batard un système unifié s'appuyant sur deux systèmes de données (dont un ne serait pas en interwiki).Roland45 (discuter) 13 août 2020 à 17:06 (CEST)

Oui une table par commune est beaucoup plus pratique pour des données démographiques. En revanche, celle-ci ne pourra contenir que l'historique de la population, pas les superficies et autres. Pour ces autres infos, le mieux est je pense de les stocker sur Wikidata (elles y sont déjà en fait).

Concernant le nom : on devrait renforcer un peu le système et rendre ainsi la question moins critique. On devrait récupérer les données Commons par l'intermédiaire de propriété Wikidata P4179 (« tableau de population »). Si le module est renommé, Wikidata doit se mettre automatiquement à jour. Utiliser le nom de la commune dans le titre est un peu plus lisible, mais effectivement un code INSEE évite les problèmes d'encodage et de majuscule. Si le numéro SIREN est plus stable, ça peut être pratique, même si je pense que c'est moins conventionnel. -Zolo (discuter) 13 août 2020 à 18:17 (CEST)

@Zolo Utiliser le code Siren pour les communes n'est, selon mon point de vue, pas envisageable. L'exemple de dénomination que tu as donné est FR 01001 L’Abergement-Clémenciat.tab, c'est clairement explicite. Mais je pensais que tout renommage de la commune entrainait a priori un renommage de la table (comme actuellement avec les modules), mais c'était une erreur puisqu'on a ici le libellé géographique et non le nom Wikifié. Il reste toutefois cette problématique de certains codes insee identiques entre commune nouvelle et ancienne commune.Roland45 (discuter) 14 août 2020 à 11:06 (CEST)

Tables départementales

Table de l'Ain

@Zolo Voici la table du département de l'Ain, sous forme d'un fichier Excel téléchargeable en cliquant sur ce lien.

Quelques observations :

• Je n'ai récupéré que les données liées aux années, du coup j'ai zappé l'url référençant toutes les populations de 1793 à 1999, figurant dans le paramètre source1. Je préfère t'envoyer le fichier tel quel pour que tu voies ce que cela donne, je complèterai ensuite. Comme pour chaque commune, c'est la même source, il faudra que tu me précises si tu veux que je l'ajoute en une seule colonne ou bien en une colonne pour chaque année de recensement, ce qui alourdirait passablement le fichier pour des données redondantes (mais faciliterait le transfert vers les tables sur Commons) ;
• La méthode détermination n'est pas formellement définie (avec les codes WD) puisque j'ai récupéré les infos du module qui correspondent à l'affichage de la donnée (true/false ou vrai/faux dans mon fichier). IL faudra me dire si tu veux quelques chose de différent ;
• Certaines cases sont vides, il s'agit de communes nouvelles ou de communes dont le recensement n'est pas connu (en général pour des raisons d'évolution du territoire) ;
• toutes les données de tous les modules n'ont pas été récupérées, mais uniquement celles des communes en vigueur au 1er janvier 2020.

Voilà. Je pense qu'on est sur la bonne voie. Qu'en penses-tu ?Roland45 (discuter) 14 août 2020 à 10:48 (CEST)

Merci Roland,

C'est effectivement beaucoup plus pratique que de partir des modèles bruts. A partir de là, je pense que le plus pratique serait de faire l'essentiel sur Excel, puis de le transformer en un ou plusieurs fichiers textes. Ca permettrait en plus de vérifier plus facilement que les données sont correctes.

Si on fait ça comme ça, il vaudrait mieux avoir l'intégalité des données pour chaque commune sur Excel. Cela comprend

• l'URL de la source
• l'identifiant Wikidata de la source. C'est à dire à chaque fois Q18677019 (« base Cassini ») jusqu'en 1999 et puis des choses comme [[:d:Q8120411|Q8120411 (« Category:1890s establishments in Bermuda »)]] après. Je ne sais pas s'il peut y avoir d'autres sources ?
• l'identifiant Wikidata de la méthode de dénombrement
• l'identifiant du "critère utilisé", c'est à dire qui est inclus dans la population. Pour l'Abergement-Clémenciat, j'avais mis des Q653524 (« population sans doubles comptes ») entre 1962 et 1999, et des Q15715409 (« population municipale ») après 2006. Mais je crois qu'il faut prendre en compte la taille de la commune. Idéalement, il faudrait aussi avoir une valeur pour les périodes antérieures.

J'ai repris ton fichier en inversant les colonnes et les lignes, et en ajoutant une colonne affichant le code Json à exporter pour la première commune [1]. Peut-être pas parfaitement relu, mais c'est pour l'idée. Si on peut avoir ça rempli pour toutes les communes, ça devrait être relativement simple après. --Zolo (discuter) 14 août 2020 à 13:56 (CEST)

@Zolo Je travaille avec une version d'Excel antérieure à … 2003! et je ne dispose donc que de 65 536 lignes sur 256 colonnes. Ca te dérange si je maintiens la disposition actuelle et que tu fasses la transposition ensuite ?Roland45 (discuter) 14 août 2020 à 14:22 (CEST)

@Roland45 Oui bien sûr, voici pour info le lien vers mon fichier détransposé https://www.dropbox.com/scl/fi/yslsbdm3vxvorikqciplo/export-communes-commons.xlsx?dl=0&rlkey=4iuq1zrrsl03rl7pjpmf0jr16 Zolo (discuter) 14 août 2020 à 14:54 (CEST)

@Zolo Nouveau problème : en retenant 8 colonnes par année, on ne peut caser que 31 années avec mes 256 colonnes (puisqu'il y a 4 colonnes d'utilisées au début), or la plupart des modules comportent actuellement 36 années ! Je réfléchis à une solution.Roland45 (discuter) 14 août 2020 à 15:02 (CEST)

@ZoloSi on concatène la première colonne (qui contient uniquement et systématiquement un crochet "[")avec le début de la deuxième, on peut précisément caser 36 années, ce qui devrait aller. Qu'en penses-tu ?Roland45 (discuter) 14 août 2020 à 15:07 (CEST)

@Roland45 oui pas de problème, je viens d'essayer et la mise en forme se fait de manière automatique. Par contre, j'ai vu qu'il y avait au moins 3 erreurs dans mon modèle :

• il faut des guillement doubles " les simples ' ne fonctionnent pas
• pas de crochet autour de l'année
• pas de virgule après l'URL de la source (même si ça a l'air de marcher quand même avec). --Zolo (discuter) 14 août 2020 à 15:38 (CEST)

@Zolo Pas de pb. Je travaille avec un premier lot de données sur ces bases. La seule difficulté est de trouver la méthode de détermination (puisqu'on doit passer de 2 valeurs (true/false) à 3 (réel, extrapolation, interpolation). Mais bon cela se fait.Roland45 (discuter) 14 août 2020 à 16:07 (CEST)

@Zolo Au fait il ne manque pas un séparateur (virgule) entre pop et méthode ?Roland45 (discuter) 14 août 2020 à 17:00 (CEST)

@Roland45 si effectivement ! -Zolo (discuter) 14 août 2020 à 18:19 (CEST)

Table-3000

@Zolo et @JessydeVilly Bon, j'ai pas mal bataillé, mais voici un premier fichier abouti ... mais qui n'est en fait que provisoire, du fait de deux questionnements pas encore résolus.

Fichier

Le fichier Table-3000.xls listant les données des 3000 premières communes (ordonnés selon le Code Insee) est récupérable ici.

Le nombre de colonnes nécessaires étant supérieur à 256, j'au scindé le fichier en deux feuilles de calcul, qu'il conviendra donc de réassembler pour avoir un fichier unique à traiter.

Difficultés rencontrées pour son élaboration : autant les données antérieures à 2006 étaient correctes puisque crées par un bot, autant pour les communes nouvelles post-2010, créées à la main, j’ai pu relever des erreurs ou absences (absence de valeurs de pop, valeurs true/false ne dépendant ps du recensement, etc). Du coup j’ai reconstitué les paramètres « méthode » à partir du calendrier 2021, on est dès lors sûrs de l’info.

Précision : dans la colonne Cassini, on peut voir un code Cassini en colonne 4 pour des communes nouvelles créées après 2006. Ceci n’est pas anormal. C’est dû au fait que ces communes nouvelles portent le code Insee d’une ancienne commune et ce code Cassini correspond à cette ancienne commune.

ALERTE :
Ne pas transférer sur Commons la totalité des fiches du tableau Table3000. Deux aspects doivent encore être éclaircis ou modifiés :

• Problématique des méthodes de recensement à clarifier ;
• cas de Nice et de la Savoie.

Documentation et questions à résoudre

Il conviendra de rédiger une documentation explicite sur ce modèle, sur la méthode de recensement et la convention d’affichage retenue. Et de savoir où la mettre, car autant avec les modules on pouvait la mettre en tête de code, autant avec les tables sur Commons, on ne peut a priori pas.

Éléments Wikidata

Critère

• Population sans double compte :Q653524 (« population sans doubles comptes »)
• Pop municipale : Q15715409 (« population municipale »)

Méthode de recensement :

• Extrapolation :Q744069 (« extrapolation »)
• Interpolation :Q187631 (« interpolation numérique »)
• Recensement : Q39825 (« recensement de la population »)

Docs de l'Insee

La doc de l’Insee sur le recensement :

• Une page de synthèse : ici
• Une doc plus complète  : ici
• Une page technique  : ici
• Un doc encore plus technique  : ici et notamment l’annexe 5 qui nous intéresse.

Pb 1 : Cas des communes de plus de 10000 habitants

Dans les communes de 10 000 habitants ou plus, une enquête par sondage est effectuée, chaque année, sur 8 % des logements ; au bout de 5 ans, 40 % des logements ont été enquêtés. Ainsi a aucun moment n’a-t-on de recensement exhaustif, ni d’ailleurs d’interpolation ou d’extrapolation. Il s’agit simplement d’une estimation (avec des méthodes bien précises quand même, voir doc).

Pour respecter la charte d’affichage retenue initialement, dans les modules, on avait retenu comme principe de mettre tue ou false suivant que l’on affiche ou pas. Pour les communes de plus de 10 000 habitants on avait, par convention true sur 2006, 2011, 2016, etc.

Dès lors qu’on veut mettre un code Wikidata pour la méthode du recensement, on se complique la vie, en particulier pour les communes de plus de 10 000 habitants :

• il nous manque un code WD du type « estimation » (voir explication ci-dessus)
• si on met un code du type « estimation  » pour ces communes, on va avoir du mal à traiter l’affichage de leurs données. En effet autant avec true/false cela ne posait pas de pb, autant avec un code WD identique pour chaque année, on va être obligés de dire que si pop > 10000 n’afficher que 2006, 2011, 2016, etc et pour les communes nouvelles créées après 2006, n’afficher que année début, puis année début +5 puis année début +10, etc.

Je vois deux solutions pour gérer ce pb :

• soit afficher toutes les valeurs après 2006 (on simplifie drastiquement la question) ;
• soit insérer dans WD un code de convention d’affichage (true/false), (après tout pourquoi pas !).

Pb 2 : Cas de Nice et de la Savoie

Dans la fiche de Cassini, il est dit : « Pour Nice et la Savoie, les recensements de la période 1814-1860 ont eu lieu en 1815, 1822, 1838, 1848 et 1858. » Or lors de la création des modèles, puis des modules, j’avais eu des états d’âme et avais élargi à tout le département des Alpes-Maritimes (actuel). Or si par Nice, il faut entendre le département dont Nice est chef-lieu, à savoir les Alpes-Maritimes, l’arrondissement de Grasse ne faisait alors pas partie des Alpes-Maritimes.

Ainsi les données du fichier Table-3000 est fautif pour ces années. Comme mon bot a recherché les années 1821, 1836, 1846 ou 1856, il ne les as pas trouvées et a renvoyer une valeur vide pour 1822, 1838, etc.

Mais en tout état de cause il y a aussi la problématique de l’arrondissement de Grasse qui doit être réglée. Donc pour l'instant, le 06 doit être mis en attente.

On y est donc presque. Mais des questionnements subsistent. A suivre donc. Je vais poursuivre mes récupérations de données (cela prend un certain temps). Merci de me faire part de toute observation.Roland45 (discuter) 16 août 2020 à 14:33 (CEST)

Discussion

Forme du fichier

Merci user:Roland45, ça avance bien en effet. S'il est possible d'enlever le crochet avant la date dans la colonne E ce serait mieux. Sinon, ça peut se faire après coup. -Zolo (discuter) 16 août 2020 à 16:11 (CEST)

Pas de pb pour enlever le crochet.Roland45 (discuter) 16 août 2020 à 16:41 (CEST)

Merci. Si éventuellement possible ce serait en fait un peu mieux je pense de mettre le chiffre de population avant l'année, pour avoir une structure de donnée plus semblable à celle de Wikidata.

@Zolo Au fait, faut-il vraiment enlever ce crochet (avant l'année) ? parce qu'il marque en fait le début de l'enregistrement (bloc annuel) et n'est pas vraiment associé à l'année. Au même titre que le "]," à la fin de l'url marque la fin de l'enregistrement. Si on l'enlève le premier crochet, il faut aussi enlever le deuxième bloc fermant, mais du coup on n'a aucun séparateur entre enregistrements. Enfin, je pense. C'est pour gagner des colonnes que j'ai fusionné les deux colonnes de début et de fin. Merci de préciser. Maintenant pour que les choses soient claires, je peux rajouter des colonnes au début et à la fin de chaque bloc annuel (avec respectivement, "[" d'un côté et "]," de l'autre). Je vais sortir du cadre, mais je transfèrerai l'excédent sur la 2ème feuille.Roland45 (discuter) 17 août 2020 à 14:46 (CEST)

@Roland45 oui pardon, il faut bien le crochet. Désolé j'ai relu un peu vite, c'est moins intuitif quand c'est à l'horizontaL. --Zolo (discuter) 18 août 2020 à 09:17 (CEST)

Critère utilisé

Il me semble avoir vu sur une page de Wikipédia, que les populations sans double compte n'étaient définies qu'à partir de années 1950 (en plus Wikidata, indique que c'est un indicateur de l'INSEE et l'INSEE n'existait pas avant). C'est ok de le mettre à partir de 1793 ? Sinon, il faudrait mettre une autre valeur ou, au pire "somevalue" pour dire que la méthode n'est pas définie.-Zolo (discuter) 16 août 2020 à 16:11 (CEST)

La population sans double compte est valable jusqu'en 1999 (ici), mais à partir de quand, elle est prise en compte ? Je vais essayer de trouver. Avant, on mettra "somevalue".Roland45 (discuter) 16 août 2020 à 16:41 (CEST)

Communes de plus de 10000 habitants

Si le choix des années à afficher pour les communes de plus de 10000 habitants n'a basé sur rien dans les données elle-même, je pense que le plus simple est de le programmer directement dans le modèle Wikipédia qui les récupère, en laissant le soin aux éventuels autres utilisateurs de choisir ce qui les intéresse.

Concernant la valeur à mettre comme méthode de recencement, si la méthode est relativement stable dans le temps, on peut peut-être créer un élément " collecte d'information annuelle de l'INSEE" ou quelque chose comme ça. -Zolo (discuter) 16 août 2020 à 16:11 (CEST)

OK pour un élément "collecte d'information annuelle de l'INSEE" sur WD. Tu peux le créer et me donner le code ?Roland45 (discuter) 16 août 2020 à 16:41 (CEST)

Voilà : Q98415788 (« collecte d'information annuelle de l'INSEE »).-Zolo (discuter) 16 août 2020 à 18:45 (CEST)

Marche à suivre

Je pense qu'il serait bon de présenter ce qu'on compte faire sur Wikidata avant de se lancer, pour voir s'il y a des suggestions particulières, et pour éventuellement inciteurs d'autres à se lancer pour d'autres pays. On pourrait lancer un projet démographie pour centraliser la discussion et la documentation. J'ai déjà créé un embryon de Wikidata:Wikidata:WikiProject Tabular data. -Zolo (discuter) 16 août 2020 à 16:11 (CEST)

@Zolo D'accord sur la démarche. Pour info, j'ai amélioré le modèle:Infobox Démographie (voir ici) et actualisé en conséquence les Infobox de tous les articles de démographie de pays (203) à partir du World Factbook de la CIA. Pour dire que je suis aussi sur les autres pays au niveau macro. Mais pour un niveau inférieur, c'est plus compliqué car les méthodes de recensement et de restitution sont éminemment variables selon les pays (mais en général plus simples que celle de la France!). Il y avait quand même déjà eu une demande de modèles/modules en ce sens, pour la Belgique ou la Suisse, je ne me rappelle plus. Mais pour la WP Fr. Toi, tu envisages une discussion au niveau Interwiki, me semble-t-il. Du coup la discussion serait en anglais ou en français ?Roland45 (discuter) 16 août 2020 à 16:41 (CEST)

Pour le projet Démographie, il y a le Portail:Démographie, mais c'est bizarre il n'y a pas de projet spécifique associé hormis le Projet:Sciences humaines et sociales. Je vais réfléchir à la question.Roland45 (discuter) 16 août 2020 à 16:46 (CEST)

Pour info, j'ai créé rapidement le projet:Démographie. Mais je pense qu'on n'en fera de la publicité sur les divers projets concernés que quand on aura développé quelques pages thématiques (ressources, démarches associées aux modèles démographique pour la France, etc). Qu'en pensez-vous ?Roland45 (discuter) 16 août 2020 à 18:43 (CEST)

@Roland45 ok merci. J'ai mis un petit message sur d:Wikidata:Upload of demographic data to Commons, opinions needed. Oui les discussion sur Wikidata sont plutôt en anglais, sauf si le sujet concerne vraiment un pays francophone. Mais si quelqu'un poste dans une autre langue, et que Google translate donne quelque chose de compréhensible, ça ne pose généralement pas de problème. Les pages de documentation peuvent être traduites. -Zolo (discuter) 16 août 2020 à 18:50 (CEST)

@Zolo Tu es sûr d'avoir mis un message ? Je ne le vois pas. Je pense que, pour que les gens réagissent, il faudrait un petit texte descriptif du projet, intégrant en particulier le tableau figurant ci-dessus.Roland45 (discuter) 16 août 2020 à 18:53 (CEST)

@Roland45 Oui pardon d:Wikidata:PC#Upload of demographic data to Commons, opinions needed. Et un lien il y a quelque jour vers d:Wikidata:WikiProject Tabular data. -Zolo (discuter) 16 août 2020 à 18:56 (CEST)

OK. Roland45 (discuter) 16 août 2020 à 18:57 (CEST)

Modifications des frontières communales

Si je ne me trompe pas, lors de fusions de communes, une même page de données, disons Module:Données/Corbeil-Essonnes/évolution population mélange des données portant sur des espaces différents. Peut-être est-ce le plus simple techniquement, mais ça pose deux questions :

• idéalement, voudrait-on faire deux fichiers séparés lorsque la commune change de limites ? Pas forcément pour tout de suite, mais pour savoir si réfléchir à la question vaut la peine.
• doit-on vraiment mettre sur un même tableau / graphique les données pré et post-fusion. Par exemple, le saut entre 1946 et 1954 dans le graphique de Corbeil-Essonnes est du à une fusion de commune en 1951, mais ça ne se voit pas du tout à la lecture. Il serait possible de restreindre le graphique de Q208812 (« Corbeil-Essonnes ») à la période post 1951 en analysant les données de Wikidata (en l'espèce, on a "date de création = 1951"). On pourrait faire un tableau séparé pour la période pré 1951, par exemple, en indiquant manuellement la période chronologique à afficher en paramètre de modèle. Se serait désirable ? -Zolo (discuter) 20 août 2020 à 11:35 (CEST)

@Zolo Cette question de la forme de l'affichage des données (tableau, graphique) s'est posée dès le début et a obtenu des réponses diverses. Elle rejoint d'ailleurs la question de la forme des articles eux-mêmes (faut-il par exemple un article dédié pour chaque ancienne commune ?) Voici quelques éléments.

Le principe retenu pour la création des modèles en 2012 a été le suivant :

• communes créées avant 2006 : récupération des données démographiques figurant dans les fiches individuelles dites « Cassini » (les noms en rouge sur l'index) ;
• communes créées après 2006 : récupération des données à partir des fichiers annuels de l’Insee.

Les fiches Cassini recensent les populations dans la géométrie en vigueur correspondant au millésime de population (dans la rubrique « Le nombre d'habitants ») mais précisent également les différents changements de territoire au fil des ans (dans la rubrique « Le territoire communal »). Si tu regardes la fiche de Corbeil-Essonnes, tu vois dans la section « le territoire communal » « Absorbe en 1951, Essonnes» et dans le tableau une rupture des chiffres.

La représentation des données (tableau, graphique) est autre chose. Le fractionnement en plusieurs tableaux n’est pas nécessairement une bonne chose, car on peut perdre en lisibilité quand il y a beaucoup de changements de territoires. Le tout est par contre de bien expliquer l’évolution du territoire dans le texte.

Pour Corbeil-Essonnes, ce choix de scinder en deux périodes a été retenu. @Père Igor a aussi retenu des dispositions similaires dans certains cas (et pourra donner des exemples). Pour un changement et une fusion au maximum de deux communes, c’est envisageable. Mais dans tous les cas si on veut avoir deux tableaux avant la fusion (de deux communes), on est obligé d’aller chercher les données de l’ancienne commune fusionnée à la main !

Je pourrais aussi faire un bot pour aller récupérer les données de toutes les anciennes communes (les noms en noir sur l'index), en gros aspirer presque tout Cassini, mais là c’est plus qu’une aspiration puisqu’il faut aussi traiter la page aspirée. Je ne dis pas que c’est infaisable, puisque c’est ce que j’ai fait en 2012 avec les communes en vigueur alors. Mais c’est titanesque et ici outre les données démographiques, il faut aussi récupérer le type de changement de territoire « réunie en 1951, à Corbeil-Essonnes» pour Esonnes.

Pour pouvoir traiter correctement et automatiquement un affichage multiple (à savoir les tableaux des anciennes communes avant la fusion), la date « date de création » figurant actuellement dans Wikidata est insuffisante. En fait il faudrait charger sur Wikidata la codification des événements dans Cassini (A pour Absorbante, a pour absorbée, C pour Créée, c pour créée, etc) et les noms des communes associées. Là non plus, ce n’est pas infaisable, mais cela ne me semble pas une priorité.

En conclusion, ma position est la suivante :

• poursuivons avec les données et la méthode de traitement actuelles ;
• lorsque le nouveau système sera opérationnel on pourra envisager de :
  • récupérer les données Cassini complémentaires relatives aux anciennes communes;
  • créer les tables nouvelles correspondantes ;
  • ajouter sur Wikidata les données complémentaires sur les changements de territoires et les liens vers les tables nouvelles associées ;
  • modifier le module de traitement pour tenir compte des nouvelles données et paramètres.
    

Cela me semble le plus sage.Roland45 (discuter) 20 août 2020 à 14:59 (CEST)

 Roland45 et Zolo : bonjour. Voici pour information comment j'ai traité la démographie de certaines communes qui ont eu une ou des fusions :

• avec article séparé pour une ancienne commune (Les Eyzies-de-Tayac-Sireuil#Démographie, Le Lardin-Saint-Lazare#Démographie),
• avec deux tableaux dans le même article : Saint-Romain-et-Saint-Clément#Démographie.

Cordialement. Père Igor (discuter) 20 août 2020 à 15:20 (CEST)

@Roland45 et @Père Igor merci pour ces éclaircissements. En cas de fusion, je pense que la présentation idéale serait de superposer des courbes des différents communes fusionnées; un peu commme les courbes violettes et verrtes de mw:Extension:Graph/fr#Exemples de diagrammes. Mais effectivement ce n'est pas forcément la priorité (et puis si en plus des fusions il peut y avoir des scissions ou autres ajustements des limites communales, ça risque de devenir compliqué à générer). -Zolo (discuter) 20 août 2020 à 17:51 (CEST)

 Zolo : autant lorsqu'il y a fusion ou scission de communes, on le sait grâce à Cassini ou d'autres sources, autant lorsqu'il y a cession d'une partie de territoire à une autre commune, il est rarissime d'en avoir l'information, et dans ces cas, on n'a pas connaissance du nombre d'habitants concernés. Pour l'amusement regarde un peu les historiques des communes de Champniers-et-Reilhac (avec Reilhac-et-Champniers) ou Saint-Just (Dordogne) avec Chapdeuil-et-Saint-Just. — Le message qui précède, non signé, a été déposé par Père Igor (discuter), le 20 août 2020 à 15:20‎

Nouveau fichier

@Zolo Voici le nouveau fichier Table-1-3004.xls qui tient compte des diverses observations (sauf pour les communes de 10000 habitants, je n'ai pas encore tranché sur le qualificatif de la méthode, je me demande s'il ne faut pas retenir Q3490295 (« sondage »)). J'en ai bavé avec les Alpes-Maritimes (ex compté de Nice pour partie).Roland45 (discuter) 17 août 2020 à 18:47 (CEST)

Merci, tout me parait bien ! Par contre ça commence en 1990 ? -Zolo (discuter) 18 août 2020 à 09:27 (CEST)

@Zolo Pas du tout. Tu as dû regarder uniquement la feuille Table3000-2. Il y a aussi la feuille Table3000. Pour avoir le fichier complet, tu dois réassembler les deux feuilles (j'étais limité à ces fameuses 256 colonnes). Cela commence bien à 1793.Roland45 (discuter) 18 août 2020 à 13:56 (CEST)

@Zolo Voilà. Cette dernière version du fichier Table-1-3004.xls devrait être la bonne. J'ai ajouté le qualificatif Q98415788 pour les communes > 10 000 habitants et pour les années > 2006. J'ai aussi inversé quelques colonnes méthodes/critères qui n'étaient pas dans le bon ordre. Il est à la même adresse.Roland45 (discuter) 18 août 2020 à 18:13 (CEST)

Merci, je regarderai cela plus en détail. Je risque de ne pas avoir beaucoup d'accès internet pendant quelques jours. -Zolo (discuter) 19 août 2020 à 11:25 (CEST)

@Roland45. Je vois que l'insee indique que la date de valeur est le premier janvier de l'année (https://www.insee.fr/fr/statistiques/4265511). Tant qu'à faire autant l'indiquer, donc mettre 2017-01-01 plutôt que 2017 (je ne sais pas si à partir de quelle année, on peut ajouter ça). -Zolo (discuter) 19 août 2020 à 16:41 (CEST)

@Zolo Oui. C'est important de le préciser puisque la géométrie territoriale est susceptible de varier dans l'année. Par contre je pense qu'on ne peut mettre cette date qu'à partir de 2006, à savoir à partir de la réforme du recensement définie par le décret de 2003. Pour les années antérieures on met l'année sans précision calendaire. Je vais faire cela. Au fait, ça y est j'ai basculé sur Excel 2019 pour pouvoir produire un fichier unique. J'ai du mal à m'y retrouver tant cela a changé depuis ma version, mais cela va aller.Roland45 (discuter) 19 août 2020 à 16:53 (CEST)

Données pour d'autres pays

J'ai regardé à tout hasard s'il y avait des données tabulaires à télécharger pour les autres pays. Et effectivement dans beaucoup de cas, on peut récupérer ce genre de données, soit au niveau du pays, soit à un niveau inférieur. Par exemple pour le Royaume-Uni, on a ce genre de table, récupérable en .csv ou .xls, qui permettrait de faire une table adaptée sur Commons et remplacer à terme utilement un tableau en png et un texte périmé dans l'article concerné (voir la situation actuelle).

Chaque chose dans son temps bien entendu. Mais tout ça pour dire que pour une transposition à d'autres pays, il faudra :

• à côté du module actuel qui permet de produire les tableaux, sections et autre textes pour la France, il conviendra d'avoir un module plus standard, non dédié à la France ;
• un outil d'extraction de données ponctuelles issues d'une table (style wikidata pour WD) ;
• un outil de chargement facile sur Commons, à partir d'un lot de données formatées en json (type quickstatements pour WD).

Bon, c'était histoire de garder ça en tête!Roland45 (discuter) 17 août 2020 à 11:40 (CEST)

Je pense que le mieux en fait serait d'avoir un seul module, mais avec des sous-modules ou des fonctions pour personnaliser en fonction du pays. Je ne sais pas si ça peut être utile, mais on pourrait aussi des paramètres pour personnaliser l'affichage au niveau de l'article. Par exemple restreindre à une période particulière sur un article historique.

J'ai commencé ça sur Module:Population de France/Bac à sable, et ça ne devrait pas poser de problème. (j'essaye d'en profiter pour réécrire deux ou trois trucs, notamment essayer d'utiliser mw:Extension:Graph pour le graphique, j'essaierai de finaliser ça la semaine prochaine). -Zolo (discuter) 19 août 2020 à 15:34 (CEST)

@Zolo Cette mw:Extension:Graph a l'air en effet particulièrement intéressante. Quand je vois la carte d'évolution de la fertilité par pays dans le monde, cela correspond à ce que j'aimerais bien faire depuis longtemps pour certaines de nos divisions françaises, à savoir lier une carte à des tables de données avec une représentation colorisée par subdivision des différentes valeurs, mais … on commence à être loin de notre sujet!!Roland45 (discuter) 20 août 2020 à 15:39 (CEST)

Actualisation des données tabulaires

@Zolo Je préfère anticiper et poser les questions très en amont. De ce que je vois sur Commons et https://phabricator.wikimedia.org/, l'actualisation en masse de nos tables, ce n'est pas encore gagné.

En effet les premières tables de composition communale ne sont pas nombreuses (18) et peuvent donc être actualisées à la main sans problème. Mais quand on passe à 35 000, il faut assurément disposer d'un automate. Il existe bien par exemple déjà par exemple un code java pour exporter/importer un lot de données tabulaires à partir de fichier csv ou xlsx (bon, avec mon vieux Excel je vais me rhabiller, mais c'est un détail!) (ici). Mais d'une part cela n'est semble-t-il pas toujours opérationnel (ici), d'autre part notre démarche d'actualisation est plus complexe que de simplement charger un tableau, puisque il faudrait dès lors :

• récupérer toutes les tables de Commons dans Excel (et pas une comme dans le code java ci-dessus) ;
• traiter les tables dans Excel pour y ajouter les données issues du fichier annuel de l'Insee (avec la complexité pour définir la méthode de détermination);
• recharger les nouveaux fichiers en code json vers Commons.

Cela me parait excessivement compliqué et je commence dès lors à avoir de sérieux doutes de la faisabilité du transfert de système Wikipédia -> Commons. Car ce n'est pas le tout de créer les tables, mais il faudra pouvoir les actualiser, et si possible que cette tâche ne repose pas, du fait de sa complexité, sur un ou deux individus seulement. Qu'en penses-tu ?Roland45 (discuter) 19 août 2020 à 09:26 (CEST)

@Roland45 xlsx c'est juste le format Excel standard actuel. csv, c'est le format le plus basique pour les tableaux. Ca peut être ouvert, et créé, sans problème à partir d'Excel :).

Comment sont actualisés les modules de type Module:Données/L'Abergement-Clémenciat/évolution population ? A priori, les pages de l'espace data peuvent être modifiées de la même manière que les autres (à part que s'il y a une faute de syntaxe, on ne peut pas sauvegarder, mais c'est plus une sécurité qu'autre chose). Ce qu'il faudra faire c'est à peu près exactement ça.--Zolo (discuter) 19 août 2020 à 11:25 (CEST)

@Zolo C'est précisément ce que je craignais. Effectivement je peux faire un script en VBA travaillant de la même manière que pour les modules. Le seul problème est ... qu'on n'est pas 36 à utiliser le VBA dans les dresseurs de bots. Je crois bien être le seul, pour le moment! Je peux bien entendu mettre à dispo le script, mais en cas de bug, pour une raison ou une autre, il faut pouvoir corriger et relancer. J'avais cru un instant que ces données sous forme tabulaire faciliteraient cette question de l'actualisation, mais ce n'est a priori pas le cas.Roland45 (discuter) 19 août 2020 à 12:05 (CEST)

@Roland45 il n'y a pour l'instant je crois ni bot ni outil spécialisé sur les données tabulaires, donc c'est moins simple qu'avec Wikidata (à part le script d'import de données page par page). A vérifier, mais si on a un tableau avec des colonnes pour le code INSEE, la population, la méthode de dénombrement et la source, ajouter une nouvelle année en fin de tableau peut se faire assez simplement Pywikibot, le système le plus utilisé sur l'ensemble des projets Wikimedia.

Le problème le plus complexe est je pense, quel que soit le lieu de stockage, de définir la méthode de recensement, ou en tout cas de connaître les années, de recensement. Si je comprends bien, l'insee ne publie jamais ces informations sous le format le plus adapté (disons, un tableau avec la population de toutes les communes pour une année donnée, avec la date du dernier recensement) ? Il faudrait créer un fichier de l'espace data de Commons avec pour chaque commune la méthode de comptage de la population pour les deux dernières années. Il suffit de les reprendre du fichier que tu es en train de faire. Après il faut juste faire quelques manipulations Excel pour l'intégrer avec le reste. Zolo (discuter) 19 août 2020 à 13:08 (CEST)

Routine pour le qualificatif de la méthode de comptage

@Zolo Il n'existe en effet pas de fichier unifié. L'Insee publie chaque année deux fichiers :

• Données de population : le fichier des populations légales 2017 est téléchargeable ici ;
• Calendrier du recensement pour définir la méthode de détermination : ici, ouvrir "Millésime de collecte des communes (campagne 2021)"

Pour l'actualisation 2021, le bot doit croiser le fichier du calendrier 2021 avec la table de détermination suivante (chaque année il suffit de faire glisser d'une ligne les qualificatifs)

Année	Méthode	qualificatif WD
2021	recensement	"Q39825",
2022	interpolation	"Q187631",
2023	interpolation	"Q187631",
2024	extrapolation	"Q744069",
2025	extrapolation	"Q744069",
chaque année	recueil annuel	"Q98415788",

Dans Excel cela se fait très facilement. Avec les tables, on a une difficulté en moins puisqu'on ne doit pas revenir sur la donnée de l'année précédente (puisqu'on gérait l'affichage avec le fameux true/false). Par contre il faut désormais intégrer la convention d'affichage dans le module lua de traitement.

Si avec Piwikibot, on peut ajouter facilement une ligne aux tables à partir du fichier Excel, dans lequel auront été préparées les données à charger, il n'y a alors pas de problème. Roland45 (discuter) 19 août 2020 à 14:12 (CEST)

Ok, pour l'intégration du la convention de traitement au module de traitemnet, c'est juste enlever une ligne et en ajouter deux. -Zolo (discuter) 19 août 2020 à 15:20 (CEST)

La convention d'affichage (des données dans le tableau ou le graphique) peut se traduire comme suit :

• si méthode <> Q98415788, n'afficher la valeur de population que si méthode = Q39825 et la dernière population
• si méthode = Q98415788 et si Pop 2006 existe, afficher pop 2006 modulo 5 (2011, 2016, etc) et la dernière population (quelle que soit la méthode) ;
• si méthode = Q98415788 et si Pop 2006 n'existe pas (rarissime, mais concerne 3 ou 4 communes nouvelles de plus de 10 000 habitants), afficher première pop post- 2006 modulo 5 et la dernière population ;

En soi, ce n'est pas compliqué.Roland45 (discuter) 19 août 2020 à 15:49 (CEST)

Table finale

@Zolo Cela avance à grand pas. D’autant qu’avec mon Excel de dernière génération, cela va mieux !

Exemples de tables

• exemple de nouvelle table FR 01002 L'Abergement-de-Varey issue du fichier ci-dessous ;
• pour rappel, la FR_01001_L'Abergement-Clémenciat que tu avais donnée en exemple.

Questions sur la structure de la table sur Commons

• Nom de la table : J'ai envisagé un certain temps, pour éviter la problématique des changements de nom par l’Insee et de toutes les questions aux caractères spéciaux ou diacritiques, de ne pas mettre le libellé géographique. Mais je suis revenu au principe initial : code ISO pays & code Insee & libellé géographique de l'insee, ce qui donne :
  • commune : Data:Population FR 01002 L'Abergement-de-Varey.tab
  • canton : Data:Population FR 0101 Ambérieu-en-Bugey.tab
  • fraction cantonale : Data:Population FR 0209 Laon-1.tab
  • arrondissement : Data:Population FR 011 Belley.tab
  • département : Data:Population FR 01 Ain.tab
  • région : Data:Population FR 84 Auvergne-Rhône-Alpes.tab
  • EPCI : Data:Population FR 240100883 CC de la Plaine de l'Ain.tab
  • Unité urbaine 2010 : Data:Population FR 01302 Ambérieu-en-Bugey.tab
  • Aire urbaine 2010 : Data:Population FR 002 Lyon.tab

Cette structure est facilement internationalisable (pour rappel, la table de correspondance NUTS et structures administratives nationales en Europe)

• Ordre des colonnes : j’ai mis la population en premier comme demandé ;
• Format des années : faut-il mettre un + devant le millésime (comme dans cette table),
• Bandeau descripteur : j’ai ajouté type : commune, avec dans l’idée d’avoir aussi commune associée, commune déléguée, canton, etc. es-tu d'accord ?

Fichier associé

Le fichier relatif aux 9000 premières communes est ici.

Problématique des codes Insee dans Wikidata

Le code Insee est insuffisant pour décrire correctement les communes, ex Arbignieu et Arboys en Bugey ont le même code Insee (01015) mais l’une est commune associée, l’autre est commune principale. L'idée serait de renforcer le codage sur Wikidata par analogie à ce qui est fait dans la structure du COG. J’ai posé la question à Vigneron sur Wikidata ici.

Création des tables

J’ai vu qu’il faut être très rigoureux pour la création des tables (sinon la publication ne se fait pas !). Le chargement de lignes blanches ne génère a priori pas d’erreur, mais je pense qu’il est souhaitable de les éliminer lors du chargement du code.

Je peux me charger de cette opération. Je peux adapter des éléments de code que j’ai déjà pour créer un bot adapté.

Mais bien entendu il faudra être sûr de la structure avant de lancer le bot, pour ne pas être amenés à revenir ensuite sur toutes les tables créées!Utilisateur:Roland45 (discuter) 22 août 2020 à 16:19 (CEST)

@Roland45 tu peux reprendre la structure de l Abergement clemenciat sur commmons. Il y a donc les données de ton fichier excel plus un entête contenant des informations sur le contenu et identique sur chaque page. Nous avons il me semble inversé la colonne année et la colonne population il faut donc le faire aussi sur l'entête. Je pense que tous les blancs, sauts de ligne et tabulations sont ignorés. Tu peux toujours commencer par deux trois pages de test et je pourrai tester le module avec. Mais je risque d'avoir du mal a voir ça très en détail avant ce weekend. Zolo (discuter) 25 août 2020 à 20:15 (CEST)

@Roland45 et @Zolo Question. Pour le cas des communes déléguées/historiques, pour la création des tables, récupérez-vous le contenu des modules ou celui des modèles ?

Au sein d'une même commune nouvelle, les populations des communes déléguées ne sont pas toutes à la même date... Par exemple pour les communes de Chemillé-en-Anjou, les populations dans les modèles sont 2010 et 2013, or la population en vigueur au 15 décembre 2015 est 2012.

De plus, certains modèles sont complétés avec les populations 2015, 2016, 2017. Alors question, faut-il publier dans les tables des communes déléguées/historiques uniquement les années de population lorsque les communes étaient en vigueur, ou au contraire continuer à les actualiser après leur disparition (ce qui impliquerait de récupérer tous les fichiers départementaux depuis 2013) ?

J'anticipe certainement une question future, puisqu'il me semble que seuls les modules sont actuellement convertis.

Cordialement, Jessy ^Oui ? 28 août 2020 à 16:53 (CEST)

@JessydeVilly Pour l'instant je ne travaille pas sur les communes déléguées ou associées. L'idée est de repartir des modules. S'il y a des erreurs, cela sera plus simple de repartir à partir de 2006 directement des données de l'Insee. Je verrai.Roland45 (discuter) 28 août 2020 à 17:29 (CEST)

Par divisions

Bonjour Roland45 Ayant déjà un excel avec les populations légales des 2054 cantons, leur libellé et leur élément WD, je voudrais créer un excel en "json" à l'instar de ce que tu as fait pour les communes (Actuellement, mon excel étant en "lua").

Quelles sont les méthodes (de comptage) pour les divisions autres que les communes ? Cordialement, Jessy ^Oui ? 29 août 2020 à 17:09 (CEST)

PS : Pour Mayotte, doit-on utiliser wikidata:Q81204110 ? Ou faut-il créer un autre élément ? Jessy ^Oui ?

Le fichier des 2054 cantons est ici. Jessy ^Oui ?

@JessydeVilly les populations de toutes les divisions supracommunales (canton, arrondissement, département, etc) sont obtenues par sommation des populations légales de chaque commune (je n'ai plus la ref, mais elle existe). Donc quel élément WD retenir ? je n'ai pour l'instant pas la solution. En tout cas, ce n'est pas une de celles pour la commune (interpolation, extrapolation, recensement). Il faut réfléchir à la question. Sinon, les bots que j'ai préparés vont traiter toutes les divisions.Roland45 (discuter) 30 août 2020 à 12:29 (CEST)

Autres divisions

Bonsoir,

Petite question, allons-nous passer les autres divisions (cantons, arrondissements, départements, régions, intercommunalités, aires urbaines, unités urbaines...) en table ? Si oui, avec quelles colonnes ?

Si tel est le cas, je dispose déjà des populations des cantons depuis 2013, et prochainement des aires et unités urbaines de 2008 à 2017 (à noter que ces dernières ne sont pas encore prises en charge par le module Population de France).

Cordialement, Jessy ^Oui ? 22 août 2020 à 22:39 (CEST)

@JessydeVilly Il existe en 2020 39 686 modules de données (voir Catégorie:Module de données démographiques). Pour éviter tout bug, le basculement des modules vers les tables ne pourra donc avoir lieu que quand toutes ces pages auront été créées.

En réalité, ce n'est pas loin de 48 000 tables qu'il conviendrait de créer pour avoir un système complet. Le détail figure sur cette page. Dans la colonne "commentaires" sont listées quelques difficultés susceptibles d'être rencontrées.

Concernant ta proposition de données, il faut être très vigilant sur les sources. Je préfère me cantonner aux données communiquées officiellement par l'Insee. Ainsi concernant les unités urbaines et aires urbaines ne sont données (dans le système web actuel de l'Insee) que pour les années 2018, 2019 et 2020. Il ne faut pas envisager de reconstituer ces données ou de travailler à partir d'anciens fichiers, enfin c'est mon point de vue.Roland45 (discuter) 23 août 2020 à 10:14 (CEST)

Dénomination des tables

@Zolo Je reviens sur la question de la dénomination des tables qui est cruciale. Car autant créer ou modifier une table ne pose pas de pb avec un bot, autant renommer une série de tables avec un bot … je ne sais pas faire. Donc il ne faut pas se louper!

La structure du nom de la table doit répondre à trois objectifs :

• pouvoir être construite sans ambiguïté ;
• pouvoir être retrouvée sans ambiguïté par les futurs modules de traitement ;
• être stable dans le temps

1ère hypothèse :

Forme

code pays & code Insee & libellé géographique de l'insee

Analyse

Construction sans ambiguité : Cette notion nécessite de recourir à des listes officielles : le code Insee et le libellé géographique de l'insee figurent bien dans le COG.

Récupération sans ambiguité : Deux solutions :

• récupérer les deux éléments à partir des caractéristiques de l’élément Wikidata caractérisant la commune. Dans une première approche on peut croire que cela ne pose pas de problème : le code insee est défini dans les identifiants et le nom officiel est dans les déclarations (P1448). Sauf que le « nom officiel » figurant dans Wikidata n’est pas toujours le vrai nom officiel figurant dans le COG (même si la source du COG est donnée). L’exemple le plus flagrant est pour les cantons ou le nom dit officiel est en fait précédé de « canton de », ce qui n’est pas le cas dans le COG. exemple Q1436278 (« canton d'Ambérieu-en-Bugey ») (dans le COG, on a Ambérieu-en-Bugey et pas canton d'Ambérieu-en-Bugey - comme on a Ain et pas département de l'Ain (que l'on n'a par contre pas dans WD) ;
• récupérer le nom libellé géographique de l'insee officiel à partir de la table de composition (qu’il conviendrait au préalable de rajouter), mais cela complique singulièrement puisqu’il faut alors balayer non seulement l’élément WD, mais aussi les tables de découpage communal.

Stabilité: Le nom officiel peut évoluer avec le temps.

2ème hypothèse :

Forme

code pays & code type division & code identifiant la division

Analyse

Construction sans ambiguité :
Il n’y désormais plus de pb avec le libellé géographique de l'insee. Il n'y a plus que des codes.

• Le codage de la division serait le suivant :

COM	commune
COMA	commune associée
COMD	commune déléguée
COMP	commune périmée
ARM	arrondissement municipal
CAN	canton français
CANA	ancien canton français
EPCI	établissement public de coopération intercommunale à fiscalité propre
ARR	arrondissement français
DEP	département français
REG	région française
UU	unité urbaine
AU	aire urbaine
FRC	fraction cantonale

• Le code identifiant la division serait, selon les divisions : le code Insee, le code Siren (EPCI) ou un nom brut (communes périmées qui n'ont pas de code Insee).

Récupération sans ambiguité : Les deux parties variables du nom peuvent être trouvées à partir de WD :

• type de division à partir de la nature de l’élément (P31)
• code Insee dans les identifiants de l’élément.

Stabilité : Stable tant que les codes ne changent pas, mais il s’agit alors d’une autre table.

Tableau de correspondance détaillé

Nature de l'élément WD (P31)	Codage Table	Identifiant WD	élément WD exemple	Code officiel exemple	Libellé officiel exemple	Nom table exemple
Q484170 (« commune française »)	COM	P374 (« code Insee d'une commune »)	Q208567 (« L'Abergement-de-Varey »)	01002	L'Abergement-de-Varey	Data:Population FR COM 01002 .tab
Q666943 (« commune associée »)	COMA	P374 (« code Insee d'une commune »)	Q1113917 (« Hellemmes-Lille »)	59298	Hellemmes-Lille	Data:Population FR COMA 59298 .tab
Q21869758 (« commune déléguée »)	COMD	P374 (« code Insee d'une commune »)	Q13325 (« Rablay-sur-Layon »)	49256	Rablay-sur-Layon	Data:Population FR COMD 01002 .tab
commune périmée	COMP		Q16682681 (« Villerach »)	VILLERACH	Villerach	Data:Population FR COMP VILLERACH .tab
Q702842 (« arrondissement municipal »)	ARM	P374 (« code Insee d'une commune »)	Q161741 (« 1er arrondissement de Paris »)	75101	1er arrondissement de Paris	Data:Population FR ARM 75101 .tab
Q18524218 (« canton français »)	CAN	P2506 (« code Insee d'un canton »)	Q1436278 (« canton d'Ambérieu-en-Bugey »)	0101	Ambérieu-en-Bugey	Data:Population FR CAN 0101.tab
Q184188 (« ancien canton français »)	CANA	P2506 (« code Insee d'un canton »)	Q3746 (« canton de Bourg »)	3315	Bourg (Gironde)	Data:Population FR CANA 3315.tab
Q18706073 (« établissement public de coopération intercommunale à fiscalité propre »)	EPCI	P1616 (« numéro SIREN »)	Q2987948 (« communauté de communes de la Plaine de l'Ain »)	240100883	CC de la Plaine de l'Ain	Data:Population FR EPCI 240100883.tab
Q194203 (« arrondissement français »)	ARR	P3423 (« code Insee d'un arrondissement départemental »)	Q14812 (« arrondissement de Beaune »)	211	Beaune	Data:Population FR ARR 211.tab
Q6465 (« département français »)	DEP	P2586 (« code Insee d'un département »)	Q3083 (« Ain »)	01	Ain	Data:Population FR DEP 01.tab
Q36784 (« région de France »)	REG	P2585 (« code Insee d'une région »)	Q18338206 (« Auvergne-Rhône-Alpes »)	84	Auvergne-Rhône-Alpes	Data:Population FR REG 84.tab
Q1479822 (« unité urbaine »)	UU		Q28493608 (« unité urbaine d'Ambérieu-en-Bugey »)	01302	Ambérieu-en-Bugey	Data:Population FR UU 01302.tab
Q2342385 (« aire urbaine »)	AU		Q2828529 (« aire urbaine de Lyon »)	002	Lyon	Data:Population FR AU 002.tab
Q22670000 (« fraction cantonale »)	FRC				Fraction de la commune de Chémery-Chéhéry appartenant au canton de Vouziers	Data:Population FR FRC 08115 0819.tab

Autre avantage : facilement internationalisable

si on se met dans une perspective d'internationaliser ces tables, la structure présente l'avantage de s'affranchir de toutes les graphies avec des caractères spéciaux (cyrilliques ou autres), puisqu'il n'y a que des codes.

• code Pays : on retient le code ISO du pays
• Code type division : il faudrait faire une table recensant toutes les divisions par pays (ex JUD pour Județ, qui est une division administrative roumaine - noter le caractère final de judet qui est un t cédille, caractère roumain - Ţ)
• code division : c'est le code NSI

Il est clair que ... c'est ce que je préconise!

Je pourrai créer un jeu de tables tests avec un exemple par type de division. La création des tables ne serait dès lors faite ... que lorsque le module de traitement fonctionnerait !Roland45 (discuter) 24 août 2020 à 14:32 (CEST)

Bonjour  Roland45 et Zolo :,

Je pense également que la seconde hypothèse est à privilégier. Il n'y aurait dès lors plus besoin de corriger le nom d'une table lorsque l'on renomme l'article principal... Reste à savoir comment on récupère les données dans les articles (et par là, j'entends comment on les appelle avec le modèle, et non comment elles sont traitées par le module).

Je reste réservé quant au basculement des fractions cantonales en tables. Le module actuel est plutôt "simple" à actualiser, et je ne pense pas qu'il soit utile de conserver un historique de population de fraction, surtout lorsqu'elles sont provisoires (càd le temps qu'une commune nouvelle rattachée à plusieurs cantons ne soit rattachée qu'à un seul).

((De plus, il ne faut pas oublier que les tableaux de compositions affichent la composition au premier janvier de l'année n (géographie n), hors les fractions sont en géographie de l'année n-1, il faut donc retirer les fractions supprimées en n-1 pour avoir un affichage correct en n)).

Cordialement, Jessy ^Oui ? 24 août 2020 à 21:22 (CEST)

@JessydeVilly Oui. J'ai ajouté les fractions cantonales pour éviter que le futur module de traitement ait à gérer à la fois des tables et des modèles (comme c'est le cas actuellement avec des modules et des modèles), mais c'est effectivement de peu d'utilité de créer de telles tables.

Sur la syntaxe du module dans les articles, je ferai une section spéciale. En gros, selon mon point de vue, il y a deux cas :

• L'article est celui d'une division : le module doit alors récupérer les parties composant la table dans l'élément Wikidata de la division ;
• L'article n'est pas celui d'une division : je pense que la syntaxe d'appel doit comprendre les éléments constituant la table du style :
  • pour une commune : {{population de France/dernière_pop|COM|01008}} (actuellement on a : {{Population de France/dernière_pop||Ambutrix}}) ;
  • pour un canton : {{population de France/dernière_pop|CAN|4521}} (actuellement on a : {{Population de France/dernière_pop||Canton de Sully-sur-Loire}}).

Mais @Zolo précisera ce qu'il en pense.Roland45 (discuter) 25 août 2020 à 08:31 (CEST)

@Roland45 et @Zolo Je pense que le plus simple sera de conserver le module des fractions cantonales, qui permettrait de conserver une partie du code actuel. À voir.

L'idée de syntaxe est satisfaisante. Il faudra néanmoins faire passer un bot pour corriger les syntaxes actuellement utilisées.

@Zolo Pourras-tu ajouter des catégorisations au module en cas d'erreur ? Actuellement (sauf erreur de ma part, il n'en existe pas).

Cordialement, Jessy ^Oui ? 25 août 2020 à 12:53 (CEST)

@Roland45 et @JessydeVilly désolé je n'avais pas tout lu de cette section (plus pris que prévu cette semaine...).

Si on veut pouvoir étendre par la suite le champ d'utilisation de ce système, il ne faut pas que le module se base sur un format prédéterminé pour récupérer les données. On risque toujours de se retrouver avec des imprévus (changements de nomenclatures, zones sans codes officiels, autres communautés linguistique tenant à utiliser un autre format ...).

Je prévoyais de récupérer le fichier par l'intermédiaire de la propriété "population tabulaire" de Wikidata. Il faut que Wikidata soit bien remplie, mais ça fait un seul endroit qui a besoin d'être tenu à jour. Et en cas de renommage de la page de données, la mise à jour doit se faire automatiquement par bot, comme c'est déjà le cas pour les images.

Il faut cependant je crois partir du principe qu'on ne renommera pas du tout les tables une fois créées. Les données étant partagés par plein de Wikis, il y a toujours un risque d'abîmer quelque chose sans s'en rendre compte. Cette absence de renommage soulève deux problèmes pour la "deuxième hypothèse" :

• elle rend problématique l'usage de la notion de "commune périmée".
• plus gênant, on risque, si j'ai bien suivi, de se retrouver avec exactement les mêmes codes pour deux entités distinctes.

Peut-être voyez vous des moyen de contourner ces problèmes ?

@JessydeVilly il faudrait effectivement renforcer la gestion des erreurs par le module.-Zolo (discuter) 27 août 2020 à 01:06 (CEST)

@Zolo @Roland45 Bonjour,

Actuellement, pour le Module:Composition Division de France, si la page Wikipédia Fr ne contient pas de lien vers son élément Wikidata, le tableau de composition ne s'affiche pas et affiche une erreur Lua (et la page n'est pas catégorisée..).

Chaque division dispose d'un élément Wikidata, ce qui signifie que chaque commune a un élément Wikidata qui lui est propre (exemple, les communes de Picauville, ont chacune leur élément Wikidata (commune 2, commune 3, commune 4). À l'heure actuelle, cela pose un problème uniquement dans le cas où une commune nouvelle garde le même nom qu'une commune déléguée au sein d'un même article, il faut dès lors lier l'article à l'élément Wikidata de la commune nouvelle pour afficher le tableau du module de composition.

Demain, lors de la création d'une commune nouvelle, il faudrait effectivement renommer une table. Chaque commune nouvelle récupérant le code INSEE de la commune siège, il faudra donc renommer la commune siège avec un D après son code Insee... Ce qui donnerait pour Arbignieu : Data:Population FR COM 01002.tab -> Data:Population FR COMD 01002.tab. Dans ce cas-là, il faudrait corriger l'élément Wikidata d'Arbignieu, et tous les articles appelant Data:Population FR COM 01002.tab sur tous les Wikis...

Le seul moyen selon moi de contourner le renommage des tables est d'utiliser le code SIREN des communes qui est propre à chaque commune. De même, les communes périmées ont eu un code SIREN qui n'a (normalement) pas été réattribué (par exemple, le SIREN de la commune périmée Cherbourg-Octeville (215 006 495) est différent du SIREN de Cherbourg-en-Cotentin (200 056 844)).

Cela implique que nous devons ajouter les codes SIREN aux tables géographiques actuelles ET aux éléments Wikidata...

Cordialement, Jessy ^Oui ? 27 août 2020 à 11:34 (CEST)

@Zolo et @JessydeVillyLe code Siren est effectivement unique, mais n'est pas très intuitif.

Et si tout simplement on utilisait le code de l'élément Wikidata, pas très intuitif non plus, mais facilement récupérable pour le coup. Exemples :

• Arboys en Bugey, au lieu de Data:Population FR COM 01002.tab, on aurait Data:Population FR Q21619395.tab
• Arbignieu (commune déléguée), au lieu de Data:Population FR COMD 01002.tab, on aurait Data:Population FR Q204156.tab

Pour le volet international, pas de pb, puisque le code WD est unique interwiki et le descriptif serait quant à lui donné en plusieurs langues.

Lors de la transformation d'une commune en commune déléguée, associée ou périmée, seul l'appel à cette commune serait à modifier et encore uniquement dans les pages qui ont un module d'appel qui n'est pas positionné dans l'article de la commune en question.

Cela me parait jouable : la structure serait alors réduite à son strict minimum code iso pays & code Wikidata.

Qu'en pensez-vous ? Cordialement.Roland45 (discuter) 27 août 2020 à 14:33 (CEST)

 Roland45 et Zolo :, effectivement, nous avons cherché la complication. Le fait d'appeler une table dans lequel on ne rajoute que le code iso et le code wikidata simplifiera la tâche à @Zolo, et nous évitera des modifications en cascade. (De plus, aucun problème pour les actualisations annuelles en cas de création de commune nouvelle puisque l'on récupère les identifiants WD des communes en vigueur et celles dont la création est postérieure au premier janvier de l'année n pour la construction des tables géographiques).

Je suis pour. Il faudra donc créer l'ensemble des éléments Wikidata qui n'existent pas à l'heure actuelle pour pouvoir créer les tables (je pense notamment aux unités et aux aires urbaines).

Cordialement, Jessy ^Oui ? 27 août 2020 à 14:47 (CEST)

Oui c'est vrai utiliser les identifiants Wikidata est en fait le plus simple. Et ils commencent à être pas mal référencés par des sites externes. -Zolo (discuter) 27 août 2020 à 18:57 (CEST)

Création des tables tests

@Zolo Au vu de ton dernier message, je vois que tu optes pour la structure de nom initiale, à savoir : code pays & code Insee & libellé Wikidata (j'avais mis initialement libellé géographique de l'Insee, mais ce n'est pas envisageable comme dit ci-après)

As-tu lu les observations ci-dessus sur les deux hypothèses de structures ?

Admettons que l’on opte pour cette solution pour créer ces tables (qui est la plus simple du point de vue du module de traitement, je l'admets). Pour créer ces tables, je ne peux pas partir du COG pour avoir le libellé géographique car certains des libellés Wikidata sont différents du nom officiel. Je dois donc partir d’une liste des libellés Wikidata. C’est dans cette perspective que j’ai fait cette page de requêtes.

• 1er problème : la requête actuelle dresse la liste des divisions aujourd’hui. Or les populations de l’année n (millésimées n-3) sont établies sur la géométrie territoriale au 1er janvier de l’année n-1, ici 2019 en l’occurrence. Bon, je peux m’en arranger, mais il faudra avoir une requête qui fonctionne pour une date donnée (1er janvier 2019 si on faisait l'actualisation aujourd'hui).

• 2ème problème : le téléchargement de la liste en csv issue de la requête me remplace tous les caractères accentués par des signes cabalistiques. Peut-être est-ce un paramètre que je n’ai pas activé dans Excel. Mais pour l’instant je ne peux pas récupérer le texte enrichi et donc pas faire de création en masse.
  • Solution : en fait il fallait utiliser le protocole 65001- Unicode (UFT-8) pour le chargement des données.
• 3ème problème : l’actualisation avec uniquement le code Insee (cf 2ème hypothèse ci-dessus) est immédiate car il suffit de transformer le fichier de population en json et le tour est joué. Tandis qu’avec le libellé WD on est obligés faire cette requête WD, la transformer en Excel puis de procéder à un balayage des codes Insee entre la liste de requête et le fichier de population (on ne sait jamais, il peut y avoir des erreurs), puis procéder à une transformation en json. Il faut déjà maîtriser toutes les phases. Je rappelle qu’un des enjeux est bien que plusieurs personnes non expertes puissent procéder facilement à cette actualisation.

• 4ème problème : Actuellement pour charger correctement les modules avec mon bot, je dispose d'une liste avec les noms wikifiés mais en code ascii pour les caractères accentués (é est traduit en %C3%A9). Avec une structure utilisant les code Insee on s'affranchit de cela. J'imagine qu'avec Pywikibot on s'en affranchit aussi, mais bon, je ne maitrise pas.

Je vais quand même faire quelques tables tests selon cette structure. Mais tant que les pb ci-dessus ne seront pas réglés, la création en masse ne pourra être lancée. Cordialement.Roland45 (discuter) 26 août 2020 à 12:00 (CEST)

@Roland45 crois que tu parles ici simplement du nom des fichiers ? Avoir le nom des communes me parait plus clair, mais si c'est trop compliqué d'un point de vue technique, je ne pense pas que ce soit indispensable. Je parlais en fait du contenu du fichier. C'était simplement histoire de rappeler que la première partie du contenu ne se trouve pas sur le fichier Excel, et qu'il faut penser à l'ajouter au moment du chargement des données. -Zolo (discuter) 26 août 2020 à 13:58 (CEST)

@Zolo Oui effectivement, je parle bien de la structure du nom de la table, pas du fichier proprement dit.Roland45 (discuter) 26 août 2020 à 14:17 (CEST)

Libellés des colonnes

@Roland45 on peut sans doute aussi ajouter un traductions des libellés dans les langues les plus communes avant un chargement en masse. Ce n'est pas forcément utile pour la réutilisation des données sur Wikipédia, mais ce sera plus lisible sur Commons. Et aussi changer "Année" en "Date" d'autant qu'on va mettre le jour je crois. -Zolo (discuter) 26 août 2020 à 14:29 (CEST)

Oui. D'accord. De toute façon cela va être un premier jeu.Roland45 (discuter) 26 août 2020 à 14:31 (CEST)

Question de la méthode de recensement avant 1962

@Zolo et @JessydeVilly Je viens seulement de découvrir cette page qui donne les séries historiques de population de 1876 à 2017. Bon à quelques années près j'aurais pu m'éviter la récupération complète des tables, mais il manque bel et bien les données antérieures à 1876. Et en tout état de cause, ces statistiques sont proposées dans la géographie communale en vigueur au 01/01/2019 pour la France hors Mayotte, afin que leurs comparaisons dans le temps se fassent sur un champ géographique stable, alors que nos données (à savoir celles de l'EHESS pour la période antérieure à 2006 ou de l'Insee après) sont dans la géométrie de l'année en vigueur). Ces données n'auraient donc pas pu être utilisées.

Il y a par contre une info intéressante dans la page des variables. On a :

• de 2006 à 2017 : populations municipales
• de 1962 à 1999 : populations sans doubles comptes
• de 1876 à 1954 : populations totales

Et on a un détail de ces paramètres ici.

On aurait en fait pu s'en douter, mais cela va mieux avec une source. Or dans nos fichiers, on a mis pour l'instant le paramètre somevalue pour la période 1793 à 1954. L'un de vous deux pourrait-il me communiquer le code Wikidata pour le qualificatif « population totale » pour que je modifie cela ? Merci.

En outre je pense que dans le descriptif, il faudrait peut-être donner l'info sur la géométrie de l'année du recensement (peut-être qu'en vietnamien cela va être difficile à traduire! disons qu'on réserverait l'info à la France) Roland45 (discuter) 27 août 2020 à 15:57 (CEST)

@Roland45 wikidata:Q15986341 celui-ci ? Jessy ^Oui ? 27 août 2020 à 16:07 (CEST)

Oui exactement. Merci. J'avoue ne pas avoir tapé le libellé dans le cadre de recherche!Roland45 (discuter) 27 août 2020 à 16:08 (CEST)

Je ne pense pas que cet élément convienne : il fait référence à la population totale telle que définie par un décret de 2003. Je ne sais pas s’il y a en pratique de grosses différences, mais je pense quand même qu’il vaut mieux créer un nouvel élément si on veut faire référence à une notion utilisée avant 1962. --Zolo (discuter) 27 août 2020 à 17:23 (CEST)

D'accord. Avec comme source la page ici.Roland45 (discuter) 27 août 2020 à 18:59 (CEST)

J'ai créé Q98688246 (« population totale ») (qui peut sûrement être amélioré). -Zolo (discuter) 27 août 2020 à 19:20 (CEST)

Champ source

Les tables Commons prennent aussi un champ "source". Je l'ai laissé vide sur Data:Population FR 01001 L'Abergement-Clémenciat.tab, vu qu'on a aussi mis une colonne source pour chaque valeur. Mais c'est peut-être bien d'y mettre un petit résumé. Peut-être "base Cassini de l'EHESS et base Insee" qui est le texte acutellement affiché sous les graphiques ? --Zolo (discuter) 28 août 2020 à 16:03 (CEST)

@Zolo Oui. Je vais voir cela et l'ajouter. Pour l'instant je travaille sur le volet interlangues et c'est pas une mince affaire! D'ailleurs je piétine un peu. Il ne faut pas grand chose pour que ça buggue. (au fait il faudra trouver un breton dans la salle car ... Google traduction ne donne pas le breton! Mais pas que!). Mais je pense pouvoir fournir un premier jeu de tests demain.Roland45 (discuter) 28 août 2020 à 17:32 (CEST)

@Roland45 tu peux récupérer les libellés Wikidata des propriétés Wikidata correspondant aux différents champs. Je pense que ça convient généralement comme libellés. Je viens de créer dans Module:Test une fonction pour les lister. J'ai testé avec {{#invoke:Test|listLabels|P585}} (la date) sur Discussion module:Test. Il y a le breton. -Zolo (discuter) 28 août 2020 à 21:17 (CEST)

@Zolo Merci. C'est parfait. De mon côté, j'avais développé un bot similaire en VBA, mais qui récupère à partir de l'élément Wikidata relatif au nom du champ, ainsi « date » à partir de Q205892 (« date calendaire »). Tu remarqueras d'ailleurs que certaines langues sont dans l'un et pas dans l'autre ainsi als (albanais) n'est pas récupéré avec ta requête! Je vais faire un mix des deux avec le tien en n°1 et le mien pour les manquants. Mais bizarrement, il en manque encore pas mal... mais bon, c'est déjà pas mal.

Par contre quand je relance le module, avec par exemple P459 (« méthode de détermination ») ou P1013 (« critère utilisé »), cela me renvoie toujours la date. Peut-être un pb de rafraichissement. As-tu une idée ?

C'est pour le texte « évolution historique des populations de la commune de XXX que j'ai recours à Google traduction.

Roland45 (discuter) 29 août 2020 à 09:36 (CEST)

Au fait, pour info, la division qui a le plus d'interwikis est « France » avec 260 langues. Il en manque donc encore 148!Roland45 (discuter) 29 août 2020 à 10:00 (CEST)

@Roland45 parfait merci. C'est corrigé, j'avais mis quelque chose de pas très intuitif dans le module. -Zolo (discuter) 29 août 2020 à 10:53 (CEST)

@Zolo et pour "S248_sourcename" et "S854_sourceurl", tu as une méthode pour récupérer l'interwiki ?Roland45 (discuter) 29 août 2020 à 12:09 (CEST)

@Roland45 il faut juste mettre un P à la place du S (ce sont des propriété normales, j'ai mis un S à la place du P dans le tableau pour indiquer que ce type de donnée, s'il devait être transféré sur Wikidata se trouverait dans la partie source dans la déclaration). -Zolo (discuter) 29 août 2020 à 12:11 (CEST)

Bug

@Zolo Ces histoires de langues, c'est sévère. Mon bot me produit un code qui ressemble à ce qu'il faudrait obtenir, mais je n'arrive pas à charger sur Commons la table. Le message d'erreur est le suivant :

Le paramètre « description » doit être un objet qui fait correspondre des codes de langue valides à des chaînes sur une ligne sans tabulation ni espaces à la fin, par exemple { "en":"String in English", ... }
Le paramètre « schema/fields[0]/title » doit être un objet qui fait correspondre des codes de langue valides à des chaînes sur une ligne sans tabulation ni espaces à la fin, par exemple { "en":"String in English", ... }

Or je ne vois pas de tabulation ni d'espace à la fin dans mon code. J'ai mis le code sur cette page. Peux-tu voir où est le problème ?

Il y aussi encore d'autres aspects à traiter (comme celui des langues où on n'a pas de traduction), mais là il s'agit d'un pb pur de syntaxe semble-t-il.Roland45 (discuter) 29 août 2020 à 15:51 (CEST)

@Roland45 en tâtonnant un peu, le problème est apparemment qu'il ne faut pas non plus d'espace en début de chaîne, et que le code "fiu-vro" ne fonctionne pas. Je pense qu'il vaut mieux aussi enlever les chaînes vides "", au cas où ça empêche le "fallback" vers une langue plus répandue. Je vois par ailleurs, que certaines langues assez courantes manquent (russe, chinois, japonais ne sont pas très répandues), je ne sais pourquoi.

@Zolo J'ai bataillé ferme. Même en appliquant tes conseils, cela plantait. J'ai cru un moment que c'était dû aux langues qui se lisent de droite à gauche (arabe, farsi, urdu, etc) (car dans Excel cela donnait l'impression de rajouter des tabulations). Mais non. Finalement c'est une des deux langues "zh_min_nan" ou "zh_yue" qui faisait le bazar! Je me demande si je n'ai pas inversé dans ma base le cantonais et le chinois min nan. Il y a encore à travailler certains aspects (majuscule en début de phrase, préposition avant le nom de la commune. Mais ce n'est pas énorme. Bon, un grand pas vient d'être franchi, mais les tables tests ne seront pas encore pour aujourd'hui (je ne fais pas de WP le soir!). Pour demain, j'espère.~~

Premières tables

Communes

@Zolo Voici les 10 premières tables. C'est vraiment impitoyable ce codage, et en particulier des langues. Quand ça bugue pour trouver d'où ça vient, c'est sévère. J'ai été obligé de faire sauter le chinois wu, mais en écrivant cela, je vois où était l'erreur, il fallait écrire wuu au lieu de wu. Je verrai si je peux rattraper le coup.

• Commons:Data:Population FR Q204388.tab - L'Abergement-Clémenciat
• Commons:Data:Population FR Q208567.tab - L'Abergement-de-Varey
• Commons:Data:Population FR Q192166.tab - Ambérieu-en-Bugey
• Commons:Data:Population FR Q204177.tab - Ambérieux-en-Dombes
• Commons:Data:Population FR Q193812.tab - Ambléon
• Commons:Data:Population FR Q193533.tab - Ambronay
• Commons:Data:Population FR Q10290.tab - Ambutrix
• Commons:Data:Population FR Q204167.tab - Andert-et-Condon
• Commons:Data:Population FR Q193996.tab - Anglefort
• Commons:Data:Population FR Q202829.tab - Apremont

Sur les langues, le principe retenu est le suivant : on ne met la langue que si l'article existe dans la wiki dans cette langue.

Il y a quand même un pb de fond encore : pour certaines langues, les titres de colonnes ne sont pas tous traduits. Il faudra remédier à cela. De toute façon il s'agit de tables temporaires encore améliorables.Roland45 (discuter) 30 août 2020 à 12:06 (CEST)

Cantons

• Commons:Data:Population FR Q1436278.tab - canton d'Ambérieu-en-Bugey
• Commons:Data:Population FR Q17174392.tab - canton d'Attignat
• Commons:Data:Population FR Q1724440.tab - canton de Valserhône
• Commons:Data:Population FR Q1724443.tab - canton de Belley
• Commons:Data:Population FR Q17175568.tab - canton de Bourg-en-Bresse-1
• Commons:Data:Population FR Q17175570.tab - canton de Bourg-en-Bresse-2
• Commons:Data:Population FR Q513535.tab - canton de Ceyzériat
• Commons:Data:Population FR Q1541895.tab - canton de Châtillon-sur-Chalaronne
• Commons:Data:Population FR Q969984.tab - canton de Gex
• Commons:Data:Population FR Q141544.tab - canton d'Hauteville-Lompnes
• Commons:Data:Population FR Q1725705.tab - canton de Lagnieu

Arrondissements

• Commons:Data:Population FR Q700647.tab - arrondissement de Belley
• Commons:Data:Population FR Q700721.tab - arrondissement de Bourg-en-Bresse
• Commons:Data:Population FR Q701238.tab - arrondissement de Gex
• Commons:Data:Population FR Q682085.tab - arrondissement de Nantua
• Commons:Data:Population FR Q700965.tab - arrondissement de Château-Thierry
• Commons:Data:Population FR Q701410.tab - arrondissement de Laon
• Commons:Data:Population FR Q702444.tab - arrondissement de Saint-Quentin
• Commons:Data:Population FR Q702552.tab - arrondissement de Soissons
• Commons:Data:Population FR Q702745.tab - arrondissement de Vervins
• Commons:Data:Population FR Q701790.tab - arrondissement de Montluçon
• Commons:Data:Population FR Q701834.tab - arrondissement de Moulins

Questions à régler :

• sources Insee antérieures à 2006 obsolètes. Pas trouvé l'équivalent
• Interwiki : compléter les vides en en-têtes de colonnes
• interwiki : envisager de traduire le paramètre "sources"

 Roland45 : l'équivalent pour les sources antérieures à 2006 est ici. Problème : "Les données proposées sont établies à périmètre géographique identique, dans la géographie en vigueur au 01/01/2020."

Penses-tu que les données démographique des almanach (voir Arrondissement de Bar-sur-Aube) peuvent être ajoutées aux tables ?

Cordialement, Jessy ^Oui ? 4 septembre 2020 à 15:19 (CEST)

@JessydeVilly Oui. Je vais tenter de récupérer ces données. IL faudra que l'on trouve le moyen de mettre quelque part cette phrase sur la géométrie en vigueur (dans la table, mais aussi dans le module).Roland45 (discuter) 5 septembre 2020 à 14:30 (CEST)

Finalement cela pose un pb. ce réajustement des valeurs sur la géométrie en vigueur au 1er janvier 2020 fait augmenter la population et introduit un décalage net en 2006. Deux solutions :

• soit on réajuste tout et alors il nous manque toutes les années intermédiaires entre 2007 et 2012 et entre 2012 et 2017 et du coup l'année suivante on ne peut pas calculer la variation sur l'année n-5. c'est donc non recevable ;
• soit on ne réajuste rien et on conserve les données actuelles avec les liens brisés (qui ne gênaient personne jusqu'à présent).

Je vais donc laisser en l'état les données.Roland45 (discuter) 5 septembre 2020 à 16:21 (CEST)

@Roland45 Conflit de modification. J'étais en train de te répondre que cela allait effectivement poser problème...

Cordialement, 5 septembre 2020 à 16:24 (CEST)

Départements

• Commons:Data:Population FR Q3083.tab - Ain
• Commons:Data:Population FR Q3093.tab - Aisne
• Commons:Data:Population FR Q3113.tab - Allier
• Commons:Data:Population FR Q3131.tab - Alpes-de-Haute-Provence
• Commons:Data:Population FR Q3125.tab - Hautes-Alpes
• Commons:Data:Population FR Q3139.tab - Alpes-Maritimes
• Commons:Data:Population FR Q3148.tab - Ardèche
• Commons:Data:Population FR Q3164.tab - Ardennes
• Commons:Data:Population FR Q3184.tab - Ariège
• Commons:Data:Population FR Q3194.tab - Aube
• Commons:Data:Population FR Q3207.tab - Aude

Régions

• Commons:Data:Population FR Q17012.tab - Guadeloupe
• Commons:Data:Population FR Q17054.tab - Martinique
• Commons:Data:Population FR Q3769.tab - Guyane
• Commons:Data:Population FR Q17070.tab - La Réunion
• Commons:Data:Population FR Q13917.tab - Île-de-France
• Commons:Data:Population FR Q13947.tab - Centre-Val de Loire
• Commons:Data:Population FR Q18578267.tab - Bourgogne-Franche-Comté
• Commons:Data:Population FR Q18677875.tab - Normandie
• Commons:Data:Population FR Q18677767.tab - Hauts-de-France
• Commons:Data:Population FR Q18677983.tab - Grand Est

France

• Commons:Data:Population FR Q142.tab - France métropolitaine

Noter qu'il s'agit d'une série annuelle 1902-2014 et donc particulièrement longue. Probablement qu'il serait souhaitable de la réduire à une série quinquennale, ou la ramener aux années de recensements réels, bien qu'en tout état de cause, il s'agira toujours d'une estimation. A réfléchir. Si on veut une cohérence avec les autres pays (puisque l'INED produit des séries pour de nombreux pays), une série quinquennale en 5 ou en 0 serait a priori à retenir.Roland45 (discuter) 6 septembre 2020 à 09:01 (CEST)

Commentaires

@Roland45 super, la structure m'a l'air bonne. En revanche, il semble que ce soit dans tous les fichiers la population de l'Abergment-Clémenciat.

Pour les traductions, quand c'est très compliqué je pense qu'on peut laisser tomber. Les tables n'ont après tous pas vraiment vocation à être utilisées à l'état brut. Pour le wu, je pense que l'intérêt est je pense assez limité, dans la mesure où toute personne capable de le lire comprendra aussi un texte en mandarin (à supposer qu'il y ait une différence pour ce genre de textes). -Zolo (discuter) 30 août 2020 à 13:16 (CEST)

Pour c:Data:Population FR 01001 L'Abergement-Clémenciat.tab, tu as laissé la méthode à "somevalue" plutôt que "population totale" mais comme c'est bon pour les autres, je pense qu'il n'y a pas de problème sur ce point. -Zolo (discuter) 30 août 2020 à 13:20 (CEST)

@Zolo J'ai corrigé, c'était un pb de paramètre que j'avais oublié de rendre variable. Je gère également désormais la suppression des lignes des années blanches (sans recensement).

Concernant L'Abergement-Clémenciat c:Data:Population FR 01001 L'Abergement-Clémenciat.tab a été remplacé par c:Data:Population FR Q204388.tab.Roland45 (discuter) 30 août 2020 à 14:47 (CEST)

@Zolo Au vu du fonctionnement du futur module qui n'a pas besoin du nom de la table, je me demande finalement si ça ne vaut pas le coup de réintroduire le nom de la division et le type dans le nom de la table, pour que ce soit plus clair. On reviendrait donc à la structure :code ISO pays & code Insee & libellé géographique de l'insee, ce qui donnerait :

• commune : Data:Population FR 01002 L'Abergement-de-Varey.tab
• canton : Data:Population FR 0101 Ambérieu-en-Bugey.tab
• fraction cantonale : Data:Population FR 0209 Laon-1.tab
• arrondissement : Data:Population FR 011 Belley.tab
• département : Data:Population FR 01 Ain.tab
• région : Data:Population FR 84 Auvergne-Rhône-Alpes.tab
• EPCI : Data:Population FR 240100883 CC de la Plaine de l'Ain.tab
• Unité urbaine 2010 : Data:Population FR 01302 Ambérieu-en-Bugey.tab
• Aire urbaine 2010 : Data:Population FR 002 Lyon.tab

Roland45 (discuter) 30 août 2020 à 16:46 (CEST)

Finalement je m'en tiens au code WD dans le titre. Ce sera plus facile à actualiser.Roland45 (discuter) 1 septembre 2020 à 15:54 (CEST)

Nouveau module

J'ai créé Module:Population de France/Bac à sable qui n'est pas encore tout à fait près, mais je mets déjà quelques remarques en rapport à ce sujet :

Organisation du module

J'ai rapatrié certains sous modules vers le module principal (notes, outils, données, constantes). A l'usage il semble que ce soit plus facile de lecture et de maintenance. Je n'exclus pas de les re-scinder mais il faudrait que les rôles de chaque module soient mieux définis.--Zolo (discuter) 30 août 2020 à 15:20 (CEST)

@Zolo Tu peux nous donner la syntaxe d'appel du module. J'ai essayé avec {{#invoke:Population de France/Bac à sable|tableau}} Mais a priori, ce n'est pas ça.Roland45 (discuter) 30 août 2020 à 15:57 (CEST)

Si c'est bien ça, mais il faut que le nom du module soit indiqué sur Wikidata, donc pour l'instant, ça ne marche que pour l'Abergement-Clémenciat. -Zolo (discuter) 30 août 2020 à 16:15 (CEST)

@Zolo Tu as vu que cela ramène le texte des sources dans la table, qui sont dès lors doublonnées. Et que les années des sources Insee ne sont plus en lien ? (L'Abergement-Clémenciat)Roland45 (discuter) 30 août 2020 à 16:36 (CEST)

@Roland45 effectivement, je n'ai pas encore mis à jour la gestion des sources qui n'est donc plus adaptée. Doit-on prévoir la possibilité de sources autres que Cassini et l'INSEE ? Le module actuel prévoit cette possibilité, mais ça ne marche pas vraiment et je ne suis pas totalement sûr de ce qu'on devrait avoir. Par exemple Monts-de-Randon mentionne une source départementale, en référence, mais le lien s'affiche avec le titre de la base Cassini ("Des villages de Cassini aux communes d'aujourd'hui"). -Zolo (discuter) 30 août 2020 à 17:04 (CEST)

@Roland45 on fait quoi donc pour les sources ni INSEE ni Cassini ? Visiblement, il y en a d'indiquées, mais je ne sais pas si elles sont vraiment utilisées pour les données. Tu en aurais la liste ? https://wstat.fr/template/ ne fonctionne pas pour les pages de module.-Zolo (discuter) 1 septembre 2020 à 17:17 (CEST)

@Zolo Les tables que je prépare n'auront que 3 types de sources (Insee, EHESS et SPLAF pour ls départements). Il est vrai qu'avant les modules, des données antérieures à 1793 avaient été insérées, voire des données complémentaires ultérieurement avec des données autres. Mais il a depuis été préconisé de sortir ce genre d'info du tableau et donc du corps du texte aussi (voir Archail). Par contre pour le volet international, je pense qu'il faut aller au plus simple et mettre en pied de tableau ou graphique uniquement le texte mis dans le champ source.Roland45 (discuter) 1 septembre 2020 à 17:49 (CEST)

Volet international

J'ai regardé un peu comment sont organisés les modules. Pour Location map, on a : afModule:Location map - arوحدة:Location map - arzوحدة:Location map - astMódulu:Mapa de llocalización - asModule:Location map avМодуль:Location map - azbماژول:Location map - azModule:Location map - banModul:Location map - barModul:Location map - bnমডিউল:অবস্থান মানচিত্র

On voit que le mot module est toujours traduit, mais qu'on peut avoir également le nom du module traduit. On a la même chose avec frModèle:Historical populations qui traite du même sujet des données démographiques, mais avec les données en dur dans l'article.

Tout ça pour dire qu'autant on comprend que cela ne pose pas de problème quand le module fonctionne en autonome, mais est-ce que cela ne va pas en poser un dans notre cas où on a des sous-modules. Comment vas-tu appeler ces sous-modules ? Même si tu récupères la racine du nom du sous-module, il faut-bien que tu aies quelque part une liste des traductions de ces sous-modules, à moins que tu appelles là aussi le sous-module via son identifiant WD ?Roland45 (discuter) 1 septembre 2020 à 18:00 (CEST)

Le problème est en fait un peu plus large que cela. De manière générale, les modules font souvent appel à d'autres modules, et tant qu'on ne centralise pas cela comme les images ou les données, ça peut être délicat.

On voit en début de Module:Population de France/Bac à sable qu'il fait appel à cinq modules, à travers les lignes require:"nom du module". Il s'agit de

• 1 sous-module
• Module:Wikidata et Module:Math qui existent dans beaucoup d'autres langues mais peuvent fonctionner un peu différemment dans chacune.
• Module:Démographie qui s'occupe des graphiques et qu'on devrait idéalement remplacer par l'extension graph, plus universelle.
• Module:Chartes qui parait assez spécifique au français (frwiki a divers codes couleurs customisés et arbitraires alors qu'enwiki semble les avoir abandonnés).

Si c'est juste changer un nom de module ce n'est pas très compliqués. Mais il faut surtout vérifier que tous les modules appelés existent dans la langue cible, et le cas échéant, faire des ajustement pour que ce soit compatible.

ll y a deux autres points, moins complexes :

• La langue du code lui même. J'ai tendance à l'écrire en anglais, pour que tout le monde puisse comprendre à peu près, de toute façon il y a forcément des mots anglais à l'intérieur. Mais les pratiques varient.
• La traductions des textes retournés par le module. Le mieux est de les mettre tous au même endroit (c'est la table "texts") de Module:Population de France/Bac à sable. Mais ce n'est pas toujours ce qu'on fait, et on peut en oublier.-Zolo (discuter) 2 septembre 2020 à 13:04 (CEST)

Module:France vs Module général

Le nouveau module permet de générer des tableaux et des graphiques pour n'importe quel jeu de données au bon format et lié depuis Wikidata. Une fonction spécifique paramètre la sélection des données pour la France. Elle est activée lorsque le pays indiqué sur Wikidata est "Q142".--Zolo (discuter) 30 août 2020 à 15:20 (CEST)

Je pense que cette manière de faire avec un module général, plus des options spécifiques à différents cas est la plus simple. Peut-être faire un sous-module de paramétrage par pays ? --Zolo (discuter) 30 août 2020 à 15:20 (CEST)

@Zolo J'ai l'impression que tu récupères la table avec getTable(qid). Du coup, il ne faut pas supprimer FR dans le nom de la table et ne mettre que l'identifiant WD qui n'est dès lors que cosmétique et peut compliquer la vie puisque tu vas chercher le code pays ensuite ?Roland45 (discuter) 30 août 2020 à 15:41 (CEST)

@Roland45 Le nom du fichier ne change rien pour le module : il se base sur Wikidata (propriétés "pays" et "population tabulaire"). -Zolo (discuter) 30 août 2020 à 16:15 (CEST)

OK. J'avais oublié qu'il y avait un lien qui reliait automatiquement l'élément WD à la table. Donc ça se passe entre liens WD.Roland45 (discuter) 30 août 2020 à 16:29 (CEST)

Lisibilité du code

J'ai essayé d'ajouter des commentaires pour rendre le code plus lisible. La principale source de complexité est probablement le fait que le module va analyser les noms des différentes colonnes sur Commons pour aller voir à quoi elles correspondent. Si l'ordre était toujours le même, ce serait plus simple. Mais je pense qu'il vaut mieux prévoir un peu de souplesse car les informations apportées ne seront pas forcément les mêmes dans tous les pays.--Zolo (discuter) 30 août 2020 à 15:20 (CEST)

"Introductions"

Je n'ai pas encore traité Module:Population de France/Introductions, qui est la plus difficile à gérer proprement. Je pense qu'on peut la laisser dans un sous-module dédié, d'autant qu'elle est très spécifique à la France. Si on veut faire quelque chose de similaire pour les autres pays, on peut sans dans utiliser un autre sous-module. Après, à titre personnel, j'ai pas mal de réserves sur cette manière d'utiliser des modèles pour générer du contenu dans le corps du texte.--Zolo (discuter) 30 août 2020 à 15:20 (CEST)

@Zolo Pour la France, il y aussi la question des notes de pied de tableau qui varient selon la nature de la division. Dès lors qu'on supprime COM1 ou COM2 ou tout type de code de division, il va falloir être clair sur le code WD correspondant à chaque type de division.Roland45 (discuter) 30 août 2020 à 15:45 (CEST)

La nature de la division peut-être récupérée sur Wikidata en utilisant la propriété "nature de l'élément" P31 (« nature de l’élément »). Mais ça ne marche pas à 100%. Par exemple, je crois que l'outre-mer a besoin d'un texte spécial, mais Wikidata utilise (logiquement) la valeur "commune de France" (par exemple sur Fort de France. Il y a moyen de retrouver ça en passant sur Wikidata, mais ça risque d'être un peu tarabiscoté et coûteux en termes de performance. Je ne sais pas trop quoi faire. Une autre solution est de faire des listes Lua des communes pour lesquelles il ne faut pas utiliser le système standard. --Zolo (discuter) 30 août 2020 à 16:15 (CEST)

Utilisation de l'extension graph

J'aimerais bien utiliser cette extension, mais elle est un peu complexe et mal documentée. Je n'ai pas réussi à la faire marcher correctement avec des histogrammes. Ca peut attendre. Ce qu'on a pour l'instant fonctionne correctement. -Zolo (discuter) 30 août 2020 à 15:20 (CEST)

Nom du module

Etant donné que la nouvelle version doit permettre de traiter tous les pays, il faut peut-être renommer en Module:Population ?--Zolo (discuter) 30 août 2020 à 15:20 (CEST)

Oui. Assurément, mais pour tout ce qui est spécifique à la France, il faudra faire un bel encart de commentaires dans le module pour montrer ce qui est propre à la France.Roland45 (discuter) 30 août 2020 à 15:47 (CEST)

Gestion des erreurs

Module:Population de France/Constantes prévoit à l'heure actuelle de catégoriser les pages avec des problèmes. Il existe 7 catétories différentes en fonction du type d'erreur. Je n'ai pas vérifié si cela marchait, mais les catégories en tout cas n'ont pas été créées. Je proposerais de s'en tenir à une catégorie unique; avec dans le texte un message d'erreur le plus descriptif possible mais pas flashy pour que les problèmes internes ne gênent pas trop le lecteur. -Zolo (discuter) 30 août 2020 à 17:18 (CEST)

 Zolo : Les catégorisations ne fonctionnent pas. Si tu pouvais bricoler quelque chose pour le module actuel également (en attendant)...

Cordialement, Jessy ^Oui ? 31 août 2020 à 13:59 (CEST)

Données départementales

@Zolo Je prépare les tables des départements et m'aperçois qu'il manque un code Wikidata. En effet les données relatives aux départements antérieures à 2006 ont été récupérées sur le SPLAF (Site sur la Population et les Limites Administratives de la France) (ici). C'est le seul qui donne les données départementales depuis 1791. Or il n'existe pas d'élément wikidata pour cette entité. Pourrais-tu le créer ? Merci.Roland45 (discuter) 31 août 2020 à 09:44 (CEST)

Je n'aurais pas dordi aujourdhui mais tout le monde peut créer un element sur Wikidata. Je le compléterai s'il manque des choses.Zolo (discuter) 31 août 2020 à 13:56 (CEST)

@Roland45 j'ai créé d:Q98819748. Je ne sais pas si leurs données sont totalement stables. Sinon, il faudrait idéalement avoir une URL d'archive qui ne bougerait pas, ou ajouter une colonne S813 indiquant la [[:d:P:P813|date de consultation. -Zolo (discuter) 1 septembre 2020 à 17:21 (CEST)

Sources

Serait-il possible d'avoir une liste exacte de la source pour les différents cas de figures, et pour l'ensemble des divisions administratives. J'essaye de reprendre Module:Population de France/Bac à sable mais je m'y perds un peu, et il y a visiblement des choses qui ne marchent pas comme elles le devraient.

@Zolo Les sources actuellement utilisées sont, pour l'instant, les suivantes :

• Q18677019 (« base Cassini ») (Communes - données antérieures à 2006)
• Q98819748 (« Le SPLAF ») (départements - données antérieures à 2006)
• [[:d:Q83418206|Q83418206 (« Populations légales 2006 »)]] (toutes divisions hors EPCI)
• Q83418077 (« Populations légales 2007 ») id
• Q83417811 (« Populations légales 2008 ») id
• [[:d:Q83417603|Q83417603 (« Populations légales 2009 »)]] id
• Q83417455 (« Populations légales 2010 ») id
• Q83417330 (« Populations légales 2011 ») id
• Q83417162 (« Populations légales 2012 ») id
• Q83416868 (« Populations légales 2013 ») id
• Q83414059 (« Populations légales 2014 ») id
• Q63809111 (« Populations légales 2015 ») id
• Q63330390 (« Populations légales 2016 ») id
• Q81204110 (« Populations légales 2017 ») id

Pour les données antérieures à 2006 hors EPCI (Arrondissements, cantons, régions), j'ai mis Insee comme référence et repris l'url existant dans le module. Le pb est que la plupart de ces url sont des liens brisés et pour l'instant je n'ai pas trouvé d'équivalent. Je cherche. J'ai bien peur qu'il faille reprendre toutes ces données, car les seules disponibles sont établies sur une géométrie territoriale différente (2019) et sont donc différentes de celles dans les tableaux (établies sur une autre géométrie). Pour le coup c'est un texte qu'il faudra ajouter en note (populations établies sur la géométrie territoriale en vigueur au 1er janvier xxx).

Note également qu'un nouveau code est créé chaque année, ce qui peut paraitre compliqué pour ton module. Je me demande s'il ne faudrait tout simplement n'avoir que l'Insee (Q156616) pour toutes les années post-2006 dans la colonne S248, le lien se ferait par l'url de la colonne S254.Roland45 (discuter) 3 septembre 2020 à 14:40 (CEST)

Gestion des cantons

Wikidata sépare les cantons d'avant 2015 et ceux d'après. Ca me parait assez logique, mais Wikipédia fonctionne différemment. @Roland45 est-il bien prévu de les séparer sur les tables Commons ?

Sur Canton de Dijon-6, il y a deux tableaux de population différents, un pour l'avant 2015 et un pour l'après 2015. La présentation est similaire, mais ils n'utilisent pas les mêmes modèles. Le premier utilise {{Tableau population de canton de France}} qui ne fait pas appel à Module:Population de France. Pour moi la meilleure solution serait d'utiliser le même modèle dans les deux cas, en ajoutant simplement un paramètre pour indiquer qu'on fait référence à l'ancien canton : |wikidata=Q88077461. -Zolo (discuter) 3 septembre 2020 à 13:28 (CEST)

@Zolo Tu as raison. Par solution de facilité, on avait considéré que le module n'était utilisé que pour les nouveaux cantons. Cela évitait aussi de faire des modules différenciés qu'il aurait fallut appeler autrement, avec un suffixe ou préfixe par exemple ou d'avoir des graphiques avec des sauts de population si on mettait tout sur les données sur le même module. Il paraitrait en effet plus logique d'avoir deux tables différentes. Bon, si ma requête WD est bonne, cela rajoute 4044 tables nouvelles dans ma besace!

Par contre il y a une difficulté majeure. Je viens d'en parcourir quelques-uns et on a des tableaux qui sont construits avec le modèle:Démographie et des données en dur dans l'article. En matière de bot, tout est faisable, mais cela se complique quand même. En tout cas si on part sur ce principe d'un seul module, de toute façon si la table n'existe pas on aura toujours les modèles de données qui seront actifs ou les données en dur encore plus. Il n'y aura donc pas de désorganisation.

Il y a une autre tâche monumentale qui nous attend (quand le module fonctionnera) : l'ajout dans tous les articles concernés de l'appel au module (en remplacement des autres appels à des modèles/modules existant dans l'article)!Roland45 (discuter) 3 septembre 2020 à 14:25 (CEST)

@Roland45 merci noté. Pour les tables de communes, il n'y a rien besoin de changer sur les articles, juste modifier les modèles pour les faire utiliser le nouveau module. -Zolo (discuter) 3 septembre 2020 à 16:47 (CEST)

@Zolo en réalité, des modèles de population existent théoriquement pour tous les cantons existants jusqu'au 21 mars 2015. Je n'ai actuellement ajouté les modèles du type {{Données/Canton de Dijon-6/évolution population}} (par appel avec {{Tableau population de canton de France}} et {{Graphique population de canton de France}}) que sur les cantons toujours en vigueur (càd un canton actuel qui a le même nom qu'un ancien canton).

 Roland45 : De toute façon, l'intégralité des anciens cantons n'ont pas de sources pour les données de populations antérieures à 2006 (liens brisés).

Cordialement, Jessy ^Oui ? 4 septembre 2020 à 14:48 (CEST)

Transfert des données

Bonjour user:Roland45 et user:JessydeVilly,

J'ai peu été présent sur Wiki ces derniers temps pour diverses raisons, mais je pense qu'on peut essayer de finaliser ce projet. user:Roland45, penses-tu qu'il reste beaucoup de travail pour pouvoir créer les tableau de populations sur Commons ? Je pense qu'une fois qu'on a les données, c'est plus facile d'avancer. On peut ensuite y aller progressivement dans la mise à jour des modèles sur Wikipédia. -Zolo (discuter) 6 mars 2021 à 12:31 (CET)

Bonjour Zolo et Roland45 je pense également qu'il faudrait que l'on concrétise ce projet.

Je ne serais pas très disponible ces jours-ci, mais je garderais un œil sur l'avancé des discussions (et sur les éventuels problèmes que l'on pourra rencontrer).

En parlant de problème, j'en soulève un (pour plus tard) : serait-il possible avec le nouveau système de conserver un module pour les fractions cantonales ? Je ne vois pas l'intérêt d'un historique de population sur les fractions cantonales, sachant que ces dernières varient (à la baisse) chaque année et qu'elles ne sont utilisées que dans le tableau de composition sur les articles de cantons...

Cordialement, Jessy ^Oui ? 6 mars 2021 à 13:23 (CET)

@Zolo et @JessydeVilly Bonjour. Le projet était effectivement en sommeil. J'étais donc passé à autre chose. Je vais dégager un peu de temps et me replonger dedans pour actualiser les tables avec les données 2018. On va voir. Je reviens sur le sujet au plus tôt.Roland45 (discuter) 6 mars 2021 à 15:07 (CET)

@Zolo et @JessydeVilly J'ai déjà créé cette page sur Commons, ce qui permet de voir quand un lien ne fonctionne pas (ce qui n'était pas le cas sous WP). La discussion peut continuer ici sur WP. Je vais regrouper les questions qui se posent.Roland45 (discuter) 6 mars 2021 à 16:14 (CET)

Quelques observations rapides

Nom du module

Comme cela a été abordé précédemment, il sera souhaitable de renommer le module « Population » pour l’internationaliser.

Nom des tables

Le décret qui est sorti récemment en février 2021 renommant un certain nombre de cantons nous conforte dans l'idée que pour ne pas se compliquer la tâche, il faut conserver uniquement le code WD dans le nom de la table et ne pas y ajouter le nom de la division. Mais ceci avait déjà été acté.

Création des tables

Deux tâches : actualiser les tableaux-sources puis créer les tables.

Actualiser les tableaux-sources avec les données 2018

Un bot pas très long, mais à faire quand même.

Création de toutes les tables

Il y en a 37 458 au 1er janvier 2021, et donc autant de tables à créer, se répartissant comme suit :

• Régions 17
• Départements 101
• Arrondissements 332
• Cantons 2 043
• Communes 34 965

Avec un bot qui fonctionne bien (à savoir dédié à la tâche et sans bug, car j’ai toujours des pb de saturation de la mémoire au bout d’un certain temps qui me contraignent de relancer la bécane !) : 5 jours environ.

Mais comme je l’ai déjà dit, il me parait souhaitable de s’assurer au préalable que tout fonctionne avant de se lancer définitivement.

@Roland45 la création des tables et son utilisation dans son module sont des choses assez différentes, et la première précède nécessairement la première. Pour les la création des tables, il faut être sûrs que toutes les données sont correctes, et puis tout faire d'un coup avec un bot (en tout cas toutes les communes). Je peux m'occuper d'ajouter les liens sur Wikidata.

Pour le module, cela peut se faire plus progressivement. Il y a encore des ajustements à faire dans le module pour qu'il puisse totalement remplacer l'actuel, puis encore du travail pour le rendre généralisable à l'ensemble des pays, voire après pour développer de nouvelles fonctionnalités. Mais ce sera sans doute plus facile à faire une fois qu'on aura les données pour pouvoir tout tester de manière plus systématique. Il y aura forcément un période de transition avant de pouvoir supprimer complètement les données stockées sur Wikipédia. --Zolo (discuter) 6 mars 2021 à 18:03 (CET)

Éléments Wikidata

Il me semble me rappeler que pour fonctionner un lien doit être mis dans l'élément WD de la division le liant avec la table. Ceci ne pourra être fait que par un bot. Je précise d'ores et déjà que je ne maîtrise pas les bots de traitement de données WD (WP et Commons, oui, mais pas WD). Il faudra donc trouver un volontaire connaissant le sujet.

Fonctionnement

En France

Pour tableau et graphique, la représentation est la même. Donc, OK (mais je n'ai testé que la commune de L'Abergement-Clémenciat, qui, soit dit en passant, a ses doubles tableaux et graphiques depuis l'an dernier !

Pour le sous-module introduction, il y a un bug, avec le message suivant : ‘’the module does not currently handle Commune de France’’

Autre pays

Pour un autre pays (avec les données françaises), ce qui est quand même au départ la finalité, il apparaît que le module n’est pas supporté. S’il faut créer un module propre à chaque pays, ce qui semble effectivement se profiler, avec tous les textes traduits dans la langue du pays, cela va se compliquer !!

D'ailleurs je pourrais créer aussi une table pour un autre pays, histoire de voir.

@Zolo et @JessydeVilly Bon, c'était histoire de relancer la réflexion.Roland45 (discuter) 6 mars 2021 à 16:55 (CET)

@Roland45 : Question certainement idiote, mais qu'entends-tu par tableaux-sources ? Les modules ? Les feuilles Excel ?

Sinon pour les noms on est d'accord, on ne se limite qu'aux codes pour éviter les X renommages.

Il faudra voir ce que l'on veut/peut faire des EPCI, AAV, UU etc...

Cordialement, Jessy ^Oui ? 6 mars 2021 à 18:00 (CET)

@JessydeVilly Oui. Je voulais parler des classeurs Excel qui permettent de servir de données au futur bot de création ou d'actualisation des tables Commons.Roland45 (discuter) 7 mars 2021 à 12:12 (CET)

Finalité

Bonjour @Roland45, @JessydeVilly et @Zolo. Merci et bravo si vous y arrivez ! Pour m'être entretenu de ce sujet lors d'une wikirencontre, j'avais noté que l'intérêt de disposer de ces données dans WD était de pouvoir compléter les articles consacrés à nos communes de France dans les centaines de wikipédia en langes étrangères, articles qui contiennent actuellement bien souvent des graphiques incomplets, voire faux ou inexistants. Est-ce toujours ce que vous cherchez à faire ? Bien cordialement. AntonyB (discuter) 6 mars 2021 à 18:26 (CET)

Bonjour AntonyB ,

C'est effectivement un des objectifs à terme. Cependant une petite précision, les données seront chargées sur Commons et non sur WikiData.

Cordialement, Jessy ^Oui ? 6 mars 2021 à 20:06 (CET)

Bien reçu. Merci de la précision en effet ! AntonyB (discuter) 6 mars 2021 à 22:08 (CET)

Introductions

J'ai commencé à évoluer vers un module plus général dans Module:Population (user:Zolo/test) et il semble que les introductions sous formes de texte que l'on vont pas mal compliquer le code. Je m'interroge en plus sur la pertinence de ces textes. De manière généralel, faire rédiger un bout d'article de manière automatique par un modèle pose des problèmes de flexibilité. Il s'agit en plus d'infos assez techniques sur les méthodes de recensement. Je doute que cela intéresse la majorité des lecteurs (et pour ceux que ça intéresse, le répéter dans chaque article n'apporte pas grand chose). On a absolument besoin de les conserver ? -Zolo (discuter) 8 mars 2021 à 15:53 (CET)

@Zolo Si on veut réduire et internationaliser, il me semble qu'une simple phrase donnant les dernières valeurs de population et la date de référence est a minima souhaitable. On peut effectivement se passer du texte sur les modalités de recensement, et ne retenir par exemple que la dernière phrase de l'actuel texte en remplaçant la note par un texte en clair, ce qui donne ::

« En 2018, la commune comptait 211 habitants (population municipale légale en vigueur au 1er janvier 2021, millésimée 2018, définie dans les limites territoriales en vigueur au 1er janvier 2020), en augmentation de 0,48 % par rapport à 2013 (Loiret : +1,99 %, France hors Mayotte : +2,36 %). »

.Roland45 (discuter) 8 mars 2021 à 19:08 (CET)

Mise en forme du graphique

J'ai jeté un nouveau coup d'oeil sur l'extension graph, qui est très puissante. Techniquement, il semblerait logique d'y avoir recours plutôt qu'à Modèle:Histogramme population manuel. En revanche, il a l'air compliqué de lui faire gaire le même graphique en barre, car les histogrammes ne fonctionnent pas avec les dates. A la place, on peut avoir une liste de points marqués par une croix. C'est un peu austère. On peut les lier avec une ligne, ce qui semblera sans doute plus clair à la plupart des gens. Le problème est que ça peut laisser croire à une évolution linéraire lorsqu'il n'y a pas de données (l'Abergement-Clémenciat entre 1800 et 1860) mais ce n'est pas vraiment pire que la situation actuelle qui peut laisser croire que le village a été déserté pendant 50 ans. -Zolo (discuter) 8 mars 2021 à 20:49 (CET)

Histogramme de l'évolution démographique

Fichier utilisé : commons:Data:Population FR Q204388.tab. (TODO : mise en forme des sources)

Histogramme de l'évolution démographique

Fichier utilisé : commons:Data:Population FR Q204388.tab. (TODO : mise en forme des sources)

@Zolo Une discussion concernant le type de graphique a déjà eu lieu dans le passé au sein du projet Communes de France (peut-être que @antonyB peut la retrouver. Il me semble difficile de revenir sur l'histogramme à barres, mais pourquoi pas. Je comprends que le Modèle:Histogramme population manuel étant propre à la WP française, cela pose un problème, mais il faut y réfléchir. Si je regarde en:Orléans, la WP anglaise utilise un graphe en polylignes (donc différent de nos barres), qui est néanmoins pas mal. Il utilise le modèle en:Template:Historical populations. Mais globalement la WP anglaise est moins avancée que nous. Souvent il n'y a pas de graphique (voir en:Demographics of New York City ou en:Demography of London). C'est même incroyable, si tu balayes en:Category:Demographics by city, il n'y en a aucune qui a un graphique créé à la volée. Quand il y en a ce sont la plupart du temps des images. Pour le coup, si un module international était créé ce serait utile à tous. A creuser donc.Roland45 (discuter) 9 mars 2021 à 12:35 (CET)

Bonjour @Zolo et @Roland45. Merci du signalement. En effet, je plussoie ce qu'écrit Roland45 d'autant que cette représentation est le fruit de bien des discussions. Quant à représenter avec des histogrammes, c'est la seule solution pour une population, lorsqu'on ne sait pas ce qui s'est passé entre deux valeurs connues. Lors des discussions, on a eu plusieurs exemples (guerres, mais surtout constructions des voies ferrés et d'ouvrages d'art au début du XX^e siècle) qui nous ont montré combien il était hasardeux de relier les points marqués par des croix (c'est le statisticien que je fus dans une vie antérieure qui parle). Bien cordialement. AntonyB (discuter) 9 mars 2021 à 14:18 (CET)

@Zolo et @AntonyB En fait j’ai parcouru pas mal de sites dédiés à la démographie : aucun ne donne des graphiques de types histogrammes à barres. Ce sont tous des graphiques à lignes (lignes continues ou lignes de points). Je dirais même que nous sommes les seuls (… sur tout le web !!) à avoir ce genre d’histogramme à barres pour les données démographiques. Quelques exemples :

• INSEE - Bilan démographique 2020
• INED – lignes continues (choisir l’onglet courbes d’évolution).
• Union européenne : des polylignes (on peut également choisir plusieurs pays pour un affichage simultané des données)
• Banque mondiale : Graphiques à lignes de points
• Royaume Uni : lignes continues avec les valeurs en infobulles
• Nations Unies – Monde : Des lignes continues
• Nations Unies – France : Des lignes continues

On ne peut pas qualifier ces sites de ne pas être sérieux. Ce sont tous des références en la matière. Il me semble que nous devrions envisager sérieusement de passer aux lignes en réfléchissant aux deux points suivants :

• peut-on sauter des années lorsque ces années ne sont pas renseignées ?
• peut-on mettre les données en infobulles ?

Cordialement. Roland45 (discuter) 9 mars 2021 à 17:22 (CET)

@Zolo et @AntonyB Notez qu'à la réflexion, la représentation de la démographie d'Orléans sur la WP anglaise (en:Orléans) est quand même intéressante. Le tableau de données est bien plus compact tout en donnant les taux d'évolution entre années de recensement, le graphe est beaucoup plus petit et suffit largement. Et la mise en continuité des années absentes n'engendre pas d'anomalie.Roland45 (discuter) 9 mars 2021 à 17:33 (CET)

---

Bonjour. Tout à fait d'accord avec toi @Roland45. Bien sûr que tous ces sites sont très sérieux. Bien sûr que tous les graphiques dans lesquels nous avons appris l'histoire et la géographie étaient bâtis à partir de courbes reliant des points. 100 % d'accord. On appelait cela quand j'étais jeune la « loi des grands nombres » : c'est évidemment vrai pour la population mondiale et il ne viendrait à l'idée de personnes d'avoir une autre représentation (quoiqu'il faille faire bien attention au moments des deux guerres mondiales, mais les statisticiens le savent).

Mais j'aurais dû rappeler (c'était l'objet d'une discussion animée il y a une dizaine d'années) que nous ne cherchons pas à représenter des évolutions où la loi des grands nombres est effective. On a même des petits villages où la population a augmenté dans des proportions très importantes en quelques années puis a diminué aussi rapidement. Il n'est alors pas correct de relier des points épars par une courbe.

Notre problème n'est pas celui de la représentation de la population mondiale. Prenons par exemple, la commune où je suis actuellement (Antony). Les recensements indiquent 24 512 habitants en 1954 et 46 483 habitants en 1962. Ceux qui connaissent la façon dont la France a accueilli en peu de temps un million de rapatriés d'Algérie savent que cela s'est fait parfois très rapidement. Antony en a accueilli de l'ordre de 20 000 entre fin 1961 et début 1962. Il appert donc qu'il ne faut pas relier le point de 1954 à celui de 1962. La représentation qu'en fait l'en.wikipedia (voir en cliquant ici) est fausse et en plus elle donne comme source EHESS et Insee alors qu'aucun de ces organismes ne donne des informations permettant de construire cette courbe. Ce n'est qu'un exemple, il y a aussi le cas des constructions de lignes de chemin de fer. Bref, l'histogramme était apparu comme la solution qui évitait de montrer des erreurs flagrantes. Mais je sais que je suis scientifique et que je veux (peut-être) trop bien faire.

Enfin dernier point, pour information, il y a une dizaine d'années un contributeur voulant bien faire à fait des images (cf. ci-contre) pour toutes les communes. Ce sont des horreurs du point de vue statistique, puisque les barres ne correspondant pas à un axe horizontal linéaire (6, 7, 8 ou 9 ans entre deux barres). Pas trop faux ici, mais certaines fois on avait un grand nombre d'années entre deux barres. Pour votre info, plusieurs WP en langue étrangère continuent à utiliser ces horreurs : voir par exemple en cliquant ici.

Bien cordialement. AntonyB (discuter) 9 mars 2021 à 18:58 (CET)

Il y a aussi la possibilité de mettre des points sans les relier. Je l'ai changé dans mon exemple pour illustration, mais je ne suis suis pas sûr que ce soit très clair pour le lecteur moyen. Après, on peut aussi garder les histogrammes. Si d'autres Wikipédias veulent utiliser le modèle, ils peuvent toujours le copier, mais c'est ça rend le code un peu moins lisible, et ça ouvre sans doute moins de possibilités d'évolutions futures. -Zolo (discuter) 9 mars 2021 à 19:15 (CET)

@Zolo Serait-il possible de donner le choix entre lignes (sans croix) et points (comme celle ci-dessus) via un paramètre ?

@AntonyB Si nous seuls les seuls - au monde - à utiliser des histogrammes à barres pour les courbes démographiques, on doit réellement s'interroger sur la pertinence de nos choix il y a une dizaine d'années.Roland45 (discuter) 9 mars 2021 à 20:37 (CET)

@Roland45 : j'ai changé le modèle pour permettre de transmettre les paramètres de mise en forme de l'extension Graph. Par défaut, les données réelles sont données par des petits points, reliés par une ligne fine. On peut cacher les points, cacher la ligne, changer les couleurs, la forme ou la taille des points. Par exemple ajouter |linewidth = 0 fait disparaitre la

---

Pour info @Roland45, ce choix ne date pas d'il y a dix ans mais d'avant (il y a des histogrammes depuis longtemps). Ce que l'on a fait en 2010 c'est de remplacer ce qui existait par des histogrammes via timeline, c'était bien long à rédiger mais au moins c'était juste du point de vue mathématique.

Exemple pour Antony (et on faisait ça pour chaque commune à l'époque ... heureusement que Wikialine puis toi sont venus aider !

Code timeline d'affichage de graphique

{{Démographie2
|colonnes           =9
|largeur-tableau    =60%
|titre              =
|marge-interlignes  =18px
|taille-police      =90%
|hauteur-lignes     =120%
|hyperliens-années  =on
|années-fond        =#F5F5F5
|population-fond    =#F3FFF3
|notes-fond         =#F5F5F5
|style-notes        =
| 1793 | {{formatnum:1223}}
| 1800 | {{formatnum:1100}}
| 1806 | {{formatnum:1028}}
| 1821 | {{formatnum:1170}}
| 1831 | {{formatnum:1182}}
| 1836 | {{formatnum:1336}}
| 1841 | {{formatnum:1360}}
| 1846 | {{formatnum:1347}}
| 1851 | {{formatnum:1328}}
| 1856 | {{formatnum:1359}}
| 1861 | {{formatnum:1650}}
| 1866 | {{formatnum:1753}}
| 1872 | {{formatnum:1497}}
| 1876 | {{formatnum:1525}}
| 1881 | {{formatnum:1620}}
| 1886 | {{formatnum:1872}}
| 1891 | {{formatnum:1967}}
| 1896 | {{formatnum:2533}}
| 1901 | {{formatnum:3068}}
| 1906 | {{formatnum:3477}}
| 1911 | {{formatnum:4490}}
| 1921 | {{formatnum:7549}}
| 1926 | {{formatnum:12468}}
| 1931 | {{formatnum:17645}}
| 1936 | {{formatnum:19780}}
| 1946 | {{formatnum:21233}}
| 1954 | {{formatnum:24512}}
| 1962 | {{formatnum:46483}}
| 1968 | {{formatnum:56638}}
| 1975 | {{formatnum:57540}}
| 1982 | {{formatnum:54610}}
| 1990 | {{formatnum:57771}}
| 1999 | {{formatnum:59849}}
| 2006 | {{formatnum:60552}}
| 2008 | {{formatnum:61240}}
|sources=base Cassini de l'EHESS pour les nombres retenus jusqu'en 1962<ref  name="fcass">
{{Lien web
   |url=http://cassini.ehess.fr/cassini/fr/html/fiche.php?select_resultat=969
   |titre=Des villages de Cassini aux communes d'aujourd'hui
   |site =site de l'École des hautes études en sciences sociales
   |consulté le= 5 septembre 2010}}</ref>, base Insee à  partir de 1968 ([[Chiffres de population en France|population sans doubles  comptes]] puis [[Chiffres de population en France|population municipale]] à  partir de [[2006]])<ref>
{{Lien web
   |url=http://www.statistiques-locales.insee.fr/Fiches%5CDL%5CDEP%5C92%5CCOM%5CDL_COM92002.pdf
   |titre=Évolution et structure de la population (de 1968 à  2007)
   |site =[[Institut national de la statistique et des études  économiques|Insee]]
   |consulté le= 5 septembre 2010}}</ref>{{,}}<ref>
{{Lien web
   |url=http://www.insee.fr/fr/ppp/bases-de-donnees/recensement/populations-legales/commune.asp?depcom=92002&annee=2006
   |titre=Recensement de la population au 1{{er}} janvier 2006
   |site =[[Institut national de la statistique et des études  économiques|Insee]]
   |consulté le= 5 septembre 2010}}</ref>
}}
<center>
<timeline>
Colors=
  id:lightgrey value:gray(0.9)
  id:darkgrey value:gray(0.7)
  id:sfondo value:rgb(1,1,1)
  id:barra value:rgb(0.7,0.9,0.7)
ImageSize  = width:750 height:340
PlotArea   = left:50 bottom:30 top:30 right:50
DateFormat = x.y
Period =from:0 till:65000
TimeAxis   = orientation:vertical
AlignBars  = justify
ScaleMajor =  gridcolor:darkgrey increment:10000 start:0
ScaleMinor =  gridcolor:lightgrey increment:5000 start:0
BackgroundColors =  canvas:sfondo
BarData=
  bar:1791
  bar:1792
  bar:1793
  bar:1794
  bar:1795
  bar:1796
  bar:1797
  bar:1798
  bar:1799
  bar:1800 text:1800
  bar:1801
  bar:1802
  bar:1803
  bar:1804
  bar:1805
  bar:1806
  bar:1807
  bar:1808
  bar:1809
  bar:1810
  bar:1811
  bar:1812
  bar:1813
  bar:1814
  bar:1815
  bar:1816
  bar:1817
  bar:1818
  bar:1819
  bar:1820 text:1820
  bar:1821
  bar:1822
  bar:1823
  bar:1824
  bar:1825
  bar:1826
  bar:1827
  bar:1828
  bar:1829
  bar:1830
  bar:1831
  bar:1832
  bar:1833
  bar:1834
  bar:1835
  bar:1836
  bar:1837
  bar:1838
  bar:1839
  bar:1840 text:1840
  bar:1841
  bar:1842
  bar:1843
  bar:1844
  bar:1845
  bar:1846
  bar:1847
  bar:1848
  bar:1849
  bar:1850
  bar:1851
  bar:1852
  bar:1853
  bar:1854
  bar:1855
  bar:1856
  bar:1857
  bar:1858
  bar:1859
  bar:1860 text:1860
  bar:1861
  bar:1862
  bar:1863
  bar:1864
  bar:1865
  bar:1866
  bar:1867
  bar:1868
  bar:1869
  bar:1870
  bar:1871
  bar:1872
  bar:1873
  bar:1874
  bar:1875
  bar:1876
  bar:1877
  bar:1878
  bar:1879
  bar:1880 text:1880
  bar:1881
  bar:1882
  bar:1883
  bar:1884
  bar:1885
  bar:1886
  bar:1887
  bar:1888
  bar:1889
  bar:1890
  bar:1891
  bar:1892
  bar:1893
  bar:1894
  bar:1895
  bar:1896
  bar:1897
  bar:1898
  bar:1899
  bar:1900 text:1900
  bar:1901
  bar:1902
  bar:1903
  bar:1904
  bar:1905
  bar:1906
  bar:1907
  bar:1908
  bar:1909
  bar:1910
  bar:1911
  bar:1912
  bar:1913
  bar:1914
  bar:1915
  bar:1916
  bar:1917
  bar:1918
  bar:1919
  bar:1920 text:1920
  bar:1921
  bar:1922
  bar:1923
  bar:1924
  bar:1925
  bar:1926
  bar:1927
  bar:1928
  bar:1929
  bar:1930
  bar:1931
  bar:1932
  bar:1933
  bar:1934
  bar:1935
  bar:1936
  bar:1937
  bar:1938
  bar:1939
  bar:1940 text:1940
  bar:1941
  bar:1942
  bar:1943
  bar:1944
  bar:1945
  bar:1946
  bar:1947
  bar:1948
  bar:1949
  bar:1950
  bar:1951
  bar:1952
  bar:1953
  bar:1954
  bar:1955
  bar:1956
  bar:1957
  bar:1958
  bar:1959
  bar:1960 text:1960
  bar:1961
  bar:1962
  bar:1963
  bar:1964
  bar:1965
  bar:1966
  bar:1967
  bar:1968
  bar:1969
  bar:1970
  bar:1971
  bar:1972
  bar:1973
  bar:1974
  bar:1975
  bar:1976
  bar:1977
  bar:1978
  bar:1979
  bar:1980 text:1980
  bar:1981
  bar:1982
  bar:1983
  bar:1984
  bar:1985
  bar:1986
  bar:1987
  bar:1988
  bar:1989
  bar:1990
  bar:1991
  bar:1992
  bar:1993
  bar:1994
  bar:1995
  bar:1996
  bar:1997
  bar:1998
  bar:1999
  bar:2000 text:2000
  bar:2001
  bar:2002
  bar:2003
  bar:2004
  bar:2005
  bar:2006
  bar:2007
  bar:2008
PlotData=
 color:barra width:10 align:left
 bar:1793 from:0 till: 1223
 bar:1800 from:0 till: 1100
 bar:1806 from:0 till: 1028
 bar:1821 from:0 till: 1170
 bar:1831 from:0 till: 1182
 bar:1836 from:0 till: 1336
 bar:1841 from:0 till: 1360
 bar:1846 from:0 till: 1347
 bar:1851 from:0 till: 1328
 bar:1856 from:0 till: 1359
 bar:1861 from:0 till: 1650
 bar:1866 from:0 till: 1753
 bar:1872 from:0 till: 1497
 bar:1876 from:0 till: 1525
 bar:1881 from:0 till: 1620
 bar:1886 from:0 till: 1872
 bar:1891 from:0 till: 1967
 bar:1896 from:0 till: 2533
 bar:1901 from:0 till: 3068
 bar:1906 from:0 till: 3477
 bar:1911 from:0 till: 4490
 bar:1921 from:0 till: 7549
 bar:1926 from:0 till: 12468
 bar:1931 from:0 till: 17645
 bar:1936 from:0 till: 19780
 bar:1946 from:0 till: 21233
 bar:1954 from:0 till: 24512
 bar:1962 from:0 till: 46483
 bar:1968 from:0 till: 56638
 bar:1975 from:0 till: 57540
 bar:1982 from:0 till: 54610
 bar:1990 from:0 till: 57771
 bar:1999 from:0 till: 59849
 bar:2006 from:0 till: 60552
 bar:2008 from:0 till: 61240
TextData=
  fontsize:S pos:(50,10)
  text:Sources - base Cassini de l'EHESS et Insee.
</timeline>
</center>

ce qui donnait à l'époque l'histogramme ci-dessous, c'est-à-dire la même représentation que ce que l'on voit aujourd'hui :

 

Quant au fait qu'on soit les seuls, je ne sais pas. Toutes les références que tu as données ci-dessus concernent des populations globales (loi des grands nombres), rien qui ne corresponde à notre besoin. Je vais essayer de trouver si une source sérieuse a traité le cas qui nous intéresse. L'exemple d'Antony me semble un bon exemple. Bien cordialement. AntonyB (discuter) 9 mars 2021 à 21:59 (CET)

@AntonyB Je connais l'historique, puisque je suis cela depuis le début. Si les histogrammes à barre sont apparus, c'est tout simplement parce qu'à l'époque, en 2007, il n'y avait pas encore de modèles. Seule la balise timeline pouvait être utilisée avec des barres horizontales ou verticales ou des courbes. Les premiers graphiques utilisant la timeline ont dû apparaitre en 2007 mais sous forme de barres, et c'est ce qui a ancré la représentation en barres. Certaines grandes villes ont dû être faites en 2008. Ce n'est qu'en juillet 2011 que les réflexions ont été lancées pour transformer cette fameuse timeline en modèle (@wikialine pour le codage du modèle et moi pour les tables associées et l'architecture générale - voir ici, ici ou ici). A aucun moment on ne se pose alors le choix de barres ou de lignes. Le déploiement a lieu en 2012. La question du choix d'histogrammes en barres ou de courbes en lignes ne s'est posée qu'en 2014 quand @Carfois a créé le Modèle:Graphique démographique. Les barres ont alors été justifiées par le fait que la population est arrêtée à la date du 1er janvier et que l'on ne peut pas admettre des lignes quand on n'a pas de données. Mais ce nouveau modèle ne s'appuyant pas sur des modèles de données facilement automatisables, n'a pas rencontré de vif succès (hormis pour certaines intercommunalités où les données continuent à être actualisées à la main). Et lorsque fin 2016, avec @Hexasoft, on passe des modèles aux modules, on ne se pose pas non plus la question. L'idée de stocker les données sur Commons est formulée par @Zolo dès 2017.

Dans cette page de janvier 2017 sur les chantiers futurs, une courbe d'évolution des densités (utilisée d'ailleurs dans certains articles) est faite avec des lignes (utilisant la timeline) et cela n'a rien de choquant.

La difficulté actuellement est que tout le monde a en tête cette visualisation en barres, ce qui rend difficile tout recul par rapport à une autre représentation.

Noter aussi que sur cette courbe de densités, on a une représentation de plusieurs entités/communes/divisions sur le même graphique, ce qui permet d'avoir une vision comparative immédiate. Avec des barres, on ne peut avoir ce genre de représentation. Si avec ce nouveau module on peut introduire une option/fonction qui permette un affichage simultané de plusieurs modèles de données et donc la représentation de plusieurs courbes (c'est donc une question que je pose à @Zolo), je crois qu'il n'y a pas photo, il faut passer aux courbes en lignes.

Cordialement.Roland45 (discuter) 10 mars 2021 à 15:20 (CET)

Superposition de deux courbes

Pour l'instant le module ne permet de générer qu'une courbe par graphique, mais permettre plusieurs courbes ne devrait pas être trop compliqué. --Zolo (discuter) 10 mars 2021 à 16:16 (CET)

On pourrait pour le coup afficher simultanément (avec des couleurs différentes) : commune, département et France métro. Ce serait vraiment fort, mais se pose alors la question des échelles qui peuvent ne pas être les mêmes. Il faudrait dès lors se limiter à deux courbes avec une échelle à gauche et une à droite. J'admets que cela se complique. Pour les densités, on n'avait pas ce pb puisqu'il s'agit d'un nombre sans dimension ou tout au moins dont l'échelle peut être commune à toutes les divisions. Dans les sites démographiques, quand il y a un affichage simultané, c'est en général des divisions de même niveau (pays, région, district, communes, etc), ce qui règle ce pb des échelles.Roland45 (discuter) 10 mars 2021 à 16:22 (CET)

Ok @Roland45 pour des courbes, je n'insiste pas et je jette l'éponge. Je suis trop scientifique. Et je comprends qu'il faut sacrifier l'exactitude au profit de la simplification de la programmation. Mais je persiste à penser que relier les deux points 1954 et 1962 sur le graphique d'Antony (ce n'est qu'un exemple) sera une horreur vis-à-vis de la réalité. Bien cordialement tout de même. AntonyB (discuter) 10 mars 2021 à 17:42 (CET)

@Roland45 utiliser deux échelles différentes semble techniquement possible ([2]) mais ça a l'air un peu plus compliqué à mettre en oeuvre avec les modules actuels. Je pourrai essayer de regarder.

@AntonyB on peut aussi ne montrer que les points sans la ligne lorsqu'il y a trop d'écart entre certaines années (soit en le précisant dans l'appel au modèle de l'article, soit programmatiquement, on définissant un écart maximal pour tracer la courbe). -Zolo (discuter) 10 mars 2021 à 18:17 (CET)

Cas des plages de données manquantes

@AntonyB et @Zolo Pour le cas de l'Abergement-Clémenciat où les données sont manquantes entre 1800 et 1860, il suffit de commencer le module de données à 1860. A quoi nous sert cette donnée isolée ? A rien. Ne pas oublier que les informations doivent être pertinentes. Là ce qui est pertinent est de commencer en 1860. Ce n'est pas parce qu'on a l'information qu'il faut automatiquement l'utiliser, au pire on peut la citer dans le texte, mais cela n'apporterait rien.Roland45 (discuter) 10 mars 2021 à 18:58 (CET)

@AntonyB et @Zolo Je confirme que l'information n'était pas pertinente pour l'Abergement-Clémenciat pour la bonne et simple raison que la commune n'a été créée ... qu'en 1857 ! Les deux points dans le tableau de l'EHESS ne signifient pas données manquantes, mais commune n'existant pas. ET je pense que cela doit être le cas pour toutes les grandes plages manquantes.Roland45 (discuter) 10 mars 2021 à 19:06 (CET)

@Roland45 ok effectivement s'il y a un long trou dans les données, se restreindre aux données les plus récentes dans un graphique semble raisonnable. En revanche, dans le cas où les données sont fiables et sans erreur de périmètre géographique, je pense qu'il est intéressant de les afficher dans le tableau (ça peut donner une idée de l'ancienneté de l'urbanisation par exemple).

Du coup je ne comprends ce que signifient les 232 habitants de l'Abergement-Clémenciat en 1793. La fiche de l'EHESS mentionne des changements de limites administratives, mais ça ne permet pas vraiment de comprendre ce qui est pris en compte. Pour le module, il n'y a pas moyen de savoir quelles données sont justes ou pas. Se baser uniquement sur les dates ou les écarts de dates ne me parait pas très rigoureux. Dans un monde idéal, il faudrait ajouter une colonne aux fichiers de données pour préciser pour chaque années les limites géographiques prises en compte. Mais ça ne me parait pas vraiment envisageable à court terme. Y-aurait-t-il donc un moyen d'identifier les données problématiques ? -Zolo (discuter) 10 mars 2021 à 20:44 (CET)

@Zolo Concernant L'Abergement-Clémenciat, la fiche de l’EHESS est très explicite dans la section « territoire communal ». En 1793, seule la commune de L'Abbergement existe. La population de 232 habitants correspond donc à celle de cette commune. Celle-ci absorbe Clémenciat entre 1795-1800, puis est réunie entre 1795-1800, (avec Sulignat) à Châtillon-sur-Chalaronne. La commune actuelle est finalement créée en 1857, par scission de Châtillon-sur-Chalaronne. Ce texte devrait donc être mis en complément des tableau et graphique.

De même que pour Châtillon-sur-Chalaronne, on devrait avoir un texte explicitant l’histoire du territoire et donc les variations de population :

• absorbe entre 1790-1794, Fleurieux
• absorbe entre 1795-1800, L'Abergement-Clémenciat / Sulignat
• cède en 1809, Sulignat
• absorbe en 1837, Relevant
• cède en 1846, Relevant
• cède en 1857, L'Abergement-Clémenciat
  

On peut d’ailleurs voir à cette occasion qu’on a la même situation de commune disparue sur une plage donnée pour Relevant ou Sulignat.

Il serait effectivement possible de faire des bots pour :

• détecter les plages où la commune n’existe pas en tant que telle, par balayage des fiches de l’EHESS (pas très compliqué, mais un peu long) ;
• écrire un texte automatique sur l’histoire des communes à partir des infos des fiches EHESS pour celles où il y a eu des scissions ou absorptions (relativement complexe, car il y a énormément de situations différentes).

Mais a priori, je pense qu’il y a d’autres tâches plus prioritaires. Disons qu’on peut les inscrire dans une liste des tâches à faire. Cordialement.Roland45 (discuter) 11 mars 2021 à 09:37 (CET)

Ok ça me gène quand même un peu qu il y ait des données incorrectes dans nos tables (labergement clemenciat 1793) et que cela ne soit pas indiqué dans les donnes elles mêmes, uniquement, et de manière indirecte dans la base de données externe d'origine. Mais effectivement on peut trouver on peut imaginer des test de cohérence pour améliorer ça dans le rendu Wikipédia final. Zolo (discuter) 11 mars 2021 à 18:36 (CET)

@Zolo Bon, je suis sur plusieurs chantiers en même temps, mais je n’oublie pas celui des tables sur Commons. J’ai fait une petite analyse (avec un bot spécial dédié à la tâche, des 500 premières tables de Cassini (il y en a quand même près de 35 000 !).

Sur ces 500 premières tables, il y en a 28 qui ont des données manquantes (soit parce que la donnée est de fait manquante, soit parce qe la commune n’existe pas à la date de tel ou tel recensement). Parmi celles-ci :

• 22 sont des communes qui ont été créées après 1793. Les données en place dans les modules ne commencent semble-t-il qu’à la date de création, donc pas de problème ;
• 4 ont des données manquantes (Saint-Georges-sur-Renon, Massieux, Rancé (Ain) (ce serait bon de l’indiquer quelque part) ;
• 1 a un recensement où elle n’existe pas (en 1841), avec en outre beaucoup de changements (Relevant) ;
• 2 ont une problématique similaire à L'Abergement-Clémenciat : Bey (Ain) et Sulignat

Par ailleurs, il y en a … 118 qui ont connu un changement de territoire (cession ou absorption) conduisant donc à des sauts du graphique dans un sens ou dans l’autre! Ce sont souvent des très petites communes qui sont absorbées et les écarts ne sont pas toujours visibles sur les graphiques. Mais cela devrait être mis quelque part dans le texte.

Je pense que dans un premier temps, il est essentiel de s’assurer que :

• toutes les communes qui ont été créées après 1793 aient bien un commencement des données à la date de création ;
• les tables soient modifiées pour éviter des cas comme L'Abergement-Clémenciat, Bey (Ain) ou Sulignat.

Pour les autres (cessions, absorptions), il faudrait l’ajouter dans le texte de l’article.

Tout ça pour dire que … ce n’est pas gagné !! Cordialement.Roland45 (discuter) 24 mars 2021 à 17:10 (CET)

Exemple d'application de graphe multicourbe à une seule échelle

Sur cette page, on peut voir l'évolution de la population du Maroc avec une répartition urbain/rural (je passe sur l'approximation du tableau sur l'absence de différenciation entre données de recensement et projections). La représentation en 3 courbes se superposant urbain/rural/total serait intéressante car elle mettrait en lumière immédiatement l'inversion urbain/rural dans les années 1990. Une seule échelle est pour le coup nécessaire. De multiples autres exemples peuvent être trouvés.Roland45 (discuter) 12 mars 2021 à 10:25 (CET)

Un autre exemple avec ce graphe présentant les évolutions comparées des populations des grandes régions de Belgique.Roland45 (discuter) 15 mars 2021 à 18:27 (CET)

Tables

Départements

Bon, je me suis remis sur les tables, non sans mal. Le bot de création marche bien, mais je me heurte à un pb de syntaxe que j'avais déjà rencontré dans le passé concernant le descriptif en langue étrangère. le message d'erreur est Le paramètre « description » doit être un objet qui fait correspondre des codes de langue valides à des chaînes sur une ligne sans tabulation ni espaces à la fin, par exemple { "en":"String in English", ... } et c'est imparable, tant que la syntaxe n'est pas bonne, la table de se charge pas, c'est sévère et particulièrement énervant. Il y a le pb des langues qui se lisent de droite à gauche où il est difficile de voir si une tabul ou un espace s'est inséré, mais je ne crois pas que ce soit cela. Le liste des tables pour les départements est ici: Commons:WikiProject Tabular data/FR départements

Les liens rouges correspondent à des tables qui n'ont pas été chargées. Si je continue à buter sur ce pb, je crois que je vais réduire drastiquement le nombre de langues et ne conserver que celles que nous pouvons appréhender visuellement. Il y en a actuellement 88 ! Il suffit d'ouvrir le code de la table pour les voir.Roland45 (discuter) 11 mars 2021 à 15:26 (CET)

Bon, ça y est. C'était la bachkir qui me plantait! Je doute qu'il y ait d'autochtones de Bachkirie qui s'intéressent à nos populations, mais c'est en tout cas fait. J'ai dû reprendre aussi les tables à cause d'un décalage dû à la Corse. Il reste uniquement à actualiser les 10 premières avec les données de 2018. J'espère qu'avec les communes cela ne va pas être aussi galère, sinon on n'est pas sortis de l'auberge.Roland45 (discuter) 11 mars 2021 à 18:10 (CET)

Top. Étant donné que les données ne sont accessibles que pour les gens qui savent où chercher et que le lecteur lambda devrait generalement avoir accès aux donnees que retraitees et mise en forme par des modèles, je pense qu on peut ne pas être trop exigeants sur les traductions si c'est trop casse tête. Zolo (discuter) 11 mars 2021 à 18:40 (CET)

 Roland45 et Zolo : Simple question, pour le Rhône, ne serait-il pas plus pertinent de mettre Q18914778 plutôt que Q46130 ? À l'instar de ce qui a été fait avec Module:Données/Rhône (département)/évolution population et Module:Données/Circonscription départementale du Rhône/évolution population ?

Cordialement, Jessy ^Oui ? 15 mars 2021 à 17:21 (CET)

Arrondissements

@Zolo et @JessydeVilly En fait cela se complique sacrément. J'ai toujours ce problème de langues (j'ai directement supprimé le farsi, l'arabe et le basque), mais outre le fait que cela plante encore sur des bricoles de description pour certaines entités, avec les arrondissements une nouvelle difficulté apparaît : les données 1968 à 1999 qui sont obsolètes. J'avais initialement récupéré les données des modules de données actuels (valeur des populations et références). Mais le problème c'est que ces données varient ... chaque année, car elles sont établies sur une géographie en vigueur à une date donnée. L'année suivante, la géographie peut avoir changé et donc les données aussi. Avec un exemple, on comprend mieux : pour l'arrondissement de Belley, on a actuellement dans l'article WP 65 222 habitants, mais si on regarde l'Insee (ici), on a en fait ... 72 241 habitants !! Simplement parce que les données proposées aujourd'hui par l'Insee sont établies à périmètre géographique identique, dans la géographie en vigueur au 01/01/2019, alors que les nôtres sont dans une géométrie bien antérieure. Je l'avais d'ailleurs déjà signalé antérieurement en écrivant « sources Insee antérieures à 2006 obsolètes. Pas trouvé l'équivalent ». Je pense qu'il faudrait pouvoir mettre quelque part cette phrase en note. A réfléchir.
Dans l'immédiat je vais peut-être passer à une autre division.Roland45 (discuter) 12 mars 2021 à 18:56 (CET)

@Zolo Voilà, c'est fait. Le récap des tables des arrondissements est ici. En fait concernant la problématique soulevée ci-dessus, il suffira de mettre un texte explicatif dans chaque article d'arrondissement (cela peut être fait avec un bot dédié). Ce n'est pas la peine d'essayer d'introduire un texte en note dans le modèle. Cordialement.Roland45 (discuter) 13 mars 2021 à 16:25 (CET)

@Roland45 merci, en revanche, je pense que si on veut ajouter des commentaires sur les données fournies par le modèle, il faut le faire dans le modèle lui même. Si on le fait dans du texte à l'extérieur, ça risque d'être compliqué de tenir à jour en cas de modifs dans le modèle / mise à jour des données. --Zolo (discuter) 14 mars 2021 à 11:09 (CET)

Cantons

Les tables des cantons sont regroupées sur cette page.

Pour info, il y a eu des changements de noms en 2020 sur une vingtaine de cantons. Dans la description, j'ai laissé l'ancien nom, car cela me posait un pb pour les autres langues. A la limite cela pourra être rectifié à la main pour la description française. En tout état de cause le titre de la table et les données restent bien entendu non impactées par ce changement de nom.Roland45 (discuter) 15 mars 2021 à 11:43 (CET)

 Roland45 et Zolo : Cela commence à prendre forme.

Je continuerais à suivre les discussions mais ne serait malheureusement pas disponible pour contribuer jusqu'en mai (les examens me prenant tout mon temps).

Cordialement, Jessy ^Oui ? 15 mars 2021 à 16:45 (CET)

 Roland45 : y a un souci sur la Dordogne avec 3 noms de cantons tronqués « ut-Périgord noir (2405) », « le-Loue-Auvézère (2406) » et « le-Manoire (2407) » au lieu de Haut-Périgord noir, Isle-Loue-Auvézère et Isle-Manoire. Père Igor (discuter) 15 mars 2021 à 16:50 (CET)

@Père Igor Oui. Merci du signalement. Ce n'est rien. C'est simplement dans le code de cette page qu'il y a eu des problèmes. Les tables sont bonnes, ce qui est quand même le principal. Tu peux cliquer sur les liens pour en avoir le cœur net. Je vais corriger. Par contre il y a d'autres problèmes de fond bien plus importants que vais développer ci-après bientôt.Roland45 (discuter) 15 mars 2021 à 17:03 (CET)

@JessydeVilly La vraie vie passe avant Wikipédia. Laisse un peu Wikipédia qui peut attendre et sera encore là à ton retour. Les examens sont plus importants.Roland45 (discuter) 15 mars 2021 à 17:03 (CET)

@Père Igor J'ai mis à jour la liste des noms suite au décret de 2021.

@Roland45 Il manque les cantons mahorais. Et oui, Wikipédia sera toujours là dans quelques mois.

PS : pour rappel, mon fichier recensant les 2054 cantons est ici.

Cordialement, Jessy ^Oui ? 15 mars 2021 à 17:07 (CET)

@JessydeVilly Je n'ai pas créé les cantons de Mayotte, tout simplement parce que les données de populations diffusées par l'Insee (ici) sont produites « hors Mayotte ». Je pense qu'elles figurent ailleurs mais je n'ai pas cherché.Roland45 (discuter) 15 mars 2021 à 17:50 (CET)

@Roland45 oui, elles sont ici

Cordialement, Jessy ^Oui ? 15 mars 2021 à 18:02 (CET)

@JessydeVilly OK. Merci. Je créerai ces tables quand on aura acté la forme définitive des tables.Roland45 (discuter) 15 mars 2021 à 18:10 (CET)

@Roland45, bonjour j'ai ajouté les liens P4179 (« tableau de population ») depuis les éléments Wikidata correspondant. Hors Mayotte, 4 éléments Wikidata marqués comme cantonss n'ont pas de lien. Un qui est en lien rouge dans ta liste :

• http://www.wikidata.org/entity/Q1727691 canton de Troyes-4

Et 4 qui ne figurent pas sur la liste :

• http://www.wikidata.org/entity/Q96461686 canton de Chartres-Sud
• http://www.wikidata.org/entity/Q20671686 canton du Nord-Libournais
• http://www.wikidata.org/entity/Q2430919 canton de Saint-Pierre-1 --Zolo (discuter) 16 mars 2021 à 11:36 (CET)

@Zolo Le point sur ces anomalies :

• canton de Troyes-4 : j'avais zappé ce lien rouge. Je vais corriger. - Fait.
• canton de Chartres-Sud : il s'agit d'un ancien canton qui n'est plus en vigueur au 1er janvier 2021
• canton du Nord-Libournais : la table existe bien (ici)
• canton de Saint-Pierre-1 : la table existe aussi (ici)

Il y a peut-être un pb dans les propriétés de ces entités WD.Roland45 (discuter) 16 mars 2021 à 16:39 (CET)

Supprimer la convention d’affichage pour faciliter les actualisations

Je reviens sur la convention d’affichage qui pose un problème majeur pour les actualisations (mais pas que).

Principes de la convention
Dans les actuels modules de données, on peut lire : Par convention, on a retenu d'afficher dans Wikipédia :

Communes	Jusqu'en 2004 : tous les recensements exhaustifs À partir de 2004 : Pour les communes de moins de 10 000 habitants : tous les recensements exhaustifs + la dernière population légale publiée (n) Pour les communes de plus de 10 000 habitants : 2006, 2011, 2016, etc + la dernière population légale publiée (n)
Autres divisions	À partir de 2004 : les recensements 2006, 2011, 2016, etc + la dernière population légale publiée (n).

Affichage avec le module:Population de France et les modules de données sur Wikipédia
Pour permettre un affichage en cohérence avec cette convention, un paramètre a été ajouté dans chaque ligne des modules de données : ["recens"] = true, on affiche, ["recens"] = false, on n’affiche pas.

Cela simplifie l’affichage, mais ne simplifie pas l’actualisation des modules de données, puisqu’il faut systématiquement revenir sur la donnée de l’année n-1. L’actualisation de cette donnée de l’année n -1 est relativement complexe. On pourrait croire qu’il suffit de connaître l’année du premier recensement (au moins pour les communes de moins de 10 000 habitants), mais c’est oublier qu’en fait si le premier recensement ne change pas, le calendrier de recensement lui change … chaque année, pour la bonne raison que chaque année certaines communes passent le seuil des 10 000 habitants. De sorte qu’il faut également revenir éventuellement sur le paramètre ["recens-prem"], auquel est associé le paramètre ["source_collecte"]

Affichage avec le module:Population et les tables de données sur Commons
Dans les tables de données sur Commons, il n’y a plus de paramètre recens, ni d’ailleurs de recens-prem, ni de source-collecte, ni d'ailleurs de texte relatif à la convention d'affichage.

Ainsi dans module:Population/France, la donnée est affichée en fonction du paramètre relatif à la méthode : si méthode = Q39825 (recensement), on affiche, sinon on rejette (si c’est une interpolation ou extrapolation)

Pour les communes de plus de 10 000 habitants (method == "Q98415788"), on affiche les données 2006, 2011, 2016. Petite remarque au passage : peut-être qu’il conviendrait de faire un test modulo 5 et non un test sur des années explicites, sinon tous les 5 ans (à partir de 2021), il faudra corriger le code du module), mais là n’est pas mon questionnement majeur.

Pour les divisions supra-communales, je n’ai pas vu explicitement de cas traité, donc je suppose que pour afficher les années 2006, 2011, etc des cantons, arrondissements et autres divisions supra, le module testera la méthode et si on a method == "Q98415788", l’affichage sélectif sera actionné.

Premier problème (divisions supra-communales) :
Si le test se fait sur la méthode pour toutes les divisions supra-communales, il faut que l’on ait systématiquement "Q98415788" dans la colonne méthode des tables de données (correspondant à P459). Or je n’avais pas tilté sur cet aspect là. Dans les tables que j’ai créées, il aurait fallu que je mette systématiquement "Q98415788" alors que j’ai mis Q39825 (recensement de la population)!

Il faudrait donc que je reprenne toutes les tables que j’ai faites jusqu’à présent. Mais à la limite, ce n’est pas le plus grave, ce n’est que du temps à passer (mais le temps est quand même compté !).

Deuxième problème (toutes divisions) :

Sauf erreur de ma part, je n’ai pas vu dans la fonction p.keepval du module, de code permettant d’afficher systématiquement la dernière année connue, ce qui veut dire qu’une commune de moins de 10 000 habitants dont la dernière année n’est pas un recensement exhaustif (Q39825), ne verrait pas les données de sa dernière année affichée. De même pour les communes de plus de 10 000 habitants dont le dernier millésime ne serait pas 2016.

Bon, cela peut être résolu par un bout de code à rajouter.

Sourcage de la méthode
Le sourcage de la méthode est fait dans les modules de données via le paramètre source-collecte avec ce lien https://www.insee.fr/fr/information/2383410 qui est un lien générique vers différentes pages. Bon, déjà il faut savoir vers quel lien aller, à savoir : Millésime de collecte des communes pour la campagne 2021.

Pourquoi n’est-il pas mis en dur dans le module de données ? Tout simplement parce qu’il change chaque année ! Et c’est précisément là un problème de fond. Parce qu’avec ce lien on ne peut sourcer que sur la base du dernier calendrier connu, à savoir celui tenant compte de la dernière situation en termes de population > ou < à 10 000 habitants. Rien ne dit donc si l’affichage tel qu’il résulte du module est correct.

Pour les tables de données sur Commons, là le problème est réglé puisque la méthode n’est pas sourcée. Le seul lien donné vers une source est celui de la page Insee relative à la population de tel ou tel millésime.

Actualisation des données
1. Avec les modules de données
C’est là qu’est le fond du problème. Actuellement il n’y a qu’une seule personne en capacité d’actualiser les modules de données, moi en l’occurrence. Les principales difficultés étant la gestion des noms de divisions qui changent souvent (sous forme codée si possible, car avec IE en VBA, on ne peut pas admettre en url des accents), la gestion de l’année de référence du découpage territorial (qui est en général pas la même que le dernier millésime du COG) et surtout ce fameux calendrier de recensement pour afficher les bonnes données selon la convention.

Or un système reposant sur une seule personne est ultra-fragile. J’avais cette année dans l’intention de publier le classeur Excel et le code VBA associé ainsi qu’un mémo des différentes tâches à faire. Mais cela m’est apparu relativement complexe à expliquer. Si demain je disparais, je doute que le système subsiste sans modification de fond pour faciliter cette actualisation, voire qu'il subsiste tout court. Et on reviendrait brutalement aux actualisations manuelles.

2. Avec les tables de données sur Commons
Là les choses se simplifient sur certains aspects. On n’a plus à gérer les noms de divisions, puisque le titre ne se réfère qu’à l’élément Wikidata. Il n’y a plus qu’à associer la base de données de population à la base des noms WD des communes du COG. Mais il reste encore … ce satané paramètre qualifiant la méthode obtenue à partir du calendrier du recensement.

On est donc obligés encore de passer par des étapes intermédiaires pour arriver auxdites tables.

Seule solution : supprimer le critère « méthode » et donc la convention d’affichage.
Mais il y a aussi d’autres raisons qui militent en ce sens :

• Je rappelle que toutes les données publiées par l’Insee sont authentifiées chaque année par un décret. Elles sont donc légales. Il n’y a donc aucune raison de n’afficher que certaines données au motif que certaines seraient issues d’un recensement exhaustif et pas d’autres (je dis seraient, car … rien ne le prouve – cf topo sur les sources ci-dessus)
• Ce paramètre est incompréhensible pour tout autre pays. Il l’est déjà pour le lecteur et le contributeur de base français (même pour celui un peu plus expert qui a compris tous ces liens vers Wikidata), alors tout étranger se demandera pourquoi la France n’affiche qu’une partie des données publiées par l’Insee. Or je rappelle que les tables sont sensées être utilisables par tous.
• Les tables des autres pays n’auront pas ce paramètre, donc de notre côté on peut très bien s’en passer.

La solution est donc : Supprimer la colonne méthode de détermination. L’actualisation est immédiatement ultra-facilitée, car on n’a plus à mettre en correspondance que deux bases : la base de population de l’Insee publiée le 1er janvier et la base des identifiants WD (la requête existe), le lien se faisant via le code Insee. Et l’actualisation peut ensuite être faite très simplement par n’importe quel outil en VBA ou autre langage.

Je ne continuerai sur le sujet (à savoir création des tables des communes (près de 35 000) et correction des tables déjà créées (environ 2500) que quand on aura acté ce principe qui me parait être la seule solution.

@Zolo Peux-tu créer une nouvelle version du module en désactivant la fonction p.keepval (ce qui devrait, je pense, permettre d'afficher toutes les données) et créant des liens sur Wikidata pour 2 ou trois entités de chaque division dont on a des tables (commune, canton, arrondissement, département)? Cela nous permettra de voir ce que cela donne et de présenter au projet:Communes de France ce vers quoi on va.Roland45 (discuter) 15 mars 2021 à 17:32 (CET)

@Roland45 J'ai enlevé pour l'instant le filtrage des données français. Mais dans l'absolu, le module devrait conserver la possiblité de sélectionner certaines données. Deux exemples :

• sur une article historique, on peut ne vouloir afficher les données que d'une certaine période.
• sur Taipei commons:Data:Taipei Population.tab fournit des données mensuelles. Dans un tableau, des données annuelles paraissent généralement suffisantes, mais peut-être pas dans 100% des cas.

La meilleure solution serait de laisser le modèle ou la fonction Lua appelante définir les éventuels filtres et paramètres de mise en forme.

Je n'ai pas trop d'idée sur l'exclusion ou non de certaines années pour la France. En revanche, si c'est faisable, je pense qu'il est bon de conserver sur Commons les infos sur la méthode de détermination. Ca n'oblige pas à les utiliser sur Wikipédia. On peut imaginer d'autres exemples, on connaitre la méthode de détermination est importante, par exemple un fichier qui contiendrait aussi des projections sur les populations à venir. Celles-ci ne seraient pas forcément inintéressantes, mais il faudrait pouvoir les différencier des chiffres réels (Utiliser : "méthode : projection" serait plus fiable que de vérifier que de simplement regarder la date. Si le fichier est un peu ancien, il peut y avoir de vieilles prévisions qui concernent ce qui est maintenant du passé :). --Zolo (discuter) 15 mars 2021 à 21:12 (CET)

@Zolo Pour le filtre, je suis d'accord sur le fait qu'on peut laisser un filtre pour les immenses bases (au mois par exemple). Mais avec une courbe et non des histogrammes, on n'a plus la problématique des chevauchements de barres s'il y en a trop pour une échelle donnée, puisque l'affichage est au point (les points étant reliés ou non). Le problème de fond est par contre l'affichage du tableau quand il y a trop de données. Mais j'y reviendrai.

Pour la méthode de détermination de données française, je maintiens qu'elle ne doit pas être maintenue pour les raisons déjà explicitées et résumées ci-après :

• La donnée n'est pas sourcée, ce qui est quand même ennuyeux ;
• si elle est vrai pour 99 % des communes, elle est erronée pour certaines (du fait de ces changements de seuils), ce qui est encore plus ennuyeux ;
• elle pose des difficultés de mise à jour des tables, ce qui est rédhibitoire ;
• il s'agit d'un TI, car tu ne trouveras nulle part l'information qui la source, puisqu'elle est obtenue automatiquement par des méthodes tarabiscotées et particulièrement sujettes à caution (puisqu'on utilise le calendrier des recensements à venir pour les 5 prochaines années - 2021-2026 pour cette année -, pour en déduire à rebours les recensements antérieurs et leur nature), donc rédhibitoire. On peut toujours obtenir des informations par des méthodes indirectes, mais à condition de pouvoir sourcer in fine le résultat ;
• elle est inutile, puisque toutes les populations publiées annuellement depuis 2006 sont des populations légales. Il n'y en a pas une de plus importante qu'une autre.

Cordialement.Roland45 (discuter) 16 mars 2021 à 16:14 (CET)

Infobulles dans le graphique

@Zolo Dans de très nombreux sites présentant des courbes démographiques, l’information apparaît en infobulle, ce qui est visuellement agréable et permet de s’affranchir de l’affichage du tableau des données. Voici quelques exemples :

• la Belgique ;
• le Royaume Uni ;
• Eurostat, ex avec l’Autriche, la Belgique, la Suisse ;
• la Nouvelle-Zélande, etc.

Penses-tu pouvoir ajouter ce type d’affichage ? Ce serait un plus énorme car on pourrait dès lors s’affranchir d’afficher le tableau qui est un peu lourdingue et qui occupe, pour les petites communes, souvent plus de place que le reste du texte ! Merci.Roland45 (discuter) 16 mars 2021 à 17:17 (CET)

Bonne idée, merci @Roland45. Je plussoie. AntonyB (discuter) 16 mars 2021 à 21:20 (CET)

J'avais un peu regardé mais j'ai l'impression que l'extension graph n'est pas vraiment forte en infobulles. J'essaye de regarder ça un peu plus en détail dimanche, je vais être assez pris jusque là. --Zolo (discuter) 17 mars 2021 à 14:01 (CET)

@Roland45 et @AntonyB les infobulles semblent techniquement possibles ([https://vega.github.io/vega-lite/docs/tooltip.html Le problème est que cela ne parait pas prévu par Module:Graph qui sert d'intermédiaire entre Module:Population et l'extension Vega. Il doit être possible d'adapter Module:Graph en ce sens, mais c'est assez technique, et a première vue, je ne me sens pas trop capable pour l'instant. A tout hasard, je pingue user:Mps qui a créé le module.

Module:Diagramme permet en revanche les infobulles, mais pour des histogrammes en barre. Il ne fonctionne par pour les courbes. --Zolo (discuter) 21 mars 2021 à 12:07 (CET)

Merci @Zolo, à suivre donc ! Bien cordialement. AntonyB (discuter) 21 mars 2021 à 12:10 (CET)

@Zolo Merci de ta recherche. Le pb est que Mps n'a plus contribué depuis 2018. Je doute donc qu'il intervienne sur le sujet. Ne faudrait-il pas poser la demande ailleurs, bistro du projet Scribunto ou ailleurs ? Cordialement.Roland45 (discuter) 21 mars 2021 à 12:16 (CET)

Il est encore un peu actif sur dewiki. Mais effectivement, je vais essayer de trouver un endroit où poser la question. C'est un peu spécialisé donc peut-être pas sur frwiki, éventuellement sur stackoverflow. -Zolo (discuter) 21 mars 2021 à 14:25 (CET)

Mise à jour ?

Il faudrait mettre dans l'article associé à cette PdD d'où les données sont prises, et comment elles sont mises à jour dans le modèle (lecture dynamique d'une source de donnée ? bot ?). Je n'ai pas été voir le source du modèle, ni lu les discussions ci-dessus, et on ne voit pas clairement les réponses à ces deux questions. Je débarque ici à cause de ceci et cela : visiblement les populations commencent à être obsolètes, et je n'ai aucune idée de quoi répondre à l'IP. Prenons donc l'exemple de Pau : comment mettre à jour la population ? (on est bientôt en 2024, et il s'agit de mettre la population avec le nombre de 2021 !) Jean-Christophe BENOIST (discuter) 30 décembre 2023 à 12:33 (CET)

 Jean-Christophe BENOIST : visiblement, l'IP veut aller plus vite que la musique. Les mises à jour commencées par notamment JessydeVilly (d · c · b) sont en cours mais ça prend du temps de mettre à jour des dizaines de milliers d'articles et ou de modèles démographiques. Wet Hennessy, comme on dit du côté de Cognac. Cordialement. Père Igor (discuter) 30 décembre 2023 à 12:43 (CET)

Mais peut-on mettre dans l'article l'architecture informatique de mise à jour du modèle ? Pour comprendre, et essayer de savoir quelle est la "vitesse de la musique" (3 années de retard, dirait-on ?). Ou la décrire ici, et j'essaierais de la formaliser dans l'article. Quelle base de donnée est utilisée ? Comment est-elle utilisée ? A quel rythme ? Où puis-je voir ces informations ? Jean-Christophe BENOIST (discuter) 30 décembre 2023 à 12:55 (CET)

Bonjour @Jean-Christophe BENOIST,

La base de données utilisée est celle de l'Insee, disponible ici.

Actuellement, la vitesse du bot est de 15 modifications par minute. Pau sera donc actualisée cet après-midi autour de 17h30.

Concernant les données, il est expliqué sur le site de l'Insee que les données millésimées 2021 entrent en vigueur au 1^er janvier 2024. Les chiffres 2021 sont donc les chiffres de population officiels en 2024 (le décalage de 3 ans étant lié à la méthode de recensement de l'Insee).

Cordialement, JessydeVilly ^Oui ? 30 décembre 2023 à 13:05 (CET)

Voilà ! Parfaites explications, merci ! Je vais essayer de mettre cela dans l'article de cette PdD (ou même carrément dans les modèles) pour ne plus se poser ces questions. Jean-Christophe BENOIST (discuter) 30 décembre 2023 à 13:08 (CET)

L'information est déjà présente dans la documentation des modèles {{Population de France/dernière pop}} et {{Population de France/dernière année}}.

Cordialement, JessydeVilly ^Oui ? 30 décembre 2023 à 13:16 (CET)

@Jean-Christophe BENOIST Tu as la réponse à tes questions dans cette page décrivant le système d'information territorial des communes de France (je pense en tout cas) et surtout dans les pages détaillées figurant dans la palette en bas de page, comme celle-ci sur les mdoèles démographiques. Il y a également une page d'actualisation par année comme celle-ci pour 2024. @JessydeVilly a repris ce travail de Bénédictain auquel je m'attelais jusqu'à il y a encore 3 ans. Bravo. Mais malgré l'énorme automatisation, cela reste un système fragile ne reposant que sur très peu de bonnes volontés. Pour ce qui n'est pas automatisé, il y a pas mal de taf pour ceux qui veulent se lancer, voir la page de 2024.Roland45 (discuter) 30 décembre 2023 à 17:41 (CET)

Je veux bien participer, si on me met sur les rails d'une tâche précise. Jean-Christophe BENOIST (discuter) 30 décembre 2023 à 17:48 (CET)

@Jean-Christophe BENOIST La première approche est de dérouler la page 2024 et voir si les tâches sont faites ou non.

Prenons la première section (Événéments 2024 / communes nouvelles), dans la première ligne, on a la création de la commune nouvelle Bazeilles, avec disparition de la commune La Moncelle. Il faut donc examiner les entités supracommunales (dans l'ordre des colonnes : Canton, Arrondissement, etc) et voir si La Mancelle figure encore dans la composition de l’entité, ce qui donne :

• Supprimer La Mancelle dans Canton de Sedan-3, Arrondissement de Sedan, Ardenne Métropole, Aire d'attraction de Sedan, Unité urbaine de Sedan.
• pour le département, à savoir Liste des communes du département des Ardennes, l’actualisation est automatique
• pour la région, l’article Grand Est n’est pas concerné.

Une fois la tâche faite, ce serait bien d’ajouter une case en bout de tableau avec la mention {{fait}}

Sinon, tu as raison, on peut faire un mémo sur la PDD du projet:Communes de France, pour rappeler l'existence de cette page et la méthodo (en mentionnant par exemple aussi la page des ressources Insee), la bible en la matière.Roland45 (discuter) 31 décembre 2023 à 10:42 (CET)

J'ai mis la "page 2024" dans ma liste de suivi. Je vais voir "comment cela se passe". Jean-Christophe BENOIST (discuter) 31 décembre 2023 à 12:00 (CET)

Populations légales 2021 extrapolées

Bonjour,
Dans la mesure où les populations légales 2021 sont extrapolées du fait de l'absence de recensement 2021 en raison de la crise sanitaire, ne faudrait-il pas que ce fait soit indiqué ? Dans mon patelin de moins de 10 000 hab par exemple, le maire est très fâché (article dans la PQR) que sa commune affiche officiellement une pop en baisse alors que ses indicateurs manifestent le contraire (4 créations de classes, etc.)…  — 🦊 jilucorg converser, le 17 janvier 2024 à 17:22 (CET)

 Jilucorg : bonjour. J'ignore quel est ton patelin mais si on applique dans la section Démographie le modèle:Population de France/section, cela indique « L'évolution du nombre d'habitants est connue à travers les recensements de la population effectués dans la commune depuis 1793. Pour les communes de moins de 10 000 habitants, une enquête de recensement portant sur toute la population est réalisée tous les cinq ans, les populations légales des années intermédiaires étant quant à elles estimées par interpolation ou extrapolation », qui est la formule qui me semble appropriée (voir exemple : Ribérac#Démographie). Il est vrai que cela conduit souvent à des divergences, parfois en défaveur, parfois en faveur, par rapport à la réalité ou au ressenti local. S'il y a des doléances à avoir, ce n'est pas vers Wikipédia qui ne fait que relater ce qu'indiquent les sources officielles. Le problème, si problème il y a, concerne l'Insee. Et de ce que je sais, il est déjà difficile à certaines communes de prévoir le nombre d'agents recenseurs nécessaire pour un recensement exhaustif tous les 5 ans. Père Igor (discuter) 17 janvier 2024 à 18:49 (CET)

Merci de ta réponse (rapide), @Père Igor,
il me semblait que le cas de 2021 était particulier, ce qui à mes yeux était confirmé par le document cité en lien : je n'ai pas compris que cette année soit une année intermédiaire, au vu du texte de l'INSEE : Du fait de la crise sanitaire de la Covid-19, l'enquête annuelle de recensement qui devait se tenir en 2021 a été reportée en 2022. L'Insee a adapté ses méthodes de calcul des populations légales pour pallier ce report et continuer à produire des populations légales de qualité chaque année (même texte sur la page des données de mon patelin, où la campagne de recensement a été reportée à cette fin janvier). Mébon, ces choses me sont trop étrangères pour que j'argue davantage , c'était juste histoire de suggérer une note qui aurait signalé cette absence de campagne de recensement pour 2021 et l'extrapolation — contrairement aux apparences pour les pékins comme moi —, pas pour incriminer ce qu'affiche WP, qui est bien sûr conforme aux chiffres officiels !
Bien cordialement, — 🦊 jilucorg converser, le 17 janvier 2024 à 19:45 (CET)