Preguntas frecuentes sobre la API de Isochrones

¿Cómo calculo una isócrona de entrada de "viaje al trabajo" (viaje hacia un destino) en comparación con una isócrona de salida (viaje desde un origen)?

Los cálculos de entrada y salida se admiten en la API de v1 con el parámetro travelDirection (travel_direction):

• FROM (saliente): Calcula el área a la que se puede llegar from el 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 (Entrante): Calcula el área desde la que puedes viajar to el punto de origen dentro del límite de tiempo especificado. Esto es adecuado para aplicaciones como las funciones de viaje diario al trabajo o la determinación de zonas de influencia alrededor de una oficina central o un centro de transporte público.

Nota: Los polígonos FROM y TO para el mismo origen y la misma duración pueden ser asimétricos en todos los modos. En el caso de DRIVE, TWO_WHEELER y BICYCLE, las causas incluyen calles de un solo sentido y restricciones de giro. En el caso de DRIVE y TWO_WHEELER, también contribuyen las rampas de entrada y salida de las autopistas, y la congestión del tráfico direccional. Para WALK y BICYCLE, la pendiente también es importante, ya que el viaje cuesta arriba es más lento que cuesta abajo.

¿En qué se diferencian los cuatro modos de viaje (DRIVE, TWO_WHEELER, BICYCLE y WALK)?

Cada modo usa sus propias reglas de acceso a la red de rutas, costos de giro y modelo de velocidad:

• DRIVE: Recorre rutas transitables con velocidades publicadas o de flujo libre, o bien velocidades de tráfico en tiempo real (TRAFFIC_AWARE), hasta 3,600 segundos (60 minutos).
• TWO_WHEELER: Recorre rutas accesibles para vehículos motorizados de dos ruedas con velocidades modeladas más bajas que DRIVE en rutas de alta velocidad y rutas TRAFFIC_AWARE opcionales, hasta 3,600 segundos (60 minutos). Como resultado, una isócrona de TWO_WHEELER es más grande que una de BICYCLE, pero más pequeña que una de DRIVE en autopistas de alta velocidad.
• BICYCLE: Recorre calles, ciclovías y rutas accesibles para bicicletas con velocidades ajustadas según el tipo de camino y la pendiente (se excluyen autopistas y autovías), hasta 7,200 segundos (120 minutos).
• WALK: Recorre aceras, senderos y calles peatonales con una velocidad de caminata ajustada según la pendiente (se ignoran las restricciones de sentido único para vehículos), hasta 7,200 segundos (120 minutos).

¿La API de Isochrones incluye transbordadores o cruces de agua?

No. La API de Isochrones solo recorre conexiones de rutas, puentes, túneles y caminos. Se excluyen las rutas de ferry y los cruces de agua en todos los modos de viaje. Las islas o penínsulas conectadas solo por ferry no se incluirán en una isócrona generada desde el continente.

A veces, el polígono que se devuelve tiene un aspecto de bloques o bordes escalonados y dentados, especialmente en el caso de 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 los valores de travel_duration y travel_mode solicitados:

• Duraciones más cortas: Usa una cuadrícula de alta resolución muy refinada, ya que el área total es pequeña, lo que genera un límite detallado.
• Duraciones más largas: Transición a una cuadrícula más gruesa y de menor resolución para cubrir el vasto área geográfica 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é, a veces, cuando se solicita una isócrona para una coordenada dentro de un parque, un lago o un complejo industrial grande, se devuelve un error "Not Found"?

La API de Isochrones calcula la duración de los viajes usando rutas y caminos. La API debe "ajustar" el punto al tramo compatible más cercano antes de comenzar el cálculo si las coordenadas de origen que solicitaste no se encuentran en una ruta reconocida.

Cada medio de transporte tiene una distancia máxima de ajuste de alrededor de 200 metros o menos. WALK y BICYCLE usan distancias más cortas que DRIVE y TWO_WHEELER, y DRIVE y TWO_WHEELER ignoran los caminos solo para peatones.

Si la coordenada de origen se encuentra más lejos de un tramo de ruta válido y compatible con el modo que esta distancia, la corrección falla y la API devuelve un error NOT_FOUND. Para resolver este problema, asegúrate de que tus coordenadas estén cerca de una calle o un sendero públicos.

¿Por qué recibo un error cuando solicito una ruta que tiene en cuenta el tráfico para caminar o andar en bicicleta?

Las condiciones de tráfico en tiempo real (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 devolverá un error 400 INVALID_ARGUMENT.

Cuando renderizo la respuesta de GeoJSON en mi mapa, la forma se muestra en el lugar equivocado, se distorsiona o no se renderiza. ¿Por qué ocurre esto?

Esto casi siempre se debe a una discrepancia en el orden de las coordenadas.

Según el estándar GeoJSON (RFC 7946), la API de Isochrones devuelve 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 mapas 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 de otros SDK: Si analizas manualmente la respuesta en objetos LatLng, debes recorrer 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" vacíos dentro de mi polígono de isócrona? ¿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, masas de agua, aeropuertos o propiedades privadas por las que no pueden circular vehículos ni peatones.

La API externa 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 punto en polígono, puedes hacer lo siguiente:

• Establece el parámetro polygon_fidelity en MEDIUM o LOW para incentivar al algoritmo a generalizar y fusionar estos intervalos internos.
• Usa una biblioteca de GIS del cliente (como Turf.js) para analizar el GeoJSON y extraer solo el primer anillo de coordenadas (el contorno 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 únicamente para la estética visual. Redondea las esquinas agudas 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 establecido en false para asegurarte de usar el límite calculado con precisión matemática.