Bonnes pratiques concernant l'API Isochrones

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.

  • polygonFidelity (polygon_fidelity) : résolution. Contrôle la taille des cellules de la grille spatiale sous-jacente utilisées pour calculer la zone accessible.

    • LOW : utilise les cellules de grille les plus grandes (plusieurs centaines de mètres de diamètre). Idéal pour couvrir de grandes zones sans lacunes et minimiser le nombre de sommets, ce qui donne une forme généralisée qui peut surestimer la zone accessible le long de couloirs routiers étroits.
    • MEDIUM : précision et taille de la charge utile équilibrées.
    • HIGH : utilise les cellules de grille les plus petites (environ 100 à 150 mètres de diamètre). Permet d'obtenir un ajustement plus précis au réseau routier, avec plus de sommets, mais peut produire des trous intérieurs là où le réseau routier est clairsemé.
    • Par défaut (POLYGON_FIDELITY_UNSPECIFIED) : si aucune résolution n'est spécifiée, le service la sélectionne automatiquement en fonction du mode de transport et de la durée, en utilisant des cellules plus fines pour les durées courtes et pour WALK, et des cellules plus grossières pour les durées longues. Pour comparer des isochrones sur différentes durées ou différents modes de transport, définissez explicitement polygonFidelity afin qu'ils utilisent la même résolution.

    Les tailles de cellule sont approximatives. Les isochrones très grands peuvent être généralisés davantage pour que la taille de la réponse reste gérable.

  • enableSmoothing (enable_smoothing) : l'esthétique. Détermine si les bords en escalier des cellules de la grille définies par la fidélité sont arrondis.
    • false (brut) : renvoie la limite alignée sur la grille. Les bords apparaissent irréguliers ou en escalier, reflétant les cellules de la grille. Idéal pour la précision analytique, comme les tests stricts de point dans un polygone.
    • true (Lissé) : arrondit les angles tout en préservant approximativement la zone de chaque anneau. Idéal pour l'affichage visuel sur les cartes. Étant donné que la limite ne suit plus les cellules de la grille, ne l'utilisez pas pour des tests stricts de point dans un polygone.

Interaction : la fidélité définit le niveau de détail de référence sur lequel l'algorithme de lissage agit.

  • Haute fidélité + lissage : produit une forme détaillée d'aspect organique qui suit de près les extrémités des routes.
  • Basse fidélité + lissage : produit une forme de "tache" large et généralisée.

Taille de la charge utile et rendu

Les isochrones de grande taille (en particulier les requêtes de longue durée avec une fidélité HIGH) peuvent contenir des dizaines de milliers de coordonnées, et la réponse JSON non compressée peut faire plusieurs centaines de kilo-octets ou plus.

  • Bande passante : sachez que la taille de la réponse JSON est importante pour les requêtes de durée maximale avec une haute fidélité.
  • Affichage : l'affichage de polygones extrêmement détaillés a un impact sur les performances du client. Pour réduire le nombre de sommets et la taille de la charge utile, choisissez polygonFidelity: MEDIUM ou LOW, ou simplifiez la géométrie sur le client avant l'affichage à l'aide d'un algorithme de simplification de ligne tel que Douglas-Peucker.

Latence et délais avant expiration du client

La latence de réponse augmente avec la taille du réseau routier parcouru : les durées courtes et les modes WALK et BICYCLE sont les plus rapides, tandis que les requêtes DRIVE et TWO_WHEELER longues (en particulier avec TRAFFIC_AWARE) prennent le plus de temps.

  • Délai avant expiration recommandé pour le client : configurez les délais des clients HTTP ou gRPC sur au moins 30 secondes afin que les requêtes longues ne soient pas interrompues prématurément par un délai avant expiration court du client.

Gestion des exceptions

Implémentez une logique de nouvelle tentative avec un intervalle exponentiel entre les tentatives et une gigue pour les réponses de limite de débit 429 RESOURCE_EXHAUSTED et les erreurs de serveur 5xx. Ne relancez pas les erreurs client 400, 403 ou 404 sans modifier votre requête :

  • INVALID_ARGUMENT (400) : vérifiez que travelDuration est compris entre 1s et 3600s (DRIVE/TWO_WHEELER) ou 7200s (WALK/BICYCLE), que location n'est pas omis et n'est pas (0, 0) (ou que place est un ID de lieu valide), et que TRAFFIC_AWARE n'est utilisé qu'avec DRIVE ou TWO_WHEELER. Si latitude ou longitude est omis, il est traité comme 0.0. Par conséquent, omettre l'un d'eux ne provoque généralement pas d'erreur 400 (sauf si l'autre valeur est également 0.0). Vérifiez les deux valeurs si l'isochrone apparaît au mauvais endroit.
  • PERMISSION_DENIED (403) : vérifiez que votre clé API ou votre jeton OAuth est inclus, et que l'API Isochrones et la facturation sont activées dans votre projet Google Cloud.
  • NOT_FOUND (404) : Impossible de résoudre l'emplacement de place ou d'aligner le point de départ sur une route à proximité utilisable par le mode de transport (à environ 200 mètres ou moins pour WALK et BICYCLE).
  • RESOURCE_EXHAUSTED (429) : votre projet a dépassé le quota de requêtes par minute (300 RPM par défaut). Réessayer avec un intervalle exponentiel entre les tentatives