¿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 servicios.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 muy refinada y de alta resolución 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 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 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 medio de transporte tiene un umbral de distancia de ajuste máxima específico:
DRIVE: 200 metros (ignora las rutas solo para peatones).TWO_WHEELER: 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.
¿Por qué recibo un error cuando solicito el enrutamiento con información del tráfico para caminar o andar en bicicleta?
Las condiciones de tráfico en vivo (TRAFFIC_AWARE) se admiten para los medios de transporte DRIVE y TWO_WHEELER. Si intentas solicitar una isócrona para WALK o BICYCLE con routingPreference establecido en TRAFFIC_AWARE, la API muestra 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é está causando 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 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 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 renderizar.
¿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 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 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 ligeramente los límites. 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.