Questions fréquentes sur l'API Isochrones

Comment calculer une isochrone "domicile-travail" entrante (trajet vers une destination) par rapport à une isochrone sortante (trajet depuis un point de départ) ?

Les calculs entrants et sortants sont compatibles avec l'API v1 à l'aide du paramètre travel_direction :

  • FROM (sortant) : calcule la zone accessible from le point de départ dans le délai spécifié. Cette option est adaptée aux cas d'utilisation tels que les zones de livraison ou la couverture de service.

  • TO (entrant) : calcule la zone depuis laquelle vous pouvez vous rendre to le point de départ dans le délai spécifié. Cette option est adaptée aux applications telles que les fonctionnalités de trajet domicile-travail ou la détermination des zones de chalandise autour d'un bureau central ou d'un pôle de transport en commun.

Parfois, le polygone renvoyé semble bloc ou présente des bords irréguliers, en particulier pour les durées plus longues. Pourquoi le niveau de détail change-t-il ?

L'API Isochrones ajuste de manière dynamique la résolution de sa grille de calcul spatial en fonction des paramètres travel_duration et travel_mode demandés :

  • Durées plus courtes : utilisez une grille haute résolution très précise, car la superficie totale est petite, ce qui donne une limite détaillée.
  • Durées plus longues : passez à une grille plus grossière et à résolution inférieure pour couvrir efficacement la vaste zone géographique sans provoquer de latence importante.

Vous pouvez définir le paramètre facultatif polygon_fidelity sur HIGH, MEDIUM ou LOW si vous avez besoin d'un niveau de détail spécifique et cohérent, quelle que soit la durée.

Pourquoi une requête d'isochrone pour une coordonnée située dans un parc, un lac ou un grand complexe industriel renvoie-t-elle parfois une erreur "Not Found" (Introuvable) ?

L'API Isochrones calcule les temps de trajet à l'aide des routes et des chemins. L'API doit "aligner" le point sur le segment compatible le plus proche avant de commencer le calcul si les coordonnées d'origine demandées ne se trouvent pas sur une route reconnue.

Chaque mode de transport a un seuil de distance d'alignement maximal spécifique :

  • DRIVE : 200 mètres (ignore les chemins réservés aux piétons).
  • TWO_WHEELER : 200 mètres (ignore les chemins réservés aux piétons).
  • BICYCLE : 180 mètres.
  • WALK : 150 mètres.

Si votre coordonnée d'origine se trouve plus loin d'un segment de route valide et compatible avec le mode que ces seuils, l'alignement échoue et l'API renvoie une erreur NOT_FOUND. Pour résoudre ce problème, assurez-vous que vos coordonnées sont proches d'une rue ou d'un chemin public.

Pourquoi une erreur s'affiche-t-elle lorsque je demande un itinéraire tenant compte du trafic pour la marche ou le vélo ?

Les conditions de circulation en temps réel (TRAFFIC_AWARE) sont compatibles avec les modes de transport DRIVE et TWO_WHEELER. Si vous tentez de demander une isochrone pour WALK ou BICYCLE avec routingPreference défini sur TRAFFIC_AWARE, l'API renvoie une erreur 400 INVALID_ARGUMENT.

Lorsque j'affiche la réponse GeoJSON sur ma carte, la forme s'affiche au mauvais endroit, est déformée ou ne s'affiche pas. Quelle en est la cause ?

Cela est presque toujours dû à une erreur d'ordre des coordonnées.

Conformément à la norme GeoJSON (RFC 7946), l'API Isochrones renvoie les coordonnées dans l'ordre [longitude, latitude]. Toutefois, de nombreux SDK de cartographie et objets géométriques personnalisés attendent les coordonnées dans l'ordre [latitude, longitude].

Si l'affichage de votre carte est incorrect, vérifiez comment votre SDK de cartographie gère GeoJSON :

  • API Maps JavaScript : si vous utilisez la couche de données (map.data.addGeoJson()), cet ordre est géré de manière native et aucune action n'est requise.
  • Objets personnalisés ou autres SDK : si vous analysez manuellement la réponse dans des objets LatLng, vous devez parcourir les coordonnées de la charge utile GeoJSON et transposer les valeurs [lng, lat] en paires [lat, lng] avant le rendu.

Pourquoi y a-t-il des "trous" dans mon polygone isochrone ? Puis-je obtenir une forme pleine à la place ?

Les trous représentent des zones sans routes accessibles dans le délai imparti. Cela est courant dans les régions où se trouvent de grandes forêts, des étendues d'eau, des aéroports ou des propriétés privées où les véhicules ou les piétons ne peuvent pas circuler.

L'API v1 externe n'expose pas de paramètre permettant de supprimer automatiquement les trous. Si votre application nécessite une limite solide, par exemple pour effectuer des vérifications de confinement point-in-polygon, vous pouvez procéder comme suit :

  • Définissez le paramètre polygon_fidelity sur MEDIUM ou LOW pour encourager l'algorithme à généraliser et à fusionner ces écarts internes.
  • Utilisez une bibliothèque SIG côté client (telle que Turf.js) pour analyser le GeoJSON et n'extraire que le premier anneau de coordonnées (l'enveloppe extérieure), en ignorant les anneaux intérieurs suivants (les trous).

Dois-je activer l'option enable_smoothing pour l'analyse spatiale backend ?

Non. Le paramètre enable_smoothing est conçu uniquement pour l'esthétique visuelle. Il arrondit les angles vifs de la grille de calcul sous-jacente pour que la forme semble organique sur une carte.

Le lissage n'est pas recommandé pour une analyse spatiale précise, car il modifie les sommets et déplace légèrement les limites. Pour les calculs backend, les requêtes de base de données ou les tests point-in-polygon, laissez enable_smoothing défini sur false pour vous assurer d'utiliser la limite calculée mathématiquement précise.