Un fond de carte France par commune optimisé pour le web et l’analyse statistique

Je mets à disposition sur data.gouv.fr un fond de carte France par commune affiné pour la réalisation de cartographies thématiques, qu’elles soient diffusées en ligne ou à affiner dans un logiciel de dessin. Ce fond, dérivé de celui de l’IGN, est deux fois plus léger, homogène, rigoureusement topologique, utilisable France entière ou à l’échelle d’une région ou d’un département. Cet article explique à quels critères il répond et comment je l’ai préparé à partir de sources plus détaillées. 

Un fond de carte adapté à la datavisualisation se doit d’être élégant, compact et épuré. Il est au service des données statistiques détaillées qu’il va permettre d’exprimer de façon très visuelle. Il doit d’une certaine manière savoir s’effacer devant la donnée, dissimuler les détails inutiles, tout ce qui pourrait brouiller la compréhension immédiate des phénomènes exposés. Pour autant, chacun doit pouvoir reconnaître les territoires qui lui sont familiers, de près comme de loin. L’art de la généralisation consiste à trouver le meilleur compromis.

D’autres techniques sont présentées ici, comme placer un symbole au meilleur endroit au sein d’un territoire : le milieu n’est pas toujours là où on le croit !

C’est enfin une nouvelle occasion de mettre en avant la puissance et la richesse fonctionnelle de l’outil web gratuit mapshaperdéjà présenté dans ce blog. Cet outil est rapide et très efficace en matière de généralisation : il préserve parfaitement l’emboîtement des territoires qu’il simplifie.

Fond de carte France par commune au 1er janvier 2020

Le cahier des charges du fond idéal

La France est découpée en un peu moins de 35 000 communes, 34 968 exactement au 1er janvier 2020, département et régions d’outre-mer (Droms) compris, de la Guadeloupe à Mayotte. Il existe quantité d’indicateurs statistiques sur les communes. Pour les analyser dans l’espace géographique, on a besoin d’un fond de carte de ces communes, qui exprimera visuellement les phénomènes par des colorations, des symboles, voire des déformations géométriques. Mais quelles sont les caractéristiques idéales d’un tel fond de carte, dans une double optique de rigueur statistique et de diffusion tous médias ?

Il doit tout d’abord se conformer au Code Officiel Géographique (COG), tenu à jour par l’Insee. Un jeu de données se rapportant au maillage communal officiel au 1er janvier 2020 sera ainsi projeté sur un fond de carte décrivant exactement les mêmes communes, identifiées par les mêmes codes Insee.

Pour représenter la France dans son ensemble, les 5 « Droms » seront rapprochés de la métropole. Plutôt que créer des cartes séparées pour les assembler in fine sous forme de cartouches dans un logiciel de dessin, il est plus commode de partir d’une couche cartographique déjà aménagée.

Le degré de précision des tracés communaux sera optimisé en fonction de deux critères a priori adverses. Tout d’abord alléger la définition géométrique du fond de carte, ce que l’usager d’une carte interactive sur le web appréciera, elle se chargera plus vite et réagira de façon fluide à ses interactions. Mais aussi maintenir pour les géographes et habitants une morphologie reconnaissable et acceptable de leurs points de repère caractéristiques (estuaires, grandes îles…) ou de leur propre commune, quelle qu’elle soit. Une triangulation « à la Voronoï » n’est pas une option soutenable !

Simplifier les tracés d’un fond de référence très détaillé (Cadastre, BD Topo, numérisation collaborative…), c’est aussi ce que l’on nomme « généraliser ». Une bonne généralisation sera homogène dans l’espace et préservera l’emboitement parfait des contours. La qualité topologique d’un fond de carte se mesure à l’aune de la qualité des frontières entre deux territoires, qui doivent se dessiner en un tracé net, évitant toute béance ou recouvrement disgracieux. Un fond « parfaitement topologique » peut se décrire sous une forme allégée, à partir des frontières entre les territoires (les « arcs ») et non du tracé complet de chaque entité. Le gain de description (et donc de poids) est presque de moitié, chaque frontière n’étant décrite qu’une fois, ce qui procure une fluidité accrue en ligne. Outre le code Insee, le fond de carte embarquera quelques attributs normalisés : le libellé de chaque commune dans sa définition officielle, le code département, le code région. Des informations complémentaires s’avèreront précieuses pour habiller la carte ou dessiner certaines analyses : le statut administratif (permettant d’isoler des chefs-lieux, des capitales) et la localisation de la mairie (pour optimiser le centrage des symboles). Ce fond de carte idéal sera enfin gratuit, librement réutilisable, et disponible dès que de besoin, c’est-à-dire à l’officialisation d’un nouveau millésime de COG (en général vers le mois de mars pour la validation définitive, après recours éventuels).

2 sources majeures : IGN ou OpenStreetMap

La plateforme data.gouv.fr propose tout d’abord ce jeu de ressources OpenStreetMap :

  • export simple du 1er janvier 2020 (shp zippé, 222 Mo),
  • export de janvier 2019 (geojson simplifié zippé, 24 Mo).

Je considère d’abord le premier, qui correspond au millésime que je recherche (2020). Mais il a un poids considérable, il faudrait sérieusement le généraliser pour répondre à mon cahier des charges ! La précision des contours est parfois assez variable d’une commune à l’autre. Il présente aussi à plusieurs endroits des défauts topologiques, qui vont compliquer son exploitation (les regroupements géométriques seront entachés de scories).


Je note enfin qu’une commune (Bernwiller) a conservé son code d’avant 2016, qui n’est donc pas le bon (68031 => 68006).

La version 2019 simplifiée est dix fois plus légère, elle mérite examen, bien que plus ancienne. Sa qualité topologique est a priori excellente. En revanche, pour une dizaine de communes au moins, il y a écart avec le COG de 2019, des fusions n’ont pas été prises en compte.

En attendant une version simplifiée conforme au COG 2020 (remarques et suggestions transmises au gestionnaire), la piste « extrait OSM via data.gouv » doit donc être écartée.

Considérons la seconde option, celle du fournisseur public et historique, l’IGN. L’Institut Géographique National a longtemps diffusé un fond de limites administratives généralisées sous la dénomination Geofla qui, avant 2014, était particulièrement légère. L’Insee valorise encore cette ancienne version, en l’éditant chaque année au rythme des fusions et scissions. On peut trouver sur insee.fr un fonds communal 2020 (et même plusieurs) dans cette précision, mais il est présenté de façon incidente comme illustration du zonage des zones d’emploi 2020, et non en tant que fond communal que l’Insee s’engagerait à mettre en ligne chaque année après la validation du COG. Je ne peux donc retenir l’Insee comme source de diffusion officielle. Pourtant, le fond Insee, tout comme l’ancien Geofla, représente un beau compromis précision/légèreté/homogénéité. C’est un exemple dont j’aimerais me rapprocher.

Depuis 2017, la gamme ADMIN-EXPRESS, sous licence ouverte, a pris la place de Geofla à l’IGN. “Les données source du produit ADMIN-EXPRESS-COG sont mises à jour annuellement à la suite de la publication du COG par l’Insee.

Deux versions sont en réalité présentées dans ce paquet conforme au COG, la première à moyenne échelle correspond à la précision de la BD Carto, et la seconde, qui éveille bien évidemment mon attention, est “une version généralisée pour un usage de cartographie statistique en particulier.

ADMIN-EXPRESS-COG généralisé de l'IGN
constitue la meilleure base de travail

Considérons cet ADMIN-EXPRESS-COG simplifié :

  • il présente une excellente topologie et une belle homogénéité de généralisation ;
  • il est bien totalement conforme au COG 2020 (comme son nom l’indique) ;
  • il présente une couche de chefs-lieux avec la position de la mairie et le statut administratif des communes ;
  • il est encore un peu lourd (2 fois plus que la version Insee), mais je vais jouer à le généraliser.
Un œil averti détectera quelques divergences esthétiques d’avec Geofla : la représentation des principaux estuaires semble obéir à des règles différentes, et la commune d’Hyères a perdu les îles auxquelles j’étais habitué ! Rien en tout cas qui ne puisse s’affiner ! 

Pour situer les idées voici un tableau résumé du poids du fichier de géométries pour différents produits (mesure en Mo sur le fichier .shp) :

OSM détailOSM simplifiéIGN ADMIN-EXPRESS-COG simplifiéIGN ADMIN-EXPRESS-COGInsee
300354011517

Voici donc mon programme, en partant de ADMIN-EXPRESS COG « généralisé » :

  • le simplifier encore plus, en visant un poids d’une vingtaine de Mo, 
  • ajouter les îles d’Hyères, en m’aidant de la version plus détaillée,
  • rapprocher les Droms,
  • constituer une couche ponctuelle de centroïdes cohérents avec les limites communales,
  • redessiner l’estuaire de la Loire (cf. Annexe).

Tout cela avec le seul outil web mapshaper !

Dans le paquet ADMIN-EXPRESS-COG, je vais récupérer la version France entière en WGS84 et plus précisément les 3 couches COMMUNE (version standard), COMMUNE_CARTO (version simplifiée), et CHEF_LIEU_CARTO. Elles couvrent la métropole et les Droms.

Généralisation = simplification topologique des contours

J’utilise mapshaper pour conduire cette exploration. Après avoir récupéré ADMIN-EXPRESS-COG, je me rends donc sur mapshaper.org. Et je fais glisser d’un coup, à partir de l’explorateur de fichier par exemple, le paquet des 5 fichiers COMMUNE_CARTO.xxx dans le navigateur, par exemple dans la partie basse de l’interface pour un import rapide. La métropole et les 5 Droms s’affichent, en WGS84, soit une représentation longitude/latitude. Je vais d’abord opérer dans ce cadre et reprojeterai plus tard vers un système métrique.

Métropole, Antilles, Guyane, Mayotte et la Réunion
J’ouvre la console par le bouton en haut à droite, et colle le code suivant, qui va simplifier le fond de carte en en conservant que 40 % de ses sommets initiaux.
-simplify target=COMMUNE_CARTO 40%

La puissance de cette commande, et c’est ce pourquoi mapshaper a été d’abord conçu, c’est que la simplification/généralisation préserve la qualité topologique de la couche, c’est-à-dire ici l’emboitement parfait des communes. C’est tout simplement parce que les contours géométriques ont d’abord été décomposés en arcs frontières. Les arcs sont simplifiés, et les nouvelles communes reconstruites en tant que chaines ordonnées d’arcs. L’unicité des frontières est donc préservée.

Une commande comme -simplify commence par un tiret, le paramètre target précise la couche visée, pour le moment, je n’en ai qu’une. Voici un exemple pour illustrer le résultat d’une telle simplification. Le chef-lieu de cette commune se trouve (mairie) dans le petit morceau résiduel, que je tiens donc à garder. Préserver cette situation particulière est l’une des raisons qui me fait retenir ce facteur de 40 %, à savoir une simplification en gros de moitié. Si je poussais plus loin la généralisation, je perdrais un détail important.

Commune de Villefranche-de-Conflent (66)

Il faut restaurer le Mont-St-Michel !

Mais il se trouve que j’ai déjà perdu, même si je ne l’ai pas vu tout de suite, un détail très important. Parmi le groupe des communes françaises à la morphologie particulière (avec des trous, en plusieurs morceaux…), une se distingue et elle est mondialement connue, c’est celle du Mont-St-Michel, à l’étendue singulière puisque qu’elle comprend deux ensembles. Ma généralisation a effacé le Mont et sa digue-route, ce n’est évidemment pas tolérable, surtout pour un Normand comme moi !

Commune du Mont-St-Michel (50), en 2 parties avec la digue qui mène au mont.
Je supprime donc, via la liste au-dessus de la carte la couche COMMUNE_CARTO, recharge l’original par glisser-déposer, et applique cette fois-ci une généralisation différenciée, qui laissera intacte la commune du Mont-St-Michel, tout en simplifiant les autres !
-simplify variable percentage='INSEE_COM == "50353" ? "100%" : "40%"'

Rendons ses îles à Hyères

Les versions standard et simplifiée d’ADMIN-EXPRESS présentent la commune d’Hyères (83) de façon radicalement différente. Il est intéressant de rajouter à la comparaison la version encore plus simplifiée, sur le papier, qu’était Geofla : 

Hyères avec ou sans ses 3 principales îles
De nombreuses communes en France ont des îles en complément de leur territoire continental, il ne s’agit pas de toutes les représenter. Mais Porquerolles, Port-Cros et l’Île du Levant appartiennent à la physionomie familière du département du Var ou de la région Sud. Je vais donc rétablir la pratique antérieure, celle adoptée dans Geofla, en réintégrant ces 3 îles à la commune d’Hyères. Pour ce faire, je les récupère dans ADMIN-EXPRESS standard. Je charge donc la couche correspondante, COMMUNE, dans mapshaper, puis exécute les lignes suivantes :
-filter target=COMMUNE "INSEE_COM=='83069'" \
-rename-layers target=COMMUNE iles_hyeres \
-explode \
-filter 'this.area<15000000 && this.area>1000000' \
-simplify target=iles_hyeres 10%

Rappel ou précision : les commandes mapshaper s’écrivent si besoin sur plusieurs lignes avec le signe \ (précédé d’un blanc). Le paramètre target précise la couche que la commande précédente “cible”, par son nom, ou son n° d’ordre en partant du bas de l’empilement des couches à l’écran.

Après avoir extrait la commune d’Hyères dans une nouvelle couche “iles_hyeres”, je la décompose en polygones élémentaires (explode), dont je retiens les 3 îles principales par un filtre sur la superficie. J’applique enfin une forte simplification.

J’assemble désormais ces deux couches, celle de toutes les communes de France (sans les 3 îles) et celle des 3 îles. Hyères étant après cette fusion décrite par 4 objets, j’applique un dissolve qui rassemble toutes les composantes d’Hyères en une seule entité, multi-polygonale :
-merge-layers target=1,2 force name=a_com2020 \
-dissolve fields=INSEE_COM,NOM_COM,INSEE_DEP,INSEE_REG
Nous voici donc ramenés au fond communal 2020 avec ses 34 968 communes officielles, comme le confirme la commande -info. On verra que Hyères est en 1ère position dans la couche, ce que l’on peut améliorer en triant selon le code Insee :
-sort INSEE_COM

Reprojection et déplacement
des régions et département d'outre-mer

Notre fond de carte est actuellement très étendu et pour le rendre plus compact, je vais rapprocher les 5 Droms par une combinaison de translations et de mise à l’échelle. Je me ramène d’abord à un système de coordonnées métriques, dans la projection de Mercator (code EPSG 3857), celle adoptée par défaut par OpenStreetMap ou le Géoportail de l’IGN. J’aurais pu choisir la Lambert 93, mais pour une carte statistique cela n’a pas vraiment d’importance, la différence étant visuellement peu perceptible et sans intérêt analytique. Je privilégie ici la facilité de superposition avec les globes virtuels classiques. Mes choix d’ajustement pour les Droms sont évidemment discutables, mais au moins exposés, et donc ajustables. La Guyane est sensiblement réduite, mais reste visuellement plus importante que les autres territoires ultra-marins.
-proj webmercator \
-affine where="INSEE_COM.indexOf('971')==0" shift=6355000,3330000 scale=1.5 \
-affine where="INSEE_COM.indexOf('972')==0" shift=6480000,3505000 scale=1.5 \
-affine where="INSEE_COM.indexOf('973')==0" shift=5760000,4720000 scale=0.35 \
-affine where="INSEE_COM.indexOf('974')==0" shift=-6170000,7560000 scale=1.5 \
-affine where="INSEE_COM.indexOf('976')==0" shift=-4885000,6590000 scale=1.5
Régions et département d'outre-mer rapprochés de la métropole
Une transformation affine agrandit ou réduit (paramètre scale) en prenant par défaut comme centre de l’homothétie le milieu du rectangle englobant la zone (avant transformation). On obtient les coordonnées de ce point avec par exemple, pour la Guadeloupe :
filter 'INSEE_COM.indexOf('971')==0' + -rectangle -points -info
Ainsi, une écriture équivalente pour rapprocher la Guadeloupe, précisant le centre de l’homothétie (avant le déplacement) serait :
-affine where="INSEE_COM.indexOf('971')==0" shift=6355000,3330000 scale=1.5 anchor=-6835567,1825092
Elle nous sera utile par la suite quand il s’agira de déplacer les points centroïdes des communes de chaque Drom de façon cohérente avec le déplacement des communes, car le rectangle englobant ces points n’est pas le même que celui englobant les communes.
Je termine cette séquence par quelques aménagements cosmétiques (suppression et renommage de variables, tri) :
-rename-fields codgeo=INSEE_COM,libgeo=NOM_COM,dep=INSEE_DEP,reg=INSEE_REG \
-drop fields=NOM_COM_M,type,INSEE_ARR \
-sort codgeo

Préparation d'une couche de chefs-lieux
cohérente avec la couche des limites communales

En cartographie thématique, il est nécessaire d’associer à chaque commune un point-centre, qui servira par exemple à placer des symboles, comme un disque de surface variable, une forme simple, ou une étiquette. Certains outils ou packages s’en tiennent encore à un calcul assez rudimentaire de ce centre géométrique (cf. ci-contre).

Pour déterminer un tel « centroïde », plusieurs techniques sont mobilisables :

  • le milieu du rectangle englobant le territoire,
  • le barycentre des sommets du contour.

Pour aller plus loin, il convient :

  • d’identifier au préalable le polygone de plus vaste superficie dans une entité multi-polygonale et de retenir celui-ci comme siège du centroïde,
  • de vérifier que le résultat des calculs précédents est bien dans le polygone, sinon, proposer un point qui soit garanti à l’intérieur,
  • de faire en sorte que ce dernier point garanti à l’intérieur soit éloigné des bordures.

Mapshaper propose, vous vous en doutez, cet algorithme le plus abouti, avec la commande -points inner.

Mais quand bien même on atteindrait ce dernier critère, figurer la population d’une commune de montagne en plaçant un symbole dans une zone en réalité inhabitée n’est pas très pédagogique. Mieux vaut chercher à restituer la zone la plus probable de concentration de population. De ce point de vue, la position de la mairie délivre une localisation plus réaliste.
À droite, la concentration de la population dans cette vallée pyrénéenne est mieux figurée

ADMIN EXPRESS comprend précisément une couche d’entités ponctuelles, CHEF_LIEU_CARTO, qui représente la position des mairies de chaque commune. Je vais donc l’utiliser. Comme la documentation associée le précise : “Dans certains cas, le chef-lieu n’est pas dans la commune“. Cela fait partie des curiosités que nous allons (re-)découvrir ensemble. Commençons par faire glisser CHEF_LIEU_CARTO dans l’interface mapshaper.

Je pars de la couche appartenant au paquet initial, donc en WGS84, ce qui veut dire que les chefs-lieux des Droms sont à leur position géographique. Je dois donc, après reprojection, les rapprocher en utilisant les mêmes règles que pour les limites communales. Comme expliqué plus haut, le paramètre anchor est ici nécessaire, afin de centrer la mise à l’échelle de la même façon que pour les communes :
-proj webmercator \
-filter 'STATUT !="Arrondissement municipal"' \
-affine where="INSEE_COM.indexOf('971')==0" shift=6355000,3330000 scale=1.5 anchor=-6835567,1825092 \
-affine where="INSEE_COM.indexOf('972')==0" shift=6480000,3505000 scale=1.5 anchor=-6792785,1647381 \
-affine where="INSEE_COM.indexOf('973')==0" shift=5760000,4720000 scale=0.35 anchor=-5912255,437952 \
-affine where="INSEE_COM.indexOf('974')==0" shift=-6170000,7560000 scale=1.5 anchor=6181190,-2407474 \
-affine where="INSEE_COM.indexOf('976')==0" shift=-4885000,6590000 scale=1.5 anchor=5028338,-1439905
Chefs-lieux déplacés de façon cohérente avec les limites communales
Je procède maintenant à un appariement topologique avec le fond communal. À chaque point sera associée la commune qui l’englobe. Normalement, ce devrait être la même que celle qui est indiquée dans la couche des chefs-lieux. Pour en avoir le cœur net, pointons les écarts et visualisons-les par un cercle rouge :
-join a_com2020 fields=codgeo,libgeo unjoined unmatched \
-style fill='grey' r=2 where 'INSEE_COM==codgeo' \
-style fill='red' r=5 where 'INSEE_COM!=codgeo' \
-sort 'INSEE_COM==codgeo?0:1'
En rouge les mairies qui demandent vérification de concordance
Une trentaine de points appellent vérification, voire ajustement. Il y a des situations attendues, ces communes dont la mairie est, on le sait, située en dehors. Et d’autres qui probablement proviennent de la généralisation : une mairie qui figurait bien dans les limites communales d’ADMIN EXPRESS, n’y est plus après ma simplification à 40 %, parce qu’elle était toute proche des limites initiales qui ont un peu bougé. Je me réjouis tout d’abord de constater que la mairie du Mont-St-Michel est positionnée de façon cohérente avec la précision de mon fond de carte communal !

La jointure réalisé par Mapshaper a également isolé ces non concordances dans les couches unjoined et unmatched. Car de façon symétrique, des communes se retrouvent sans chef-lieu. Après analyse, 4 cas de figure se dessinent :
Pour toutes ces communes, sauf les 6 premières qui n’ont pas d’habitant, je vais déplacer le chef-lieu que je veux considérer comme un centroïde support de symboles, afin de le placer dans sa commune. Il s’agit d’un déplacement très marginal, que je peux réaliser directement dans l’interface de Mapshaper. Enfin, un peu de travail manuel !


Mapshaper propose opportunément une option “drag points” qui rend l’opération aisée et pour ainsi dire ludique. Je peux relancer de temps en temps ce jeu d’instructions, et voir mes points rouges disparaître les uns après les autres :
-drop fields=codgeo \
-join a_com2020 fields=codgeo \
-style fill='grey' r=2 where 'INSEE_COM ==codgeo' \
-style fill='red' r=5 where 'INSEE_COM !=codgeo'
Il me reste à stocker les coordonnées de ces centroïdes, car j’aimerais les injecter dans la couche des limites communales. Pour bien faire, je vais les calculer dans deux référentiels, celui de Mercator dans lequel je suis déjà, et WGS84 pour faciliter le traitement en GeoJSON. Au préalable, vérifions le nombre d’enregistrements de cette couche ponctuelle avec la commande info. Je note 35 421 points, alors que j’en attendais 34 968 – 6 = 34 962. C’est le signe qu’il y a des doublons (à signaler à l’IGN), que je vais éliminer avec la commande -uniq. J’en profite pour apprêter un peu mieux le résultat :
-info \
-rename-layers p_com2020=CHEF_LIEU_CARTO \
-uniq INSEE_COM \
-drop fields=ID,INSEE_COM \
-info
J‘aboutis bien à 34 962 points. Ajoutons 4 colonnes avec les coordonnées de ces points, dans les référentiels EPSG 3857 et WGS84 (EPSG 4326) :
-each "xcl3857=~~this.x;ycl3857=~~this.y" \
-proj wgs84 \
-each "xcl4326=this.x;ycl4326=this.y" \
-proj webmercator
Je peux maintenant ajouter à la table a_com2020 des limites communales les coordonnées de ces centroïdes. J’utilise un paramètre keys pour déclencher une jointure classique sur le code Insee (codgeo), et non une jointure topologique :
-target a_com2020 -join p_com2020 keys=codgeo,codgeo fields=xcl3857,ycl3857,xcl4326,ycl4326

Export de ces deux couches dans 3 formats pour servir différents usages

Pour stocker le résultat de mon travail, il me suffit de cliquer le bouton Export, et de choisir parmi les différents formats. Shapefile, GeoJSON et TopoJSON ont chacun leurs avantages :

  • Shapefile est un format binaire compact, le plus largement utilisé dans le monde des systèmes d’informations géographiques. Il s’agit d’un format propriétaire élaboré par Esri. Il est performant et rapide à charger, même pour de gros fichiers, et il encode les données dans la projection choisie. C’est donc un choix pertinent pour un fond de carte volumineux optimisé pour une projection particulière, ce qui est le cas ici. Exporté avec l’option precision=1, qui arrondit les coordonnées métriques à l’entier, il représente, zippé, 9 Mo. La plupart des logiciels cartographiques le lisent. L’inconvénient de ce format est qu’il recouvre en réalité un lot de 5 fichiers différents, mais on peut souvent charger le zip directement, par exemple dans QGIS ou dans… mapshaper
  • GeoJSON est un format texte, qui présente l’avantage d’être un standard ouvert (spécifié par un groupe de développeurs indépendants) et facilement lisible. Les fichiers sont en revanche plus volumineux, et la norme impose un encodage en WGS84 ;
  • TopoJSON est une extension du format GeoJSON mise au point par Mike Bostock, créateur de la librairie D3, qui valorise la décomposition topologique en arcs qui est aussi au cœur de mapshaper. Cela permet de produire des fichiers bien plus légers et donc plus facilement utilisables sur le web (notamment avec D3). L’outil Magrit, qui limite la taille des fichiers en entrée à 26 Mo (non zippés), pourra charger la version TopoJSON de notre fond de carte, mais pas la version GeoJSON.

Récapitulatif

J’ai donc élaboré deux couches cartographiques relatives aux communes françaises, dans le référentiel normalisé du Code Officiel Géographique 2020 :

  • a_com2020 : limites communales au 1er janvier 2020, simplifiées de moitié par rapport à la version originale ADMIN-EXPRESS, avec une définition proche de celle de l’ancien Geofla. Les Droms sont rapprochés. Cette couche comprend outre le code et le libellé officiel de chaque commune, quelques informations pratiques : département, région, coordonnées d’un centroïde pertinent.
  • p_com2020 : centroïdes / chefs-lieux des communes. Cette couche renseigne également le statut administratif, ce qui permet de sélectionner par exemple les chefs-lieux de régions pour les afficher comme couche d’habillage.

Ces deux couches sont disponibles, sous différents formats, sur la plateforme data.gouv.fr. Elles seront naturellement complétées avec les versions 2021 dès la parution d’ADMIN-EXPRESS-COG dans ce millésime (vers le mois de mars).

Pour visualiser France par commune directement dans mapshaper

Pour aller plus loin

J’ai eu beaucoup de plaisir pendant cette exploration à découvrir encore de nouvelles fonctions mapshaper. Alors que je pensais devoir en passer par QGIS pour certaines étapes, il s’est avéré que mapshaper savait, quasiment, tout faire ! En tous cas tout ce dont j’avais besoin. Son créateur Matthew Bloch vient même de me communiquer un bon tuyau sur la simplification conditionnelle. Voici donc quelques ressources additionnelles pour approfondir votre connaissance de cet outil. Je salue également la qualité des fichiers produits par l’IGN, dont l’expertise en matière de généralisation nous permet, depuis bien des années, de réaliser des cartes statistiques web-compatibles.

Annexe : aménagement de l'estuaire de la Loire

Les principaux estuaires sont dessinés de façon a priori illogique dans ADMIN-EXPRESS, plus cohérente dans Geofla. Geofla les évoque de façon claire, suffisante pour que l’on reconnaisse leur existence, mais sans chercher l’exactitude géographique, la limite de salure des eaux ou plus loin encore le trait de côte. ADMIN-EXPRESS simplifié présente toute la Gironde, évoque la Seine, et ignore la Loire. Plus curieux encore, ADMIN-EXPRESS simplifié est en réalité plus détaillé que la version standard dans le cas de la Gironde !

Intéressons-nous donc à la Loire, j’aimerais obtenir la découpe de droite, partant de la situation de gauche. Mon idée est de dessiner un pochoir, et de l’appliquer ensuite à mon fond communal.

Je sélectionne les communes en bordure d’Estuaire pour délimiter ma zone d’intervention, puis exporte cette sélection renommée com_loire au format geojson (j’applique au préalable une reprojection en WGS84 par -proj wgs84, car GeoJSON impose ce système de référence) :

Sélection manuelle de quelques communes

Mapshaper ne me permet pas de dessiner des formes géométriques libres (voilà, j’ai trouvé une de ses limites !), je vais en passer par un autre outil web gratuit : https://geojson.io/. Une fois ces communes chargées, je dessine par dessus mon pochoir :

Édition d'un pochoir avec geojson.io
Édition d'un pochoir avec geojson.io
Je supprime les communes qui m’ont servi de repérage pour ne conserver que le pochoir, que j’exporte à nouveau sous la forme d’un estuaire_loire.geojson, pour le charger dans mapshaper. J’applique une reprojection pour le superposer à ma couche communale à découper et je termine par un -erase :
-proj target=estuaire_loire webmercator \
-erase target=a_com2020 source=estuaire_loire
Fond communal avec l'estuaire de la loire redessiné
Fond communal avec l'estuaire de la loire redessiné

3 commentaires sur “Un fond de carte France par commune optimisé pour le web et l’analyse statistique”

  1. Merci beaucoup Eric pour ce partage!
    A noter que la représentation “illogique” de l’estuaire de la Gironde a déjà fait l’objet de quelques échanges de courriers entre administrations, mais à ce jour, d’après ce que j’ai compris, la raison industrielle l’a emportée sur les besoins des utilisateurs locaux.

    1. Merci beaucoup Bruno pour ta lecture attentive ! C’est intéressant de savoir que le débat sur la représentation des estuaires a été posé, je vais m’employer à le prolonger. Il me semble que Contours Iris a aussi une Gironde “comblée”.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.