Questions fréquentes sur l'API Isochrones

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

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

  • FROM (aller) : calcule la zone accessible from le point de départ dans le délai spécifié. Cela convient aux cas d'utilisation tels que les zones de livraison ou la couverture des services.

  • TO (Entrant) : calcule la zone à partir de laquelle vous pouvez vous déplacer 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 desserte autour d'un bureau central ou d'un hub de transport.

Quelles sont les différences entre les quatre modes de transport (DRIVE, TWO_WHEELER, BICYCLE et WALK) ?

Chaque mode utilise ses propres règles d'accès au réseau routier, ses propres coûts de virage et son propre modèle de vitesse :

  • DRIVE : parcourt les routes carrossables en utilisant les vitesses affichées ou en circulation fluide, ou les vitesses de trafic en temps réel (TRAFFIC_AWARE), jusqu'à 3 600 secondes (60 minutes).
  • TWO_WHEELER : traverse les routes accessibles aux deux-roues motorisés avec des vitesses modélisées inférieures à DRIVE sur les routes à grande vitesse et un itinéraire TRAFFIC_AWARE facultatif, jusqu'à 3 600 secondes (60 minutes). Par conséquent, un isochrone TWO_WHEELER est plus grand que BICYCLE, mais plus petit que DRIVE le long des autoroutes à grande vitesse.
  • BICYCLE : traverse les rues, les bandes cyclables et les pistes accessibles aux vélos, avec des vitesses ajustées en fonction du type de route et de la pente (à l'exclusion des autoroutes et des voies rapides), jusqu'à 7 200 secondes (120 minutes).
  • WALK : traverse les trottoirs, les sentiers et les rues piétonnes avec une vitesse de marche ajustée en fonction de la pente (en ignorant les restrictions de circulation à sens unique), jusqu'à 7 200 secondes (120 minutes).

L'API Isochrones inclut-elle les ferries ou les traversées de cours d'eau ?

Non. L'API Isochrones ne traverse que les routes, les ponts, les tunnels et les chemins. Les itinéraires en ferry et les traversées en bateau sont exclus pour tous les modes de transport. Les îles ou péninsules reliées uniquement par ferry ne seront pas incluses dans une isochrone générée à partir du continent.

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

L'API Isochrones ajuste dynamiquement la résolution de sa grille de calcul spatial en fonction des valeurs travel_duration et travel_mode demandées :

  • Durées plus courtes : utilisez une grille haute résolution très précise, car la zone totale est petite, ce qui permet d'obtenir une limite détaillée.
  • Durées plus longues : passez à une grille plus grossière et de résolution inférieure pour couvrir efficacement la vaste zone géographique sans entraîner 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 la demande d'un isochrone pour une coordonnée située dans un parc, un lac ou un grand complexe industriel renvoie-t-elle parfois une erreur "Introuvable" ?

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

Chaque mode de transport a une distance d'alignement maximale d'environ 200 mètres ou moins. WALK et BICYCLE utilisent des distances plus courtes que DRIVE et TWO_WHEELER, et DRIVE et TWO_WHEELER ignorent les chemins réservés aux piétons.

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

Pourquoi un message d'erreur s'affiche-t-il lorsque je demande un itinéraire tenant compte du trafic pour un trajet à pied ou à vélo ?

Les conditions de circulation en temps réel (TRAFFIC_AWARE) sont disponibles pour les modes de transport DRIVE et TWO_WHEELER. Si vous essayez de demander un 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 incohérence dans l'ordre des coordonnées.

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

Si le rendu de votre carte est incorrect, vérifiez comment votre SDK de carte gère le format GeoJSON :

  • API Google 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 d'effectuer l'affichage.

Pourquoi y a-t-il des "trous" vides dans mon polygone d'isochrone, et puis-je obtenir une forme pleine à la place ?

Les trous représentent les zones sans routes accessibles dans le délai imparti. C'est souvent le cas dans les régions comportant de grandes forêts, des plans 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-dans-polygone, vous pouvez :

  • 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 (comme 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 du backend ?

Non. Le paramètre enable_smoothing est conçu uniquement pour l'esthétique visuelle. Il arrondit les angles de la grille de calcul sous-jacente pour donner à la forme un aspect 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 de backend, les requêtes de base de données ou les tests de point dans un polygone, laissez enable_smoothing défini sur false pour vous assurer d'utiliser la limite calculée mathématiquement précise.