2.1.1 Présentation générale

L’offre de transport théorique dans un territoire peut être étudiée à partir de données croisant les itinéraires (organisation des parcours et localisation des arrêts) et les horaires de passage des véhicules.

Deux formats de données statiques sont privilégiés :

• NeTEx (Network Timetable Exchange), répondant aux critères établis par le Comité européen de normalisation en électronique et en électrotechnique

• GTFS (General Transit Feed Specification), répondant aux critères spécifiques des flux Google Transports en commun public. Les données doivent être validées par le validateur GTFS de Google.

2.1.2 Exemple des données de Montpellier 3M

Nous utiliserons dans ce tutoriel le cas de la métropole de Montpellier. La métropole est constituée de 31 communes comptant 499 761 habitants en 2020 (INSEE RP2020). Elle détient la compétence d’autorité organisatrice des mobilités (AOM) sur son ressort territorial et opère 4 lignes de tramway et 41 lignes de bus. Cet exemple servira d’illustration des méthodes présentées dans cette fiche afin de disposer d’un cas d’étude simplifié, mais d’autres échelles territoriales sont bien sûr possibles en ajoutant les données de l’offre en adéquation avec l’échelle d’analyse (offre régionale, ferroviaire, autres AOM locales, etc.). Les données renseignant l’offre de transport théorique de TAM (Transports de l’agglomération de Montpellier) sont fournies au format GTFS depuis le point d’accès national aux données de transport, et peuvent être converties au format GeoJSON et au format NeTEx directement depuis le site de téléchargement.

L’extraction des données utilisées pour ce tutoriel a été réalisée le 27 mars 2023. Elles décrivent l’offre de transport de façon statique pour la période s’écoulant du 16 mars 2023 au 14 mai 2023. Les données utilisées pour ce tutoriel ont été actualisées pour la dernière fois à la date du 25 mars 2023.

Le dossier contient différents fichiers au format texte, renseignant chacun une partie du système de transport sous la forme d’un tableau de données utilisant des virgules comme séparateurs de colonnes :

• agency : le fichier contient des informations sur les compagnies (agences) de transport en commun opérant sur le réseau étudié (ex : identifiant, nom, site Web, téléphone, fuseau horaire…)

• routes : le fichier catalogue les lignes du réseau de transport, qu’il décrit par le biais d’identifiants et de noms courts ou longs, par type de transport, par mode de ramassage et de descente, et d’autres informations plus ou moins formalisées. Une couleur peut être associée à une route afin d’en faciliter le repérage par les utilisateurs

• trips : le fichier décrit les itinéraires réalisés sur les routes (lignes), notamment par le biais d’informations sur les sens de déplacement et les dates de service (blocks). Plusieurs trips peuvent donc avoir lieu sur une même route

• stops : le fichier identifie, nomme, géolocalise (coordonnées lat/long) et caractérise (ex : type d’arrêt, identifiant de l’emplacement parent, accessibilité aux personnes en fauteuil roulant…) les arrêts du réseau

• stop_times : le fichier renseigne, pour chaque itinéraire (trip) concerné, les heures de passage (arrivée et départ) à l’arrêt. Des informations sur les modes de rammassage/descente, l’affichage sur les panneaux et d’autres caractéristiques des arrêts sont proposées. L’ordonnancement des passages aux arrêts pour un itinéraire particulier est également consigné

• transfers : le fichier est optionnel. Il permet de spécifier les règles de transit entre deux arrêts, en termes d’éloignement géographique et de durée de déplacement à pied, ou, comme avec les données de la TAM, sous la forme d’une variable catégorielle qui renseigne sur la possiblité de réaliser un transfert entre deux arrêts (transfert recommandé, programmé, possible sous contrainte de temps ou impossible)

• calendar : le fichier recense les dates pour lesquelles un service est fonctionnel : une date de début et une date de fin indiquent la plage de dates d’activité du service, et, pour chaque jour de la semaine (lundi à dimanche), une variable renseigne sur la disponibilité (ou l’indisponibilité) du service pour l’ensemble des lundis (resp. mardis, mercredis, jeudis, vendredis, samedis et dimanches) de la plage

• calendar_dates : le fichier renseigne sur les exceptions au service régulier consigné dans le fichier calendar. Il peut par exemple servir à indiquer les changements d’activité du service (ajout ou suppression) du fait d’un événement particulier, ou pour s’adapter à un calendrier scolaire.

De nombreuses dépendances existent donc entre les différents fichiers constituant la base de données GTFS, et ces fichiers peuvent être plus ou moins nombreux comme l’illustre le diagramme de classe proposé sur la page Wikipédia associée et reproduite ci-dessous.

2.2.1 Téléchargement des données depuis la Geofabrik

La société allemande Geofabrik GmbH propose au téléchargement des instantanés de la base de données OSM pour un espace géographique donné. L’échelle géographique la plus fine correspond aux anciennes régions françaises. Les données décrivant la métropole de Montpellier Méditerranée sont donc contenues dans le paquet décrivant le Languedoc-Roussillon.

La bibliothèque osmextract permet de télécharger et d’importer facilement des données OpenStreetMap de Geofabrik et d’autres fournisseurs depuis R.

library(osmextract)

Nous allons utiliser le fichier décrivant les limites de la métropole de Montpellier Méditerranée afin de créer un filtre spatial lors du téléchargement des données OSM depuis la Geofabrik. Pour cela, nous l’importons dans le projet en cours via la fonction st_read() de la bibliothèque sf.

Le fichier GeoJSON décrivant le territoire de la métropole de Montpellier est disponible ici :

Télécharger les données

library(sf)
epci_3m <- st_read("data/EPCI_MONTPELLIER.geojson")

La fonction oe_get() de la bibliothèque osmextract permet d’associer par le biais d’une relation d’appartenance géographique un lieu d’entrée (option place) avec l’URL du fichier .osm.pbf correspondant (dans le cas de la métropole de Montpellier, il s’agit de l’ancienne région Languedoc-Roussillon), qu’elle enregistre dans une liste puis télécharge. Le paramètre boundary permet d’associer un filtre spatial à la requête, et de ne télécharger que les objets contenus dans les limites géographiques désignées (et renseignées au format sf/sfc/bbox). Notons que la fonction appelle en interne la fonction oe_vectortranslate() qui converti le fichier .osm.pbf en fichier geopackage (.gpkg) avant de le lire. Le filtre spatial ne s’applique que sur le fichier .gpkg qu’elle télécharge, et pas sur le fichier .osm.pbf étant lui aussi téléchargé. Des options d’enregistrement du fichier peuvent être ajoutées, par exemple afin de forcer la mise à jour si le fichier a été téléchargé auparavant (paramètre force_download) ou pour indiquer le chemin d’accès du répertoire dans lequel enregistrer le fichier (paramètre download_directory) en remplacement de la valeur par défaut (répertoire temporaire).

contours_3m <- st_as_sf(st_union(epci_3m))

osm_3m <- oe_get(place = contours_3m, 
                      boundary = contours_3m, 
                      force_download=TRUE, 
                      download_directory=getwd())

Notons qu’il est possible d’extraire les données OSM au format .pbf depuis une source externe, comme le propose le site BBBike extract par exemple. Le site permet notamment de définir un cadre de délimitation (bounding box) pour les informations spatiales à télécharger, ce qui réduira a posteriori la taille du graphe construit pour lancer les requêtes OTP.

2.2.2 Description des données .osm.pbf

Le format des données ainsi téléchargées (Protocolbuffer Binary Format) est spécifique au projet OpenStreetMap, mais utilise le format de sérialisation de Google pour produire un fichier au format binaire. Il permet de regrouper des informations multiples (entités, objets, tuiles) de façon indépendante.

Par curiosité (mais cela n’est pas une étape nécessaire pour la mise en oeuvre de la chaîne de traitements), on peut importer les couches d’information géographique souhaitées une à une ou de façon groupée via la fonction st_read(), en spécifiant la couche (organisée par type de géométrie) et en créant une requête sur les attributs, par exemple en sélectionnant les routes (key = highway) dans la couche.

osm_highways <- sf::read_sf("geofabrik_languedoc-roussillon-latest.osm.pbf", 
                            query = "select highway from lines")

2.2.3 Utilisation des tags OSM pour les itinéraires routiers

OTP permet de définir un ensemble de critères pour décider quand une rue est autorisée aux piétons, aux vélos ou aux voitures. Par défaut, OTP utilise les tags OSM et considère que :

• les mobilités piétonnes et cyclables ne sont pas autorisées sur les routes décrites comme highway=trunk, highway=trunk_link, highway=motorway, highway=motorway_link, ou highway=construction

• les mobilités piétonnes et cyclables sont toutes les deux autorisées sur les routes décrites comme highway=pedestrian, highway=cycleway, et highway=footway

• les vélos ne sont pas autorisés sur les routes de type highway=footway lorsque lui sont associées les étiquettes suivantes : footway=sidewalk, public_transport=platform, ou railway=platform.

Depuis la version 2 d’OTP, le logiciel permet de définir des niveaux de sécurisation des routes pour les trajets piétons et cyclables en fonction des tags OSM. Ces options ne sont pas intégrées dans la version 1.5 du logiciel mobilisée dans la librairie R faisant l’objet de cette fiche.

3.2.1 Création du répertoire

OTP est distribué sous la forme d’un unique fichier .jar (Java ARchive) exécutable de façon autonome. Dans un premier temps, nous allons créer le répertoire dans lequel l’enregistrer.

La fonction file.path() permet de spécifier le chemin d’accès vers un fichier en concaténant des chaînes de caractères. Par défaut, le séparateur utilisé est “/”.

path_data <- file.path("data/OTP")

3.2.2 Pré-construction du fichier .jar

La fonction otp_dl_jar() de la bibliothèque opentripplanner télécharge le fichier JAR (Java Archive) d’OTP. Par défaut, le fichier JAR est caché dans un sous-répertoire de la bibliothèque. Si l’on souhaite spécifier la localisation du fichier .jar, il faut en indiquer le chemin d’accès (path =) et spécifier que l’on ne souhaite pas utiliser le cache par défaut (cache = FALSE).

download_otp <- otp_dl_jar(path = path_data, cache = FALSE)

Il faudra penser à commenter cette ligne de code une fois le téléchargement réalisé afin de ne pas le ré-exécuter à chaque relance du script.

Si le téléchargement du fichier via R ne fonctionne pas, vous pouvez télécharger manuellement le fichier depuis le dépôt maven.

On indique ensuite dans un vecteur au format “caractères” le chemin d’accès complet vers l’archive d’OTP :

path_otp <- paste(path_data, "/otp-1.5.0-shaded.jar", sep = "")

4.5.1 Créer manuellement les fichiers de configuration

OTP permet de configurer les options de déplacement à prendre en compte lors du déploiement de l’application (version personnalisée d’OTP) à l’aide de trois types de fichiers au format JavaScript Object Notation (.json) :

• build-config.json renseigne les éléments indispensables à la génération du graphe, par exemple en spécifiant les fichiers GTFS sources pour différents systèmes de transports en commun fonctionnant sur le territoire ou en indiquant que l’on souhaite que les transferts entre arrêts d’une même station de transport (par exemple, de métro) soient privilégiés :

• router-config.json contient des options de configuration d’exécution mobilisées lors du setup (i.e. otp_setup()) qui peuvent donc être modifiées une fois le graphe construit. On peut par exemple spécifier les durées maximales de recherche d’un itinéraire et de ses alternatives avec l’option timeouts ou modifier le sens de circulation par défaut sur le réseau routier par l’option driveOnRight: false :

• otp-config.json contient des commutateurs simples qui activent ou désactivent les fonctionnalités à l’échelle du système. La plupart des applications ne nécessitent pas la modification de ce fichier.

De nombreux paramètres peuvent ainsi être ajoutés dans le fichier de configuration du serveur OTP (voir la présentation en ligne). Des exemples de fichiers de configuration sont disponibles en ligne. Notons toutefois qu’OTP fournit des valeurs par défaut qu’il définit comme raisonnables. Les trois fichiers sont donc optionnels, tout comme les options à l’intérieur de chacun.

4.5.2 Modifier les paramètres via des fonctions R

La bibliothèque opentripplanner propose plusieurs fonctionnalités afin de faciliter la configuration de l’instance OTP.

La fonction otp_make_config() crée un fichier de configuration, de type router, build ou otp.

router_config <- otp_make_config(type = "router")  

Le fichier est organisé sous la forme de quatre listes, comprenant chacune un ensemble d’objets :

• $routingDefaults : liste la série de paramètres par défaut, par exemple la vitesse de marche ($routingDefaults$walkSpeed)

• $boardTimes : liste les paramètres de configuration des temps d’embarquement par mode de transport

• $alightTimes : liste les paramètres de configuration des temps de démarrage par mode de transport

• $timeouts : liste les délais maximums de calcul des 1er, 2e, 3e, etc. itinéraires.

router_config$routingDefaults$walkSpeed <- as.numeric(0.84)

router_config$routingDefaults$bikeParkTime <- as.integer(120)

La fonction otp_validate_config() génère des tests de validité d’un l’objet de configuration. Un problème régulièrement rencontré est l’erreur de typage des paramètres de la fonction (integer, numeric, etc.).

otp_validate_config(router_config)

Une fois le paramètrage du fichier de configuration finalisé, la fonction otp_write_config() permet de l’exporter au format JSON.

otp_write_config(router_config,                
                 dir = path_data,
                 router = "default")

Les configurations du routeur sont prises en compte lors du lancement du serveur OTP et ne peuvent être mobilisées alors qu’une session est en cours. Nous allons donc nous déconnecter puis nous reconnecter à l’instance locale d’OTP pour pouvoir en tenir compte lors de nos analyses.

otp_stop()

otp_setup(otp = path_otp, dir = path_data, router = "default")

my_otpcon <- otp_connect(timezone = "Europe/Paris", router = "default")

6.1.1 Localiser les différentiels d’accès à un lieu selon un mode de déplacement

La fonction otp_isochrone() génère des cartes d’isochrones en fonction d’un mode de transport (ou de la combinaison de plusieurs modes). Les paramètres de la fonction sont identiques à ceux utilisés pour générer des itinéraires, à l’exception de l’argument cutoffSec qui permet de définir les bornes maximales de chaque intervalle de temps, en secondes (les valeurs doivent donc être multipliées par 60 pour représenter des temps en minutes, par 3 600 pour représenter des temps en heures, etc).

iso_gareStRoch <- otp_isochrone(otpcon = my_otpcon,
            fromPlace = c(3.880727, 43.604937),
            mode = c("WALK", "TRANSIT"),
            maxWalkDistance = 2000,
            date_time = as.POSIXct("2023-04-25 08:00:00"),
            cutoffSec = c(15, 30, 45, 60, 75, 90) * 60) 

Nous pouvons utiliser les fonctionnalités de cartographie interactive proposées par la bibliothèque leaflet pour R afin de donner à voir le résultat. Pour retrouver des temps de déplacement en minutes, nous créons une variable transformant le temps de déplacement associé à l’isochrone (donné en secondes) en le divisant par 60.

iso_gareStRoch$minutes = iso_gareStRoch$time / 60 

Les isochrones de distance représentant des intervalles de temps de déplacement, nous allons d’abord construire la variation de teintes représentant ces différences d’ordre de grandeur.

mycol_2 <- colorFactor(
  palette = 'Reds',
  domain = iso_gareStRoch$minutes
)

Nous utiliserons la fonction addPolygons() afin de figurer les isochrones sur le fond de carte, en introduisant de nouvelles options de mise en forme :

• stroke = FALSE : permet de retirer les contours des polygones

• smoothFactor : définit le niveau de simplication des géométries en fonction du zoom

• fillOpacity : contrôle le niveau d’opacité (resp. de transparence) du remplissage.

Avant de créer la carte, nous téléchargeons les lignes de tramway de la métropole de Montpellier (format shapefile) afin de faciliter l’interprétation des résultats :

Télécharger les données

tramway <- st_read("data/MMM_MMM_LigneTram.shp")
tramway <- st_transform(tramway, 4326)

leafMap <- leaflet(data = iso_gareStRoch) %>%
  setView(lat = 43.604937, lng = 3.880727, zoom = 10) %>%
  addPolygons(stroke = FALSE,
              color = ~mycol_2(minutes),
              smoothFactor = 0.2,
              fillOpacity = 1) %>%
  addProviderTiles(providers$CartoDB.Positron)

leafMap <- leafMap %>%
  addPolylines(data = tramway,
               opacity = 1,
               weight = 4,
               color = ~factor(num_exploi, levels = c(1, 2, 3, 4), 
                               labels = c("blue", "#c51b8a", "green", "brown")))

leafMap

Nous allons également ajouter une légende afin de faciliter la lecture de la carte.

mycol_3 <- colorFactor(
  palette = c("blue", "#c51b8a", "darkgreen", "brown"),
  domain = tramway$num_exploi)

leafMap <- leaflet(data = iso_gareStRoch) %>%
  setView(lat = 43.604937, lng = 3.880727, zoom = 10) %>%
  addPolygons(stroke = FALSE,
              color = ~mycol_2(minutes),
              smoothFactor = 0.2,
              fillOpacity = 1) %>%
  addProviderTiles(providers$CartoDB.Positron) %>%
  addLegend("bottomright", pal = mycol_2, 
            values = ~minutes,
    title = "Temps d'accès",
    labFormat = labelFormat(suffix = " min"),
    opacity = 1)

leafMap <- leafMap %>%
  addPolylines(data = tramway,
               opacity = 1,
               weight = 4,
               color = ~factor(num_exploi, levels = c(1, 2, 3, 4), 
                               labels = c("blue", "#c51b8a", 
                                          "darkgreen", "brown"))) %>%
  addLegend("bottomleft", pal = mycol_3,
            values = tramway$num_exploi,
            title = "Lignes de tramway",
            opacity = 1)

leafMap

6.1.2 Comparer cartographiquement les différentiels d’accès à un lieu entre deux modes

Nous pouvons aussi choisir de superposer les isochrones de temps de déplacement à vélo sur la carte, et proposer à l’utilisateur de basculer d’une représentation à une autre grâce au paramètre group proposé par leaflet.

iso_gareStRoch_velo <- otp_isochrone(otpcon = my_otpcon,
            fromPlace = c(3.880727, 43.604937),
            mode = "BICYCLE",
            maxWalkDistance = 2000,
            date_time = as.POSIXct("2023-04-25 08:00:00"),
            cutoffSec = c(15, 30, 45, 60, 75, 90) * 60) 

iso_gareStRoch_velo$minutes = iso_gareStRoch_velo$time / 60 

Pour distinguer les deux modes de déplacement sur la carte, nous construisons une progression chromatique en teintes bleues :

mycol_4 <- colorFactor(
  palette = 'Blues',
  domain = iso_gareStRoch_velo$minutes)

À l’aide de l’option group et des fonctionnalités de contrôle des couches introduites par la fonction addLayersControl(), il est possible de modifier l’aspect de la carte en fonction des choix d’affichage de l’utilisateur.

leafMap <- leaflet() %>%
  setView(lat = 43.604937, lng = 3.880727, zoom = 10) %>%
    addPolygons(data = iso_gareStRoch_velo,
              stroke = FALSE,
              color = ~mycol_4(minutes),
              smoothFactor = 0.2,
              fillOpacity = 1, 
              group = "VELO") %>%
  addPolygons(data = iso_gareStRoch,
              stroke = FALSE,
              color = ~mycol_2(minutes),
              smoothFactor = 0.2,
              fillOpacity = 1, 
              group = "TRANSIT") %>%
  addProviderTiles(providers$CartoDB.Positron) %>%
  addLayersControl(
    overlayGroups = c("TRANSIT", "VELO", "TRAMWAY"),
    options = layersControlOptions(collapsed = FALSE))

leafMap <- leafMap %>%
  addPolylines(data = tramway,
               opacity = 1,
               weight = 4,
               group = "TRAMWAY",
               color = ~factor(num_exploi, levels = c(1, 2, 3, 4), 
                               labels = c("blue", "#c51b8a", "green", "brown")))

leafMap

L’affichage de la légende peut également être rendu dépendant des fonctionnalités de contrôle des couches via le paramètre group.

leafMap <- leaflet() %>%
  setView(lat = 43.604937, lng = 3.880727, zoom = 10) %>%
  addPolygons(data = iso_gareStRoch_velo,
              stroke = FALSE,
              color = ~mycol_4(minutes),
              smoothFactor = 0.2,
              fillOpacity = 1, 
              group = "VELO") %>%
  addPolygons(data = iso_gareStRoch,
              stroke = FALSE,
              color = ~mycol_2(minutes),
              smoothFactor = 0.2,
              fillOpacity = 1, 
              group = "TRANSIT") %>%
  addProviderTiles(providers$CartoDB.Positron) %>%
  addLayersControl(
    overlayGroups = c("TRANSIT", "VELO", "TRAMWAY"),
    options = layersControlOptions(collapsed = FALSE)
  ) %>%
  addLegend("bottomright", pal = mycol_2, 
            values = iso_gareStRoch$minutes,
            title = "Temps d'accès (TC/marche)",
            labFormat = labelFormat(suffix = " min"),
            opacity = 1,
       group = "TRANSIT"
  ) %>%
  addLegend("bottomleft", pal = mycol_4, 
            values = iso_gareStRoch_velo$minutes,
    title = "Temps d'accès (vélo)",
    labFormat = labelFormat(suffix = " min"),
    opacity = 1,
    group = "VELO")

leafMap <- leafMap %>%
  addPolylines(data = tramway,
               opacity = 1,
               weight = 4,
               group = "TRAMWAY",
               color = ~factor(num_exploi, levels = c(1, 2, 3, 4), 
                               labels = c("blue", "#c51b8a", 
                                          "darkgreen", "brown"))) %>%
  addLegend("bottomleft", pal = mycol_3,
            values = tramway$num_exploi,
            title = "Lignes de tramway",
            opacity = 1,
            group = "TRAMWAY")
  
leafMap

6.2.1 Préparation des données

La localisation des 30 mairies de la métropole de Montpellier (hors Montpellier) est recueillie à partir de la base de données des équipements de l’INSEE. Les mairies correspondent aux lignes portant le code A129 pour la variable TYPEQU. Dans ce tutoriel, nous utilisons une extraction de la base de données réalisée a priori, du fait de la lourdeur du fichier d’origine.

Les données utilisées dans cet exemple sont disponibles ici :

Télécharger les données

mairies <- read.csv("data/mairies_3M.csv", header = TRUE)

head(mairies)

  AAV2020   AN BV2012 DEP DEPCOM DOM      EPCI    DCIRIS LAMBERT_X LAMBERT_Y
1      12 2021  34022  34  34022   A 243400017 340220102  781729.9   6285175
2      12 2021  34058  34  34027   A 243400017 340270000  782250.0   6292750
3      12 2021  34172  34  34057   A 243400017 340570103  772475.6   6281921
4      12 2021  34058  34  34058   A 243400017 340580101  779478.3   6287040
5      12 2021  34172  34  34077   A 243400017 340770101  771637.0   6284634
6      12 2021  34088  34  34087   A 243400017 340870000  757131.6   6272537
   QP QUALI_IRIS QUALI_QP QUALI_QVA QUALI_ZFU QUALI_ZUS QUALITE_XY QVA REG SDOM
1 CSZ          1        X         X         X         X      Bonne CSZ  76   A1
2 CSZ          X        X         X         X         X Acceptable CSZ  76   A1
3 CSZ          1        X         X         X         X      Bonne CSZ  76   A1
4 CSZ          1        X         X         X         X      Bonne CSZ  76   A1
5 CSZ          1        X         X         X         X      Bonne CSZ  76   A1
6 CSZ          X        X         X         X         X      Bonne CSZ  76   A1
  TYPEQU UU2020 ZFU ZUS
1   A129  34302 CSZ CSZ
2   A129  34133 CSZ CSZ
3   A129  34701 CSZ CSZ
4   A129  34206 CSZ CSZ
5   A129  34701 CSZ CSZ
6   A129  34214 CSZ CSZ

Nous transformons la couche d’informations géographiques décrivant les mairies au format dataframe en simple feature dataframe, c’est-à-dire dans un format explicitement géographique grâce à la fonction st_as_sf.

mairies <- st_as_sf(mairies,
                    coords = c("LAMBERT_X", "LAMBERT_Y"),
                    crs = st_crs(2154))

Les coordonnées géographiques étant en Lambert93 (code EPSG 2154), nous les traduisons pour OTP en WGS84 (code EPSG 4326) via la fonction st_transform.

mairies <- st_transform(mairies, 4326)

Nous choisissons la plage horaire pour laquelle OTP réalisera toutes ses requêtes. L’horaire de départ est 6h et l’horaire de fin 9h afin de nous assurer de récolter les déplacements permettant d’arriver entre 7h et 9h à la gare Saint-Roch.

temps_debut <- as.POSIXct("2023-04-19 06:00:00")

temps_limite <- as.POSIXct("2023-04-19 09:00:00")

Nous créons ensuite les listes de lieux d’origine et de destination.

coord_origine <- as.matrix(cbind(st_coordinates(mairies)[,1], st_coordinates(mairies)[,2]))

coord_dest <- c(3.88040, 43.60508)

6.2.2 Exécution de la boucle pour récolter l’offre de transport

Nous construisons une boucle qui réalise une itération par minute supplémentaire de l’horaire de début jusqu’à l’horaire limite au cours de laquelle nous effectuons des requêtes d’itinéraires en transport en commun depuis les lieux d’origine vers le lieu de destination dont nous enregistrons successivement les caractéristiques dans un tableau de données que nous nommons routes.

La durée de cette opération est fonction du nombre de traitements et d’itérations qu’OTP doit réaliser. La fonction tryCatch() permet à la boucle de fonctionner malgré une éventuelle erreur de connexion au serveur OTP, due à des instabilités ponctuelles.

routes <- data.frame()

while(temps_debut < temps_limite){
  tryCatch({
    resultats <- otp_plan(otpcon = my_otpcon, 
                          fromPlace = coord_origine,
                          toPlace = coord_dest,
                          mode = c("TRANSIT", "WALK"),
                          date_time = temps_debut,
                          maxWalkDistance = 1000,
                          get_geometry = FALSE)
    temps_debut <- temps_debut + 60
    routes <- rbind(routes, resultats)
  }, error = function(e) {
    print(paste("Erreur dans la boucle :", e$message))
  })
}

6.2.3 Mise en forme des données

Puisque nous voulons compter le nombre de déplacements possibles avec une arrivée à destination entre 7h et 9h, la période de pointe, nous supprimons les déplacements hors-champ (arrivée avant 7h et après 9h).

routes <- routes[routes$endTime >= "2023-04-19 07:00:00" & routes$endTime < "2023-04-19 09:00:00", ]

La boucle d’itérations a récolté un grand nombre de doublons : d’une minute à une autre, l’offre de transport renvoyée par OTP ne change pas systématiquement. De ce fait, nous sélectionnons les seuls déplacements uniques renvoyés par le serveur OTP avec la commande distinct. Le paramètre .keep_all = TRUE permet de garder l’ensemble des colonnes de routes.

tableau_resultat <- routes %>%
  distinct(fromPlace, endTime, .keep_all = TRUE)

Enfin, nous calculons le nombre de déplacements à partir de chaque mairie avec la commande n_distinct(endTime), et la durée moyenne des déplacements avec mean(duration/60).

tableau_resultat <- tableau_resultat %>%
  group_by(fromPlace) %>%
  summarise(nb_deplacements = n_distinct(endTime), 
            duree_moy = mean(duration/60))

Le graphique ci-dessous représente la distribution des temps de déplacement moyens obtenus pour les différentes communes sous la forme d’un histogramme.

ggplot() + geom_histogram(aes(x = tableau_resultat$duree_moy),
                          bins = 9,
                          color = "black", 
                          fill = "lightblue") +
    labs(title = "Distribution des durées moyennes des déplacements obtenus pour les 30 communes",
         x = "Durée moyenne des déplacements (min)",
         y = "Nombre de mairies") +
    theme_classic() # thème de fond (ici "classic")

Nous notons que la répartition des temps de déplacement moyens en transport en commun depuis les mairies des communes de la métropole de Montpellier Méditerrannée vers la gare Saint-Roch aux heures de pointe du matin est très irrégulière et présente des écarts importants (les valeurs étant comprises entre 30 et 84 minutes).

6.2.4 Cartographie

Nous souhaitons savoir si les différences de temps de déplacement moyens s’organisent en fonction d’une logique d’éloignement géographique des communes à la ville centre. Pour cela, nous transformons préalablement l’objet tableau_resultat au format dataframe vers le format simple feature dataframe, en mobilisant les coordonnées géographiques des différents points de départ obtenues en extrayant le contenu de la colonne fromPlace via la fonction word().

library(stringr)

tableau_resultat$x <- word(tableau_resultat$fromPlace, 1, sep = ",")

tableau_resultat$y <- word(tableau_resultat$fromPlace, 2, sep = ",")

tableau_resultat <- st_as_sf(tableau_resultat, coords = c("y", "x"),
                    crs = st_crs(4326))

Nous choisissons de représenter ces différentiels d’accessibilité sous forme d’une cartographie statique. Le nombre de déplacements réalisables par commune est figuré par le biais de cercles proportionnels. Les durées moyennes de ces déplacements sont discrétisées par classes d’intervalles égaux.

De nombreuses bibliothèques existent pour réaliser de la cartographie avec R, dont la bibliothèque phare de création de graphiques avec R ggplot2.

mapsf a toutefois été créée en 2021 dans le but spécifique de faciliter la production de cartes thématiques conformes au règle de la sémiologie graphique avec R, à partir d’objets sf. Les principales fonctionnalités de la bibliothèque sont recensées dans un document graphique en ligne.

La fonction mf_map() de la bibliothèque mapsf est la fonction centrale du package qui permet de construire une carte au format varié à partir des paramètres :

• x l’objet au format sf

• var la variable à cartographier

• type le type de carte que l’on souhaite créer (prop pour des symboles proportionnels, choro pour une carte choroplèthe, typo pour une palette de couleurs variées, symb pour des symboles ponctuels différenciés…). Puisque nous souhaitons représenter conjointement une variable quantitative de stock et des intervalles de temps de déplacement, nous choisissons le type prop_choro qui permet de varier la taille des figurés et leur intensité chromatique de façon synchrone.

Nous ajontons le nombre d’habitants pour chaque commune (INSEE RP2020) et calculons la densité de population. La surface de chaque polygone est calculée avec st_area avec l’unité m\(^2\) par défaut. Nous utilisons la bibliothèque units pour convertir automatiquement les surfaces de chaque commune de m\(^2\) à km\(^2\) avec set_units. L’expression attributes() = NULL permet ensuite de supprimer les unités de la colonne car elles peuvent causer des problèmes lors des rendus graphiques (comme ggplot2).

library(units)

epci_3m$popu <- c("9305", "6794", "2176", "23469", "4014", "1640",
                  "5613", "2839", "6423", "9438", "6490", "3293",
                  "7194", "8218", "12104", "2818", "3517", "7600", 
                  "2183", "1039", "299096", "6007", "5628", "11843",
                  "10463", "8885", "17674", "6771", "2041", "1856", "3330")

epci_3m$popu <- as.numeric(epci_3m$popu)

epci_3m$surface_km2 <- st_area(epci_3m)

epci_3m$surface_km2 <- set_units(epci_3m$surface_km2, km^2)

epci_3m$densite <- epci_3m$popu/epci_3m$surface_km2

attributes(epci_3m$densite) = NULL

Notons que la cartographie paginée nécessite d’utiliser des coordonnées définies dans un système de projection cartographique adapté au territoire à l’étude, ici nous utiliserons le Lambert93 (code EPSG 2154).

tableau_resultat <- st_transform(tableau_resultat, 2154)
epci_3m <- st_transform(epci_3m, 2154)

gare_st_Roch <- data.frame(x = 3.880731, y = 43.604622)
gare_st_Roch <- st_as_sf(gare_st_Roch, coords = c("x", "y"), crs = 4326)
gare_st_Roch <- st_transform(gare_st_Roch, 2154)
gare_st_Roch$nom <- "Gare Saint-Roch"

library(mapsf)

mf_theme("iceberg")

mf_map(epci_3m,
       type = "choro",
       var = "densite",
       breaks = "geom",
       nbreaks = 5,
       pal = "Reds",
       leg_pos = "left",
       leg_title = "Densité de population\n(habitants par km²)",
       leg_frame = TRUE, 
       expandBB = c(0, 0, 0.1, 0))
       
mf_map(tableau_resultat,
       type = "prop_choro",
       var = c("nb_deplacements", "duree_moy"),
       inches = 0.15,
       border = "grey50",
       lwd = 1,
       leg_pos = c("right"),
       leg_title = c("Nombre", "Temps moyen\n(en min)"),
       breaks = "equal",
       nbreaks = 9,
       pal = "Greens",
       leg_frame = c(TRUE, TRUE))

mf_base(gare_st_Roch,
       add = TRUE,
       col = "blue",
       cex = 2,
       pch = 15)

mf_label(gare_st_Roch,
         var = "nom",
         col = "blue",
         halo = TRUE,
         cex = 1,
         bg = "white",
         pos = c(4, 1),
         r = 0.05)

mf_layout(
  title = "Déplacements des 30 mairies vers la gare Saint-Roch (7h-9h)",
  credits = paste0(
    "Sources: OTP et TAM 2022 \n",
    "mapsf ",
    packageVersion("mapsf")
  ),
  frame = TRUE)

Il est possible d’évaluer la performance de l’offre de transport par rapport à la distance euclidienne qui sépare les mairies de la gare Saint-Roch. Nous pouvons calculer cette distance avec l’expression st_distance de la bibliothèque sf. Nous ajoutons ensuite les distances dans notre tableau_resultat.

distances <- st_distance(tableau_resultat$geometry, gare_st_Roch$geometry)

tableau_resultat$distance_euclidienne <- distances

Afin de faciliter la lecture des résultats, il nous faut les codes INSEE de chacune des mairies. Les codes INSEE sont enregistrés dans le tableau mairies avec les même coordonnées géographiques que tableau_resultat. Nous devons réaliser une jointure spatiale pour joindre toutes les colonnes des deux tableaux avec la fonction st_join. Nous devons au préalable attribuer la valeur de 0.1 à st_precision afin de faire correspondre les coordonnées géographiques des deux tableaux en raison de très légères différences (aussi petites soient-elles) dues à des manipulations antérieures.

mairies <- st_transform(mairies, 2154)

st_precision(mairies) <- 0.1

st_precision(tableau_resultat) <- 0.1

jointure_spatiale <- st_join(tableau_resultat, mairies)

La conversion de mètre à kilomètre est réalisée par set_units puis nous supprimons l’unité avec attributes() = NULL car elle empêche la création du nuage de points dans ggplot2.

jointure_spatiale$distance_euclidienne <- set_units(jointure_spatiale$distance_euclidienne, km)

attributes(jointure_spatiale$distance_euclidienne) = NULL

Nous ponvons enfin réaliser le nuage de points afin de constater la performance, pour chaque mairie, de l’offre de transport par rapport à la distance qui la sépare de la gare. Nous utilisons la bibliothèque ggrepel pour que les étiquettes s’affichent avec plus de lisibilité, grâce à l’expression geom_text_repel qui empêche leur chevauchement.

library(ggrepel)

dist <- ggplot(jointure_spatiale, aes(x = distance_euclidienne, y = duree_moy, label = DEPCOM)) + 
  geom_point() +
  geom_text_repel(size = 3, box.padding = 0.3) +
  xlab("Distance euclidienne (km)") +
  ylab("Durée moyenne des déplacements (min)") +
  labs(subtitle ="Performance des transports collectifs par rapport à la distance")

dist

Le graphique permet de constater qu’il y a globalement bien une relation entre la distance et la durée moyenne des déplacements (plus c’est loin, plus il faudra de temps). Toutefois, des différences importantes de temps de déplacement, à distance égale, existent : la mairie du Crès (34090) est presque aussi éloignée que celle de Pérols (34198) alors qu’un écart de 25 minutes de déplacement les différencie (Pérols possède une desserte en tramway contrairement au Crès).

N’oubliez pas d’arrêter le serveur OTP une fois vos analyses terminées!

otp_stop()