Aller au contenu

Discussion Projet:Communes de France/Archive186

Le contenu de la page n’est pas pris en charge dans d’autres langues.
Une page de Wikipédia, l'encyclopédie libre.
Autres discussions [liste]
  • Admissibilité
  • Neutralité
  • Droit d'auteur
  • Portail de qualité
  • Bon portail
  • Lumière sur
  • À faire
  • Archives
  • Commons

Cette page de discussion est une archive.

Pour intervenir sur les discussions actuelles ou pour en lancer une nouvelle, allez sur la page de discussion actuelle.

Modèle cartes interactive et OpenStreeMap

[modifier le code]

Hello,

Via Utilisateur:OrlodrimBot/Liens de fichiers brisés, j'ai retiré un certain nombre de ces modèles ({{Cartes interactive et OpenStreetMap}}), pour diverses raisons :

  • Dans tous les cas supprimés, parce que plusieurs des cartes appelées par le modèle n'existaient pas (le contributeur qui a ajouté le modèle à l'article n'ayant pas vérifié l'existence des 4 cartes)
  • Parce qu'avec les cartes de l'infobox et des communes limitrophes, ça fait 9 cartes en début d'article : ça contraint fortement la présentation du texte (une remarque également faite par Espandero (d · c · b) ici)
  • Parce que le modèle ne présente pas les cartes successivement, mais simultanément sur la version mobile (accès aux articles depuis un smartphone devenant compliqué)
  • Parce que le fait de présenter des cartes différentes via un même modèle, dont une interactive mais pas les autres, complique la compréhension de ce que l'on voit. Une carte à la fois, légendée, devrait être la règle - si nécessaire en galerie, mais en modèle c'est pénible.

Je ne veux pas reprendre ici une quelconque "croisade" contre les modèles, ce n'est pas le but, mais un modèle de cette complexité introduit de réelles vulnérabilités. Notamment, soit les modèles en jeu ne sont pas protégés et permettent donc à un vandale d'atteindre des dizaines, voire centaines d'articles en même temps. Soit ils le sont, réduisant les chances de modification et complexifiant l'édition. Et même un modèle protégé, s'il appelle des images qui ne sont pas directement visibles, rends un vandalisme particulièrement difficile à tracer. Par exemple, sur Bonnetan, n'importe qui peut télécharger une image en l'appelant File:Bonnetan OSM 01.png, et comme elle n'est pas directement visible, que cette modification n'apparaît pas dans l'historique de l'article, et que cette modification n'écrase pas un fichier pré-existant (vandalisme traçable sur Commons), ça peut rester des lustres dans l'article.

Je comprends bien que le but est à la fois pratique (donner accès à des cartes pertinentes) et esthétique, mais le sens de l'esthétique, qui est personnel, ne devrait pas primer sur la facilité de contributions et l'ouverture à tous (une édition complexe est rebutante et limite l'accès de fait à la modification). D'autant que le modèle est du coup parfois mal utilisé : j'entends par là (outre les cas, dont j'ai déjà fait grief, d'images absentes) que les contributeurs ajoutant ce modèle ne s'aperçoivent parfois pas qu'il y a déjà une carte interactive, ou une carte OpenStreetMap, qui remplit déjà exactement le même rôle. Est-ce que les articles sur les communes ont vraiment besoin de plusieurs cartes interactives par commune ? Ou est-ce que certains lecteurs et contributeurs ne s'aperçoivent pas qu'il suffit de cliquer sur la première carte pour pouvoir interagir avec, ou sur les flèches pour voir d'autres cartes, et donc ajoutent des cartes sans voir celles qui sont "cachées" dans l'animation ? D'autant qu'avec un format "animation", on s'attend à quelque chose en plusieurs étapes, démontrant un processus, pas juste une galerie sous un autre format.

Bref. Je voulais juste inciter à prendre un peu de recul sur ce modèle, et vous prévenir que j'allais continuer à le retirer là où il crée des liens rouges fichier incompréhensibles sur une version mobile.

Cordialement, Esprit Fugace (discuter) 4 août 2023 à 20:29 (CEST)

Notif pour user:Ccmpg créateur du modèle, et pour user:Roland45, user:AntonyB, user:RP87, user:Poudou!, user:Père Igor, user:Doique, user:JessydeVilly, user:Paternel 1, user:Sherwood6 que j'ai vu notifiés ou intervenir à divers degrés dans des discussions sur ce modèle, tracées via les pages liées. Esprit Fugace (discuter) 4 août 2023 à 20:29 (CEST)

Arrondissement d'Arras

[modifier le code]

Bonjour à tous. J'ai un problème de compréhension pour l'article Arrondissement d'Arras. Il commence par annoncer 358 communes depuis 2015 ici, puis, plus bas dans l'article, dans cette section, il est noté 357 communes ce qui correspond au chiffre donné par l'Insee. À noter que l'on trouve, pour la période après 2015, la commune de Galametz dans cet arrondissement et dans l'arrondissement de Montreuil !. Ne voulant pas faire d'erreur, je n'ai apporté aucune correction sachant que c'est peut-être moi qui ne comprend pas bien. Merci pour votre aide. Bien cordialement. Ltqphg (discuter) 5 août 2023 à 21:17 (CEST)

@Ltqphg Bonjour. Après vérification sur Admin Express (COG) :
  • le nombre de communes est bien de 357.
  • Galametz est dans l'Arrondissement de Montreuil et pas d'Arras ;
  • Il y a dans l'article deux sections redondantes « Composition de l'arrondissement après 2015 » et « Découpage communal depuis 2015 ». C'est la deuxième qui est correcte. La première est doublement fausse : en composition de communes (Galametz et Canteleux ne doivent pas être dans l'arrondissement) et en présentation. Depuis que les cantons ne sont en effet plus des subdivision de l'état (circonscriptions administratives), mais des circonscriptions électorales, les arrondissements n'ont pas à être découpés en cantons ou fractions de cantons. C'est d'autant plus perturbant que les arrondissements sont composés de communes entières et là on a l'impression qu'il y a des fractions de communes (qui en fait au final se rassemblent, mais c'est visuellement faux). La section « Composition de l'arrondissement après 2015 » doit être supprimée, selon mon point de vue.
Roland45 (discuter) 5 août 2023 à 23:11 (CEST).
Merci @Roland45 pour cette réponse argumentée et qui confirme mon message. Pour la correction qui me semble plus que nécessaire et pour laquelle je ne me sens pas compétent, existe-t-il un projet:Arrondissement qui pourrait faire cette correction ou un contributeur spécialisé ?. Bien cordialement. Ltqphg (discuter) 6 août 2023 à 11:47 (CEST)
J'ai fait un tir groupé pour le département de façon sommaire. Cdlt, Lyon-St-Clair [Hon hon hon] 6 août 2023 à 12:17 (CEST)

Graphique de population des communes nouvelles

[modifier le code]

Notification Roland45 et JessydeVilly : bonjour. Sur les communes nouvelles, le graphique présente toute une zone vierge sur la gauche, correspondant à une période antérieure au premier recensement (exemples Boulazac Isle Manoire#Démographie et Beaumontois en Périgord#Démographie). Comment faire pour supprimer cette anomalie ? Merci d'avance. Père Igor (discuter) 15 août 2023 à 21:26 (CEST)

Bonjour @Père Igor et @JessydeVilly. Je n'ai pas trop le temps de regarder, mais a priori, c'est une histoire de seuil et de largeur de barres et d'images. On a mis un seuil de 5 pour le nb minimal de barres (en dessous-de 5, pas de graphique, au-dessus un graphique). Mais le graphique est défini par une largeur fixe et la barre par une largeur maxi. Pour un faible nombre de barres, on a donc un espace blanc. Le module fonctionnant bien, il n'y a pas à revenir dessus. Le mieux dans le cas d'espèce me parait être tout simplement de ne pas afficher le graphique et d'utiliser {{Population de France/tableau}} au lieu de {{Population de France/section}}. Cordialement.Roland45 (discuter) 16 août 2023 à 11:51 (CEST)
Bonjour @Père Igor et @Roland45.
Je viens de jeter un œil au code du modèle Population de France. Il n'y a rien à corriger dedans. {{Population de France/section}} utilise le modèle {{Histogramme population manuel}} pour afficher le graphique.
J'ai testé en créant manuellement un {{Histogramme population manuel}} avec les données de Boulazac Isle Manoire et le décalage existe (voir le graphique et le code ci-dessous) et n'est pas lié à la largeur fixe du graphique.
S'il y a une correction à effectuer, ce sera au niveau du modèle {{Histogramme population manuel}}.
Évolution de la population de Boulazac Isle Manoire
Le code : {{Histogramme population manuel |titre=Évolution de la population de Boulazac Isle Manoire |largeur=710 |hauteur=340 |couleur-fond=rgb(1,1,1) |couleur-barres=rgb(0.7,0.9,0.7) |2016|1847 |2017|1846 |2018|1853 |2019|1842 |2020|1803 |nombre=5 |max=1803 }}
Cordialement, Jessy Oui ? 16 août 2023 à 13:35 (CEST)
Notification JessydeVilly : je n'y connais rien en programmation mais n'y a-t-il pas moyen d'ajouter un paramètre facultatif concernant l'année de création de la commune et qui influerait donc sur le graphique ? On dirait que les paramètres du graphique le font commencer dans les années 1990, par défaut, alors que le tableau, lui, est cohérent avec les données. Père Igor (discuter) 16 août 2023 à 14:39 (CEST)
@JessydeVilly Le modèle utilise bien Modèle:Histogramme population manuel dans lequel la largeur de la barre de donnée est définie par la formule suivant :
width:{{#ifexpr:ceil({{{largeur|600}}}/(3*{{{nombre|10}}}))>20|20|{{#expr:ceil({{{largeur|600}}}/(3*{{{nombre|10}}}))}}}}
Dans le cas qui nous intéresse (largeur=710), on a bien 710/1,5 >20 donc la largeur de la barre est 20 (valeur par défaut).
Pour l’affichage et le positionnement des barres, c’est ensuite le Modèle:Histogramme population manuel/BarData20 qui est utilisé. Par défaut le modèle affiche 20 barres. Ce qui explique ce pavé blanc.
En fait pour supprimer ces blancs (question de @Père Igor), il suffirait (je pense) de mettre un conditionnement sur chacune de ces 20 lignes dans ce dernier modèle (ou a minima sur les 15 premières). Mais ... je préfère ne pas me lancer !!Roland45 (discuter) 16 août 2023 à 15:30 (CEST)

Les records tombent

[modifier le code]

Bonjour à tous les records tombent pour les statistiques météo, que doit-on faire ? attendre les relevés météo france ou on laisse faire. ex Montauban, Agen, Albi, Narbonne ... --Paternel 1 (discuter) 24 août 2023 à 14:39 (CEST)

@Paternel 1 Les données météorologiques (records en particulier) sont (avec les données démographiques, mais pas uniquement) des données qui peuvent devenir obsolètes rapidement (annuellement, voire en cours d'année). Les données climatiques (normales climatiques) ont une durée de vie plus longue (10 ans). Ainsi oui, à un moment ou un autre, il faut actualiser, notamment les tableaux des stations météo qui figurent dans certains articles. Mais il faut savoir que la plupart de ces tableaux ne sont actuellement même pas actualisés avec les records de juillet 2022. Et pour cause, il y a 1741 stations en métropole et donc potentiellement le même nombre de tableaux à actualiser. Certains disposent d'un lien vers l'outil développé par @Jean-Christophe BENOIST (https://meteofrancetoclimat.toolforge.org) et de l'identifiant Météo-France, mais pas toutes. Et les formes des tableaux sont diverses. Donc cela peut être fait à la main. Mais il faut prendre son élan. Pour ma part, j'interviendrai avec un bot sur le sujet, mais ce ne sera pas avant plusieurs semaines.Roland45 (discuter) 25 août 2023 à 10:33 (CEST)
On peut mettre les records en textuel avant le tableau, mais on ne peut/doit pas changer les tableaux. Il faut attendre que cela remonte naturellement par les fiches météofrance. Tout à chacun, y compris une IP de passage, peut mettre à jour le tableau par https://meteofrancetoclimat.toolforge.org et c'est indiqué en commentaire dans le texte. C'est dommage en revanche que le bot ne soit maitrisable que par un seul d'entre nous. Il faudrait mettre en commentaire dans le tableau généré par le bot comment mettre à jour le tableau, par le même bot ou autre. Un problème potentiel aussi avec le bot, est que de nombreuses stations météofrance ont fermé en 2021/2022 (restrictions de budget je suppose), et le bot ne s'en apercevra pas. En mettant à jour manuellement on peut transférer à une station proche (je l'ai fait pour 2 ou 3 villes). Jean-Christophe BENOIST (discuter) 25 août 2023 à 10:56 (CEST)
Merci pour vos réponses, le plus gênant reste le nombre de sources utilisées qui ne sont pas toujours confirmées par Météo France. --Paternel 1 (discuter) 25 août 2023 à 12:47 (CEST)
@Jean-Christophe BENOIST Pour ne pas compliquer le message, je n'ai effectivement pas parlé des stations qui ont fermé. Il y en avait 1850 (de mémoire) et il n'y en a plus que 1741 (en métropole). Mais pour le coup cela ne gène aucunement le bot qui n'actualise que ce qui doit être actualisé à partir de la dernière liste de Météo-France.
Le bot, on lui fait faire ce que l'on veut. Si on veut ajouter tel ou tel texte, cela ne pose aucun problème. Pareil pour les données à afficher.
Pour la question du transfert à une station proche, ce n'est pas le principe que j'avais retenu. On n'affiche les données que des stations actives dans les communes où elles sont situées. Ainsi si une station ferme et que l'article a un tableau météo, il restera tel quel et ne sera pas actualisé. Par contre dans la commune où se situe la nouvelle station, le nouveau tableau ne sera affiché que si on est dans une démarche complète d'actualisation de la section. Si ce n'est qu'un passage pour actualiser les tableaux existants, il ne sera pas ajouté (même si on peut très bien aussi envisager de l'ajouter tel quel, brut).
Pour l'affichage des données, j'ai fait à titre d'exemple un tableau comparatif sur la commune de Montauban entre les deux tableaux (existant dans l'article (toolforge) et celui généré par le bot. On voit qu'il y a des différences d'affichage des dates et des données (pour ne pas alourdir, le n'avais pas retenu les nombres de jours avec précipitations ≥ 1 mm, ≥ 15 mm et ≥ 10 mm).
Pour le bot, désolé mais j'ai l'impression qu'il n'y a pas grand monde qui maîtrise le VBA. Et pour ma part, je ne maîtrise pas le Python, ou tout autre langage structuré, ce qui pourrait rendre les bots plus universels.
@Paternel 1 Les seules données officielles sont celles de Météo-France. Ainsi, pour Montauban, ni la version du tableau actualisée au 23/08 ni celle actualisée au 24/08 ne sont correctes, pour les bonnes et seules raisons que le tableau est sourcé avec la fiche Météo-France arrêtée au 6 août 2023. Elles ne sont peut-être pas fausses en tant que telles, mais leur présentation est fausse. On pourrait rajouter une source complémentaire dans le tableau (média national), mais là on complique sérieusement les présentations.
Pour actualiser, il est donc souhaitable d'attendre le 6 septembre avec les nouvelles fiches de Météo-France. Voire un peu plus tard. On n'est quand même pas à quelques jours près.Roland45 (discuter) 25 août 2023 à 16:22 (CEST)
Il y a de nombreuses villes importantes (et de plus en plus avec la raréfaction) qui n'ont pas de station météo "intra muros", on a très souvent des stations proches (par exemple Lille, c'est l'aéroport extra-muros, et les stations "proches" sont dans l'ordre de grandeur de distance de cet exemple). Et les stations qui disparaissent sont souvent des stations "proches" : pourquoi laisser dans une ville une station "proche" figée en 2021, et ne pas migrer vers une autre station proche ? Pour la maitrise, je n'ai pas parlé de la maitrise des scripts, mais de la maîtrise de la regénération des tableaux. Qui peut le lancer ? Tout à chacun, même une IP de passage, peut regénérer par toolforge quand il estime que le tableau est obsolète. Jean-Christophe BENOIST (discuter) 25 août 2023 à 16:32 (CEST)
@Jean-Christophe BENOIST Pour la question de l'affichage du tableau météo sur uniquement la commune où elle est ou bien sur les communes environnantes, je me la pose depuis très longtemps. J'ai un exemple simple : Orléans. La station de référence est en fait située à Bricy (voir ici), même si elle se nomme Orléans-Base aérienne, mais elle est à 14 km du centre-ville. Faut-il donc la mettre uniquement sur Bricy, sur Bricy et Orléans, sur toutes les communes d'Orléans métropole, sur toutes les communes dans un rayon de 20 km autour de Bricy ? Devant la complexité de la chose, le plus simple est de ne retenir que la commune de localisation (d'autant qu'en multipliant les tableaux on multiplie les actualisations nécessaires - Ce qui d'ailleurs a pas été fait dans le cas d'Orléans-Bricy, mais parce que le bot n'est pas passé sur le Loiret. Noter que le bot qui génère le texte complet (texte section + tableau) donne bien la localisation de la station la plus proche et renvoie donc bien vers l'article de la commune, mais un plus serait de renvoyer vers le texte de la section climat de l'article où est ladite-station.
Pour la régénération des tableaux tout un chacun peut regénérer par toolforge quand il estime que le tableau est obsolète, le texte masqué est explicite (même si actuellement les 2 tableaux sont légèrement différents).Roland45 (discuter) 25 août 2023 à 16:53 (CEST)
Mais dans ce cas, il faudrait que le tableau généré par le bot suggère en commentaire/texte masqué de regénérer le tableau par toolforge s'il est jugé obsolète (ou coincé sur une station fermée Émoticône). Je ne crois pas que cela soit le cas actuellement. Jean-Christophe BENOIST (discuter) 25 août 2023 à 17:26 (CEST)
@Jean-Christophe BENOIST Oui, la phrase de conseil est actuellement absente. Je la rajouterai. Pour l'actualisation, je me demande s'il ne va pas falloir attendre ... le 6 octobre, car on risque d'avoir encore des records de battus cette semaine (pas absolus, mais pour septembre)!Roland45 (discuter) 2 septembre 2023 à 18:05 (CEST)
Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Discussion_Projet:Communes_de_France/Archive186&oldid=219952907 ».