La decisión de qué proveedor de mapas usar en una app de transporte regional se toma generalmente al principio del proyecto, con el criterio de qué es más rápido de integrar o más barato en el tier gratuito. Lo que esa decisión raramente considera es que el mapa no es el fondo visual de la pantalla del pasajero — es el motor que calcula los ETAs antes de aceptar el viaje, traza la ruta del conductor desde su posición actual hasta el origen, geocodifica las direcciones que los usuarios escriben en formas que pocas veces coinciden con la nomenclatura oficial, y determina si el conductor en una zona de baja conectividad puede navegar sin internet. En operaciones de 300 a 700 viajes diarios en ciudades medianas de México o Colombia, el proveedor equivocado produce problemas que no tienen nombre en el dashboard pero sí tienen costo: tiempos de espera reales más altos que los ETAs prometidos, solicitudes que nunca encuentran al conductor, y viajes fallidos en colonias donde el geocodificador no tiene datos suficientes.

Este artículo es para operadores que están eligiendo su stack de mapas antes del lanzamiento, o que ya tienen uno activo y están evaluando si el costo mensual o los problemas operativos justifican una migración. Los tres proveedores con mayor adopción en plataformas de ride-hailing regional — Google Maps Platform, HERE Maps y Mapbox — difieren en precio a escala, en profundidad de cobertura en ciudades secundarias de LATAM, en las capacidades offline que cada SDK expone, y en qué tan bien interpreta cada uno las formas en que los pasajeros regionales realmente escriben sus direcciones. La elección correcta no es la misma para todos los casos: depende del volumen actual, de las ciudades específicas donde opera la plataforma, y de si los requisitos del conductor y del pasajero apuntan al mismo proveedor o a dos distintos.

Los tres proveedores de mapas y en qué se diferencian

Google Maps Platform domina el mercado de aplicaciones de consumo por razones concretas: tiene la mayor densidad de datos en casi cualquier ciudad de LATAM, incluyendo municipios de segundo y tercer nivel donde los otros dos proveedores tienen blancos en el mapa. Su base de datos de lugares, restricciones de circulación y calles nuevas se actualiza con mayor frecuencia, y el geocodificador puede interpretar referencias a establecimientos conocidos que los usuarios regionales usan como referencia de dirección — no solo el número de calle sino el OXXO de la esquina o el mercado central. La desventaja es estructural: Google Maps Platform cobra por cada llamada a la API, sin un modelo de precio plano, y los costos crecen de forma no lineal conforme la operación escala. En una plataforma que usa enrutamiento, geocodificación, seguimiento en tiempo real y matrices de distancia simultáneamente, ese modelo puede producir facturas que el operador no anticipó cuando hizo las proyecciones iniciales con el volumen de una operación pequeña.

HERE Maps tiene un origen distinto: nació como tecnología de navegación para la industria automotriz y durante años fue el proveedor de datos de mapas que usaban los fabricantes de automóviles en sus sistemas de navegación integrados. Eso le da una fortaleza específica en el contexto de ride-hailing: datos de tráfico en tiempo real de alta precisión, mapas diseñados para navegación vehicular con soporte sólido de rutas offline, y un modelo de precios que en volúmenes medios puede ser entre un 30% y un 50% más barato que Google Maps Platform. Las debilidades están en la familiaridad del SDK para equipos técnicos que aprendieron con Google, y en ciudades pequeñas y periféricas de LATAM donde la cobertura de calles es menos densa y la geocodificación de direcciones informales produce más errores que el competidor principal.

Mapbox es el proveedor con el modelo más abierto: construye su cobertura sobre OpenStreetMap, la base de datos geográfica colaborativa que cualquier persona puede editar, y añade encima datos comerciales propios y herramientas de diseño que ninguno de los otros dos ofrece en el mismo grado. Su SDK es el más personalizable — permite modificar el estilo visual del mapa, integrar datos propios y construir componentes de navegación con un nivel de control que Google y HERE no exponen. El precio es competitivo: el tier gratuito es generoso y el costo por llamada en las categorías de mapa base y seguimiento en tiempo real es menor que en los otros dos. La limitación principal en LATAM es la dependencia de OpenStreetMap: en ciudades medianas de México, Colombia, Perú y Bolivia donde la comunidad de contribuidores activos es pequeña, los datos de calles pueden estar incompletos o desactualizados en colonias nuevas, fraccionamientos cerrados y zonas periféricas donde una parte significativa de la demanda de taxi ocurre.

El costo real de las llamadas a la API en una operación de 400 viajes diarios

La comparación de precios entre proveedores solo es útil si se calcula sobre las llamadas reales que genera un viaje, no sobre el precio de lista de una sola API. Un viaje en una app de taxi genera en promedio entre 8 y 14 llamadas a la API de mapas: geocodificación de la dirección de origen, geocodificación de destino, cálculo de ETA antes de la asignación, enrutamiento del conductor hasta el pasajero, enrutamiento del trayecto, actualizaciones de posición en tiempo real durante el recorrido, y en algunas implementaciones el recálculo de la tarifa final con la ruta real recorrida. Para una operación de 400 viajes diarios con 10 a 12 llamadas por viaje, eso representa entre 120,000 y 145,000 llamadas mensuales — volumen suficiente para que la diferencia entre proveedores sea relevante en la estructura de costos.

Por qué la cobertura offline importa más en LATAM que en Europa o Estados Unidos

Los benchmarks de rendimiento de proveedores de mapas se publican principalmente para mercados donde la cobertura celular en zonas urbanas es casi universal. En ciudades medianas de LATAM, la conectividad del conductor en el trabajo real es distinta: hay colonias periféricas, carreteras de acceso a fraccionamientos nuevos y zonas industriales donde la señal 4G es inconsistente y el conductor pierde la ruta si el SDK no puede operar sin conexión. El problema no es exclusivo de ciudades pequeñas — ocurre en ciudades de 300,000 o 500,000 habitantes con desarrollo periférico reciente donde la infraestructura de telecomunicaciones todavía no alcanza la densidad que la cobertura en el mapa del operador sugiere. En esas zonas, un SDK que necesita conexión continua para actualizar la ruta deja al conductor sin navegación funcional justo en el trayecto que más incertidumbre genera para el pasajero.

La capacidad offline de los tres proveedores es notablemente distinta. HERE Maps tiene la funcionalidad offline más madura, resultado directo de su historia en navegación automotriz: permite descargar paquetes de mapas por región y calcular rutas completas sin conexión activa. El SDK de Google Maps para iOS y Android puede operar parcialmente offline en áreas previamente descargadas, pero con limitaciones en el recálculo dinámico de rutas cuando el conductor se desvía del trayecto original. Mapbox permite descargar áreas específicas de mapa base, pero las capacidades de navegación turn-by-turn offline son más variables dependiendo de cómo se implemente el SDK y qué componentes se activen. Para operadores en ciudades donde la conectividad del conductor es un factor real, la evaluación de capacidades offline no es una funcionalidad secundaria — es uno de los tres criterios principales de la decisión junto al precio y a la cobertura de calles.

Geocodificación de direcciones informales: el diferenciador que no aparece en ningún benchmark

Una de las diferencias menos documentadas entre proveedores de mapas, y una de las más relevantes para operaciones en LATAM, es qué tan bien funciona cada geocodificador cuando el usuario escribe una dirección de la forma en que realmente la conoce. En México, Colombia y gran parte de LATAM, muchas direcciones no tienen número de calle formal o el número no coincide con la base de datos oficial: el pasajero escribe 'frente al OXXO en la avenida Insurgentes', 'a media cuadra del mercado Juárez' o simplemente el nombre de la colonia con una calle cercana de referencia. El geocodificador que produce las coordenadas más precisas para ese tipo de entrada es el que reduce los errores de recogida — conductores que esperan en el número de calle incorrecto, pasajeros que ven el pin en la acera equivocada — que son la segunda causa más frecuente de cancelaciones después de los tiempos de espera prolongados. Google Maps tiene ventaja estructural en este punto por la profundidad de su base de datos de lugares: el geocodificador puede interpretar referencias a establecimientos conocidos y producir coordenadas útiles incluso para entradas muy informales. HERE funciona bien en direcciones formales pero su desempeño con referencias informales en ciudades secundarias es menos consistente. Mapbox depende de la densidad de datos de OpenStreetMap en el área, con resultados más variables en ciudades con baja actividad de contribuidores.

El SDK del conductor y el del pasajero tienen requisitos distintos

Un error frecuente al elegir el proveedor de mapas es aplicar los mismos criterios de evaluación al SDK que usa el conductor y al que usa el pasajero. Las prioridades son distintas porque los casos de uso son distintos. El SDK del pasajero necesita principalmente un mapa visual limpio, autocompletado de direcciones preciso y seguimiento fluido de la posición del conductor en tiempo real — los tres puntos fuertes de Google Maps Platform. El SDK del conductor necesita principalmente navegación turn-by-turn confiable con GPS snapping sobre la calle correcta, capacidad de funcionamiento con conectividad intermitente, y recalculation de ruta rápida cuando hay desvíos — los puntos donde HERE Maps tiene ventaja histórica. Algunos operadores regionales resuelven esta diferencia de requisitos usando proveedores distintos para cada app: Google Maps para la app del pasajero donde la experiencia visual y la geocodificación son prioritarias, y HERE Maps o una implementación offline de Mapbox para la app del conductor donde la navegación sin conexión es más relevante. Esta estrategia tiene un costo de integración adicional pero elimina el compromiso de usar un único proveedor que no es el más adecuado para ninguna de las dos aplicaciones. La decisión vale la pena evaluar cuando la operación supera los 200 viajes diarios y los problemas de navegación o geocodificación empiezan a aparecer de forma repetida en el mismo tipo de viaje.

Cuándo migrar de proveedor y cuándo el costo de cambio no vale la pena

Para operaciones con menos de 200 viajes diarios, el costo de la API de mapas rara vez representa una parte significativa de la estructura de costos — en ese volumen, ningún proveedor genera facturas que afecten materialmente la economía de la operación. En esa etapa el criterio más relevante es la velocidad de integración: qué tan rápido puede el equipo técnico tener el SDK funcionando con las funcionalidades base. Google Maps gana ese criterio por la madurez de su documentación y la amplitud de la comunidad de desarrolladores. La conversación sobre si migrar a HERE o Mapbox por razones de costo empieza a ser relevante cuando la operación supera los 300 a 400 viajes diarios y la factura mensual de mapas supera los $600 a $800 USD. En ese punto, la diferencia entre proveedores puede representar entre $300 y $700 USD mensuales — suficiente para justificar cuatro a seis semanas de trabajo técnico de migración. Lo que el análisis de migración necesita considerar, además del diferencial de precio, es el período de degradación de calidad que ocurre mientras el nuevo proveedor se calibra en la operación real: conductores que reportan inconsistencias en el GPS snapping, geocodificaciones que retornan resultados distintos a los que el pasajero espera, y zonas donde la cobertura del nuevo proveedor es menor que la del anterior.

La elección del proveedor de mapas no es una decisión técnica de arquitectura que el equipo de producto toma al inicio del proyecto y no vuelve a revisar. Es una decisión con consecuencias operativas directas: en la tasa de cancelaciones por ETA incorrecto, en el porcentaje de viajes fallidos por geocodificación inexacta en colonias periféricas, y en los costos de plataforma que a 400 viajes diarios pueden representar entre $200 y $700 USD de diferencia mensual dependiendo del proveedor y del mix de APIs. El operador que revisa esa decisión cuando ya tiene volumen real tiene los datos para tomarla correctamente; el que la optimiza en el mes uno con estimaciones de lo que espera que ocurra toma la decisión con información incompleta sobre el comportamiento real de los conductores y los pasajeros en sus ciudades específicas.

Lo que hace útil la comparación de proveedores no es un benchmark abstracto de cuál es mejor en condiciones de laboratorio — es la evaluación de cada uno contra los requerimientos concretos de la operación: las ciudades donde se opera y la densidad de datos de cada proveedor en esas ciudades, el perfil de conectividad de los conductores en las zonas periféricas activas, el nivel de formalidad de las direcciones que los pasajeros escriben, y el volumen al que el diferencial de costo se vuelve relevante. Esa evaluación toma dos o tres semanas con pruebas en entorno real de producción y es considerablemente más barata que seis meses operando con un proveedor que produce problemas que el operador no puede nombrar pero sí puede medir en las métricas que importan.