Pourquoi puis-je demander une isochrone à pied ou à vélo jusqu'à deux heures, mais seulement une heure en voiture ?
Cette limite est basée sur la complexité de calcul. Un véhicule parcourt une distance beaucoup plus importante qu'un piéton ou un cycliste sur la même durée, ce qui signifie que le réseau routier sous-jacent qui doit être analysé s'étend de manière exponentielle. La conduite est limitée à une heure maximum (3 600 secondes) pour que l'API puisse renvoyer une réponse dans une fenêtre synchrone rapide et en temps réel, tandis que la marche et le vélo sont pris en charge jusqu'à deux heures (7 200 secondes).
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 accessiblefromle 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 de service.TO(entrant) : calcule la zone depuis laquelle vous pouvez vous rendretole point de départ dans le délai spécifié. Cela convient 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.
Parfois, le polygone renvoyé semble irrégulier ou présente des bords dentelés, 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 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" ?
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 sont pas situées 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).BICYCLE: 180 mètres.WALK: 150 mètres.
Si votre coordonnée d'origine est plus éloignée 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 voie publique ou d'un chemin.
Pourquoi une erreur s'affiche-t-elle lorsque je demande un routage tenant compte du trafic pour la marche ou le vélo ?
Les conditions de circulation en temps réel (TRAFFIC_AWARE) ne sont compatibles qu'avec le mode de transport DRIVE. 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 est affichée 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 externe v1 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_fidelitysurMEDIUMouLOWpour 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 extraire uniquement 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.