Apple Maps vs Google Maps: el caso de Madrid
La capa de transporte público de Apple Maps empezó (por fin) a funcionar en Madrid el pasado 28 de junio.
Por pura deformación profesional, porque llevo tres años lidiando con este problema y porque como madrileña me interesa saber de dónde han sacado los datos y cómo entienden la ciudad, dediqué algunas horas a analizarlo y a compararlo con el otro gigante del sector, Google Maps.
Spoiler: no me extraña que hayan tardado en lanzar porque Madrid es un dolor de cabeza en cuanto a datos de transporte. No es que la red sea amplia (que lo es) y tenga muchos modos diferentes (que los tiene), es que sus datos no están integrados y cada medio de transporte lucha su guerra.
¿Os suena la Tarjeta Multichapuza del Consorcio de Transportes, que promete unificar todos los billetes pero vale menos que una pinza?
Pues esto es igual.
Dicho esto: el trabajo que ha hecho Apple en Madrid es bastante brutal.
Con una app así puedes ganar de tres formas: con diseño, con funcionalidades o, principalmente, con datos.
La información de transporte es muy sensible — qué más da una interfaz bonita si no me das la ruta correcta o me dices exactamente cuándo pasa mi autobús — y siendo Google una empresa que pretende organizar toda la información del mundo yo esperaría algo más fino por su parte. Pero tengo la sensación de que Google aplica a su capa de transporte la misma filosofía que a su buscador: enchufar todos los datos que haya y que un algoritmo los procese. Si esos datos necesitan algo de cuidado humano, ¡lo siento! No es mi negocio.
Éste es un pequeño ejemplo reciente:
Uno de los autobuses que sustituye a la Línea 5 se llama SE2, pero la EMT lo llama en sus datos SE752. En la vida real no existe ningún SE752. Apple se toma la molestia de editarlo y Google no.
El detalle es mínimo. Pero es el primero de tantos que he quedado 😍 entusiasmada 😍 al ver que una gran empresa dedica tal atención a Madrid.
¿Qué medios de transporte (y datos) hay en la Comunidad de Madrid?
Tenemos: autobuses de Madrid (EMT), Metro, Cercanías, autobuses interurbanos (los verdes), autobuses urbanos de municipios de fuera de Madrid y Bicimad, que no incluyen ni Apple ni Google.
De los cuales:
- EMT: tiene datos abiertos, limpios y actualizados.
- Metro: tiene datos abiertos sin actualizar desde 2016 (ej. a Campo de las Naciones no le han cambiado el nombre a Feria de Madrid)
- Cercanías: la red está mal diseñada y por eso nadie la entiende. Los datos abiertos reflejan el desorden, llevan un año sin actualizarse y tienen muchos errores (lo sé porque me los he estudiado).
- Interurbanos y urbanos: hay abiertos algunos datos de algunas rutas, pero en general están bastante mal.
Nota: que no haya datos abiertos no significa que Apple o Google no accedan a ellos. Hay líneas de interurbanos que a Google le da ALSA, mientras que Apple sólo cita al Consorcio de Transportes de Madrid.
¿Qué medios de transporte (y datos) incluyen Apple y Google?
Ambas tienen de todo, pero con matices.
Autobuses interurbanos
Hay paradas de autobús interurbano que existen en la vida real y en Apple, pero no en Google.
También hay líneas de autobús urbano e interurbano que existen en la vida real y en Apple, pero no en Google.
Also: ¿estación de autobuses, Google? Es una parada.
En las verdaderas estaciones de autobuses (¡los intercambiadores!) Apple también gana a Google: incluye todas las líneas, las pinta de verde y las combina en una gran estación con el Metro — tal y como sucede en la vida real.
(Mi diseño ideal de intercambiador incluye búsqueda por línea + información de dársena y nivel, pero nadie ha solucionado eso aún)
Metro, EMT e incidencias
El Metro de Madrid y los autobuses de la EMT están bien resueltos en ambos casos, quizá porque los datos vienen correctos de serie.
Incluso Google ha mejorado y ha cerrado la Línea 5 🎉 , algo que no hizo el verano pasado con la Línea 1, que cerró por obras durante tres meses y nunca dejó de aparecer sugerida en Google Maps.
Apple también la cierra, aunque sólo da rutas que evitan la Línea 5, sin informar de la incidencia. Quizá el usuario que espere una ruta en Línea 5 entre dos paradas de Línea 5 necesite saber por qué no aparece y quede confuso al ver un resultado de Línea 6 + bus. ¿No?
Tren
El de Cercanías es un caso especial. Tanto el plano como la señalética en las estaciones como los horarios de su web cuentan verdades diferentes, así que da igual cómo lo muestres en tu app: nunca estará del todo bien.
Un ejemplo: la C2 empieza siendo C2 y termina siendo C8 según el plano, aunque según los horarios a veces es C8A o C8B.
[Hablamos largo y tendido de éste y otros casos aquí]
¿Dónde y cómo representas los trenes en pantalla? Los representas sobre el mapa, en las tablas de horarios de cada estación y en las rutas sugeridas. ¿Y qué necesitas saber cuando coges el tren? Necesitas saber dónde va (paradas intermedias, porque poca gente conoce las líneas de Cercanías como las del Metro, y cabecera) y número de andén.
Por partes:
- Sobre el mapa, la solución de Apple y Google es parecida: no pintan las líneas de Cercanías de diferentes colores, sino de uno solo para diferenciarlas del Metro. Tampoco incluyen su nombre.
- En las tablas de horarios, ni Apple ni Google muestran paradas intermedias ni andén. Lo primero es factible pero lo segundo no: la información de andén no está disponible de forma abierta en ningún sitio (sólo la da la app de ADIF, ni siquiera la app del Consorcio de Madrid) así que nadie la ha incluido aún.
Además, Google muestra trenes regionales que existen, pero que NO puedes coger dentro de Madrid.
Creo que éste es el reflejo más claro de lo que decía arriba: Google mete toda la información que tiene, pero no se preocupa de editar la que no sirve o puede confundir a la gente.
Al sugerir rutas, la mejor forma de saber quién gana en trenes es comprobar quién sabe que C2 y C8 son la misma línea y hay trenes directos Guadalajara-Cercedilla y viceversa.
¿Por qué? Todos los sets de datos que he visto en Madrid consideran que, entre Cercedilla y Guadalajara, hay que hacer transbordo en Chamartín (que es donde la línea cambia de C2 a C8). Y no es verdad.
Para dar bien la información, hay que a) saber esto b) unir ambos trenes en los datos y c) no decirle al usuario que baje.
Google lo hace mal:
Y Apple bien:
Conclusión: o Apple tiene acceso a muy buenos datos o se ha preocupado de entender que en Chamartín no hay que hacer transbordo entre C2 y C8.
¡No todo el mundo llega hasta ahí!
Diseño
Lo más bonito al representar una red de transporte sobre un mapa son los trazados de las líneas.
Incluso hechos a mano, son un problema bastante complejo de resolver, especialmente cuando juntas varias líneas y estaciones.
Los planos esquemáticos que diseñan las agencias no están pensados para ajustarse a la realidad, sino para que el usuario entienda de un vistazo cuántas estaciones hay entre A y B y qué líneas conectan con otras.
Pero Google y Apple tienen de base un mapa geográfico, que sí refleja la realidad. ¿Cómo representas líneas y estaciones sobre él y mantienes la armonía?
Como en otras ciudades, Google aplica robots y Apple artesanía. La mejor forma de verlo es haciendo zoom en una estación compleja, como Sol.
Eso sí: ninguna es perfecta. En Atocha, Apple luce más bonita, pero la información más parecida a la realidad (que Atocha Renfe conecta Metro y Cercanías) la da Google.
No puedes ganar en todo ¯\_(ツ)_/¯
Otros detalles
Apple conoce algunas salidas de Metro y Google no
(ninguna conoce la correcta 😏)
Apple conoce los pasos subterráneos y Google no
Repite conmigo: “organizar toda la información del mundo y hacerla accesible (…)”
Y ninguna lleva del todo bien la información en tiempo real
EMT Madrid tiene una API abierta con información precisa sobre cuándo llega el bus. Google no la usa y Apple sólo a veces.
Siempre que leas que un autobús pasa “cada X minutos”, estarás viendo información basada en horarios.
¿Y ahora cómo vamos a mantener esto?
Entiendo que si Apple ha esperado tanto a hacer Madrid es porque quería hacerlo bien. Y no la he probado sobre terreno — donde puede que haya horarios incorrectos o algún otro fallo — pero trasteando un par de horas desde mi silla de oficina de Londres he encontrado suficientes razones para reconocer que, al menos en su primera versión, se lo han currado.
El transporte, como los mapas, cambia todo el rato. Y en Madrid a los datos aún les queda mucho para ser robóticos y perfectos, así que es necesaria una atención (en parte, humana) casi constante. Eso o se desactualizan y tu app pierde a la gente.
Cuando Apple presentó sus mapas en 2012 toda la industria se rió en su cara porque estaban fatal. Tanto que su CEO, Tim Cook, pidió perdón en público y recomendó usar los mapas de Google o Nokia.
At Apple, we strive to make world-class products that deliver the best experience possible to our customers. With the launch of our new Maps last week, we fell short on this commitment (…)
While we’re improving Maps, you can try alternatives by downloading map apps from the App Store or use Google or Nokia maps.
Cinco años después, Apple Maps sigue sin estar disponible en todo el mundo y sólo da direcciones con transporte público en 50 ciudades, mientras Google incorpora todos los sets de datos que encuentra.
La estrategia es extremadamente diferente — poco y muy bien hecho, en lugar de mucho y mal — , pero creo que el resultado tiene sentido: nadie volverá a confiar en ti una vez le hayas perdido (o le hayas metido por un cementerio de noche, como me ha hecho a mí Google Maps).
Disclaimer: trabajo en Citymapper, una app de transporte público que también funciona en Madrid. Este post sólo recoge mi opinión, no la de la compañía.
