Centro de Investigación Científica y de Educación
Superior de Ensenada, Baja California
MR
Maestría en Ciencias
en Ciencias de la Computación
Contextualización de la movilidad de habitantes de
zonas urbanas desfavorecidas
Tesis
para cubrir parcialmente los requisitos necesarios para obtener el grado de
Maestro en Ciencias
Presenta:
Alberto Gabriel Ramos Salvio
Ensenada, Baja California, México
2018
Tesis defendida por
Alberto Gabriel Ramos Salvio
y aprobada por el siguiente Comité
Dr. José Antonio García Macías
Director de tesis
Dra. Mónica Elizabeth Tentori Espinosa
Dr. Jaime Sánchez García
M.C. Christian Paul García Martínez
Dr. Jesús Favela Vara
Coordinador del Posgrado en Ciencias de la Computación
Dra. Rufina Hernández Martínez
Directora de Estudios de Posgrado
Alberto Gabriel Ramos Salvio © 2018
Queda prohibida la reproducción parcial o total de esta obra sin el permiso formal y explícito del autor y director de la tesis
ii
Resumen de la tesis que presenta Alberto Gabriel Ramos Salvio como requisito parcialpara la obtención del grado de Maestro en Ciencias en Ciencias de la Computación .
Contextualización de la movilidad de habitantes de zonas urbanasdesfavorecidas
Resumen aprobado por:
Dr. José Antonio García Macías
Director de tesis
Las áreas urbanas que son persistentemente pobres son un tema de gran preo-cupación para muchos países. Estas áreas existen aún en países donde se tiene unevidente crecimiento económico. Se considera que algunas de las posibles razones deesta alta concentración de pobreza puede deberse a factores geográficos. Estipulamosque dichos factores afectan la movilidad de las personas, por lo cual es importante en-tender como las personas se mueven en su entorno. Esta tesis busca contextualizarla movilidad de las personas. Para esta investigación se realizó un estudio contex-tual, una aplicación para capturar movilidad urbana mediante dispositivos portátiles,un sistema web para análisis y visualización, una prueba piloto y un estudio en la co-lonia Camino Verde de la ciudad Tijuana en Baja California, México. Como resultadode este trabajo se encontraron instancias en las que la movilidad urbana en zonasdesfavorecidas de personas que participaron en este estudio difería de la movilidadesperada. La base de conocimiento generada en este trabajo, así como las aplicacio-nes desarrolladas, pueden constituir la base para futuros estudios de mayor amplitudy profundidad.
Palabras clave: ICT4D, D4D, Movilidad Urbana, Sensado Participativo, En-torno Urbano desfavorecido, Rastreo de habitantes, Contextualización deMovilidad, Movilidad humana
iii
Abstract of the thesis presented by Alberto Gabriel Ramos Salvio as a partial require-ment to obtain the Master of Science degree in Master’s Degree in Computer Science.
Mobility contextualization of inhabitants of underdeveloped urban regions
Abstract approved by:
Dr. José Antonio García Macías
Thesis Director
Urban areas that are persistently poor are a subject of great concern for manycountries. These areas still exist in countries where there is evident economic growth.It is considered that some of the possible reasons for this high concentration of po-verty may be due to geographical factors. We stipulate that these factors affect themobility of people, so it is important to understand how people move in their envi-ronment. This thesis seeks to contextualize the mobility of people. For this research,a contextual study was carried out, an application to capture urban mobility throughportable devices, a web system for analysis and visualization, a pilot test and a studyin the Camino Verde neighborhood of Tijuana in Baja California, Mexico. As a result ofthis work, instances were found in which the urban mobility of disadvantaged urbanareas of people who participated in this study differed from the expected mobility. Theknowledge base generated in this work, as well as the applications developed, can bethe basis for future studies of greater breadth and depth.
Keywords: ICT4D, D4D, Urban Mobility, Participatory Sensing, DisadvantagedUrban Environment, Human Tracking, Mobility Contextualization, Human Mo-bility
iv
Dedicatoria
This thesis is dedicated to all those people who have invested a part of themselves
so that it could be completed. To my parents who have given up so much so that
I could be here. To my sibling Paulina, Cristina, Liliana, Alan, Danna (Fish) for their
support in all my endeavors. To my girlfriend for her love and understanding. To my
friends, classmates, family, and teachers who have always been there for me these
two years. It’s been the sum of all you’ve made a part of yourself that’s made this
possible.
v
Agradecimientos
I want to thank CONACYT for the scholarship that helped me do this investigation
and CICESE for the opportunity to do my Masters.
To my thesis director Dr. José Antonio García Macía for his help and support du-
ring this thesis project. It was your vision that allowed me to develop this work and I
wouldn’t have been able to do it without you.
To my committee members; Dra. Mónica Elizabeth Tentori Espinosa, Dr. Jaime Sán-
chez García, and M.C. Christian Paul García Martínez, I have learned a lot from you. I
admit that I made many many mistakes while writing this thesis. Far too many to count
so thank you for your patience.
To Karina Ortiz and Angelica Lomelí Contreras, for support in the administrative
area during the course of this work. I wouldn’t have been able to finish this endeavour
without your help.
To the community in Camino Verde that participated in this study and the members
of Torolab; Raul, Ana, Ale, Caro, Alma, Steph, and Miguel. Thank you for helping me
with the research. Sometimes it was daunting but you helped me get through it.
To my classmates Jose, Esteban, David, Gloria, Fushu, Rewer, Arturo, Ivonne, Karen,
Aurora, Lucely, Alita, and everyone else who was with me at CICESE for taking this
journey with me. You’ve helped make this chapter of my life better. And especially
thanks to Alita because you’ve helped me during some rough times that helped me
define myself. To my roommates and friends; Felipe, Laura, and Jessy thank you for
sharing your space with me, I’m sorry if I was ever too messy but I really appreciate all
you’ve done for me.
And to everyone who’s been with me through all this; Thank you because basi-
cally...
vi
vii
Tabla de contenido
Página
Resumen en español . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
Resumen en inglés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Dedicatoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
Agradecimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Lista de figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Lista de tablas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Capítulo 1. Introducción1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Propuesta e hipótesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4. Preguntas de investigación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5.1. Objetivos generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5.2. Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6. Contribución de la tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.7. Organización de la tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Capítulo 2. Marco teórico2.1. Antecedentes y trabajo relacionado . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1. Cómputo urbano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.2. Sensado Participativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.3. Sistemas de estimación de localización . . . . . . . . . . . . . . . . 92.1.4. Modelado de movilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1.5. Sistemas basados en localización . . . . . . . . . . . . . . . . . . . . 11
2.2. Conceptos de ciencias sociales . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.1. Áreas urbanas desfavorecidas . . . . . . . . . . . . . . . . . . . . . . 122.2.2. Bienestar subjetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.3. Pobreza experimentada . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.4. Pobreza de ingresos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.5. Pobreza multidimensional . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.6. Trampas de pobreza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Capítulo 3. Metodología3.1. Revisión de literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2. Selección de Tecnología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3. Estudio Contextual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4. Implementación y desarrollo del sistema . . . . . . . . . . . . . . . . . . . . 173.5. Diseño de Experimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
viii
Tabla de contenido (continuación)
3.5.2. Población . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.5.3. Duración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.5.4. Tipo de Estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.5.5. Evaluación de los datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6. Resumen y conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Capítulo 4. Sistema de rastreo y recolección de datos4.1. Aplicación de GeoLock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.1. Arquitectura de la aplicación GeoLock . . . . . . . . . . . . . . . . . 234.1.2. Settings Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.1.3. Lockscreen Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.1.4. MQTT Helper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.1.5. MQTT Utils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.1.6. Preference Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2. Consideraciones de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.3. Aspectos Técnicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.1. Rastreo de la Ubicación . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3.2. Captura y transferencia de datos . . . . . . . . . . . . . . . . . . . . 314.3.3. Energía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.3.4. Otras consideraciones técnicas . . . . . . . . . . . . . . . . . . . . . . 33
4.4. Aspectos Sociales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.4.1. Interacción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.4.2. Incentivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5. Implementación de la aplicación GeoLock . . . . . . . . . . . . . . . . . . . 354.5.1. Primeras versiones del sistema de rastreo . . . . . . . . . . . . . . 35
4.6. Resumen y conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Capítulo 5. Sistema de registro y visualización5.1. Plataforma de visualización . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.1. Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.1.2. Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2. API v1 para RaMoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.2.1. Acciones disponibles para el API . . . . . . . . . . . . . . . . . . . . . 45
5.3. Métodos de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.4. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.5. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.6. Tecnologías . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.6.1. Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.6.2. Fiware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.7. Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.7.1. PHP Web App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.7.2. Funciones de JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . 525.7.3. MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.7.4. RaMoS.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.7.5. OSRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
ix
Tabla de contenido (continuación)
5.7.6. Google Maps API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.8. Resumen y conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Capítulo 6. Diseño e implementación del estudio6.1. Prueba Piloto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.2. Diseño del estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596.3. Etapas del estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596.4. Reclutamiento y perfil de los participantes . . . . . . . . . . . . . . . . . . 59
6.4.1. Expectativa de privacidad . . . . . . . . . . . . . . . . . . . . . . . . . 606.4.2. Registro de participantes . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.5. Realización de campaña de sensado . . . . . . . . . . . . . . . . . . . . . . 65
Capítulo 7. Resultados y discusiones7.1. Estadísticas del uso del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 667.2. Casos encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.2.1. Participante 35 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677.2.2. Participante 36 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.3. Escenarios de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747.3.1. Escenario uno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747.3.2. Escenario dos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.4. Resumen y conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Capítulo 8. Conclusiones8.1. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808.2. Dificultades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808.3. Contribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818.4. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828.5. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828.6. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Literatura citada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Anexo 1: Protocolo de Entrevista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Anexo 2: Consentimiento para participar como sujeto de investigación . . . . 90
x
Lista de figuras
Figura Página
1. Marco de trabajo actual del cómputo urbano. . . . . . . . . . . . . . . . . . . . . 8
2. Cómo funciona la triangulación: Imagen comparativa. . . . . . . . . . . . . . . 10
3. Modelo propuesto de la metodología con la cual se llevó a cabo el desa-rrollo de este proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Modelo propuesto con base en los resultados de las entrevistas realizadascomo parte del estudio contextual . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5. Diseño simple de la arquitectura del sistema . . . . . . . . . . . . . . . . . . . . 19
6. Interfaz de usuario para la aplicacion GeoLock . . . . . . . . . . . . . . . . . . . 23
7. Arquitectura de la aplicación móvil GeoLock donde se muestran algunasde las clases y los servicios que fueron desarrollados para la aplicación. . 24
8. Pantalla con configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9. Pantalla de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
10. Captura de pantalla de la aplicación prototipo para el rastreo de partici-pantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
11. Portal de bienvenida para la plataforma de la visualización de datos . . . . 40
12. Pagina del dashboard con el listado de los participantes . . . . . . . . . . . . . 41
14. Lista de los archivos disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
13. Página para visualización de los datos . . . . . . . . . . . . . . . . . . . . . . . . 42
15. Lista de los archivos disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
16. Lista de los puntos de interés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
17. Paneles de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
18. Arquitectura del servidor RaMoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
19. Visualización de la pila de una máquina virtual en comparación con uncontenedor de Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
20. Pantalla de la aplicación Ramos.py corriendo en el servidor. . . . . . . . . . . 54
22. Ejemplo del diccionario de ubicaciones decodificado por la librería polylinedecoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
21. Respuesta ejemplo del API de ruteo de Google Maps . . . . . . . . . . . . . . . 56
23. Imagen de junta con los residentes que participarían en la campaña desensado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
24. Firma de los acuerdos de consentimiento para participar en el estudiocomo sujeto de investigación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
25. Dispositivo en el día de entrega . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
xi
Lista de figuras (continuación)
Figura Página
26. Visualización de rutas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
27. Comparación de rutas en metros para el participante 35 durante el día 14de agosto del 2018 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
28. Comparación de divergencias en las rutas para el participante 35 duranteel día 14 de agosto del 2018 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
29. Cantidad de desviaciones acumuladas por día para el participante 35 . . . 71
30. Error en el modelo de Google Maps para trayectoria peatonal . . . . . . . . . 71
31. Comparación entre ruta real y ruta esperada . . . . . . . . . . . . . . . . . . . . 72
32. Comparación entre ruta real y ruta esperada para el participante 36 du-rante el día 8/15/2018 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
33. Imagen del área de la ruta del participante 36 durante el día 8/15/2018donde la ruta verde es la ruta sugerida por Google Maps y la ruta Azul esla ruta real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
34. Prototipo de alta fidelidad para el brazalete de seguridad . . . . . . . . . . . . 76
35. Computadora para la recolección de los datos . . . . . . . . . . . . . . . . . . . 77
36. Simulacion de capa de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
xii
Lista de tablas
Tabla Página
1. Recursos disponibles en el API REST de la plataforma RaMoS . . . . . . 47
2. Características de participantes del estudio piloto . . . . . . . . . . . . . 58
3. Tabla de participantes del estudio *NOTA: Estos datos se obtendranproximamente* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
1
Capítulo 1. Introducción
En este capítulo se presenta la introducción al tema de tesis “Contextualización de
Movilidad de Habitantes de Zonas Urbanas Desfavorecidas”. Se menciona la motiva-
ción que se tuvo para el desarrollo de esta investigación. Al mismo tiempo se describe
el planteamiento del problema, así como las preguntas de investigación y objetivos.
Con el fin de dar al lector una idea general de la problemática y la investigación que
se llevó a cabo sobre ella.
1.1. Motivación
Las áreas urbanas que son persistentemente pobres como las que se definen en
la sección 2.2.1 son un tema de gran preocupación para muchos países. Aún en paí-
ses donde existe un evidente crecimiento económico existen áreas persistentemente
pobres (Jalan y Ravallion, 2002). Se considera que algunas de las posibles razones de
esta alta concentración de pobreza puede deberse a factores geográficos. La geografía
es un elemento importante que determina a que grado se puede desarrollar un hogar.
Es decir, factores externos como el acceso dentro de el entorno a trabajos, a servicios
públicos y a una mejor infraestructura urbana; que ayudan a determinar la posibilidad
de escapar de la pobreza. Por ejemplo, un hogar pobre que se situa en un área con
buen acceso a infraestructura puede eventualmente escapar de la pobreza mientras
que otro hogar completamente idéntico situado en un área con menor acceso a estos
servicios tiene menos posibilidades de mejorar su situación.
El tener datos duros, es decir datos verificables, que no son anecdóticos, resultados
de estudios con metodologías claras y reproducibles de la movilidad humana en las
zonas urbanas desfavorecidas, así como de su geografía particular, pueden ayudar
significativamente a la generación de soluciones para la mejora del bienestar subjetivo
de las personas que viven en estas regiones. El bienestar subjetivo es la métrica de
que tan bien las personas auto-perciben su vida. Es importante poder visualizar las
necesidades de una región geográfica para un mejor entendimiento de la problemática
y posibles soluciones de ésta.
2
1.2. Planteamiento del problema
De las más de 3.3 mil millones de personas que componen la población urbana
global, alrededor de un setenta por ciento viven en entornos pobres en recursos urba-
nos (United Nations, 2012). Estos son entornos con bajo desarrollo de infraestructura.
Comúnmente pueden tener una infraestructura vial deficiente como por ejemplo falta
de banquetas, calles y pasos peatonales.
Es importante entender la manera en la que se mueven las personas dentro de
su entorno porque puede ser un indicador de otros datos importantes, como falta de
infraestructura vial o zonas de baja seguridad para peatones. Por ejemplo puede ser
una métrica de su bienestar y actualmente ya existen estudios que buscan entender
la movilidad humana pero una porción considerable de ellos se han llevado a cabo en
entornos de ciudades con infraestructura adecuada.
Por lo cual mayor parte de nuestra comprensión de la movilidad humana y el com-
portamiento espacial dentro de las ciudades se basa en la investigación que se realiza
en países desarrollados (Keeling, 2009). Si consideramos que las decisiones que las
personas toman con respecto a su movilidad urbana se ven afectadas por razones de
infraestructura y factores geográficos, se refuerza la idea de que puede existir una
diferencia entre la movilidad de las personas en ciudades desarrolladas y no desarro-
lladas (Noulas et al., 2012). Ciertas metodologías que se han usado en estudios para
entender la movilidad urbana como el que hizo Lathia et al. (2012) donde usó la tar-
jeta para transporte público para obtener información, se vuelve imposible replicar en
entornos donde no hay forma de monitorear el uso del transporte público urbano.
Por lo que esto representa una limitación en la reproducción de estos estudios en
países de baja infraestructura, debido a la amplia diferencia de circunstancias. Las
ciudades desarrolladas son ciudades que no se ven afectadas por ciertos problemas
geográficos que podemos observar en entornos desfavorecidos.
Lo mencionado anteriormente significa que las conclusiones obtenidas de los estu-
dios que fueron llevados a cabo en las regiones que cuentan con mejor infraestructura
y no tienen los mismos problemas geográficos que las regiones desfavorecidas no
necesariamente se pueden aplicar en las regiones de bajo desarrollo.
3
1.3. Propuesta e hipótesis
El trabajo que se desarrolló en esta tesis consiste en el diseño e implementación
de una plataforma que permita dar contextualización a la movilidad en áreas urbanas
desfavorecidas. De tal manera que se ayude a entender como afecta el contexto a la
toma de decisiones de movilidad dentro de la ciudad en regiones urbanas con menor
infraestructura. Esto con la finalidad de comprobar la hipótesis de que factores geo-
gráficos externos afectan la toma de decisiones de las personas en entornos urbanos
de favorecidos.
1.4. Preguntas de investigación
Con base en la problemática que ha sido expuesta y con la hipótesis de que tener
una captura de las trayectorias que toman las personas diariamente entre diferentes
puntos en los entornos urbanos, puede ayudar a entender la movilidad humana, se
proponen las siguientes preguntas de investigación.
¿Existen factores del entorno físico que afectan las decisiones y posibilidades de
movilidad en entornos urbanos desfavorecidos?
¿Existe una relación entre la distancia recorrida y la cantidad de divergencias1
en el trayecto de una persona de un punto A a un punto B en un entorno urbano
desfavorecido?
¿Se pueden usar técnicas de sensado participativo2 para hacer recolección de
datos en un entorno urbano desfavorecido?
1.5. Objetivos
En esta sección se expone el objetivo general de este proyecto de tesis en conjunto
con los objetivos específicos con base en los cuales se llevó a cabo la tesis.
1Las divergencias son desviaciones en la trayectoria real respecto a la trayectoria esperada.2El sensado participativo se describe en la sección 2.1.2
4
1.5.1. Objetivos generales
El objetivo general de la tesis es desarrollar una plataforma para sensado parti-
cipativo que permita obtener los datos sobre la movilidad de las personas en zonas
desfavorecidas de tal manera que se puedan usar para elaborar un análisis contextual
sobre las diferencias encontradas entre las rutas esperadas y las rutas reales recorri-
das por los usuarios.
1.5.2. Objetivos específicos
Diseñar un sistema que permita colectar trayectorias sobre la movilidad cotidiana
de los participantes por medio de sensado participativo.
Diseñar un sistema por medio del cual se puedan obtener puntos de interés en
las rutas recorridas por los usuarios del primer sistema.De igual manera este
sistema debe permitir generar rutas esperadas en base a los puntos de interés.
De tal manera que se puedan usar para la visualización y análisis con la finalidad
de que por medio de comparación se obtenga las posiciones de las divergencias
en las rutas.
Realizar una prueba de campo en un entorno urbano desfavorecido.
1.6. Contribución de la tesis
Como parte de este trabajo se desarrolló una conjunto de métodos para seguir con
la finalidad de recolectar datos de movilidad en zonas urbanas desfavorecidas. Como
resultado de la metodología se obtuvieron los siguientes productos: una aplicación
móvil para la captura de los datos de geolocalización de los participantes del estudio
que son residentes de una zona urbana desfavorecida; Una plataforma web donde se
pueda monitorear los datos recibidos de los participantes del estudio (ver capítulo 5); y
generar evidencia empírica sobre las diferencias entre la movilidad real y la movilidad
que se esperaría entre diferentes puntos de la trayectoria. La aplicación móvil que
no requiere estar conectada todo el tiempo al Internet; de esta manera se facilita el
despliegue de la campaña de sensado en zonas urbanas desfavorecidas.
5
Este estudio se realizó en la colonia Camino Verde de la ciudad de Tijuana en Baja
California, México durante las ultimas dos semanas de agosto y los datos obtenidos se
aportan para estudios futuros. Consideramos que camino verde es un buen ejemplo de
las zonas urbanas desfavorecidas por que es una colonia en Tijuana con baja infraes-
tructura vial y con grandes problemas de seguridad, de tal manera que (Dibble et al.,
2017) llamo a Camino Verde un lugar como muy pocos parques y muy poca policía
pero demasiadas armas, drogas y una profunda necesidad social.
1.7. Organización de la tesis
Este trabajo de tesis contiene ocho capítulos. A continuación se hace un resumen de
estos capítulos. En el capítulo 2 se presenta el marco teórico y el trabajo relacionado.
Este capítulo introduce al lector a conceptos de computo móvil y ubicuo necesarios
para la comprensión de la problemática y la solución implementada. Conceptos como
el censado centrado en las personas y la estimación de localización.
El capítulo 3 se enfoca en presentar la metodología llevada a cabo para la reali-
zación de este trabajo de tesis. Presenta los diferentes pasos que fueron llevados a
cabo para el desarrollo del trabajo. Al igual que da detalles de la fase analítica para la
validación y comprobación del sistema y los datos capturados.
En el capítulo 4 se describe detalladamente el desarrollo de la aplicación Android
RMHZUD dedicada a la recolección de datos de localización de los usuarios.
En el capítulo 5 se describe el desarrollo del sistema web por medio del cual se pue-
den visualizar los datos que fueron obtenidos. También se describen los programas que
se desarrollaron para comunicar los diferentes módulos del sistema web. Incluyendo
los pasos que se llevaron a cabo para hacer la integración del sistema con Fiware;
una plataforma de la Unión Europea para el desarrollo de sistemas del Internet de las
cosas.
En el capítulo 6 se describe el desarrollo de la campaña de sensado participativo
que se elaboró en Tijuana. Se describen los pasos que se siguieron para elaborar la
campaña y obtener los datos.
6
En el capítulo 7 se mencionan los resultados obtenidos por parte del análisis reali-
zado con los datos recolectados durante la campaña.
Finalmente, en el capítulo 8 se presentan las conclusiones obtenidas y las aporta-
ciones al estado del arte, así mismo se mencionan las limitaciones y trabajo futuro de
esta investigación.
7
Capítulo 2. Marco teórico
En la primera parte de este capítulo se presentan conceptos importantes de las
ciencias de la computación para el desarrollo de la tesis. Conceptos como el sensado
centrado en personas y temas de estimación de la localización. En la segunda par-
te de este capítulo el enfoque cambia a temas que están fuera de la ciencias de la
computación. Estos temas son mas relacionados con la economía y psicología.
2.1. Antecedentes y trabajo relacionado
Este trabajo de tesis se basa en el rastreo de la movilidad de personas que viven en
áreas desfavorecidas, es decir, áreas que tienen un bajo desarrollo de infraestructura
y que son poco ideales para el desarrollo de la persona. Consideramos que existe una
relación entre los factores geográficos que existen en las áreas urbanas desfavorecidas
y las decisiones sobre movilidad que tomas las personas que viven en estas áreas. De
igual manera postulamos que estas decisiones tiene una relación con el bienestar
subjetivo de las mismas personas. La motivación para el presente estudio es entender
cómo se relacionan la movilidad urbana de las personas en áreas desfavorecidas y
su bienestar subjetivo del cual podemos leer mas en la sección 2.2.2. El bienestar
subjetivo y el estudio de su relación con las ciencias de la computación es un tema
relativamente nuevo.
Para llevar a cabo este trabajo se investigaron las aportaciones del bienestar sub-
jetivo en campos del cómputo urbano y de salud. Además, también se tomaron en
cuenta conceptos de la estimación de ubicación, modelado de actividad, sistemas ba-
sados en la ubicación y temas como sociología y psicología.
2.1.1. Cómputo urbano
La urbanización ha provisto un avance rápido en la calidad de vida de muchas
personas. Sin embargo, genera muchos problemas como son una alta densidad de
población, congestión de tráfico, una alza en crimen, mala infraestructura y según
8
Li et al. (2012) un uso de recursos ineficiente. El cómputo urbano es un área de la
computación que busca integrar elementos tecnológicos a poblaciones urbanas, para
que éstas se beneficien de la tecnología (Zheng et al., 2014), por lo cual los sistemas
desarrollados como parte de la tesis caen dentro de lo que es el computo urbano.
En su artículo “Urban Computing: Concepts, Methodologies, and Applications”, (Zheng
et al., 2014) da una buena introducción a los conceptos de cómputo urbano. Habla del
marco de trabajo actual del cómputo urbano el cual se compone de cuatro capas que
podemos ver en la gráfica 1, las cuales son sensado urbano, gestión de datos urbanos,
análisis de datos y prestación de servicios.
(a)
Figura 1. Marco de trabajo actual del cómputo urbano.
En otras palabras el cómputo urbano busca conectar el sensado urbano con ad-
ministración de los datos que fueron obtenidos de estos sensores para llevar a cabo
un análisis de los datos y poder crear una prestación de servicios en un proceso que
sea recurrente para una mejora continua y no intrusiva de la vida de las personas, los
9
sistemas de operación de la ciudad y el medio ambiente.
2.1.2. Sensado Participativo
Sensado participativo va mas allá de solo la recolección de datos. Para (Burke et al.,
2006) el sensado participativo se puede definir como "Grassroots Sensing" lo cual po-
demos traducir como sensado de base. Esto es por que las comunidades que tienen
conocimiento de primera mano del problema y cuya preocupación principal no es ne-
cesariamente la tecnología que les permite llevar acabo la captura de los datos son
los que deberían ejecutar estas campañas. Por lo cual en el sensado participativo se
busca hacer uso de dispositivos como celulares y otros dispositivos del internet de las
cosas para formar redes de sensores que permitan a usuarios capturar y compartir
conocimiento local.
Las personas que viven en los entornos que buscamos entender tal y como es
Camino Verde, tienen un conocimiento intimo de los problemas que existen en su co-
munidad como por ejemplo los problemas que limitan su movilidad. Esto les habilita a
responder a estos factores geográficos durante sus trayectorias diarias de una manera
que es valiosa para la investigación.
2.1.3. Sistemas de estimación de localización
En el articulo “Location Systems for Ubiquitous Computing” (Hightower y Borrie-
llo, 2001) definen como sistemas de estimación de localización aquellas tecnologías
y sistemas que automáticamente ubican personas, equipo y otros objetos tangibles.
Después de esto afirma que para poder crear buenos sistemas de cómputo móvil es
necesario entender de manera correcta el contexto de la ubicación. Razón por la cuál,
la estimación de ubicación se ha convertido en un importante tema del cómputo ubi-
cuo.
Dentro del artículo “GSM Indoor Localization” el autor (Varshavsky et al., 2007) co-
menta como existen y se han estudiado varios medios de ubicación en interiores y a
la vez presenta un sistema basado en la huella digital de GSM.
10
Algunos sistemas para la estimación de ubicación son los basados en beacons y
triangulación. Los sistemas basados en ubicación por beacon son muy sencillos. Ellos
buscan generar un punto de ubicación cuando el dispositivo está dentro de un rango
predeterminado de una estación base de la cual su ubicación ya es conocida. Mientras
tanto la estimación de ubicación con base en la triangulación usa un mínimo de tres es-
taciones base y en la intersección de las señales es donde se encuentra el dispositivo
esto lo podemos ver gráficamente en la imagen 2. Normalmente este tipo de gene-
ración de ubicación resulta ser muy costoso. Pero con el desarrollo de la red satelital
GPS se ha vuelto mucho mas accesible aunque solo funciona bien para la localización
en los exteriores.
(a)
Figura 2. Cómo funciona la triangulación: Imagen comparativa.
En la actualidad, gracias al desarrollo de los dispositivos móviles, obtener datos de
la estimación de ubicación de algún individuo se ha vuelto mucho mas sencillo puesto
que los dispositivos ya cuentan con los sensores necesarios para obtener la ubicación.
Incluso algunos de los dispositivos móviles mas básicos tienen integrado un sistema
GPS el cual por medio de una triangulación satélital, con un mínimo de tres satélites
puede encontrar la ubicación de un dispositivo. En caso de no poder conectarse a
los satélites el dispositivo puede intentar por medio de una interpolación de antenas
celulares o una generación de posición por Internet.
11
2.1.4. Modelado de movilidad
Según Calabrese et al. (2013), existe poco entendimiento de los patrones de movi-
miento humanos. El poder entender estos patrones es útil en muchos ámbitos desde la
predicción de tráfico hasta la planificación urbana. Estudios que se realizaron previa-
mente han mostrado que la movilidad humana se puede representar con un modelo
Levy-Walk por medio del rastreo de notas bancarias i.e. billetes (Brockmann et al.,
2006). En este trabajo, se observó que cada vez que un billete cambiaba de manos el
billete reflejaba la movilidad compuesta de dos personas. Desafortunadamente este
modelo no era suficientemente bueno puesto que un billete componía la movilidad de
múltiples participantes, por eso el autor llevó a cabo un modelado del movimiento de
las personas basado en los datos de celulares. Este modelo resultó ser mucho mejor,
puesto que, al contrario de los billetes, un celular siempre es cargado por el mismo
individuo.
La información de la movilidad humana permitirá realizar mejoras en la planifica-
ción para eventos de desastres naturales. Actualmente, los datos de movilidad huma-
na más completos son de urbes desarrolladas, y como se mencionó en la introducción
1.1, no aplican a ciudades en desarrollo y a zonas urbanas desfavorecidas.
2.1.5. Sistemas basados en localización
Los sistemas basados en ubicación son aquellos sistemas que utilizan la ubicación
de la persona, objeto u dispositivo para la generación de servicios a nivel de software.
Un ejemplo de uno de estos sistemas es el elaborado por Zheng et al. (2012) para
la generación de recomendaciones colaborativas; en su trabajo también se evalúo un
sistema basado en localización que esta compuesto por tres distintos algoritmos, con
los datos reales de GPS de 119 usuarios. El primer algoritmo propuesto se encarga
de juntar los datos de todos los usuarios para mitigar los huecos en la información.
El segundo algoritmo se encarga de proponer posibles ubicaciones de interés a cada
usuario usando una factorización de matriz y tensor. El tensor que usa es basado en el
modelado de los usuarios y la localización de actividades. Finalmente, el tercer algorit-
mo toma el problema de un punto de vista de donde considera la falta de datos como
12
un problema de ranking. De esta manera permite minimizar la cantidad de perdidas
basadas en los rankings y permite entregar mejores recomendaciones.
2.2. Conceptos de ciencias sociales
Este trabajo de tesis es un trabajo multidisciplinario en el que se busca usar herra-
mientas de la ciencias de la computación para entender el fenómeno de la movilidad
urbana. Es por esta razón que se vuelve importante entender conceptos de las ciencias
sociales.
2.2.1. Áreas urbanas desfavorecidas
Las áreas urbanas desfavorecidas son zonas urbanas que carecen la infraestructura
básica urbana. Esto puede ser por ejemplo alumbrado público, banquetas, calles pavi-
mentadas. La hypotesis que motiva este trabajo es que la falta de esta infraestructura
puede resultar perjudicial para las personas que viven dentro de estas regiones.
2.2.2. Bienestar subjetivo
Gran parte de la investigación que es llevada a cabo en las ciencias sociales se rela-
ciona con la conceptualización, la medición, la dinámica de cambio y el entendimiento
del nivel del bienestar (Juster et al., 1981) o la auto percepción de la felicidad de las
personasDiener et al. (2002).
Las ciencias sociales pueden ayudar a definir que significa tener una buena vida, y
a la vez demostrar que acciones conllevan al bienestar. Pero existe poco conocimiento
sobre qué es lo que hace que una vida valga la pena (Seligman y Csikszentmihalyi,
2000).
13
2.2.3. Pobreza experimentada
La pobreza experimentada es la baja satisfacción con la calidad de vida. Y esta va
más allá de la pobreza económica experimentada (o la baja satisfacción económica)
(Kakwani et al., 2008). Las políticas que ayudan a tratar con la pobreza de ingresos
2.2.4 y la pobreza económica no necesariamente reducen la pobreza experimentada
(Rojas, 2008).
En otras palabras, la cantidad de satisfacción que las personas perciben sobre su
vida está directamente relacionada a la pobreza que ellos experimentan. Hay políticas
que pueden ser implementadas por los gobiernos que reducen la pobreza de ingresos
pero que tienen efectos negativos en la pobreza experimentada (Rojas, 2008)
2.2.4. Pobreza de ingresos
La definición de la pobreza de ingresos es lo que tradicionalmente nos viene a la
mente cuando se piensa en pobreza. Cuando consideramos a un individuo podemos
medir su relación a la línea de la pobreza basado en la cantidad de recursos que el
individuo tiene disponibles. Es decir, una persona está en pobreza de ingresos cuando
los ingresos de ésta, están bajo una determinada línea (Goedhart et al., 1977).
2.2.5. Pobreza multidimensional
Por mucho tiempo, la pobreza era vista como el resultado de bajo crecimiento eco-
nómico y hasta cierto punto culpa del individuo (Suich, 2012). Pero en décadas recien-
tes el concepto de lo que es la pobreza ha crecido para incluir conceptos que no son
meramente económicos. El estudio de lo que es la pobreza multidimensional ha cap-
turado la atención de investigadores y legisladores (Alkire y Foster, 2011). El gobierno
en México ha estado en la vanguardia de la medición de la pobreza (Thorbecke, 2011).
Según Lever (2004) la pobreza está compuesta por muchas dimensiones, entre ellas
(Suich, 2012):
14
Las necesidades materiales básicas – Estas necesidades están compuestas por
ingresos, bienes, comida y un hogar.
Salud – Esta categoría incluye servicios básicos hasta el poder sentirse bien y
fuerte.
Buena relación social – Esto es la presencia de la cohesión social.
Seguridad – Seguridad personal y de posesiones, el acceso seguro a recursos
Libertad de elección - Es la habilidad de tener control sobre la vida de uno mismo.
El poder elegir qué le pasa a uno y hacer las cosas que agregan valor a la vida.
2.2.6. Trampas de pobreza
Las trampas de pobreza son un concepto donde muchos de los comportamien-
tos y de las políticas que normalmente se ven asociados con la pobreza son auto-
perpetuados por lo cual no se pueden resolver desde adentro (Rodríguez y Shelton,
2013). Es decir que una persona que es pobre, no necesariamente es pobre a causa
de sus fallas y errores, sino puede ser pobre a causa de las circunstancias que están
más allá de su control.
2.3. Resumen
En este capítulo se discutieron diferentes temas, de computación y de otras áreas
tales como psicología, economía y estudios sociales. Dentro de la ciencias de la compu-
tación se habló de temas como cómputo urbano, sistemas de estimación de localiza-
ción, modelado de movilidad y otros. La introducción a estos temas permite al lector
entender la relación entre la movilidad y la computación. De igual manera se presenta-
ron temas que están fuera del área de ciencias de la computación. Estos temas ayudan
a los lectores que provienen de áreas mas técnicas entender la motivación social para
el estudio.Entender estos temas permite describir mejor la metodología que se usó
para el desarrollo del sistema de captura y análisis de la movilidad, el cual es descrito
en el capítulo 3
15
Capítulo 3. Metodología
En este capitulo se presenta la metodología que se usó para el desarrollo de este
proyecto de tesis. Podemos visualizar la metodología en la figura 3. Cada uno de los
pasos de la metodología se presentan en las siguientes secciones.
(a)
Figura 3. Modelo propuesto de la metodología con la cual se llevó a cabo el desarrollo de este proyecto.
3.1. Revisión de literatura
El primer paso de la metodología que se llevó en el estudio fue el de la revisión de
literatura. La cual se hizo desde dos enfoques: el social y el del rastreo de la movilidad
humana por medios tecnológicos.
Con la búsqueda de trabajos con enfoque social se buscaron trabajos de investi-
gación sobre como la pobreza multidimensional afecta a la movilidad. Esto con la fi-
nalidad de establecer la conexión entre la movilidad en zonas urbanas desfavorecidas
y la pobreza multidimensional. A pesar de que no se encontraron estudios que direc-
tamente relacionaran la movilidad con la pobreza. Si se encontraron estudios donde
hablaba de la relación de la crecimiento económico de individuos con la presencia de
infraestructura como por ejemplo en el articulo "Geographic poverty traps? A micro
16
model of consumption growth in rural China"de (Jalan y Ravallion, 2002) donde se ex-
plora la idea de que tan importantes son los recursos físicos y de capital humano en
una economía en desarrollo. Los recursos físicos pueden ser acceso a agua, escuelas,
o incluso cosas tan simples como banquetas. Si consideramos que estos recursos o la
falta de ellos afecta la toma de decisiones de residentes de estas áreas desfavorecidas,
encontramos un enlace entre la movilidad y la pobreza.
Mientras tanto la búsqueda que llevamos a cabo con el enfoque de movilidad hu-
mana nos mostró varios estudios como (Calabrese et al., 2013) y (Fan et al., 2016)
que se habían desarrollado para entender la movilidad de las personas. Estos estudios
eran para entender el esparcimiento de virus, para ver como mejorar las rutas de eva-
cuación en caso de desastres naturales. Sin embargo todos estos estudios se llevaron
a cabo en ciudades que cuentan con una infraestructura muy diferente a la que vemos
en zonas urbanas desfavorecidas.
3.2. Selección de Tecnología
En conjunto con Ubilogix se llevó a cabo un proceso de selección de tecnología.
Ellos son una empresa que se dedica a desarrollo de software e ingeniería de redes en
la ciudad de Ensenada. En este proceso de selección de tecnología se llevaron a cabo
varias juntas donde se discutieron diferentes posibilidades para lo que seria nuestro
dispositivo de rastreo. El dispositivo de rastreo es el dispositivo por medio del cual
llevaríamos la captura de los datos de movilidad de cada participante. En el capítulo
4 se detallan algunas de las diferentes consideraciones de aspectos técnicos (4.3); de
igual manera las consideraciones sociales (4.4) que se tomaron para el proceso de la
selección de tecnología del sistema de rastreo.
3.3. Estudio Contextual
Como parte del estudio contextual se elaboraron dos entrevistas a residentes de
la colonia Camino Verde en la ciudad de Tijuana Baja California, México. Se pueden
consultar las preguntas que se hicieron como parte de estas entrevistas en el Anexo
1. El propósito de este estudio fue determinar, por medio de la información obtenida
17
en las entrevistas, como la movilidad afecta el bienestar de las personas. En particular
nos interesaba entender como los medios de transporte público podían afectar a las
personas en diferentes aspectos de su vida, como son su economía, su salud y su
tiempo.
Las entrevistas se hicieron a dos residentes de la colonia. Ambas comentaron sobre
dificultades que pasan a causa del transporte. Según las respuestas de algunas de
las preguntas que se hicieron a los participantes de la entrevista; el obtener un mejor
transporte es decir un transporte privado propio podría ayudar a aliviar muchos de
los problemas que ellos perciben en su movilidad urbana diaria. Desafortunadamente
para muchas de las personas que viven en el tercer nivel de desarrollo el obtener un
mejor transporte es algo que es casi imposible.
Por medio de la codificación axial (que es la descomposición de los temas centrales
durante el análisis de datos cualitativos), tomamos los conceptos base que se obtuvie-
ron en las entrevistas y elaboramos un modelo conceptual (ver figura 4). Con base en
este modelo podemos observar que las personas que viven en estas regiones desfavo-
recidas pasan dificultades a causa de la falta de regulación que existe en los servicios
de transporte público lo cual resulta en una mala calidad de servicio. De igual manera
pasan dificultades a causa de la inseguridad que existe y de las grandes distancias
que tienen que recorrer y podemos ver como todo esto impacta en su economía, salud
y finalmente en su bienestar subjetivo.
Con las observaciones en estas entrevistas se obtuvo un contexto de las dificulta-
des que pasan las personas en condición de pobreza, particularmente en cuánto a la
movilidad urbana.
3.4. Implementación y desarrollo del sistema
La implementación y el desarrollo del sistema de rastreo se llevó a cabo por un
periodo de alrededor de ocho meses. El sistema se compone de dos sub-sistemas.
El primero es una aplicación para teléfonos celulares que funcionan con el sistema
operativo Android. Esta aplicación se encarga de recolectar los datos de la ubicación
de las personas en un periodo predeterminado. En el capítulo 4 se explica a detalle
18
(a)
Figura 4. Modelo propuesto con base en los resultados de las entrevistas realizadas como parte delestudio contextual
el desarrollo de ésta aplicación. En la figura 5 podemos visualizar una arquitectura
simplificada para el sistema en completo. Sin embargo, a pesar de que es un solo
sistema la presentación del sistema se divide en dos capítulos. En el capitulo 4 se
presenta la aplicación móvil, mientras que en el capitulo 5 se presenta el sistema de
registro y visualización.
El otro subsistema es una aplicación web desarrollada en PHP. Esta aplicación corre
en un servidor y su objetivo es controlar los dispositivos de rastreo y hacer junto con
estos dispositivos actividades de registro, obtención de los datos y la visualización de
los datos. El desarrollo de la aplicación web se describe en el capítulo 5.
19
(a)
Figura 5. Diseño simple de la arquitectura del sistema
3.5. Diseño de Experimento
3.5.1. Variables
Los dos tipos de variables principales que existen en un experimento son las va-
riables independientes y las variables dependientes. Una variable independiente es la
condición que se cambia o se controla en un experimento científico para probar los
efectos sobre la variable dependiente. Una variable dependiente es la condición que
se prueba y mide en un experimento científico.
Variables Independientes
Puntos de Inicio - Es el punto desde el cual una persona inicia el trascurso de la
ruta.
Punto Final - Es el punto en el cual una persona termina el trascurso de la ruta.
Ruta esperada entre puntos de interés - Esta es la ruta que uno esperaría que una
persona que no conoce la región recorrería entre el punto A y punto B.
Variable Dependiente
20
Desviación acumulada en metros - Esta es la cantidad de metros que se desvió el
participante de la ruta esperada.
Núero de Desviaciones - Esta es la cantidad de veces que se desvió el participan-
te.
3.5.2. Población
La población para el estudio está compuesta por residentes de la Colonia Camino
Verde de Tijuana. Son padres de familia y jóvenes que participan en diferentes progra-
mas en conjunto con La Granja Transfronteriza; un centro de investigación compuesto
por un colectivo de artistas, arquitectos, científicos e ingenieros que está localizado en
la colonia Camino Verde.
La Granja Transfronteriza se encargó del reclutamiento de los participantes para
el estudio. En total catorce personas de la colonia Camino Verde participaron en el
estudio de las cuales ocho son hombres y seis son mujeres. En particular el principal
requisito para ser partícipe del estudio es que la personas no contaran con transporte
privado propio. Por lo cual facilitaría la captura de datos de movilidad urbana peato-
nal. Sin embargo no se puso como criterio de exclusión el que los participantes usaran
transporte motorizado público pues sabemos que es el transporte principal para mu-
chos de los residentes de la colonia.
3.5.3. Duración
El estudio se llevó a cabo durante un periodo de treinta días. En los cuales se captu-
ró el movimiento urbano de los participantes del experimento cada vez que visitaban
el centro de La Granja Transfronteriza. De los treinta días que se capturaron para el
análisis únicamente se usaron quince días de datos por razones de tiempo para la
escritura de este documento.
21
3.5.4. Tipo de Estudio
El tipo de estudio será intra-sujetos Charness et al. (2012) para poder comparar las
rutas del mismo sujeto.
Un experimento intra-sujetos es aquel en el que todos los participantes experi-
mentan las diferentes condiciones. Por ejemplo en un experimento médico; todos los
participantes se tratan con todos los medicamentos (Seltman, 2012). Por ejemplo en
este caso cada participante del estudio recorrerá las diferentes rutas. Uno de los gran-
des beneficios de este tipo de experimento es que no requiere un gran cantidad de
participantes.
Un experimento que usa el diseño de intra-sujetos también puede ayudar a reducir
los errores asociados con las diferencias individuales. En un diseño intra-sujetos, los
individuos están expuestos a todos los niveles de un tratamiento, por lo que las dife-
rencias individuales no distorsionarán los resultados. Cada participante sirve como su
propia línea de base.
3.5.5. Evaluación de los datos
De las personas que participaron en la campaña de movilidad que se llevó a cabo
en la colonia Camino Verde se seleccionaron a dos participantes sobre los cuales se
llevó a cabo un análisis de los datos capturados. Los datos se analizaron con méto-
dos de estudio cualitativos. Donde se compararon las distancias recorridas de cada
participante con la distancia esperada entre el punto inicial y punto final de cada ruta.
3.6. Resumen y conclusiones
En este capítulo se presentó la metodología se usó para el desarrollo del sistema
y las aplicaciones. Cada una de las secciones presenta una parte de la metodología.
En los siguientes capítulos se describe el desarrollo que se llevó para la aplicación de
Android y para la plataforma web.
22
Capítulo 4. Sistema de rastreo y recolección de datos
En este capítulo se presenta el procedimiento que se llevó para el diseño de la
aplicación. El propósito de la aplicación es capturar los datos de la movilidad de parti-
cipantes en campañas de sensado participativo particularmente enfocado en aquellas
que toman lugar en entornos urbanos desfavorecidos.
En este capítulo se describen los requerimientos y implicaciones de diseño que se
descubrieron por medio de las sesiones de selección de tecnología que se llevaron a
cabo en Ubilogix. Al igual que se menciona la aplicación prototipo como prueba de
concepto que se desarrolló. Por último se presenta la aplicación que se desarrolló y las
conclusiones al final del capítulo.
4.1. Aplicación de GeoLock
En esta sección discutiremos los diferentes aspectos de la aplicación de Android
que se desarrolló para el rastreo de la movilidad en los entornos urbanos. Primero
en la subsección Arquitectura de la aplicación GeoLock, mostramos un diagrama de
arquitectura similar a los diagramas de UML.
Posteriormente se discuten los diferentes nodos de la aplicación para poder explicar
cómo se comunican unos con los otros y el flujo de la información, con el propósito de
poder dar al lector un mejor conocimiento de cómo funciona interiormente la aplica-
ción. De esta manera alguien que lea este documento pueda más fácilmente entender
el código fuente de la aplicación.
23
(a)
Figura 6. Interfaz de usuario para la aplicacion GeoLock
4.1.1. Arquitectura de la aplicación GeoLock
En la Figura 7 podemos ver que la aplicación GeoLock está compuesta por diez
nodos principales. Cada uno de estos tiene funciones específicas por medio de las que
podemos dar uso al dispositivo para capturar la movilidad de los participantes de la
campaña.
En los siguientes párrafos hablaremos de cada uno de los nodos y sus propósitos. A
pesar de que hay más nodos, los propósitos son mínimos y en ocasiones únicamente
sirven como extensiones de un nodo más grande. La aplicación está compuesta por el
punto de entrada que se llama Settings Activity. Aparte de estas, también existe una
actividad que se llama Lockscreen Activity. La aplicación también tiene los servicios
MQTT Helper, Lockscreen Service y Lockscreen Intent Receiver. Finalmente la aplica-
ción también usa las clases GPS Tracker, GPS Utils, MQTT Utils y Preference Singleton.
Dentro de esta sección hablamos de cada uno de estos nodos y sus propósitos.
24
Fig
ura
7.
Arq
uit
ect
ura
de
laaplic
aci
ón
móvil
GeoLo
ckdonde
sem
uest
ran
alg
unas
de
las
clase
sy
los
serv
icio
sque
fuero
ndesa
rrolla
dos
para
laaplic
aci
ón.
25
4.1.2. Settings Activity
Este componente es el punto de entrada para la aplicación GeoLock. En esta vista
de la aplicación la persona que ejecuta la campaña puede ajustar ciertos aspectos de
las configuraciones. El participante de la campaña no tiene acceso a esta parte de la
aplicación. Únicamente la persona que está haciendo la campaña de recolección de
datos participativos puede modificar las configuraciones de la aplicación. Al iniciar la
campaña se encuentran tres diferentes secciones donde el usuario puede configurar
datos de la campaña.
En la sección general la aplicación permite introducir los datos del participante
de la campaña. Podemos ver esta pantalla en 8a. La aplicación solicita tres datos
del participante; el nombre, apellido y número de teléfono (Figura: 8b). Estos datos
posteriormente se pasan al servidor para registrar al participante.
En la configuración del servidor se pueden configurar datos del servidor MQTT al
cual el servidor está conectado. Pide dos diferentes datos, primero la dirección del
servidor y finalmente el puerto en el cual está corriendo el servidor MQTT (Figura: 8c).
26
(a) (b)
(c) (d)
Figura 8. Pantalla con configuración
27
La tercera y última sección permite configurar la cantidad de días que correrá la
campaña. Una vez que todos los datos estén configurados se puede iniciar la campaña
(Figura: 8d). Es muy importante que, cuando se inicie la campaña en el dispositivo por
primera vez, el celular esté conectado al Internet para poder registrar el dispositivo en
el servidor.
4.1.3. Lockscreen Activity
Una vez que se inicia la campaña en la actividad de ajustes, se crea una intención
de abrir la actividad llamada LockScreenActivity. La actividad busca ser una fuente
de información para el participante de la campaña sin permitir entradas por parte del
participante podemos ver la pantalla en la figura 9a. Uno de los datos que la función
busca mostrar al participante es la hora actual de tal manera que pueda servir como
un reloj para el participante.
La primera función que corre la aplicación por parte de la LockScreenActivity es una
que se llama updateClock(). Esta función actualiza los campos de texto cada cien mili-
segundos. Entre estos está el nivel de batería restante en el dispositivo, la hora actual
y algún mensaje que puede servir para el desarrollador como forma de depuración o
para mostrarle al participante algún mensaje.
La siguiente función que corre es para deshabilitar todos los botones de entrada. El
botón de regresar solo retorna un menos uno para evitar que se cierre la aplicación. El
botón de home fue más difícil de deshabilitar. La forma en la que se pudo deshabilitar
finalmente fue definir la pantalla de LockScreenActivity como la pantalla principal, por
lo cual al momento de oprimir el botón para que lleve al usuario a la pantalla inicial,
el celular pensará que ya está ahí. Finalmente, para deshabilitar el botón de la lista de
aplicaciones se crea una función que está escuchando constantemente para cuando
se abra la lista de aplicaciones seleccioná la primera instantáneamente, la cual va a
ser la de la actividad de LockScreenActivity.
Crea un botón que la persona que está corriendo la campaña puede usar para des-
bloquear la aplicación y cerrar la campaña. Al presionar el botón la aplicación solicita
un código que está codificado en la aplicación (Figura: 9b). Cuando se introduce el
28
código correcto, la aplicación rehabilita los botones para poder cerrar la aplicación y
restaurar el celular a funcionalidad normal.
Después de esto inicializa la función de track que es parte de la clase GPSutils. Esta
es la función que maneja la captura de los datos de GPS.
(a) (b)
Figura 9. Pantalla de usuario
4.1.4. MQTT Helper
MQTT Helper es una clase que permite usar la biblioteca de paho para conectarnos
al servidor de MQTT. Los datos del servidor los obtiene de las preferencias de Android.
Estas se definen dentro de la actividad de SettingsActivity. Si por alguna razón los
datos del servidor no fueron definidos, por omisión usa iot.eclipse.org con el puerto
1883 que es un servidor público puesto por parte de la fundación eclipse.
29
4.1.5. MQTT Utils
Esta función se encarga de procesar los mensajes recibidos. Cuenta con varias
funciones que pueden llevar a cabo diferentes acciones como por ejemplo modificar el
tiempo entre cada captura de dato. Pero la función mas importante con la que cuenta
es la que hace el registro del dispositivo.
4.1.6. Preference Singleton
Esta clase se encarga simplemente de dar acceso a las preferencias de Android
desde todas las otras clases. Esta función es muy útil por que permite trabajar con
el contexto de la aplicación para compartir ciertas configuraciones entre diferentes
clases. Incluso permite pasar variables entre diferentes actividades.
4.2. Consideraciones de diseño
Para el diseño del sistema móvil se consultó con la empresa Ubilogix para obtener
una lista de requerimientos. Se empezó considerando las diferentes posibilidades de
tecnologías que se podrían usar para la captura de los datos de movilidad. Original-
mente se había considerado incluso el desarrollo de un dispositivo de hardware en
lugar de una aplicación. Por medio de varias juntas para tener lluvias de ideas con
Ubilogix llegamos al consenso de usar una aplicación de Android que capturara datos
de GPS. Se consideraron los siguientes aspectos sociales y técnicos.
Aspectos técnicos
• Rastreo de la ubicación
• Captura y transferencia de datos
• Gastos de energía
• Otras consideraciones técnicas
Aspectos sociales
30
• Interacción
• Incentivos
En las siguientes secciones discutimos estos aspectos.
4.3. Aspectos Técnicos
Para el diseño del dispositivo de rastreo se consideraron diferentes aspectos técni-
cos que eran necesarios para obtener un prototipo.
El primero de los aspectos técnicos necesarios era el rastreo de la ubicación y la
tecnología que se usaría para esto. Existen muchas diferentes tecnologías para obte-
ner la ubicación; en la sección 4.3.1 se discute un poco de la investigación que se hizo
sobre algunas de las tecnologías disponibles para la determinación de la ubicación.
Aparte de los sistemas de ubicación también se discutieron otros aspectos técnicos
en las lluvias de ideas como por ejemplo el almacenamiento de datos, y cuál sería el
método para obtener estos datos de los dispositivos de rastreo. Finalmente, también
se consideraron problemas de energía para el funcionamiento del dispositivo y algunos
otros datos de contexto.
4.3.1. Rastreo de la Ubicación
Para el rastreo de la ubicación se consideraron diferentes tecnologías. Al principio
del estudio se había pensado que quizás el uso del GPS no era la mejor opción pues
para el desarrollo de un circuito de rastreo se podría volver una opción costosa el
conseguir los chips de GPS. Por lo cual se investigaron diferentes tipos de sistemas
para el rastreo de ubicación.
Una de las maneras mas básicas para encontrar la ubicación de un objeto es por
medio de la triangulación. Normalmente se considera la triangulación como encontrar
la ubicación de un objeto basándose en la distancia de este objeto a dos o mas esta-
ciones de las cuales ya se conoce la ubicación. La triangulación se puede hacer con
31
diferentes tecnologías e incluso sistemas como el GPS hacen uso de triangulación en
base a la distancia de satélites tomando estos como las estaciones base.
En una pequeña sesión informal de lluvia de ideas se discutieron diferentes posi-
bilidades para hacer este rastreo. Una de las ideas que se propuso fue que quizás se
podría hacer la triangulación usando las antenas de las estaciones de radio FM que
ya existen dentro de la ciudad. Las torres de transmisión FM se podrían usar como
la estación base para la triangulación al detectar con qué potencia está llegando la
señal.
Este prototipo no se desarrolló mucho más allá de la fase conceptual porque aun-
que se podría usar para calcular la ubicación, con las limitaciones de tiempo en este
proyecto se convirtió en muy algo poco viable.
Manteniéndonos en al idea de desarrollar nuestro propio sistema de triangulación
se consideró usar la red de torres GSM para calcular la ubicación o incluso el desplie-
gue de una red de antenas de Wifi para crear una red de Internet comunitaria donde
conociendo la ubicación de los puntos de acceso a la red, y a cual de los puntos está
conectado se podría tener una idea muy gruesa de la ubicación del dispositivo. Pe-
ro de igual manera se consideró que era demasiado caro usar módulos de GSM para
obtener la ubicación y que el despliegue de una red de Wifi a pesar de que tendría
otros beneficios para la comunidad se volvería no solo costosa pero también tendría la
limitación de únicamente poder rastrear a los participantes dentro de la cobertura de
la red Wifi.
Finalmente, después de haber tomado en consideración los factores económicos,
llegamos a la conclusión de que era más económico obtener celulares Android de
baja gama los cuales ya cuentan con un chip de GPS integrado. Estos nos brindan un
entorno de desarrollo integrado con un sistema operativo y API, lo cual nos facilita
crear nuestra aplicación.
4.3.2. Captura y transferencia de datos
Uno de los aspectos importantes era como se iba a manejar la obtención de los
datos del dispositivo que cargarían los participantes. Se tenía que tomar en cuenta la
32
disponibilidad de las conexiones al Internet y los tiempos oportunos para consultar los
datos.
Dado que la problemática principal en la cual se basa este estudio es que existe una
falta de infraestructura en estas regiones desfavorecidas, era importante considerar
que no existiría una conexión constante al Internet por medio de la cual se podría
obtener los datos. Es por esto que se decidió usar un medio de transferencia tipo
“Delay Tolerant Network” es una red tolerante a los retrasos; este tipo de sistema
espera a que el dispositivo se conecte al Internet para establecer una conexión con el
servidor y hacer la transferencia de datos.
4.3.3. Energía
El consumo de energía era un factor muy importante que se tenia que tomar en
cuenta para el desarrollo del dispositivo. Como originalmente se había considerado
el diseñar un dispositivo se volvió importante pensar cómo podríamos energizar dicho
dispositivo. Este tema es importante puesto que el uso de una unidad de procesamien-
to central tendría un consumo alto de energía. Una de las unidades computacionales
que habíamos considerado al inicio era el uso del dispositivo tipo Raspberry Pi Zero.
Pero incluso bajando el poder de procesamiento para el ahorro de energía el mayor
tiempo de uso calculado que podríamos obtener de una batería convencional era ocho
horas.
Incluso después de la selección de celulares como el dispositivo para la captura de
datos, el consumo de energía fue un problema importante a resolver. Fue imposible
capturar los datos GPS segundo a segundo pues el consumo de energía se volvía
demasiado grande y la duración de la batería se acortaba a un par de horas. Por
estas razones se alargó el tiempo entre las capturas de datos a dos minutos y medio.
Se postula que para el estudio de movilidad basándonos en la movilidad peatonal
una resolución de un dato cada dos minutos y medio es suficiente para capturar una
imagen clara de la movilidad de los participantes.
33
4.3.4. Otras consideraciones técnicas
Entre las otras consideraciones que se tomaron como posibilidades para expandir
el uso de este estudio fue la posible transformación del dispositivo de captura de
datos en un tipo de sociómetro. Donde se podrían capturar datos de ruido ambiental
e incluso posteriormente clasificar el ruido ambiental de tal manera que podamos
entender como esto puede afectar el bienestar subjetivo de las personas. Pero una
vez mas debido a las limitaciones de tiempo puestas sobre este proyecto, por ser una
tesis de maestría se determinó que no habría suficiente tiempo para el desarrollo de
estas actividades.
Como una derivación más de este proyecto se determinó que una posible función
para el dispositivo seria que se usara como algún tipo de alerta de ayuda. Esta idea
después se desarrolló como un prototipo aparte el cual se presentó en el articulo “Buil-
ding Security Spheres: Design of a Wearable Device for Monitoring Child Displacements
in Dangerous Zones” el cual fue aceptado al congreso MexHIC.
4.4. Aspectos Sociales
Aparte de los aspectos técnicos que se revisaron durante la selección de la tecnolo-
gía otro tema que fue importante tratar era aquel de los aspectos sociales necesarios
para poder llevar a cabo la campaña de la recolección de datos. Era importante definir
el nivel de privacidad que se les podría proporcionar a los participantes, el nivel de
interacción entre los participantes y los dispositivos y finalmente como se podría in-
centivar a la participación en esta campaña de recolección de datos. En las siguientes
secciones explicaremos más a detalle las consideraciones que se hicieron dentro de
estos aspectos sociales durante el proceso de la selección de tecnología.
4.4.1. Interacción
El nivel de interacción entre los usuarios y el dispositivo fue un tema de mucha
duda. Era necesario tomar decisiones como si el tipo de campaña que se llevaría a
34
cabo seria participativa u oportunista. Esto es, si el dispositivo se encargaría automá-
ticamente de definir cuándo se tomarían ciertos datos, o si el usuario por medio de la
participación podría proporcionar datos.
En las ideas originales para el diseño del dispositivo cuando consistía en una tarjeta
computadora integrada tal como el Raspberry Pi se había pensado que quizás proveer
un medio de entrada al usuario podría ser tan simple como proveer un botón, este
concepto después se pasó para el diseño de las Security Spheres.
Cuando ya se definió que el dispositivo para la captura de los datos sería un celular,
surgieron nuevos temas con respecto al nivel de interacción que el usuario tendría con
el dispositivo. Por ejemplo Como se podría asegurar que el usuario no le movería al
dispositivo al nivel de parar la captura de los datos.
Una de las sugerencias que se hicieron fue de simplemente remover la pantalla del
celular y ponerlo en un tipo de caja negra. De tal manera que el usuario no pudiera
distinguir que el dispositivo es un celular. Este proceso hubiera resultado en el costo
de la labor para el desensamble de los dispositivos el cual hubiera sido provisto por
parte de Ubilogix.
La necesidad de limitar a las funciones del dispositivo y reducir su interacción con
él se volvieron más aparentes después de una visita de campo que se hizo a la colonia
Camino verde. En esta visita se le apoyó al M.C. Miguel Ylizaliturri en una campaña
de recolección de datos donde se les brindaron tabletas a niños de la colonia y se
les acompañó en una pequeña campaña de toma de fotografías de la colonia. Durante
esta pequeña campaña una de las cosas que se notó es que el mayor uso que le daban
los niños a la tableta era para jugar el juego “Clash of Clans”. A pesar de que en esta
campaña en lo único que afectó fue en la cantidad de fotos que los niños tomaron, para
una campaña donde se vuelve extremadamente necesario maximizar la duración de
la batería con el propósito de no perder puntos de ubicación, el que los participantes
puedan usar aplicaciones con tan alto consumo de energía se volvió un problema.
Esto nos animó a minimizar al máximo la interacción que el usuario tendría con la
aplicación. Sin embargo, finalmente llegamos a la conclusión de que podría ser algo
útil mostrar información, como mínimo el nivel de batería restante del dispositivo para
que pueda planear el mejor momento para cargar el dispositivo adecuadamente. Por
35
esta razón decidimos dejar la pantalla en el celular y no presentarlo como caja negra.
En cambio, el desarrollo de la aplicación buscó limitar la funcionalidad del celular a
únicamente capturar los datos de la ubicación y mostrar la información necesaria al
usuario.
4.4.2. Incentivos
Los incentivos eran un tema importante que considerar para el desarrollo de la
campaña e incluso del experimento, entre los diseños iniciales se había pensado en
usar una memoria o un reproductor de archivos mp3 como interfaz para incentivar a
los usuarios a cargar el dispositivo con ellos al igual que mantener la batería cargada.
Otra propuesta fue que se podría poner un identificador dentro del dispositivo donde
participantes de la campaña podrían tener acceso a ciertos recursos por parte de la
granja, como una biblioteca, o un club de Dungeons and Dragons en caso de que la
campaña fuera dirigida a los niños que participan en las actividades de la granja.
Gracias al precio realmente bajo de los dispositivos celulares finalmente se decidió
que como incentivo para la captura de datos y para mantener el dispositivo encendido
los participantes después de cuatro semanas de datos completos se podrían quedar
con el dispositivo.
4.5. Implementación de la aplicación GeoLock
En esta sección estaremos mostrando el proceso con detalles de las acciones que se
tomaron para el desarrollo de la aplicación GeoLock. Los prototipos que se elaboraron,
y las pruebas que se hicieron con la finalidad de tener un sistema funcional.
4.5.1. Primeras versiones del sistema de rastreo
La primera versión de lo que convertiría en la aplicación GeoLock se llamó GETLOC,
esta era una aplicación de Android muy sencilla que se desarrolló con el propósito de
probar algunas de las bibliotecas existentes en Android. Con la finalidad de poder ver
36
el funcionamiento del transporte de datos, la captura de datos del GPS y el consumo
de la batería. En la figura 10 podemos observar la interfaz básica de la aplicación.
(a)
Figura 10. Captura de pantalla de la aplicación prototipo para el rastreo de participantes
La primera funcionalidad que se le implementó fue permitir la comunicación de la
aplicación en el celular con un servidor. Para esto fue necesario escoger un protocolo
de transporte. En este caso por preferencia personal y con la idea de en una finalidad
comunicarse con un servidor que funcionara con el stack del servicio de FIWARE se
escogió el protocolo de MQTT. Uno de los componentes del stack de FIWARE es el “IOT
Things Agent” que permite la comunicación por varios diferentes protocolos uno de los
cuales es el MQTT, lo cual nos facilitaba el desarrollo. Se utilizó la biblioteca de MQTT
publicada por Paho1 con la cual se creó una clase que se encarga de la conexión al
servidor y de enviar los mensajes.
Una vez que la funcionalidad de los mensajes se implemento, se continuo con el
desarrollo la captura de la ubicación actual por medio del API de Android. Para esto se
implementó una clase la cual, en el momento de llamar una de sus funciones, accede
a este API y obtiene la ubicación por medio del Location Provider.
1El proyecto Eclipse Paho proporciona implementaciones de cliente de código abierto de los protocolosde mensajería MQTT y MQTT-SN.
37
Para esto se usó un botón que hacía el llamado a la función para obtener la ubica-
ción y posteriormente pasaba el resultado a la función que manejaba el mandar los
mensajes. Por este medio era posible obtener la ubicación y mandarla por mensaje
a un servidor de FIWARE. Posteriormente se desarrolló una función con el uso de un
temporizador por medio de la cual se podía mandar constantemente mensajes, los
cuales contenían la ubicación del dispositivo en conjunto con datos adicionales como
el nivel de batería.
Por este medio podríamos tener acceso a la ubicación de los participantes; desafor-
tunadamente era imposible utilizar este método para el rastreo de la ubicación de los
participantes en campo, puesto que para utilizar adecuadamente este método sería
necesario poder asegurar que los participantes de la campaña contarían con una co-
nexión a Internet el cien por ciento del tiempo.La verdad es que aunque sería posible
proveer conexión a Internet a los participantes por medio de redes GSM 3g y LTE esto
quizás se volvería demasiado costoso.
Finalmente, este fue el primer prototipo para hacer pruebas de la duración de la
batería usando el GPS y transfiriendo datos constantemente. El que el dispositivo es-
tuviese mandando datos constantemente significa que nos da un limite inferior a la
duración que tendría la batería.
4.6. Resumen y conclusiones
En este capítulo se presentaron los métodos que se usaron para guiar el desarrollo
de la aplicación de Android GeoLock. Se presentó de igual manera el proceso que se
llevó en las sesiones de diseño con expertos por parte de la empresa Ubilogix.
Se consideraron los diferentes medios de captura de ubicación que se podrían uti-
lizar para llevar a cabo la campaña de captura de datos y cómo se podría hacer la
transferencia de estos datos al servidor. El consumo de energía de los dispositivos.
También se tomaron en cuenta aspectos sociales como la interacción que los par-
ticipantes llevarían con los dispositivos y los incentivos para que participaran en la
campaña.
38
Fue con base en los aspectos técnicos y sociales que se encontraron durante estas
sesiones de diseño que se elaboró el desarrollo de la aplicación.
Finalmente, después de esto se describioó como fue la implementación del desa-
rrollo. Detallando algunas de las diferentes clases bibliotecas y helpers que se usaron
y desarrollaron para la implementación de la aplicación.
La aplicación de Android GeoLock permite capturar datos de la movilidad de los
participantes y subirlos al servidor. Minimizando la interacción que tiene con los parti-
cipantes de las campañas, de esta manera funcionando como captura de datos opor-
tunista.
Estos datos son pasados a la plataforma WEB por medio de un API que fue desarro-
llado. En el capitulo 5 mostramos el desarrollo de la plataforma Web y de su API.
39
Capítulo 5. Sistema de registro y visualización
En este capítulo se presenta el procedimiento que se llevó para el diseño de la
aplicación web que se llama RAstreo de MOvilidad System (RaMoS). El propósito de la
aplicación es actuar como servidor que pueda llevar a cabo la recolección de los datos
que provienen de los participantes en las campañas de rastreo de la movilidad. Aparte
de servir como el registro donde se guardan los datos de la movilidad también ejerce
la función de la visualización de los datos.
En el capítulo se describen las diferentes partes del sistema que componen a la
aplicación RaMoS; cómo se comunican entre ellas y las diferentes funciones que pro-
vee el sistema para la captura y visualización de los datos obtenidos en campañas de
movilidad.
5.1. Plataforma de visualización
La plataforma para la visualización de los datos capturados en el estudio está dis-
ponible en el URL http://agrs.science. Al entrar a está portal se le presenta al usuario
una página de bienvenida. Esta página se puede visualizar en la figura 11
En este portal se le da al usuario dos opciones. La primera es para registrarse en la
plataforma. La pantalla de registro permite al usuario seleccionar un nombre de usua-
rio, un correo y contraseña. Actualmente la plataforma únicamente permite registrar
al usuario con un correo que esté en el dominio de @cicese.edu y @cicese.edu.mx,
esto es algo que puede ser editado para incluir nuevos dominios posibles para el re-
gistro. La contraseña, usando la función de PHP password_hash, se genera una serie
de caracteres codificados de tal manera que la contraseña que se guarda en la base
de datos es segura.
La segunda opción que se le presenta al usuario es una página donde puede iniciar
sesión o en caso de que el usuario no recuerde su contraseña, que pueda restablecer
la contraseña.
40
(a)
Figura 11. Portal de bienvenida para la plataforma de la visualización de datos
5.1.1. Dashboard
Una vez que se haya iniciado sección, se le presenta al usuario una página donde
puede visualizar los participantes del estudio. Esta página se llama el dashboard y la
podemos ver en la figura 12
5.1.2. Datos
En la figura 13 podemos ver la página donde se pueden visualizar los datos. En esta
página se da un listado de los dispositivos. Para cada dispositivo se puede visualizar
los días que se capturaron.
De igual manera para cada día se da un listado de los archivos capturados
Al momento de seleccionar un día la aplicación genera una lista de los archivos
disponibles. Cada archivo es la colección de datos por una hora, o dos horas depen-
diendo del modelo del dispositivo. También al final de la lista incluye una opción para
combinar los archivos disponibles en un solo archivo virtual.
41
(a)
Figura 12. Pagina del dashboard con el listado de los participantes
(a)
Figura 14. Lista de los archivos disponibles
Al momento de seleccionar una de las opciones disponibles el sistema genera un
mapa con la ruta que el participante recorrió durante el periodo seleccionado. Con los
datos de movilidad el sistema también genera la lista de puntos que posiblemente son
42
(a)
Figura 13. Página para visualización de los datos
de interés para el participante. Estos puntos pueden ser su hogar, su lugar de trabajo,
o simplemente lugares que frecuenta.
La lista de los puntos de interés se puede ver a mano derecha del mapa en la
pagina y se muestra en la figura 16a . Cada punto de interés contiene tres diferentes
enlaces. El primero se llama Click to see. Al momento de dar click a este enlace como
se ve en la figura 16b se genera un punto sobre el mapa donde se puede visualizar la
ubicación geográfica del punto de interés.
43
(a)
Figura 15. Lista de los archivos disponibles
(a) (b)
Figura 16. Lista de los puntos de interés
Aparte del enlace Click to see también se generan otros dos enlaces llamados Step
1 y Step 2. Cada uno de estos enlaces permite agregar los puntos de interés a los
paneles de control mostrados en las figuras 17a, y 17c. Estos puntos son calculados
por medio del algoritmo de iCluster el cual es descrito en la sección 5.7.2.
Inicialmente los paneles de control están vacíos como se puede ver en la 17a. Por
medio de los enlaces se puede agregar hasta un máximo de dos puntos de interés
a cada uno de los paneles de control, como se ve en la figura 17b y 17c. Una vez
44
agregados con el botón de generar en cada panel respectivamente se puede agregar
los datos al tercer panel.
(a) (b)
(c) (d)
Figura 17. Paneles de control
5.2. API v1 para RaMoS
La plataforma RaMoS provee una interfaz de aplicación por medio de la cual se
puede hacer uso de la información recabada. De igual manera el API permite inter-
acción con los dispositivos por medio de comandos predefinidos. Este API entrega los
resultados en un formato JSON que es útil para el desarrollo de nuevas aplicaciones.
45
5.2.1. Acciones disponibles para el API
Como se puede ver en la tabla 1, el API cuenta con una interfaz para mandar coman-
dos; estos comandos permiten interactuar con el dispositivo. Actualmente la llamada
al API cuenta con cuatro posibles comandos, los cuales se pueden mandar en forma
de un parámetro. El comando se manda dentro del parámetro <ACTION>. Los posibles
comandos que se pueden mandar son:
edebug
Este comando permite habilitar el modo de depuración en los dispositivos. Es-
to presenta un mensaje en la pantalla del dispositivo del participante con datos
que se pueden usar para revisar el correcto funcionamiento del dispositivo.
ddebug
Este comando permite des-habilitar el modo de depuración en los dispositivos.
Esto quita el mensaje de depuración de la pantalla del dispositivo del participan-
te.
start
Este comando permite iniciar el rastreo del participante en caso de que haya
sido detenido. Este comando también toma un parámetro mas. El parámetro es
DEF y tomo como entrada un número entre 1 y 5. en ejemplo: /api.php?v=1&
mtd=sendcommand& action=start& devid=<ID> & def=1 entre mas pequeño el
número mayor resolución para la captura de datos puesto a que este parametro
define cada cuanto tiempo se va a estar haciendo una captura en minutos.
stop
Este comando permite parar el rastreo que hace el dispositivo.
46
5.3. Métodos de diseño
Para el diseño del sistema RaMoS se tomaron en cuenta las consideraciones con
las cuales se había diseñado la aplicación móvil. Con base en estas consideraciones
se empezó el diseño de la aplicación web que nos daría las funciones del servidor.
El propósito principal del sistema era poder conocer las rutas tomadas por los parti-
cipantes durante el periodo del estudio. Por lo cual se evaluaron diferentes bibliotecas
para la visualización de datos geoespaciales.
Para este sistema se empezó con un prototipo de baja fidelidad, el cual era una
pagina web sin funcionalidad. Esto se hizo para darnos una idea de cómo se debía
de ver el sistema y posteriormente se fueron implementando las funcionalidades por
medio del backend en conjunto con una aplicación always on para escuchar mensajes.
5.4. Requerimientos
Con el fin de crear una plataforma para la visualización de los datos de movilidad
que fueron capturados en los celulares que se les brindaron a los participantes del
estudio, se tomaron en cuenta los siguientes requisitos:
Mostrar los participantes registrados en la campaña de recolección de datos y su
información de contacto en caso de ser necesario.
Que la plataforma pueda tener comunicación con los celulares para poder enviar
comandos, independientemente de que los celulares puedan estar detrás de una
firewall .
Que permita llevar a cabo análisis de las rutas que recorrieron los participantes
de tal manera que se puedan obtener los puntos que son de interés para el parti-
cipante.
Generar rutas esperadas tomando como punto de inicio y punto final aquellos
que se obtuvieron por medio de la generación de puntos de interés, basándonos
en las rutas de los participantes.
47
Tabla 1. Recursos disponibles en el API REST de la plataforma RaMoS
Método PATH Descripción
GET /api.php?v=1&mtd=listusers
Muestra la lista de dispositivos ac-tualmente registrados en el siste-ma. Regresa un arreglo que con-tiene a cada dispositivo en formade JSON. Dentro del JSON viene elid del dispositivo en la base de da-tos, El devid que se usa como unallave para subir los datos,
GET /api.php?v=1&mtd=listdays&id=<ID>
Muestra la lista de los días quetiene datos capturados para undispositivo con un id <ID>. Estedato se puede usar para despuésconsultar los datos capturados.
GET /api.php?v=1&mtd=getdaydata&id=<ID>&day=<DAY>
Esta ruta del API permite el acce-so a los datos del día entero. Don-de cada punto dentro del arregloes un arreglo compuesto de lati-tud, longitud, altura y tiempo
GET /api.php?v=1&mtd=sendcommand&action=<ACTION>&devid=<ID>
Este método permite enviar co-mandos especializados a los dis-positivos de rastreo. Donde AC-TION es la acción deseada y ID esel id del dispositivo en la base dedatos.
POST /api.php?v=1&mtd=upload&key=<key>&devid=<ID>
Este método permite subir los ar-chivos con los datos capturadosen el dispositivo.
48
Analizar comparación de la ruta que el participante recorre. En otras palabras la
ruta real por comparación con ruta esperada.
Obtener posiciones de las divergencias entre las rutas recorridas por los partici-
pantes y las rutas sugeridas por servicios de ruteo.
Con base en estos requerimientos funcionales se llevó a cabo el desarrollo de la
plataforma.
5.5. Arquitectura
En la Figura 18 podemos ver la arquitectura básica que compone la plataforma
RaMoS. La plataforma está compuesta por dos aplicaciones principales. La primera es
una Web App que permite visualizar y analizar las rutas tomadas por los participantes.
La segunda aplicación es una always on que esta conectada al servicio de broker
de un servidor MQTT; esto es para poder tomar las acciones necesarias cuando un
dispositivo manda un mensaje a las direcciones adecuadas. Los dispositivos pueden
mandar mensajes que corresponden a unas acciones, estas pueden ser desde dar de
alta un nuevo dispositivo hasta subir archivos de la movilidad del participante cuando
el dispositivo se conecta a servicios de red.
En los siguientes párrafos hablaremos de cada uno de los nodos de ambas aplica-
ciones, sus propósitos y de cómo es que interactúan entre si.
49
Fig
ura
18.
Arq
uit
ect
ura
delse
rvid
or
RaM
oS
50
5.6. Tecnologías
Esta sección da una breve introducción a algunas de las tecnologías usadas para el
desarrollo de la plataforma RaMoS.
5.6.1. Docker
Docker es una aplicación de computadora para la virtualización de aplicaciones
por medio del kernel. La virtualización a nivel de kernel es más ligera que el uso de
máquinas virtuales pero a la vez permite el aislamiento de recursos. Hoy en día es una
de las aplicaciones mas prominentes para el desarrollo de plataformas, puesto a que
permite el entregar una plataforma completamente funcional con todas las bibliotecas
necesarias. En la Figura 191 podemos visualizar como se diferencia los contenedores
a las máquinas virtuales.
(a)
Figura 19. Visualización de la pila de una máquina virtual en comparación con un contenedor de Docker
El Desarrollo de la plataforma RaMoS fue hecho con la idea de pasar el sistema
a una imagen de Docker, en la cual se pudieran crear contenedores. La plataforma
1Fuente: https://rancher.com/playing-catch-docker-containers/
51
cuenta con un archivo de docker-compose por medio del cual se puede generar una
copia del sistema para efectos de desarrollo y de despliegue.
5.6.2. Fiware
Fiware es una plataforma creada por parte de la Unión Europea. Esta plataforma
está hecha para el desarrollo y despliegue de aplicaciones inteligentes basadas en el
contexto.
Una de las versiones de la aplicación always on que se desarrolló fue hecha en el
lenguaje node.js para la plataforma Fiware. Esta aplicación manejaba el registro de los
participantes en el servidor, pero después fue integrada a la aplicación RaMoS.py que
podemos ver en la sección 5.7.4.
Sin embargo, la plataforma de Fiware por medio de su servicio del Cloud Lab funcio-
nó como un entorno de pruebas en el cual se llevaron a cabo el desarrollo de muchos
de los componentes de esta plataforma y donde se efectuaron las primeras pruebas
de campo.
5.7. Componentes
En esta sección se presentan los diferentes aspectos técnicos y tecnologías que
fueron usadas para el desarrollo de la plataforma RaMoS. Se da una breve introducción
a los marcos de trabajo, bibliotecas, sistemas y lenguajes que fueron usados para el
desarrollo.
5.7.1. PHP Web App
PHP es un lenguaje de programación especializado para el desarrollo de páginas
web. Este lenguaje es procesado del lado del servidor y lo que se le presenta al usuario
es una página de HTML estática. Es una herramienta poderosa que permite la creación
de páginas dinámicas.
52
La aplicación RaMoS está construída en este lenguaje. Está diseñada con base en un
patrón arquitectónico de modelo vista controlador (MVC). En una arquitectura MVC la
aplicación está separada en tres componentes donde cada uno de estos componentes,
está encargado de manejar aspectos específicos del desarrollo.
La parte del modelo está enfocada a hacer consultas a la base de datos. Después
de hacer la consulta el modelo regresa un objeto con los resultados de la consulta.
El controlador maneja el ruteo de las páginas para direccionar al usuario a la página
correcta con base en el URL. Finalmente la vista son plantillas de páginas con base en
los cuales se pueden generar páginas dinámicas.
5.7.2. Funciones de JavaScript
Las funciones de JavaScript para el programa están separadas en dos distintos
archivos. El primero de los archivos es el que tiene que ver con las funciones de clus-
tering. Este archivo es la implementación del algoritmo iCluster que fue desarrollado
por (Hu y Wang, 2007). iCluster es un algoritmo basado en el tiempo para la creación
de clusters.
Cuando se busca encontrar puntos de interés basándonos en una lista de coorde-
nadas secuenciales que incluyen el tiempo, lógicamente se puede concluir que los
puntos mas importantes son aquellos en los que se pasó mas tiempo. Sin embargo
esto a veces puede fallar, por lo que se desarrolló el algoritmo iCluster, el cual incluye
tolerancia para las veces donde existe una ligera desviación.
El otro archivo maneja las funciones para la comparación de puntos donde permite
interactuar con la biblioteca Leaflet de JavaScript. Una vez que el algoritmo de iCluster
calcula los puntos de interés el usuario puede visualizar las diferentes ubicaciones en
el mapa con la biblioteca Leaflet donde se crean círculos verdes sobre el mapa en la
ubicación.
Posteriormente, para comparar, el primer paso es seleccionar dos puntos para la
comparación. Con estos dos puntos seleccionados se puede generar la ruta real. Para
la generación de la ruta real, la función encargada recibe el indice de cada uno de
53
los puntos, quita del mapa la ruta que estaba dibujada. Del arreglo de puntos corta la
sección del punto A al punto B y dibuja esta sección de puntos sobre el mapa.
Para la parte dos, toma los puntos A y B, y con estos puntos hace una solicitud al
API de OSRM del que podemos aprender mas en la sección 5.7.5 o al API de Google
Maps el cual podemos ver en la sección 5.7.6. Estos nos regresan la ruta esperada.
Finalmente una vez que la ruta real y la ruta esperada están seleccionadas en el
paso tres podemos iniciar la comparación de la ruta.
5.7.3. MQTT
Para el transporte de los mensajes se seleccionó el protocolo MQTT, el cual es un
protocolo que fue desarrollado por IBM para el monitoreo de un petroducto. MQTT es
un protocolo ligero que permite enviar mensajes entre dispositivos siempre y cuando
ambos puedan tener acceso a un servidor central que funciona como broker.
5.7.4. RaMoS.py
Ramos.py es una aplicación central para el desarrollo de la aplicación. Originalmen-
te desarrollada en el lenguaje Go posteriormente fue portada a Python por problemas
con la biblioteca de MQTT para Go.
Esta aplicación se encarga de registrar a los participantes en la base de datos
cuando la aplicación GeoLock manda el mensaje por medio de MQTT.
De igual manera esta aplicación maneja muchas de las posibles funciones que se
pueden llevar a cabo entre el servidor y los dispositivos. En la figura 20 vemos la
aplicación corriendo en el servidor registrando cada conexión de un dispositivo con el
servidor.
54
(a)
Figura 20. Pantalla de la aplicación Ramos.py corriendo en el servidor.
5.7.5. OSRM
OSRM o también conocido como Open Source Routing Machine (Maquina de ruteo
de fuente abierta) es un motor de generación de la ruta mas corta en redes viales. Está
escrita en la versión 14 del lenguaje de computación C++ e implementa algoritmos
sofisticados de ruteo y los combina con datos provenientes de OpenStreetMap. Estos
datos también son gratis y abiertos.
Gracias a que el proyecto está virtualizado en una imagen de Docker es posible des-
cargar esta imagen y crear nuestro propio contenedor para poder correr una instancia
local.
5.7.6. Google Maps API
El API de Google Maps es una interfaz de aplicación proveída por Google. Es por
medio de esta interfaz que los desarrolladores pueden acceder a rutinas, protocolos y
herramientas del servicio de Google Maps para construir sus aplicaciones. En particular
55
se utilizó el Directions API que es uno de los servicios incluidos en el API de Google
Maps.
Podemos visualizar un ejemplo de la respuesta que nos regresa una llamada al API
de Google Maps en la figura 21.
La llamada al API nos regresa los puntos importantes dentro de la llave steps. Cada
step contiene el punto inicial y el punto final. A pesar de que estos puntos se podrían
usar para correr la comparación de las rutas, los puntos son demasiado espaciados.
Esto resulta en que se vuelva difícil hacer la visualización en el mapa. Para poder
generar una linea que se pudiera visualizar bien en el mapa era importante poder
generar los puntos entre cada uno de los pasos que regresaba el API de Google Maps.
Para esto se consideró usar una vez mas el API de OSRM donde se entregaría el
punto inicial y el punto final obtenidos de cada step como valores de entrada. De
esta manera podríamos obtener los puntos significativos entre esos dos puntos. Sin
embargo, investigando un poco se descubrió una función que permite decodificar la
polyline entregada en la respuesta del API.
Esta función fue escrita por Ismael Stahelin de doublespringlabs y estaba dispo-
nible en su github https://gist.github.com/ismaels/6636986 esta función después de
obtener el polyline como entrada nos regresa un diccionario de latitudes y longitudes
que podemos ver en la figura 22.
Figura 22. Ejemplo del diccionario de ubicaciones decodificado por la librería polyline decoder
1 [2 {"latitude": 41.85073,"longitude": -87.65126},3 {"latitude": 41.63641,"longitude": -88.16034},4 {"latitude": 41.3131, "longitude": -88.19437},5 {"latitude": 40.90493,"longitude": -88.66934},6 ...7 ]
Esta función posteriormente fue modificada ligeramente para entregar los puntos
en un arreglo en vez de en un diccionario.
56
Figura 21. Respuesta ejemplo del API de ruteo de Google Maps
1 {2 "status": "OK",3 "geocoded_waypoints" : [4 {5 "geocoder_status" : "OK",6 "place_id" : "ChIJ7cv00DwsDogRAMDACa2m4K8",7 "types" : [ "locality", "political" ]8 },9 ...
10 ],11 "routes": [ {12 "summary": "I-40 W",13 "legs": [ {14 "steps": [ {15 "travel_mode": "WALKING",16 "start_location": {"lat": 41.8507300,"lng": -87.65100},17 "end_location": {"lat": 41.8525800,"lng": -87.6514100},18 "polyline": {19 "points": "a~l~Fjk~uOwHJy@P"20 },21 "start_location": {22 ...23 },24 "end_location": {25 ...26 },27 "overview_polyline": {28 "points": "a~l~Fjk~uOnzh@vlbBtc~@tsE`vnApw{A`dw@~w\\|tNtqf@l{
Yd_Fblh@rxo@b}@xxSfytAblk@xxaBeJxlcBb~t@zbh@jc|Bx}C`rv@rw|@rlhA~dVzeo@vrSnc}Axf]fjz@xfFbw~@dz{A~d{A|zOxbrBbdUvpo@`cFp~xBc`Hk@nurDznmFfwMbwz@bbl@lq~@loPpxq@bw_@v|{CbtY~jGqeMb{iF|n\\~mbDzeVh_Wr|Efc\\x`Ij{kE}mAb~uF{cNd}xBjp]fulBiwJpgg@|kHntyArpb@bijCk_Kv~eGyqTj_|@`uV`k|DcsNdwxAott@r}q@_gc@nu`CnvHx`k@dse@j|p@zpiAp|gEicy@`omFvaErfo@igQxnlApqGze~AsyRzrjAb__@ftyB}pIlo_BflmA~yQftNboWzoAlzp@mz`@|}_@fda@jakEitAn{fB_a]lexClshBtmqAdmY_hLxiZd~XtaBndgC"
29 },30 ...31 } } ] }
57
5.8. Resumen y conclusiones
En este capítulo se presentaron los métodos que se usaron para guiar el desarrollo
de la plataforma RaMoS, se presentan los requerimientos, la arquitectura y las tec-
nologías que se usaron durante el desarrollo. Se presentan también las aplicaciones
complementarias que se desarrollaron.
58
Capítulo 6. Diseño e implementación del estudio
En este capítulo se discuten las dos campañas de sensado que se desarrollaron para
llevar a cabo este estudio. Se explica el proceso que se realizó para el reclutamiento y
la captura de los datos.
6.1. Prueba Piloto
Se realizó una prueba piloto para verificar la funcionalidad de los sistemas que
se desarrollaron. Se probaron ambos, la aplicación GeoLock que describimos en el
capítulo 4 y el sistema web RaMoS que describimos en el capítulo 5.
La prueba piloto se realizó empezando el día 30 de abril del 2018 y por un perio-
do de 7 días válidos. Cuatro estudiantes de CICESE participaron en la prueba piloto.
Podemos ver algunas características de los participantes en la tabla 3
Tabla 2. Características de participantes del estudio piloto
Participante Posgrado Edad Días
P1 Computación 24 4
P2 Computación 38 8
P3 Oceanografía 25 11
P4 Computación 26 16
A pesar de que la duración del estudio debía de ser por el periodo de una semana
como se puede ver en la tabla, se capturaron diferentes cantidades de días para cada
participante. Esto es por la metodología donde únicamente le descontaba al partici-
pante los días validos.
En esta prueba definimos un día valido como un día en el que el participante estuvo
activo en promedio un ochenta por-ciento del día. Para la participante uno se registra-
ron únicamente cuatro días. La razón de esto es que hubo un error en la aplicación lo
que causó que se cerrara la misma. Este error se reporto hasta el final de la prueba
59
piloto, lo que causó que únicamente cuatro días fueran capturados. Para el resto de los
participantes hubo varios días en los cuales no cumplían con el mínimo requerimien-
to de movilidad durante el día por lo que varios días se tuvieron que capturar para
cumplir con la cuota de siete días validos.
Por medio de esta prueba piloto se pudieron detectar errores como el que se encon-
tró con el dispositivo de la participante número uno. Aparte de este error se encontró
que era muy importante recordar a los participantes que deben mantener sus disposi-
tivos con carga.
Los errores encontrados durante la prueba piloto fueron corregidos para la versión
que fue usada en la prueba final.
6.2. Diseño del estudio
Teniendo ya establecidos nuevos requerimientos encontrados durante la fase de la
prueba piloto. Se llevó a cabo el diseño para el estudio.
6.3. Etapas del estudio
Este estudio se conformó en dos partes separadas:
1. Reclutamiento - Durante esta etapa se realizó el reclutamiento de los participan-
tes. Esta etapa la podemos ver detallada en la sección 6.4.
2. Realización de campaña de sensado - Una vez que ya se tenían a los participantes
se llevó a cabo la realización de la campaña de sensado. Durante este periodo se
hizo el despliegue de los dispositivos y la captura de datos.
6.4. Reclutamiento y perfil de los participantes
Para la realización de este estudio se llevó a cabo un proceso de reclutamiento. Era
necesario reclutar participantes que pasaran una cantidad considerable de su tiempo
60
en un entorno urbano desfavorecido.
El entorno que se escogió para este estudio es la colonia Camino Verde de la ciudad
de Tijuana en Baja California, México. Dentro de esta colonia existe una centro de
investigación denominado Granja Transfronteriza. En este centro de investigación se
han hecho muchos estudios y actividades de alcance social. El personal de la Granja
Transfronteriza apoyó para realizar el reclutamiento de los participantes del estudio.
Ellos reclutaron catorce participantes para el estudio. Únicamente se designaron dos
criterios de exclusión.
Que sean residentes de la colonia Camino Verde. - Esto con el fin de intentar ma-
ximizar la posibilidad de que los participantes tomen rutas en entornos urbanos
desfavorecidos. En este criterio de exclusión se hicieron dos excepciones para,
dos de las personas que apoyan dentro de la Granja Transfronteriza pero no viven
en la colonia.
Que no cuenten con vehículo de transporte motorizado propio. Por cuestiones de
la batería se capturaban mejores datos cuando el participante se transportaba de
manera peatonal. A pesar de que no se prohibió el uso de transporte público, si
se consideró como criterio de exclusión el contar con un vehículo propio.
En la tabla 3 podemos visualizar el número identificador que fue asignado al parti-
cipante junto con su edad, ocupación y cantidad de días capturados. La razón por la
disparidad de días es que a pesar de que el estudio se reporta como ser de una sema-
na, se realizó la captura de datos por un periodo total de treinta días con la finalidad
de tener un conjunto de datos completo sobre el cual se pudiera realizar análisis.
6.4.1. Expectativa de privacidad
Uno de los temas de preocupación para el equipo de investigación y para los par-
ticipantes fue la posible invasión de privacidad con los datos de rastreo. El equipo
de investigación consideró diferentes medidas que podrían ser tomadas con el fin de
aumentar la privacidad de los participantes.
61
Tabla 3. Tabla de participantes del estudio *NOTA: Estos datos se obtendran proximamente*
ID Genero Edad Ocupación Días
33 M 19 Houseman null
35 M 19 Estudiante 8
36 F 33 Ama de Casa 9
37 M 16 Estudiante 21
38 M 37 Estudiante 20
39 M 39 Construcción null
40 F 18 Mamá 14
41 F 36 Ama de casa 5
42 F 30 Coordinadora enla granja trans-fronteriza
9
43 F 19 Estudiante 11
44 M 34 Construcción 21
45 M 15 Estudiante 12
48 M 17 Estudiante null
49 F 17 Estudiante null
62
Se consideraron algunas medidas como modificación de los datos para que aunque
fueran fieles, los datos no se pudieran ubicar directamente. Esta modificaciones po-
dría haber sido por medio de la suma de una constante a las coordenadas capturadas
por los participantes. Sin embargo esto hubiese dificultado el análisis de los datos.
Una de las aportaciones de este proyecto como se menciona en la sección 8.3 son los
datos que se proporcionan para futuras investigaciones. Por esto a los participantes
se les dará privacidad por obscuridad, al codificar sus nombres. Se consideró que fue
importante hacer hincapié a los participantes de que a pesar de que los datos captura-
dos podrían ser usados para investigaciones futuras, los nombres de los participantes
serían mantenidos en secreto.
De esta manera se aseguró que la privacidad de los participantes se mantendría
intacta frente a futuros grupos de investigación a pesar de que el equipo de investiga-
ción actual si conozca la identidad de los participantes. Cada uno de los participantes
consintió a la investigación y firmaron un acuerdo para participar en el estudio.
6.4.2. Registro de participantes
El día 14 de Agosto del 2018 se realizó el registro de los participantes para el estudio
de rastreo. Para esto se hizo un viaje a la Granja Transfronteriza, con los dispositivos
de rastreo.
Se tuvo una junta con los residentes de la colonia que habían sido escogidos para
participar en el estudio donde se les explicó la importancia del estudio, los procedi-
mientos y se respondieron preguntas que los participantes pudieran tener sobre el
estudio.
63
(a)
Figura 23. Imagen de junta con los residentes que participarían en la campaña de sensado
Se entregó a los participantes un acuerdo de consentimiento para la participación
en el estudio. Donde se les explicaron las diferentes cláusulas del estudio como la
duración del estudio y la recompensa por su participación.
Con la firma en el documento de consentimiento los participantes accedieron a que
los datos colectados sean retenidos por parte del equipo de investigación. De igual
manera concedieron permisos para que los datos sean usados en futuras investigacio-
nes.
64
(a)
Figura 24. Firma de los acuerdos de consentimiento para participar en el estudio como sujeto de inves-tigación
Finalmente a cada uno de los participantes se les entregó un dispositivo y se les
solicitó que llenaran los datos para el registro del dispositivo. Estos datos son nombre,
apellido y número de teléfono.
65
(a)
Figura 25. Dispositivo en el día de entrega
6.5. Realización de campaña de sensado
Oficialmente la campaña de sensado se realizo por un periodo de 30 días. Para
los propósitos de este estudio únicamente se utilizaron datos de la primera semana
capturada de los participantes. Se eligió la primera semana por la disponibilidad pronta
de los datos para llevar a cabo el análisis. Aparte de esto, los datos de la primera
semana estaban muy completos por que la mayoría de los participantes regresaron
la primera semana a descargar datos. En el capítulo 7 discutimos el análisis que se
realizó sobre los datos capturados.
66
Capítulo 7. Resultados y discusiones
En este capitulo se exponen diferentes estadísticas del uso de los sistemas RaMoS
y GeoLock. Después se habla de algunos de los casos encontrados que pensamos
que son interesantes dentro de los datos de los participantes del estudio. Finalmente
se presentan dos escenarios con los cuales se considera que se podría continuar la
investigación y usar los datos y la metodología desarrollada aquí como un punto de
lanzamiento.
7.1. Estadísticas del uso del sistema
Con base en los datos parciales capturados en el periodo del 14 de Agosto al 14 de
Septiembre, se determinaron las siguientes estadísticas de uso del sistema.
Se capturaron un total de 2842 horas de datos de movilidad en 159 días, con una
media de la población de μ = 284.2 horas y una desviación estándar de σ = 204.1. En
promedio los participantes capturaron 15.9 días de datos. Esto significa que en prome-
dio cada participante capturó 284 horas de datos, pero también muestra que hay una
gran diferencia de datos entre los participantes. Esto es por que hubo participantes
que no sincronizaron datos.
Es importante recordar que estos datos no incluyen los datos que fueron capturados
en los dispositivos de rastreo pero no sincronizados con la plataforma, por lo cual este
análisis estadístico únicamente se estará haciendo sobre diez participantes.
7.2. Casos encontrados
A causa de las limitaciones puestas en este proyecto por el tiempo disponible para
un estudio de maestría se seleccionaron únicamente dos participantes para el análisis
de este estudio. Fueron seleccionados por que tenían un alto nivel de sincronización
con el servidor. Se tomaron los datos colectados de cada participante dentro del pe-
riodo de las primeras dos semanas. A continuación mostramos algunos casos que
consideramos pueden ser interesantes y que sirven como una demostración de este
67
estudio. Dentro de las comparaciones la ruta real recorrida por el participante es ex-
presada en color azul mientras que la ruta esperada generada por el API de Google
Maps es expresada en color verde.
7.2.1. Participante 35
Para el primer participante a analizar seleccionamos al participante con el identifi-
cador 35. Este participante capturó 8 días en su primera conexión al servidor. De estos
ocho días todos los días tienen datos válidos sobre los cuales podemos hacer análisis.
Dentro del primer día con los datos de la movilidad del participante se generaron
seis diferentes puntos de interés. Estos puntos de interés están mayormente en el área
de la Universidad Autónoma de Baja California. Este participante es un estudiante de
la universidad y representa el camino que las personas tienen que recorrer para tener
acceso a los servicios.
Existe otro punto sobre el cual podemos comparar la ruta de este punto a los puntos
de interés ubicados alrededor de la UABC. La distancia entre el punto de interés 1 y
el punto de interés 2 que está ubicado cerca de la UABC por medio de la ruta real es
8861m, mientras que por la ruta esperada obtenida del API de Google Maps es 8554m.
El que el participante haya tomado una ruta que es mas larga que la ruta real puede
ser un indicador de que existe una condición que toma prioridad a la distancia que
causó que cambiara su trayectoria.
Si comparamos estas dos rutas podemos ver que existen cuatro diferentes diver-
gencias principales dentro de la ruta 26a. Estas existen entre el punto de interés uno
y el punto de interés dos. Esta comparación la podemos ver en la figura 26. De las
cuatro divergencias dos son grandes y dos son chicas, la primera divergencia entre las
dos rutas se puede visualizar en la figura 26b.
68
(a) (b)
Figura 26. Visualización de rutas
En la figura 27 podemos ver una comparación entre la distancia recorrida para cada
una de las rutas encontradas del día 14 de Agosto del 2018. Existe una ruta la cual
no está en la gráfica, que es la ruta entre el punto de interés 3 y 4. En esta ruta los
puntos estaban demasiado cerca, por lo cual no se pudo generar una comparación. De
los datos encontrados en tres de las cuatro rutas comparadas la distancia de la ruta
esperada fue mas grande que la de la ruta real. Por la gran distancia recorrida, con-
sideramos que la ruta 1a2 fue hecha en transporte público, lo cual explicaría algunos
de los saltos en las distancias.
En la figura 28 podemos visualizar la cantidad de divergencias que hubo en las
diferentes rutas. La ruta 5a6 tuvo una diferencia de 651 metros entre la ruta esperada
y la ruta real; esta es la mayor de las cuatro rutas. Esta misma es la que tuvo la mayor
cantidad de divergencias con un total de 6 divergencias de las 12 encontradas en todo
el día.
69
(a)
Figura 27. Comparación de rutas en metros para el participante 35 durante el día 14 de agosto del 2018
A causa de la distancia de la ruta 1a2 podemos inferir que en esa ruta el partici-
pante hizo uso del transporte público. Allí la ruta ruta esperada es mas larga que la
ruta real. Sin embargo una vez mas por las distancias recorridas consideramos que las
rutas 2a3, 4a5 y 5a6 fueron hechas de manera peatonal. Esto nos da una indicación
de que cuando existen divergencias en trayectorias peatonales puede ser para ahorrar
tiempo. Sin embargo esto es solo especulación, puesto a que como se menciona en el
la sección 8.1 no pudimos hacer entrevistas a los participantes del estudio.
70
(a)
Figura 28. Comparación de divergencias en las rutas para el participante 35 durante el día 14 de agostodel 2018
Finalmente en la figura 29 podemos visualizar por cada día de la semana analizada
la cantidad de desviaciones acumuladas para el participante 35. Los datos que en-
contramos en el día 8/14/2018 muestran que la mayor cantidad de desviaciones son
hechas en tramos cortos y se repite en el día 8/17/2018 y 8/20/2018.
Una cosa importante que recordar es que una divergencia no necesariamente es un
indicador de algo negativo en la ruta esperada que obtenemos del servicio de Google
Maps, sino también puede ser un indicador de algo positivo en la ruta alterna que tomo
el participante. Sin embargo existen unos casos donde la ruta esperada obtenida de
Google Maps hace algunos errores muy obvios. Uno de estos es el mostrado en la
figura 30. En esta divergencia, el participante hace uso de un paso peatonal mientras
que la ruta de Google Maps toma un rodeo de cientos de metros.
71
(a)
Figura 29. Cantidad de desviaciones acumuladas por día para el participante 35
(a)
Figura 30. Error en el modelo de Google Maps para trayectoria peatonal
72
7.2.2. Participante 36
Similarmente al análisis que se hizo para el participante 35, se analizaron los datos
de movilidad del participante 36. Este participante tuvo una mucha menor distancia de
manera diaria que el participante 35. Mientras que el participante 35 recorrió un total
de 68,341 metros con un promedio de μ = 2847.54 metros por ruta y una desviación
estándar de σ = 4024 metros, el participante 36 durante el mismo periodo de datos
recorrió un total de 14,770 metros con un promedio de μ = 777.37 metros por ruta
y una desviación estándar de σ = 1251.5 metros. En este caso podemos ver que el
promedio es menor que la desviación estándar por que el participante 36 tuvo varias
rutas cortas, y solo 3 muy largas.
Muchos de los mismos hallazgos que se hicieron con el participante 35 los podemos
observar en los datos obtenidos del participante 36. Cosas como que normalmente la
ruta esperada es mas larga que la ruta real. Esto lo podemos visualizar en la figura 31.
(a)
Figura 31. Comparación entre ruta real y ruta esperada
Esto es muy interesante por que dice que los participantes tratan de recorrer me-
nores distancias. Sin embargo para este participante hubo algunas ocasiones en las
cuales no tomó la ruta mas corta. Incluso en estas ocasiones tomó una ruta mucho
mas larga y donde existía una ruta mucho mas directa.
73
(a)
Figura 32. Comparación entre ruta real y ruta esperada para el participante 36 durante el día 8/15/2018
Una de las funciones disponibles en el sistema consiste en graficar en la ruta real
cual es la diferencia de altura. Aquí es interesante que por ejemplo el participante en la
ruta de la gráfica 32 decidió tomar una ruta que es mas larga y no la ruta mas directa.
Aquí consideramos que el participante decidió tomar esta ruta por el contexto del
área en la que está. Una cosa que no se puede ver solamente con el mapa, para lo que
el uso de la altura para dibujar la ruta nos da una indicación, es que hay una cambio
de altura durante la ruta. Esto lo podemos visualizar en la figura 33 donde se nota que
una de las carreteras es mas alta que la otra.
74
(a)
Figura 33. Imagen del área de la ruta del participante 36 durante el día 8/15/2018 donde la ruta verdees la ruta sugerida por Google Maps y la ruta Azul es la ruta real
7.3. Escenarios de Uso
Consideramos que es importante que los desarrollos que se hicieron en este pro-
yecto puedan ser la base para futuras investigaciones. Con el propósito de motivar la
investigación en esta área de estudio presentamos los siguientes dos escenarios que
se podrían desarrollar para la implementación de esta base de conocimientos.
7.3.1. Escenario uno
La seguridad de las personas es un tema muy importante y es un tema que está
directamente relacionado con la movilidad urbana de las personas. Cuestiones de se-
guridad afectan las opciones disponibles en la movilidad de las personas. Por lo cual el
contexto de la seguridad en las rutas que las personas toman es un dato interesante
que se puede agregar a la plataforma. Al sobreponer mas datos en forma de capas
sobre el mapa permite llegar a nuevas conclusiones basadas en el nuevo contexto.
Es por esto que una forma de continuar la investigación en el tema de la movili-
75
dad humana es con el desarrollo de una tecnología que pueda capturar la percepción
de seguridad propia de las personas en relación con su posición geográfica. Estos da-
tos se pueden usar posteriormente para generar un mapa de calor con respecto a la
seguridad de la zona urbana desfavorecida que se puede sobreponer en el mapa.
Durante el periodo de la investigación de este tema de tesis en colaboración con
el M.C. Miguel Ylizaliturri se trabajó en un artículo que fue aceptado en la conferencia
MexHIC 2018. Este artículo describe el proceso de diseño para el dispositivo llama-
do Security Bubble Bracelet que podemos ver en la figura 34; un dispositivo de bajo
perfil que permitiría dar un sentido de seguridad para niños que viven en estas áreas
urbanas desfavorecidas. Este dispositivo permitirá que se reporte de una manera sen-
cilla la inseguridad sin necesariamente llamar la atención hacia ellos mismos. A veces
existen situaciones que pueden causar que la auto percepción de la persona sobre su
seguridad baje pero a la vez no permita reportarlo en el momento.
Uno de estos escenarios es cuando uno observa malandros en la calle. Es imposible
pedirle a participantes de un estudio que sacaran un dispositivo para poder reportar
en el momento una baja en su percepción de seguridad, puesto que esto los podría
convertir en posibles víctimas. Para el artículo se construyó un prototipo, proponemos
que con este prototipo se podría llevar a cabo campañas de sensado donde se buscaría
capturar los datos de la percepción de la seguridad de las personas.
76
(a)
Figura 34. Prototipo de alta fidelidad para el brazalete de seguridad
Con el prototipo que se desarrolló para el articulo de Security Bubble Bracelet se
podría llevar a cabo una campaña de sensado centrado en las personas. En la figura 34
mostramos el brazalete que se desarrolló para la el articulo, este prototipo cuenta con
dos botones escondidos. Proponemos que estos datos sean recolectados por medio de
geo-etiquetado.
77
(a)
Figura 35. Computadora para la recolección de los datos
Los participantes pueden usar el botón grande para reportar una área que les cau-
sa una inseguridad inmediata mas no permanente. Esto por ejemplo podría ser que
estuvieran personas cerca intentando entrar a robar en una propiedad ajena, cuando
presencien un asalto o vean algo peligroso. Estos puntos tendrían un tiempo de expi-
ración. Mientras el otro botón puede indicar una área permanentemente insegura. De
este modo podemos generar los mapas de calor.
En la figura 36 podemos visualizar como se podría ver el mapa al momento de
aplicar una capa de seguridad. En la parte superior ponemos por ejemplo el uso de
puntos inseguros temporales y en la parte inferior en la derecha proponemos como se
podría ver el uso de puntos de inseguridad mas permanentes.
78
(a)
Figura 36. Simulacion de capa de seguridad
7.3.2. Escenario dos
Un segundo escenario de investigación que proponemos es donde se puede crear
un servicio de generación de rutas en base a la seguridad. La inspiración la tomamos
de una aplicación que se creó como parte del proyecto de SMARTSDK que genera rutas
para las personas con base en su perfil médico.
Este proyecto se llama GreenRoute. La aplicación toma los perfiles médicos auto
reportados de las personas y con base en los datos obtenidos de sensores ubicados
en la ciudad de México toman datos sobre la contaminación del aire y la cantidad de
polen. Usando estos datos el servicio genera una ruta que toma en cuenta la salud del
usuario.
79
Usando este servicio nosotros proponemos la creación de un servicio similar que
pueda tomar los datos de las rutas que tomaron las personas y sugerir esas rutas
como rutas alternas a usuarios nuevos.
Cuando una persona llega a un lugar nuevo tiende a usar servicios como Google
Maps para consultar el camino a su destino. Estos servicios no hacen uso del conoci-
miento intrínseco que tienen las personas sobre las zonas urbanas en las que viven y
es imposible actualmente transmitir estos datos de las personas que viven en estas
zonas urbanas desfavorecidas a las personas que son nuevas en el área.
7.4. Resumen y conclusiones
En este capítulo se presentaron estadísticas generadas en base a los datos obte-
nidos de la campaña de sensado. Se presentaron dos casos encontrados en las tra-
yectorias obtenidas durante la primera semana del estudio de dos participantes y se
presentaron dos escenarios de por donde se podría continuar la investigación que ha
sido empezada con esta tesis.
80
Capítulo 8. Conclusiones
En este capitulo se presentan las conclusiones obtenidas por el desarrollo de este
trabajo de investigación. Se presentan las limitaciones que se tuvieron y las contribu-
ciones. Finalmente se discute el trabajo futuro que se podría abordar basándonos en
esta investigación.
8.1. Limitaciones
Algunas de las limitaciones de este estudio se mencionan a continuación:
Datos cualitativos - Una de las limitaciones para este estudio fue que no se con-
siguieron datos cualitativos, sobre las rutas recorridas por los participantes. Esto
nos limita a que únicamente podemos especular de las razones por las cuales los
participantes tomaron las divergencias.
Cantidad de participantes - La baja cantidad de participantes que se tuvieron con-
sideramos es una limitante de este estudio. Una mayor cantidad de participantes
resultaría en mejores inferencias sobre las rutas.
Área estudiada - El área donde se llevo a cabo el estudio es una área muy grande.
Con la baja cantidad de participantes resulta que hay datos muy dispersos y es
improbable tener múltiples participantes que recorran la misma ruta.
8.2. Dificultades
Para el desarrollo de este trabajo de investigación se encontraron algunas dificulta-
des. A continuación describimos las dificultades que se tuvieron.
Tiempo - El limitante principal para el desarrollo de este trabajo de tesis fue la
cantidad de tiempo establecida para un trabajo de maestría. Hay muchas mejoras
que se pueden hacer ambas en la plataforma y en la aplicación para Android.
81
Distancia al campo de pruebas - Se eligió a la colonia Camino Verde como lugar
para llevar a cabo la recolección de los datos. Camino Verde está localizada en
la ciudad de Tijuana, puesto que el equipo de investigación está localizado en
Ensenada, se volvió difícil el hacer pruebas de campo ya con la población del
experimento.
Equipo de rastreo - Dentro del equipo de rastreo existieron varias limitaciones
particularmente con relación a la duración viable de recolección de datos con una
carga. Pero también por la limitante de la calidad de los datos de GPS.
8.3. Contribuciones
El desarrollo de este trabajo de tesis tuvo las siguientes contribuciones al conoci-
miento.
1. Metodología para captura de datos en zonas urbanas desfavorecidas - La primera
aportación de este proyecto es una base de conocimiento que es compuesta
por la metodología que se uso para la captura de datos en la colonia Camino
Verde. Esta se puede usar para realizar futuros estudios que utilicen sensado
participativo en zonas urbanas desfavorecidas.
2. Sistemas - Los sistemas que fueron desarrollados para la captura y visualización
de los datos que explicamos en los capítulos 4 y 5. Como se mencionó en la sec-
ción 8.1 hubo ciertas limitaciones en el desarrollo de las plataformas. Sin embar-
go consideramos que los sistemas son una buena aportación y permite continuar
desarrollando las plataformas.
3. Datos - En total se colectó la movilidad de 14 participantes durante un periodo de
treinta días. Estos datos en conjunto con los datos capturados en la prueba piloto
son aportados para la realización de estudios futuros.
82
8.4. Trabajo futuro
Dentro de la sección 7.3 describimos algunos escenarios donde la tecnología desa-
rrollada podría ser usada para futuros proyectos. Aparte de los escenarios propuestos
consideramos que se puede llevar mayor desarrollo en la plataforma de tal manera
que facilite la contextualización de los datos.
A pesar de que la funcionalidad básica está en la plataforma, hay muchas mejo-
ras que se podrían hacer. Principalmente si se desea realizar este estudio con una
población mas grande, se requiere rediseñar la aplicación GetLock descrita en el ca-
pitulo 4. En necesario desarrollar una aplicación con mejor uso de batería e incluso
consideramos que la aplicación se puede rediseñar para usar el mismo dispositivo del
participante sin la necesidad de proveer un dispositivo.
8.5. Resumen
Para esta investigación se realizó un estudio contextual, una aplicación para An-
droid, un sistema web compuesto de dos aplicaciones, una prueba piloto y un estudio
en la colonia Camino Verde de la ciudad Tijuana en Baja California, México.
Para el estudio contextual, se obtuvo información cualitativa por medio de entrevis-
tas a dos residentes de la colonia Camino Verde. La información cualitativa obtenida
mostró de qué manera la falta de acceso a servicios públicos y trabajo afecta el bien-
estar subjetivo de las personas. El entender las opciones que tienen las personas en
su movilidad urbana afecta el bienestar de las mismas personas funcionó como moti-
vación para el desarrollo del proyecto.
Con esta motivación se desarrolló una aplicación Android que se pudiera usar para
llevar a cabo una campaña de sensado. Los datos que captura la aplicación son datos
de la ubicación del dispositivo, lo cual permite el rastreo de movilidad urbana.
Aparte de la aplicación de Android GetLock se desarrolló un sistema web que permi-
te la recolección de los datos de movilidad de participantes en la campaña de sensado
y la visualización de los mismos datos. El sistema web RaMoS también permite la com-
paración de las rutas esperadas entre los puntos de interés de los participantes y las
83
rutas reales recorridas.
Con todas estas aplicaciones se estableció una base de conocimiento con la cual se
realizaron dos campañas de estudio. Una como prueba piloto para calificar la funcio-
nalidad del sistema. Con los conocimientos encontrados en la prueba piloto se hicieron
mejoras en ambas aplicaciones y con las aplicaciones mejoradas se realizó una com-
paña de sensado.
Finalmente con los datos obtenidos de la campaña de sensado se llevó a cabo el
análisis sobre los datos de movilidad de dos participantes de la campaña donde se
mostró que existen diferencias en la movilidad esperada y la movilidad real de las
personas que viven en estos entornos urbanos desfavorecidos.
8.6. Conclusiones
En este trabajo de tesis se encontraron instancias en las que la movilidad urbana
de dos de las personas que participaron en este estudio difería de la movilidad espe-
rada en zonas urbanas desfavorecidas. De igual manera se desarrolló un conjunto de
métodos por con los cuales se pueden realizar campañas de sensado participativo.
Se mostró que es posible obtener estos datos en zonas donde no existe una infra-
estructura típica de los entornos urbanos donde se colectan, ya que las conexiones
a Internet no están siempre disponibles. Se demostró que efectivamente existen di-
vergencias en las trayectorias de las personas a pesar de las dificultades del trabajo
de investigación que se detallan en la sección 8.2. Sin embargo consideramos que es
necesario continuar la investigación para poder proveer mejor información sobre la
razón de las divergencias.
84
Literatura citada
Alkire, S. y Foster, J. (2011). Counting and multidimensional poverty measurement.Journal of public economics, 95(7): 476–487.
Brockmann, D., Hufnagel, L., y Geisel, T. (2006). The scaling laws of human travel.Nature, 439(7075): 462–465.
Burke, J. A., Estrin, D., Hansen, M., Parker, A., Ramanathan, N., Reddy, S., y Srivastava,M. B. (2006). Participatory sensing.
Calabrese, F., Diao, M., Di Lorenzo, G., Ferreira Jr, J., y Ratti, C. (2013). Understandingindividual mobility patterns from urban sensing data: A mobile phone trace example.Transportation research part C: emerging technologies, 26: 301–313.
Charness, G., Gneezy, U., y Kuhn, M. A. (2012). Experimental methods: Between-subject and within-subject design. Journal of Economic Behavior & Organization,81(1): 1–8.
Dibble, S., Gibbins, J., y Tamayo, A. (2017). The deadliest year. San Diego Union-Tribune.
Diener, E., Suh, E. M., Lucas, R. E., y Smith, H. L. (1999). Subjective well-being: Threedecades of progress. Psychological bulletin, 125(2): 276.
Diener, E., Oishi, S., y Lucas, R. E. (2002). Subjective well-being: The science of hap-piness and life satisfaction. In C.R. Snyder & S.J. Lopez (Ed.), Handbook of PositivePsychology. En: Oxford Handbook of Positive Psychology. pp. 187–194.
Fan, Z., Song, X., Shibasaki, R., Li, T., y Kaneda, H. (2016). Citycoupling: bridgingintercity human mobility. pp. 718–728.
Goedhart, T., Halberstadt, V., Kapteyn, A., y Van Praag, B. (1977). The poverty line:concept and measurement. Journal of Human Resources, pp. 503–520.
Hightower, J. y Borriello, G. (2001). Location systems for ubiquitous computing. Com-puter, 34(8): 57–66.
Hu, D. H. y Wang, C.-L. (2007). Gps-based location extraction and presence mana-gement for mobile instant messenger. En: T.-W. Kuo, E. Sha, M. Guo, L. T. Yang, yZ. Shao (eds.), Embedded and Ubiquitous Computing, Berlin, Heidelberg. SpringerBerlin Heidelberg, pp. 309–320.
Jalan, J. y Ravallion, M. (2002). Geographic poverty traps? a micro model of consum-ption growth in rural china. Journal of applied econometrics, 17(4): 329–346.
Juster, F. T., Courant, P. N., y Dow, G. K. (1981). A theoretical framework for the mea-surement of well-being. Review of Income and Wealth, 27(1): 1–31.
Kakwani, N., Silber, J., et al. (2008). Introduction: Multidimensional poverty analysis:Conceptual issues, empirical illustrations and policy implications. World Develop-ment, 36(6): 987–991.
Kanazawa, S. (2005). Who lies on surveys, and what can we do about it? The Journalof Social, Political, and Economic Studies, 30(3): 361.
85
Keeling, D. J. (2009). Transportation geography: local challenges, global contexts. Pro-gress in Human Geography, pp. 516–526.
Lathia, N., Quercia, D., y Crowcroft, J. (2012). The hidden image of the city: Sensingcommunity well-being from urban mobility. pp. 91–98.
Lever, J. P. (2004). Poverty and subjective well-being in mexico. Social IndicatorsResearch, 68(1): 1–33.
Li, J., Liu, Q., y Sang, Y. (2012). Several Issues about Urbanization and Urban Safety.International Symposium on Safety Science and Engineering in China, 43: 615–621.
Nevárez, J. B. y Castro, M. C. (2014). La crisis global, el programa oportunidades ysu impacto en la reducción de la pobreza en méxico. Revista Nicolaita de EstudiosEconómicos, 9(2): 7 – 38.
Noulas, A., Scellato, S., Lambiotte, R., Pontil, M., y Mascolo, C. (2012). A Tale of ManyCities: Universal Patterns in Human Urban Mobility. PLoS ONE, 7(5): e37027.
Rodríguez, F. R. y Shelton, C. A. (2013). Caught in a poverty trap? testing for single vs.multiple equilibrium models of growth. Journal of Globalization and Development,3(2): 1–25.
Rojas, M. (2008). Experienced poverty and income poverty in mexico: A subjectivewell-being approach. World Development, 36(6): 1078–1093.
Seligman, M. E. y Csikszentmihalyi, M. (2000). Positive psychology: An introduction.55(1).
Seltman, H. J. (2012). Experimental design and analysis. Reporte técnico.
Suich, H. (2012). Conceptual framework: poverty.
Thorbecke, E. (2011). Measurement of social well-being and progress. Realidad, Datosy Espacio, Revista Internacional de Estadística y Geografía, 2(1): 96–109.
United Nations (2012). World Urbanization Prospects The 2011 Revision. Reporte téc-nico, Department of Economic and Social Affairs and Population Division.
Varshavsky, A., De Lara, E., Hightower, J., LaMarca, A., y Otsason, V. (2007). Gsm indoorlocalization. Pervasive and Mobile Computing, 3(6): 698–720.
Zheng, V. W., Zheng, Y., Xie, X., y Yang, Q. (2012). Towards mobile intelligence: Learningfrom gps history data for collaborative recommendation. Artificial Intelligence, 184:17–37.
Zheng, Y., Capra, L., Wolfson, O., y Yang, H. (2014). Urban computing: concepts, metho-dologies, and applications. ACM Transactions on Intelligent Systems and Technology(TIST), 5(3): 38.
2
86
Anexo 1: Protocolo de Entrevista
Instrucciones
Buenos días (tardes). Mi nombre es ____. Gracias por venir. Esta entrevista consistirá
de una sola parte que está compuesta por cuatro conjuntos de preguntas. Si usted está
de acuerdo y me da permiso, estaré grabando nuestra conversación. El propósito es
que puede obtener todos los detalles, pero a la vez pueda llevar una conversación
atenta con usted. Le aseguro que todos los comentarios se mantendrán confidenciales
y al final compilare un reporte que contendrá todos os comentarios que obtuve en las
entrevistas sin identificadores personales.
Sección 1: Preguntas demográficos
1. ¿Cuál es su nombre?
2. ¿En qué año nació?
3. ¿Cuál es su estado civil?
4. ¿Usted asistió o asiste a la escuela?
No: 4.1 ¿Me puede contar por qué?
Si: 4.1 ¿Cuál fue el último año de estudio que curso?
Si no termino: 4.2 ¿Por qué no continuo?
5. ¿Actualmente cuenta con un trabajo o más trabajos?
No: Saltar a 6
Si: 5.1 ¿Qué tipo de trabajo o trabajos labora?
5.2 ¿Que tan lejos le quedan su trabajo o trabajos?
2.3 ¿Qué medio de transporte usa para llegar a su trabajo?
6. ¿Tiene usted hijos?
No: Saltar a 7
Si: 6.1 ¿Cuántos hijos tiene?
6.2 ¿Cuántos de ellos aún viven en casa?
6.3 ¿Asisten actualmente a la escuela sus hijos?
6.3a. ¿De qué manera se trasladan a la escuela?
87
6.3b ¿Qué tan lejos queda la escuela de su casa?
6.3c. ¿Cuánto gasta diariamente en el transporte a la escuela?
Sección 2: Preguntas sobre puntos de interés
7. ¿Qué tanto tiempo pasa fuera de su casa?
No: 7.1 ¿Por cuales razones no sale usted de casa?
8. ¿Qué puntos de interés frecuenta fuera de su colonia?
9. ¿Cuánto tiempo gasta en trasladarse de su casa a los puntos previamente mencio-
nados?
10. ¿Qué medio o medios usa para trasladarse entre los puntos previamente mencio-
nados?
11. ¿Cómo percibe el impacto económico de trasladarse entre los puntos de interés?
Sección 3: Preguntas sobre transporte público
12. ¿Ha usado usted el transporte público dentro de su colonia?
No: Saltar a Sección 4
Si: Saltar a 13
13. ¿Cómo calificaría el servicio de transporte público?
14. ¿Qué tan lejos le queda de su casa las paradas del transporte público?
15. ¿Considera que existe una cantidad adecuada de paradas de transporte público
porque o porque no?
16. ¿Considera que existe una cantidad adecuada de rutas de transporte público por-
que o porque no?
16. ¿La frecuencia con la que pasa el transporte público le parece adecuada, porque o
porque no?
17. ¿Le han causado problemas la frecuencia con la que pasa las unidades de trans-
porte público?
88
18. ¿Le han causado problemas la frecuencia con la que pasa las unidades de trans-
porte público?
Sección 6: Transporte en general
19. ¿Cuántas veces al mes tiene usted que trasladarse caminando?
20. ¿Cuáles son algunos de los aspectos más difíciles de trasladarse dentro de su
colonia?
21. ¿En su caso particular, cual es el aspecto que más le afecta?
22. ¿Ha tenido alguna experiencia dentro o afuera de su colonia con respecto al trans-
porte que le haya evitado llegar a alguna cita importante?
No: Saltar a 23
Si: 22.1 Por favor describa dicha experiencia.
23. ¿Ha tenido alguna experiencia dentro o afuera de su colonia con respecto al trans-
porte que se le ha hecho particularmente inusual?
No: Saltar a 24
Si: 23.1 Por favor describa dicha experiencia.
24. En una escala de 0 a 10 donde cero es completamente inhábil y 10 completamente
hábil, cómo calificaría su habilidad para moverse dentro de su colonia.
25. En una escala de 0 a 10 donde cero es completamente inhábil y 10 completamente
hábil, cómo calificaría su habilidad para moverse dentro de su Ciudad.
26. ¿Cuáles son las horas del día que más se le dificulta trasladarse dentro de su
colonia?
27. ¿Con cuál frecuencia tiene usted que caminar de noche en su colonia?
Sección 4: Economía
28. ¿Qué tanto de sus ingresos son dedicados al transporte?
29. ¿Usted considera que un mejor medio de transporte le ayudaría en su economía
familiar?
89
No: Saltar a 30
Si: 29.1 Por favor describa por qué.
30. ¿Qué otros factores de transporte afectan a su economía familiar?
31. ¿Usted o alguien que conoce cuenta con necesidades especiales con respecto al
transporte?
No: Saltar a 32
Si: 31.1 ¿Cuáles serían esas necesidades?
32.2 ¿Esas necesidades como afectan la economía familiar?
32. ¿Considera que un mejor medio de transporte abriría las puertas para un mejor
trabajo o aumentar sus ingresos familiares? No: Saltar a 33 Si: 30.1 De qué manera le
ayudaría a usted el mejor medio de transporte.
33. ¿Usted ve posible mejorar sus medios de transporte?
No: Saltar a 34
Si: 33.1 ¿Cuáles son sus metas para mejorar su transporte?
34. ¿Qué considera es el mayor obstáculo para cumplir sus metas de mejor transporte?
35. ¿Cuáles considera que son los temas más importantes que debe atender el go-
bierno con respecto al transporte en su colonia?
36. ¿Cómo considera que esta la seguridad dentro de su colonia?
37. ¿Existen zonas dentro de su colonia que son mejor evitar?
No: Saltar a 38
Si: 37.1 ¿Cómo le ha afectado la existencia de estas zonas?
Sección 5: Salud
38. ¿Ha afectado de manera negativa el transporte público a su estado de ánimo?
39. ¿Con cuanta frecuencia acude a servicios médicos?
40. ¿Cuál es el centro médico más cercano a su casa?
41. ¿En sus propias palabras como afecta el transporte a su salud?
1 | 3
CONSENTIMIENTO PARA PARTICIPAR COMO SUJETO DE INVESTIGACIÓN
Documento de consentimiento para sujetos
Por medio de esta forma le estamos solicitando su apoyo para la participación en la prueba piloto del
estudio del Rastreo de la Movilidad de Habitantes de Zonas Urbanas desfavorecidas. Se le agradece por
su ayuda con la participación voluntaria en este estudio y cualquier pregunta que tenga después de leer
este documento se la podrá responder el equipo de investigación.
Investigador Principal
Alberto Ramos
Investigador (Director de Tesis)
J. Antonio Garcia Macías
PROPOSITO DEL ESTUDIO
El propósito de este estudio es colectar datos de movilidad de residentes de la colonia Camino Verde que
se puedan usar para probar la funcionabilidad del sistema que fue desarrollado como parte de la tesis de
maestría del ing. Alberto Gabriel Ramos Salvio con finalidad de mejor entender la movilidad en entornos
urbanos con baja infraestructura.
QUIEN PUEDE PARTICIPAR
Este estudio está abierto a la comunidad de residentes de la colonia Camino Verde en la ciudad de Tijuana.
En particular se busca a aquellos residentes que no cuenten con automóvil propio para poder obtener una
captura fiel de los datos de movilidad peatonal; se permite el uso de transporte público y de otros tipos
de transporte como taxis y uber.
En particular sería deseable que los residentes que participen en este estudio sean aquellos que caminen
frecuentemente.
PROCEDIMIENTOS
Al inicio del estudio se les entregara un celular a los participantes. El estudio se llevará a cabo por un
periodo de dos semanas. Donde los participantes se comprometen a cargaran todos los días con el celular
en su persona manteniendo la batería del celular cargada. Es importante cargar el celular mínimo una vez
al día para asegurarse de que pueda capturar las rutas diarias.
90
Anexo 2: Consentimiento para participar como sujeto de
investigación
RMHZUD-CICESE
2 | 3
CONFIDENCIALIDAD
Los datos colectados durante el trascurso de este estudio serán mantenidos completamente
confidenciales y usados únicamente para la prueba del sistema que fue desarrollado y posiblemente para
estudios futuros. No se compartirá información personal de los participantes para estos usos.
Acceso a Datos
Para proteger su seguridad y bienestar el equipo de investigación es el único que tiene la autorización de
acceso a los datos, según los términos de confidencialidad mencionados. Cualquier información derivada
de este proyecto de investigación que muestre su identidad no será voluntariamente revelada por estos
dos equipos (que tendrán acceso a los datos) sin su consentimiento explícito. Publicaciones y/o
presentaciones que resulten de esta investigación no incluirán información que revele su identidad.
Retención de los datos
El equipo de investigación mantendrá los datos que resulten de la investigación. Otros investigadores
pueden tener acceso a los datos para futuras investigaciones.
Incentivo
Como incentivo para la participación de este estudio para mantener el celular cargado y portarlo
diariamente, al proveer dos semanas adicionales de datos a las dos semanas del estudio se le regalara el
celular al participante. Al momento de concluir las dos semanas adicionales el participante se puede poner
en contacto con el equipo de investigación por medio de La Granja Transfronteriza para la eliminación de
la aplicación de rastreo y la activación de la funcionabilidad normal del dispositivo
SI USTED TIENE ALGUNA PREGUNTA
Si tiene comentarios, dudas, preocupaciones con respecto a la forma en la que se llevará a cabo la
investigación por favor contacte al equipo de investigación listado al inicio del presente documento.
RMHZUD-CICESE
3 | 3
ACUERDO DE PARTICIPACION VOLUNTARIA
Usted no debería firmar este documento a menos que lo haya leído. La participación en este estudio es
voluntaria. Usted puede negarse a contestar cualquier pregunta o suspender su participación en
cualquier momento sin sanciones ni pérdida de beneficios a los que tiene derecho. Su decisión no afectará
su relación futura con la CICESE. Su firma indica que usted ha leído la información en este documento de
consentimiento y ha tenido la oportunidad de hacer cualquier pregunta que tenga sobre el estudio.
Estoy de acuerdo en participar en el estudio
___________________________________________________ __________________
Firma Fecha
___________________________________________________
Nombre
___________________________________________________ __________________
Firma del Investigador Fecha
___________________________________________________
Nombre del Investigador