Discussion Projet:Communes de France/Mise à jour automatique de données

Débats : Mise à jour automatique de données

Page de débats sur la mise à jour automatique de données dans les modèles et les articles sur les communes françaises.

Listes de modèles susceptibles d'intégrer des mises à jour automatisées

Modèles de tableaux démographique - Tableaux d’évolution démographique : {{DemogAL}} {{DemogFranceAR}} {{DemogFR}} {{Démographie2}} {{DemogNS}} {{Démographie}} (utilisé aussi en dehors des communes fr:) - Autre tableau : {{Structure de la population}} (utilisé aussi pour commune)

Modèles d'Infobox - Infobox pour communes : {{Infobox Communes de France}} {{Infobox Commune de France}} {{Infobox Commune française}} {{Géo/Fr-Commune}} {{Communefra}} {{Communefra/Corse}} {{Communefra/Guadeloupe}} {{Communefra/Martinique}} {{Communefra/Réunion}} {{Commune française/Mayotte}} {{Comm NC}} - Infobox autres : {{Infobox Région de France}} (si addition automatique des pop...) {{Infobox Département de France}} (si addition automatique...) {{Infobox Arrondissement de France}} (si addition automatique...) {{Infobox Canton de France}} (si addition automatique...)

Les débats

La population communale

Proposition de mode de mise à jour

Proposition 1 - Robot et sous-pages avec modèle Switch

• Création d'une sous-page par département pour récolter les données sur la population. La sous-page de données utilise un {{#switch}} (voir le code en édition).

  Exemple : Utilisateur:Phe/Population 01, les données de pop. pour le département 01

• Adaptation des modèles comme les infobox mais aussi d'autres modèles...

  Exemple : Modèle infobox d'essai, ce qui donne concrètement sur une page la chose suivante Cliquez-ici .

Proposition 2 - Robot et sous-page avec inclusion section

• Création d'une sous-page par département pour récolter les données sur la population. La sous-page de données utilise pour chaque nombre de population de commune une section.

  Exemple : Aucun exemple actuellement, les données de pop. pour le département de l'Ain (01).

• Adaptation des modèles comme les infobox mais aussi d'autres modèles...

  Exemple : Aucun exemple actuellement, ce qui donne concrètement sur une page la chose suivante Aucuns exemples.

Aucun exemple n'est actuellement disponible car il faut préalablement faire activer l'inclusion par section sur wp:fr.

Proposition 3 - Robot et sous-page par commune avec switch et multiple données par entrées

Pour avoir plus de précision sur cette proposition lire les débats plus bas en cliquant-ici.

• Création d'une sous-page par commune pour récolter les données sur la population (année et nombre de la population). La sous-page de données utilise un {{#switch}} (voir le code en édition).

  Exemples : Modèle:Population Évry (Essonne), Modèle:Population Angoulins

• Adaptation des modèles comme les infobox mais aussi d'autres modèles...

  Exemple : Type d'utilisation possible, {{Infobox Communes de France/essai}} (infobox), {{Population Commune de France}} (Tableau démographique). Ces exemples peuvent être testé en plaçant ces modèles sur les pages Angoulins et Évry (Essonne) puis en cliquant sur prévisualiser.

Proposition 4 - Robot et sous-page par département avec switch et multiple données par entrées

Les propositions 1 et 2 fonctionnent, elles sont suffisamment efficaces pour gérer quelques insertions de données par page mais pas suffisamment efficace pour gérer quelques centaines de données par page (cas des listes de communes par département), le temps de sauvegarde est trop long pour être utilisable, la plus inefficace des deux est l'inclusion de section, la sauvegarde d'une page avec 450 données de population est impossible. D'où cette prposition 3 comme alternative possible, plus efficace en terme de charge des serveurs.

• Création d'une sous-page par département pour récolter les données sur la population. La sous-page de données utilise un {{#switch}} (voir le code en édition).

  Exemple : Utilisateur:Phe/Population 01 ter, les données de pop. pour le département du Pas-de-Calais (62)

• Adaptation des modèles comme les infobox mais aussi d'autres modèles...

  Exemple : Type d'utilisation possible, Cliquez-ici.

Contre la mise-à-jour annuelle de la population dans les modèles de tableaux démographiques pour les communes de moins de 10 000 habitants

Je ne m'y oppose pas pour les Infobox puisque cette mise-à-jour annuelle permettrait la présentation de la population de chaque commune avec l'information légale la plus précise au moment de la lecture de la page et que cette information DISPARAITRAIT ensuite chaque année remplacée par la nouvelle population légale l'année qui suit.

MAIS pour les modèles de tableaux démographiques, je suis contre, d'une part parce qu'il est inutile d'avoir des informations année par année (surtout dans les communes de moins de 10 000 ans où il y aurait un surplus d'infos et que les recensements complets ont lieu tous les cinq ans sur ces communes, on aurait donc 1 année sur 5, une information basée sur un recensement et les quatre autres sur des estimations), d'autre part, parce que les estimations des années antérieures seront réactualisées en fonction des recensements futurs pour ces communes de moins 10 000 habitants, il faudrait donc en fait chaque année, procéder ainsi à une mise à jour de plusieurs dernières années en arrière. Je m'explique, une commune de moins de 10000 habitants en forte baisse entre deux recensements (genre 1000 une année et 700 cinq ans plus tard) aura des estimations suivant le deuxième recensement qui suivront la tendance donnée par les deux précédents recensements (genre 650 puis 620...), si cinq ans plus tard, lors du troisième recensement, la population remonte (genre à 800), ces chiffres seront révisées et alors lors de la publication en janvier de l'année X+3 de la population légale de l'année X, les chiffres de la population légale de l'année X-1 changeront aussi pour toutes les communes qui n'ont été recensé qu'en X-2 (recensées de nouveau que durant l'année X+3) et X-3 (recensées de nouveau lors de l'année X+2 mais avec des chiffres non encore publiés). En plus des chiffres de la nouvelle année, les estimations seront donc fausses et à mettre à jour pour 2 communes sur 5 sur une année antérieure et pour 1 commune sur 5 sur deux années antérieures. Bref, pour les modèles démographiques et pour les communes de moins de 10 000, il ne faut garder que les chiffres des recensements ayant lieu qu'une année sur cinq, année différente selon les communes. GabrieL (d) 3 février 2009 à 17:01 (CET)

Population 2006

Issue de la page de discussion du projet commune de France du 1 janvier 2009 J'en ai parlé sur le Bistro, mais finalement ça vous intéresse peut-être : l'INSEE a publié les derniers chiffres de population des communes françaises. Ces chiffres sont repris dans un (gros) [PDF] décret. Vu les nouvelles méthodes de recensement (mise à jour tous les ans), ça risque d'être difficile de rester à jour. Peut-être avec un robot, ou un modèle qui ferait un lien direct vers la page de l'INSEE donnant les chiffres de population (Paris, Fleury-devant-Douaumont...) Seudo (d) 1 janvier 2009 à 09:02 (CET)

Ok, je vois qu'il y a déjà un sous-projet consacré à ce sujet. Je vais voir là-bas... Seudo (d) 1 janvier 2009 à 09:06 (CET)

De ce que j'en vois, le sous-projet concernait le recensement partiel précédent. Y a-t-il eu discussion sur celui-ci ? (j'imagine qu'on ne retient que la « population municipale », donc statistique, et non la « population totale » légale, puisqu'auparavant on retenait la PSDC… Mais cela a-t-il était acté ?) Y a-t-il une page de coordination ? Manuel Menal (d) 1 janvier 2009 à 12:26 (CET)

Par ailleurs, une mise à jour de l'infobox est probablement nécessaire puisque ce concept de « population sans double compte » n'existe plus dans les nouveaux recensements. Mais comme il ne faut pas changer l'intitulé du champ sur les articles où la population n'a pas encore été mise à jour, il faudra probablement rajouter un champ « population municipale » et remplacer sans par ce nouvel intitulé au moment des mises à jour… Bref, on aurait besoin de se coordonner. Manuel Menal (d) 1 janvier 2009 à 12:40 (CET)

Et un robot ne fait pas tout : il y a besoin de modifier les phrases explicatives quand il y en a dans les articles et de mettre à jour les articles sur les départements genre démographie de la Charente. --Rosier (d) 1 janvier 2009 à 12:53 (CET)

En effet, un robot serait sans doute trop compliqué à mettre en place. Mais on pourrait modifier l'infobox pour que le champ "population" ait un lien hypertexte vers la page de l'INSEE contenant le chiffre « légal » : ça paraît facile puisque l'URL est http://www.insee.fr/fr/ppp/bases-de-donnees/recensement/populations-legales/commune.asp?depcom= suivi du code INSEE (déjà présent dans l'infobox). Seudo (d) 1 janvier 2009 à 14:54 (CET)

Es-tu sûr que les chiffres que tu as mis dans démographie de la Charente concernent le 1/1/2009 ?? à mon avis ce sont ceux du 1/1/2006.

Sneaky 013 (d) 1 janvier 2009 à 13:11 (CET)

J'ai corrigé. Ils correspondent effectivement à 2006. Manuel Menal (d) 1 janvier 2009 à 13:17 (CET)

exact, mon erreur vient de ce que ces chiffres sont les chiffres légaux au 1/1/2009--Rosier (d) 1 janvier 2009 à 16:16 (CET)

Je suis très perplexe quant à la dexterité de certains d'entre nous pour la mise à jour de population. Des changements ont, semble-t-il, déjà été effectués sur les communes de certains départements et il apparaît que ces changements sont aujourd'hui à reprendre. Ne faudrait-il pas plutôt attendre de nous coordonner avant de lancer toute la troupe sur des modifications incertaines.

Personnellement, si les changements sur les infobox me paraissent indiscutablement pertinentes (malgré la mise à jour annuelle), je note cependant qu'elles ne sont pas encore adaptées (le terme sans double compte, si j'ai bien compris, n'est pas approprié).

En ce qui concerne les tableaux de démographie pour les communes, est-ce que les enquêtes annuelles (c'est le terme employé par l'Insee, en fait il s'agit du recensement quinquennal) ne seraient pas plus appropriées. En effet, même s'il ne s'agit pas d'un recensement au sens précédemment donné, ce chiffre n'a-t-il pas plus de valeur que le chiffre 2006 qui n'est (toujours si j'ai bien compris ...) que le résultat d'un calcul ? En plus, cela nous éviterait une mise à jour annuelle sur ce tableau qui deviendrait vite assez lourd au fil des ans et le modèle {{Démographie}} prévoit déjà l'enquête annuelle. Reste évidemment à savoir si ces chiffres resteront consultables au fil du temps sur le site de l'Insee ...

Plus qu'un avis, ce sont des questions que je soumets, et un frein à ce qui me paraît un courant un peu trop rapide. Cordialement, ---- Ikmo-ned (discuter avec) 2 janvier 2009 à 20:07 (CET)

À mon avis, une granularité d'un an est trop faible pour pouvoir saisir facilement l'évolution des données, ce qui est souvent le plus utile. Il va falloir choisir, par exemple, toujours afficher l'année en cours puis tout les cinq ans. Pour la disponibilité des années précédentes, si la proposition ci dessous est adopté, ces données resteront disponibles sur wikipédia. - phe 3 janvier 2009 à 11:21 (CET)

Les chiffres 2006 sont calculés sur la base des recensement partiel de 2004, 2005, 2006, 2007 et 2008, soit cinq ans. On peut dès lors choisir de n'afficher les nouvelles données que tous les cinq ans, la prochaine mise à jour intervenant que pour 2011, calculée sur les chiffres 2009, 2010, 2011, 2012 et 2013, chiffres que nous aurons début 2014. Qu'en pensez-vous ?--Cyrilb1881 (d) 3 janvier 2009 à 17:14 (CET)

Non Cyril, cela ne marche pas comme çà (du moins il me semble) : les populations légales sont bien données désormais tous les ans et non tous les 5 ans. En 2010, nous aurons la population légale de 2007 calculée sur la base des recensements partiels de 2005, 2006, 2007, 2008 et 2009. — Droop ^[blabla] 4 janvier 2009 à 21:10 (CET)

C'est bien ce que j'ai écrit, il nous faudra attendre le 1er janvier 2010 pour avoir la population théorique au 31 décembre 2007. Maintenant, ce que je propose, c'est, sur les articles WP et indépendamment de l'Insee, de ne pas changer tous les ans les chiffres mais d'attendre cinq périodes de recensement pour afficher de nouveaux chiffres. Cette année, on le fait puis en 2014, on s'y met à nouveau, avec les chiffres du 31 décembre 2011. Car pour nos articles, il n'y a pas grand intérêt à changer de chiffre tous les ans, pour la très grande majorité des communes, il n'y aura pas ou peu de variation entre 2006 et 2007, etc.--Cyrilb1881 (d) 4 janvier 2009 à 23:34 (CET)

Mise à jour avec un bot sans modification des 36000 articles

Même avis que Ikmo-ned, la mise à jour est prématuré, et tout ce travail est totalement inutile. Il serait préférable de retirer la population des articles (ou mieux de ne pas y toucher pour l'instant), d'activer l'inclusion par section sur wp:fr: et de modifier les infobox pour charger les données automatiquement. L'avantage est qu'il n'y aura aucun article à mettre à jour, un bot peux créer les sous pages de données (par paquet de 100 ça fera 3600 sous pages de données) et la mise à jour se fera chaque année sans avoir à modifier un seul article. - phe 2 janvier 2009 à 20:36 (CET)

D'une façon ou d'une autre, il faudra automatiser tout, ce qui impliquera de tout reprendre. Il y a, par ailleurs, une réflexion à avoir sur les moyens techniques les plus appropriés au vu de la nouvelle méthode de recensement. Je pense que moi et d'autres feront des propositions en ce sens.

Le fait de mettre à jour dès maintenant ne change rien ; de toutes façons, de gentilles IPs s'en chargeront pour nous si nous ne le faisons pas. Ca n'avance rien, mais ça n'empêche rien non plus.

Sur le fond, je ne vois pas la distinction que tu fais entre le chiffre 2006 et le résultat annuel. Le chiffre 2006 est issu, pour les communes de plus de 10 000 habitants, des recensements partiels effectués ces 5 dernières années ; et pour les communes de moins de 10 000 habitants, des recensements complets effectués chaque année sur 1/5e des communes. C'est cette méthode qui sera utilisée chaque année pour définir les populations légales, dorénavant. C'est une méthode statistique assez fiable, et qui par ailleurs définira les populations légales (sur la base desquelles sont comptées les dotations versées par l'Etat aux collectivités, etc.).

Il me semble que nous n'aurions pas intérêt à ne pas utiliser ces chiffres. Par contre, cela pose des problèmes techniques, mais cf. plus haut.

N'allons pas trop vite à faire un changement global, en effet : le problème qui nous est posé est plus large (le fait d'avoir des nouveaux chiffres chaque année), la solution doit l'être aussi. Ca ne nous empêche pas d'actualiser les articles si on le souhaite...

(Conflit d'édition) bon, phe a déjà commencé les propositions suite à notre discussion Manuel Menal (d) 2 janvier 2009 à 20:48 (CET)

Je ne suis sûr de rien, mais il me semble que vous oubliez un détail en proposant d'automatiser l'obtention et la mise à jour des données. Nous n'avons pas le droit de « piller » à grande échelle et de façon automatisée toute base de données, y compris celle de l'Insee. Je crois me souvenir que nous avons déjà été confronté à ce genre de problème à la création des articles de communes, lorsque nous avons dû enlever certaines informations directement issues de sites. Je serai plutôt partisan de définir une périodicité des mises à jour sur WP.--Cyrilb1881 (d) 2 janvier 2009 à 20:52 (CET)

Que l'acquisition des données soit manuel au automatique ne change rien, s'il y a un problème de législation, il existe déjà. - phe 2 janvier 2009 à 21:04 (CET)

Les données 2006 sont des données authentifiées par un décret, dont on peut, lui, reprendre le contenu. Si on venait à reprendre toute une série de données pour chaque commune (le nombre de logements, etc. etc.) de façon systématique, là, on pourrait être dans le pillage. Pour l'instant, on risque rien : elles sont pas publiées. Manuel Menal (d) 2 janvier 2009 à 21:10 (CET)

Par ailleurs, http://www.insee.fr/fr/publications-et-services/default.asp?page=copyright.htm : « Les publications et données mises à disposition sur le présent site sont consultables et téléchargeables gratuitement ; elles peuvent être réutilisées, y compris à des fins commerciales, sans licence et sans versement de redevances, sous ces seules réserves : respect de l'intégrité de l'information et des données et mention précise des sources. »

Ca tombe bien, on met les sources et on compte pas insérer de faux chiffres. Manuel Menal (d) 2 janvier 2009 à 21:14 (CET)

Si c'est un bot qui s'y colle, il faut envisager qu'il mette à jour à la fois dans l'infobox : la nouvelle population, la mention 2006, qu'il recalcule la densité, qu'il modifie le paragraphe Démographie (que celui-ci soit alimenté par le modèle:Démographie ou par le modèle:demogFR qui sont, à l'heure actuelle tous les deux amenés à évoluer ces jours-ci, compte tenu des nouveautés du nouveau recensement (population municipale au lieu de population sans doubles comptes + corrections d'erreurs - voir plus bas -)) en y ajoutant la source (lien avec site INSEE correct).

Voilà ce que, pour ma part, je vois déjà à faire, mais peut-être en ai-je oublié ? De plus, si j'ai bonne mémoire, il existe plusieurs infobox Modèle:Communefra avec 4 variantes (Corse, Guadeloupe, Martinique, Réunion), Modèle:Infobox Commune de France (la plus répandue), et j'ignore s'il y en a d'autres, ce qui suppose des programmations séparées ou fort complexes.

Avant de procéder aux modifications en masse, il faudra déjà que soient réglés les problèmes liés aux modèles ci-dessus (modèle:Démographie indique que 2006 est une Population provisoire, ce qui est erroné ; il s'agit de la population municipale légale ; modèle:demogFR quant à lui a ajouté 2006 dans une ligne qui contenait 9 informations et, de ce fait, les 10 colonnes de la ligne sont décalées par rapport aux 9 colonnes des lignes du dessus (voir exemple Agonac et de plus, lorsque le recensement qui a eu lieu entre 2004 et 2007 a déjà été mis à jour, le résultat est surprenant : Bassillac (2 colonnes 2006 dont une vide) ou Marsaneix (colonne 2006 vide précède colonne 2004 remplie).

Y a-t-il moyen de recenser combien d'articles utilisent tel modèle de démographie ou telle infobox ?

Et ensuite, combien de temps faudra-t-il pour obtenir la panacée et des programmes sur mesure pour corriger en masse ces données ? Père Igor (d) 2 janvier 2009 à 22:49 (CET)

Il n'y a pas de modification en masse à faire, la nouvelle méthode ne demande pas de modification des articles, seule les 4 (5 ?) infoboxe de commune seront modifiées, ainsi que les modèles de démographie. Les paramètres population et densité des articles ne seront plus utilisé, le paramètre 2006 des modèles de démographie sera aussi ignoré. Il sera temps de les retirer des articles plus tard, une fois prouver que la méthode proposer de mise à jour fonctionne. La première étape consiste à faire une demande auprès des devs pour que l'inclusion par section soit possible sur fr:, il faut ensuite extraire les données et créer les sous-pages de données, je m'en occupe dans les quelques jours qui viennent, ensuite faire quelques tests, peut être avec les pages sur les cantons qui sont bien plus simples. Pour les utilisations des modèles de démographie, pages liées à partir du modèle. - phe 3 janvier 2009 à 09:14 (CET)

@ Manuel Menal : Pour les enquêtes annuelles, je voulais évidemment parler des communes de moins de 10 000 habitants (je ne parlais de les utiliser que pour les tableaux, pas pour l'infobox). Si l'on prend une commune au hasard (Colleville-Montgomery), l'enquête annuelle 2004 ([1]) donnait 2 219 habitants, la population légale 2006 ([2]) est de 2 254. Comment est calculé ce chiffre et est-il aussi fiable que celui de 2004 ?

Sinon, petite découverte en ce qui me concerne et qui peut interesser le projet : je crois bien que le modèle {{Infobox Ville de Slovénie}} calcule tout seul la densité, d'après la population et la superficie. ---- Ikmo-ned (discuter avec) 3 janvier 2009 à 01:24 (CET)

Le modèle {{Infobox Communes de France}} calcul lui aussi automatiquement la densité.--Wikialine (d) 5 janvier 2009 à 00:30 (CET)

Les données sont aussi fiable que les anciennes, il y a seulement une modification de la définition de population, sans double compte avant 2006, population municipale après 2006 - phe 3 janvier 2009 à 08:56 (CET)

À lire ce document de l'Insee (§3.2), je ne suis pas vraiment d'accord. L'Insee parle bien d'estimation et d'interpolation. Dans l'exemple cité ci-dessus, l'année 2004 a donc plus d'intérêt dans un tableau que 2006. Je trouve qu'il faudrait que, d'une manière ou d'une autre, elle soit valorisée.

En revanche, je note que le document que tu cites assimile la population municipale à une population sans double compte. ---- Ikmo-ned (discuter avec) 3 janvier 2009 à 10:23 (CET)

Mais est-ce que ce renseignement est disponible ? J'ai échantillonné quelques pages de données de l'insee et la référence donné est systématiquement « Source : Recensement de la population 2006 - Limites territoriales au 1er janvier 2008 », comment déterminer la date du dernier recensement ? - phe 3 janvier 2009 à 11:02 (CET)

D'un point de vue statistique, il n'est pas vrai que les recensements généraux soient plus fiables que ces nouveaux chiffres. Les recensements généraux comportent des erreurs dues à l'absence de réponses ou aux réponses erronées. Précédemment, la marge d'erreur était telle que ces chiffres étaient eux-mêmes revus avec des facteurs correctifs. Ils n'étaient donc qu'une « estimation », une « interpolation ». En prenant en compte des données fiables issues des communes telles que l'évolution du parc de logements, ces données se « bonifient ».

Par ailleurs, je suis véritablement opposé au fait d'utiliser des chiffres d'années différentes selon les communes. On l'a vécu récemment avec certaines qui avaient leur population estimée en 2005, certaines celle de 1999… Ça fausse les classements ; ça complique la lecture pour l'internaute à qui l'on donne des données pas comparables entre les articles ; ça complique le travail des rédacteurs parce que les données précises des recensements (outre la population) ne sont disponibles que pour 2006, et pas 2004 ; et ça complique énormément le travail de mise à jour des populations. D'ailleurs, je vais à Colleville-Montgomery ! À plus tard. Manuel Menal (d) 3 janvier 2009 à 11:16 (CET)

Pour l'accessibilité les pages des enquêtes annuelles par département permettant d'ouvrir chaque pdf communal sont toujours disponibles.

Je suis 100% d'accord sur la cohérence des chiffres de toutes les communes, et j'ai suffisamment virer des chiffres différents de 1999 dans les infobox pour te l'affirmer, mais pour moi c'est bien l'infobox qui doit jouer ce rôle. Pour les tableaux démographiques, ce n'est pas un problème. Et à mon avis, l'enquête annuelle reste tout de même plus fiable, mais je n'en ferai pas un drâme si cette option n'est pas retenue. Si tu es arrivé à Colleville pour le déjeuner, tu pourras peut-être y manger des huîtres... ---- Ikmo-ned (discuter avec) 3 janvier 2009 à 12:04 (CET)

Voila une proposition, Utilisateur:Phe/Population 01 les données de population pour le département 01, Utilisateur:Phe/infobox commune fr basé sur une des infoboxs de communes avec cette modification (pas de modification du libellé double compte etc.) cette page est juste pour montrer le concept. Deux essais Utilisateur:Phe/test_infobox. La page de données n'utilise pas l'inclusion de section qui n'est pas actuellement permise sur wp:fr mais utilise un switch (voir le code en édition). Le code réel de l'infobox sera un peu différent, il faut que j'ajoute la sélection de la bonne page par département - phe 3 janvier 2009 à 16:23 (CET)

Grosso-modo, tu proposes une sorte de base de donnée qui centralise sur une seule page toutes les données démographiques en utilisant le switch... J'ai vu que ça fonctionne, l'idée est intéressante. Par contre à part les initié est ce que les wikipédiens vont comprendre comment s'y prendre pour modifier le nombre d'habitants dans l'article de leur ville. Nous aujourd'hui on sait car on a xuivi cette discussion mais les prochains arrivant. Je m'intérroge également sur le poid en Ko dans les articles car si on utilise ce genre de base de donnée avec switch alors il sera en principe utilisé dans l'infobox mais également dans le tableau démographique voir même dans l'histogramme donc répété 3 fois dans un seul article. Phe je ne sais pas ce que tu en penses, je te fais confience là dessus., je te laisses voir si ça alourdi ou non le poid de la page. Et puis je m'intérroge sur la multiplication de ce genre de base de donnée, car on peut le faire quelques part pour tous les paramètres des infobox mais aussi des autres modèles présents dans un articles de communes... N'est pas une petite révolution quelque part dans la conception même de nos modèles. Et niveau poids est ce que ça va jouer. Personnellement, je trouve l'idée d'avoir des page de données utilisant l'inclusion de section plus séduisante. Il faudrait lancer un grand débat au niveau de la communauté pour savoir ce qui serait le mieux. En tout Phe, je trouve ton idée innovante reste à peser le pour et le contre. En tout cas j'y suis pas opposé pour le moment. amicalement--Wikialine (d) 3 janvier 2009 à 17:09 (CET)

Vu que l'insee mettra à jour les données une fois par an pourquoi est-ce qu'un utilisateur voudrait modifier les chiffres de l'insee ? Le plus gros problème viendra des utilisateurs qui ne comprendront pas pourquoi ils ne peuvent pas modifier le chiffre de population mais de telle modifications devraient être réverté de toute façon (je présume qu'il est acquis que dans l'infobox on veut les chiffres publiés par l'insee, actuellement ceux de 2006 pour toute les communes). Pour le poids des pages même avec un switch ce n'est pas très lourd, pour le département 01, 419 communes, la page fait 5,5 Ko, en supprimant les espaces superflus ça descendra un peu en dessous de 4 Ko, c'est raisonnable. Sinon il y a la possibilité d'utiliser l'inclusion de section qui serait plus efficace mais il faut faire activer cette fonctionnalité *si* on tombe d'accord pour utiliser un schéma similaire à celui que je propose. - phe 3 janvier 2009 à 18:04 (CET)

A oui, j'ai mal lu, donc si j'ai bien compris cette fois-ci, les mises à jour des nombres dans les bases de données se feront automatiques. Elles seront automatiquement prises, par une sorte de bot, du site de l'insee puis mise sur nos pages de données. Ensuite pour le poid je suis rassuré. Donc pas de problème, moi je suis d'accord pour la mise en place de ton système par switch Phe. Par contre, si vraiment, il n'est pas difficile de mettre en place l'inclusion de section alors se serait préférable d'adopter cette seconde solution, le poid serait encore moindre et le nombre d'applications encore plus grande... D'ailleurs je suis étonné que l'inclusion de section ne soit pas encore permise, ce serait pourtant bien pratique dans plein de domaines. amicalement--Wikialine (d) 3 janvier 2009 à 18:55 (CET)

Après test, le switch est au final moins lourd pour les articles, du fait du système de cache. C'est plutôt la meilleure solution. Manuel Menal (d) 4 janvier 2009 à 13:49 (CET)

Après encore plus de test, la méthode 3 (mélange de switch et données séparés par des /) est bien plus efficace qu'un switch pure ou que l'inclusion de section. 5 janvier 2009 à 13:15 (CET)

Complètement contre toutes ces idées, car en France (donc pour tout contributeur opérant à partir de la France, ou pour tout contributeur écrivant pour être lu par des Français), toute exploitation automatisée de base de données est interdite (c’est le automatisé qui est important, et quand on voit la vitesse d'avancement des mises à jour diverses sur les communes de France, on comprend pourquoi). On a déjà fait la connerie une fois au moment de la création des articles, on ne va tendre régulièrement le baton pour se faire battre non plus. Épiméthée (d) 4 janvier 2009 à 13:11 (CET)

A moins que tu aies une source pour ce que tu avances, c'est faux.

Ce qui est interdit, c'est l'extraction substantielle d'une base de données externe protégée par le droit d'auteur. Qu'elle soit automatisée ou non ne change strictement rien à l'affaire. D'ailleurs, la Wikiquote francophone a été fermée suite à une extraction substantielle de base de données manuelle. Mais l'utilisation qui est préconisée ici est :

1. De récupérer les données à partir d'un décret, ce qui n'est pas comparable.
2. De toutes façons, parfaitement conorme aux conditions d'utilisation de l'INSEE que j'ai citées ci-dessus (qui nécessite l'intégrité des données et de citer les sources).

Il n'y a strictement aucun problème légal avec ce qui est proposé ici. Manuel Menal (d) 4 janvier 2009 à 13:46 (CET)

Je pense que ton exemple de la Wikiquote est différent : dans un recueil de citations, ce qui constitue l’originalité du recueil, c’est le travail de recherche, de compilation et d’authentification. Copier, mécaniquement ou à la main, sans travail complémentaire autre qu’une mise en forme obligatoire vu le support de publication, n’est pas une violation du droit de BdD, mais simplement une violation du droit de la propriété intellectuelle.

Le droit des BdD est différent, je pense que je vais demander son avis à Jurispedia. Épiméthée (d) 4 janvier 2009 à 13:54 (CET)

Les base de données qui sont protégés, le sont quelque soit la méthode d'accès, un accès manuel ou automatique ne change rien. Les données de l'insee ne sont pas protégés moyennant la citation de sources et le respect de l'intégrité des sources. - phe 4 janvier 2009 à 14:00 (CET)

Non, c'est bien le droit des bases de données qui s'applique à Wikiquote. Je suis administrateur de Wikiquote, et un des utilisateurs qui ont participé à sa re-création après sa fermeture. Je t'invite à lire, par exemple m:Closure of French Wikiquote, et principalement ce qui s'applique ici, à savoir m:Wikiquote FR/Closure of French Wikiquote/Frenchlaw Article L342-1.

L'automatisation n'a strictement rien à voir avec la chose. Je t'invite à lire les mentions légales sur le site de l'INSEE, qui sont ce qui nous importe : nous les respectons entièrement. Manuel Menal (d) 4 janvier 2009 à 14:03 (CET)

Je plussoie Épiméthée, le fait est que nous avons déjà été confronté au problème, inutile de tenter à nouveau le diable.
D'autre part, je voudrais ici modérer les ardeurs de certains. Les bot et l'automatisation, c'est bien, mais rien ne remplace pour le moment le travail « humain » et surtout les vérifications qui en découle. Donc, ce sera long mais je suis plutôt partisan de mettre à jour manuellement les articles et les listes et de vérifier ce que nous mettons. Il y a eu trop d'erreurs de bot pour risquer de devoir repasser derrière. Quant à créer encore de nouvelles sous-pages, non ! Déjà que certains créé des pages pour une simple liste de maires sans plus-values...
Par ailleurs, il n'y a pas eu d'écho à une de mes proposition plus haut : que pensez-vous de limiter, sur WP, le nombre de mise à jour à une fois tous les cinq ans, soit chiffre 2006, chiffre 2011, etc ?--Cyrilb1881 (d) 4 janvier 2009 à 14:23 (CET)

Je crois que tu n'as vraiment pas du tout compris la proposition.

D'une part, sur le côté légal, merci de croire que je ne propose pas de « tenter le diable ». Je ne suis pas un jeune fougueux qui n'y connaît rien et arrive sur Wikipédia sans se soucier des lois. Je connais bien les soucis légaux que nous avons eus, je connais bien également les contraintes qui sont les nôtres. Cependant, je me fonde sur des faits objectifs : le droit des bases de données (cf. article L342-1 du CPI cité plus haut) et les conditions d'utilisation des bases de données de l'INSEE. La proposition faite respecte entièrement ces contraintes.

Bien sûr, la mise à jour automatique des infobox et autres listes ne changent pas la nécessité de vérifications des articles. Qui le croit ? J'écris moi-même des articles sur des communes. Je sais ce qu'il en est, et je l'ai d'ailleurs fait dès début janvier. Néanmoins, il y a un véritable problème à résoudre avec ces infobox.

Ne pas les mettre à jour, c'est avoir des centaines d'utilisateurs, sous IP ou non, qui vont corriger de façon très approximative les articles, et nous ne pourrons pas passer derrière eux. Nous aurons ainsi des chiffres qui ne correspondent pas à la date indiquée, des densités incohérentes, des chiffres non vérifiés. Nous aurons également des articles dont les données resteront obsolètes pendant des années. C'est parfaitement inacceptable pour une encyclopédie.

Un bot ne fait pas d'erreur quand il s'agit de récupérer la population pour chaque commune et mettre à jour les articles en fonction, ça n'est pas vrai. Si erreur il y a, elle viendra de l'INSEE, et le bot n'y change strictement rien. Quant aux sous-pages, ce qui est proposé est de créer des sous-pages de travail, dans l'espace Projet, qui serviront au bot. Personne n'a jamais proposé de sous-pages dans les articles.

Enfin, pour ta proposition, je pense, pour les mêmes raisons que plus haut, qu'elle n'est pas une bonne solution : nous ne pouvons accepter d'avoir des chiffres obsolètes simplement parce que nous avons du mal à mettre à jour en temps en heure les articles ; d'autant que d'autres le feront à notre place, et de façon incohérente et approximative. Bien cordialement, Manuel Menal (d) 4 janvier 2009 à 14:43 (CET)

Les sous-pages de données seront des sous-pages du projet pas des sous pages d'articles. Ceci dit, sur la question de la légalité, si vous penser qu'Épiméthée a raison, il ne reste plus qu'à supprimer les données concernant la population, le code insee etc. (en fait cela revient à supprimer les infobox), à ne pas mentionner le maire etc. Toutes les données des articles proviennent de base de données. L'automatisation ou non de la procédure n'a rien à voir avec la légalité d'utilisation des données. Un juge pourrait considérer l'utilisation de robot comme une circonstance aggravante mais seulement pour les DB protégées. Pour le côté encyclopédique des articles, il n'est pas acceptable pour une encyclopédie de qualité de laisser des mois des articles dans l'état ou ils sont actuellement. - phe 4 janvier 2009 à 14:51 (CET)

Moi je ne suis pas opposé à l'idée de Phe pour automatiser la mise à jour de la population dans les infobox et pourquoi pas dans le tableau démographique... Soit on automatise soit on laisse tel quel, les 2 solutions me vont, personnellement. Au niveau légale, je crois que l'on peutr dire qu'il n'y a pas de soucis, ça ne pose pas de problème au pire, on peut demander confirmation du coté des participants du projet droit, sur le bistro et je ne sais où encore si vraiment il y a un doute. Par contre, j'avoue avoir une petite faiblesse pour l'idée d'usage de l'inclusion de section plutot qu'un switch. Certes l'un ou l'autre me conviendront au final, mais si je devas choisir l'inclusion de section serait vraiment un plus. Ensuite pour ce qui est du risque que certains jeunes wikipédiens ne comprennent pas qu'il puisse modifier le paramètre dans un modèles consacré à la population, ce problème poura être supprimé, soit en imaginant un système automatisé au niveau des modèles (infobox, tableau démographique...) soit en mettant dans la syntaxe un petit commentaire du genre <! -- Paramètres automatisé, ne pas modifier, merci -->. amicalement--Wikialine (d) 4 janvier 2009 à 17:13 (CET)

@ Manuel Menal Je suis plutôt d'accord avec toi quand tu indiques « nous ne pouvons accepter d'avoir des chiffres obsolètes » mais je préfère des chiffres obsolètes mis à jour avec retard que des chiffres faux.

J'aime bien ton optimisme quand tu écris « Un bot ne fait pas d'erreur quand il s'agit de récupérer la population ». Un bot, non, mais la personne qui le programme, si. Il n'y à qu'à voir les recensements de 1962 qui sont en grande partie faux car on n'a pas su faire une soustraction à partir de chiffres négatifs. Toutes les communes touchées par l'exode rural à cette époque avaient moins d'habitants en 1968 qu'en 1962 (source INSEE). Dégâts sur le département dont je m'occupe : sur les 557 communes de Dordogne, au moins 75 % que j'ai rectifiées en 2008. Exemple (non rectifié pour l'instant) dans le département voisin de la Corrèze : Saint-Éloy-les-Tuileries à comparer avec ça. Eh oui, 218 - (- 34) = 252 et non 184. Et l'erreur date du 6 août 2005, à la création de l'article par un bot, qui a reproduit cette erreur à grande échelle. Pour vérifier, je viens d'aller chercher une commune au hasard dans l'historique du bot le 9 novembre 2006 : Saint-Jean-Cap-Ferrat (connue au-delà de nos frontières) qui indique 2296 habitants en 1962 à comparer avec 2356 - (- 60) = 2416 (une paille ; la poutre, c'est lorsque certaines communes se sont retrouvées avec des chiffres de population négative (lu dans une discussion il y a pas mal de temps)). Donc, si un bot peut mettre à jour OK, mais avec tests préalables sur différents types d'articles. Comme je l'écrivais plus haut avant-hier, la programmation risque d'être compliquée compte tenu des différents types d'infobox et/ou des différents types de tableaux démographiques répartis selon les articles. J'apprécierai un programmateur de bot qui en profiterait pour rectifier 1962 là où c'est nécessaire. Cordialement. Père Igor (d) 4 janvier 2009 à 21:02 (CET)

Oui, bien sûr il faudra des tests. Bien sûr, il faudra qu'on s'y mette tous pour que tout se passe au mieux. Mais note bien que je n'ai pas cru qu'un bot ne faisait jamais d'erreur. Je dis juste qu'on est devant un cas où il n'y aura pas d'erreur sur les chiffres : il s'agit, là, de récupérer des paires code INSEE <=> population, ce qui ne pose strictement aucun souci. Dans ton exemple, le bot devait réaliser un calcul, ce qui est autrement plus complexe et donc sujet à erreurs.

En l'occurrence, je pense qu'on peut dire qu'on est sur un cas simplissime : récupérer des données sous une forme code => valeur, et trouver pour chaque code la valeur associée. Dur de se tromper là-dessus Manuel Menal (d) 4 janvier 2009 à 21:40 (CET)

Tel que tu l'expliques, effectivement, c'est simplissime. Là où cela me semble plus complexe, c'est la mise à jour qui s'ensuivra avec les paramètres d'infobox et de tableau démographie propres à chaque commune. Bonne soirée. Père Igor (d) 4 janvier 2009 à 22:39 (CET)

La modification des infobox sera faite dans une sous-pages de test, mais conceptuellement ça n'a rien de compliqué, il s'agit de sélectionner la page de données avec un {{{insee}}} / 1000 et la bonne entrée dans la page de données avec un {{{insee}}} mod 1000 (modulo), le code réel sera plus compliqué, mais la méthode elle même est relativement simple. Pour le problème de 1962, s'il y a beaucoup d'erreur on pourrait coller une rustine simplement en n'affichant pas l'entrée pour 1962 dans le modèle en attendant d'avoir le temps de s'en occuper sérieusement ? Pour le modèle de démographie le problème est que ce modèle ne reçoit pas le numéro insee, dans le pire des cas le nom de la page pourrait servir de clef pour retrouver la donnée correspondant, mais j'aimerai bien trouver une solution plus simple. - phe 5 janvier 2009 à 13:15 (CET)

Pour 1962 mon souci de récupération des données est réglé, les chiffres sont disponibles sur le site de l'insee sans avoir à faire le calcul à partir (PDSC 1968 - le solde migratoire 62-68), toutes les données dans un seul fichier, ça laisse beaucoup de moins de possibilité de refaire des erreurs. - phe 6 janvier 2009 à 15:17 (CET)

D’après Legifer, la recopie ne pose pas de souci ; le seul écueil éventuel peut provenir de l’utilisation d’un bot. Dans le cas d’une copie manuelle (genre une vingtaine de contributeurs écrivant chacun sur les départements d’une région), on est sur de ne pas avoir de souci ; dans le cas d’un bot, ce n’est pas sur, mais dans notre cas précis, il me semble que ce devrait être bon (toujours d’après les explications de Michelet) ;

Quand au sourçage, je pense qu’il faut insister dessus, de façon à pouvoir présenter une référence pour chaque info donnée, ce qui est la définition d’un bon article. Si on ne le fait pas maintenant, je pense qu’on aura moyen envie de le faire dans un an. Et pourtant une bonne balise ref, ça aide bien à distinguer la mise à jour vandalisme qui passe par là. Épiméthée (d) 6 janvier 2009 à 09:51 (CET)

Ce que dit Michelet (qui, soit dit en passant, n'est pas plus juriste que moi), en l'occurrence, c'est qu'au vu des mentions légales de l'INSEE, il n'y a pas de question à se poser, bot ou pas.

Autrement, pour l'extraction substantielle, c'est exactement ce que j'ai dit plus haut. Note que l'article L342-1 du CPI commence par « Le producteur de bases de données a le droit d'interdire : ». Ce que ne fait pas l'INSEE, et c'est ce qui nous intéresse. Manuel Menal (d) 6 janvier 2009 à 10:25 (CET)

Pour le sourçage manuel sur les communes que j'ai commencées, j'ai utilisé un lien avec la page propre à chaque commune (voir exemple Beaussac) avec blabla = "Insee, Population légale 2006". Père Igor (d) 6 janvier 2009 à 10:32 (CET)

L'idée là serait que les infobox ajoutent automatiquement la référence en mettant, effectivement, un lien vers la page de la commune sur le site de l'INSEE. Ca s'automatise très bien vu qu'on a le code INSEE, et ça permet d'avoir des références bien formatées (et avec toujours le même type d'URL) sur tous les articles, ce qui serait un gain considérable. Manuel Menal (d) 6 janvier 2009 à 10:37 (CET)

Pour les ref, oui c'est indispensable, et Épiméthée pose une question intéressante. L'insee ne maintient pas les ref pour les données anciennes, comment va-t-on procéder l'année prochaine, lorsque les liens comme [3] ne mentionneront plus l'année 2006 mais l'année 2007 alors que nous allons nous servir de ce lien pour l'année 2006 ? - phe 6 janvier 2009 à 10:42 (CET)

Igor, pour les ref je suis d'accord avec Manu, elle devrait être dans l'infobox les modèle de démographie avec une mention comme « <ref>de 1962 à 2006 [[population sans double compte]], [lien vers l'insee pour les pops 1962-1999 ? (il faut deux liens 1962-1982 et 1982-1999 ?)], à partir de 2006 [[population municipal]], [lien insee pour l'année 2006]</ref> - phe 6 janvier 2009 à 10:59 (CET)

Moi je crois au contraire qu'il ne faut pas mettre de ref dans les infobox pour plusieurs raisons, car peu esthétiques, puis généralement les infobox sont comme l'intro, une reprise d'informations détaills en profondeur dans l'article. Et puis surtout la raison principale auquel on doit prendre compte, c'est que l'ajout de ref peut créer de nombreuses complications techniques avec tous les paramètres automatisés comme le calcul automatisé de la densité ou encore pour le calcul des population entre elle pour avoir un résultat possible par département, région, canton, ... Très sincèrement les infobox ne devraient pas accueillir de ref, les tableaux démographiques sweraient plus approprié à mon sens. C'est d'ailleurs ce que l'on a toujours fait jusqu'à présent. amicalement--Wikialine (d) 6 janvier 2009 à 22:42 (CET)

Oups, oui, je voulais parler des modèles de démographie, j'ai corrigé mon message. - phe 7 janvier 2009 à 12:54 (CET)

Comme le dit Michelet « En l'occurrence, la notice de "mention légale" de l'INSEE dit que la recopie est libre et qu'ils s'en moquent, donc je ne vois pas pourquoi on se poserait trop de question... » - phe 6 janvier 2009 à 10:42 (CET)

@ phe, pourquoi parles-tu de 2 liens différents 1962-1982 et 1962-1999 ? Un seul suffit : [4]. Pour les recensements complets depuis 1793, je mets en plus une source Cassini (voir pour Agonac la notice communale Cassini [5]) mais là c'est plus manuel, car le code Cassini n'a rien à voir avec l'INSEE.

Maintenant, il serait intéressant effectivement de savoir avec certitude si l'INSEE va écraser ou non l'année prochaine les données légales 2006. Si oui, problème.

Pour le changement de nomenclature 1962-1999 population sans doubles comptes et à partir de 2004 population municipale, c'est un travail à effectuer en amont sur les modèles démographie utilisés et ça ne gênera en rien le travail du bot qui utilisera ensuite ces modèles bien repensés. Père Igor (d) 6 janvier 2009 à 11:32 (CET)

L'INSEE n'écrasera pas les données légales 2006, d'autant que les résultats détaillés seront publiés courant 2009. Ils changeront vraisemblablement de place, mais ça n'est pas un souci : ça nécessitera juste de changer les infobox. (Alors qu'avec le système actuel au contraire, il faut changer tous les articles). Manuel Menal (d) 6 janvier 2009 à 11:46 (CET)

 

Oui, il n'y a pas de problème, j'ai cru que certains de nos articles utilisaient ce type de lien [6]. - phe 6 janvier 2009 à 15:12 (CET)

Peut-être que ce lien (que je ne connaissais pas) existe effectivement sur certains articles mais [7] te fournit la totalité de la période. La partie détaillée n'est toutefois pas identique. Père Igor (d) 6 janvier 2009 à 18:14 (CET)

Mise à jour tableau départemental des communes ?

Certains tableaux sont très complets : triables suivant tous les critères comportant même la superficie et les densités de toutes les communes. Toutefois ils comportent les PSDC de 1999

exemple : communes de l'Ain

y a t'il un moyen de les mettre à jour par robots ?

liste complète là [8]

Sneaky 013 (d) 4 janvier 2009 à 00:10 (CET)

Si l'on veut être rigoureux il faudrait vérifier toutes ces listes. Depuis qu'elles ont été crées il y a eu des fusions, défusions, changements, échanges de terrains. Est-on certain que tout soit à jour ? Tella bavarder 4 janvier 2009 à 10:52 (CET)

Contre cette idée et d'accord avec Tella, comme pour la mise à jour des maires, c'est l'occasion de vérifier les informations et d'apporter des corrections.--Cyrilb1881 (d) 4 janvier 2009 à 14:24 (CET)

Et donc de se retrouver avec, comme pour les maires, nombre d'articles qui indique une mauvaise étiquette politique, et même souvent un mauvais nom ?

Il me semble qu'il serait bon au contraire de faire une première mise à jour globale, et ensuite de mettre en place une page de coordination qui nous permette d'aller vérifier et compléter tous ces articles, qui en ont de toutes façons besoin. Mais économisons nous du travail, sans quoi nous allons encore ramer sans fin. Manuel Menal (d) 4 janvier 2009 à 14:47 (CET)

Désolé mais je ne vois pas quel est le gain si l'on fait passer un bot et qu'il faut revérifier derrière...--Cyrilb1881 (d) 4 janvier 2009 à 14:54 (CET)

Le gain de temps énorme. Copier/coller des centaines de chiffres depuis le décret, pour chaque commune, est très long, très pénible, et par ailleurs amène à faire des erreurs (décalage d'une ligne, typo...) qu'un bot ne ferait pas. Une fois un bot passé, il n'y a plus que le texte à vérifier, rajouter des ref pour les éventuelles fusions, etc. : c'est 15 fois moins de travail, et donc beaucoup plus d'efficacité (et une probabilité d'erreurs moindre). Manuel Menal (d) 4 janvier 2009 à 14:58 (CET)

Bon alors je remballe mon idée tant pis s'ily a des communes manquantes. Pour mon département c'est ok. Tella bavarder 4 janvier 2009 à 15:09 (CET)

Tella, je ne comprends pas le besoin de vérifier les listes de l'insee, ce sont les données officielles, et ce sont les seules données que nous devrions utiliser sur wp:fr, à moins que tu ne parles d'autre choses ? - phe 4 janvier 2009 à 15:51 (CET)

Arf, non, je viens de comprendre. Oui il va falloir vérifier que les listes que nous utilisons dans les listes par département sont conformes aux listes de l'insee, c'est aussi typiquement le style de liste qui doivent être géré par un bot via les divisions administratives de l'insee pour être assurer de la conformité avec les données de l'insee (conformité qui est une des deux restrictions d'utilisation des données de l'insee : intégrité des données) - phe 4 janvier 2009 à 15:55 (CET)

Les modèles de Tableaux d’évolution démographique

Autant pour les modèles d'infobox l'ajout de de paramètres automatisées pour la mise à jours des données démographiques ne semble pas poser de problème majeur, autant pour les modèles de tableaux d'évolution démographique, les choses sont moins évidentes. En effet, jusqu'à maintenant on mettant à jour les tableaux manuellement donc pas de problème mais si l'on automatise ces modèles comment faire en sorte que l'on puisse conserver les anciens chiffres de recensement pour les années passées. Au passage, il serait souhaitable que le projet communes de France rédige une page claire et précise sur comment se base les anciennes et nouvelles évaluations démographique, car on s'y perd. En tout cas, pour ces tableaux, il faut trouver un moyens de pouvoir conserver une trace de ces nouveaux chiffres. En tout cas avant de se lancer, prenons le temps de bien expliquer les choses et de citer des exemples claires. Autrement il risquera d'y avoir des incompréhensions au sein des débats ici même, mais également pour les rédacteurs sur les articles... amicalement--Wikialine (d) 5 janvier 2009 à 19:46 (CET)

je viens d'essayer d'y apporter un peu de clarté mais bon ... :-)[9]Sneaky 013 (d) 5 janvier 2009 à 21:07 (CET)

bon je pense qu'on s'y perd un peu moinsSneaky 013 (d) 9 janvier 2009 à 13:45 (CET)

Voici le lien, dont parle Sneaky 013, Chiffres de population en France. Au moins, les choses sont plus claires à présent. On peut également au passage saluer le travail de vulgarisation de Sneaky sur cette page. Les choses compliquées deviennent plus simples lorsque on les expliques clairement. amicalement--Wikialine (d) 9 janvier 2009 à 19:36 (CET)

Pff je viens encore de faire des modifications sur Chiffres de population en France c'est encore plus pointu que ce que je croyais la différence entre la nouvelle population municipale et l'ex PSDC (j'avais pas vu ce petit détail des étudiants mineurs :) qui viennent réduire le gonflement induit par le changement de méthode Sneaky 013 (d) 13 janvier 2009 à 06:55 (CET)

Comme je viens de l'indiquer sur Discussion_Projet:Communes_de_France#Modèle:DemogFR, j'ai créé un nouveau modèle de tableau démographique {{Démographie2}}.

En effet le modèle DemogFR est fait de telle sorte qu'il n'est pas très facile de le faire évoluer pour supporter de façon simple les nouvelles années à venir. Ce nouveau modèle Démographie2 permet l'affichage des tableaux de population avec beaucoup de flexibilité sur la mise en page (largeur, nombre de colonnes, couleurs, etc. sont paramétrables) et le nombre d'années à afficher (jusqu'à 200 - si besoin de plus je peux modifier le modèle). Je ferai plus tard un modèle DemogFR2 similaire à DemogFR (sous un troisième nom) qui utilisera le modèle Démographie2 et s'utilisera avec les mêmes arguments que DemogFR mais avec des arguments étendus (support des années 2006, etc.). Ensuite, on pourra l'utiliser à la place de DemogFR si cela convient. Je peux faire des modifications à Démographie2 si besoin. Carfois (d) 7 janvier 2009 à 12:03 (CET)

Le modèle Démographie2 ne devrait-il pas être contenir « fr » dans son nom ? Si on ajoute des refs dans le modèle ils vont devenir spécifiques aux communes fr: - phe 7 janvier 2009 à 12:57 (CET)

Si en effet Phe, mais en fait cela dépend aussi de si on laisse ce modèle complètement générique ou de si on lui met des paramètres ou caractéristiques dédiées à la France (pour l'instant je n'ai mis qu'un seul tel paramètre, "sansdoublescomptes", par conservatisme par rapport aux autres modèles de démographie mais sans être certain que ce paramètre soit très utile puisque l'on peut aussi écrire ce qu'on veut dans le paramètre "notes"). Comme le modèle est tout nouveau, ceci n'a pas encore été décidé. Il n'a d'ailleurs pas même vraiment encore été décidé si ce modèle allait être utilisé ou non tout court mais je pense qu'il le sera. J'ai maintenant refondu le modèle pour qu'il n'ait plus de tableaux imbriqués. Il y aura sûrement quelques améliorations encore à apporter. Carfois (d) 13 janvier 2009 à 07:11 (CET)

Automatisation de la mise à jour de la population

Bonjour, j'ai bien réfléchie à toutes les possibilités qui s'offrent à nous et je penses avoir trouver une solution. D'après moi, la solution la plus convenable en prenant compte des limites techniques que nous impose Wikipédia, il me semble que pour créer un système de mise à jour automatique de la population des communes, nous soyons obligé de créer une sous-page par commune qui serviraient à reccueillir uniquement les données. Je sais ça fait beaucoup, soit plus de 36 600 sous-pages. Mais une fois fait la charge de travail devrait être minime pour nous tous. Puis ces pages devront être mises à jour uniquement par un bot. Ainsi graces à ces sous-pages que l'on pourrait appeler « Macommune/Population », on pourra avoir tous les modèles d'infobox mis à jour automatiquement et ce facilement avec un script très très très très léger en poid (nombre de ko) ce qui n'est pas négligeable. Avec ces sous-pages on va pouvoir mettre en place des tableaux démographiques qui se mettront à jour automatiquement sans que l'on ait plus rien à faire une fois inclus le modèle dans la page. Ensuite l'avantage de ces sous-pages, c'est que ça va permettre de créer des applications qui dépasse le cadre du niveau communal. En effet, si l'on a les données de population communal et bien on peut créer des modèles qui calcul automatiquement la population intercommunale, départementale, régionale, nationale... Graces à ces sous-pages on pourra permettre aussi la mise à jour automatique des pages de liste comme Liste des communes de la Charente-Maritime (soit une 100ène car une page par département, de page pour l'exemple ici)... Par contre, si l'on ne trouve pas de robot capable de récupérer les données sur le site de l'insee pour ensuite les mettre dans nos sous-pages, alors certes ce sera moins bien, mais pour autant ces sous-pages resteront toujours une meilleurs solution même si l'on devait pour je ne sais quelle raison les remplir manuellement. En effet actuellement, on doit mettre à jour manuellement la totalité des articles de communes (infobox + tableaux démographiques...), les listes, les infobox et tableaux démographiques dans les articles interdépartementaux, départementaux et régionaux voir même nationaux... Donc dans tous les cas, on gagnera beaucoup de temps. On peut même imaginer des solutions par bot plus simple que j'expliquerai plus tard. L'avantage supplémentaire de ces sous-page est de nous mettre un peu plus à l'abris des réforme territoriale. Les départements, les régions et j'en passe sont appeler à disparaître ou à être modifiées, il y a beaucoup de réformes ces dernier temps en matière de collectivité territoriale, il y a même des référendum dans les îles... Les communes sont des découpages territoriaux plutot stable ainsi avec nos sous page on n'est plus tranquille. Donc avant de me lancer dans la mise en place de ce système, j'ai besoin de votre soutien car notre projet va être précurseur en matière d'automatisation de donnée. Je mettrais en place quelques exemples pour mieux aider à comprendre si besoin est et avant de lancer une création de masse. Par ailleurs, Droopig va avoir du boulot. Voilà vous savez tout. Êtes-vous partant ? amicalement--Wikialine (d) 9 janvier 2010 à 23:15 (CET)

Bonjour. Je demande à voir des exemples. Pour ma part, je pense que le département est l'élément stable en plus des communes, ce qui permet de télécharger et traiter les données par paquets depuis les fichiers Excel de l'Insée, ce qui limite considérablement le travail. En tout cas, il faut en effet utiliser au maximum les bots et les modèles. Que penses-tu du processus "JFB" exposé plus haut ? Dans un cas comme dans l'autre, comment se remplira la table et le graphique ? En tout cas, le principe de la sous-page (ou du modèle) me paraît sympa, pour centraliser les données (et éviter de les modifier n'importe où ailleurs). Le modèle JFB (popdatafr, ...) permet de centraliser très proprement, mais la dernière année seulement. Dans le principe de la sous-page communale, on peut en effet centraliser tous les chiffres de population de la commune, les données source pour l'article (infobox, table, graphique), ce qui est propre aussi, à condition que ce soit viable. Il faudra voir aussi si dans l'article les données seront dupliquées par bot (fréquence?), ou remplacées par des modèles pointant vers la sous-page (qui aura un nom unique par commune). La première solution me paraît moins de qualité (on peut modifier manellement les nombres, comme actuellement). A voir donc sur un exemple... Jack ma ^►discuter 10 janvier 2010 à 08:22 (CET)

Bravo Wikialine pour faire avancer la discussion. Comme écrit par d'autres, je crois qu'un exemple sera le meilleur moyen de progresser dans cette discussion. Merci encore. Cordialement. AntonyB (d) 10 janvier 2010 à 09:44 (CET)

Alors, d’accord sur le principe, si Legifer est d’accord. Par contre, vu le boulot, autant penser à une mise en place qui tienne justement compte que les communes n’ont peut-être pas autant d’avenir que ça, et à une automatisation de la récupération de données si il y a un mouvement massif de fusions de communes, genre dans dans une trentaine de mois. Épiméthée (d) 10 janvier 2010 à 10:10 (CET)

@Jack ma, le système de JFB est intéressant. Il y a pas mal de tant on avait déjà discuter d'un système équivalent ici de Phe. Le problème majeur de ce système est que l'on propose de centraliser toutes les données de population communale (avec ou sans double compte...) sur des pages de modèles reprenant le découpage départemental. Par exemple, une page de données de toutes les populations des communes (283 communes) du département du finistère, poserait plusieurs problèmes. A savoir, le découpage administratif des département est-il stable ? Avec les réforme du gouvernement actuel, il se peut que les département disparaissent ou fusionnent. De plus, il n'y a pas des départements partout, que faisons-nous pour les communes qui se trouvent dans certaines collectivités d'outre mer. En ce moment même un référendum va avoir lieu pour certaines iles (Martinique, il me semble...), on parle de possible fusion là bas des département et des régions... Autres problème plus technique cette fois, si l'on tente de tout centraliser sur une seule page, la page va peser lourd en terme de ko à la sortie. En effet, faisons un calcul simple avec l'exemple du département du finistère. Il y a là bas 283 communes, donc on aura 283 fois des dates car une par communes, puis il faut y ajouter les anciens recensement donc de 283 nombres de recensement ça peut se multiplier par 10 (si une dizaine de recensements par communes) soit au total 2 830 nombres de recensement. Autre soucis, le nom des modèles. Dans un soucis de titrage on se doit d'adopter un nom de modèle clair et facil de compréhension. Il y a encore d'autres problèmes... Pour ce qui est des tableauesx et graphique avec le système que je propose se sera très simple, mais chaque chose en son temps. D'abord je viens de créer un exemple pour les infobox. Après je mettrait en place un exemple de tableau qui se remplira automatiquement... amicalement--Wikialine (d) 11 janvier 2010 à 00:30 (CET)

@ Épiméthée, En cas de disparition des communes, peu probable à mon sens, mais c'est un avis personnel, en bien justement l'avantage d'avoir une sous page par article de commune permet de ne pas boulverser les articles. En effet, on a tous travaillé ici à un momentn ou à un autre sur des articles de communes ayant disparut ou qui ont perdu leur statut de commune... Pour autant ces anciennes communes ont leurs articles sur WP, c'est normale, et et donc il est impératif que ces articles conservent les données de population. Donc on aura toujours plus de stabilité en évitant la centralisation de données. Par ailleurs, graces à ce système on peut créer des addition etd es soustraction, donc si des communes fusionnent on peut additionner les données ... amicalement--Wikialine (d) 11 janvier 2010 à 00:30 (CET)

J'avais pensé à un système similaire avec les données météorologique qui ne sont pas propre à une commune mais dépendent de la station. On insère le tableau météo qui est sur autre page et comme sa on a plus à modifier tout les tableaux de toutes communes qui entourent Lyon par exemple.--Mokacchino (d · c) 10 janvier 2010 à 14:54 (CET)

Bon voilà, j'ai commencé à vous créer des exemples pour que ce soit plus parlant. On va commencer par les infobox mises à jour automatiquement. Pour les modèles de tableau démographiques et autres, les exemples et développement se feront facilement par la suite. J'ai donc créé une infobox d'exemple {{Infobox Communes de France/essai}} qui comprend le script d'appel automatique vers la base de données rattaché au articles. J'ai créé également 2 bases de données que sont Modèle:Population Évry (Essonne) et Modèle:Population Angoulins. Vous pouvez donc dès à présent faire un essai d'une infobox qui se met à jour automatiquement. Pour se faire allez sur les articles Angoulins (petite commune) et Évry (Essonne) (grande commune). Puis modifiez légèrement le nom de l'infobox en ajoutant « /essai ». Pour ce qui est des paramètres « sans » et « date-sans », ils peuvent être retiré car il n'existent plus. Puis cliquez sur « Prévisualiser ». L'infobox met automatiquement le dernier nombre du recensement et met à jour également automatiquement la date du recensement. Si vous n'arrivez pas à faire l'essai demandez moi. Qu'en pensez-vous ? amicalement--Wikialine (d) 11 janvier 2010 à 00:38 (CET)

Wikialine ça marche ! Je suppose que le modèle sera en final dans Angoulins/Population comme tu avais dit ? (cela me semble mieux pour ne pas avoir à créer autant de modèles que de communes indépendants). C'est bien car le modèle est simple (mise à jour facile) et centralise les données. Jack ma ^►discuter 11 janvier 2010 à 07:45 (CET)

Bonjour, j'ai mis en place sur la wiki occitane les modèles popfrxx (communes par département pour les départements tout ou partie occitans 03 04 05 06 07 09 11 12 13 15 16 18 19 23 24 26 30 31 32 33 34 36 38 40 42 43 46 47 48 63 64 65 66 81 82 83 84 86 87), popfrreg (régions, même si le code INSEE des régions n'est pas très usité), popfrd (départements). En principe, un copier/coller vers la wiki fr suffit... J'ai aussi créé un premier modèle popfr03c avec les populations cantonales de l'Allier (il y aura aussi popfr03a pour les arrondissements). Je voulais surtout m'interroger sur la pertinence des tableaux démographiques sur toutes les communes et surtout sur celle de leur mise à jour annuelle. Les sciences humaines - et les encyclopédies - doivent à mon avis présenter des informations donnant lieu à réflexion. Autant une donnée brute comme la dernière population a sa place dans l'infobox, autant l'évolution démographique d'une commune de 200 habitants me semble de peu d'intérêt, voire à renvoyer vers le site "cassini". Mais ce n'est qu'un avis personnel ;-) --— J.-F. B. ^{(me'n parlar)} 11 janvier 2010 à 09:08 (CET)

Bonjour JF. Le problème, si j'ai bien compris, est que tes modèles ne concernent que la dernière année (Modèle:Popfrdata), ce qui n'est donc utile que pour l'infobox. Wikialine propose un moyen de stocker (centraliser) les données de toutes les années pour une commune. Par ailleurs, je suis d'accord que selon les communes, on ne doit pas avoir les mêmes tableaux ou graphiques. Il faudra plusieurs modèles, ou plutôt limiter le modèle graphique aux grandes communes (le modèle tableau est utilisé partout; il faudra convenir d'un seul). Jack ma ^►discuter 11 janvier 2010 à 09:34 (CET)

Ça fonctionne, effectivement. Reste un problème de taille, seule l'infobox est (encore) concernée par cette mise à jour automatique alors que la partie démographie doit présenter les même données actualisées. D'ailleurs, pour répondre à JFB, toutes les communes méritent de présenter l'ensemble de l'évolution démographique, a fortiori les communes de « seulement » 200 habitants car bien souvent, ce sont des communes rurales qui souffrent de l'exode et d'un dépeuplement prononcé. C'est important de le mentionner et de le présenter. Et il n'y a pas de raison non plus de privilégier les grandes communes pour l'histogramme, toutes y ont droit, il faut juste prendre le temps de le faire. Au passage, je vous invite fortement à ne pas enregistrer l'essai sur les articles exemples.--Cyrilb1881 (d) 11 janvier 2010 à 12:35 (CET)

@Cyril: Wikialine nous dit bien que l'infobox n'est qu'un premier exemple, le reste (tableau et graphes) suivront facilement. Je pense que le tableau (ou le graphe) se feront automatiquement d'après le contenu (populations et dates disponibles dans la commune). Jack ma ^►discuter 11 janvier 2010 à 14:08 (CET)

J'attends de voir. Mais d'expérience, ça ne sera certainement pas si facile que ça… d'autant moins que ton « il faudra convenir d'un seul » est tout simplement irréaliste à l'échelle du projet Communes de France.--Cyrilb1881 (d) 11 janvier 2010 à 18:25 (CET)

Cyril, Le doit de votre phrase ci-dessus est le résultat d'une décision ? --— J.-F. B. ^{(me'n parlar)} 11 janvier 2010 à 13:21 (CET)

Je me permets d'apporter mon point de vue : le doit me semble relever du « bon sens ». Je suis en effet bien ennuyé de voir tous ces articles de communes dans lesquels la donnée population est mise à jour dans l'Infobox alors qu'elle ne l'est pas dans le corps de l'article (en particulier dans le chapitre Démographie, mais pas seulement malheureusement). Or l'Infobox initialement avait pour but de reprendre des informations de l'article. Cordialement. AntonyB (d) 11 janvier 2010 à 13:34 (CET)

Les sous-pages d'articles ne sont pas autorisées. Tella bavarder 11 janvier 2010 à 15:03 (CET)

+1 AntonyB et +1 Tella .--Cyrilb1881 (d) 11 janvier 2010 à 18:25 (CET)

Je vais essayer de répondre à plusieurs sujets évoqués ici ou là.

• Pour ce qui est du nom, j'ai du laisser tomber l'usage de sous-pages, du genre « Angoulins/Population » pour me tourner vers un nom de modèle. Ainsi d'un point de vu technique ça facilite considérablementr les choses, puis comme l'a dit Tella les sous-pages d'articles ne sont pas autorisées, mais surtout ce sont des modèles il est donc préférable de débuter leur nom par modèles dans un soucis de respect des conventions de nommage. Le nom définitif de ces bases de données est donc [[Modèle:Population <Nom article de la commune>]].
• Il y a semble-t'il une forte attente en matière de mise à jour automatique des tableaux démographiques... J'ai créé dans un premier temps un exemple pour les infobox. Je n'ai pas trop eu le temps de créer un tableau démographique qui se mette à jour automatiquement. Dès que j'ai un moment promis je m'en occupe. Mais l'important c'est de bien comprendre que graces à ces modèles, on peut les utiliser sur une multitude de modèles annexes (infobox, tableau démographiques, ...).

amicalement--Wikialine (d) 11 janvier 2010 à 20:05 (CET)

Bon je vais faire la mise à jour des communes des Pyrénées-Atlantiques "a la mano". Tella bavarder 11 janvier 2010 à 20:29 (CET)

J'ai commencé à développer un tableau démographique automatisé pour que vous ayez un exemple. Vous pouvez faire un test en ajoutant {{Population Commune de France}}, sur les articles Angoulins et Évry (Essonne). Cliquez bien sur prévisualiser. Ce modèle de tableau n'est pas terminé. Je tiens à le préciser, mais au moins ça vous donne un autre exemple d'appliquation d'usage des modèles de population. amicalement--Wikialine (d) 12 janvier 2010 à 05:33 (CET)

Avant d'aller plus loin (puisque les sous-pages ne sont pas autorisées), je me demande si nommer le modèle avec le numéro Insée n'est pas préférable qu'avec le nom de la commune, si celui-ci change ? - même si c'est moins parlant. Jack ma ^►discuter 12 janvier 2010 à 08:31 (CET)

Non, on ne peut pas utiliser le code INSEE car en fait les modèles infobox ou les tableaux démographique sont génériques sur l'ensemble des articles car on peut utiliser le scriopt « {{PAGENAME}} ». Actuellement en utilisant ce script on se passe de remplir un quelconque paramètre. Par contre si un jour, il faut modifier le nom d'un article et bien il suffira de renommer le nom de l'article et celui de son modèle de population, donc pas de soucis particulier. amicalement--Wikialine (d) 12 janvier 2010 à 20:18 (CET)

Ça fonctionne, mais il manque les sources des données qui doivent impérativement apparaître sur l'article. Et le principe de créer uns sous-page par article de commune (et par extension, de canton, d'arrondissement, etc.) n'est pas souhaitable à mon avis. L'utilisation d'un robot type Droopigbot est préférable.--Cyrilb1881 (d) 12 janvier 2010 à 16:05 (CET)

Il n'y a plus de sous-page (voir plus haut). Les données sont centralisées en-dehors de l'article; pas de redondance donc entre l'infobox, le tableau, le graphique, donc de lourdeur, risque d'erreur, etc... Ceux-ci ne seraient donc que des affichages de ces données, stockées dans le modèle. C'est aussi l'occasion d'homogéniser ces multiples tableaux démographiques... Jack ma ^►discuter 12 janvier 2010 à 16:38 (CET)

Qu'on ait 36 600 « sous-pages » intitulées Population X ou 36 600 « modèles » intitulés modèle:Population X revient exactement au même ! Ce sont 36 600 pages de trop, inutiles au lecteur, qui prennent de la place sur les disques. La solution du robot est à mon avis toujours la meilleure jusqu'à présent.--Cyrilb1881 (d) 12 janvier 2010 à 17:32 (CET)

Si les données sont centralisées (c'est-à-dire non dupliquées), ça prendra moins de place au total. L'article de chaque commune sera beaucoup plus léger (tableau et graphe ne seront codés que sur 1 ligne; on économise aussi sur les modèles, lourds actuellement). Jack ma ^►discuter 12 janvier 2010 à 17:44 (CET)

Pour répondre à certains sujets évoqués ici :

• On ne doit plus parler de sous-pages mais de modèles. Consernant le poids occasionné par la création de ces modèles pour WP, le poid est quasiment nul, pour la simple raison que les données se trouvant avant dans l'article se retrouve dans la base de donnée. Par ailleurs la création des ces modèles va permettre d'éviter de recopier plusieurs fois les mêmes nombres sur plusieurs ou même articles.
• Concernant les articles de cantons, arrondissements, intercommunalités, départements, régions... grâces aux modèles des communes on peut créer un système qui calcul automatiquement la démographie de ces collectivités. Par conséquent, les modèles de population par ville vont servir également de base de donnée pour mettre à jour automatiquement dans les articles, les infobox des communes, des intercom, des départements, des régions... mais également des tableaux démographiques des communes, des intercom, des départements, des régions... ainsi que toutes les pages de liste de commune et autres équivalents pour des découpages administratifs supérieurs.
• L'usage d'un robot pour mettre à jour les données directement sur les articles peut marcher, c'est une idée qui se vaut. Par contre, il nous faut un dresseur de bot motivé dans le sens, où il va falloir le programmer plusieurs fois. En effet, les articles de communes, de listes, et les articles connexes n'étant pas harmonisés. Le robot va devoir être programmé une fois pour modifier toutes une série d'infobox. Ensuite, il va falloir trouver une solution pour mettre à jour les tableaux démographiques. A ce que j'ai compris les modèles du genre Démographie2 ou autre, ne sont pas utilisés uniquement sur des articles de communes, donc le dresseur de bot va devoir trouver une combine pour faire le tri automatiquement entre les articles de communes qui utilise ce type de tableau démographique et les articles qui ne portent pas sur une commune, j'ignore si c'est possible... Ensuite admettons que le bot à réussi à mettre à jour automatiquement l'ensemble des différentes infobox, l'ensemble des différents tableaux démographiques, soit environ une 15ène de modèles, maintenant il faut le reprogrammer pour qu'il mette à jour les articles de liste comme Liste des communes de la Charente-Maritime. Disons une 100ène pour les liste de communes classées par département, donc une nouvelle fois, il faut programmer le robot, faire en sorte qu'il sache récupérer les données sur les articles de communes n'utilisant pas les mêmes modèles d'infobox et de tableaux démographiques. Mais bon admettons que le robot réussisse là encore. A la sortie je pourrais continuer encore car la mise à jour peut déborder sur les articles connexes (intercommunalités...). Donc dans l'hypothèse du tout robot, on a le problème de la profusion de reprogrammations multiples à faire pour le bot et encore, je ne suis pas assez experte mais je ne suis pas certaine qu'il soit aisé de demander à un bot de faire le tri de tableaux utilisés exclusivement sur un article de commune française. Ensuite second problème qui reprend les propos précédent en terme de poid. Pour le coup, je ne vous raccompte pas le nombre de création de ligne d'historique supplémentaire que ça représente par articles. A chaque intervention sur une page, le robot laisse une trace. Encore dernièrement j'ai eut une discussion intéressante sur le fait que l'on ait pas le droit actuellement d'utiliser des bots pour faire du simple renommage de modèle. Donc là on a en plus du programme de programmation, on a le problème de poid.
• L'usage d'un bot facilité si l'on utilise les modèles de base de donné que je présente. En effet, le dresseur de bot ne devra en tout et pour tout programmer qu'une seule fois son bot pour qu'il récupère automatiquement les données depuis le site de l'INSEE pour ensuite les copier-coller dans nos modèles de base de donnée. Le dresseur n'a plus besoin d'une 20ène de programmes différents un seul devrait suffire. Par ailleurs, si l'on utilise un modèle comme {{Population Commune de France}} sur l'ensemble des articles alors on peut envisager la possibilité d'utiliser facilement un bot pour produire automatiquement des graphiques (histogrammes, courbes...). Ce serait un voie à explorer par la suite.
• S'agissant de l'exemple du tableau démographique automatisé {{Population Commune de France}}, je viens de l'améliorer encore un peu plus en y ajoutant le titre et les sources. De toutes façon on pourra ensuite continuer à améliorer ce modèle, ce n'est pour le moment pas le sujet centrale. Pour le moment il est important que chacun voit par lui même que le système fonctionne.

Si vous avez des questions ou autre, des précisions ? Je dois également vous dire que graces à ce système on peut également créer des modèles automatisés pour les articles comprenant des listes comme Liste des communes de la Charente-Maritime. Cela peut se faire facilement en reprenant en parti l'idée du système des modèles {{Élu}} couplés à nos bases de données...

Enfin pour rappel vous pouvez à présent faire des essais en utilisant les modèles {{Infobox Communes de France/essai}} (infobox automatisé) et {{Population Commune de France}} (tableau démographique automatisé) sur les articles Évry (Essonne) et Angoulins. Lorsque vous faites vos essai cliquez toujours sur « Prévisualiser ». amicalement--Wikialine (d) 12 janvier 2010 à 20:18 (CET)

Ce modèle me semble être très bien parti et me semble être une très bonne idée. Par contre je pense qu'il serait préférable de mettre les données de population en sous-page du modèle (donc de renommer {{Population Angoulins}} en {{Population Commune de France/Angoulins}} par exemple). Ça centraliserait davantage (du moins en apparence) les différentes composantes du modèle et en renforcerait le lien. -- Tzeentch ✉ 13 janvier 2010 à 15:15 (CET)

Créer des sous-modèles à des modèles non reliés directement, ce n'est pas conseillé. De plus ça va allourdir les scripts avec un nom plus long. Par contre, tu as raison de préciser qu'il faudra centraliser un peu plus ces modèles. Pour se faire le plus simple et ce qui est fait actuellement pour les autres mêmes séries de modèles (infobox, palette, géolocalisation...), tous ces sous-modèles seront centralisés au sein de catégories dédiées. De plus, je n'ai pas voulu trop surcharger les débats ici, mais la porté du système proposé ici peut parfaitement dépasser le cadre des communes de France. Je l'ai légèrement évoqué mais ces modèles pourront facilement servir par la suite de bases de données pour faire fonctionner des modèles automatisés pour les intercommunalités, les départements, les régions... Donc ces modèles à proprement parlé peuvent dépasser le cadre des communes de France. C'est pourquoi en terme de nommage, il faut reprendre les conventions actuelles de nommage. Pour faire simple (quelque soit les modèles), on doit de préférence commencer un nom de modèle par « Modèle: », puis ensuite préciser si ce modèle s'inscrit dans une série de modèles précis (si c'est une infobox alors ajouter avec une majuscule « Infobox », si c'est une palette alors ajouter de préférence « Palette », ....) donc pour nous « Population », et après cela on précise le sujet (pour les modèles de géolocalisation on doit inscrire le nom du lieu représenté comme le nom d'un Pays, région, département...), soit pour nous le nom de la commune et dans un soucis d'automatisation et pour des raisons techniques, le nom plus exactement de l'article de la commune. Ce qui donne au final un nom de modèle reprenant les conventions habituelles de nommage de modèles. Par ailleurs, nous sommes encore précursseur en la matière mais si notre expérience fonctionne bien, il y a des chances que d'autres projets emboitent le pas pour les articles de communes étrangères... Donc il n'est pas impossible d'étudier plus tard la possibilité de créer un Projet:Population... ce qui lierait encore un peu plus tous ces modèles. amicalement--Wikialine (d) 13 janvier 2010 à 15:59 (CET)

Et mettre les odnnées dans une sous-page du projet ou dans un nouveau espace de nom genre donnée: ou bdd:

Projet:Automatisation des données --Mokacchino (d · c) 15 janvier 2010 à 17:59 (CET)

Le mieux serait encore que WP mette en place un système autonome de BDD, passer par des sites externes à WP est à éviter, disons que jusqu'à présent c'était la règle, mais bon ça peut évoluer. Le système que je propose prend en compte ce soucis d'autonomie. amicalement--Wikialine (d) 16 janvier 2010 à 13:40 (CET)

Modification des infoboxes et des articles

Voir Modification des infobox - phe 11 janvier 2009 à 16:35 (CET)

Conclusion

Population communale

En cours de débats, aucune décisions n'est encore prise...

Autre donnée

Pas de débats en cours...

Article connexe

• Voir les discussions - Liste de tous les débats ayant eut lieu au sein du projet communes de France.