Aidez-nous à améliorer data.gouv.fr en répondant à notre enquête annuelle ❤️
République
Française
Données sur la localisation et l’accès de la population aux équipements
Description
Ce jeu de données produit par l’Insee permet de s’intéresser aux temps d’accès aux équipements, en utilisant comme source principale la base permanente des équipements (BPE). Il fournit, pour chaque carreau de 200 mètres de côté, sa population (issue du dispositif Filosofi) ainsi que la distance et la durée par la route le séparant de son équipement le plus proche, pour chaque type d’équipement de la BPE. Il s’appuie sur le distancier Metric-OSRM, qui permet des calculs de trajets routiers en voiture optimaux, de point à point, avec une grande rapidité d’exécution.
Les données sont mises à jour à chaque nouveau millésime de la BPE. La description complète du jeu de données figure dans la note méthodologique à télécharger ci-dessous.
Les bases sont au format parquet, partitionnées selon la région (variable reg). Un exemple de code R montre comment les exploiter à l’aide du package {duckdb}.
Dans les publications où elles sont utilisées, il est demandé de citer les sources des données comme suit :
Sources : Insee, base permanente des équipements, distancier Metric-OSRM, © les contributeurs d’OpenStreetMap et du projet OSRM
- Contacts
- Contact(Contact)
- Dernière mise à jour
- 16 juillet 2025
Vues
0
Téléchargements
0
Qualité des métadonnées:
Votre question porte sur autre chose que ce jeu de données ? Visiter notre forum
7 discussions
Proposition de correctif dans les métadonnées
"Latitude du point central du carreau de population (EPSG:3035 pour la métropole, EPSG:4559 pour la Martinique, EPSG:2975 pour La Réunion)",Numérique -> Plutôt Longitude. Idem pour le Y avec Latitude.
Autre correction suggérée : supprimer "reg" (Code région du carreau) des métadonnées car absent des données.
Merci
Idée de calcul pour "localisation et accès de la population aux équipements"
Bonjour. Cette donnée me semble particulièrement intéressante et utile à l'étude des potentiels entre population et équipements. Est-il envisagé un autre calcul qui serait la distance temps en transport en commun et la transport en commun ? Avec une notion de fréquence associée (nombre de trajets journaliers par exemple). Cela pourrait intéresser des urbanistes, des développeurs de solutions de mobilité, des gérontologues, des écologues, etc. Il existe des bases régionales (Atoumod) ou des API (je me souviens de Navitia) pour ce faire ? Merci.
Désolé pour l'erreur " (...) en transport en commun et la transport en commun ?" lire "en transport en commun".
C'est effectivement des sujets que nous avons en tête, mais nous n'avons pas de diffusion de données prévues à court terme
Au niveau de notre territoire (l'agence d'urbanisme du Havre, dans la région Normandie), je vais probablement faire un petit pilote avec le lien entre le carreau de 200m (centroide), et le professionnel de santé de recours 1 (médecin généraliste D201, officine de pharmacie D307, Kinésithérapeute D233 et l'infirmière D244). L'idée sera de calculer avec 1°) la desserte TEC, en temps, 2°) sa fréquence mais aussi 3°) la distance à l'arrêt de TEC le plus proche pour l'origine (centroide de population) ainsi que 4°) la distance à l'arrêt TEC le plus proche pour la destination (le professionnel de santé. Cela permettra de lever certaines carences en TEC dans cette desserte d'équipement absolument déterminante. Merci de votre suivi.
Je compte utiliser la base Atoumod. Cela pourrait être présenté en comité d'utilisateurs de la BPE de l'Insee.
Sources utilisées dans "localisation et accès de la population aux équipements"
Bonjour. Merci pour cette nouvelle source d'information à l'échelle fine (carreau 200m de Filosofi) que nous allons utiliser pour notre territoire (lot r28, Normandie). Dans le descriptif est évoqué " (...) le temps d’accès aux équipements, en utilisant comme source principale la base permanente des équipements (BPE) (...)". Quels sont les autres bases utilisées ? Merci beaucoup pour ce complément d'information.
Bonjour et merci pour votre retour ! Seules les données de population Filosofi sont utilisées en plus de la BPE pour la production de cette base.
Merci de votre réponse qui permet une mise en forme de nos données avec des contraintes avec la BPE 2023 d'une part et Filosofi 2019 d'autre part avec ce jeu de données.
Temps d'accès aberrants ?
Bonjour,
Et merci pour ce travail de mise à disposition d'une information aussi fine !
Nous nous interrogeons sur une possible problématique sur la pointe du médoc en Gironde (33).
Par exemple, pour la commune du Verdon-sur-Mer (idsrc : 3459600_2559400) le temps d'accès pour l'accès aux "EXPOSITION ET MEDIATION CULTURELLE'"(F312) et aux "Arts du Spectacle" (F315) sont d'environ 171 minutes (2h30) pour aller à Saintes. Ainsi pour les habitants concernés le temps d'accès à l'équipement le plus proche est plus élevé que pour aller à Bordeaux (dont on peut poser l'hypothèse qu'elle bénéficie de ces équipements).
Partagez-vous le constat ? Et si oui, pensez-vous qu'il soit possible de refaire tourner les calculs après ajustement de la méthode de détermination de la ressource la plus proche ? En effet, ici la gironde (fleuve) peut-être traversée via deux bacs (ferries) mais le pont le plus proche est à Bordeaux. Il me semble que c'est cette particularité qui conduit au problème.
En vous remerciant par avance,
Bonjour et merci pour votre retour,
Effectivement nous excluons les ferries du calcul car ils ne sont pas toujours bien répertoriés dans notre distancier et les temps ne sont pas toujours exacts. Cela entraîne quelques cas aberrants comme celui que vous avez signalé. Nous allons voir ce que nous pouvons faire pour la prochaine mise à jour.
Simon Beck
Merci de votre réponse,
la prochaine mise à jour étant sur la millésime 2024 ? ou des mises à jour sont envisagées au fil de l'eau ?
Bonjour,
Ce sera probablement à l'occasion de la production du millésime 2024 effectivement.
Simon Beck
Y a-t-il une inversion des coordonnées X et Y?
Bonjour et merci pour ce jeu de données,
Je fais des tests avec un des fichiers parquet (le fichier donnes-2023-reg24.parquet) et il semble qu'il faille que j'inverse le X et le Y dans la conversion en EPSG:4326 avec pyproj (libraire python de conversion) pour tomber sur les bonnes coordonnées lat,long.
Voici 3 colonnes de la 2ème ligne du fichier:
idSrc, X, Y
3749400_2713600, 3749400.0, 2713600.0
from pyproj import Transformer
transformer = Transformer.from_crs("EPSG:3035", "EPSG:4326")
transformer.transform(3749400.0, 2713600.0)
=>
(54.28212440267015, -15.270266734842929) # Ce qui n'est pas bon
transformer.transform(2713600.0,3749400.0)
=>
(47.273048465583074, 2.4366243900905733) # semble bon
Y aurai-t-il une erreur dans le fichier?
Bonjour,
Je ne maîtrise pas python, mais en lisant rapidement la documentation sur la fonction utilisée (https://pyproj4.github.io/pyproj/stable/examples.html#transformations-from-crs-to-crs), je me demande si selon les CRS, il ne faut pas donner le Y avant le X ? Est ce que le soucis pourrait venir de là ?
Je pense que dans un système de coordonnées projeté (type EPSG:3035) où les coordonnées sont des mètres, X est forcement la coordonnée dans l'axe Est-Ouest.
Etrange alors... il ne me semble pas qu'il y ait de soucis dans les données quand je les cartographie sous R... Avez vous essayer avec le paramètre "always_xy=True" ?
Effectivement, c'est bien correct, j'ai importé les données dans QGIS et il n'y a pas d'inversion entre X et Y. C'est donc bien quelque chose de bizarre avec la fonction transformer de pyproj.
Merci pour vos réponses,
Et effectivement, avec le paramètre "always_xy=True", ça marche correctement !
ah super :)
Diviser par 7 le volume des données ?
Merci pour cette mise en ligne spectaculairement riche !
Une suggestion.
Les fichiers parquet mis en ligne seraient en gros 7 fois plus légers en arrondissant 3 variables numériques à l'entier.
Comme il s'agit de mètres et de minutes, cela ne change pas grand chose, me semble-t-il, à la précision des données,
mais permettrait en revanche d'économiser beaucoup de place, et/ou de bande passante.
Exemple :
donnees-2023-reg76.parquet : 1,6 Go
donnees-2023-reg76_v2.parquet : 230 Mo
Exemple de conversion DuckDB :
COPY (
FROM 'donnees-2023-reg76.parquet'
SELECT * REPLACE (round(distance)::int AS distance, round(deuclidienne)::int AS deuclidienne, round(duree)::int AS duree)
) TO 'donnees-2023-reg76_v2.parquet' (compression zstd);
Ah, merci pour cette suggestion que nous n'avions pas en tête ! On va regarder ça et probablement le mettre en place si les résultats ne sont pas affectés.
Merci ! J'observe que la base nationale résultant de l'assemblage des fichiers régionaux pèse 2 Go en parquet, et reste manipulable avec vélocité. Intéressant en complément des extraits régionaux.
---------------- Extraction de toute la base
-- 1 liste des urls des fichiers parquet régionaux, via l'API data.gouv.fr
SET variable insee_urls = (
WITH t1 AS (
FROM read_json('https://www.data.gouv.fr/api/1/datasets/donnees-sur-la-localisation-et-lacces-de-la-population-aux-equipements/')
SELECT unnest(resources, recursive := true)
) FROM t1 SELECT list(url) WHERE format = 'parquet'
);
-- 2 assemblage et export vers un parquet unique optimisé (2 Go, 500 millions de lignes)
COPY (
FROM read_parquet(getvariable('insee_urls'), filename := true)
SELECT * EXCLUDE (filename) REPLACE (round(x)::int AS x, round(y)::int AS y, round(distance)::int AS distance, round(deuclidienne)::int AS deuclidienne, round(duree)::int AS duree)
, regexp_extract(filename,'reg(\d+)\.parquet',1) AS REG)
TO 'donnees-2023-insee_bpe_caro.parquet' (compression zstd) ;
Calcul de la population par carreau
Bonjour,
Merci pour cette nouvelle base de données.
Si j'ai bien compris les identifiants des carreaux ne sont pas uniques car si un carreau est à cheval sur 3 iris, on aura 3 enregistrements dans la base et dans chacun des enregistrements la population sera égale au tiers de la population du carreau (cf. " Par contre elle ne fournit pas d’information précise de localisation des populations en cas de carreau à cheval sur plusieurs IRIS ou plusieurs communes : on répartit donc celle-ci de manière homogène entre les différents croisements."). Par "homogène" on entend égale et non pas proportionnelle à la part de la surface du carreau intersectant chaque iris ?
Pour faire la jointure avec la table géographique des carreaux, il faut faire des regroupements (ou un first) sur les différents champs (hors depcom, iris, dep,reg) et faire la somme de la population.
Est-ce correct ?
Cordialement,
Gaëtan Gaborit
Bonjour, vous avez tout à fait compris ! Malheureusement nous avons été contraints sur ce point pour des raisons de secret.