Limites et perspectives des méthodes et indicateurs

Les limites énoncées ici sont attribuables à l’ensemble de la section 6.2. Elles concernent autant les méthodes que les indicateurs résultants.

L’outil utilise le calculateur de trajet de Google pour effectuer l’ensemble des calculs de chemin. Ceci le rend complètement dépendant de l’API Google maps. Les paramètres du calculateur ne sont pas entièrement connus. L’algorithme du chemin le plus court choisi par Google n’est pas dévoilé ainsi que sa méthode de calcul de temps de parcours entre une origine et une destination. Également, aucune information n’est connue sur la codification du réseau en soi. Les caractéristiques des liens codifiés tels le nom du lien, sa vitesse, le type de lien (pédestre, cyclable, autoroutier, etc.), sa trajectoire (polyligne), le nombre de voies, le sens de la circulation, etc. ne sont pas accessibles au programmeur.

Mode Superficie (km2) Ratio Mode / Auto

Marche 2.75 0.03

Velo 20.02 0.20

TC 6.86 0.07

Auto 101.24 1.00

La non-divulgation des méthodes et systèmes d’informations engendre diverses problématiques. D’abord, le réseau ne peut être modifié pour évaluer différents scénarios par exemple. Puis, des modifications sur le réseau peuvent être apportées sans préavis. Il n’y a aucune traçabilité dans le temps de l’évolution du réseau. Il est impossible de générer aisément des indicateurs caractérisant le réseau tel que la longueur du réseau cyclable, autoroutier, etc.

Le calculateur de trajet Google ne tient pas compte des effets de circulation, ni de temps de recherche de stationnement. Les résultats obtenus sont à écoulement libre. Pour la marche et le vélo, cela a très peu d’impact sur les résultats puisqu’ils ne sont généralement pas soumis à la congestion, ni aux contraintes de stationnements. Certaines parties du réseau routier montréalais, par contre, ont de la congestion durant les heures de pointe et les stationnements sont limités. Ni la congestion, ni le temps de recherche de stationnement ne sont pris en compte. Ceci implique que les temps de parcours automobile sont parfois sous-estimés dépendamment de la destination du déplacement et l’heure.

L’API Google maps prétend limiter le nombre de calculs de trajets à 2 500 par jour. Par contre, d’après les expérimentations, ce nombre peut-être excédé. Toutefois, il semble exister une limite de requêtes dans le temps. Par exemple, il est impossible pour l’outil d’effectuer plus de 800 calculs de chemins par itération. Le nombre de destinations est donc limité.

Concernant l’outil en soi, l’aspect général de l’interface pourrait être amélioré ainsi que sa facilité d’utilisation.

L’outil actuel calcule les trajets de l’origine (point d’intérêt) vers chacune des destinations. Il serait intéressant de réaliser l’opération inverse, soit de toutes les destinations théoriques vers le point d’intérêt. Ce changement est simple à réaliser, il suffit d’inverser l’origine et la destination.

Dans une perspective plus large, il serait souhaitable qu’un outil intègre les modes marche, auto et vélo ainsi que le transport collectif sous une même interface.

Tel que mentionné, l’outil n’a pas été créé pour fournir une interface graphique intéressante. L’API Google maps n’est pas aussi développé que la majorité des logiciels SIG, principalement au niveau des requêtes spatiales préprogrammées. Il est difficile de générer des couches d’interpolation de type matriciel ou de faire des jointures spatiales avec d’autres bases de données. Les fonctions ne permettent pas de générer de manière satisfaisante des polygones

regroupant les points de mêmes attributs pour créer des surfaces. Actuellement, la fonction Google regroupe les points en ordre de liste sans tenir compte de leur position. Ceci forme une masse incohérente. Toutefois, le web a autant de potentiel qu’un logiciel SIG. Il suffit d’en développer la programmation.

La méthode des courbes de temps de parcours peut servir de base pour la méthode classique d’indicateurs d’opportunités gravitaire. La jointure spatiale d’une couche d’intérêt comme des emplois et une couche d’interpolation ou de courbe de niveau permettrait de calculer ces indicateurs gravitaires.

En ce qui à trait aux indicateurs, plusieurs finalités sont envisageables. Les cartes isochrones peuvent servir à la clientèle d’un générateur important pour connaître leur temps de parcours vers une panoplie de destinations. Elles peuvent également aider au choix de logis parce qu’elles donnent une vue d’ensemble sur le territoire. Par exemple, si une personne souhaite déménager, une carte isochrone à partir de son lieu de travail peut l’aider à connaître tous les secteurs à environ 30 minutes de son travail selon le mode de son choix. Elles peuvent être utiles pour un commerçant ou un employeur pour connaître son bassin d’attraction.

Les indicateurs de superficie d’accès peuvent avoir des effets frontière. Par exemple, si un indicateur d’opportunités d’emplois est développé à partir des superficies d’accès, le centre d’emploi à 31 minutes de déplacement ne sera pas considéré. Les emplois à proximité auront la même importance que ceux à la frontière. Il serait donc pertinent de produire une distribution des emplois en fonction du temps d’accès comme proposée à la Figure 60 pour les personnes.

Dans le calcul de la superficie du polygone accessible, des erreurs se glissent avec la méthode utilisée. Des concentrations localisées se forment à l’intérieur du grand périmètre de 15 minutes. Ces concentrations, illustrées à la figure suivante, sont des endroits où le temps d’accès est supérieur à 15 minutes. Elles sont incluses dans la superficie totale à deux reprises. Les superficies totales ne sont donc pas justes. L’ordre de grandeur demeure la même. Une amélioration quant à la méthodologie devrait être apportée pour les retirer.

Figure 63. Erratum dans la superficie accessible totale

Pour ce qui de la méthode d’ajustement des temps de parcours auto, les nouveaux temps de parcours obtenus supposent que l’itinéraire de départ a été conservé entre l’origine et l’une des destinations. Or, il serait préférable de recalculer les trajets en fonction des nouvelles vitesses sur les tronçons pour obtenir l’itinéraire et le temps de parcours optimal. Par contre, recalculer les itinéraires en modifiant les paramètres de vitesse nécessite l’utilisation d’une ressource extérieure au calculateur Google maps.

Des problématiques sont liées à l’utilisation des données GPS pour obtenir des vitesses moyennes par tronçon. D’abord, certaines vitesses relevées par le capteur GPS sont parfois aberrantes, ces dernières auraient avantage à être corrigées ou supprimées de la base de données. Puis, lorsqu’il y a peu d’observations sur un tronçon, la valeur moyenne accordée peut être à son tour non représentative du tronçon.

Cette méthode pourrait s’appliquer au mode vélo si des relevés de GPS le permettaient. L’impact des feux de circulation, des pistes cyclables et des dénivellations pourrait être observé.

Or, l’expérience a été menée pour valider la pertinence des indicateurs et de la méthode de correction des temps de parcours. D’après les résultats, l’expérience semble pertinente.

 Fournir de base à des indicateurs d’opportunités, opportunités/superficie, de flexibilité (variation dans le temps ou dans l’espace), etc.

 Développer des indicateurs d’attractivité d’un mode par rapport à un autre.

 Comparer des générateurs entre eux par la superficie d’accès offerte à sa clientèle ou par le bassin de population rejoint.

 Observer des lacunes chez certains modes dans une ou plusieurs directions (impasse pédestre, aucun service de transport collectif, etc.).

L’aspect le plus intéressant de cet indicateur est la possibilité de comparaison entre les modes.