Centro de Investigación Cientíﬁca y de Educación Superior de … · 2018-10-22 · Centro de...

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:


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:


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...

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


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


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.


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Ìj{kE}mAb~uF{cNd}xBjp]fulBiwJpgg@|kHntyArpb@bijCk_Kv~eGyqTj_|@ùV`k|DcsNdwxAott@r}q@_gc@nu`CnvHx`k@dse@j|p@zpiAp|gEicy@òmFvaErfo@igQxnlApqGze~AsyRzrjAb__@ftyB}pIlo_BflmA~yQftNboWzoAlzp@mz`@|}_@fda@jakEitAn{fB_a]lexClshBtmqAdmY_hLxiZd~XtaBndgC"

29 },30 ...31 } } ] }

57


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


P3 Oceanografía 25 11


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



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


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.


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

[email protected]

Investigador (Director de Tesis)

J. Antonio Garcia Macías

[email protected]

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

Centro de Investigación Cientíﬁca y de Educación Superior de … · 2018-10-22 · Centro de...

Documents

Transcript of Centro de Investigación Cientíﬁca y de Educación Superior de … · 2018-10-22 · Centro de...