Datos
INTRODUCCIÓN
Los vehículos de micromovilidad compartida producen una gran cantidad de datos e información que las ciudades necesitarán para comprender plenamente el impacto de estos servicios en todos los frentes, desde las operaciones, pasando por la planeación, hasta la equidad.
Las ciudades no actuaron con prontitud suficiente para establecer normas de intercambio de datos cuando las empresas de redes de transporte (TNC por sus siglas en inglés) llegaron hace casi una década. Como estos nuevos servicios aún están en etapas tempranas de desarrollo, las ciudades aún tienen la oportunidad de evitar repetir este error y exigir los datos que llevarán a una toma de decisiones más informadas.
Para ello las ciudades deberán establecer requisitos claros de intercambio de datos con los operadores para que identifiquen la información que se busca, cómo se manejará y almacenará, la calidad, exactitud, formato y frecuencia de la información solicitada, al igual que las directrices de privacidad para su recopilación, almacenamiento y utilización. Del mismo modo, la definición de información de identificación personal (PII por sus siglas en inglés) cambia a gran velocidad y difiere sustancialmente entre jurisdicciones, por lo cual será importante para las ciudades ser claras acerca de lo que la ciudad y el estado consideren como PII y la mejor manera de administrar y proteger esos datos.
ESTÁNDARES NACIONALES
Todos los gobiernos locales que desarrollen políticas de micromovilidad deberían incluir estas disposiciones generales con el fin de asegurar que sus normativas aborden estos problemas de modo similar en todas las comunidades.
-
1
API de flota
Las ciudades deberían exigir una interfaz de programación de aplicaciones (API por sus siglas en inglés) -un intermediario de software que permite que dos aplicaciones hablen entre ellas- con datos de todas las empresas para permitir a la ciudad monitorear y hacer cumplir los requisitos normativos y de las operaciones de las flotas.
-
2
Formato de datos
Idealmente las ciudades se deberían esforzar por exigir y utilizar una API autenticada y normalizada, como los formatos de la General Bike Share Feed Specification (GBFS) o Mobility Data Specification (MDS). Pero algunas ciudades podrían aún tener que solicitar los datos en formatos .xsl, .csv u otros.
-
3
Datos históricos de actividad de viajes
Las ciudades deberían exigir a los operadores entregar datos históricos de actividad de viajes de manera regular según lo determine la ciudad.
-
4
Privacidad
Las ciudades deberían crear prácticas estrictas para la privacidad de datos y requisitos a los proveedores tales como:
- El cumplimiento de las normas de privacidad de la ciudad y de los niveles superiores de gobierno;
- La priorización de la recopilación de datos de los vehículos más que de los usuarios, en especial los datos basados en ubicación;
- Una política clara de protección de información de identificación personal para evitar su divulgación pública sin haber sido previamente agregada u oscurecida;
- El uso del servicio no debería estar atado al acceso a datos o al dispositivo personal;
- Requisitos de solicitud de acceso a cualquier elemento del dispositivo del usuario, incluyendo la cámara, los contactos o la ubicación;
- Los operadores deberían expresar claramente qué datos recopilan de los usuarios y explicar para qué lo hacen;
- Una prohibición a la venta de los datos a terceros.
-
5
Seguimiento por GPS
Los vehículos deberían indicar su ubicación cada 90 segundos y poner los datos a disposición de la ciudad; y todos los datos de ubicación entregados a la ciudad por medio de la API del operador deberían provenir del vehículo y no del GPS del usuario.
SECCIONES DE POLÍTICA
Propiedad de los datos
Con la introducción de tantos nuevos servicios de movilidad, las ciudades tienen la capacidad de acceder a más datos que nunca. Pero, de la mano de estos nuevos datos llegan nuevas responsabilidades de determinar cómo serán almacenados para su agregación y análisis.
Agencia reguladora
Los datos solicitados se entregan directamente a la agencia reguladora.
VENTAJAS
Gran control sobre los datos y su análisis; evita conflictos sobre la transferencia de datos entre partes y los requisitos legales.
DESVENTAJAS
La entidad podría no tener la experiencia o la capacidad de manejar, analizar o asegurar estos datos de forma efectiva; podría crear problemas de privacidad en jurisdicciones con leyes de registros abiertos.
Tercero
Los datos solicitados se suministran a través de un tercero como una institución académica, una entidad sin ánimo de lucro o una plataforma de análisis de datos.
VENTAJAS
Probablemente la entidad ha sido constituida para este propósito; mayor capacidad de administrar, analizar y asegurar los datos; podría aplacar las preocupaciones por la seguridad; puede ofrecer herramientas de análisis con valor agregado a fin de ayudar a la ciudad con la interpretación de los datos y su uso para los procesos de aplicación de las normas, evaluación y planeación.
DESVENTAJAS
Podría generar menor control sobre los datos y sus usos; podría generar problemas de financiación; existiría el riesgo de amarrarse con un proveedor o de depender continuamente de una suscripción para acceder a los datos; en un escenario académico se podría sufrir de problemas de rotación relacionados con la matrícula.
Métodos de recolección
A medida que las ciudades hagan seguimiento a la utilización de estos servicios, necesitarán desarrollar un sentido claro de los datos que necesitan recolectar y asegurarse de que los operadores puedan proporcionarlos.
Datos en tiempo real
Los datos en tiempo real son información que se entrega inmediatamente después de ser recolectada.
VENTAJAS
Es información minuto a minuto de lo que ocurre en la comunidad; es efectivo para verificar y asegurar el cumplimiento en tiempo real. Puede ser suministrada a la ciudad por medio de la API o plataformas de análisis de terceros.
DESVENTAJAS
La entidad podría no tener la capacidad o condición para administrar datos en tiempo real; podría generar problemas de seguridad en jurisdicciones que tengan leyes de datos abiertos; deben ser recolectados y archivados continuamente para su uso en análisis históricos.
CASO DE ESTUDIO
Austin, TX
Las normas de Austin establecen que el licenciatario deberá facilitar al director o a un tercero autorizado por el director información en tiempo real e histórica de toda su flota a través de una interfaz de programación de aplicaciones (API) documentada y basada en la web. El licenciatario es el responsable directo de proporcionar la llave de la API al director y no remitirá a la Ciudad con el representante de otra filial o de la empresa matriz para el acceso a la API. La API entregará los datos de conformidad con las especificaciones más recientes autorizadas por el Director, de modo que se proteja la privacidad de los usuarios individuales. Reglas definitivas del Director para el despliegue y operación de los sistemas de movilidad con vehículos pequeños de Austin
Datos históricos de actividad
Los datos de actividad proporcionan un conocimiento más profundo acerca de la utilización de los servicios de micromovilidad.
VENTAJAS
Permite un análisis más profundo de las tendencias incluyendo los datos de viajes, número de usuarios, mantenimiento y aspectos de seguridad, entre otros.
DESVENTAJAS
La entidad podría no tener la capacidad o condición para administrar datos; podría generar problemas de seguridad en jurisdicciones que tengan leyes de datos abiertos; no proporciona datos para la operación y gestión diaria.
Datos de encuestas
Los datos de encuestas surgen de la participación directa y entrevistas a los usuarios.
VENTAJAS
Puede obtener retroalimentación cualitativa sobre los servicios y operaciones y formular preguntas acerca de los datos demográficos y otra información que no podría ser recopilada por los operadores por asuntos de privacidad; desarrollar la encuesta requeriría de tiempo del personal y recursos.
DESVENTAJAS
Puede llevar mucho tiempo y ser costoso de gestionar. debe limitarse a una vez por período de renovación del permiso o anualmente, la que sea menos frecuente.
CASO DE ESTUDIO
St. Louis, MO
Los operadores de los sistemas de bicicletas compartidas deben estar dispuestos a distribuir una encuesta a los clientes y no clientes de la ciudad de St. Louis con una frecuencia máxima no superior a un año. Requisitos de Permisos del Programa de Bicicletas Compartidas de St. Louis
RECOMENDACIONES
Las ciudades deberían exigir reportes de actividad histórica frecuentes y periódicos (semanales / mensuales) a fin de contar con información actualizada acerca de cómo están operando estos servicios en sus comunidades. Los datos en tiempo real sobre la disponibilidad y operaciones de los vehículos también deberían estar disponibles por medio de la API para uso de la ciudad o de las plataformas de análisis de terceros.
Las ciudades deberían exigir a los proveedores llevar a cabo encuestas de manera frecuente y periódica para entender mejor la manera en que los viajeros usan el servicio, quiénes lo usan, y recopilar información sobre cómo se podría mejorar. Las ciudades deberían trabajar en colaboración con los proveedores a fin de formular preguntas útiles para comprender las repercusiones de los servicios compartidos y distribuir las encuestas a los usuarios. Las ciudades también podrían optar por aliarse con instituciones académicas y los operadores para formular una encuesta.
Las ciudades también deberían considerar el uso de un enfoque estándar para la recopilación de datos entre ciudades, como la Especificación de datos móviles de Los Angeles, para desarrollar un conjunto de datos consistente que quieran obtener de los operadores al negociar los acuerdos de intercambio de datos.
Verificación de datos
Con tantos datos disponibles y preguntas sobre la eficacia de los datos en el pasado reciente, será importante crear procesos para verificar que los datos recibidos son exactos y confiables.
Verificación de la Encuesta nacional de movilidad (Encuesta Origen Destino - EOD)
Realizada por la Administración Federal de Carreteras, la Encuesta nacional de movilidad (NHTS por sus siglas en inglés) o Encuesta Origen Destino (EOD) es la única fuente nacional de datos que permite analizar las tendencias de los viajes personales y domésticos. Incluye los viajes diarios no comerciales en todos los modos, incluyendo las características de las personas que viajan, sus hogares y sus vehículos.
VENTAJAS
La EOD proporciona datos de alta calidad para verificar contra los datos recopilados por los operadores.
DESVENTAJAS
La EOD se realiza cada 10 años, por lo cual estará desactualizada en la mayoría de años.
Auditorías periódicas de datos
Se lleva a cabo un auditoría de datos para evaluar la calidad o utilidad de los datos para un fin determinado. Estas auditorías deberían estar diseñadas para verificar el cumplimiento de los requisitos de intercambio de datos sin sacrificar la exposición de la información de identificación personal.
VENTAJAS
Son una forma directa y clara de validar los datos.
DESVENTAJAS
Pueden ser demoradas y costosas.
CASO DE ESTUDIO
San Francisco, CA
El titular del permiso se compromete a poner sus políticas, procedimientos y prácticas con respecto a la seguridad de los datos a disposición de la SFMTA a su solicitud, y del mismo modo acepta que la SFMTA se reserve el derecho de contratar a un tercero para realizar un auditoría de seguridad hacia la mitad de la vigencia del permiso o cuando la SFMTA decida que se justifica un auditoría.Términos y condiciones del Permiso de patinetas motorizadas compartidas de San Francisco
API
VENTAJAS
Puede usar información de lo que ocurre minuto a minuto.
DESVENTAJAS
No proporciona una imagen completa de todo lo que la ciudad querrá ver.
RECOMENDACIONES
No hay un estándar claro y generalmente aceptado en cuando a los estándares para que las ciudades tengan la seguridad de que los datos que reciben sean precisos. Las ciudades deberían trabajar con otras jurisdicciones, entidades sin ánimo de lucro enfocadas en datos e instituciones académicas para realizar auditorías periódicas y decidir cuáles son los mejores métodos para garantizar la exactitud y eficacia.
Las ciudades deberían incluir disposiciones para revocar permisos a toda empresa que no facilite los datos, no lo haga según se le solicite, o que suministre datos inexactos intencionalmente.
Datos que pueden ser recopilados
Si bien aún no hay un estándar para datos de movilidad completamente codificado en el país, la Mobility Data Specification de Los Angeles (MDS) y la General Bikeshare Feed Specification (GBFS) evolucionan rápidamente y son las más prometedoras en cuanto a la recolección y análisis de datos estandarizada entre ciudades y operadores privados de movilidad.
Similar a un lenguaje común e inspirada en la GBFS y la General Transit Feed Specification (GTFS), la Mobility Data Specification (MDS) es un estándar de datos y una especificación de API para ayudar a los gobiernos municipales a recibir, comparar y analizar los datos de los proveedores de movilidad y así gestionar activamente a los proveedores de movilidad privados de bicicletas compartidas sin anclaje, patinetas eléctricas y a los proveedores de viajes compartidos que trabajen sobre el derecho de vía público. La especificación es una forma de implementar el intercambio, la medición y regulación de datos en tiempo real para los municipios y proveedores de movilidad. Su propósito es garantizar que los gobiernos municipales tengan la capacidad de hacer cumplir, evaluar y gestionar los proveedores.
Bajo el liderazgo de la Asociación norteamericana de bicicletas compartidas, los propietarios y operadores de sistemas de bicicletas compartidas de los sectores públicos, privado y sin ánimo de lucro, junto con desarrolladores de aplicaciones y proveedores de tecnología, han desarrollado la GBFS. La GBFS está concebida como una especificación para datos de solo lectura en tiempo real; se excluyen de esta especificación los datos escritos de vuelta en los sistemas individuales de bicicletas compartidas. La GBFS es una especificación abierta, desarrollada y mantenida por la comunidad de productores y consumidores de datos de GBFS. La especificación no es fija ni inalterable.
A continuación se presenta un ejemplo de los tipos de datos que se pueden recopilar por medio de MDS y GBFS.
Datos de flota
- ID del proveedor
- Nombre del proveedor
- ID del dispositivo
- ID del vehículo
- Días en servicio
- Fecha de ingreso
- Salida de servicio
- Tipo de vehículo
- Bicicleta
- Patineta
- Motoneta
- Moped
- Otro
- Tipo de propulsión
- Humana
- Asistencia eléctrica
- Eléctrica
- Combustión
- Tipo de evento (¿cuál es el estado del vehículo?)
- Disponible
- Reservado
- Suspendido
- Retirado
- Hora del evento
- Latitud
- Longitud
- Carga o Porcentaje de batería
Datos del viaje
- ID del proveedor
- Nombre del proveedor
- ID del dispositivo
- ID del vehículo
- Tipo de vehículo
- Bicicleta
- Patineta
- Motoneta
- Moped
- Otro
- ID del viaje
- Hora de inicio
- Hora de finalización
- Duración del viaje
- Distancia del viaje
- Información de la ruta (incluyendo los puntos de inicio y finalización)
- URL de verificación de estacionamiento (Una URL en la que la ciudad puede ver una fotografía del vehículo estacionado)
- Costo estándar (El costo estándar de realizar el viaje)
- Costo real (El costo realmente pagado por el cliente)
Datos del estacionamiento
- ID del proveedor
- Nombre del proveedor
- ID del dispositivo
- ID del vehículo
- Tipo de vehículo
- Bicicleta
- Patineta
- Motoneta
- Moped
- Otro
- Latitud
- Longitud
- Hora del reporte
- Reportante (¿quién reportó el estado?)
- Proveedor
- Público
- Ciudad
- Otro
- Tipo de reporte (¿qué se reportó?)
- Obstrucción
- Estacionamiento
- Libre
- Tiempo de acción (¿cuánto tardó el operador en responder?)
- Tipo de acción (¿qué acción tomó el operador para resolver?)
- Volver a estacionar
- Sin acción
- Perdido
- Irrecuperable
- Movido por el usuario
Datos de mantenimiento
- ID del proveedor
- Nombre del proveedor
- ID del dispositivo
- ID del vehículo
- Tipo de vehículo
- Bicicleta
- Patineta
- Motoneta
- Moped
- Otro
- Latitud
- Longitud
- Hora del reporte
- Reportante (¿quién reportó la necesidad de mantenimiento?)
- Proveedor
- Público
- Ciudad
- Otro
- Tipo de reporte (¿qué necesita mantenimiento?) (Se deberá crear una lista de con códigos de todas las posibles necesidades de mantenimiento para todos los tipos de vehículos)
- Hora de suspensión
- Hora de acción
- Tipo de acción
- Reparado
- Retirado
- Sin acción
- Perdido
- Irrecuperable
- Movido
Datos del incidente
- ID del proveedor
- Nombre del proveedor
- ID del dispositivo
- ID del vehículo
- Tipo de vehículo
- Bicicleta
- Patineta
- Motoneta
- Moped
- Otro
- Hora del incidente
- Latitud
- Longitud
- Lugar del incidente
- Carril de viaje
- Carril para bicicletas
- Acera
- Otro
- Reportante
- Proveedor
- Público
- Policía
- Ciudad
- Otro
- Acción sobre el vehículo
- Reparado
- Retirado
- Sin acción
- Perdido
- Irrecuperable
- Lesión
- Reporte policial
- Número de reporte policial
