¿Por qué puedo solicitar una isócrona para caminar o andar en bicicleta por hasta 2 horas, pero la conducción se limita a 1 hora?
Esta limitación se basa en la complejidad computacional de los cálculos. Un vehículo viaja mucho más lejos que un peatón o un ciclista durante el mismo período, lo que significa que la red de rutas subyacente que se debe analizar se expande de forma exponencial. La conducción se limita a un máximo de 1 hora (3,600 segundos) para garantizar que la API pueda mostrar una respuesta dentro de una ventana síncrona rápida y en tiempo real, mientras que se admite caminar y andar en bicicleta por hasta 2 horas (7,200 segundos).
¿Cómo calculo una isócrona de "viaje al trabajo" de entrada (viajar a un destino) en comparación con una isócrona de salida (viajar desde un origen)?
Los cálculos de entrada y salida se admiten en la API de v1 con el parámetro travel_direction:
FROM(salida): Calcula el área a la que se puede llegarfromel punto de origen dentro del límite de tiempo especificado. Esto es adecuado para casos de uso como zonas de entrega o cobertura de servicio.TO(entrada): Calcula el área desde la que puedes viajartoel punto de origen dentro del límite de tiempo especificado. Esto es adecuado para aplicaciones como funciones de viaje al trabajo o para determinar zonas de captación alrededor de una oficina central o un centro de transporte.
A veces, el polígono que se muestra parece bloqueado o tiene bordes irregulares y escalonados, en especial para duraciones más largas. ¿Por qué cambia el nivel de detalle?
La API de Isochrones ajusta de forma dinámica la resolución de su cuadrícula de cálculo espacial en función de la travel_duration y el travel_mode solicitados:
- Duraciones más cortas: Usa una cuadrícula de alta resolución y muy refinada porque el área total es pequeña, lo que da como resultado un límite detallado.
- Duraciones más largas: Realiza la transición a una cuadrícula más gruesa y de menor resolución para cubrir el área geográfica extensa de manera eficiente sin causar una latencia grave.
Puedes establecer el parámetro polygon_fidelity opcional en HIGH, MEDIUM o LOW si necesitas un nivel de detalle específico y coherente, independientemente de la duración.
¿Por qué solicitar una isócrona para una coordenada dentro de un parque, un lago o un complejo industrial grande a veces muestra un error "No se encontró"?
La API de Isochrones calcula los tiempos de viaje con rutas y caminos. La API debe "ajustar" el punto al segmento compatible más cercano antes de iniciar el cálculo si las coordenadas de origen solicitadas no se encuentran en una ruta reconocida.
Cada modo de viaje tiene un umbral de distancia de ajuste máximo específico:
DRIVE: 200 metros (ignora las rutas solo para peatones).BICYCLE: 180 metros.WALK: 150 metros.
Si tu coordenada de origen se encuentra más lejos de un segmento de ruta válido y compatible con el modo que estos umbrales, el ajuste falla y la API muestra un error NOT_FOUND. Para resolver este problema, asegúrate de que tus coordenadas estén cerca de una calle o camino público.
Cuando renderizo la respuesta GeoJSON en mi mapa, la forma se muestra en el lugar incorrecto, está distorsionada o no se renderiza. ¿Qué causa esto?
Esto casi siempre se debe a una falta de coincidencia en el orden de las coordenadas.
Según el estándar GeoJSON (RFC 7946), la API de Isochrones muestra las coordenadas en el orden de [longitude, latitude]. Sin embargo, muchos SDKs de mapas, incluida la API de Maps JavaScript y varios componentes de mapas para dispositivos móviles, esperan coordenadas o objetos LatLng en el orden de [latitude, longitude].
Si la renderización del mapa es incorrecta, debes iterar las coordenadas en la carga útil de GeoJSON y transponer los valores antes de pasarlos al SDK de Maps.
¿Por qué hay "agujeros" huecos dentro de mi polígono de isócrona y puedo obtener una forma sólida en su lugar?
Los agujeros representan áreas sin rutas accesibles dentro del límite de tiempo. Esto es común en regiones con grandes bosques, cuerpos de agua, aeropuertos o propiedades privadas donde no pueden viajar vehículos ni peatones.
La API externa de v1 no expone un parámetro para quitar agujeros automáticamente. Si tu aplicación requiere un límite sólido, por ejemplo, para realizar verificaciones de contención de puntos en polígonos, puedes hacer lo siguiente:
- Establece el parámetro
polygon_fidelityenMEDIUMoLOWpara alentar al algoritmo a generalizar y combinar estos espacios internos. - Usa una biblioteca GIS del cliente (como Turf.js) para analizar el GeoJSON y extraer solo el primer anillo de coordenadas (el shell exterior), descartando los anillos interiores posteriores (los agujeros).
¿Debo habilitar la opción enable_smoothing para el análisis espacial de backend?
No. El parámetro enable_smoothing está diseñado exclusivamente para la estética visual.
Redondea las esquinas pronunciadas de la cuadrícula de cálculo subyacente para que la forma se vea orgánica en un mapa.
No se recomienda el suavizado para el análisis espacial preciso, ya que altera los vértices y desplaza los límites ligeramente. Para los cálculos de backend, las consultas de bases de datos o las pruebas de puntos en polígonos, mantén enable_smoothing establecido en false para asegurarte de usar el límite calculado con precisión matemática.