Les préférences de trafic que vous sélectionnez permettent d'équilibrer la précision des détails de l'itinéraire et les performances des requêtes. Lorsque vous envoyez une requête, vous devez déterminer s'il est préférable de renvoyer les résultats les plus précis possibles ou le plus rapidement possible. L'API Routes fournit des options qui vous permettent de contrôler la qualité des données de réponse par rapport à la latence de la réponse.
Définir le niveau des données de trafic
L'API Routes fournit les API RoutingPreference (REST) et RoutingPreference (gRPC), qui vous permettent de spécifier des préférences de routage pour le calcul des routes. Ces préférences diffèrent dans la mesure où elles prennent en compte les conditions de circulation dans le calcul de l'itinéraire. Chaque préférence de routage produit des résultats qui diffèrent dans une certaine mesure en ce qui concerne la qualité des itinéraires, l'heure d'arrivée prévue estimée et la latence de réponse.
Les conditions de circulation caractérisent la vitesse de circulation. Exemple :
- En l'absence d'embouteillages, les conditions de circulation sont considérées comme normales, et le trafic circule à la vitesse normale, sans entrave.
- À l'approche des heures de pointe, la densité du trafic augmente, ce qui ralentit le trafic et entraîne des conditions de circulation faibles à modérées.
- Dans un trafic très dense, le débit s'arrête alors.
Sans tenir compte du trafic
Lorsque vous définissez la préférence de routage TRAFFIC_UNAWARE, les routes sont calculées sans tenir compte des conditions de circulation actuelles. Cette préférence de routage offre la latence de réponse la plus faible (les réponses sont renvoyées le plus rapidement).
TRAFFIC_UNAWARE est le paramètre par défaut.
Dans la réponse:
L'heure d'arrivée prévue est contenue dans la propriété de réponse
duration.Les propriétés de réponse
durationetstaticDurationcontiennent la même valeur.
Utilisez cette préférence de routage si vous souhaitez que les réponses soient renvoyées le plus rapidement possible et que des informations de routage approximatives soient suffisamment pertinentes.
Prise en charge du trafic
Lorsque vous définissez la préférence de routage TRAFFIC_AWARE, les routes sont calculées pour tenir compte des conditions de circulation actuelles. Ainsi, les itinéraires et les détails de l'itinéraire reflètent plus précisément les conditions réelles. Étant donné que cette amélioration de la qualité des données se fait au détriment de la latence des réponses, des optimisations de performances sont appliquées pour réduire une grande partie de cette latence.
Dans la réponse:
L'heure d'arrivée prévue qui tient compte du trafic en temps réel est contenue dans la propriété de réponse
duration.La propriété de réponse
staticDurationcontient la durée de trajet sur l'itinéraire sans tenir compte des conditions de circulation.
Utilisez cette préférence de routage lorsque vous souhaitez obtenir des informations de routage plus précises que TRAFFIC_UNAWARE et que cela ne vous dérange pas que des réponses soient renvoyées avec une augmentation modérée de la latence.
Optimisé pour le trafic
Lorsque vous définissez la préférence de routage TRAFFIC_AWARE_OPTIMAL, les routes sont calculées en tenant compte des conditions de trafic actuelles, mais aucune optimisation des performances n'est appliquée. Dans ce mode, le serveur effectue une recherche plus exhaustive sur le réseau routier afin de trouver l'itinéraire optimal.
La préférence d'itinéraire TRAFFIC_AWARE_OPTIMAL correspond au mode utilisé par maps.google.com et par l'application mobile Google Maps.
Lorsque vous utilisez cette option avec Compute Route Matrix, le nombre d'éléments dans une requête (nombre d'origines x nombre de destinations) ne peut pas dépasser 100. Pour en savoir plus sur les limites de Compute Route Matrix, consultez la section Calculer une matrice de routage.
Dans la réponse:
L'heure d'arrivée prévue qui tient compte du trafic en temps réel est contenue dans la propriété de réponse
duration.La propriété de réponse
staticDurationcontient la durée de trajet sur l'itinéraire sans tenir compte des conditions de circulation.
Cette préférence de routage offre la latence de réponse la plus élevée (c'est-à-dire que les réponses sont renvoyées avec le délai le plus long). Utilisez cette préférence de routage lorsque vous souhaitez obtenir des résultats de la plus haute qualité, quel que soit le temps de réponse des réponses.
Effet de la définition de l'heure de départ
Vous pouvez éventuellement utiliser la propriété departureTime pour définir l'heure de départ d'un trajet. Si vous ne définissez pas la propriété departureTime, elle est définie par défaut sur l'heure à laquelle vous envoyez la requête.
Pour
TRAFFIC_UNAWARE, vous ne pouvez pas définirdepartureTime, car le choix de l'itinéraire et de la durée est basé sur le réseau routier et sur les conditions de circulation moyennes toutes heures confondues.Pour
TRAFFIC_AWAREetTRAFFIC_AWARE_OPTIMAL, qui tiennent compte des conditions de circulation en temps réel, plus ladepartureTimeest proche de l'heure actuelle, plus le trafic en temps réel est important. Plus vous définissez une heure de départ dans le futur, plus l'historique des conditions de circulation est pris en compte.
Exemple de configuration de préférence de routage
Le code JSON suivant montre comment définir la préférence de routage dans le corps d'une entité de message de requête.
{
"origin":{
"location":{
"latLng":{
"latitude":37.419734,
"longitude":-122.0827784
}
}
},
"destination":{
"location":{
"latLng":{
"latitude":37.417670,
"longitude":-122.079595
}
}
},
"travelMode":"DRIVE",
"routingPreference":"TRAFFIC_AWARE_OPTIMAL"
}
Configurer la qualité des polylignes
L'API Routes vous permet de demander des informations sur les conditions de circulation le long d'une polyligne tenant compte du trafic. Pour en savoir plus, consultez Demander des polylignes.
La qualité d'une polyligne peut être décrite dans les termes suivants:
Le nombre de points qui composent la polyligne
Plus il y a de points, plus la polyligne est lisse (en particulier pour les courbes).
La précision des points à virgule flottante
Les points sont spécifiés sous forme de valeurs de latitude et de longitude, représentées au format à virgule flottante à simple précision. Cela fonctionne bien pour les petites valeurs (qui peuvent être représentées avec précision), mais la précision diminue à mesure que les valeurs augmentent en raison des erreurs d'arrondi à virgule flottante.
Les méthodes computeRoutes (REST) et ComputeRoutes (gRPC) acceptent l'option de requête polylineQuality pour contrôler la qualité des polylignes.
Exemple de définition de la qualité d'une polyligne
polylineQuality spécifie la qualité de la polyligne en tant que HIGH_QUALITY ou OVERVIEW (par défaut). Avec OVERVIEW, la polyligne est composée d'un petit nombre de points et présente une latence de requête inférieure à celle de HIGH_QUALITY.
Par exemple, dans le corps de la requête:
{
"origin":{
"location":{
"latLng":{
"latitude": 37.419734,
"longitude": -122.0827784
}
}
},
"destination":{
"location":{
"latLng":{
"latitude": 37.417670,
"longitude": -122.079595
}
}
},
"travelMode": "DRIVE",
"routingPreference": "TRAFFIC_AWARE",
"polylineQuality": "HIGH_QUALITY",
"polylineEncoding": "ENCODED_POLYLINE",
"departureTime": "2023-10-15T15:01:23.045123456Z",
...
}