Configurer la qualité et la latence

Lorsque vous effectuez une requête, vous devrez peut-être décider s'il est préférable de renvoyer les résultats les plus précis possible 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.

Configurer le niveau de données sur le trafic

L'API Routes fournit les attributs RoutingPreference (REST) et RoutingPreference (gRPC) qui vous permettent de spécifier les préférences de routage pour le calcul des routes. Ces préférences diffèrent dans la mesure où elles tiennent compte des conditions de trafic dans le calcul de l'itinéraire. Chaque préférence de routage produit des résultats qui diffèrent par rapport à un degré en termes de qualité d'itinéraire, d'heure d'arrivée prévue estimée et de latence de réponse.

Le trafic est caractérisé par des conditions de trafic. Exemple :

• En l'absence d'encombrement, les conditions de trafic sont considérées comme normales, et le trafic circule à la vitesse normale.
• À l'approche des heures de pointe, la densité du trafic augmente, ce qui ralentit le trafic, générant des conditions de circulation légères à modérées.
• Dans le trafic bumper, le débit s'interrompt, ce qui génère des conditions de trafic intenses.

Trafic non pris en compte

Lorsque vous définissez la préférence de routage TRAFFIC_UNAWARE, les itinéraires sont calculés 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 duration et staticDuration contiennent la même valeur.

Utilisez cette préférence de routage si vous souhaitez que les réponses renvoient le plus rapidement possible et que les détails de routage approximatifs soient suffisants.

Alertes de trafic

Lorsque vous définissez la préférence de routage TRAFFIC_AWARE, les itinéraires sont calculés en tenant compte des conditions de circulation actuelles. Par conséquent, les détails de l'itinéraire et de l'itinéraire reflètent plus précisément les conditions réelles. Étant donné que cette augmentation de la qualité des données se fait au détriment de la latence de réponse, les optimisations de performances sont appliquées pour réduire une grande partie de la latence.

Dans la réponse:

• L'heure d'arrivée prévue en tenant compte du trafic en temps réel est contenue dans la propriété de réponse duration.

• La propriété de réponse staticDuration contient la durée du trajet sur l'itinéraire sans tenir compte des conditions de circulation.

Utilisez cette préférence de routage si vous souhaitez obtenir des informations de routage plus précises que TRAFFIC_UNAWARE, mais que vous ne vous inquiétez pas si les réponses sont renvoyées avec une latence modérée.

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 circulation 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 de routage TRAFFIC_AWARE_OPTIMAL équivaut au mode utilisé par maps.google.com et par l'application mobile Google Maps.

Lorsque vous utilisez cette option avec la route matricielle Compute, le nombre d'éléments dans une requête (nombre d'origines × nombre de destinations) ne peut pas dépasser 100. Pour en savoir plus sur les limites de la matrice de routes Compute, consultez Calculer une matrice de routes.

Dans la réponse:

• L'heure d'arrivée prévue en tenant compte du trafic en temps réel est contenue dans la propriété de réponse duration.

• La propriété de réponse staticDuration contient la durée du 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 (en d'autres termes, les réponses renvoient 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é, quelle que soit la durée 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 souhaitée au 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 effectuez la requête.

• Pour TRAFFIC_UNAWARE, vous ne pouvez pas définir departureTime, car le choix de l'itinéraire et de la durée est basé sur le réseau routier et les conditions de circulation moyennes toutes heures confondues.

• Pour TRAFFIC_AWARE et TRAFFIC_AWARE_OPTIMAL, qui tiennent compte des conditions de trafic en temps réel, plus le departureTime est proche de l'heure actuelle, plus le trafic en temps réel devient important. Plus l'heure de départ est éloignée, plus l'historique des conditions de circulation est pris en compte.

Exemple de paramétrage d'une préférence de routage

Le code JSON suivant montre comment définir la préférence de routage dans un corps d'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é de la polyligne

L'API Routes vous permet de demander des informations sur les conditions de circulation via une polyligne tenant compte du trafic. Pour en savoir plus, consultez la section Demander des polylignes.

La qualité d'une polyligne peut être décrite comme suit:

• Nombre de points qui composent la polyligne

  Plus il y a de points, plus la polyligne est fluide (en particulier dans les courbes).

• Précision des points à virgule flottante

  Les points sont spécifiés en tant que 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 d'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 paramètre de qualité des polylignes

polylineQuality spécifie la qualité de la polyligne comme 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 à 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",
  ...
}