Concepts clés

Pour générer une isochrone, fournissez à l'API une origine, un mode de transport (voiture, deux-roues, vélo ou marche, par exemple) et une limite de temps. Vous pouvez également ajuster les préférences de calcul d'itinéraire et l'apparence visuelle du polygone obtenu.

Horizon temporel

La principale contrainte que vous fournissez au service est travel_duration. Elle définit l'horizon temporel du calcul.

• Durée maximale : l'API accepte un temps de trajet maximal de 3 600 secondes (1 heure) pour les modes DRIVE et TWO_WHEELER, et de 7 200 secondes (2 heures) pour les modes WALK et BICYCLE.
• Performances : le temps de calcul est proportionnel à la durée demandée et au mode de transport sélectionné. Une isochrone d'une heure en voiture couvre une zone géographique et un réseau routier beaucoup plus vastes qu'une isochrone d'une heure à pied, ce qui entraîne une latence plus élevée pour la requête en voiture.
• Formatage : comme l'API utilise google.protobuf.Duration, la durée doit être mise en forme sous forme de chaîne se terminant par un "s" (par exemple, "3600s"), plutôt que sous forme d'entier.

Points d'origine et ajustement à la route

Vous pouvez spécifier le point de départ de l'isochrone de deux manières :

• Coordonnées : paire de latitude et de longitude (location).
• ID de lieu : identifiant unique d'un lieu spécifique sur Google Maps (place). Lorsque vous fournissez un ID de lieu, le service utilise le centroïde de ce lieu comme point d'origine. Notez que l'API attend le format de nom de ressource, tel que places/ChIJ.... Pour en savoir plus sur les ID de lieu, consultez la section ID de lieu.

Quelle que soit la méthode d'entrée, l'API ne calcule pas les temps de trajet à partir du point physique exact si ce point ne se trouve pas sur une route, par exemple à l'intérieur d'un parc ou d'un bâtiment. Pour gérer cette situation, le service utilise l'ajustement à la route. L'ajustement à la route présente les caractéristiques suivantes :

• Ajustement intelligent : le service tente d'ajuster votre point d'origine au segment de route praticable le plus proche.
• Connaissance du mode : la logique d'ajustement tient compte de votre travel_mode. Si vous demandez DRIVE ou TWO_WHEELER, l'API ignore les voies réservées aux piétons et recherche la rue carrossable la plus proche. Si vous demandez WALK, l'API donne la priorité aux chemins et trottoirs praticables.
• Cas d'échec : si l'API ne trouve pas de segment de route approprié dans la distance d'ajustement maximale de votre point d'origine (environ 150 à 200 mètres, selon le mode de transport : 200 mètres pour DRIVE et TWO_WHEELER, 180 mètres pour BICYCLE et 150 mètres pour WALK), l'API renvoie une erreur 404 NOT_FOUND. Cela indique généralement que le point est trop éloigné du réseau routier ou qu'il se trouve dans une zone où les données cartographiques ne sont pas compatibles avec le mode de transport demandé.

Sens de déplacement (entrant ou sortant)

Vous pouvez calculer l'accessibilité entrante et sortante à l'aide du paramètre travelDirection :

• FROM (sortant) : calcule la zone accessible à partir du point d'origine dans la limite de temps spécifiée. Cela convient aux cas d'utilisation tels que les zones de livraison ou la couverture de service.
• TO (entrant) : calcule la zone à partir de laquelle vous pouvez vous rendre au point d'origine dans la limite de temps spécifiée. Cela convient pour déterminer les zones de chalandise, par exemple les lieux d'où les employés peuvent se rendre au bureau central.

Connaissance du trafic

Contrôlez l'influence des données de trafic sur le polygone généré à l'aide du paramètre routing_preference :

• TRAFFIC_UNAWARE (par défaut) : utilise les limitations de vitesse et la hiérarchie des routes pour générer le polygone isochrone. Cela produit une forme déterministe qui ne fluctue pas en fonction de l'heure de la journée. Ce paramètre est idéal pour une analyse générale ou une planification de scénario de référence.
• TRAFFIC_AWARE : calcule les isochrones à l'aide des conditions de trafic en direct ou prédictives au moment de la requête, ce qui réduit la zone accessible en cas de congestion et l'étend en dehors des heures de pointe. Remarque : Le calcul d'itinéraire tenant compte du trafic n'est possible que lorsque travel_mode est défini sur DRIVE ou TWO_WHEELER.

Remarque : Les isochrones tenant compte du trafic sont plus sensibles à la latence que les isochrones ne tenant pas compte du trafic.

Lissage et fidélité

Vous pouvez personnaliser l'apparence et la précision des polygones de sortie à l'aide des paramètres polygon_fidelity et enable_smoothing. Bien que ces options soient indépendantes, elles fonctionnent ensemble pour déterminer la forme finale.

• polygon_fidelity : contrôle la taille des cellules de grille sous-jacentes utilisées pour calculer la zone accessible.

  • LOW : utilise des cellules de grille plus grandes. Idéal pour couvrir de grandes zones sans lacunes, ce qui donne une forme généralisée.
  • MEDIUM : précision équilibrée.
  • HIGH : utilise des cellules de grille plus petites. Permet un ajustement plus précis au réseau routier, mais peut produire des zones vides ou des trous si le réseau routier est clairsemé.
  • POLYGON_FIDELITY_UNSPECIFIED : si aucune valeur n'est spécifiée, le service sélectionne dynamiquement la fidélité en fonction de la durée du trajet demandée.

    

    Fidélité élevée, moyenne et faible du polygone

• enable_smoothing : indique si les arêtes vives des cellules de grille définies par la fidélité doivent être arrondies.

  • false (brut) : valeur par défaut. Renvoie le calcul géométrique exact. Les arêtes apparaissent irrégulières ou en escalier. Idéal pour la précision analytique, comme les tests stricts de point dans un polygone. Latence inférieure à celle du lissage.
  • true (lissé) : applique un algorithme de post-traitement pour arrondir les angles. Idéal pour l'affichage visuel sur les cartes.

    

    Isochrone avec et sans lissage