¿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 carreteras 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 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, especialmente 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 la vasta área geográfica de manera eficiente sin causar una latencia grave.
Puedes configurar el parámetro opcional polygon_fidelity 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 gran complejo industrial a veces muestra un error "No se encontró"?
La API de Isochrones calcula los tiempos de viaje con carreteras 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 carretera reconocida.
Cada modo de viaje tiene un umbral de distancia de ajuste máxima 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 carretera 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.
¿Por qué recibo un error cuando solicito el enrutamiento con información sobre el tráfico para caminar o andar en bicicleta?
Las condiciones de tráfico en tiempo real (TRAFFIC_AWARE) se admiten exclusivamente para el modo de viaje DRIVE. Si intentas solicitar una isócrona para WALK o BICYCLE con routingPreference configurado como TRAFFIC_AWARE, la API mostrará un error 400 INVALID_ARGUMENT.
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 Maps y objetos de geometría personalizados esperan coordenadas en el orden de [latitude, longitude].
Si la renderización del mapa es incorrecta, verifica cómo el SDK de Maps controla GeoJSON:
- API de Maps JavaScript: Si usas la capa de datos (
map.data.addGeoJson()), este orden se controla de forma nativa y no se requiere ninguna acción. - Objetos personalizados o otros SDKs: Si analizas manualmente la respuesta en objetos
LatLng, debes iterar las coordenadas en la carga útil de GeoJSON y transponer los valores[lng, lat]en pares[lat, lng]antes de la renderización.
¿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 carreteras 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 v1 no expone un parámetro para quitar automáticamente los agujeros. Si tu aplicación requiere un límite sólido, por ejemplo, para realizar verificaciones de contención de punto en polígono, puedes hacer lo siguiente:
- Configura 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 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 ligeramente los límites. Para los cálculos de backend, las consultas de bases de datos o las pruebas de punto en polígono, mantén enable_smoothing configurado como false para asegurarte de usar el límite calculado con precisión matemática.