Croiser les données spatiales pour gagner en précision

Une représentation précise de la population dans un système d'information géographique (SIG) revêt une importance particulière lorsqu'on s'intéresse à l'aménagement urbain, aux infrastructures de transport, aux équipements publics, à la gestion des risques ou celle des espaces naturels. Lorsqu'on est capable de situer la population dans l'espace, on peut aussi répondre à un tas de questions comme "combien de personnes âgées de plus de 75 ans habitent à plus de 300 m d'un transport public", "combien d'enfants de moins de 15 ans n'ont pas d'établissements scolaires à moins de 5 km", "combien de gens seront affectés par le bruit de la future rocade nord", "voit-on une corrélation entre la distance aux entreprises et les ménages à bas revenus", pour peu qu'on dispose dans le SIG de données sur la population et les entreprises.

De nombreux bâtiments (en jaune) de la ville de Nîmes sont soumis au risque d'inondation (zones bleues).

Carroyage de population + bâti cadastral = précision accrue

Les données carroyées de la population de l'Insee rendent la chose possible, je l'ai montré sur quelques exemples dans ce blog. La précision est de l'ordre de 200 mètres, la maille du carroyage. C'est assez fin pour faire des agrégats au niveau des quartiers (la subdivision IRIS). Je me suis demandé si on pouvait obtenir une meilleur précision pour évaluer l'exposition au risque d'inondation ou la distance d'une population à des services publics (transports, écoles, hôpitaux). J'avais observé des maisons, généralement anciennes, construites juste un peu en retrait de lits majeurs de rivières sujettes à des crues dans le Gard et dans l'Hérault. Ces maisons ne devraient pas être affectées par des crues ordinaires. Dans un SIG, la représentation de la population à l'échelle du carreau est trop grossière pour tenir compte de ces stratégies locales. La part des habitants affectés est calculée en appliquant la proportion de la superficie du carreau couverte par la zone inondable. Cette règle de trois marche bien dans beaucoup de cas mais sans doute assez mal si la population n'est pas répartie de façon homogène dans les carreaux.

Mon idée était donc de peupler le bâti du cadastre, une donnée géographique disponible librement depuis peu. Parmi les éléments du bâti, certains seulement sont des immeubles et tous ces immeubles ne sont pas des logements, c'est bien là où se situe la difficulté. On pourrait en première approximation répartir uniformément la population de chaque carreau dans le bâti qu'il contient mais on se retrouverait alors à peupler d'habitants des garages, des armoires électriques sur la voie publique, des entrepôts, des stades de foot, ce qui réduirait le gain de précision espéré. Il y a aussi la question de la surface habitable qui est fonction de la surface et du nombre d'étages, une donnée absente du cadastre.

 

Quels carrés jaunes sont des logements ?

Little Big Data

Pour estimer si un élément du bâti du cadastre est un logement, j'ai d'abord employé une série d'heuristiques basées sur des mesures géométriques pour exclure certains bâtiments publics, entrepôts, grandes surfaces. En croisant d'autres données spatiales, comme la vocation des IRIS, les IRIS A étant consacrés aux activités commerciales ou industrielles, on peut considérer que les grands bâtiments sont a priori des hangars. Pour estimer le nombre d'étages, j'ai fait une statistique au doigt mouillé sur la surface et les dimensions d'immeubles de logements. C'est un modèle assez rudimentaire, basé sur des observations, de nombreux tâtonnement et avec 0% d'IA.

L'algorithme a été réalisé en PL/PgSQL, il procède à une série de créations de tables à partir de jointures et de calculs sur les données d'origine pour ajouter à la couche du bâti un nombre d'habitants. La raison de ce découpage tient d'abord à la simplification du code, qui autrement aurait été extrêmement complexe à concevoir, à optimiser et à lire. Ensuite, entre chaque création de table, on peut créer des index GIST qui accélèrent considérablement le calcul.

Heuristique du logement

Les premières tentatives de validation sont encourageantes, j'obtiens des valeurs vraisemblables pour les villas, les grands ensembles et les immeubles en ville. En regardant de près la ville de Nîmes que je connais, j'ai trouvé des bizarreries, comme certaines tours d'habitations qui se retrouvent désertes, ou la Maison Carrée qui compte quelques habitants, ce que est une erreur manifeste. Mais le Carré d'Art, les Arènes et le Lycée Feuchère n'en ont pas, ils ont bien été pris en compte par mon algorithme. Agrégée au niveau de l'IRIS, la population localisée au cadastre présente des écarts avec les données de population des IRIS 2010 de l'Insee, mais moins que les calculs réalisés directement sur le carroyage.

Pour les autres données démographiques et économiques de l’Insee livrées avec le carroyage, on reste prudent. Ces chiffres sur la tranche d'âge, la taille du ménage, le statut de propriétaire ou le revenu fiscal déclaré par unité de consommation sont lissés à l'échelle de rectangles qui englobent plusieurs carreaux de population. Pour les affecter dans tels ou tels bâtiments avec plus de précision que cette échelle, il faudrait les croiser, encore, avec d'autres données.

Qu'est-ce qu'une jointure spatiale ?

Lorsqu'on fait la jointure de deux tableaux de données, on enrichit l'information initiale. Mais il faut pour cela trouver une clé de jointure, un identifiant commun et non ambigu, comme un numéro Insee de commune, le numéro SIREN des entreprises ou le symbole d'un élément chimique. Pour les données géolocalisées, la clé est une relation spatiale (inclusion, contact, distance) entre deux éléments. Concevoir cette clé nécessite un questionnement et un raisonnement géographique. Cette démarche, très simplifiée dans le cas illustré ici, peut faire intervenir des statistiques ou des modèles plus ou moins compliqués.