Questions fréquentes sur l'API Isochrones

Pourquoi puis-je demander une isochrone à pied ou à vélo jusqu'à deux heures, mais que la durée est limitée à une heure pour la voiture ?

Cette limite est basée sur la complexité de calcul. Un véhicule parcourt une distance beaucoup plus longue 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é se développe de manière exponentielle. La conduite est limitée à une heure maximum (3 600 secondes) pour garantir que l'API peut renvoyer une réponse dans une fenêtre synchrone rapide 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 une origine) ?

Les calculs entrants et sortants sont acceptés dans l'API v1 à l'aide du paramètre travel_direction :

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

• TO (entrant) : calcule la zone à partir de laquelle vous pouvez vous déplacer to le point d'origine 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 permet d'obtenir 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 erreur "Introuvable" s'affiche-t-elle parfois lorsque je demande une isochrone pour une coordonnée située dans un parc, un lac ou un grand complexe industriel ?

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

Chaque mode de transport a un seuil de distance d'accrochage 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 vos coordonnées d'origine sont plus éloignées d'un segment de route valide et compatible avec le mode que ces seuils, l'accrochage échoue et l'API renvoie une erreur NOT_FOUND. Pour résoudre ce problème, assurez-vous que vos coordonnées sont positionnées à proximité d'une rue ou d'un chemin public.

Lorsque j'affiche la réponse GeoJSON sur ma carte, la forme est mal placée, 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]. Toutefois, de nombreux SDK de cartographie, y compris l'API Maps JavaScript et divers composants de carte mobile, attendent des coordonnées ou des objets LatLng dans l'ordre [latitude, longitude].

Si le rendu de votre carte est incorrect, vous devez parcourir les coordonnées de la charge utile GeoJSON et transposer les valeurs avant de les transmettre à votre SDK Maps.

Pourquoi y a-t-il des "trous" à l'intérieur de mon polygone isochrone ? Puis-je obtenir une forme pleine à la place ?

Les trous représentent les zones sans routes accessibles dans le délai imparti. C'est courant dans les régions avec 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 contenu 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 extraire uniquement la première couronne de coordonnées (l'enveloppe extérieure), en ignorant les couronnes intérieures suivantes (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 vifs de la grille de calcul sous-jacente pour que la forme paraisse naturelle sur une carte.

Nous ne recommandons pas le lissage 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, définissez enable_smoothing sur false pour vous assurer d'utiliser la limite calculée mathématiquement précise.