mashup_CaritasValencia-Lorenzo_Sicilia

TRABAJO FINAL DE CARRERA

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍAGEODÉSICA, CARTOGRÁFICA Y TOPOGRÁFICA

Titulación:

Ingeniero en Geodesia y Cartografía

“DESARROLLO DE UN MASHUPPARA LA VISUALIZACIÓN Y GESTIÓNDE LA INFORMACIÓN GEOGRÁFICA

DE CÁRITAS VALENCIADENTRO DEL MARCO DE INVESTIGACIÓN

PARTICIPATIVA CON UTÓPIKA-UPV”

Alumno:

LORENZO SICILIA TORRES

Tutor académico:

JESÚS PALOMAR VÁZQUEZ

E.T.S.I. Geodésica, Cartográfica y Topográfica de Valencia

Titulación: Ingeniero en Geodesia y Cartografía.

Título del Trabajo: Desarrollo de un mashup para la visualización y gestiónde la información geográfica de Cáritas Valencia,dentro del marco de investigación participativa con Utópika-UPV

Nombre y apellidos del alumno:Lorenzo Sicilia Torres

Tutor académico:Jesús Palomar Vázquez

Fecha:Julio 2011

Desarrollo de un mashup para la visualización y gestiónde la información geográfica de Cáritas Valencia,

dentro del marco de investigación participativa con Utópika-UPV por Lorenzo Sicilia Torres

se distribuye bajo la licenciaCreative Commons

Reconocimiento-NoComercial-CompartirIgual 3.0 Unported License

http://creativecommons.org/licenses/by-nc-sa/3.0/




Gracias a Jesús Palomarpor sus acertadas orientaciones,

siempre en los momentos adecuados.

Gracias a Nuria Baeza y a toda la gente de Cáritaspor su trabajo diario y por el refuerzo continuo

que para mí han supuesto, derrochando ilusión y gratitud.No olvidaré nunca la “sorpresa” que organizaron en su sede,

el riquísimo almuerzo, el vídeo y el birrete “cum laude” de cartulina.

Gracias, como no, a Diego Álvarez y demás miembros de Utópika,gracias a sus “locuras”, bien cuerdas, todo esto es posible.

Gracias por abrir nuevas ventanas de aire fresco en la universidad.

Gracias también a mis padres, mi hermana... a toda mi familia, la de sangrey la que se nos va regalando, gracias por tanta facilidad regalada...

Y gracias a Tí, por no dejar de soñar y alentar sueños...

Índices

Índice de contenido

Introducción...................................................................................................................9

Constitución del proyecto............................................................................................11

1.1.Antecedentes.......................................................................................................131.2.Justificación .......................................................................................................141.3.Descripción general ............................................................................................151.4.Requisitos que satisfacen las necesidades, deseos y expectativas de los interesados ................................................................................................................161.5.Influencias de los interesados ............................................................................171.6.Restricciones de partida, internas y externas .....................................................17

Tecnologías involucradas.............................................................................................19

2.1.Entorno de desarrollo .........................................................................................212.1.1.HTML..........................................................................................................212.1.2.CSS..............................................................................................................212.1.3.JavaScript....................................................................................................222.1.4.API de Google Maps para JavaScript (versión 3).......................................232.1.5.php...............................................................................................................242.1.6.MySQL........................................................................................................252.1.7.AJAX...........................................................................................................262.1.8.Drupal..........................................................................................................26

2.2.Herramientas de desarrollo ................................................................................272.3.Equipo e instalaciones ........................................................................................28

2.3.1.Requisitos mínimos de software para el cliente .........................................282.3.2.Requisitos de software para el servidor ......................................................28

Definición del proyecto................................................................................................29

3.1.Contexto del proyecto.........................................................................................313.1.1.Prácticas en empresa o institución...............................................................31

a)Fechas, horario, lugar de realización, tutores ..............................................31b)Bolsa económica de apoyo al estudio .........................................................31

3.1.2.Propiedad intelectual e industrial del trabajo .............................................343.2.Dependencias del proyecto ................................................................................343.3.Objetivos del proyecto .......................................................................................35

3.3.1.Para Utópika ...............................................................................................353.3.2.Para Cáritas ................................................................................................35

3.4.Especificación de la aplicación ..........................................................................363.4.1.Grupos/Segmentos de usuarios ..................................................................363.4.2.Objetivos ....................................................................................................363.4.3.Contenidos y funcionalidades.....................................................................38

Ejecución del proyecto.................................................................................................39

4.1.Metodología de trabajo.......................................................................................414.1.1.Investigación-Acción Participativa.............................................................414.1.2.Planificación temporal.................................................................................42

TFC: Ingeniería en Geodesia y Cartografía – Lorenzo Sicilia Torres 3

Mashup para la visualización y gestión de información geográfica de Cáritas Valencia

4.2.Consideraciones previas......................................................................................434.3.Modelo funcional general de las aplicaciones....................................................454.4.Información geográfica.......................................................................................46

4.4.1.Fuentes de información geográfica.............................................................50a)Cáritas Diocesana.........................................................................................51b)Instituto Cartográfico Valenciano (ICV)......................................................53c)Ayuntamiento de Valencia............................................................................54d)Respecto a la localización de elementos puntuales......................................54

4.4.2.Representación de información geográfica.................................................55a)Elementos puntuales con la clase Marker....................................................55b)Elementos poligonales con la clase Polygon................................................56

4.4.3.Generación de información geográfica.......................................................60a)En general, para entidades poligonales........................................................60b)Demarcaciones de parroquias.......................................................................63c)Demarcaciones de arciprestazgos.................................................................64d)Demarcaciones de vicarías...........................................................................69e)Demarcaciones de comarcas.........................................................................69f)Entidades puntuales......................................................................................69

4.5.Información alfanumérica...................................................................................714.6.Arquitectura de la información y su almacenamiento........................................78

4.6.1.Tablas MySQL tipo 1..................................................................................80a)Cáritas parroquial.........................................................................................80b)Centro Municipal de Servicios Sociales.......................................................84c)Contenedores de ropa de la Fundación INTRA...........................................85d)Tiendas @rropa de la Fundación INTRA....................................................85e)Otros Recursos Sociales...............................................................................86

4.6.2.Tablas MySQL tipo 2..................................................................................86a)Arciprestazgos..............................................................................................87b)Vicarias.........................................................................................................87c)Comarcas......................................................................................................87

4.7.Descripción detallada del Localizador................................................................884.7.1.Entorno gráfico............................................................................................88

a)Diseño Centrado en el Usuario.....................................................................88b)Botones e iconos propios..............................................................................90

4.7.2.Modelo funcional........................................................................................914.7.3.Características y ejemplos de uso................................................................94

a)Controles generales de visualización............................................................94b)Elección de recursos localizables.................................................................95c)Dirección base y tipo de búsqueda...............................................................96d)Globos de información.................................................................................98e)Cálculo de rutas............................................................................................99f)Informe para imprimir.................................................................................101

4.8.Descripción detallada del Generador................................................................1024.8.1.Entorno gráfico..........................................................................................1024.8.2.Modelo funcional......................................................................................104

4 Investigación participativa con Utópika-UPV

Índices

4.8.3.Características...........................................................................................106a)Controles generales de visualización..........................................................106b)Selección de unidad mínima de análisis y área de estudio.........................106c)Elección del tipo de consulta .....................................................................108d)Papel del php con SQL en los tipos de consulta.........................................110e)Consultas en bloque....................................................................................113f)Consulta en bloque con intervalos iguales dado el número de intervalos...116g)Consulta en bloque con intervalos iguales dada la amplitud del intervalo.117h)Consulta en bloque por cuantiles................................................................117i)Consulta en bloque por cortes naturales (Jenks).........................................118j)Consulta individual.....................................................................................121k)Consulta de situaciones más frecuentes.....................................................123l)Trabajando con las capas de información ..................................................125m)Generación de informes sobre las consultas.............................................128

4.8.4.Algunos ejemplos de mapas resultantes....................................................1304.9.Introducción y edición de datos con Drupal.....................................................131

4.9.1.Adaptación del contenido al sistema de Drupal........................................1314.9.2.Funcionalidades.........................................................................................134

Cierre..........................................................................................................................1355.1.Informe sobre el grado de cumplimiento de los objetivos marcados................137

5.1.1.Desde Utópika...........................................................................................1375.1.2.Desde Cáritas.............................................................................................138

a)Localizador de Recursos.............................................................................138b)Generador de mapas...................................................................................139

Conclusiones...............................................................................................................1416.1.Valoración personal ..........................................................................................1436.2.Vías futuras de trabajo para el proyecto............................................................145

6.2.1.En general..................................................................................................1456.2.2.Para el Localizador....................................................................................1466.2.3.Para el Generador......................................................................................147

Bibliografía.................................................................................................................1497.1.Libros................................................................................................................1517.2.Páginas web.......................................................................................................151



Índice de ilustracionesFigura 1. Planificación temporal con OpenProj........................................................................42Figura 2. Esquema del modelo funcional general de las aplicaciones......................................45Figura 3. Demarcaciones parroquiales de las Vicarías 1 y 2 (a falta de los poblados marítimos del sur)......................................................................................................................................47Figura 4. Áreas de Servicios Sociales del Ayuntamiento de Valencia (a falta de algunos poblados del norte y del sur).....................................................................................................48Figura 5. Demarcaciones de los 25 Arciprestazgos de las Vicarías 3 a 8 de la Diócesis...........48Figura 6. Demarcaciones de los 9 Arciprestazgos de las Vicarías 1 y 2 de la Diócesis.............48Figura 7. Demarcaciones de las 8 Vicarías de la Diócesis........................................................49Figura 8. Demarcaciones de las 33 Comarcas presentes en la Diócesis....................................49Figura 9. Mapa analógico 1:8.000 con demarcaciones parroquiales de la ciudad de Valencia..51Figura 10. Ejemplo de Informe de Límites Parroquiales..........................................................52Figura 11. Mapa con áreas de Servicios Sociales en un tríptico de la Regidoria de Benestar...52Figura 12. Shapes de límites administrativos del CV300 mostrados en gvSIG........................53Figura 13. Shapes de barrios y distritos del municipio de Valencia suministrados por su Ayuntamiento...........................................................................................................................54Figura 14. Ejemplo de marcadores y ventana de información desplegada................................56Figura 15. Ejemplo de polígono simple. Comarca Alt Vinalopó...............................................57Figura 16. Ejemplo de polígono complejo. Comarca L'Horta Nord.........................................58Figura 17. Ejemplo de marcadores y ventana de información desplegada................................59Figura 18. Dibujo de demarcaciones parroquiales en Google Earth.........................................63Figura 19. Herramienta “Disolver” del Gestor de geoprocesos................................................65Figura 20. Herramienta “Área de influencia” del Gestor de geoprocesos.................................66Figura 21. Herramienta “Juntar” del Gestor de geoprocesos....................................................67Figura 22. Herramienta “Reproyectar” del Gestor de geoprocesos...........................................68Figura 23. Tabla de atributos del shape municipios WGS84.....................................................68Figura 24. Herramienta “¿Qué hay aquí?”................................................................................69Figura 25. Página 1 de la encuesta “Memoria de Actividades de la Cáritas Parroquial 2010”..72Figura 26. Página 2 de la encuesta “Memoria de Actividades de la Cáritas Parroquial 2010”..73Figura 27. Página 3 de la encuesta “Memoria de Actividades de la Cáritas Parroquial 2010”..74Figura 28. Página 4 de la encuesta “Memoria de Actividades de la Cáritas Parroquial 2010”..75Figura 29. Localizador de Recursos: vista general...................................................................89Figura 30. Marcadores diseñados para el Localizador..............................................................90Figura 31. Botones diseñados para el Localizador....................................................................90Figura 32. Localizador de Recursos: Efectos en los botones....................................................90Figura 33. Esquema del modelo funcional del Localizador......................................................91Figura 34. Algoritmo punto en polígono: casos 1, 2 y 3...........................................................92Figura 35. Algoritmo punto en polígono: casos 4 y 5...............................................................93Figura 36. Control de Street View............................................................................................94Figura 37. Controles de posición y escala................................................................................94Figura 38. Selector de cartografía base.....................................................................................94Figura 39. Mini ventana de situación con su botón que la oculta o muestra.............................94Figura 40. Localizador de Recursos: ejemplo 1........................................................................95Figura 41. Localizador de Recursos: ejemplo 2........................................................................96Figura 42. Localizador de Recursos: ejemplo 3........................................................................97Figura 43. Herramienta Limpiar mapa......................................................................................97Figura 44. Localizador de Recursos: ejemplo 4........................................................................98


Índices

Figura 45. Localizador de Recursos: ejemplo de globos en Cáritas Parroquiales.....................99Figura 46. Localizador de Recursos: ejemplo 5......................................................................100Figura 47. Localizador de Recursos: ejemplo de ruta “a pie”.................................................100Figura 48. Localizador de Recursos: ejemplo de ruta “en coche”...........................................100Figura 49. Localizador de Recursos: Sección Informe...........................................................101Figura 50. Localizador de Recursos: ejemplo de informe de recursos localizados.................101Figura 51. Generador de Mapas: vista general inicial.............................................................102Figura 52. Generador de Mapas: panel lateral desplegado y detalle botón oculta / muestra.. .103Figura 53. Generador de Mapas: panel lateral ocultado, con mapa generado, fondo blanco y detalle botón oculta / muestra.................................................................................................103Figura 54. Esquema del modelo funcional del Generador......................................................104Figura 55. Sección de selección de unidad mínima y área de estudio en el Generador...........106Figura 56. Selector simple de unidad mínima de análisis.......................................................107Figura 57. Selector múltiple de área de estudio......................................................................107Figura 58. Aspecto de la sección tipo consulta, seleccionado el modo “En bloque”...............109Figura 59. Aspecto de la sección tipo consulta, seleccionado el modo “Individual”...............109Figura 60. Aspecto de la sección tipo consulta, seleccionado el modo “Situaciones”.............109Figura 61. Herramienta “Limpiar consultas”..........................................................................109Figura 62. Menú desplegable de selección de variable de estudio en el Generador................113Figura 63. Menú desplegable de selección de método de clasificación en intervalos en el Generador...............................................................................................................................113Figura 64. Menú desplegable de selección del tipo de dato a utilizar en cada consulta “En bloque” en el Generador.........................................................................................................114Figura 65. Ejemplo de clasificación con intervalos iguales dado el número de intervalos......116Figura 66. Ejemplo de clasificación con intervalos iguales dado la amplitud del intervalo....117Figura 67. Ejemplo de clasificación por cuantiles..................................................................118Figura 68. Ejemplo de clasificación por cortes naturales. Método de Jenks...........................120Ilustración 69: Histograma de valores clasificados por cortes naturales (Método de Jenks)...120Figura 70. Menú desplegable de selección del tipo de dato a utilizar en cada consulta “Individual” en el Generador..................................................................................................121Figura 71. Menú desplegable de selección de la variable de estudio a utilizar en cada consulta “Individual” en el Generador..................................................................................................121Figura 72. Menú desplegable de selección del operador en cada consulta “Individual” en el Generador...............................................................................................................................122Figura 73. Ejemplo de mapa temático construido con consultas individuales........................123Figura 74. Ejemplo de mapa temático de situaciones más frecuentes.....................................124Figura 75. Sección “Capas visibles” en el panel lateral de herramientas del Generador.........125Figura 76. Ejemplos de cómo desplazar etiquetas y leyendas en el Generador.......................127Figura 77. Ejemplos de disposición de elementos en las etiquetas del Generador..................127Figura 78. Generador de Mapas: Sección Informe.................................................................128Figura 79. Ejemplo 1 de informe en el Generador de Mapas..................................................128Figura 80. Ejemplo 2 de informe en el Generador de Mapas..................................................129Figura 81. Ejemplo final 1 del Generador de Mapas..............................................................130Figura 82. Ejemplo final 2 del Generador de Mapas..............................................................130Figura 83. Ejemplo final 3 del Generador de Mapas..............................................................131Figura 84. Página de acceso al administrador implementado en Drupal.................................133



Índice de tablasTabla 1. Contenidos y funcionalidades.....................................................................................38Tabla 2. Número de archivos y de líneas de código implementado en cada lenguaje...............43Tabla 3. Información geográfica propia....................................................................................46Tabla 4. Valores del campo tipo_poli en las tablas tipo 2 de la base de datos que definirán polígonos complejos (véase 4.6.2. pág.86)...............................................................................57Tabla 5. Estructura del paths en clase Polygon (23).................................................................58Tabla 6. Tipos de campos utilizados en las tablas de la base de datos MySQL.........................79Tabla 7. Tablas tipo 1 en la base de datos MySQL...................................................................80Tabla 8. Tabla content_type_parroquias: Campos para uso interno en Drupal .........................80Tabla 9. Tabla content_type_parroquias: Campos de información geográfica y otros..............80Tabla 10. Tabla content_type_parroquias: Campos de información general de la Cáritas Parroquial.................................................................................................................................81Tabla 11. Tabla content_type_parroquias: Campos de datos estadísticos sobre beneficiarios...81Tabla 12. Tabla content_type_parroquias: Campos de datos estadísticos sobre voluntarios.....82Tabla 13. Tabla content_type_parroquias: Campos de datos estadísticos sobre dinamización comunitaria, comunicación, participación en campañas...........................................................82Tabla 14. Tabla content_type_parroquias: Campos de datos estadísticos sobre ingresos en el balance económico...................................................................................................................83Tabla 15. Tabla content_type_parroquias: Campos de datos estadísticos sobre gastos en el balance económico...................................................................................................................83Tabla 16. Tabla content_type_parroquias: Campos de datos estadísticos sobre situaciones que se presentan más frecuentemente..............................................................................................84Tabla 17. Tabla content_type_cmss..........................................................................................84Tabla 18. Tabla content_type_contenedoresintra......................................................................85Tabla 19. Tabla content_type_tiendas_arropa...........................................................................85Tabla 20. Tabla content_type_otros_recursos...........................................................................86Tabla 21. Tablas tipo 2 en la base de datos MySQL.................................................................86Tabla 22. Tabla geo_arciprestazgos..........................................................................................87Tabla 23. Cuadro resumen de tipologías de consultas SQL para los modos “Individual” y “En bloque”...................................................................................................................................110Tabla 24. Cuadro 1 de diferencias entre los subtipos de A, B y C de consultas SQL..............112Tabla 25. Cuadro 2 de diferencias entre los subtipos de B y C de consultas SQL...................112


Introducción

El título del presenta Trabajo Final de Carrera, dice así:

“Desarrollo de un mashup para la visualización y gestiónde la información geográfica de Cáritas Valencia,

dentro del marco de investigación participativa con Utópika-UPV”

Mashup (36), aplicación web híbrida, es el término con el que en desarrollo web se acuña las páginas web o aplicaciones que usan y combinan datos y funcionalidad procedentes de una o más fuentes para crear nuevos servicios. El término implica integración fácil y rápida, usando a menudo APIs abiertas y fuentes de datos para producir resultados enriquecidos.

En nuestro caso, hablamos de mashup, fundamentalmente porque usamos la API de Google Maps para construir dos aplicaciones que vienen a cubrir diferentes necesidades de Cáritas Valencia.

Y todo ello, dentro de un marco de Investigación Acción Participativa desde la iniciativa Utópika en la Universidad Politécnica de Valencia.

Estos y otros aspectos, serán desarrollados en el presente documento a través de siete grandes bloques. Empezamos ahora por el primero, en él se nos habla de cómo se ha llegado a constituir este proyecto.

Capítulo 1Constitución del proyecto

1.1. Antecedentes

El proyecto en el que se enmarca la realización del presente Trabajo Final de Carrera (en adelante TFC) tiene su origen en la iniciativa de Investigación Participativa en la UPV, UTÓPIKA. Utópika es una propuesta inspirada en otras iniciativas de ámbito eu-ropeo llamadas Science Shops (Tiendas de la Ciencia) que buscan responder a las de-mandas de la sociedad civil desarrollando estudios de viabilidad, de impacto ambien-tal, sondeos o asesorías, soluciones tecnológicas, etc.

Los objetivos generales marcados para la iniciativa UTÓPIKA son los siguientes:

1. Conectar la I+D universitaria con las necesidades e intereses de colectivos ciu-dadanos que no suelen tener este acceso por falta de recursos, contactos, etc., y promover la participación de estos colectivos en las actividades de investiga-ción.

2. Servir de herramienta para influir en la agenda universitaria de I+D, con una mayor orientación de la I+D hacia demandas de la sociedad,

3. Crear oportunidades de aprendizaje en los participantes del proceso de investi-gación: estudiantes, profesores y miembros de la organización social.

4. Acercar la enseñanza universitaria a las realidades sociales / locales.

El presente TFC tiene su origen en los trabajos realizados por UTÓPIKA y Cáritas Diocesana de Valencia para la puesta en marcha de un proyecto de investigación ac-ción participativa sobre la realidad social de la ciudad de Valencia.

Concretamente, el TFC plantea la creación de una solución tecnológica que permita a Cáritas Diocesana Valencia plasmar sobre unos “mapas de pobreza” todos los datos que presentan regularmente en su memoria anual.



Después de unos primeros contactos en los que Utópika y Cáritas definieron un primer esbozo del proyecto a desarrollar, Utópika publicó el posible proyecto en su página web www.utopika.upv.es presentándolo así a toda la comunidad universitaria a la espe-ra de que algún alumno o profesor se mostrara dispuesto a trabajar en él.

El alumno de Ingeniería en Geodesia y Cartografía Lorenzo Sicilia Torres, tras conocer la existencia de dicho proyecto, planteó la posibilidad de trabajar en el mismo como alumno investigador mediante la realización de su TFC, buscó el pertinente tutor (pro-fesor investigador) y, así, junto a Jesús Palomar Vázquez, inició el proceso para consti-tuirlo como tal.

1.2. Justificación

Son múltiples los beneficios que se pueden derivar de la utilización de la metodología investigación acción participativa en cualquier ámbito social. Su estructura flexible y de fácil adaptación al contexto, permite que las personas involucradas no se sientan ob-jetos, sino sujetos comprometidos con las soluciones que el momento les demanda.

Entre otros, podemos destacar los siguientes beneficios concretos:

1. Se puede aplicar en cualquier contexto, no importa el nivel socio-económico, educativo, edad, raza, etc. Lo importante del método es la decisión del grupo y el compromiso por la mejora; estos dos aspectos resultan muy motivadores para la puesta en marcha de cualquier plan de acción que busca cambios en su hacer para bienestar de todos.

2. Facilita la actualización continua de las aspiraciones de determinado grupo; no hay un final para este tipo de investigación. Cuando se satisfacen unas necesida-des o se resuelven los problemas, aparecen otras situaciones que ameritan ser atendidas, pero el grupo ya tiene las habilidades de creatividad, motivación y trabajo en equipo para abordarlas pro activamente. La metodología incluye una parte de acción de la que se aprende teóricamente para avanzar con las siguien-tes hipótesis

3. Permite la participación conjunta del colectivo, todos se sienten importantes y tomados en cuenta para la solución de los problemas. Se produce una democra-tización del conocimiento. Hay feedback con las personas "investigadas" y, éste, nutre la calidad del conocimiento creado.

En el caso concreto de este TFC, para Cáritas es fundamental tomarle el pulso a la rea-lidad y analizar los cambios que se están produciendo en nuestra sociedad en relación a la exclusión social y la pobreza. A partir de los datos que Cáritas genera, produce análi-


Capítulo: Constitución del proyecto

sis e informes que le ayudan a guiar la intervención futura en los distintos territorios y ámbitos de actuación en los que trabaja. Sus recursos humanos y técnicos son limita-dos, pero aún con estas dificultades, el tratamiento de sus datos, obtiene como resulta-do una serie de herramientas con las que puede seguir planificando su intervención. Este proyecto surge tras la necesidad de Cáritas de dar un paso más: dotar a sus datos de un soporte gráfico, de base cartográfica, más visual y accesible que facilite la com-prensión y la planificación de actividades y acciones.

Puesta en marcha la investigación participativa, el proyecto se enriqueció ampliando su alcance. Se detectaron nuevas necesidades de Cáritas que estaban en relación con la te-mática tratada y se decidió añadir al proyecto el desarrollo de un “Localizador de Re-cursos Sociales” en el ámbito territorial de Cáritas en el municipio de Valencia que, además, posibilitara la participación de otras entidades sociales que trabajan en el campo de la pobreza y la exclusión.

1.3. Descripción general

Se parte de la base de que el proyecto no quedará cerrado tras la finalización de este TFC. Permanecerá abierto para futuras mejoras y ampliaciones. La utilidad última del proyecto es poder llevar a cabo investigación social participativa.

Por el momento, el TFC ha consistido en una primera definición del proyecto global, delimitando también en qué partes del proyecto se ha trabajado con el TFC (desarrollo de dos aplicaciones web) y apuntando posibles vías de trabajo en el futuro. Por tanto, estas aplicaciones podrán ser mejoradas y ampliadas en futuros trabajos.

Las dos aplicaciones son:

• Generador de Mapas Sociales: aplicación web de análisis de datos sociales que permite generar informes de mapas temáticos asociados. Se concreta en un gestor de base de datos (de datos alfanuméricos y datos geográficos), de momento de los que maneja Cáritas, pero se buscará enriquecerlo en futuras ampliaciones con nuevos datos de otras entidades. Este gestor permite, para los campos diseñados inicialmente, editar los datos alfanuméricos existentes o añadir nuevos

• Localizador de Recursos Sociales: aplicación web en la cuál, indicando una di-rección, te facilita los recursos que le corresponden por zona (Cáritas Parroquial, Centro Municipal de Servicios Sociales), los más cercanos o los que se encuen-tran en un perímetro determinado. Los recursos están clasificados en categorías, de manera que el usuario puede indicar qué recursos localizar.



Es importante reseñar que el desarrollo de estas dos aplicaciones se ha llevado a cabo dentro del marco de investigación participativa donde han tomado parte activa todos los miembros del grupo: representantes de Cáritas, representantes de Utópika, técnicos de apoyo, profesor investigador y alumno investigador.

1.4. Requisitos que satisfacen las necesidades, deseos y expectativas de los interesados

Una parte importante en la constitución del proyecto, fue ver cuáles eran los requisitos de partida que satisfacían las necesidades, deseos y expectativas de los interesados. Consultadas todas las partes, se fijaron los siguientes:

1. Las herramientas han de permitir una gestión autónoma, para la mayoría de las tareas, por parte de las entidades que las administren, de momento Cáritas y Utópika.

2. Las herramientas han de quedar abiertas posibilitando futuras actualizaciones, ampliaciones, mejoras...

3. Los desarrollos realizados deben estar documentados para facilitar la realización de futuras actualizaciones.

4. Respecto a la cartografía de base, su actualización no ha de depender del pro-yecto y ha de ser detallada para todo el posible territorio: por ahora, la Diócesis de Valencia (más o menos equivalente al conjunto de la provincia de Valencia mas 60 municipios de Alicante)

5. El Localizador de Recursos Sociales ha de contar con un potente geocodificador que asegure grandes garantías de éxito para cualquier dirección dentro del terri-torio abarcado.

6. Las bases de datos, al menos en su parte alfanumérica, han de ser editables por los administradores.

7. Sería conveniente facilitar una herramienta para la introducción masiva de datos alfanuméricos (archivo xls, csv)

8. El sistema ha de permitir operaciones de análisis tipo SIG (punto en polígono, listado de puntos/polígonos cuya información asociada cumpla unas determina-das condiciones impuestas por la operación de análisis...)

9. Las dos herramientas han de permitir imprimir informes de los resultados. 10. La presentación del producto, ha de adaptarse a las características del usuario

mayoritario: usuario sin nociones informáticas y de edad avanzada (voluntaria-do de Cáritas).


Capítulo: Constitución del proyecto

1.5. Influencias de los interesados

En este apartado se detalla la influencia que cada uno de los interesados tiene sobre el proyecto:

• Cáritas: Determina la información que maneja la primera versión de la solución implementada. Valida la interfaz de usuario de la herramienta.

• Usuarios: Determinan el diseño de la interfaz de la herramienta. Validan el uso de la herramienta mediante las operaciones de consulta.

• Utópika: Revisa la metodología de desarrollo del proyecto. Ejerce la codirección del proyecto junto con el tutor del TFC.

• Miembros del equipo de desarrollo: El alumno investigador del TFC marca los límites del proyecto en base a sus conocimientos y capacidades.

1.6. Restricciones de partida, internas y externas

Las restricciones de partida ayudan a delimitar el alcance del proyecto y del TFC con el que se inicia. Las enumeramos a continuación:

1. Teniendo en cuenta los requisitos que satisfacen a los interesados (apartado 1.4.) y estudiadas otras opciones (OpenLayers con OpenStreetMap...) se opta por uti-lizar como base cartográfica la de Google Maps, sobre todo para el Localizador de Recursos Sociales. Para el Generador de Mapas de Pobreza de momento con-tamos con utilizar Google Maps, pero se estudiará mejor por si es factible utili-zar cartografías libres que no impongan licencias privativas (aunque sean gratui-tas)

2. Las delimitaciones territoriales con las que trabaja Cáritas (parroquias, arcipres-tazgos, vicarías, diócesis) no se corresponden normalmente con las delimitacio-nes administrativas (barrios, distritos, términos municipales, provincias,...)

3. Las delimitaciones territoriales de las parroquias están definidas oficialmente por una descripción literal en la fecha de constitución de cada parroquia, Esta información resulta desfasada en una gran mayoría de casos.

Para la ciudad de Valencia, a partir de estas descripciones, hace unos años se di-bujaron las delimitaciones sobre un plano callejero escala 1:8.000; este mapa es el que fundamentalmente se utilizará como referencia, aunque la ciudad también



ha experimentado numerosos cambios urbanísticos desde entonces, sobre todo en las zonas periféricas.

4. Los dos últimos puntos suponen que el trazado de muchas de las delimitaciones territoriales que necesita el proyecto no se encuentra en formato digital y ha de ser el propio proyecto el que lo genere. Por el tiempo que esto implica, con este TFC inicial, para el Localizador de Recursos Sociales, de momento nos limita-mos a las vicarías 1 y 2 (delimitaciones territoriales de Cáritas que se correspon-den con la ciudad de Valencia y algunas zonas del área metropolitana). Aún así, esta limitación se dejará abierta para que se pueda ir ampliando al resto de la Diócesis (más o menos la provincia de Valencia y 60 municipios de Alicante).

5. Por facilidad de conservación del sistema de referencia para Google Maps, se piensa utilizar Google Earth para dibujar los polígonos de delimitación de cada parroquia. La información vectorial que facilita Google Earth es limitada. No permite visualizar conjuntamente la localización de los números de policía ni vi-sualiza la delimitación de las manzanas ni la delimitación de los términos muni-cipales. Únicamente se visualizan los ejes de las vías urbanas, carreteras, algu-nos caminos o sendas... Por ello, sobre todo en vías urbanas de pequeño ancho, se pueden dar errores de ubicación de números de policía. Para minimizar los errores nos apoyaremos en la información vectorial del catastro, aunque no es la que utiliza Google para georeferenciar.


Capítulo 2Tecnologías involucradas

2.1. Entorno de desarrollo

Las aplicaciones web del presente TFC, no utilizan directamente ningún software SIG, pero sí manejan conceptos, algoritmos, estructuras de datos...

Por lo demás, el entorno de desarrollo, en cuanto a plataformas y lenguajes de progra-mación, es: html, CSS, JavaScript, PHP 5, MySQL 5, AJAX, Drupal 6.22 y la API de Google Maps (inicialmente en su versión 2 y, finalmente, en su versión actual 3).

A continuación pasamos a describirlas.

2.1.1. HTML

HTML (32), siglas de HyperText Markup Language (Lenguaje de Marcado de Hiper-texto), es el lenguaje de marcado predominante para la elaboración de páginas web. Es usado para describir la estructura y el contenido en forma de texto, así como para com-plementar el texto con objetos tales como imágenes. HTML se escribe en forma de eti-quetas, rodeadas por corchetes angulares (<,>). HTML también puede describir, hasta un cierto punto, la apariencia de un documento, y puede incluir un script (por ejemplo JavaScript), el cual puede afectar el comportamiento de navegadores web y otros pro-cesadores de HTML.

2.1.2. CSS

CSS (31), Hojas de Estilo en Cascada, viene del inglés Cascading Style Sheets, del que toma sus siglas. CSS es un lenguaje usado para definir la presentación de un documen-to estructurado escrito en HTML o XML (y por extensión en XHTML).



El W3C (World Wide Web Consortium) es el encargado de formular la especificación de las hojas de estilo que servirán de estándar para los navegadores.

La idea que se encuentra detrás del desarrollo de CSS, es separar la estructura de un documento de su presentación.

Por ejemplo, el elemento de HTML <h1> indica que un bloque de texto es un encabe-zamiento y que es más importante que un bloque etiquetado como <h2>. Versiones más antiguas de HTML permitían atributos extra dentro de la etiqueta abierta para dar-le formato (como el color o el tamaño de fuente). No obstante, cada etiqueta <h1> de-bía disponer de la información si se deseaba un diseño consistente para una página y, además, una persona que leía esa página con un navegador perdía totalmente el control sobre la visualización del texto.

Cuando se utiliza CSS, la etiqueta <h1> no debería proporcionar información sobre cómo será visualizado, solamente marca la estructura del documento. La información de estilo, separada en una hoja de estilo, especifica cómo se ha de mostrar <h1>: color, fuente, alineación del texto, tamaño...

La información de la hoja de estilo puede ser adjuntada como un documento separado o en el mismo documento HTML. En este último caso podrían definirse estilos genera-les en la cabecera del documento o en cada etiqueta particular mediante el atributo "style".

En nuestro caso, se utilizan fundamentalmente hojas de estilo externas almacenadas en un archivo diferente al archivo donde se almacena el código HTML de la página Web. Esta es la manera de programar más potente, porque separa completamente las reglas de formateo para la página HTML de la estructura básica de dicha página.

2.1.3. JavaScript

JavaScript (34) es un lenguaje de programación interpretado. Se define como orientado a objetos.

Se utiliza principalmente en su forma del lado del cliente (client-side), implementado como parte de un navegador web permitiendo mejoras en la interfaz de usuario y pági-nas web dinámicas, aunque también existe una forma de JavaScript del lado del servidor (Server-side JavaScript o SSJS). Su uso en aplicaciones externas a la web, por ejemplo en documentos PDF, aplicaciones de escritorio (widgets, ...) es también significativo.


Capítulo: Tecnologías involucradas

JavaScript se diseñó con una sintaxis similar al C, aunque adopta nombres y conven-ciones del lenguaje de programación Java. Sin embargo Java y JavaScript no están re-lacionados y tienen semánticas y propósitos diferentes.

Todos los navegadores modernos interpretan el código JavaScript integrado en las pá-ginas web. Para interactuar con una página web se provee al lenguaje JavaScript de una implementación del Document Object Model (DOM).

Tradicionalmente se venía utilizando en páginas web HTML para realizar operaciones y únicamente en el marco de la aplicación cliente, sin acceso a funciones del servidor. JavaScript se interpreta en el navegador, al mismo tiempo que las sentencias van des-cargándose junto con el código HTML.

2.1.4. API de Google Maps para JavaScript (versión 3)

Una API (33), Interfaz de Programación de Aplicaciones (del inglés Application Programming Interface) es el conjunto de funciones y procedimientos (o métodos, en la programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción.

Son usados generalmente en bibliotecas. Una API representa una interfaz de comunica-ción entre componentes de software. Se trata del conjunto de llamadas a ciertas biblio-tecas que ofrecen acceso a ciertos servicios desde los procesos y representa un método para conseguir abstracción en la programación, generalmente (aunque no necesaria-mente) entre los niveles o capas inferiores y los superiores del software. Uno de los principales propósitos de una API consiste en proporcionar un conjunto de funciones de uso general, por ejemplo, para dibujar ventanas o iconos en la pantalla. De esta for-ma, los programadores se benefician de las ventajas de la API haciendo uso de su fun-cionalidad, evitándose el trabajo de programar todo desde el principio. Las APIs asi-mismo son abstractas: el software que proporciona una cierta API generalmente es lla-mado la implementación de esa API.

En concreto, la API de Google Maps para JavaScript (17), en su versión más actual, versión 3 (en adelante API v3), permite insertar Google Maps en páginas web. Esta úl-tima versión está especialmente diseñada para proporcionar una mayor velocidad y que se pueda aplicar más fácilmente tanto a móviles como a las aplicaciones de navegador de escritorio tradicionales.

El API v3 proporciona diversas utilidades para manipular mapas (al estilo de la página http://maps.google.com) y para añadir contenido al mapa mediante diversos servicios, permitiendo crear sólidas aplicaciones de mapas en un sitio web.



La API v3 es un servicio gratuito disponible para cualquier sitio web que sea gratuito para el consumidor. Aspecto en el que encaja perfectamente el presente proyecto.

2.1.5. php

PHP (38) es un lenguaje de programación interpretado, diseñado originalmente para la creación de páginas web dinámicas. Es usado principalmente para la interpretación en el lado del servidor (server-side scripting) pero actualmente puede ser utilizado desde una interfaz de línea de comandos o en la creación de otros tipos de programas inclu-yendo aplicaciones con interfaz gráfica usando las bibliotecas Qt o GTK+.

En nuestro caso se utiliza para la interpretación en el lado del servidor, facilitando la generación de documentos xml tras consultas SQL a la base de datos.

PHP es un acrónimo recursivo que significa PHP Hypertext Pre-processor. Fue creado originalmente por Rasmus Lerdorf en 1994; sin embargo, la implementación principal de PHP es producida ahora por The PHP Group y sirve como el estándar de facto para PHP al no haber una especificación formal. Publicado bajo la PHP License, la Free Software Foundation considera esta licencia como software libre.

Puede ser desplegado en la mayoría de los servidores web y en casi todos los sistemas operativos y plataformas sin costo alguno. El lenguaje PHP se encuentra instalado en más de 20 millones de sitios web y en un millón de servidores, el número de sitios en PHP ha compartido algo de su preponderante presencia con otros nuevos lenguajes no tan poderosos desde agosto de 2005. Es también el módulo Apache más popular entre las computadoras que utilizan éste como servidor web.

El gran parecido que posee PHP con los lenguajes más comunes de programación es-tructurada, como C y Perl, permiten a la mayoría de los programadores crear aplicacio-nes complejas con una curva de aprendizaje muy corta. También les permite involu-crarse con aplicaciones de contenido dinámico sin tener que aprender todo un nuevo grupo de funciones.

Aunque todo en su diseño está orientado a facilitar la creación de sitios web, es posible crear aplicaciones con una interfaz gráfica para el usuario, utilizando la extensión PHP-Qt o PHP-GTK. También puede ser usado, desde la línea de comandos, de la misma manera como Perl o Python pueden hacerlo; a esta versión de PHP se la llama PHP-CLI (Command Line Interface).

Cuando el cliente hace una petición al servidor para que le envíe una página web, el servidor ejecuta el intérprete de PHP y éste procesa el script solicitado que generará el contenido de manera dinámica (por ejemplo, obteniendo información de una base de



datos). El resultado es enviado por el intérprete al servidor, quien a su vez se lo envía al cliente.

Mediante extensiones, es también posible la generación de archivos PDF, Flash, así como imágenes en diferentes formatos.

Permite la conexión a diferentes tipos de servidores de bases de datos tales como MySQL, PostgreSQL, Oracle, ODBC, DB2, Microsoft SQL Server, Firebird y SQLite. En nuestro caso utilizaremos MySQL.

2.1.6. MySQL

MySQL (37) es un sistema de gestión de bases de datos relacional, multihilo y multiu-suario con más de seis millones de instalaciones. MySQL AB (desde enero 2008 una subsidiaria de Sun Microsystems y ésta, a su vez, de Oracle Corporation desde abril 2009) desarrolla MySQL como software libre en un esquema de licenciamiento dual.

Por un lado se ofrece bajo la GNU GPL para cualquier uso compatible con esta licen-cia, pero para aquellas empresas que quieran incorporarlo en productos privativos de-ben comprar a la empresa una licencia específica que les permita este uso. Está desa-rrollado en su mayor parte en ANSI C.

Al contrario de proyectos como Apache, donde el software es desarrollado por una co-munidad pública y los derechos de autor del código están en poder del autor individual, MySQL es patrocinado por una empresa privada, que posee el copyright de la mayor parte del código.

Esto es lo que posibilita el esquema de licenciamiento anteriormente mencionado. Además de la venta de licencias privativas, la compañía ofrece soporte y servicios. Para sus operaciones contratan trabajadores alrededor de todo el mundo que colaboran vía Internet.

SQL (Lenguaje de Consulta Estructurado) fue comercializado por primera vez en 1981 por IBM, el cual fue presentado a ANSI y desde entonces ha sido considerado como un estándar para las bases de datos relacionales. Desde 1986, el estándar SQL ha apareci-do en diferentes versiones como por ejemplo: SQL:92, SQL:99, SQL:2003.

MySQL es una idea originaria de la empresa opensource MySQL AB. El objetivo que persigue esta empresa consiste en que MySQL cumpla el estándar SQL, pero sin sacri-ficar velocidad, fiabilidad o usabilidad.

El nombre de MySQL procede de la combinación de My, hija del cofundador Michael "Monty" Widenius, con el acrónimo SQL (según la documentación de la última versión



en inglés). Por otra parte, el directorio base y muchas de las bibliotecas usadas por los desarrolladores tienen el prefijo My.

MySQL es muy utilizado en aplicaciones web, como Drupal o phpBB, en plataformas (Linux / Windows – Apache – MySQL – PHP / Perl / Python), y por herramientas de seguimiento de errores como Bugzilla. Su popularidad como aplicación web está muy ligada a PHP, que a menudo aparece en combinación con MySQL. Es una base de da-tos muy rápida en la lectura cuando utiliza el motor no transaccional MyISAM, pero puede provocar problemas de integridad en entornos de alta concurrencia en la modifi-cación. En aplicaciones web hay baja concurrencia en la modificación de datos y en cambio el entorno es intensivo en lectura de datos, lo que hace a MySQL ideal para este tipo de aplicaciones.

2.1.7. AJAX

Ajax, (27) acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML), es una técnica de desarrollo web para crear aplicaciones interactivas o RIA (Rich Internet Applications). Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los usuarios mientras se mantiene la comunicación asíncrona con el ser-vidor en segundo plano. De esta forma, es posible realizar cambios sobre las páginas sin necesidad de recargarlas, lo que significa aumentar la interactividad, velocidad y usabilidad en las aplicaciones.

Ajax es una tecnología asíncrona, en el sentido de que los datos adicionales se requie-ren al servidor y se cargan en segundo plano sin interferir con la visualización ni el comportamiento de la página. JavaScript es el lenguaje interpretado en el que normalmente se efectúan las funciones de llamada de Ajax, mientras que el acceso a los datos se realiza mediante XMLHttpRequest, objeto disponible en los navegadores actuales. En cualquier caso, no es necesario que el contenido asíncrono esté formateado en XML, aunque en nuestro caso sí lo utilizamos de este modo.

Ajax es una técnica válida para múltiples plataformas y utilizable en muchos sistemas operativos y navegadores dado que está basado en estándares abiertos como JavaScript y Document Object Model (DOM).

2.1.8. Drupal

Drupal (29) es un sistema de gestión de contenido modular multipropósito y muy con-figurable que permite publicar artículos, imágenes, u otros archivos y servicios añadi-dos como foros, encuestas, votaciones, blogs y administración de usuarios y permisos. Drupal es un sistema dinámico: en lugar de almacenar sus contenidos en archivos está-



ticos en el sistema de ficheros del servidor de forma fija, el contenido textual de las pá-ginas y otras configuraciones son almacenados en una base de datos y se editan utili-zando un entorno Web.

Es un programa libre, con licencia GNU/GPL, escrito en PHP, desarrollado y manteni-do por una activa comunidad de usuarios. Destaca por la calidad de su código y de las páginas generadas, el respeto de los estándares de la web, y un énfasis especial en la usabilidad y consistencia de todo el sistema.

El diseño de Drupal es especialmente idóneo para construir y gestionar comunidades en Internet. No obstante, su flexibilidad y adaptabilidad, así como la gran cantidad de módulos adicionales disponibles, hace que sea adecuado para realizar muchos tipos di-ferentes de sitios web.

Nosotros lo hemos elegido para la gestión de la información alfanumérica a través de diferentes formularios de entrada y edición. También nos hemos decidido por drupal por su buena gestión de usuarios y permisos (ver apartado 4.9. pág. 131).

2.2. Herramientas de desarrollo

Estas han sido las herramientas de desarrollo utilizadas para la realización de las apli-caciones web. Todas ellas son de software libre a excepción de Google Earth:

• Linux: Distribución Ubuntu 10.04 como sistema operativo donde ejecutar el res-to de herramientas

• Google Earth 5.2: Para dibujar los diferentes polígonos territoriales

• Gedit 2.30.3: Editor de textos para desarrollar los códigos php, JavaScript, php, html...

• XAMPP 1.7.4: Servidor local independiente de plataforma que consiste princi-palmente en la base de datos MySQL, el servidor Web Apache y los intérpretes para lenguajes de script: PHP y Perl. El nombre proviene del acrónimo de X (para cualquier sistema operativo), Apache, MySQL, PHP, Perl.

• gvSIG 1.10: Para procesar información geográfica facilitada por el Ayuntamien-to de Valencia (barrios y distritos) y el ICV (límites de término municipal...)

• Día 0.97.1: Editor de gráficos para la realización de esquemas.

• OpenProj 1.4: Para la organización de tareas y realización de cronogramas...

• Gimp 2.6: Herramienta de edición gráfica para la creación de iconos, botones, imágenes web...

• Cloc 1.53: Contador de líneas de programación en diferentes lenguajes.



2.3. Equipo e instalaciones

2.3.1. Requisitos mínimos de software para el cliente

Para el acceso a la aplicación, se necesita disponer de un navegador web. Se recomien-da el uso de Mozilla Firefox como primera opción, y Chromium / Google Chrome como segunda, por ser ambos proyectos de software libre y por proporcionar una vi-sualización optimizada ya que respetan los estándares de la W3C. No obstante, el con-junto de navegadores soportados es el siguiente:

• Mozilla Firefox, versiones de la 3.5 a la 4

• Chromium y Google Chrome, versiones de la 6 a la 9

• Opera 10 y posterior

• Safari 5

• Internet Explorer 7 y 8

El tamaño mínimo de la pantalla se define en 1024x768.

2.3.2. Requisitos de software para el servidor

Para la instalación de la aplicación en el servidor, se definen los siguientes requisitos:

• MySQL 5

• Apache 2.2 con PHP 5 habilitado (mod_php)

Se recomienda la utilización del siguiente grupo de paquetes:

• Ubuntu Server 10.04 LTS

• MySQL 5.1 (5.1.41-3ubuntu12.7)

• PHP 5.3 (5.3.2-1ubuntu4.5)

• Apache 2.2 (2.2.14-5ubuntu8)


Capítulo 3Definición del proyecto

3.1. Contexto del proyecto

El desarrollo del presente TFC se enmarca dentro de un proyecto de investigación ac-ción participativa entre Utópika y Cáritas; y se realiza como conclusión de los estudios de Ingeniería en Geodesia y Cartografía del alumno Lorenzo Sicilia Torres en la E.T.S.I. Geodésica Cartográfica y Topográfica (en adelante ETSIGCT) de la UPV.

Parte de este trabajo se ha desarrollado bajo un convenio de prácticas en empresa o ins-titución entre la ETSIGCT y Cáritas Diocesana de Valencia. Por su particular significa-ción, a continuación explicamos los detalles más relevantes de este convenio.

3.1.1. Prácticas en empresa o institución

a) Fechas, horario, lugar de realización, tutores

Las prácticas se han desarrollado desde el 22 de diciembre de 2010 hasta el 25 de fe-brero de 2011. El tutor en la ETSIGCT ha sido Jesús Palomar y en la entidad (Cáritas Diocesana de Valencia), Nuria Baeza, responsable del Departamento de Análisis de la Realidad. La carga horaria semanal ha sido de 30 horas, repartidas en: 10 horas en la sede de Cáritas, 10 horas en la UPV y 10 horas de trabajo personal en casa.

b) Bolsa económica de apoyo al estudio

En este punto se ha dado una circunstancia que consideramos importante resaltar. Dado el carácter de este trabajo, se solicitó que la bolsa de ayuda al estudio no estuviera do-tada económicamente, siendo aceptada tal petición por la Dirección de la ETSIGCT. Se consideró oportuno realizar esta petición atendiendo al carácter particular del trabajo y acogiéndonos a lo que recoge la Normativa de la UPV sobre prácticas en empresas o instituciones en su artículo 48, punto 2º.



Añadiremos que dicha petición se efectuó acompañada de las razones que, desde cada una de las partes implicadas, se aportaron para justificarla.

Razones aportadas por UTÓPIKA

La iniciativa UTÓPIKA surge de un grupo de profesores/investigadores de la Universi-dad Politécnica de Valencia para poner en marcha, de forma no lucrativa, proyectos de investigación acción participativa en el seno de la UPV.

La realización de estos proyectos se lleva a cabo bajo la coordinación de los miembros de UTÓPIKA y cuenta con el trabajo desinteresado de asociaciones y organizaciones de la sociedad civil junto con profesores e investigadores y alumnos de la UPV. El tra-bajo realizado por los alumnos y alumnas se enmarca dentro de sus proyectos y traba-jos finales de carrera.

Los proyectos desarrollados suponen para los alumnos y alumnas una experiencia for-mativa enmarcada dentro de la Educación para el Desarrollo Sostenible. A través de ella, los alumnos y alumnas desarrollan los cinco tipos fundamentales de aprendizaje: aprender a saber, a prender a ser, aprender a vivir con otros, aprender a hacer y apren-der a transformarse uno mismo y a la sociedad. En términos de resultados de aprendi-zaje, este tipo de experiencias formativas pretenden alcanzar lo siguientes:

1. Pensamiento crítico. 2. Pensamiento complejo y sistémico. 3. Gestión del cambio. 4. Entender interrelaciones entre disciplinas. 5. Aplicar el aprendizaje a una variedad de contextos. 6. Toma de decisiones, incluyendo situaciones inciertas. 7. Actuar con responsabilidad local y globalmente. 8. Habilidad para identificar valores. 9. Actuar con respeto por y para otros. 10. Identificar interesados (stakeholders) y sus necesidades. 11. Participar en procesos de toma de decisiones democráticos. 12. Construcción y negociación de consensos.

Por todo esto, consideramos que este marco de trabajo, dentro del cual se desarrolla el TFC, supone una experiencia formativa de gran valor para el alumno.

Razones aportadas por Cáritas Diocesana de Valencia

Cáritas es una entidad sin ánimo de lucro que desarrolla sus actividades gracias a las aportaciones de sus socios, colaboradores y voluntarios, con el apoyo de entidades bancarias y de las administraciones estatales, autonómicas y municipales. Pero sobre


Capítulo: Definición del proyecto

todo, podemos llevar a cabo nuestra labor, gracias a los más de 3.000 voluntarios que, sin recibir remuneración económica alguna, prestan su tiempo, experiencia y conoci-mientos para ponerlos al servicio de los últimos y más desfavorecidos.

Todos los esfuerzos económicos se encaminan a cubrir las necesidades de los colecti-vos a los que atendemos. Nuestro volumen de usuarios y las necesidades que nos plan-tean, han aumentado exponencialmente en estos tres últimos años, dada la especial co-yuntura de crisis que padecemos. Así pues, nuestros recursos económicos escasean.

En beneficio de nuestros usuarios, buscamos mejorar y tecnificar cada vez más nues-tras herramientas de trabajo, buscando la efectividad y la excelencia, pero somos cons-cientes de que nuestros recursos económicos tienen otras prioridades.

Por esta razón, desde hace dos años, hemos centrado algunos esfuerzos en fomentar la Responsabilidad Social Corporativa (RSC) en las empresas y otros tipos de entidades. Fue en este nuevo contexto donde surge la posibilidad de trabajar con Utópika, que cu-riosamente, tiene una vocación similar de servicio a la sociedad a la que plantea la RSC, pero dentro del ámbito universitario.

El encuentro fue fácil y fructífero y los fines y objetivos que ambas entidades tenía-mos, encajaron perfectamente: un intercambio de necesidades y experiencias, mas la posibilidad de aprender y trabajar de otro modo.

Razones aportadas por el alumno

Como alumno, considero que la realización del TFC dentro de un contexto de investi-gación participativa y en un marco de colaboración educativa con prácticas en empresa o institución, supone un complemento perfecto para la finalización de mis estudios de Ingeniería en Geodesia y Cartografía.

Para mí, supone una gran oportunidad de aprendizaje y de poner al servicio de la socie-dad los conocimientos que he ido, y estoy, adquiriendo en la ETSIGCT.

Todos los beneficios educativos y académicos que encuentro con estas prácticas van mucho más allá de la aportación económica que pudiera recibir. Es más, personalmente deseo que no haya dotación económica en coherencia con las características del trabajo y el espacio donde se desarrolla.



3.1.2. Propiedad intelectual e industrial del trabajo

Los trabajos generados en el marco de los proyectos de in-vestigación acción participativa desarrollados por UTÓ-PIKA, como el presente, son publicados mediante licencia

Creative Commons. Las condiciones generales de la misma son:

Reconocimiento (Attribution): En cualquier explotación de la obra autorizada por la licencia hará falta reconocer la autoría.

No Comercial (Non commercial): La explotación de la obra queda limitada a usos no comerciales.

Compartir Igual (Share alike): La explotación autorizada incluye la creación de obras derivadas siempre que mantengan la misma licencia al ser divulgadas.

Puede consultarse una explicación detallada de la licencia, así como el texto legal completo en las siguientes direcciones web:

http://creativecommons.org/licenses/by-nc-sa/3.0/es/

http://creativecommons.org/licenses/by-nc-sa/3.0/es/legalcode.es

3.2. Dependencias del proyecto

Enumeramos aquí todas las dependencias que condicionan el desarrollo del proyecto:

1. Limitaciones de Google Maps 2. Datos de Cáritas (estructura, formato, calidad...) 3. Datos de otras entidades.4. Configuración de los servidores de la UPV donde van a estar alojadas las herra-

mientas. Las características del servicio de alojamiento avanzado de la UPV a tener en cuenta en el marco de este trabajo son las siguientes:

• Lenguajes soportados:

• Bases de Datos: se permite trabajar con bases de datos MySQL y SQLServer. Pudiendo utilizar para ello entornos de administración web para bases de datos: ASP.NET Enterprise Manager para SQLServer y phpMyAdmin para MySQL.

• Aplicaciones Java.

• Cifrado SSL.


http://creativecommons.org/licenses/by-nc-sa/3.0/es/legalcode.es

http://creativecommons.org/licenses/by-nc-sa/3.0/es/


3.3. Objetivos del proyecto

A continuación de detallan los objetivos generales del proyecto.

3.3.1. Para Utópika

Los objetivos para Utópika son los siguientes:

1. Consolidar una metodología de trabajo basada en la Investigación Acción Parti-cipativa.

2. Elaborar un conjunto de herramientas TIC (Tecnología de Información y Comu-nicación) que faciliten la publicación y consulta de información relativa a la rea-lidad social valenciana.

3. Disponer de un prototipo funcional que permita ampliar el conjunto de organi-zaciones no gubernamentales que pueden aportar información.

4. Concretar proyectos de Investigación Acción Participativa que hagan uso exten-sivo de la información almacenada con la participación de las organizaciones y comunidades involucradas.

5. Aportar a los agentes sociales e investigadores las aplicaciones desarrolladas. Para ello se publicarán con licencias Creative Commons.

3.3.2. Para Cáritas

Los objetivos para Cáritas son los siguientes:

1. Disminuir el tiempo de búsqueda de información acerca de la localización del punto de atención (Cáritas Parroquial) correspondiente por domicilio.

2. Al rentabilizar mejor el tiempo, aumentar el número de personas atendidas en el mismo número de horas de atención.

3. Disponer de una información actualizada que oriente mejor la intervención con las personas y que les evite traslados y visitas innecesarias.

4. Poder plantear intervenciones sociales más globales al conocer el resto de recur-sos que existen en el mismo territorio de intervención.

5. Favorecer el trabajo en red y coordinar acciones para conseguir intervenciones sociales más eficaces y rentables (mejorar la gestión de los recursos)

6. Analizar los datos de pobreza y exclusión generados por Cáritas y hacer estu-dios territoriales como base a posteriores intervenciones.

7. Poder realizar acciones de denuncia social tras el análisis geográfico de los da-tos.



3.4. Especificación de la aplicación

3.4.1. Grupos/Segmentos de usuarios

Los Grupos/Segmentos de usuarios a los que van destinadas las herramientas son:

• Utópika: Administrador técnico

Conocimientos informáticos avanzados.

• Voluntarios de la Acogida en Cáritas Diocesana de Valencia

Entendemos por “Acogida”, el servicio de primera atención que se ofrece a las personas en situación de exclusión y que acuden a las instalaciones que disponen las parroquias para los grupos de voluntarios de Cáritas Diocesana. En el conjun-to de la Diócesis de Valencia son 401 puntos de atención y sólo en la ciudad de Valencia son más de 100 las parroquias que dispensan este servicio. El número total de voluntarios es de 3.531. El 36% con edades superiores a 65 años y un 38% más en la franja de 31 a 50. Por sexos encontramos que el 78% son muje-res. Así pues, el perfil mayoritario son mujeres de edad avanzada con conoci-mientos informáticos rudimentarios o nulos.

• Departamento de Análisis de la Realidad en Cáritas Diocesana

Nuria Baeza. Conocimientos informáticos: office e Internet a nivel usuario.

• Trabajadores de los Programas De Acción Social de Cáritas Diocesana

85 personas con conocimientos informáticos a nivel usuario

• Público en general

Se suponen, como mínimo, conocimientos básicos de utilización de Internet.

3.4.2. Objetivos

Se plantean para cada uno de los Grupos/Segmentos de usuarios:

• Utópika: Administrador técnico

1. Diseñar un proyecto que permita ser ampliable y mejorable más allá de los lí-mites con que se inicia mediante el presente TFC.

2. Dotar de una herramienta de análisis con base cartográfica a las entidades de acción social que trabajan contra la pobreza en Valencia.

3. Facilitar la presentación conjunta de todos los recursos sociales disponibles en Valencia, tanto a los usuarios potenciales del público en general como a las diferentes entidades que pueden atenderles.

4. Aportar, a los agentes sociales de la sociedad valenciana, herramientas que ayuden a la investigación-acción social participativa.

5. Poder gestionar las aplicaciones en su totalidad.



• Voluntarios de Cáritas Diocesana de Valencia

6. Mejorar la atención a los usuarios que acuden a la sede de Cáritas o a las pa-rroquias en busca de ayuda, optimizando el tiempo de atención y proporcio-nando información más precisa y completa de los recursos disponibles.

7. Automatizar el proceso por el cual se facilita al usuario la localización e in-formación detallada de la Cáritas Parroquial que le corresponde por zona, con el objetivo de ofrecerle allí una atención más cercana y personalizada.

• Departamento de Análisis de la Realidad en Cáritas Diocesana

8. Disponer de una herramienta que facilite el análisis de la realidad a partir de los datos que se recogen anualmente de las parroquias, enriquecidos con otras posibles fuentes de información (ayuntamiento, censo...) explotándolos geográficamente desde una base cartográfica y con las delimitaciones admi-nistrativas propias (parroquias, arciprestazgos, vicarías, diócesis) y externas (áreas de Servicios Sociales del municipio de Valencia, términos municipa-les, comarcas...)

9. Poder incluir, en la memoria anual de Cáritas y en los informes que se reali-zan a otras secciones de Cáritas, mapas temáticos que ilustren los resultados de los análisis presentados.

10. Administrar todos los datos alfanuméricos y los polígonos territoriales en la medida que sea posible.

• Trabajadores de los Programas de Acción Social de Cáritas Diocesana de Valencia

11. Mejorar la atención a los usuarios que acuden en busca de ayuda, optimizan-do el tiempo de atención y proporcionando información más precisa y com-pleta de los recursos más y menos próximos disponibles.

12. Mejorar la coordinación con otros recursos inscritos en las mismas zonas de actuación.

13. Potenciar el trabajo en red en los mismos territorios logrando una incidencia local más profunda.

• Público en general

14. Disponer de una página web en la que poder encontrar, de manera conjunta, todos los recursos sociales disponibles en Valencia.

15. Mejorar el conocimiento de las realidades locales de pobreza y exclusión me-diante diferentes datos y mapas temáticos.



3.4.3. Contenidos y funcionalidades

A continuación, en la tabla 1, se detallan los contenidos y funcionalidades de las apli-caciones, viendo a la vez qué objetivos del apartado anterior (3.4.2.) vienen a cubrir.

Objetivos

Contenidos y funcionalidades 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Visualización y edición de todos los datos y de la estructura interna de la aplicación.

x

Visualización y edición de todos los datos alfanuméricos y los listados de coordenadas de cada polígono.

x

Adición y edición de datos alfanuméricos y geográficos (localización puntual) de recursos sociales de las mismas áreas de actuación.

x x

Visualización de los datos alfanuméricos correspondientes a los recursos sociales a través del Localizador.

x x x x x x x

Visualización, edición y adición de datos alfanuméricos y geográficos y operaciones de análisis con ellos generando informes y mapas temáticos asociados.

x x x

Visualización, edición y adición de datos alfanuméricos y operaciones de análisis con ellos y con los datos geográficos generando informes y mapas temáticos asociados.

x x x x

Tabla 1. Contenidos y funcionalidades


Capítulo 4Ejecución del proyecto

4.1. Metodología de trabajo

4.1.1. Investigación-Acción Participativa

El trabajo se ha desarrollado simultáneamente desde Utópika y desde Cáritas de una forma coordinada siguiendo la metodología de Investigación–Acción Participativa, (IAP) que asegura una continua relación entre todas las partes de forma que el produc-to final está siendo evaluado y mejorado continuamente, ya que todas las partes (Socie-dad, Universidad y Utópika) forman parte activa del proceso.

A lo largo de varios meses hemos trabajado conjuntamente. Cáritas ha provisto los da-tos necesarios para la estructuración de las demarcaciones, que casualmente en este año 2010 sufrieron una remodelación y reestructuración importantes, se ha participado en las sucesivas pruebas y mejoras de la aplicación, en la subsanación de errores, me-joras en el diseño, adaptabilidad de la herramienta… Por su parte, la UPV desde Utó-pika y el profesor investigador (tutor académico), ha desarrollado todo el soporte aca-démico necesario para la validación del TFC, las soluciones técnicas y los conocimien-tos necesarios para acompañar al alumno en la resolución de los obstáculos, inciden-cias y dificultades que el desarrollo del trabajo ha tenido. Y el alumno ha diseñado, creado, moldeado, depurado y perfeccionado ambas herramientas hasta adaptarlas jus-tamente a las necesidades planteadas.

Durante este tiempo se han mantenido diferentes reuniones de grupo y se ha contado con una fluida comunicación a través de distintos medios: espacio de trabajo virtual con documentos de trabajo, lista de correo de grupo, teléfono, mensajes de correo elec-trónico personales y encuentros bilaterales. Asimismo, se ha participado en dos cursos sobre IAP que ha organizado Utópika en el Centro de Formación Permanente (CFP).



4.1.2. Planificación temporal

La planificación temporal quizá ha sido uno de los puntos débiles del proyecto.

Hubo una primera fase de toma de contacto con el contenido del proyecto que se em-prendía: estudio de las diferentes posibilidades técnicas, de los lenguajes y plataformas a utilizar...

Tras esta primera fase, nos propusimos hacer una previsión de tareas a desempeñar con su estimación temporal. Para ello, nos ayudamos del software Open Proj (ver fig. 1).

Aunque han sido varias la estimaciones y revisiones que se han ido haciendo de la pla-nificación temporal inicial, ha sido complicado acertar en sus valoraciones. Pensamos que una buena parte de los motivos está en que la mayoría de los lenguajes y platafor-mas utilizadas han sido nuevas para el alumno y, como consecuencia de ello, la estima-ción del tiempo de aprendizaje ha sido muy difícil de valorar.

Por otro lado, ha habido un seguimiento continuo de la planificación temporal median-te reuniones del grupo de trabajo: miembros de Utópika, Cáritas y alumno.

Dada la dificultad en la estimación del tiempo de realización, un punto positivo en la organización del trabajo ha sido el ir marcando diferentes metas. Así, se ha posibilitado ir cerrando bloques del proyecto que podían funcionar autónomamente. De este modo, si se decidía concluir el TFC en un punto dado, el trabajo realizado hasta entonces ya contaba con entidad y autonomía propias. Los bloques han sido:

1. Localizador de Recursos2. Generador de Mapas3. Administrador de contenido con Drupal


Figura 1. Planificación temporal con OpenProj

Capítulo: Ejecución del proyecto

4.2. Consideraciones previas

Como indicábamos en el punto 2.1, para la implementación de las aplicaciones desa-rrolladas se han utilizado diferentes plataformas y lenguajes de programación: JavaScript, PHP 5, MySQL 5, AJAX y la API v3 de Google Maps.

En la siguiente tabla se muestra un resumen de la envergadura de las aplicaciones de-sarrolladas, en cuanto a número de archivos y líneas de programación escritas:

Lenguaje nº de archivosLíneas en

blancoLineas de

comentariosLíneas de

código

JavaScript 59 891 1838 4487

HTML 2 385 69 1740

CSS 3 148 86 955

PHP 4 128 39 794

Totales: 68 1552 2032 7976

Tabla 2. Número de archivos y de líneas de código implementado en cada lenguaje

A la hora de la implementación en los diferentes lenguajes se han tenido en cuenta dos consideraciones previas que han condicionado el trabajo en este sentido:

• En cuanto a su estructuración y comentarios : Dado que las aplicaciones desarro-lladas en este TFC suponen el punto de arranque de un proyecto más amplio que no queda cerrado, hemos considerado importante estructurar el código de la ma-nera más inteligible posible, utilizando múltiples funciones de JavaScript. En el mismo sentido, también considerábamos necesario incluir suficientes comenta-rios en el código, explicando las acciones pertinentes y dotando de encabezados a cada función o conjunto de funciones importantes.

• En cuanto a la optimización : Buscando un mejor funcionamiento, mayor rapidez de proceso y un mantenimiento más sencillo del código, se ha tenido especial cuidado en optimizar el código creando, en el caso de JavaScript, funciones de instrucciones que se repetían en diferentes puntos. Asimismo, también en JavaScript, se ha cuidado la utilización de las variables imprescindibles, pensan-do cuáles debían ser locales en cada función y cuáles globales a toda la aplica-ción.

A continuación mostramos un ejemplo donde apreciar parte de lo descrito. Se trata de la función JavaScript que sirve para añadir un marcador al mapa simboli-



zado con la imagen y sombra dadas, en el que, al hacer clic en él, se abre una ventana de información con el mensaje de texto html facilitado.// *********************************************************************// **************** Función crearMiMarca *************************// *********************************************************************// // Descripción: Crea un marcador y abre globo con clic en él// Llamada por:// - función load()// - funciones descarga_prqs(), descarga_cmssv(),// descarga cintra() y descarga_arropa()// - función auxMarca(...)// - función iniciaLocalizacion()// Invoca a:// nada// Recibe:// - punto : objeto punto (en el que situará¡ el marcador)// - html : string con el texto a mostrar en el globo de // información// - imgIcon : imagen con la que estará representado el marcador// - sombraIcon : sombra de la imagen con la que estará // representado el marcador// Devuelve:// un marcador // Variables locales:// - marcador// Variables globales:// - map// - centro// - infoGlobo// - Globo

function crearMiMarca(punto,html,imgIcon,sombraIcon) { // Crea y dibuja la marca var marcador = new google.maps.Marker({ map: map, position: punto, icon: imgIcon, shadow: sombraIcon }); // Abre globo al hacer clic en ella google.maps.event.addListener(marcador, "click", function() { centro = map.getCenter(); infoGlobo.setContent(html); infoGlobo.open(map, marcador); Globo = true; }); return marcador;}//************* fin función crearMiMarca *******************************

La estructuración del código también se ha plasmado a nivel de lenguajes usados y aplicaciones implementadas. Así, en el servidor encontramos estos directorios:

1. estilos : para las hojas de estilos css.2. php : para los scripts php3. src : para los scripts JavaScript, con las funciones comunes a ambas aplicacio-

nes y las propias de cada una divididas en subdirectorios

Con la opción “Ver código fuente” disponible en cualquier navegador, se puede ver todo el código escrito en html, JavaScript y css. El php lo facilitamos en los anexos.



4.3. Modelo funcional general de las aplicaciones

En este punto, describiremos a grandes rasgos la lógica de funcionamiento de nuestras dos aplicaciones. Para ello, citaremos los diferentes lenguajes de programación utiliza-dos y el sistema de bases de datos empleado viendo las relaciones entre ellos.

El esquema general puede resumirse así:

• Las aplicaciones web, en cuanto a estructura y presentación gráfica están cons-truidas con html y CSS.

• Los datos están almacenados en una base de datos MySQL a los que se accede mediante php con consultas SQL; los resultados devueltos en estas consultas se estructuran, también con php, en un documento XML.

• Finalmente, los datos contenidos en el XML son leídos mediante JavaScript y al-macenados en el lado del cliente.

• Es con estos datos almacenados en el lado cliente con los que después trabajan las funciones implementadas con JavaScript tomando como base la API v3.

Todo esto se puede apreciar gráficamente en el siguiente esquema (fig. 2).


Figura 2. Esquema del modelo funcional general de las aplicaciones

Lad

o C

lient

e

Página web (html + CSS)Formularios que activan funciones javascript:

botones, listas desplegables,campos de entrada, casillas de selección

Funciones js de mapaInteractúan con la ventanade mapa de Google Maps

dibujando elementos,modificando zooms,

mostrando globosde información...

Funciones dedocumento e informe

Actualizan el estado de loselementos visibles en la web

y generan informesde la información mostrada.

Funciones js dellamada a los php

Llaman a scripts php,y almacenan los datosdevueltos en variables

JavaScript

Lad

o Se

rvid

or

Base de datos MySQLCon información estructurada

en diferentes tablas

Interprete phpRealiza la consulta

demandada a la base de datosy construye un documento XML

con la información devueltade manera estructurada


4.4. Información geográfica

Además de la base cartográfica que aportan los mapas de Google, nuestras aplicacio-nes utilizan información geográfica propia que hemos tenido que generar y que es re-presentada con elementos poligonales y elementos puntuales.

En la tabla 3 podemos apreciar los diferentes tipos de información geográfica, clasifi-cados según son de tipo polígono o de tipo puntual. Además, se indica en cuál de las dos aplicaciones desarrolladas se utiliza.

Localizador de Recursos Sociales

Generador de Mapas Sociales

Elementos poligonales

Demarcaciones de parroquia x x

Áreas de Servicios Sociales del Ayuntamiento. de Valencia x

Demarcaciones de arciprestazgo x

Demarcaciones de vicaría x

Demarcaciones de comarca x

Elementos puntuales

Punto de atención de Cáritas x

Centro Municipal de Servicios Sociales del Ayto. de Valencia x

Contenedor de recogida de ropa de la Fundación INTRA (Cáritas) x

Tienda de ropa @rropa de la Fundación INTRA (Cáritas) x

Otros recursos sociales x

Tabla 3. Información geográfica propia

Antes de describir cada una de ellas, es importante conocer cómo estructura geográfi-camente Cáritas el territorio en el que trabaja. Esa misma estructuración, en parte, es con la que también trabajarán las dos aplicaciones hasta ahora desarrolladas.

La totalidad del territorio es conocido como Diócesis de Valencia y está organizada en 8 vicarías, 34 arciprestazgos y 651 parroquias. La unidad mínima territorial es la parro-quia; varias parroquias componen un arciprestazgo, varios arciprestazgos una vicaria, y la totalidad de las vicarías configuran la Diócesis al completo.

La Diócesis de Valencia comprende 327 municipios: 264 de la provincia de Valencia (toda la provincia excepto el municipio de Gátova, recientemente incorporado a la pro-



vincia de Valencia desde la de Castellón de la Plana, y que continúa siendo Diócesis de Segorbe-Castellón); y 63 de la provincia de Alicante.

Es necesario resaltar, como ya comentábamos en el apartado 1.6., en su punto 2. (pág. 17), que en multitud de ocasiones estas demarcaciones territoriales utilizadas por Cári-tas no se corresponden con ninguna demarcación oficial de las administraciones públi-cas. Este hecho supone que la generación digital de las demarcaciones implica un gran trabajo. Por este motivo, en el presente TFC hemos limitado la generación de algunas entidades, en concreto la de su unidad mínima territorial (la parroquia), tanto en su de-marcación como en su localización puntual. A continuación, en su descripción, aporta-mos más detalles de esta limitación que nos hemos fijado.

Pasamos ahora a describir cada uno de los tipos de información geográfica propia:

1. Demarcaciones de parroquia . Para Cáritas, la parroquia es la unidad mínima de representación poligonal. Como apuntábamos antes, en la Diócesis de Valencia existen 651 parroquias repartidas en 327 municipios. Sólo la ciudad de Valencia y parte de su área metropolitana, territorio que comprenden las vicarías 1 y 2, ya cuenta con 118 parroquias. Fuera de estas dos vicarías, en el mejor de los casos, algunas de las 533 parroquias restantes coinciden con algunos de los otros 326 términos municipales. Por este motivo, en esta primera fase del proyecto que comprende el TFC, nos hemos limitado a dibujar las 118 demarcaciones parro-quiales de las dos primeras vicarías que, por otro lado, eran las que, de cara al Localizador, más interesaban a Cáritas. Queda pendiente pues, para futuras fases, dibujar las 533 restantes, de las cuales, al menos 207 habrá que dibujar prácticamente sin apoyos de otros límites oficiales disponibles como el de los términos municipales.


Figura 3. Demarcaciones parroquiales de las Vicarías 1 y 2 (a falta de los poblados marítimos del sur)


2. Áreas de Servicios Sociales del Ayuntamiento de Valencia . Otra información importante para el Localizador, es el Centro Municipal se Servicios Sociales co-rrespondiente a un determinado domicilio. El ayuntamiento de Valencia tiene di-vidido su término municipal en 11 áreas de Servicios Sociales que se pueden ver en la figura 4.

3. Demarcaciones de arciprestazgo . Estas demarcaciones se utilizan en el Gene-rador de Mapas. Un arciprestazgo está compuesto por varias parroquias. En la Diócesis de Valencia hay 34. Los 9 primeros se corresponden con las vicarías 1 y 2 (fig. 6), es decir con la ciudad de Valencia y parte del área metropolitana.


Figura 4. Áreas de Servicios Sociales del Ayuntamiento de Valencia (a falta de algunos poblados del norte y del sur)

Figura 5. Demarcaciones de los 25 Arciprestazgos de las

Vicarías 3 a 8 de la Diócesis

Figura 6. Demarcaciones de los 9 Arciprestazgos de las Vicarías 1 y

2 de la Diócesis


4. Demarcaciones de vicaría . Varios arciprestazgos componen una vicaría. Los 34 arciprestazgos de la Diócesis de Valencia están estructurados en 8 vicarías (ver fig. 7).

5. Demarcaciones de comarca . Estas son las únicas demarcaciones oficiales en las Administraciones Públicas que de momento utilizamos. Se trata de 33 comar-cas, de las cuales 29 están presentes con su demarcación completa y pertenecen a la provincia de Valencia. De las 4 restantes, correspondientes a los municipios de la provincia de Alicante pertenecientes a la Diócesis, 2 (Alt Vinalopó y L'Al-coià) están incluidas sólo parcialmente (ver fig. 8).

6. Puntos de atención de Cáritas . Se trata de la localización puntual de cada uno de los 119 puntos de atención que se han incluido en el Localizador; 118 se corres-ponden con parroquias; el que resta, es el punto de atención en la sede de Cári-tas Diocesana. Los de las parroquias están circunscritos al territorio de su de-marcación.

7. Centros Municipales de Servicios Sociales del Ayuntamiento de Valencia . Loca-lización puntual de cada uno de los 13 centros de atención de los Servicios So-


Figura 7. Demarcaciones de las 8 Vicarías de la Diócesis

Figura 8. Demarcaciones de las 33 Comarcas presentes en

la Diócesis


ciales del Ayuntamiento de Valencia; 11 de ellos se circunscriben a las corres-pondientes áreas de Servicios Sociales descritas en el punto 2. de este mismo apartado; los otros 2, son respectivamente: la sede de la Regidoría de Benestar y el C.A.S.T. (Centro Municipal de Atención Social a Personas Sin Techo).

8. Contenedores de recogida de ropa de la Fundación INTRA (Cáritas) . Localiza-ción puntual de los 143 contenedores de recogida de ropa que tiene repartidos la Fundación INTRA de Cáritas por toda la Diócesis.

9. Tiendas de ropa @rropa de la Fundación INTRA (Cáritas) . Localización puntual de las 11 tiendas de inserción sociolaboral con las que cuenta la Fundación IN-TRA de Cáritas en toda la Diócesis.

10. Otros recursos sociales . Localización puntual de otros recursos sociales, clasifi-cados según las categorías que utiliza el ayuntamiento de Valencia. Aunque el soporte está disponible, de momento sólo se han incluido dos recursos de prueba en este apartado. La intención es que las diferentes entidades que ofrecen estos recursos se impliquen en este proyecto facilitando sus datos y manteniéndolos actualizados. Se plantea de este modo porque se piensa que es la mejor manera de favorecer desde esta herramienta el trabajo en red. Las categorías utilizadas por el ayuntamiento son:

• Adicciones

• Cooperación internacional

• Discapacidad

• Familia, menor y adopciones

• Juventud

• Mayores

• Migrantes

• Minorías étnicas

• Mujer

• Presos y ex-reclusos

• Sin techo

• Enfermedad Mental

4.4.1. Fuentes de información geográfica

Para la generación de la información geográfica propia, se ha contando con diferentes fuentes cartográficas, una buena parte de ellas en formato gráfico analógico. Incluso una fuente, para las demarcaciones de parroquia, ha sido de tipo textual (descripción literal).

La facilitación de las distintas fuentes ha corrido por parte de diferentes proveedores:

• Cáritas Diocesana : fuentes en formato analógico.

• Instituto Cartográfico Valenciano (ICV) : fuentes en formato digital shp.

• Ayuntamiento de Valencia : fuentes en formato digital shp.



a) Cáritas Diocesana

Cáritas ha aportado diferentes fuentes, sobre todo encaminadas a la definición de las demarcaciones de parroquia, pero también una con objeto de delimitar las áreas de Servicios Sociales del ayuntamiento de Valencia. Pasamos a describirlas:

Mapa en papel con demarcaciones parroquiales de la ciudad de Valencia:

Mapa escala 1:8.000 publicado por la Editorial Pamias como Guía Urbana de Códigos Postales de la ciudad de Valencia. Se desconoce el año de edición, pero presumible-mente es anterior al año 2.000 ya que se puede observar cómo en muchas zonas de la ciudad se ha producido una gran modificación urbanística.

En dicho mapa, se encuentran deslindadas a mano las demarcaciones de las parroquias tal y cómo se encontraban estructuradas en el momento en que se dibujaron. Hay que hacer notar que, desde entonces, bastantes de estas parroquias han sufrido fusiones o cambios en sus límites, así como que faltaban algunas parroquias total o parcialmente por estar ubicadas en extrarradios no presentes en el mapa.

El mapa ha sido facilitado en fotocopia en papel a su misma escala y también escanea-do en diferentes formatos: jpeg y pdf (ver fig. 9).


Figura 9. Mapa analógico 1:8.000 con demarcaciones parroquiales de la ciudad de Valencia


Informe de límites parroquiales:

Informe impreso de cada parroquia donde se hace constar una descripción literal de los límites de su demarcación. Muchas de estas descripciones son del año de erección; he-cho que dificulta su interpretación por citar calles, caminos, acequias o lindes ya ine-xistentes. En el mejor de los casos hay añadidas actualizaciones posteriores (fig. 10).

Tríptico de Recursos Sociales adscritos a la Regidoría de Benestar Social:

Este tríptico cuenta con un mapa en el que se pueden apreciar las distintas áreas de Servicios Sociales del ayuntamiento de Valencia (ver fig. 11).


Figura 10. Ejemplo de Informe de Límites Parroquiales

Figura 11. Mapa con áreas de Servicios Sociales en un tríptico de la Regidoria de Benestar


b) Instituto Cartográfico Valenciano (ICV)

Del ICV hemos obtenidos los shapes con los límites administrativos correspondientes a los términos municipales de toda la Comunidad Valenciana. La información se co-rresponde con la contenida en la serie CV300.

La serie cartográfica CV300 (20), es el mapa que abarca la totalidad de la Comunidad Valenciana. Ha sido confeccionado por generalización de la cartografía de la serie CV10, actualizando las diferentes capas o temáticas, como vías de comunicación a par-tir de ortofotomapas de vuelos posteriores. La toponimia es la oficial en el año 2002.

Partiendo de este mapa topográfico, completan la serie mapas temáticos de cuencas hi-drográficas, demográfico, político, sombras y red de vértices geodésicos de 4º orden.

Los shapes de los que disponemos nosotros contienen datos de las informaciones plas-madas en los mapas político y demográfico.

Los shapes están en un CD-rom de Productos Digitales del ICV y vienen clasificados por provincias y por códigos postales (ver fig. 12).

• Escala nominal: 1/300.000

• Georeferenciación: UTM, HUSO 30, ED50


Figura 12. Shapes de límites administrativos del CV300 mostrados en gvSIG


c) Ayuntamiento de Valencia

El ayuntamiento ha facilitado distintos shapes con las delimitaciones de barrios y dis-tritos del municipio.

No nos ha sido indicada ni su escala ni su georeferenciación. Hemos supuesto que la escala es de más detalle que la del CV300; entendemos lógica esta suposición por tra-tarse de cartografía municipal y, a su vez, parece corroborada al observar mayor grado de definición en los deslindes. También hemos supuesto que la georeferenciación es la misma que en la serie CV300 (UTM, HUSO 30, ED50), funcionando bien en su inte-gración conjunta.

Estas shapes (fig. 13), las hemos utilizado sobre todo para delimitar las demarcaciones parroquiales y las áreas de Servicios Sociales de los extrarradios y zonas limítrofes del término municipal no presentes en nuestras fuentes analógicas.

d) Respecto a la localización de elementos puntuales

Por último, decir que las coordenadas de localización de los elementos puntuales, no han sido facilitadas desde ninguna fuente y se han obtenido mediante el servicio de geocodificación de la API v3 a partir de las direcciones de las mismas: nombre de la calle o vía, número de policía y población.


Figura 13. Shapes de barrios y distritos del municipio de Valencia suministrados por su Ayuntamiento


4.4.2. Representación de información geográfica

Los elementos poligonales son creados mediante la clase Polygon de la API v3, mien-tras que los elementos puntuales se construyen utilizando la clase Marker.

Es importante resaltar que Google Maps utiliza WGS84 como sistema de georeferen-ciación. Utiliza un par de coordenadas (latitud y longitud) para la determinación de cada punto, por ejemplo la localización de un marcador construido con la clase Marker. Y usa listados de estos pares de coordenadas para la determinación de formas poligonales construidas mediante la clase Polygon.

a) Elementos puntuales con la clase Marker

De las distintas propiedades con las que se puede configurar un marcador, nosotros uti-lizamos las 4 siguientes:

• map : mapa en el que se va a mostrar el marcador,

• position : localización (latitud y longitud) del marcador,

• icon : icono de imagen con el que se representará el marcador,

• shadow : imagen de sombra del icono.

Otra de las características interesantes de los marcadores, es la posibilidad de que al hacer clic en ellos se abra una ventana de información con un mensaje personalizado. Esto también lo utilizamos.

A modo de ejemplo, se pueden apreciar programado todo lo descrito en la siguiente función JavaScript:

function crearMiMarca(punto,html,imgIcon,sombraIcon) { // Crea y dibuja la marca var marcador = new google.maps.Marker({ map: map, position: punto, icon: imgIcon, shadow: sombraIcon }); // Abre globo al hacer clic en ella google.maps.event.addListener(marcador, "click", function() { centro = map.getCenter(); infoGlobo.setContent(html); infoGlobo.open(map, marcador); Globo = true; }); return marcador;}

En la figura 14, se pueden ver el conjunto de tipos de nuestros marcadores, así como una ventana de información desplegada.



b) Elementos poligonales con la clase Polygon

Son varias las propiedades configurables a la hora de construir un polígono con la cla-se Polygon. En nuestro caso configuramos expresamente las siguientes:

• paths : listados de pares de coordenadas que configuran la forma del polígono,

• strokeColor : color del borde,

• strokeOpacity : nivel de opacidad del borde (entre 0 y 1),

• strokeWeight : ancho del borde en píxeles,

• fillColor : color de relleno,

• fillOpacity : nivel de opacidad del relleno (entre 0 y 1),

• zIndex : número que indica la prioridad a la hora de mostrarse cuando se dan so-lapes; los polígonos con números más altos se mostrarán por encima de los que los tienen más bajos.

Especial mención merece la opción phats. Según podemos leer en la Referencia de la API v3 (16), se trata de la secuencia ordenada de coordenadas que designa un bucle ce-rrado. Un polígono puede constar de una o más rutas. Como resultado, la propiedad de las rutas puede especificar uno o más conjuntos de coordenadas LatLng.

Los polígonos simples se pueden definir mediante un solo conjunto de LatLng. En nuestro caso, como veremos en el apartado 4.6.2. (pág. 86), cada uno de estos polígo-nos simples ocupará un registro en la tabla correspondiente de la base de datos y toma-rán el valor 0 en su campo tipo_poli (ver tabla 4).


Figura 14. Ejemplo de marcadores y ventana de información desplegada


En el caso de polígonos complejos, el paths se puede especificar como un conjunto de conjuntos. En nuestro caso, se han utilizado polígonos complejos en la construcción de las demarcaciones de arciprestazgos, vicarías y comarcas.

Polígonos complejos son, por ejemplo, aquéllos que están formados por varias partes y/o tienen polígonos isla (enclaves de otros polígonos dentro de ellos).

La construcción de polígonos complejos en nuestras aplicaciones, la hemos hecho a partir de la conjunción de varios conjuntos simples de coordenadas; conjuntos que, de por sí, definirían polígonos simples.

Es decir, cada uno de estos conjuntos simples de coordenadas, definirán o una parte del polígono complejo resultante o una isla en éste (enclave de otro polígono en él).

Cada conjunto simple de coordenadas, ocupará un registro en la tabla correspondiente de la base de datos y tomarán el valor 1, 2 ó 3 en su campo tipo_poli, dependiendo del papel que representen a la hora de definir un polígono complejo (ver tabla 4).

Valor de tipo_poli Descripción

0 Polígono simple (por ejemplo las demarcaciones parroquiales dibujadas)

1 Parte principal de un polígono complejo

2 Parte secundaria de un polígono complejo

3 Enclave de otro polígono en el polígono complejo que contribuye a formar

Tabla 4. Valores del campo tipo_poli en las tablas tipo 2 de la base de datos que definirán polígonos

complejos (véase 4.6.2. pág.86)

Como aclaración gráfica de todo lo explicado aportamos las siguientes figuras 15 y 16.


Figura 15. Ejemplo de polígono simple. Comarca Alt Vinalopó


En la figura 15 podemos apreciar un ejemplo de polígono simple (valor tipo_poli = 0). Sin embargo, en la figura 16, se presenta un ejemplo de polígono complejo compuesto de los siguientes trozos:

• Trozo a: tipo_poli = 1, parte principal del polígono complejo resultante;

• Trozo b: tipo_poli = 2, parte secundaria del polígono complejo resultante; en nuestro ejemplo representará un enclave de la Comarca L'Horta Nord en la Co-marca Valencia.

• Trozos c y d: tipo_poli = 3, polígonos isla en el polígono complejo resultante; en nuestro caso representan enclaves de la Comarca Valencia en la Comarca L'Horta Nord.

En la siguiente tabla explicamos cómo se construiría (23) el paths en cada uno de los casos presentados en las figuras 15 y 16:

Tipo polígono Paths

Simple(figura 15)

[lista puntos]

Complejo(figura 16)

[ [lista puntos (a), lista puntos (c), lista puntos (d)], [lista puntos (b] ]

Tabla 5. Estructura del paths en clase Polygon (23)

Al igual que con los marcadores, una característica interesantes de los polígonos, es la posibilidad de que al hacer clic en ellos se abra una ventana de información. Esto, tam-bién lo utilizamos del mismo modo que con los marcadores.


Figura 16. Ejemplo de polígono complejo. Comarca L'Horta Nord


A continuación se puede ver un ejemplo de cómo se construye un polígono que alma-cenaremos en la variable “poligono”:

// Crea un polígono con la lista de puntos "pts"var poligono = new google.maps.Polygon({ paths: pts, strokeColor: "#FF3300", strokeOpacity: 1, strokeWeight: 2, fillColor: "#66FF33", fillOpacity: 0.3, zIndex: 1});

En la siguiente imagen (fig. 17) se pueden ver dos polígonos, el amarillo se correspon-de con el Área de Servicios Sociales de Benimaclet y el verde con la demarcación de la parroquia San Leandro Obispo.

Se puede apreciar cómo al hacer clic sobre el polígono de la demarcación parroquial se ha abierto una ventana de información descriptiva de su Cáritas correspondiente.

Esto ha sido posible, estando ambos polígonos superpuestos, porque las demarcaciones parroquiales tienen un “zIndex: 1” mayor que las áreas de Servicios Sociales que lo tienen “zIndex: 0”. Se ha establecido este orden porque las demarcaciones parroquiales suelen ser más pequeñas que las áreas de Servicios Sociales. Si el orden hubiera sido el contrario o si no se hubiera establecido y se hubiera dibujado primero la demarcación parroquial, al pinchar sobre ella se nos hubiera abierto la información del Área de Servicios Sociales.


Figura 17. Ejemplo de marcadores y ventana de información desplegada


4.4.3. Generación de información geográfica

Tal y como decíamos en puntos anteriores, una parte importante del proyecto ha con-sistido en la generación de la información geográfica propia a partir de las fuentes cita-das en el punto (4.4.1.).

Explicaremos ahora los detalles principales de los procesos de generación de este tipo de información.

a) En general, para entidades poligonales

En el proceso de generación de información geográfica propia de entidad poligonal, el objetivo último ha sido el conseguir los listados de pares de coordenadas (longitud y latitud) de la porción (polígonos simples) o porciones (polígonos complejos) que configuran un polígono (ver apartado 4.4.2.b) para poderlo almacenar después en la base de datos MySQL.

Dichos listados de coordenadas en formato texto (longitud_1,latitud_1 longitd_2, latitud_2...) se han obtenido a partir de archivos KML generados con Google Earth y archivos GML generados con gvSIG. Describiremos brevemente ambos formatos:

• GML (30), acrónimo inglés de Geography Markup Language (Lenguaje de Mar-cado Geográfico). Es un sublenguaje de XML descrito como una gramática en XML Schema para el modelaje, transporte y almacenamiento de información geográfica. Su importancia radica en que a nivel informático se constituye como una lengua franca para el manejo y trasvase de información entre los diferentes software que hacen uso de este tipo de datos, como los Sistemas de Información Geográfica. GML se diseñó a partir de la especificación abstracta producida por el grupo OpenGIS, ahora Open Geospatial Consortium, y de la serie de docu-mentos ISO 19100. GML no contiene información específica sobre cómo se debe hacer la visualización de los datos representados. Para ello, se utilizan estilos que se relacionan a GML y se describen en otros sublenguajes de XML.

• KML (35), acrónimo inglés de Keyhole Markup Language, es un lenguaje de marcado basado en XML para representar datos geográficos en tres dimensiones. Fue desarrollado para Keyhole LT, precursor de Google Earth (Google adquirió Keyhole LT en octubre de 2004 tras lanzar su versión LT 2). Su gramática contie-ne muchas similitudes con la de GML. Los ficheros KML a menudo suelen dis-tribuirse comprimidos (ficheros KMZ.). Un KML especifica una característica (un lugar, una imagen o un polígono) para Google Earth. Contiene título, una descripción básica del lugar, sus coordenadas y alguna otra información.



Ejemplos de estos formatos son los siguientes:

GML de la comarca L'Hosta Nord (vista en la Figura 16 pág.58):<cit: comHortaNord.shp xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:GML="http://www.opengis.net/GML" xmlns:cit="http://www.gvsig.org/cit" xsi:schemaLocation="http://www.gvsig.org/cit cit.xsd"><GML:name>comarcas1-20soloDiocesis.shp</GML:name> <GML:boundedBy> <GML:Box GML:srsName="http://www.opengis.net/GML/srs/epsg.xml#4326"> <GML:coord>

<GML:X>-1.5289066325462601</GML:X><GML:Y>38.612619218237086</GML:Y> </GML:coord> <GML:coord> <GML:X>0.2343145312972057</GML:X><GML:Y>40.210085743795915</GML:Y> </GML:coord> </GML:Box> </GML:boundedBy> <GML:featureMember><cit:Feature GML:fid="10"> <GML:MultiSurface GML:srsName="http://www.opengis.net/GML/srs/epsg.xml#4326"> <GML:surfaceMember> <GML:Surface GML:srsName="http://www.opengis.net/GML/srs/epsg.xml#4326"> <GML:exterior><GML:LinearRing><GML:coordinates> -0.3849496586483454,39.53468750999842 … -0.38494965864834546,39.53468750999842 </GML:coordinates></GML:LinearRing></GML:exterior> </GML:Surface> </GML:surfaceMember> <GML:surfaceMember> <GML:Surface GML:srsName="http://www.opengis.net/GML/srs/epsg.xml#4326"> <GML:exterior><GML:LinearRing><GML:coordinates> -0.3681427346849577,39.59982851689267 … -0.36814273468495773,39.59982851689267 </GML:coordinates></GML:LinearRing></GML:exterior> </GML:Surface> </GML:surfaceMember> <GML:surfaceMember> <GML:Surface GML:srsName="http://www.opengis.net/GML/srs/epsg.xml#4326"> <GML:exterior><GML:LinearRing><GML:coordinates> -0.353417774853108,39.52979247474452 … -0.3534177748531087,39.52979247474452 </GML:coordinates></GML:LinearRing></GML:exterior> </GML:Surface> </GML:surfaceMember> <GML:surfaceMember> <GML:Surface GML:srsName="http://www.opengis.net/GML/srs/epsg.xml#4326"> <GML:exterior><GML:LinearRing><GML:coordinates> -0.3322496257116463,39.53999941677838 … -0.3322496257116463,39.53999941677838 </GML:coordinates></GML:LinearRing></GML:exterior> </GML:Surface> </GML:surfaceMember> <GML:surfaceMember> <GML:Surface GML:srsName="http://www.opengis.net/GML/srs/epsg.xml#4326"> <GML:exterior><GML:LinearRing><GML:coordinates> -0.3230460630811314,39.58696211760006 … -0.3230460630811314,39.58696211760006 </GML:coordinates></GML:LinearRing></GML:exterior> </GML:Surface> </GML:surfaceMember> <GML:surfaceMember> <GML:Surface GML:srsName="http://www.opengis.net/GML/srs/epsg.xml#4326"> <GML:exterior><GML:LinearRing><GML:coordinates> -0.4503907214392421,39.5454755101583 … -0.4470303552000967,39.54178191764881 </GML:coordinates></GML:LinearRing></GML:exterior> </GML:Surface> </GML:surfaceMember> </GML:MultiSurface> <id_comarca>7.0</id_comarca> </cit:Feature></GML:featureMember></cit:comHortaNord.shp>



Como vemos, se trata de un polígono complejo compuesto de 6 trozos; cada uno de ellos con su listado de coordenadas correspondiente (que por ser muchas, se muestran incompletas en el código anterior).

KML de la demarcación parroquial Santa Ana (polígono simple):<?xml version="1.0" encoding="UTF-8"?><KML xmlns="http://www.opengis.net/KML/2.2" xmlns:gx="http://www.google.com/KML/ext/2.2" xmlns:KML="http://www.opengis.net/KML/2.2" xmlns:atom="http://www.w3.org/2005/Atom"><Document> <name>50 - Santa Ana.KML</name> <Style id="sn_ylw-pushpin04">

<LineStyle> <color>ff000000</color> <width>2</width></LineStyle><PolyStyle> <color>b0ffffff</color> <colorMode>random</colorMode></PolyStyle></Style><StyleMap id="msn_ylw-pushpin3"> <Pair> <key>normal</key> <styleUrl>#sn_ylw-pushpin04</styleUrl> </Pair> <Pair> <key>highlight</key> <styleUrl>#sh_ylw-pushpin71</styleUrl> </Pair></StyleMap><Style id="sh_ylw-pushpin71"> <IconStyle> <scale>1.2</scale> </IconStyle> <LineStyle> <color>ff000000</color> <width>2</width> </LineStyle> <PolyStyle> <color>b0ffffff</color> <colorMode>random</colorMode> </PolyStyle> </Style> <Placemark> <name>50 - Santa Ana</name> <styleUrl>#msn_ylw-pushpin3</styleUrl> <Polygon> <tessellate>1</tessellate> <outerBoundaryIs> <LinearRing> <coordinates> -0.3558075733339994,39.47178227049925,0 -0.3568262044973206,39.47207048271579,0 -0.358487617407199,39.46944325336162,0 -0.3601547321012846,39.46828487148347,0 -0.361394526556709,39.46885791201487,0 -0.3631935501568817,39.46882423235252,0 -0.3599722951315488,39.46336945405459,0 -0.3575264063791558,39.46422470331496,0 -0.3541074777730717,39.47146219734055,0 -0.3546911030362325,39.47162987761009,0 -0.3556578883552231,39.47192435954569,0 -0.3558075733339994,39.47178227049925,0 </coordinates> </LinearRing> </outerBoundaryIs> </Polygon> </Placemark>

</Document></KML>



En ambos ficheros, GML de gvSIG y KML de Google Earth, se puede observar cómo las coordenadas longitud y latitud de cada punto se ofrecen con 14 o más cifras deci-males. En este sentido, debemos hacer notar que la API v3 de Google Maps utiliza una precisión de 6 cifras decimales en latitud y longitud (aproximadamente 10 cm. plani-métricamente) por lo que hemos procedido a truncar a la 6ª cifra decimal todas las co-ordenadas longitud y latitud proporcionadas desde los ficheros KML y GML.

Al truncar al 6º decimal las coordenadas, algunos puntos aparecen con idéntica longi-tud y latitud por lo que también se procedió a eliminar todos los redundantes.

Además, hemos visto cómo el KML de Google Earth ofrece una tercera coordenada correspondiente a la altimetría, en nuestro caso no iba a ser utilizada y se ha prescindi-do su registro.

b) Demarcaciones de parroquias

Como decíamos en el apartado 4.4., se han generado 118 demarcaciones parroquiales. Ya comentamos en dicho apartado, en su punto 4.4.1., que las fuentes de información han sido el mapa en papel de la Figura 9 (pág. 51) y las descripciones literales de los informes de límites parroquiales (fig. 10, pág. 52) . Únicamente se han tomado de apo-yo algunos shapes de barrios y distritos del ayuntamiento para las zonas limítrofes, Po-blats del Nord y Poblats del Sud. En este último caso, los shapes han sido previamente convertidas a GML con gvSIG.

Así, con todo, el deslinde y dibujo de las demarcaciones ha sido prácticamente manual utilizando Google Earth (ver fig. 18).


Figura 18. Dibujo de demarcaciones parroquiales en Google Earth


En el proceso de dibujo, se ha tenido la precaución de hacer coincidir, en número y lo-calización, los vértices de lados comunes de los polígonos.

Las dificultades encontradas en este proceso, se han debido a las propias del software, al grado de actualización de las fuentes y a los cambios sufridos en las demarcaciones en el último año (nuevos límites de arciprestazgos, vicarías y algunas parroquias).

Respecto a las limitaciones propias del software (Google Earth) ya indicamos en el apartado 1.6. que la información vectorial facilitada es limitada. No permite visualizar conjuntamente la localización de los números de policía ni visualiza la delimitación de las manzanas ni la delimitación de los términos municipales. Únicamente se visualizan los ejes de las vías urbanas, carreteras, algunos caminos o sendas... Por ello, sobre todo en vías urbanas de pequeño ancho, se pueden dar errores de ubicación de números de policía. Para minimizar los errores, nos hemos apoyado en la información vectorial del catastro (9), aunque no es la que utiliza Google para georeferenciar. Otra dificultad es no poder utilizar los vértices ya dibujados cuando son comunes a dos o más polígonos; siempre hay que volverlos a dibujar.

Una última limitación, se ha encontrado a la hora de visualizar los shapes del ayunta-miento en Google Earth. Este proceso pasa por utilizar gvSIG para transformar los shapes a WGS84 (proceso que explicamos en el punto 5. pág. 67) y exportarlos poste-riormente a un formato que reconozca Google Earth. Lo lógico hubiera sido utilizar KML, pero finalmente optamos por usar GML ya que el anterior no incluía valores de la tabla de atributos que nos sirven para identificar cada entidad. Ahora bien, Google Earth no reconoce este formato y, para importarlos allí, ha hecho falta otro proceso in-termedio de transformación de GML a KML; proceso nada complejo utilizando un edi-tor de textos y su herramienta de buscar/reemplazar ya que la estructura de ambos fi-cheros (GML y KML) es muy similar.

Una vez dibujadas todas las demarcaciones en Google Earth, se han generado los co-rrespondientes KML para obtener sus listados de coordenadas y truncarlas en su 6º de-cimal.

c) Demarcaciones de arciprestazgos

Las demarcaciones de arciprestazgo, como veíamos en el apartado 4.4., son generaliza-ción de las de parroquia, ya que varias parroquias componen un arciprestazgo.

El problema es que demarcaciones parroquiales sólo tenemos dibujadas 118, las co-rrespondientes a los arciprestazgos 1 a 9 (más o menos la ciudad de Valencia y algún pequeño trozo de su área metropolitana).



Este hecho, implica que hayamos tenido que buscar otro modo de generar los 25 arci-prestazgos restantes, del 10 al 34.

Explicamos ahora por separado ambos procesos:

• Generación de arciprestazgos 1 a 9 . Para este proceso se han seguido los siguien-tes pasos.

1. Abrimos una vista en gvSIG en la que el sistema de proyección sea WGS84 (EPSG: 4326) e importamos un KML con las demarcaciones de las 118 pa-rroquias.

2. Generamos un shape a partir del KML y editamos su tabla de atributos aña-diendo un campo que indique a qué arciprestazgo corresponde cada parro-quia.

3. Con la herramienta “Disolver” del “Gestor de geoprocesos” (fig 19), disolve-mos las demarcaciones parroquiales con igual valor de arciprestazgo.

Lo malo es que esta herramienta no acaba de disolver internamente los polí-gonos y a la hora de generar el GML se siguen apreciando los polígonos desde los que se ha generado como si de un polígono compuesto por varias partes se tratase.

Para solucionar este punto, optamos por utilizar un nuevo geoproceso, el de


Figura 19. Herramienta “Disolver” del Gestor de geoprocesos


“Área de influencia” (fig 20). Este geoproceso crea un nuevo polígono exte-rior o interior a cada uno de los polígonos que se le indique, disolviendo, si así se le pide, los polígonos resultantes que se solapen. Quizá no sea el méto-do más ortodoxo, pero hemos utilizado esta funcionalidad para conseguir lo pretendido: tomando arciprestazgo por arciprestazgo, hemos generado un nuevo polígono a 1 metro por su exterior, y después, a partir del polígono único resultante, ya disuelto, hemos vuelto a generar un nuevo polígono, esta vez a 1 metro por su interior, para revertirlo a su forma inicial.

El mayor inconveniente de este método, es una pequeña pérdida de precisión en la definición del polígono resultante al haber hecho el buffer de 1 metro. Ahora bien, considerando la utilidad a la que se va a destinar los polígonos (creación de mapas temáticos con el Generador) la pérdida de precisión es perfectamente asumible. Máxime teniendo en cuenta que serán polígonos que se utilizarán al mismo nivel que los generados con los shapes de la serie cv300 del ICV, de una precisión considerablemente menor (60 metros en pla-nimetría).

4. De estos nuevos polígonos, sí podemos ya rescatar los listados de coordena-das para truncarlos al 6º decimal y dejarlos preparados para su inclusión en la base de datos.


Figura 20. Herramienta “Área de influencia” del Gestor de geoprocesos


• Generación de arciprestazgos 10 a 34 . Para generar estos arciprestazgos ya no te-nemos demarcaciones parroquiales dibujadas que poder unir; utilizaremos como base los términos municipales contenidos en los shapes del cv300.

Fuera de los arciprestazgos 1 a 9 (vicarías 1 y 2), y a excepción de las zonas limí-trofes con estos, el resto de arciprestazgos de la Diócesis también se pueden di-bujar por generalización de términos municipales.

A qué arciprestazgo pertenece cada término es una información que se puede ex-trapolar de los datos que tenemos de cada parroquia, ya que sabemos en qué po-blación se encuentra y a qué arciprestazgo pertenece.

Dicho esto, pasamos a describir los pasos dados en este otro proceso:

5. Preparamos un shape que incluya todos los municipios presentes en la Dió-cesis. Para ello, lo primero que deberemos hacer es transformarlos del siste-ma de referencia ED50 a WGS84.

Abrimos una vista en gvSIG con sistema de referencia ED50 / UTM Huso 30 (EPSG 23030) en la que importamos todos los shapes de Valencia y Alicante, para después juntarlos en uno único con el geoproceso “Juntar” (fig. 21).

Una vez juntos, reproyectamos el shape resultante de ED50 a WGS84 me-diante la herramienta “Reproyectar” (fig. 22) del “Gestor de geoprocesos” y utilizando la transformación EPSG:1145.


Figura 21. Herramienta “Juntar” del Gestor de geoprocesos


Y finalmente, cargamos el shape reproyectado en una nueva vista que habre-mos configurado previamente con sistema de referencia WGS84 (EPSG: 4326)

6. Preparamos su tabla de atributos, eliminando los campos que no nos intere-sen (dejamos sólo el nombre y el id del municipio) y añadiendo, a partir de los datos que disponemos de las parroquias, 4 campos más que rellenaremos:

• id_arcip: para el identificador de arciprestazgo

• id_vic: para el identificador de vicaría

• id_comarca: para el identificador de comarca

• id_prov: para el identificador de provincia

Una vez completados todos los campos de los que tenemos datos en la infor-mación de las parroquias, eliminamos los registros de los municipios que no hemos rellenado ya que son de municipios de Alicante que no pertenecen a nuestro área de trabajo.

7. A partir de aquí, únicamente nos resta realizar análogamente los pasos 3 y 4 descritos en el proceso efectuado con los arciprestazgos 1 a 9 utilizando las herramientas “Disolver” (por el campo id_arcip) y “Área de influencia”.


Figura 22. Herramienta “Reproyectar” del Gestor de geoprocesos

Figura 23. Tabla de atributos del shape municipios WGS84


El proceso parece que podría quedar concluido aquí, pero nos falta revisar las zonas de unión entre los dos bloques de arciprestazgos (1 a 9 y 10 a 34), ya que se han generado con fuentes cartográficas distintas. El proceso no será complejo, tomando como guía los límites descritos por el bloque 1 a 9, efectuaremos dos operaciones posibles:

• Recortaremos de las zonas del 10 al 34 (con el geoproceso “Recortar”) lo que se llegue a solapar con los del 1 al 9.

• O completaremos los huecos que queden sin cubrir en dos pasos: primero alar-gando el arciprestazgo en cuestión con la herramienta de “Autocompletar polí-gono” (Geometría/Insertar/Autopolígono) y después lo recortaremos como indi-camos en la operación anterior.

d) Demarcaciones de vicarías

Una vez tenemos los shapes de todos los arciprestazgos, generar las demarcaciones de vicarías es inmediato utilizando las herramientas “Disolver” (por el campo id_vic) y “Área de influencia” análogamente a los pasos 3 y 4 del apartado anterior (c) descritos en el proceso efectuado con los arciprestazgos 1 a 9.

e) Demarcaciones de comarcas

Las demarcaciones de comarcas se han generado a partir del shape de términos muni-cipales obtenido en el punto 5 del apartado anterior (c), con la tabla de atributos prepa-rada en el punto 6 del mismo apartado.

El proceso es análogo al explicado en los pasos 3 y 4 de dicho apartado y ya utilizado también para las vicarías. Esta vez el campo de disolución será id_comarca.

f) Entidades puntuales

Las coordenadas longitud y latitud de localización de los elementos puntuales se han obtenido de tres formas distintas:


Figura 24. Herramienta “¿Qué hay aquí?”


• Manualmente . A partir de la información que se brinda con la opción “¿qué hay aquí?” (fig. 24) del menú contextual del botón secundario sobre cualquier punto del mapa en la página de Google Maps (http://maps.google.com) Esta opción se ha utilizado en categorías de pequeño número de entidades: Centros Municipales de Servicios Sociales, tiendas @rropa y Otros Recursos.

• Obteniendo los datos desde un archivo KML . Esta opción se ha usado para los contenedores de ropa de la Fundación INTRA. La Fundación los tiene localiza-dos en la siguiente página web de Google Maps

http://maps.google.com/maps/ms?ie=UTF8&t=h&oe=UTF8&msa=0&msid=114599883637930956654.0004836eb226bb59bfb34

Para poder exportar a un fichero KML los datos allí contenidos, basta con añadir a la dirección lo siguiente: &output=KML

Así, se genera un KML que descargamos y en el que podemos encontrar la localización de cada uno de los contenedores.

• Automáticamente . En bloque, utilizando un script php para la geocodificación de un gran número de direcciones. El script, lee la base de datos y en cada registro, toma la dirección de un campo y genera la latitud y longitud correspondientes que almacena en otros dos campos preparados al efecto.

Este segundo método se ha usado para la geocodificación de las direcciones de los 118 puntos de atención de Cáritas representados en el Localizador. Al tratarse de un proceso automático, ha sido necesaria la revisión posterior para detectar posibles errores.

Mostramos a continuación el código php utilizado:<?phprequire("phpsql_dbinfo.php");

define("MAPS_HOST", "maps.google.es");define("KEY", "");

// Abrimos conexión con el servidor$connection = mysql_connect("localhost", $username, $password);if (!$connection) { die("No se ha podido conectar: " . mysql_error());}

// Establecemos la base de datos MySQL con la que trabajaremos$db_selected = mysql_select_db($database, $connection);if (!$db_selected) { die("No está disponible la db : " . mysql_error());}





http://maps.google.com/


// Selecccionamos todos los registros de la tabla parroquiase$query = "SELECT * FROM parroquias WHERE 1";$result = mysql_query($query);if (!$result) { die("Petición inválida: " . mysql_error());}

// Inicializamos delay$delay = 0;$base_url = "http://" . MAPS_HOST . "/maps/geo?output=xml" . "&key=" . KEY;

// Iteramos a través de cada registro geocodificando cada direcciónwhile ($row = @mysql_fetch_assoc($result)) { $geocode_pending = true;

while ($geocode_pending) { $direccion = $row["direccion"].", ".$row["localidad"]; $id_parroquia = $row["id_parroquia"]; $request_url = $base_url . "&q=" . urlencode($direccion); $xml = simplexml_load_file($request_url) or die("url not loading");

$status = $xml->Response->Status->code; if (strcmp($status, "200") == 0) { // Geocodificación satisfactoria $geocode_pending = false; $coordinates = $xml->Response->Placemark->Point->coordinates; $coordinatesSplit = split(",", $coordinates); // Formato: Longitud, Latitud, Altitud $lat = $coordinatesSplit[1]; $lng = $coordinatesSplit[0];

$query = sprintf("UPDATE parroquias " . " SET lat = '%s', lng = '%s' " . " WHERE id_parroquia = '%s' LIMIT 1;", mysql_real_escape_string($lat), mysql_real_escape_string($lng), mysql_real_escape_string($id_parroquia)); $update_result = mysql_query($query); if (!$update_result) { die("Petición inválida: " . mysql_error()); } } else if (strcmp($status, "620") == 0) { // envíos demasiado rápidos $delay += 100000; } else { // fallo en la geocodificación $geocode_pending = false; echo "La dirección " . $direccion . " no se ha podido geocodificar. "; echo "Estado recibido " . $status . "\n"; } usleep($delay); }}?>

4.5. Información alfanumérica

La información alfanumérica ha sido facilitada prácticamente en su totalidad por Cári-tas Diocesana.

Su mayor fuente de datos es la “Memoria de Actividades” que cada Cáritas parroquial rellena anualmente a modo de encuesta. En las cuatro siguientes páginas podemos ver esta encuesta y todos los campos de datos que incluye (figuras 25, 26, 27 y 28).




Figura 25. Página 1 de la encuesta “Memoria de Actividades de la Cáritas Parroquial 2010”











En lo referente a parroquias y Cáritas parroquiales, arciprestazgos y vicarías, práctica-mente toda la información se desprende de esta encuesta y de la Guía Diocesana (6), también accesible en parte desde la web de la Archidiócesis.

Todos estos datos se nos han facilitado en un fichero xls con un registro (fila) por cada Cáritas parroquial.

De los campos contenidos en dicho fichero se han utilizado prácticamente todos, a ex-cepción de algunos con información de datos personales. Los 95 usados, son los siguientes:

1. PRESENTA MEMORIA 2010 2. Código parroquial 3. Arciprestazgo 4. Parroquia 5. Vicaría 6. Dirección Parroquia 7. Código Postal 8. Comarca 9. Localidad Parroquia 10. Email parroquia 11. Teléfono de la parroquia 12. FAX parroquia 13. Web parroquia 14. ¿Cuántos voluntarios tienen hasta 20

años? 15. ¿Cuántos son Hombres? 16. ¿Cuántos voluntarios tienen de 21 a

30 años? 17. ¿Cuántos son mujeres? 18. ¿Cuántos voluntarios tienen de 31 a

50 años? 19. Número total de voluntarios 20. ¿Cuántos voluntarios tienen de 51 a

65 años? 21. ¿Cuántos voluntarios tienen más de

65 años? 22. Días de atención al público 1 23. Horario atención 24. Días de atención al público 2

25. Horario 2 26. Días de atención al público 3 27. Horario 3 28. Hombres 29. Mujeres 30. Hasta 40 años 31. de 41 a 64 años 32. De 65 en adelante 33. Beneficiarios Totales 34. Inmigrantes sin papeles que buscan

trabajo 35. Inmigrantes con Permiso de Resi-

dencia y Trabajo que buscan trabajo36. Familias con algún enfermo en casa

que necesita ayuda 37. Problemas de drogas en la familia 38. Mujeres solas con cargas familiares 39. Ancianos solos 40. Familias españolas con dificultades

económicas 41. Familias con algún enfermo mental 42. Problemas de vivienda 43. Transeúntes de paso 44. ¿Cuántos extranjeros habéis

atendido este año? 45. ¿Y cuántos españoles? 46. De los atendidos ¿Cuántos han

venido por primera vez este año? 47. De las ayudas concedidas ¿Cuánto



dinero habéis dado en mano? 48. ¿A cuántas personas habéis ayudado

a encontrar trabajo? 49. ¿Tenéis ropero parroquial? 50. ¿Participáis directamente en algún

proyecto con los países del Sur? 51. ¿Participáis en la semana de

movilizaciones de Pobreza Cero? 52. ¿tenéis en el equipo personas

dedicadas a la animación? 53. ¿Utilizáis el segundo domingo para

sensibilizar a la comunidad parroquial?

54. ¿Utilizáis el guión de la Eucaristía del 2º domingo que remitimos desde C.Diocesana?

55. Si no lo conoces ¿estarías interesado en recibirlo?

56. ¿Te interesaría recibirlo? 57. Guión oraciones Cáritas 58. ¿Utilizáis la hoja informativa de

Cooperación Internacional? 59. ¿Te interesaría recibirla? 60. ¿Dais a conocer el material de la

campaña fuera de la comunidad parroquial?

61. Guía niños/jóvenes 62. Cartel 63. Guión litúrgico eucaristía 64. Díptico 65. Propios 66. Guía adultos 67. ¿Estáis presentes en los medios de

comunicación social (prensa, radio, TV)?

68. Colectas mensuales Segundo Domingo

69. Cuotas de socios de las CC.PP.

70. Donativos 71. Campaña Día de Caridad 72. Campaña de Emergencias 73. Aportación de Cáritas Diocesana

por solicitudes de ayuda a casos 74. Aportación de Cáritas Diocesana

por solicitudes de ayuda a Proyectos 75. Subvenciones de Ayuntamiento 76. Subvenciones de otras entidades 77. Otros conceptos 78. Ayudas ProInfancia (La Caixa) 79. TOTAL INGRESOS 80. Alquiler desahucio recibos 81. Atención Primaria Alimentación:

vales bolsas de comida 82. Atención Primaria Medicamentos y

ayudas de farmacia 83. Atención Primaria Otros 84. Ayudas educación de niños

(guarderías, becas de comedor, material escolar...)

85. Ayudas a transeúntes (bocadillos, billetes, pensiones...)

86. Proyectos Parroquiales 87. Proyectos Arciprestales e

interparroquiales 88. Animación y formación 89. Gestión de la Cáritas Parroquial 90. Aportación a Cáritas Diocesana por

el Día de Caridad 91. Aportación a Cáritas Diocesana por

Campañas de emergencias 92. Aportación a Cáritas Diocesana por

otros conceptos o Campañas 93. Aportaciones a otras instituciones de

dentro y fuera de la Iglesia 94. Ayudas ProInfancia (La Caixa) -G- 95. TOTAL GASTOS



Los datos de los Centros Municipales de Servicios Sociales y de los pocos Otros Re-cursos que se han incluido a modos de prueba, se han obtenido de la página web de la Regidoría de Benestar (7) o de las páginas webs propias de las entidades en el caso de Otros Recursos.

4.6. Arquitectura de la información y su almacenamiento

El soporte elegido para el almacenamiento de datos geográficos y datos alfanuméricos ha sido una base de datos MySQL (ver apartado 2.1.6.).

Las ventajas de este sistema son diversas:

1. Facilitan guardar toda la información en un mismo sistema de manera estructu-rada utilizando diferentes tablas y distintos campos en estas últimas.

2. Permiten acceder a la información por las diferentes vías que se implementen. En nuestro caso: las aplicaciones web del Localizador y Generador acceden a ella para generar los mapas con sus datos vinculados; el apartado de administra-ción implementado en Drupal (ver apartado 4.9.) accede a ella para mantenerla actualizada editando, añadiendo o quitando contenido.

3. Como toda base de datos, puede recibir consultas, en este caso bajo instruccio-nes SQL para devolver la información que cumpla dichas instrucciones. Este punto es utilizado sobre todo en el Generador de Mapas ya que una parte impor-tante de su modelo funcional (ver apartado 4.8.2.) se sostiene sobre este punto.

4. Cuenta con un soporte optimizado que minimiza el espacio de almacenamiento y los tiempos de respuesta.

La base de datos utilizada se ha compartido finalmente con el gestor de contenidos instalado (ver apartado 4.9.) para la administración de la información. Este hecho ha supuesto que el número de tablas en la base de datos se haya multiplicado.

Con todo, las tablas previstas inicialmente para almacenar estructuradamente la infor-mación son muchas menos. En concreto, 8:

• Tablas tipo 1 . Son 5 y comparten información de carácter geográfico e informa-ción de carácter alfanumérico gestionables desde Drupal.

• Tablas tipo 2 . Son 3 y contienen información más puramente geográfica, aunque con algún pequeño dato de carácter alfanumérico.



En la definición de cada tabla, se han especificado los nombres de los campos, su for-mato y longitud (“n” en general; y “m” cifras decimales para el tipo FLOAT), y si es un campo obligatorio y si es campo de clave principal (este último, sólo se puede atribuir a un campo).

Para la definición del formato del campo se ha elegido de entre los siguientes:

Tipo Descripción

smallint(n)Entero con o sin signo. Rango de valores: con signo (-32768, 32767) ; sin signo (0, 65535)

int(n)Entero con o sin signo. Rango: con signo (-2147483648, 2147483647) ; sin signo (0, 429.4967.295)

float(n,m)Número pequeño en coma flotante de precisión simple. Los valores válidos van desde -3.402823466E+38 a -1.175494351E-38, 0 y desde 1.175494351E-38 a 3.402823466E+38

varchar(n) Cadena de longitud variable. Podrá contener desde 0 a 255 caracteres.

text(n) Texto con un máximo de 65535 caracteres.

mediumtext(n) Texto con un máximo de 16.777.215 caracteres.

longtext(n) Texto con un máximo de 4.294.967.295 caracteres.

Tabla 6. Tipos de campos utilizados en las tablas de la base de datos MySQL

Inicialmente, la definición de las tablas se hizo utilizando phpMyAdmin. Pero después para las tablas compartidas con Drupal, las de tipo 1, se utilizó una definición compar-tida: primero se definieron desde el gestor de tipos de contenido de Drupal para des-pués retocarse mínimamente algunos campos con phpMyAdmin, ya que la definición en Drupal ofrece menos posibilidades que en phpMyAdmin.

Un ejemplo de creación de tablas con phpMyAdmin utilizando instrucciones SQL, tal y como se hizo al inicio, es el siguiente:

CREATE TABLE `cmss` ( ìd` SMALLINT NOT NULL PRIMARY KEY , `nombre` VARCHAR( 75 ) , `direccion` VARCHAR( 100 ) , `CP` VARCHAR( 5 ) , `localidad` VARCHAR( 50 ) , `telefono` VARCHAR( 9 ) , òbs_tel` VARCHAR( 100 ) , `fax` VARCHAR( 9 ) , è-mail` VARCHAR( 100 ) , ùrl` VARCHAR( 100 ) , òbservaciones` TEXT( 500 ) , `lat` FLOAT( 10, 6 ) , `lng` FLOAT( 10, 6 ) , `color` VARCHAR( 7 ) , `coordinates` TEXT( 10000 ) ) ENGINE = MYISAM ;



Pasamos a continuación a describir cada una de estas tablas con su correspondiente di-seño y formato de campos.

4.6.1. Tablas MySQL tipo 1

Se trata de las 5 tablas que, como decíamos, comparten información de carácter geo-gráfico e información de carácter alfanumérico gestionables desde el administrador im-plementado en Drupal.

En la siguiente tabla mostramos sus nombres y los grandes tipos de contenido que al-macenan:

Nombre de la tabla Tipo de información contenida

content_type_parroquias Cáritas parroquial

content_type_cmss Centro Municipal de Servicios Sociales

content_type_contenedoresintra Contenedores de ropa de la Fundación INTRA

content_type_tiendas_arropa Tiendas @rropa de la Fundación INTRA

content_type_otros_recursos Otros Recursos Sociales

Tabla 7. Tablas tipo 1 en la base de datos MySQL

a) Cáritas parroquial

La tabla content_type_parroquias es la que cuenta con mayor número de campos. Co-mo son muchos, 102 exactamente, los describiremos en diferentes bloques de campos.

Nombre Descripción Tipo

vid Índice interno int(10)

nid Índice interno int(10)

Tabla 8. Tabla content_type_parroquias: Campos para uso interno en Drupal


field_prq_lat_value Latitud float(10,6)

field_prq_lng_value Longitud float(10,6)

field_prq_coordenadas_value Listado de coordenadas de su demarcación longtext

field_prq_anyo_memoria_value Año de actualización de datos int(4)

field_prq_localizador_value Indica si se usa o no en el Localizador Varchar(1)

Tabla 9. Tabla content_type_parroquias: Campos de información geográfica y otros




field_prq_id_value Código parroquial int(6)

field_prq_id_arcip_value ID Arciprestazgo int(2)

field_prq_nombre_value Nombre parroquia varchar(100)

field_prq_id_vicaria_value ID Vicaría int(2)

field_prq_cp_value Código Postal int(11)

field_prq_id_comarca_value ID Comarca smallint(2)

field_prq_localidad_value Localidad varchar(50)

field_prq_observaciones_value Observaciones longtext

field_prq_direcccion_value Dirección varchar(100)

field_prq_email_value Email varchar(100)

field_prq_telefono_value Teléfono varchar(9)

field_prq_fax_value FAX varchar(9)

field_prq_url_value Web varchar(100)

field_prq_atencion1_value Días de atención al público 1 varchar(50)

field_prq_horario1_value Horario atención 1 varchar(100)





field_prq_ropero_value ¿Tiene ropero? varchar(1)

Tabla 10. Tabla content_type_parroquias: Campos de información general de la Cáritas Parroquial


field_prq_est09_value TOTAL DE BENEFICIARIOS int(11)

field_prq_est10_value Hombres atendidos int(11)

field_prq_est11_value Mujeres atendidas int(11)

field_prq_est12_value Extranjeros atendidos int(11)

field_prq_est13_value Españoles atendidos int(11)

field_prq_est14_value Atendidos que han acudido por vez primera int(11)

field_prq_est15_value Ayudas que se se han dado en mano float

field_prq_est16_value Personas ayudadas a encontrar trabajo int(11)

field_prq_est73_value Edad mayoritaria personas atendidas: hasta 40 años varchar(1)

field_prq_est74_value Edad mayoritaria personas atendidas: de 41 a 64 años varchar(1)

field_prq_est75_value Edad mayoritaria personas atendidas: de 65 en adelante varchar(1)

Tabla 11. Tabla content_type_parroquias: Campos de datos estadísticos sobre beneficiarios




field_prq_est01_value TOTAL DE VOLUNTARIOS int(11)

field_prq_est02_value Voluntarios hombres int(11)

field_prq_est03_value Voluntarios mujeres int(11)

field_prq_est04_value Voluntarios edad hasta 20 años int(11)

field_prq_est05_value Voluntarios edad de 21 a 30 años int(11)



field_prq_est08_value Voluntarios edad más de 65 años int(11)

Tabla 12. Tabla content_type_parroquias: Campos de datos estadísticos sobre voluntarios


field_prq_est55_value Participación directa en algún proyecto con países del Sur varchar(1)

field_prq_est56_value Participación en la semana de movilizaciones de Pobreza Cero varchar(1)

field_prq_est57_value Cuentan en el equipo con personas dedicadas a la animación varchar(1)

field_prq_est58_value Utilización del segundo domingo para sensibilizar a la comunidad parroquial

varchar(1)

field_prq_est59_value Utilización del guión de la Eucaristía del 2º domingo que prepara Cáritas Diocesana

varchar(1)

field_prq_est60_value No utilizan el guión de la Eucaristía, pero les interesaría recibirlo varchar(1)

field_prq_est61_value Utilización del guión de oraciones de Cáritas varchar(1)

field_prq_est62_value No utilizan el guión de oraciones, pero les interesaría recibirlo varchar(2)

field_prq_est63_value Utilización de la hoja informativa de Cooperación Internacional varchar(1)

field_prq_est64_value No utilizan la hoja de Cooperación, pero les interesaría recibirla varchar(1)

field_prq_est65_value Divulgación del material de la campaña fuera de la comunidad parroquial

varchar(1)

field_prq_est66_value Material campaña. Utilizan Guía niños/jóvenes varchar(1)

field_prq_est67_value Material campaña. Utilizan Cartel varchar(1)

field_prq_est68_value Material campaña. Utilizan Guión litúrgico eucaristía varchar(1)

field_prq_est69_value Material campaña. Utilizan Díptico varchar(1)

field_prq_est70_value Material campaña. Utilizan Guía adultos varchar(1)

field_prq_est71_value Material campaña. Utilizan material propio varchar(1)

field_prq_est72_value Presentes en los medios de comunicación (prensa, radio, TV) varchar(1)

Tabla 13. Tabla content_type_parroquias: Campos de datos estadísticos sobre dinamización

comunitaria, comunicación, participación en campañas...




field_prq_est27_value TOTAL INGRESOS int(11)

field_prq_est28_value Ing. Colectas mensuales Segundo Domingo int(11)

field_prq_est29_value Ing. Cuotas de socios de las CC.PP. int(11)

field_prq_est30_value Ing. Donativos int(11)

field_prq_est31_value Ing. Campaña Día de Caridad int(11)

field_prq_est32_value Ing. Campaña de Emergencias int(11)

field_prq_est33_value Ing. Aportación Cáritas Diocesana por solicitudes de ayuda a casos int(11)

field_prq_est34_value Ing. Aportación Cáritas Dioc. por solicitudes de ayuda a Proyectos int(11)

field_prq_est35_value Ing. Subvenciones de Ayuntamiento int(11)

field_prq_est36_value Ing. Subvenciones de otras entidades int(11)

field_prq_est37_value Ing. Otros conceptos int(11)

field_prq_est38_value Ing. Ayudas ProInfancia (La Caixa) int(11)

Tabla 14. Tabla content_type_parroquias: Campos de datos estadísticos sobre ingresos en el balance

económico


field_prq_est39_value TOTAL GASTOS int(11)

field_prq_est40_value Gast. Alquiler desahucio recibos int(11)

field_prq_est41_value Gast. Atención Primaria Alimentación: vales bolsas de comida int(11)

field_prq_est42_value Gast. Atención Primaria Medicamentos y ayudas de farmacia int(11)

field_prq_est43_value Gast. Atención Primaria Otros int(11)

field_prq_est44_value Gast. Ayudas educación de niños (guarderías int(11)

field_prq_est45_value Gast. Ayudas a transeúntes (bocadillos int(11)

field_prq_est46_value Gast. Proyectos Parroquiales int(11)

field_prq_est47_value Gast. Proyectos Arciprestales e interparroquiales int(11)

field_prq_est48_value Gast. Animación y formación int(11)

field_prq_est49_value Gast. Gestión de la Cáritas Parroquial int(11)

field_prq_est50_value Gast. Aportación a Cáritas Diocesana por el Día de Caridad int(11)

field_prq_est51_value Gast. Aportación a Cáritas Diocesana por Campañas de emergencias int(11)

field_prq_est52_value Gast. Aportación a Cáritas Diocesana por otros conceptos o Campañas

int(11)

field_prq_est53_value Gast. Aportaciones a otras instituciones de dentro y fuera de la Iglesia int(11)

field_prq_est54_value Gast. Ayudas ProInfancia (La Caixa) int(11)

Tabla 15. Tabla content_type_parroquias: Campos de datos estadísticos sobre gastos en el balance

económico




field_prq_est17_value Situación 1 más frecuente int(11)










Tabla 16. Tabla content_type_parroquias: Campos de datos estadísticos sobre situaciones que se

presentan más frecuentemente

b) Centro Municipal de Servicios Sociales

La tabla content_type_cmss tiene los siguientes campos:


vid Índice interno de Drupal (no editable) int(10)

nid Índice interno de Drupal (no editable) int(10)

field_cmssv_nombre_value Nombre del Centro varchar(75)

field_cmssv_direccion_value Dirección varchar(100)

field_cmssv_cp_value Código Postal varchar(5)

field_cmssv_localidad_value Localidad varchar(50)

field_cmssv_telefono_value Teléfono varchar(9)

field_cmssv_obs_tel_value Observaciones al teléfono varchar(100)

field_cmssv_fax_value Fax varchar(9)

field_cmssv_email_value Correo electrónico varchar(100)

field_cmssv_url_value Página web varchar(100)

field_cmssv_observaciones_value Observaciones longtext

field_cmssv_lat_value Latitud Float (10,6)

field_cmssv_lng_value Longitud Float (10,6)

field_cmssv_coordenadas_value Listado de coordenadas de la demarcación de su Área correspondiente

longtext

Tabla 17. Tabla content_type_cmss



c) Contenedores de ropa de la Fundación INTRA

La tabla content_type_contenedoresintra tiene los siguientes campos:


vid Índice interno de Drupal (no editable)

int(10)

nid Índice interno de Drupal (no editable)

int(10)

field_conten_nombre_value Nombre del contenedor varchar(75)

field_conten_direccion_value Dirección varchar(100)

field_conten_cp_value Código Postal varchar(5)

field_conten_localidad_value Localidad varchar(50)

field_conten_descripcion_value Descripción varchar(200)

field_conten_lat_value Latitud float(10,6)

field_conten_lng_value Longitud float(10,6)

Tabla 18. Tabla content_type_contenedoresintra

d) Tiendas @rropa de la Fundación INTRA

La tabla content_type_tiendas_arropa tiene los siguientes campos:



int(10)


int(10)

field_tiendas_nombre_value Nombre de la tienda varchar(100)

field_tiendas_direccion_value Dirección varchar(100)

field_tiendas_localidad_value Localidad varchar(50)

field_tiendas_telefono_value Teléfono varchar(9)

field_tiendas_email_value Correo electrónico varchar(100)

field_tiendas_horario_value Horario de apertura varchar(200)

field_tiendas_observaciones_value Observaciones longtext

field_tiendas_lat_value Latitud float(10,6)

field_tiendas_lng_value Longitud float(10,6)

Tabla 19. Tabla content_type_tiendas_arropa



e) Otros Recursos Sociales

La tabla content_type_otros_recursos tiene los siguientes campos:



int(10)


int(10)

field_ot_nombre_value Nombre del recurso varchar(100)

field_ot_direccion_value Dirección varchar(100)

field_ot_localidad_value Localidad varchar(50)

field_ot_telefono_value Teléfono varchar(9)

field_ot_email_value Correo electrónico varchar(100)

field_ot_url_value Página web varchar(100)

field_ot_horario_value Horario de apertura varchar(200)

field_ot_descripcion_value Descripción longtext

field_ot_observaciones_value Observaciones longtext

field_ot_lat_value Latitud float(10,6)

field_ot_lng_value Longitud float(10,6)

Tabla 20. Tabla content_type_otros_recursos

4.6.2. Tablas MySQL tipo 2

Como decíamos al comienzo de este apartado 4.6., las tablas de este segundo tipo son tres y contienen información más puramente geográfica, aunque con algún pequeño dato de carácter alfanumérico.

Estas tablas no son editables desde el administrador implementado con Drupal; para modificarse se ha de acceder a ellas de otro modo, por ejemplo, con phpMyAdmin.

Nombre de la tabla Tipo de información contenida

geo_arciprestazgos Datos para construir los arciprestazgos

geo_vicarias Datos para construir las comarcas

geo_comarcas Datos para construir las vicarías

Tabla 21. Tablas tipo 2 en la base de datos MySQL

Se trata de las tablas que sirven para construir los polígonos de las demarcaciones de arciprestazgo, vicaría y comarca.



Como más de un elemento de estas entidades tiene forma de polígono complejo, estas tablas disponen de la estructura necesaria para almacenar las distintas partes que confi-gurarán cada polígono.

Respecto a la información alfanumérica que decimos que contienen, nos referimos al identificador y al nombre de cada una de las entidades almacenadas en ellas.

Ya explicamos cómo eran y cómo se construían los polígonos complejos en el apartado 4.4.2.b) (pág.56). Ahora simplemente nos limitaremos a describir los campos de cada una de estas tablas.

a) Arciprestazgos

La tabla geo_arciprestazgos tiene los siguientes campos:


id Identificador único del registro smallint(6)

nombre_arcip Nombre del arciprestazgo (sólo estará relleno en el caso de registros de polígonos tipo 0 o tipo 1)

varchar(100)

lat_etiqueta Latitud del punto de inserción de la etiqueta float(10,6)

lng_etiqueta Longitud del punto de inserción de la etiqueta float(10,6)

coordinatesListado de coordenadas que definen la forma poligonal del polígono (tipos 0 y 1) o parte (2 ó 3)

mediumtext

id_arcipIdentificador del arciprestazgo que representa o del que es parte

smallint(2)

tipo_poli Tipo de polígono (0,1,2 ó 3) smallint(1)

n_polisNúmero de partes que forman el polígono, sin contar las islas tipo 3 (0 si no tiene partes o es una)

smallint(2)

n_hijos Número de polígonos isla, tipo 3, que contiene smallint(2)

poli_padreid del registro del polígono tipo 0 o 1 del que es isla (Si no es tipo 3, se rellena con 0)

smallint(2)

Tabla 22. Tabla geo_arciprestazgos

b) Vicarias

La tabla geo_vicarías es idéntica a la geo_arciprestazgos, únicamente cambia el nom-bre de los campos nombre_arcip por nombre_vicaria y id_arcip por id_vicaria.

c) Comarcas

Y lo mismo sucede con la tabla geo_comarcas. Es idéntica a la geo_arciprestazgos, cambiando los campos nombre_arcip por nombre_comarca y id_arcip por id_comarca.



4.7. Descripción detallada del Localizador

El Localizador de Recursos Sociales es la primera de las dos aplicaciones web desarro-lladas en este TFC. El acceso al mismo es público desde la siguiente dirección:

http://www.utopika.upv.es/caritas

En las próximas páginas, daremos un repaso a su entorno gráfico; realizaremos una descripción detallada de la aplicación valiéndonos de un esquema-explicación del mo-delo funcional implementado; y, para terminar, repasaremos las características en cuan-to a sus prestaciones a la vez que las mostramos con ejemplos.

4.7.1. Entorno gráfico

La IAP (ver 4.1.1.) ha tenido un papel muy importante en este apartado. Dentro de este marco, para la construcción gráfica de la aplicación se ha utilizado el método de Dise-ño Centrado en el Usuario.

Comenzaremos pues, hablando del Diseño Centrado en el Usuario. E inmediatamente después, nos detendremos en la creación propia de botones e iconos de marcadores, adaptados a nuestras necesidades y personalizados con la simbología manejada por los distintos recursos.

a) Diseño Centrado en el Usuario

El Diseño Centrado en el Usuario (28) es una filosofía de diseño que tiene por objetivo la creación de productos que resuelvan necesidades concretas de sus usuarios finales, consiguiendo la mayor satisfacción y mejor experiencia de uso posible con el mínimo esfuerzo de su parte.

Toma forma como un proceso en el que se utilizan una serie de técnicas multidiscipli-nares y donde cada decisión tomada debe estar basada en las necesidades, objetivos, expectativas, motivaciones y capacidades de los usuarios.

La mayoría de los procesos que hacen Diseño Centrado en el Usuario tienen el siguien-te esqueleto que nosotros también hemos seguido:

1. Conocer a fondo a los usuarios finales, normalmente usando investigación cuali-tativa o investigación cuantitativa

2. Diseñar un producto que resuelva sus necesidades y se ajuste a sus capacidades, expectativas y motivaciones


http://www.utopika.upv.es/caritas


3. Poner a prueba lo diseñado, normalmente usando un test de usuario. En nuestro caso: periodos de prueba.

El trabajo de conocer el perfil de los usuarios finales ya lo hicimos en la fase de defini-ción de proyecto y puede consultarse en el apartado 3.4.1. (pág.36) donde describimos los grupos/segmentos de usuarios.

Así, atendiendo a los perfiles mayoritarios (persona de edad avanzada, mujer y con po-cos o nulos conocimientos informáticos), el diseño gráfico ha seguido estos criterios:

1. Simplicidad de uso: cuantos menos controles, botones..., mejor.

2. Tamaño de fuentes y botones adecuados, tendiendo a grandes.

3. Letras claras con fondo oscuro que, además de facilitar la lectura por proporcio-nar mayor contraste, supone una mejor eficiencia energética por necesitar menor fuente lumínica.

4. Conjunto global bien distribuido: con los distintos bloques correctamente dife-renciados (cabecera, ventana de mapa y panel lateral de herramientas) y con gran espacio para la ventana de mapa y suficiente para el panel lateral de herra-mientas.

Atendiendo todos estos criterios y la resolución mínima de pantalla (1024x768) que se requería al cliente en el apartado 2.3.1. (pág.28), la visión general, en modo pantalla completa (recomendada), será como se muestra en la figura 29.


Figura 29. Localizador de Recursos: vista general


b) Botones e iconos propios

Mención especial merecen los botones (fig. 31) y los iconos de los marcadores con sus correspondientes sombras (fig. 32) que se han creado a medida para el proyecto. Utili-zan simbología característica y alusiva a los elementos que representaban. La herra-mienta de software libre utilizada para esta tarea ha sido el editor gráfico Gimp.

Otra característica importante de los botones, a parte de su personalización y tamaño, son dos efectos buscados:

• Efecto de “botón presionado / botón en posición natural” . Con él (ver fig. 32), en todo momento es fácil apreciar qué recursos están seleccionados (botón pre-sionado) y cuáles no (botón en posición natural).

• Efecto al pasar sobre el botón . Resaltando el borde en amarillo al pasar el ratón sobre él (ver fig. 32).

Ejemplo: en la figura 29, vemos activados un botón sí, uno no; y también se aprecia cómo se resalta en amarillo el borde del segundo botón, empezando por la izquierda, al pasar el ratón sobre él.


Figura 32. Localizador de Recursos: Efectos en los botones

Figura 30. Marcadores diseñados para el Localizador

Figura 31. Botones diseñados para el Localizador


4.7.2. Modelo funcional

Ya vimos en el apartado 4.3. un modelo funcional general para las dos aplicaciones. Lo personalizamos ahora para el Localizador dando mayor detalle de su lógica de trabajo.

De lo primero que hace la aplicación al cargar la página, es almacenar en variables glo-bales JavaScript, a modo de listas, todos los datos que hay almacenados en la base de datos y que son susceptibles de consultarse en el Localizador. El script php en el que se apoya este proceso, phpsqlgenxml_localizador.php, puede verse en los anexos.

Así, cada consulta realizada a través de los formularios (botones, selectores, etc), se hace contra estas listas y no contra la base de datos.

Otra opción hubiera sido realizar una consulta a la base de datos tras cada petición. Pero valorando el tiempo de respuesta en cada caso, optamos por descargar al inicio to-


Figura 33. Esquema del modelo funcional del Localizador

Funciones js dellamada a los phpAl cargar la página,llaman al script php

que descarga todos losdatos y los almacenanen variables javaScript


Actualizan el estado de loselementos visibles en la web

y generan informesde la información mostrada.

Funciones js de mapaInteractúan con la ventanade mapa determinando quédibujar (según los recursosseleccionados y el tipo debúsqueda), modificando

zooms, mostrando globos...

Página web(html + CSS)Formulariosque activan

funciones javascript:botones,

listas desplegables,campos de entrada,casillas de selección

Lad

o C

lient

eL

ado

Serv

idor

Base de datos MySQLCon la información estructurada

en diferentes tablas

Interprete phpRealiza la consulta

demandada a la base de datosy construye un documento XML

con la información devueltade manera estructurada


dos los datos para después operar siempre en el Lado Cliente. Con nuestra elección, el tiempo de carga se alarga más al inicio, pero una vez tenemos los datos en el Lado Cliente, las respuestas a las consultas son muy rápidas.

Respecto al tiempo de carga inicial, es importante advertir que la página y todo su en-torno gráfico se muestran listos muy rápidamente.

Ahora bien, la descarga de elementos de la base de datos para ser almacenados en variables-listas JavaScript puede tardar un poco más, aunque este hecho sea práctica-mente transparente al usuario. Esto se debe a que el proceso de descarga, tipo AJAX, es asincrónico (ver 2.1.7.). Así, puede ocurrir que, si efectuamos una consulta muy rá-pidamente, no obtengamos resultados por no estar los datos aún descargados y almace-nados en las listas globales JavaScript, aunque la página aparezca como lista y total-mente cargada. De todos modos, todo esto es un mal menor, ya que, seguramente, si repetimos la consulta segundos después, ya obtendremos resultados.

En cuanto a las funciones que desempeñan operaciones de carácter más puramente analítico, geográficamente hablando, destacaremos:

• La función auxElMasCercano.js: sencilla función que determina, entre una lis-ta de puntos, el más próximo a otro punto dado.

• El método contains.js: que determina si un polígono contiene a un punto dado. Utilizamos este método para discriminar a qué demarcación se corresponde el punto en que se sitúa la dirección dada en cada consulta. El algoritmo (8) se sos-tiene sobre los principios que explicaremos apoyándonos en la figura 34.

El algoritmo evalúa si un punto está dentro de un polígono, contando el número de nodos que genera el umbral de su coordenada vertical al atravesar los lados del polígono. Si ambos números son impares, el punto está dentro del polígono; si ambos números son pares o uno de ellos es 0, el punto estará fuera del polí-gono.

Se pueden presentar algunas situaciones especiales como las que vemos en los dos casos de la figura 35.


Figura 34. Algoritmo punto en polígono: casos 1, 2 y 3


En el caso de la izquierda, vemos cómo el umbral coincide con uno o varios vér-tices del polígono. En el de la derecha, el umbral coincide por completo con un lado del polígono.

En ambos casos, en vez de generar dos o más nodos por lado en dichas intersec-ciones, el algoritmo genera por lado un único nodo, como es lógico. El criterio que utiliza es: un lado genera un nodo si tiene uno de sus extremos por debajo del umbral y el otro por encima o sobre dicho umbral.

Siguiendo este criterio: en el caso de la izquierda, el lado “a” genera un nodo, pero el lado “b” no; y en el caso de la derecha, el lado “c” sí lo genera, pero los lados “d” y “e” no.

Como decíamos, este método lo hemos utilizado para discriminar dentro de qué demarcación parroquial o dentro de qué Área de Servicios Sociales se encuentra el punto de una dirección dada. Ahora mismo, todas las demarcaciones parro-quiales y todas las áreas de Servicios Sociales se han podido representar con po-lígonos simples (véase pág. 56, apartado 4.4.2.b) por lo que el método funciona perfectamente contra su listado de coordenadas.

En el momento en que necesitemos implementar el sistema de polígonos comple-jos (véase el mismo apartado 4.4.2.b) para representar alguna de estas entidades, también necesitaremos modificar la función que determina qué polígono contie-ne un punto dado.

Podremos seguir utilizando el método Contains, pero deberemos aplicarlo a cada una de las partes que componen el polígono complejo, contando también que en el caso de estar contenido el punto de búsqueda en un trozo de polígono isla (en-clave de otro polígono en este complejo), lógicamente habrá que considerar que el punto no está contenido en el polígono del que es parte esa isla.

Pasamos ahora a describir las características principales del Localizador.


Figura 35. Algoritmo punto en polígono: casos 4 y 5


4.7.3. Características y ejemplos de uso

Detallaremos las características de la aplicación recorriendo diferentes puntos: contro-les generales de visualización, tipos de recursos localizables, dirección base suminis-trada y tipos de búsqueda, cálculo de rutas y, finalmente, informe para imprimir. Tam-bién nos apoyaremos de imágenes a modo de ejemplos de uso.

a) Controles generales de visualización

Dentro de la ventana de mapa encontramos los siguientes controles de visualización:

• Zoom y posición . En la parte izquierda encontramos la barra de control de escala y el control de posición habituales en Google Maps (fig 37). También permite variar la escala con el botón central del ratón. Además, hemos incluido un zoom ventana (18) que se activa con la tecla “shift”.

• Street View . Entre el control de posición y la barra de control de escala, dispone-mos del muñequito (fig. 36) que podemos arrastrar a cualquier posición del mapa para visualizar en Street View esa posición.

• Selección de cartografía base . El selector de la parte superior derecha nos permi-te elegir entre “Mapa” con o sin relieve y “Satélite” con o sin etiquetas (fig. 38).

• Mini ventana de situación . En la parte inferior derecha hemos incluido una mini ventana de mapa (fig. 39) con la misma posición central que la ventana principal, pero con 4 niveles de zoom menos. Es de utilidad para saber en qué zona nos es-tamos moviendo más globalmente. Ambas están sincronizadas: cualquier movi-miento en esta mini ventana también se traslada a la principal y viceversa. En su parte inferior derecha cuenta con un pequeño botón que la oculta/muestra.


Figura 36. Control de Street View

Figura 37. Controles de posición y escala

Figura 38. Selector de cartografía base

Figura 39. Mini ventana de situación con su botón que la oculta o muestra


b) Elección de recursos localizables

Como ya hemos podido concluir con lo descrito hasta ahora, el Localizador ofrece re-cursos sociales clasificados en siete categorías. Ahora bien, las cuatro primeras (refe-rentes a los puntos de atención de Cáritas y a los Centros Municipales de Servicios So-ciales) son como dos dobles: una categoría se destina a los puntos de localización y la otra a su demarcación. La séptima, la correspondiente a Otros Recursos Sociales, está subdividida en 12 categorías adicionales, las mismas que utilizan los Servicios Socia-les del Ayuntamiento de Valencia, tal y cómo veíamos en el apartado 4.4. (pág.50).

Cualquier combinación de estas siete categorías principales puede ser visualizada con-juntamente, es decir, podemos visualizar los elementos localizados para una única ca-tegoría o bien para varias, hasta llegar a la totalidad de siete. En cuanto a la séptima, la de Otros Recursos, sólo podremos ver, cada vez, una de las doce subcategorías en las que está dividida. Optamos porque fuera así para facilitar la interpretación del mapa, ya que todos los “Otros Recursos” están simbolizados con el mismo marcador.

Ejemplo: en la figura 40, podemos apreciar el resultado de haber seleccionado cinco de las siete categorías.

1. Puntos de atención de Cáritas2. Demarcaciones Cáritas Parroquiales3. Áreas Servicios Sociales4. Contenedores @rropa5. Otros recursos sociales (seleccionada su subcategoría Familia, menor y adopcio-

nes)


Figura 40. Localizador de Recursos: ejemplo 1


c) Dirección base y tipo de búsqueda

La aplicación ofrece tres tipos de búsqueda de recursos: dos primeras vinculadas a la dirección base facilitada y una adicional que permite visualizar todos los recursos.

1. Para la dirección dada . Localiza los recursos más próximos o, en el caso de Cá-ritas y de los Centros Municipales de Servicios Sociales, los correspondientes por demarcación de parroquia y Área de Servicios Sociales respectivamente.

Ejemplo: en la anterior figura 40, podemos apreciar cómo se ha localizado la Cáritas correspondiente por demarcación a la dirección dada (Plza. del Ayunta-miento 1), el Área de Servicios Sociales que contiene dicha dirección, el conte-nedor de ropa y el recurso de “Familia, menor y adopciones” más cercanos.

2. A menos de... Localiza los recursos que se encuentran en un radio determinado. En el caso de las demarcaciones parroquiales y las áreas de Servicios Sociales, toma como referencia su vinculada localización puntual (de la Cáritas y del Centro Municipal).

Ejemplo: en la figura 41 podemos observar las Cáritas parroquiales (y sus de-marcaciones) más los contenedores @rropa que se encuentran en un radio de 1.000 metros alrededor de la dirección dada: Calle Bélgica, 5.

3. Ver todas . Como el nombre indica, visualiza en el mapa todos los recursos alma-cenados en la base de datos que se correspondan con las categorías selecciona-das. Ejemplo: en la fig. 42 vemos todos los Centros Munic. Servicios Sociales.




Un detalle a tener en cuenta, es la facilidad de uso que se ha buscado atendiendo al perfil conocido o potencial de usuarios. Desde esta premisa, se ha implementado un amplio grado de automatización en los controles. Un buen ejemplo de ello, es ver cómo se actualizan los resultados en el mapa al hacer cualquier cambio en las opciones seleccionables: al cambiar de dirección, seleccionar o deseleccionar recursos, cambiar el tipo o el radio de búsqueda...

Además, si deseamos retornar el mapa a su estado inicial, sin ningún recurso localiza-do en él, se cuenta con un control (fig. 43) que permite limpiarlo en su totalidad.

Otra característica que queremos resaltar, es el haber previsto internamente unas listas JavaScript de recursos ya dibujados en el mapa. Estas listas sólo se actualizan (vacián-dose y volviéndose a rellenar) cuando modificamos la dirección de búsqueda.

Dichas listas, ofrecen una mayor velocidad de respuesta a la hora de seleccionar y des-eleccionar recursos, ya que no se tiene que evaluar la consulta a las listas globales ge-nerales cada vez que hay un cambio. Con este sistema, basta con hacer la consulta la primera vez de cada tipo de búsqueda y, las sucesivas, se limitarán a mostrar u ocultar lo contenido en estas listas de elementos ya dibujados la primera vez.



Figura 43. Herramienta Limpiar mapa


Por último, decir que también hemos controlado el estado de la vista del mapa al efec-tuarse cambios en ella:

1. Hemos implementado que el zoom se adapte para que sean visibles todos los re-cursos seleccionados con el tipo de búsqueda elegido.

2. Cuando abrimos un globo de información y se desplaza la vista para que pueda ser mostrado, almacenamos el estado anterior del mapa para retornarlo allí al ce-rrar el globo (con su aspa de cierre o pinchando en otro lugar: sobre el mapa o sobre otra entidad).

d) Globos de información

Son las ventanas de información que se abren al pinchar sobre los marcadores o sobre los polígonos y muestran la información referente a ese elemento. Distinguimos dos ti-pos: el primero, el del marcador en la posición de la dirección dada; y el segundo, el de marcadores de recursos o polígonos de sus demarcaciones.

• Globo en el marcador “casa” . Siempre nos muestra la dirección tal y como la de-vuelve el sistema de geocodificación de Google Maps. Además, en caso de que haya algún recurso no disponible entre los solicitados, nos lo lista. En este último caso, el globo se abriría automáticamente para advertirnos de tal circunstancia. También hay que reseñar que cualquier cambio al seleccionar o deseleccionar re-cursos, se actualiza automáticamente en la información del globo.

Ejemplo: en la figura 44 vemos cómo a 500 metros de la dirección Poeta Artola 15, sí que hay tres Cáritas Parroquiales, pero no hay ningún Centro Municipal de




Servicios Sociales ni Contenedores @rropa; hecho que, como podemos ver, se indica en el globo del marcador “casa”.

• Globo en marcadores o demarcaciones de recursos : muestra la información per-sonalizada de cada recurso. Además, incluye los enlaces “Cómo llegar” y “Aña-dir a informe” que posibilitan, respectivamente, calcular la ruta (lo explicaremos en el punto “e”) y añadir la información al informe que puede imprimirse (lo ex-plicaremos en el punto “f”).

Por otro lado, para que el aspecto de visualización sea óptimo en los globos de los puntos de atención de Cáritas, se ha contado con incluir en ellos sólo aquellos datos de contacto de los que hay información, para esa Cáritas, en la base de da-tos; esto evita líneas en blanco o encabezados de datos que no tienen después contenido. Un ejemplo de esto ,se puede ver en los dos globos de la figura 45: el primero tiene correo electrónico y el segundo no.

e) Cálculo de rutas

Una característica más del Localizador es la posibilidad de calcular la ruta, a pie o en coche, desde la dirección dada hasta el recurso desde el que la solicitamos.

La petición del cálculo de ruta se hace, como explicábamos en el punto anterior, desde el enlace “Cómo llegar” que encontraremos en cualquier globo de información de los que se abren al pinchar sobre cada marcador o demarcación vinculada (véase, por ejemplo, la fig. 45).

El cálculo de rutas ofrece una materialización gráfica de la ruta sobre el mapa y un in-forme, paso a paso, por escrito en el panel lateral. Ambas informaciones están vincula-


Figura 45. Localizador de Recursos: ejemplo de globos en Cáritas Parroquiales


das, de manera que, al pinchar sobre cualquier ítem del informe escrito, podemos ver su correspondencia en el mapa abriéndose un globo de información con la instrucción textual en el punto en que se debe seguir.

En el ejemplo de la figura 46 vemos la ruta para llegar en coche desde la calle Colón, nº 25 hasta su correspondiente Centro Municipal de Servicios Sociales. También apre-ciamos la vinculación, entre ruta gráfica e informe del panel lateral, al contemplar el globo que se ha abierto en el punto correspondiente al paso 5 del informe escrito.

La ruta, también se actualiza automáticamente cuando cambiamos de tipo de ruta entre “a pie” o “en coche”. Para el ejemplo anterior, vemos ambas en las figuras 47 y 48.

Por último, decir que hay un botón con forma de escoba, igual al de Limpiar Mapa (fig. 43), pero que en este caso borra la ruta del mapa y su informe del panel lateral.



Figura 47. Localizador de Recursos: ejemplo de ruta “a pie”

Figura 48. Localizador de Recursos: ejemplo de ruta “en coche”


f) Informe para imprimir

Como apuntábamos en el punto “d”, la información contenida en el globo de cualquier recurso puede ser añadida a un informe, disponible para imprimir directamente o con-sultarlo antes desde su vista previa.

La información se añade con el enlace “Añadir a informe” que encontramos en cada globo, tal y como explicábamos en el punto “d” y vemos en la figura 45 (pág. 99).

Los botones de imprimir y de vista previa, se encuentran en la sección “Informe“ (fig. 49), en la parte de abajo del panel lateral. En esta misma sección se van listando los elementos añadidos al informe y, además, encontramos el mismo botón de escoba que en otras secciones; en ésta, nos permitirá vaciar el contenido del informe.

Ejemplo: en la figura 49, hemos podido ver la sección “Informe” con tres recursos lis-tados con su información disponible para ser impresa. En la figura 50 mostramos el in-forme correspondiente.


Figura 49. Localizador de Recursos: Sección Informe

Figura 50. Localizador de Recursos: ejemplo de informe de recursos localizados


4.8. Descripción detallada del Generador

El Generador de Mapas Sociales es la segunda de las dos aplicaciones web desarrolla-das en el presente TFC. El acceso al mismo es público y está disponible desde la parte inferior derecha del Localizador o, directamente, desde la siguiente dirección:

http://www.utopika.upv.es/caritas/generador.html

Como hicimos con el Localizador, en las próximas páginas, realizaremos una descrip-ción detallada de la aplicación. En primer lugar nos detendremos en lo referente a su entorno gráfico. Después, continuaremos utilizando un esquema-explicación del mode-lo funcional implementado. Y finalmente, daremos un repaso a sus características en cuanto a prestaciones, acompañándonos en este punto de ejemplos de sus resultados.

4.8.1. Entorno gráfico

Todo lo que ya explicamos sobre la IAP y Diseño Centrado en el Usuario en el aparta-do 4.7.1. (pág. 88), también es extrapolable a esta aplicación de generación de mapas.

El Generador supone una herramienta más técnica que el Localizador, por lo que, aun-que el acceso a ella es público, los usuarios potenciales son sustancialmente menos.

De entrada, quien más uso le va a dar es el Departamento de Análisis de la Realidad de Cáritas Diocesana, departamento y entidad de donde surgió la necesidad que cubre.


Figura 51. Generador de Mapas: vista general inicial

http://www.utopika.upv.es/caritas/generador.html


En la figura 51, presentamos una vista general de la aplicación tal y como se muestra al cargar la página. Conforme a lo que se puede deducir de su observación, el diseño gráfico de esta aplicación respecto al Localizador ha sido, en general, más sencillo. No ha habido que crear nuevos botones, ni marcadores... Marcadores no utiliza y botones, los pocos que se han necesitado, se han mantenido respecto al Localizador, también por conservar un estilo común.

La diferencia gráfica más sustancial, es el espacio dedicado a la ventana de mapa, pu-diendo ocupar el 100% de la pantalla (en modo pantalla completa –recomendado–).

El panel lateral de herramientas, se sitúa flotando sobre el mapa, disponiendo de un bo-tón en su parte superior derecha que nos permite mostrarlo u ocultarlo según necesite-mos (fig. 52 y 53).

La decisión de ocupar todo el espacio disponible para la ventana de mapa, se debe a las necesidades que imponen las finalidades de la aplicación.

El objetivo final del Generador es construir mapas temáticos (como el de la fig. 53) que puedan ser tomados con capturas de pantalla para incluirlos en publicaciones o presentaciones de diapositivas: medios divulgativos de anuncio y denuncia de la reali-dad social valenciana.

Algunos ejemplos de estos mapas se pueden ver en las siguiente páginas, especialmen-te en el apartado 4.8.4. (pág. 130).


Figura 52. Generador de Mapas: panel lateral desplegado y detalle botón oculta / muestra

Figura 53. Generador de Mapas: panel lateral ocultado, con mapa generado, fondo blanco y

detalle botón oculta / muestra


4.8.2. Modelo funcional

Ya vimos, en el apartado 4.3., un modelo funcional general para las dos aplicaciones. Al igual que hicimos en el apartado 4.7.2. con el Localizador, lo personalizamos ahora para el Generador dando mayor detalle de su lógica de trabajo.

De lo primero que hace la aplicación al cargar la página, es descargar toda la informa-ción de carácter geográfico para construir los polígonos que representarán las distintas entidades (parroquias, arciprestazgos, vicarías y comarcas).

Para esta tarea, se apoya en el script php phpsqlgenxml_generador_geo.php que se puede consultar en los anexos.


Figura 54. Esquema del modelo funcional del Generador

Funciones js dellamada a los php

Al cargar la página, llaman alscript php que descarga

los datos geográficos y, trasconstruir los correspondientespolígonos, los almacenan / Alrealizar consultas, llaman al

php que pregunta a la BD quedevuelve la respuesta


Actualizan el estadode los elementos visibles en la web

y generan informesde la información

mostrada.

Funciones js de mapaInteractúan con la ventanade mapa determinando quédibujar (según las consultas

efectuadas y lo devueltopor la base de datos), modificando zooms,mostrando leyendas,

límites, globos...

Página web(html + CSS)Formulariosque activan

funciones javascript:botones,

listas desplegables,campos de entrada,casillas de selección

Lad

o C

lient

eL

ado

Serv

idor Base de datos MySQL

Con información estructuradaen diferentes tablas

Interprete phpRealiza la consulta demandada a la base de datos

y construye un documento XML con la informacióndevuelta de manera estructurada


Estos polígonos que construimos, se almacenan en variables globales JavaScript, a modo de listas. Así, cuando realizamos una consulta a la base de datos, esta nos de-vuelve los índices de los polígonos que intervienen en la consulta y que serán dibuja-dos. Estas consultas de las que hablamos, se realizan con el apoyo del script php phpsqlgenxml_generador_consultas.php (también disponible en los anexos).

Así, tras la descarga inicial de información geográfica, en cada consulta realizada a tra-vés de los formularios (botones, selectores, etc), al preguntar a la base de datos, sólo tiene que descargarse índices y valores de datos.

Otra opción hubiera sido, además de descargar los valores de datos y en lugar de los índices de polígonos a dibujar, haber descargado también los listados de coordenadas de dichos polígonos. Pero valorando el tiempo de respuesta en cada caso, optamos por descargar al inicio todos los datos geográficos que suman más de 4Mb. De esta mane-ra, se minimiza el volumen de transferencia de datos en cada consulta. Al igual que nos pasaba en el Localizador, con esta elección, el tiempo de carga se alarga más al inicio, pero una vez tenemos los datos en el Lado Cliente, el resultado de las consultas se obtiene mucho más rápido.

Como sucedía en el Localizador, respecto al tiempo de carga inicial, es importante ad-vertir que la página y todo su entorno gráfico se muestran listos muy rápidamente.

Ahora bien, la descarga de elementos geográficos de la base de datos para ser almace-nados como polígonos en variables-listas JavaScript, puede tardar un poco más, y ya dijimos que este hecho es prácticamente transparente al usuario. Se debe a que el pro-ceso de descarga, tipo AJAX, es asincrónico (ver apartado 2.1.7. pg. 26).

Así, como sucedía en el Localizador, nos puede volver a ocurrir que si efectuamos una consulta muy rápidamente tras cargar la página, no obtengamos resultados por no estar los datos geográficos aún descargados y almacenados -aunque la página aparezca como lista y totalmente cargada-. De todos modos, todo esto vuelve a ser un mal me-nor, ya que, seguramente, si repetimos la consulta pocos segundos después, ya obten-dremos resultados. Una buena forma de comprobar si las diferentes entidades geográfi-cas han sido descargadas y almacenadas, es intentar mostrar sus límites en el mapa, se-leccionando cada uno de ellos en el apartado “Límites” en la sección “Capas visibles” del panel lateral. Si tras seleccionar los de una entidad determinada, aparecen dibuja-dos en el mapa, esa entidad ya ha sido descargada completamente.

Por otro lado, decir que en el proceso de creación de polígonos a partir de la informa-ción geográfica descargada, para todas las entidades, a excepción de la de parroquia, el sistema utilizado es el de polígonos complejos (ver apartado 4.4.2.b) pág. 56).



Y por último, antes de pasar a describir características junto algunos ejemplos de uso, queremos hacer notar una consideración importante: a diferencia del Localizador don-de el dominio de la programación JavaScript era claro, en el caso del Generador, aun-que el JavaScript también sigue dominando, debemos decir que la parte de php con complejas consultas SQL a la base de datos, también ha tenido un peso muy considera-ble. Nos extenderemos en este punto en el punto (d), pg. 110, del siguiente apartado.

4.8.3. Características

Detallaremos las características de la aplicación recorriendo diferentes puntos. Empe-zaremos por los controles generales de visualización. Proseguiremos con la selección de unidad mínima de análisis y área de estudio. Continuaremos con la elección del tipo de consulta y configuraciones de estas. Seguiremos con el formato de los valores a tra-bajar (% o número). Antes de acabar, abordaremos el control de capas de información. Y finalmente, describiremos la generación de informes sobre las consultas.

Nos apoyaremos, cuando sea necesario, en casos prácticos a modo de ejemplo para ilustrar la explicación.

a) Controles generales de visualización

Dentro de la ventana de mapa encontramos prácticamente los mismos controles que para el Localizador, a excepción de la mini ventana de situación que no hemos incluido esta vez. Nos remitimos a la página 94 para ver sus explicaciones.

b) Selección de unidad mínima de análisis y área de estudio

Un primer paso determinante e imprescindible en cualquier consulta para generar un mapa temático con esta aplicación, es seleccionar la unidad mínima de análisis y el área de estudio con los que trabajaremos.

Ambas variables se definen desde dos selectores (fig. 55), el primero simple y el se-gundo múltiple, dispuestos en la parte superior del panel lateral de herramientas.


Figura 55. Sección de selección de unidad mínima y área de estudio en el Generador


• La unidad mínima de análisis hace referencia a las entidades poligonales que utilizaremos para representar los datos estadísticos consultados.

En el estado actual de desarrollo de la aplicación, podemos elegir entre:

1. Comarca . La única unidad de análisis disponible de las de carácter oficial en las Administraciones Públicas.

2. Parroquia . Unidad mínima de análisis más pequeña y básica de cuantas utili-za Cáritas. Las consultas con esta unidad mínima están disponibles para las vicarías 1 y 2, más o menos equivalente a la ciudad de Valencia y alguna pe-queña porción de su área metropolitana.

3. Arciprestazgo . Resultante de la agrupación de varias parroquias. Disponible para toda la Diócesis; esto es, toda la provincia de Valencia (excepto el muni-cipio de Gátova como veíamos en el apartado 4.4.) y 63 municipios de la provincia de Alicante.

4. Vicaría . Resultante de la agrupación de varios arciprestazgos. También dispo-nible para toda la Diócesis.

En la figura 56, podemos contemplar el menú de selección desplegado con la opción “Arciprestazgo” seleccionada.

• Y el área de estudio nos posibilita delimitar la zona de trabajo, yendo desde un sólo arciprestazgo hasta la totalidad de la Diócesis.

En la figura 57, podemos ver su menú de selección con las opciones “Vicaría 1” y “Vicaría III” seleccionadas.


Figura 56. Selector simple de unidad mínima de análisis

Figura 57. Selector múltiple de área de estudio


Es importante resaltar que, dependiendo de la opción elegida en el selector de unidad mínima (fig. 56), el selector de área de estudio (fig. 57) se actualiza con las opciones correspondientes y adecuadas a la unidad mínima seleccionada.

En general, como opciones de área de estudio disponibles para una determinada unidad mínima, tendremos el listado de entidades de rango superior y el listado de entidades de ese mismo rango (para todas menos para las parroquias).

Es decir, si elegimos como unidad mínima el arciprestazgo, en el selector de área apa-recerán el listado de vicarías y el de arciprestazgos. Si elegimos el de parroquias, ten-dremos las vicarías I y II y el listado de los 9 arciprestazgos de los que tenemos esa in-formación geográfica (a nivel de parroquia). Eligiendo vicaría, tendremos el listado de vicarías. Y finalmente, seleccionando el de comarca, tendremos el listado de comarcas.

El modo de selección en el selector múltiple de área, es el de cualquier selector. Permi-te elegir una a una (manteniendo pulsada la tecla “Ctrl”) o, por el contrario, un rango concreto (seleccionando inicio y final de dicho rango mientras se mantiene pulsada la tecla “shift”). Aún así, para facilitar algunas selecciones múltiples, se han incluido al-gunas opciones que las realizan de manera equivalente; ejemplos de ellas son:

• Todas las comarcas

• Todas las Vicarías

• Todas las Vicarías menos la I y la II (muy útil para hacer mapas legibles de toda la Diócesis, separando las vicarías I y II del resto por tener, estas dos primeras, mucha información –10 de los 34 arciprestazgos totales– en poca superficie com-parándolo con el resto de la Diócesis (ver figuras 5 y 6, pág. 48).

c) Elección del tipo de consulta

Se han implementado tres modos de consulta generales: “En bloque”, “Individual” y “Situaciones” (situaciones más frecuentes).

Podemos elegir cualquiera de ellas desde la sección de tipo de consulta que encontra-mos en el panel lateral justo debajo de la sección de unidad mínima y área de estudio. Y dependiendo de la que elijamos, el aspecto de esta sección, desde la que configurare-mos cada consulta, cambiará (21) para incluir los controles que nos permitirán cons-truir cada petición de consulta.

En las siguientes figuras (fig. 58, 59 y 61) podemos apreciar el aspecto de esta sección cuando elegimos cada uno de los tres tipos de búsqueda citados.



Como consideración general a los tipos de consulta, apuntaremos que en los modos “En bloque” y “Situaciones”, la realización de una nueva consulta borra del mapa las existentes y añade la nueva que se demanda.

Sin embargo, cuando elegimos el modo “Individual”, cada consulta demandada se aña-de a las ya existentes en el mapa (de tipo “Individual”, “En bloque” o de “Situaciones”).

Si teniendo seleccionado el modo “Individual”, queremos empezar a añadir consultas al mapa desde cero mientras ya existe alguna dibujada en el mapa, tendremos que bo-rrar las consultas existentes manualmente utilizando el botón “Limpiar consultas” que se muestra en la siguiente figura (fig. Error: No se encuentra la fuente de referencia).


Figura 59. Aspecto de la sección tipo consulta, seleccionado el

modo “Individual”


modo “En bloque”


modo “Situaciones”

Figura 61. Herramienta “Limpiar consultas”


d) Papel del php con SQL en los tipos de consulta

Tal y como comentábamos al final del apartado 4.8.2., en el Generador, la parte de php, con complejas consultas SQL a la base de datos, ha tenido un peso muy considerable.

Cada consulta construida desde los formularios del panel lateral descritos en el aparta-do “e”, se apoya en el script php phpsqlgenxml_generador_consultas.php que se puede ver en los anexos.

A dicho script le llegan, en forma de variables añadidas a la url que le llama, todos aquellos datos necesarios para efectuar la consulta apropiada a la base de datos. Tras la consulta, el script devuelve un xml con los valores necesarios para construir los mapas en JavaScript.

En cuanto al script php, nos detendremos un poco en explicar las consultas SQL utili-zadas para los modos de consulta “Individual” y “En bloque”. En el siguiente cuadro podemos ver un resumen de las diferentes tipologías de consultas SQL.

Consultas individuales Consultas en bloque

Tipo de dato Intervalo [,]Otro operador

>, <, =, > ó =, < ó =$operador y $valor fijos

> ó = 0

nº A1 A2

% (en el área de estudio) B1 B4

(en toda la Diócesis) C1 C4

%

del TOTAL padre (en el área de estudio)

B2 ó B3 B5 ó B6

del TOTAL padre (en toda la Diócesis)

C2 ó C3 C5 ó C6

Tabla 23. Cuadro resumen de tipologías de consultas SQL para los modos “Individual” y

“En bloque”

Para entender bien las consultas, quizá sea necesario entender qué significa cada tipo de dato. Los explicamos más adelante en la página 114.

Consultas tipo A:

Son las que utilizan los valores de las variables en el formato en que aparecen en la base de datos. Se usarán cuando seleccionemos como tipo de dato:

• nº



Su estructura básica es:

SELECT $udMinima, $idArea, SUM($variable) AS TotalVariable FROM content_type_parroquias GROUP BY $udMinima HAVING ($condArea) AND otraCondicionORDER BY TotalVariable ASC, $idArea ASC, $udMinima ASC

La diferencia entre los subtipos A1 y A2, estriba en el valor de otraCondicion (ver ta-bla 24 más adelante).

Consultas tipo B:

Son las que utilizan los valores de las variables en formato de porcentaje en el área de estudio. Se usarán cuando seleccionemos como tipo de dato:

• % (en el Área de estudio)

• ó % del TOTAL padre (en el Área de estudio)


SELECT $udMinima, $idArea, SUM($variable)*100/ ( ( paraTotalAcomputar FROM content_type_parroquias WHERE ($condArea) ) ) AS TotalVariableFROM content_type_parroquias GROUP BY $udMinima HAVING ($condArea) AND otraCondicionORDER BY TotalVariable ASC, $idArea ASC, $udMinima ASC

Las diferencias entre los subtipos B1, B2, B3, B4, B5 y B6, radican en los valores de paraTotalAcomputar y otraCondicion (ver tablas 24 y 25 más adelante).

Consultas tipo C:

Son las que utilizan los valores de las variables en formato de porcentaje en toda la Diócesis. Se usarán cuando seleccionemos como tipo de dato:

• % (en toda la Diócesis)

• ó % del TOTAL padre (en toda la Diócesis)




SELECT $udMinima, $idArea, SUM($variable)*100/ ( ( paraTotalAcomputar FROM content_type_parroquias ) ) AS TotalVariableFROM content_type_parroquias GROUP BY $udMinima HAVING ($condArea) AND otraCondicionORDER BY TotalVariable ASC, $idArea ASC, $udMinima ASC

Las diferencias entre los subtipos C1, C2, C3, C4, C5 y C6, se aprecian en los valores de paraTotalAcomputar y otraCondicion (ver tablas 24 y 25).

Subtipo otraCondicion

A1

B1 C1(TotalVariable >= $valor1 AND TotalVariable <= $valor2)B2 C2

B3 C3

A2

B4 C4

TotalVariable $operador $valorB5 C5

B6 C6

Tabla 24. Cuadro 1 de diferencias entre los subtipos de A, B y C de consultas SQL

Subtipo paraTotalAcomputar

B1 C1SELECT SUM($variable)

B4 C4

B2 C2SELECT SUM($varMadre)

B5 C5

B3 C3SELECT (SUM($varMadreA)+SUM($varMadreB))

B6 C6

Tabla 25. Cuadro 2 de diferencias entre los subtipos de B y C de consultas SQL

Tal y como podemos deducir de lo expuesto en este apartado, las diferencias entre las distintas consultas tienen que ver, sobre todo:

1. En el tipo de dato que manejan (nº ó %) afectando a la consulta en el caso de cálculo de porcentajes (ver tabla 25).

2. En la condición que se establece si trabajamos con intervalos o, por el contrario, con un operador y un valor (ver tabla 24).



e) Consultas en bloque

Es el primero de los tipos de consulta disponibles en el Generador. Nos permite repre-sentar, usando una gama de colores, las entidades de la unidad mínima seleccionada presentes en el área de estudio elegida.

El resultado son intervalos y colores graduados que representan una progresión de va-lores numéricos (cualquiera de los que toman las variables disponibles citadas en las tablas 11, 12, 13, 14 y 15 (pág. 81 y siguientes).

La selección de una de estas variables de estudio se efectúa desde el menú desplegable correspondiente (fig. 62)

Se han implementado cuatro posibles métodos para el cálculo de intervalos que nos clasificarán los valores de la variable de estudio.

1. Intervalos iguales dado el número de intervalos 2. Intervalos iguales dada la amplitud del intervalo 3. Cuantiles 4. Cortes naturales (Jenks)

El método es seleccionable desde un menú desplegable (fig. 63)


Figura 62. Menú desplegable de selección de variable de estudio en el Generador

Figura 63. Menú desplegable de selección de método de clasificación en intervalos en el Generador


En todos ellos, el tipo de consulta SQL es cualquiera de los siguientes: A2, B4, C4, B5 ó B6, C5 ó C6, A2, B4, C4, B5 ó B6, C5 ó C6 (dependiendo del tipo de dato elegido –nº ó cualquiera de los %–, ver tabla 23, pág. 110).

Internamente, el sistema asigna para estas consultas los valores “> ó =” al operador y “0” al valor de la variable.

Con todo, el xml que se nos devuelve tras la consulta SQL a la base de datos, contiene un listado ordenado de los valores que toma la variable en cada una de las entidades que intervienen en la consulta.

Este listado ordenado de valores es el que, después, en JavaScript, nos encargamos de clasificar dependiendo del método de clasificación en intervalos elegido.

La selección del tipo de dato al que nos referíamos un poco más arriba, también se rea-liza mediante un menú desplegable (fig. 64).

Explicaremos ahora estos diferentes tipos de datos disponibles:

1. nº . Valores de las variables en el formato en que aparecen en la base de datos.2. % (en el Área de estudio) . Valores en formato de porcentaje. El % es calculado

en base a la suma total de los valores de la variable en el área de estudio.3. % (en toda la Diócesis) . Valores en formato de porcentaje. El % es calculado en

base a la suma total de los valores de la variable en toda la Diócesis.4. % del TOTAL padre (en el Área de estudio) . Valores en formato de porcentaje.

El % es calculado en base a la suma total de los valores de la “variable madre” en el área de estudio.

5. % del TOTAL padre (en toda la Diócesis) . Valores en formato de porcentaje. El % es calculado en base a la suma total de los valores de la “variable madre” en toda la Diócesis.

A modo de ejemplo: elegida la variable “Extranjeros atendidos”, si escogemos el tipo de dato 3, obtendremos, para cada entidad, el % de extranjeros en toda la Diócesis que han sido atendidos en dicha entidad. Sin embargo, escogiendo el tipo de dato 4, obten-dremos el % de extranjeros atendidos en esa entidad del total de atendidos en el área.


Figura 64. Menú desplegable de selección del tipo de dato a utilizar en cada consulta “En

bloque” en el Generador


En el caso de los tipos de dato 4 y 5, hablamos de una “variable madre” (ver tabla 25, pág. 112). Se trata de una variable respecto de la cual queremos calcular el porcentaje de otra.

Contamos con varios bloques de variables que se prestan a este tipo de análisis. Cuan-do elegimos alguno de estos dos tipos, la lista de variables se actualiza mostrando úni-camente aquéllas que permiten este tipo de análisis.

Los bloques de variables que permiten este análisis son los siguientes:

1. Voluntarios . Variables de la tabla 12 (pág. 82), tomando como “variable madre” el “TOTAL de voluntarios”, suma de referencia para el cálculo del porcentaje.

2. Ingresos .Variables de la tabla 14 (pág. 83), tomando como “variable madre” el “TOTAL de ingresos”, suma de referencia para el cálculo del porcentaje.

3. Gastos . Variables de la tabla 15 (pág. 83), tomando como “variable madre” el “TOTAL de ingresos”, suma de referencia para el cálculo del porcentaje.

4. Hombres / Mujeres atendidos . Dos variables en las que se toma como “variable madre” la suma de ambas.

5. Españoles / Extranjeros atendidos . También dos variables en las que se toma como “variable madre” la suma de ambas.

El penúltimo aspecto a reseñar en esta explicación general del modo de consulta “En bloque”, es la selección de colores: en el panel, elegiremos un color inicial y un color final, entre los cuales se calculará una rampa de color graduada.

Para el cálculo de esta rampa de color, partimos de los valores (R, G, B) de los colores inicial (R1, G1, B1) y final (R2, G2, B2). Conocido el número de intervalos (n), calcu-lamos los correspondientes incrementos:

• Incremento de Rojo = (R2-R1)/n

• Incremento de Verde = (G2-G1)/n

• Incremento de azul = (B2-B1)/n

Estos incrementos los vamos sumando a los valores (R1, G1, B1) iniciales para conse-guir los colores de la rampa. Precauciones que hemos de tomar: los incrementos han de ser números enteros y, para que podamos utilizar los colores en JavaScript/CSS, hemos de convertirlos, una vez calculados, a formato hexadecimal.

Para terminar, también reseñaremos que la entrada de datos mediante la caja de texto en la que debemos introducir los valores deseados, está controlada para evitar la intro-



ducción de valores erróneos o incongruentes. Así, si el formato introducido es inco-rrecto, o si el número es inapropiado (número de intervalos demasiado grande...) se nos lanzará un mensaje de alerta para que lo subsanemos.

f) Consulta en bloque con intervalos iguales dado el número de intervalos

El método de clasificación de intervalos iguales divide el rango de valores de la varia-ble de estudio en rangos de igual tamaño.

En este caso en el que se facilita el número de intervalos (n), calcularemos la amplitud (amp) de intervalo de la siguiente forma:

amp=valor máximo−valor mínimo

n

A modo de ejemplo, aportamos el resultado de la clasificación por este método de la variable “Total de beneficiarios”, tomando como unidad mínima la de arciprestazgo y como área de estudio todas las vicarías.


Figura 65. Ejemplo de clasificación con intervalos iguales dado el número de intervalos


g) Consulta en bloque con intervalos iguales dada la amplitud del intervalo

Utilizando el mismo ejemplo que en el punto anterior, pero esta vez indicando la am-plitud de intervalo en lugar del número, obtenemos el siguiente resultado. En aparien-cia el mismo, ya que hemos elegido una amplitud muy similar a la que se había calcu-lado en el apartado anterior.

h) Consulta en bloque por cuantiles

En el método de clasificación por cuantiles, los valores se dividen de forma que cada clase o rango de valores contenga el mismo número de elementos.

Lógicamente, el reparto ha de ser de elementos enteros. En caso de obtener una frac-ción decimal al dividir el número de elementos entre el número de intervalos, el redon-deo será a la baja y el número de elementos que sobrarían al terminar el reparto serían distribuidos, uno a uno, entre los primeros intervalos. Ejemplo, en el reparto de 11 ele-mentos en 3 intervalos, tocarían a 3,6; redondeando a 3, el reparto final sería: 4 , 4 y 3.


Figura 66. Ejemplo de clasificación con intervalos iguales dado la amplitud del intervalo


Como ejemplo para este método (fig. 67), escogemos la variable de “atendidos que han acudido por primera vez”, con el tipo de dato “% (en el Área de estudio)” y representa-da con la unidad mínima de arciprestazgo para las vicarías I y II.

i) Consulta en bloque por cortes naturales (Jenks)

Los intervalos por cortes naturales son el método de clasificación que, para crear cla-ses, identifica saltos de valor importantes en la secuencia de valores.

Para ello, el método de optimización de Jenks (26) utiliza un algoritmo que minimiza las varianzas dentro de cada grupo con lo que, de manera implícita, también maximiza la varianza entre los grupos.

El uso del algoritmo puede ser ilustrado en cuatro pasos:

1. El usuario selecciona la variable (x) cuya distribución de datos se desea clasifi-car y especifica el número de grupos o clases (k) en los que desea agrupar di-chos datos.


Figura 67. Ejemplo de clasificación por cuantiles


2. Generamos un conjunto de k-1 valores aleatorios o uniformes en el rango [min {x}, max {x}]. Estos valores se utilizan como límites de clase inicial.

3. Para cada una de esas clases iniciales, calculamos su media de valores z j

y el sumatorio de cada una de las varianzas, varianza de cada valor del grupo con respecto a su media. Almacenamos como SDCM la suma de todos estos su-matorios de varianzas:

SDCM=∑j=1

k

∑i=1

N j

zij− z j

4. Finalmente, asignamos iterativamente los valores individuales de cada catego-ría a clases adyacentes mediante el ajuste de los límites de clase verificando que el SDCM se reduce. Este proceso iterativo termina cuando la reducción del SDCM está por debajo de un umbral prefijado; es decir, cuando la varianza dentro de cada grupo es lo más pequeña posible, e implícitamente la variación entre las clases es lo más grande posible.

Un modo de comprobar la bondad del ajuste, es evaluar el resultado de la variable GVF (Goodness of Variance Fit).

GVF=1−∑j=1

k

∑i=1

N j

zij−z j

∑i=1

N

zi−z

=SDAM−SDCM

SDAM

Los valores de GVF estarán entre 0 y 1; cuanto más cercano a 1 sea, mejor bondad de ajuste tendremos.

Por lo tanto, para obtener un buen ajuste de cortes naturales, lo conveniente es hacer diferentes pruebas eligiendo distintos números de intervalos. Así, podremos comparar los valores de GVF, y el que nos lo proporcione más alto, será la mejor configuración posible.

Antes de mostrar un ejemplo, comentar que para la implementación de este método, nos hemos apoyado parcialmente en la pequeña librería geostat (14).

Como ejemplo de este método de clasificación (fig. 68), hemos configurado el siguien-te mapa temático: % de extranjeros atendidos (respecto al total de españoles y extranje-ros atendidos en el área de estudio), representado con la unidad mínima de arciprestaz-go tomando como área de estudio todas las vicarías.



Para ver gráficamente la clasificación efectuada, mostramos por último el histograma de los valores clasificados con los cortes realizados


Ilustración 69: Histograma de valores clasificados por cortes naturales (Método de Jenks)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

0

2

4

6

8

10

12

14

Figura 68. Ejemplo de clasificación por cortes naturales. Método de Jenks


j) Consulta individual

Es el segundo de los tipos de consulta disponibles en el Generador. Nos permite hacer consultas individuales a la base de datos, preguntando por las entidades de la unidad mínima de análisis seleccionada que cumplen unas determinadas condiciones en el área de estudio elegida.

Una característica interesante de este tipo de consulta, es que permite que cada una de éstas sea añadida al mapa y al informe, si se da el caso, junto a las consultas que ya existan en ellos (resultados de consultas de tipo “Individual”, “En bloque” o de “Situa-ciones”).

La configuración de cada consulta pasa por establecer los siguientes parámetros (muy similar en muchos puntos al procedimiento de las consultas “En bloque”):

1. Selección del tipo de dato con el que trabajaremos en la consulta. A elegir entre los mismos que describíamos en la página 114. Su elección se realiza mediante un menú desplegable (fig. 70).

Todo lo explicado en la página 115 respecto a los dos últimos tipos de datos, también es aplicable en este modo de consultas.

2. Selección de una de las variables de estudio disponibles . También se efectúa desde el menú desplegable correspondiente (fig. 72).


Figura 70. Menú desplegable de selección del tipo de dato a utilizar en cada consulta

“Individual” en el Generador

Figura 71. Menú desplegable de selección de la variable de estudio a utilizar en cada consulta “Individual” en el Generador


3. Selección del operador y del valor que determinarán la condición de consulta. El primero de ellos se elige desde un menú desplegable (fig. 72). El segundo se introduce desde un campo de entrada de texto que hay a su derecha.

Respecto al operador, decir que hay disponibles los siguientes:

• =

• >

• <

• > ó =

• < ó =

• Intervalo: número 1 – número 2. Si elegimos este último, deberemos intro-ducir dos números separados por un guión. Serán los límites menor y mayor entre los cuales deberán estar los valores de la variable de estudio.

Respecto al campo de entrada de texto, decir que, al igual que ocurría con el de consultas “En bloque”, está controlado su contenido para no rellenarlo en for-mato equivocado o inapropiado. Si así fuera, se lanzaría un mensaje de alerta advirtiéndolo y no se efectuaría la consulta hasta que se subsanase dicha cir-cunstancia.

El tipo de consulta SQL en este modo “Individual” es cualquiera de los presentados en la tabla 23 (pág. 110).

Con todo, el xml que se nos devuelve tras la consulta SQL a la BD, contiene un listado ordenado de los valores que toma la variable en cada una de las entidades que intervie-nen en la consulta por cumplir las condiciones de búsqueda: unidad mínima, área de estudio y operador más valor o valores de intervalo de la variable.

A modo de ejemplo, presentamos el siguiente mapa (fig. 73) en el que se han incluido dos consultas:

1. Cáritas de la vicaría II que tienen menos de 10 voluntarios de 21 a 30 años.2. Cáritas de la vicaría I que tienen 10 o más voluntarios de entre 21 y 30 años.


Figura 72. Menú desplegable de selección del operador en cada consulta “Individual” en el Generador


k) Consulta de situaciones más frecuentes

Se trata del tercer modo de consulta implementado en el Generador de mapas. Selec-cionadas la unidad mínima de análisis y el área de estudio, podemos realizar mapas te-máticos en los que observar cuáles son las situaciones que más frecuentemente se pre-sentan en los punto de atención de Cáritas.

Se pueden consultar las que aparecen más frecuentemente en primero, segundo, tercero o cuarto lugar. Los valores de la base de datos que se consultan son los que aparecen en la tabla 16 (pág. 84) que se corresponden a las siguientes situaciones:

1. Inmigrantes sin papeles que buscan trabajo.2. Inmigrantes con Permiso de Residencia y Trabajo que buscan trabajo.3. Familias con algún enfermo en casa que necesita ayuda.4. Problemas de drogas en la familia.5. Mujeres solas con cargas familiares.6. Ancianos solos.7. Familias españolas con dificultades económicas.8. Familias con algún enfermo mental.9. Problemas de vivienda.10. Transeúntes de paso


Figura 73. Ejemplo de mapa temático construido con consultas individuales


El sistema es sencillo: cada Cáritas parroquial indica anualmente a través de su memo-ria (ver punto 2.4. de la fig. 26 pág. 73) cuáles son las tres situaciones que se les pre-sentan más frecuentemente.

Cada una de esas tres situaciones aparecerá con el valor 1 en el registro correspondien-te a esa Cáritas en la base de datos, por lo que la consulta de cuáles son las cuatro más frecuentes en un arciprestazgo, vicaría o comarca, será inmediata haciendo la suma de las veces que aparece cada situación y discriminando las cuatro que tienen sumas ma-yores.

Como ejemplo, presentamos el siguiente mapa (fig. 74) en el que se pueden observar, por comarcas, las situaciones más frecuentes que se presentan en todo el territorio que atiende Cáritas Valencia.


Figura 74. Ejemplo de mapa temático de situaciones más frecuentes


l) Trabajando con las capas de información

Como ya hemos comentado anteriormente, el objetivo final del Generador es poder construir mapas temáticos a partir de los datos estadísticos disponibles.

Estos mapas podrán ser utilizados de diferentes modos: ilustrando informes, acompa-ñando los distintos apartados de la memoria anual (1) que publica Cáritas y presenta ante los medios y la sociedad, apoyando presentaciones de diapositivas en ruedas de prensa, en reuniones de trabajo, de planificación...

Por tanto, ya que las finalidades y los destinatarios pueden ser múltiples, la aplicación nos ha de permitir un amplio margen de personalización de cada mapa.

La sección que describiremos ahora, nos ofrece grandes posibilidades para tal propósi-to. Se dispone en el panel lateral de herramientas justo debajo de la sección de tipos de consulta y tiene el siguiente aspecto (fig. 75).

Explicaremos uno a uno los distintos elementos del panel:

1. Casillas de verificación de la parte superior :

• Consultas: activa / desactiva la visualización de las entidades dibujadas en el mapa como resultado de las consultas.

• Leyenda: activa / desactiva la visualización de la leyenda descriptiva de las consultas presentes en el mapa.

• Fondo negro y fondo blanco: activan / desactivan la presencia de un fondo negro o blanco respectivamente. Estos fondo ocultan la cartografía base de Google Maps y pueden ser útiles para resaltar la simbología de colores del mapa temático generado. El fondo negro está pensado especialmente para presentaciones de diapositivas (mayor contraste en la proyección), mientras que el blanco resulta más apropiado para incluirlo en documentos impresos.

• Escala: activa / desactiva la visualización de la escala gráfica de Google Maps en la ventana de mapa.


Figura 75. Sección “Capas visibles” en el panel lateral de herramientas del

Generador


• Controles: activa / desactiva la visualización de los controles de posición, escala y selección de cartografía base.

2. Etiquetas de las consultas : su casilla de verificación activa / desactiva la visuali-zación de las etiquetas correspondientes a las consultas en el mapa.

Por otro lado, los distintos controles que le acompañan, nos permiten personali-zar la visualización de estas etiquetas, tanto en formato como en contenido.

En cuanto al formato, podemos configurar:

• Color del texto de la etiqueta: entre blanco o negro.

• Tamaño del texto de la etiqueta: entre cuatro niveles diferentes.

En cuanto al contenido, podemos configurar qué información mostrar en la eti-queta, entre las siguientes:

• Id: número identificador de la entidad que representa.

• Nombre: nombre descriptivo de esa entidad.

• Valor: valor numérico que toma la variable de estudio en la consulta efectuada.

3. Límites : este apartado nos permite mostrar u ocultar los límites de las distintas entidades poligonales con las que trabajamos en el proyecto (parroquias, arciprestazgos, vicarías y comarcas) para incluirlos o no en el mapa como elementos de cartografía base. Para cada uno de ellos podemos configurar el color y el grosor del trazo.

Vinculado a los límites, un elemento explicativo de ellos que podemos mostrar en el mapa es una Leyenda descriptiva de estos. A través de su correspondiente casilla de verificación, se muestra u oculta en el mapa.

Para terminar este subapartado, haremos tres consideraciones finales:

1. Movilidad de elementos (leyendas y etiquetas) . Los dos tipos de leyendas y las etiquetas de cada entidad dibujada en el mapa pueden desplazarse manualmente para buscar su posición estética más idónea. Una vez movido cada elemento, su posición de conserva aunque desactivemos y activemos su visualización.

Para mover un elemento, deberemos pinchar sobre su punto de desplazamiento situado un poco por encima de él en su parte superior izquierda. Al pinchar so-bre este punto y desplazarlo un poco, comprobaremos cómo nos acompaña una pequeña marca de posición en forma de aspa (fig. 76).



2. Adaptabilidad de la disposición del contenido de las etiquetas dependiendo de los elementos seleccionados para mostrar en ellas. Dependiendo de la combina-ción de elementos que elijamos para mostrar en las etiquetas (de entre los 3 dis-ponibles), la disposición de los mismos, será una u otra. Mostramos en la figura 77 algunos ejemplos.

3. Actualización inmediata en el mapa de los cambios que se realizan en los con - troles de capas. Todo cambio que realicemos en los controles de capas, se trasla-dará inmediatamente a lo mostrado en el mapa.

Así, por ejemplo, los cambios de grosor o color en los límites, se verán refleja-dos de manera inmediata tanto en los propios límites dibujados en el mapa como en la leyenda descriptiva de los mismos.

Del mismo modo, los cambios en la configuración de etiquetas, tanto en forma-to como en contenido, también ser verán trasladados al mapa al instante.


Figura 76. Ejemplos de cómo desplazar etiquetas y leyendas en el Generador

Figura 77. Ejemplos de disposición de elementos en las etiquetas del Generador


m) Generación de informes sobre las consultas

La información asociada a cada consulta (entidades que intervienen, valores que toman en la variable de estudio, detalle de las clasificaciones...) es recogida en un informe que podemos imprimir directamente o ver en modo de vista previa.

La información se añade al informe tras realizar una consulta. Se añade con los mismo criterios que lo hace al incorporarse al mapa. Es decir, las consultas de tipo “Indivi-dual” se irán añadiendo al informe conservando las que haya antes, si las hay, y a no ser que utilicemos el botón “Limpiar consultas” para empezar de cero. Las consultas “En bloque” o de “Situaciones” se añadirán al informe borrando previamente lo que tu-viera contenido.

Los botones de imprimir y de vista previa, se encuentran en la sección “Informe“, en la parte inferior del panel lateral (ver fig. 78)

En las siguientes figuras 79 y 80, podemos ver dos ejemplos de informe: El primero, correspondiente a dos consultas en modo “individual” y, el segundo, refleja los resulta-dos de una consulta “En bloque”.


Figura 78. Generador de Mapas: Sección Informe

Figura 79. Ejemplo 1 de informe en el Generador de Mapas



Figura 80. Ejemplo 2 de informe en el Generador de Mapas


4.8.4. Algunos ejemplos de mapas resultantes

Mostraremos en este apartado final del Generador, algunos mapas temáticos resultan-tes tal y como quedarían preparados para incluirlos en informes, presentaciones, publi-caciones...


Figura 81. Ejemplo final 1 del Generador de Mapas



4.9. Introducción y edición de datos con Drupal

Una vez implementadas las dos aplicaciones, Localizador y Generador, sólo nos falta-ba conseguir un modo sencillo de poder introducir nuevos datos y editar los existentes.

Esta tarea podría resultar fácil si contáramos con unos cuantos formularios, uno por cada tipo de dato de los que aparecen en el Localizador (Cáritas Parroquiales, Centros Municipales de Servicios Sociales. Contenedores de la Fundación INTRA, Tiendas @rropa y Otros Recursos),

Para tal propósito, nos decidimos a utilizar, como base, el potente gestor de contenidos Drupal.

4.9.1. Adaptación del contenido al sistema de Drupal

Como ya indicamos en el apartado 4.6. (pág. 78), inicialmente, la definición de las ta-blas MySQL se hizo utilizando phpMyAdmin. Pero cuando quisimos migrar los datos a la nueva base de datos en la que se instaló Drupal, hubo que adaptar las tablas y defi-




nirlas de nuevo, sobre todo las tablas compartidas con Drupal, las de tipo 1 (véase apartado 4.6.1., pág. 80).

Para ello, se utilizó una definición compartida: primero se definieron desde el gestor de tipos de contenido de Drupal para después retocarse mínimamente algunos campos con phpMyAdmin, ya que la definición en Drupal ofrece menos posibilidades que en phpMyAdmin.

Por otro lado, otro aspecto a reseñar en la importación de los datos a Drupal es que, una vez definidas las tablas, la importación de los datos se hizo de forma masiva a través de phpMyAdmin utilizando ficheros csv.

Ahora bien, a la hora de incluir nuevos contenidos en la tablas de cada tipo de conteni-do de Drupal, también tuvimos que tener en cuenta que hay otras cuatro tablas de ad-ministración interna que son afectadas cada vez que se añade contenido desde los for-mularios de esta plataforma. Las tablas son:

• history

• node

• node_comment_statistics

• node_revisions

A continuación se muestran, a modo de ejemplo, el contenido de los archivos csv y sql que se han tenido que generar para poder rellenar estas tablas manualmente en los re-gistros correspondientes a las tiendas @rropa. Este paso es imprescindible para garan-tizar la integridad del sistema y que así funcione correctamente tras la importación ma-siva de datos a través de phpMyAdmin.

history.csv

"1";"737";"1307783165" "1";"738";"1307783166" "1";"739";"1307783167" "1";"740";"1307783168" "1";"741";"1307783169" "1";"742";"1307783170" "1";"743";"1307783171" "1";"744";"1307783172" "1";"745";"1307783173" "1";"746";"1307783174" "1";"747";"1307783175"

node.csv

"737";"737";"tiendas_arropa";"es";"Calle Serranos";"1";"1";"1307783165";"1307783165";"0";"0";"0";"0";"0";"0" "738";"738";"tiendas_arropa";"es";"Calle República Argentina";"1";"1";"1307783166";"1307783166";"0";"0";"0";"0";"0";"0" "739";"739";"tiendas_arropa";"es";"Calle Abadía";"1";"1";"1307783167";"1307783167";"0";"0";"0";"0";"0";"0"



"740";"740";"tiendas_arropa";"es";"Calle Puçol (barrio de Benimaclet)";"1";"1";"1307783168";"1307783168";"0";"0";"0";"0";"0";"0" "741";"741";"tiendas_arropa";"es";"Calle Alicante";"1";"1";"1307783169";"1307783169";"0";"0";"0";"0";"0";"0" "742";"742";"tiendas_arropa";"es";"Calle Colón";"1";"1";"1307783170";"1307783170";"0";"0";"0";"0";"0";"0" "743";"743";"tiendas_arropa";"es";"Avenida Primado Reig";"1";"1";"1307783171";"1307783171";"0";"0";"0";"0";"0";"0" "744";"744";"tiendas_arropa";"es";"Calle Racó de San Llorenç";"1";"1";"1307783172";"1307783172";"0";"0";"0";"0";"0";"0" "745";"745";"tiendas_arropa";"es";"Calle Calvario";"1";"1";"1307783173";"1307783173";"0";"0";"0";"0";"0";"0" "746";"746";"tiendas_arropa";"es";"Calle Botánico Cavanilles";"1";"1";"1307783174";"1307783174";"0";"0";"0";"0";"0";"0" "747";"747";"tiendas_arropa";"es";"Calle San Eloy";"1";"1";"1307783175";"1307783175";"0";"0";"0";"0";"0";"0"

node_comment_statistics.sql

INSERT INTO `node_comment_statistics` (`nid`, `last_comment_timestamp`, `last_comment_name`, `last_comment_uid`, `comment_count`) VALUES (737, 1307783165, NULL, 1, 0), (738, 1307783166, NULL, 1, 0), (739, 1307783167, NULL, 1, 0), (740, 1307783168, NULL, 1, 0), (741, 1307783169, NULL, 1, 0), (742, 1307783170, NULL, 1, 0), (743, 1307783171, NULL, 1, 0), (744, 1307783172, NULL, 1, 0), (745, 1307783173, NULL, 1, 0), (746, 1307783174, NULL, 1, 0), (747, 1307783175, NULL, 1, 0);

node_revisions.csv

"737";"737";"1";"Calle Serranos";;;;"1307783165";"0" "738";"738";"1";"Calle República Argentina";;;;"1307783166";"0" "739";"739";"1";"Calle Abadía";;;;"1307783167";"0" "740";"740";"1";"Calle Puçol(barrio de Benimaclet)";;;;"1307783168";"0" "741";"741";"1";"Calle Alicante";;;;"1307783169";"0" "742";"742";"1";"Calle Colón";;;;"1307783170";"0" "743";"743";"1";"Avenida Primado Reig";;;;"1307783171";"0" "744";"744";"1";"Calle Racó de San Llorenç";;;;"1307783172";"0" "745";"745";"1";"Calle Calvario";;;;"1307783173";"0" "746";"746";"1";"Calle Botánico Cavanilles";;;;"1307783174";"0" "747";"747";"1";"Calle San Eloy";;;;"1307783175";"0"


Figura 84. Página de acceso al administrador implementado en Drupal


4.9.2. Funcionalidades

Terminaremos el epígrafe dedicado a este sistema de administración del contenido im-plementado con Drupal, señalando sus principales funcionalidades:

1. Permite editar y añadir información de los tipos de contenido utilizados en el proyecto.

2. Diferencia entre los privilegios y permisos de los distintos usuarios para que cada uno sólo pueda modificar o añadir los datos que le corresponden.

3. Facilita a nuevos usuarios (entidades del ámbito social) dar de alta nuevos re-cursos en el sistema desde la categoría “Otros Recursos”.


Capítulo 5Cierre

5.1. Informe sobre el grado de cumplimiento de los objetivos marcados

5.1.1. Desde Utópika

Los objetivos generales de Utópika en relación al trabajo final de carrera realizado, se han cumplido al cien por cien. El proyecto ha servido para poner de manifiesto que es posible conectar las estructuras de investigación de la Universitat Politècnica de Va-lència con las necesidades e intereses de colectivos ciudadanos; y acercar la enseñanza universitaria a las realidades sociales / locales.

La metodología de desarrollo del proyecto, centrada en la Investigación Acción Partici-pativa, ha facilitado que los diferentes integrantes del proyecto (el alumno, Cáritas y Utópika) participaran activamente en el proyecto y colaboraran para alcanzar los obje-tivos marcados. En este sentido, es destacable la labor realizada por Nuria Baeza, des-de Cáritas Valencia. Su enorme dedicación ha permitido contar con un alto grado de participación de todas las personas de su organización relacionadas con el proyecto. La participación activa de Cáritas desde el inicio ha sido uno de los puntos fuertes del pro-yecto.

Por otro lado, el proyecto ha servido para crear una oportunidad de aprendizaje para to-das las personas que hemos participado en su desarrollo. Es necesario destacar, la enor-me implicación del alumno, Lorenzo Sicilia. Su capacidad de aprendizaje, de supera-ción ante las dificultades, tanto técnicas como metodológicas, junto con su generosidad y calidad humana, han servido para hacer del TFC una experiencia de aprendizaje alta-mente positiva y enriquecedora para todas las personas implicadas.



En definitiva, el desarrollo del TFC aquí expuesto, ha permitido crear oportunidades de aprendizaje para todos los participantes, tanto estudiante y profesores, como miembros de la organización social y de Utópika.

5.1.2. Desde Cáritas

Tras un tiempo de utilización de las dos herramientas desarrolladas y teniendo en cuen-ta los objetivos que planteábamos inicialmente, desde Cáritas podemos aportar las si-guientes datos a modo de valoración.

a) Localizador de Recursos

La utilidad de esta herramienta es enorme por varias razones;

1. Reduce de 5 minutos (media aproximada) a 10 segundos (aproximadamente) la búsqueda de la información. Con lo que este tiempo puede ser utilizado en aten-der durante más minutos a las personas a lo largo de la entrevista en el Servicio de Acogida.

2. Aumenta el número de personas atendidas. Haciendo un cálculo aproximado, sólo en el Servicio de Acogida de la sede central encontramos que; con los mi-nutos que ahorran las voluntarias que atienden cada día a 20 personas (20 pax x 5 min = 100 min) diariamente se puede atender a 3 personas más durante 30 mi-nutos cada una. Por cada 5 días de atención semanales (3x5=15 pax) y por cada 4 semanas al mes (15x4=60); a lo largo de 10 meses, habremos atendido a 600 personas más aproximadamente al año…Y esto sólo en el servicio de la sede central. Si lo ampliamos a las consultas que pueden hacerse desde cualquiera de los 400 puntos de la red… el efecto se multiplica de manera asombrosa.

3. Se puede acceder a la herramienta desde cualquier ordenador, por lo que la con-sulta se puede realizar directamente por los usuarios que ahorrarían tiempo diri-giéndose directamente al punto de atención correcto.

4. Es una herramienta abierta a otras instituciones y entidades fuera de Cáritas que podrían añadir sus puntos de atención, ampliando así la red de servicios disponi-bles para su consulta. Es decir, potencia la coordinación y el trabajo en red.

5. La información está actualizada ya que se han diseñado los mecanismos de ac-tualización de los datos de manera que se pueda garantizar que los datos publi-cados en la herramienta son los últimos disponibles.

6. Mejora la coordinación y el trabajo de intervención con las personas. Las deri-vaciones y la información correctas redundan directamente en el trabajo, se


Capítulo: Cierre

evitan derivaciones improcedentes, se ahorran desplazamientos y pérdidas de tiempo, al conocer los horarios y días de atención de cada punto, se pueden pla-nificar los desplazamientos y las intervenciones sociales mejor.

7. Se reducen los microestresores. Según las propias palabras de las voluntarias que ya utilizan esta herramienta, la velocidad y certeza de las búsquedas les ahorran muchos momentos de tensión en los que retrasar la respuesta por no en-contrar la información; esto antes creaba situaciones incómodas y tensas en las entrevistas. La sensación de eficacia y seguridad que han ganado les ahorra mu-cha tensión y al estar más relajadas, consideran que excusan, atienden y acogen mejor a los destinatarios.

8. Se ha dado respuesta a una demanda muy antigua que venían realizando los ser-vicios de Acogida.

9. La satisfacción de las usuarias es muy alta. Los comentarios y alabanzas que ha recibido esta herramienta por parte de las usuarias son enormemente positivos. En la próxima encuesta de satisfacción que realizaremos en 2011, se arrojarán datos acerca de la satisfacción en la atención que experimentan las personas atendidas.

Una vez más, el espíritu de la mejora continua ha dado como resultado una herramien-ta que se adapta perfectamente a las necesidades de las personas que están en contacto directo con nuestros destinatarios finales y que son sensibles a las necesidades de es-tos, requiriendo, sobre todo, celeridad en las respuestas, seguridad en la información que se les da y una atención personal, individualizada, cálida y de calidad.

Además, compartir la iniciativa con una entidad como Utópika, trabajar de algún modo la responsabilidad social con la Universidad, facilitar el uso de tecnología avanzada, socializar la información, ser más transparente en la gestión al permitir compartir la in-formación y el trabajo en red con otras entidades que van a localizar sus recursos sobre el mismo mapa, son todas enseñanzas que nos hablan de rentabilizar recursos, de Ges-tión del conocimiento, Responsabilidad Social, Concienciación Social, Alfabetización Digital y sobre todo… y lo más importante, tomar conciencia una vez más de que to-das nuestros esfuerzos y acciones deben estar alineadas en pro de la atención a los últi-mos y más desfavorecidos.

b) Generador de mapas

El generador de mapas nos facilita todo un análisis geográfico de los datos que hasta ahora quedaba fuera del alcance de Cáritas. Un análisis que puede comparar los datos



que generamos con otras fuentes geoestadísticas. Nos permite mejorar el diseño de nuestras intervenciones, destinando los recursos adecuados o definiendo líneas de actuación nuevas.

Al abrirse la posibilidad de realizar análisis combinando datos propios y ajenos, pode-mos planificar intervenciones más ágiles y rentables, que impliquen a los territorios de los que traten los datos.

El generador nos ayuda en las acciones de denuncia social, facilita la visualización de los datos y nos ofrece una herramienta importante para suministrar datos a los medios de comunicación social.

El generador, pone a disposición de los técnicos de Cáritas que trabajan directamente en el territorio, la posibilidad de realizar análisis de los datos de la última memoria de manera que pueden planificar mejor su intervención y su trabajo cotidiano.

Es una herramienta que facilita la ilustración de los informes que realiza el Departa-mento de Análisis de la Realidad, haciéndolos más accesibles.

Abre la posibilidad de consultas on line sobre los resultados de las memorias para los técnicos en el territorio, dotándoles de mayor autonomía y rapidez en la preparación de reuniones, recopilación de datos para encuentros con corporaciones locales, entidades y las mismas Cáritas interparroquiales, arciprestales y comarcales.

Esta herramienta cumple así con un viejo anhelo de Cáritas Diocesana de Valencia que siempre ha querido mostrar la imagen de la pobreza y exclusión con la que trabajamos en un soporte visual que haga más fácil la comprensión de la realidad social de nuestra Diócesis con la esperanza de concienciar a la sociedad y a las fuerzas políticas de que es necesario trabajar conjuntamente para construir una sociedad más Justa, Fraterna y Solidaria.


Capítulo 6Conclusiones

6.1. Valoración personal

A nivel general, puedo decir, claramente, que ha sido muy gratificante todo lo relacio-nado con la realización de este Trabajo Final de Carrera. Fue necesario que se dieran unas pocas casualidades, quizá no tan casuales, para que se me brindara la posibilidad de participar en un proyecto tan interesante como el de la iniciativa Utópika, red de in-vestigación participativa en la UPV.

En un trabajo donde el componente humano ha sido tan importante, no puedo evitar dedicar unas líneas al respecto en esta valoración personal. Importante, en primer lu-gar, por la gran calidad humana de las personas con las que he tenido la suerte de tra-bajar. Personas que sueñan que otro mundo es posible y, desde esa base, con ilusión y entrega, ofrecen su esfuerzo, trabajo y conocimientos para que, cada día, ese sueño se vaya haciendo realidad. Vidas entregadas para que las vidas de otros sean más dignas. Y desde esta última idea, apunto el segundo motivo por el que considero tan importan-te el componente humano de este trabajo. Para mí, ha sido una suerte el poder finalizar estos estudios de ingeniería con un trabajo que no acabará guardado en un cajón; es más, con un trabajo que ha venido a cubrir unas necesidades reales; necesidades en el acompañamiento y ayuda a personas y colectivos que socialmente a veces condenamos al olvido de la exclusión. Haber podido aportar un pequeño granito de colaboración en el trabajo por la justicia, palabras tan presentes en Cáritas, ha sido el mejor modo de concluir estos estudios.

El proyecto también ha supuesto para mi una gran oportunidad de aprendizaje en va-rios ámbitos. Primero en el campo de la Investigación Acción Participativa (IAP) y, se-gundo, en el mundo infinito de la informática, explorando terrenos poco transitados por mí hasta ahora como la programación web y su diseño en CSS, la API de Google



Maps, diseño gráfico... La IAP, desde la iniciativa Utópika en la UPV, ha sido todo un descubrimiento. Los dos cursos que hemos podido disfrutar este año en el CFP y la experiencia, en general, de trabajar la investigación participativa, me han aportado nuevas perspectivas y han ensanchado mi horizonte haciéndome ver nuevas posibilidades de poner al servicio de la sociedad todo lo aprendido en la universidad. Asimismo, el estrecho trabajo con Cáritas y Utópika y todas las ventajas del trabajo en común que hemos ido experimentando, me siguen animando al trabajo en equipo, de manera colaborativa, siempre sumando, apoyando...

También ha sido mucho lo aprendido en aspectos técnicos. Es fácil ser consciente de ello echando la vista atrás algunos meses.

Con todo, el camino no ha estado exento de dificultades. La planificación temporal ha sido un punto débil en el TFC. Ha sido difícil el ir estimando el tiempo de realización de las distintas tareas; en parte quizá por la novedad de muchas técnicas, pero también por ser optimista en exceso en la valoración del coste temporal del trabajo. Pero gra-cias al trabajo en equipo, estas carencias se fueron supliendo con trabajo gradual, por fases, asegurando el ir alcanzado pequeñas metas.

La apuesta por el software libre ha tenido muchas ventajas y ha sido una opción clara en busca de coherencia con el trabajo realizado. Aunque también ha supuesto algún pe-queño quebradero de cabeza, por ejemplo a la hora de instalar Google Earth en Ubuntu o, lo último, al complicarse la corrección ortográfica de este documento. En este senti-do, algunos procesos del TFC, como la generación de información geográfica, podrían haber sido más rápidos con software comercial, pero quisimos mantener la fidelidad a esta opción por el software libre y quizá, gracias a ello, el aprendizaje en muchos as-pectos también haya sido mayor.

También fue una decisión importante el cambio, a mitad de proyecto, de la versión 2 de la API de Google Maps, a la versión 3 (la más reciente y actual). Aunque aparente-mente supusiera un “volver a empezar”, realmente fue la circunstancia que provocó el mayor aprendizaje y comprensión de la API, del JavaScript y de toda la metodología general de trabajo (estructuración del código, optimización, etc).

Finalmente, no puedo hacer otra cosa que agradecer todo el apoyo recibido para la con-clusión de este trabajo, a la vez que me gustaría animar, a todo aquél que lea estas lí-neas, a que no deje de buscar ni deje pasar la oportunidad de participar en iniciativas como la que han promovido este proyecto.


Capítulo: Conclusiones

6.2. Vías futuras de trabajo para el proyecto

Tal y como decíamos en el apartado 1.3. (pág. 15), la andadura de todo el camino reco-rrido, arrancaba desde la base de que el proyecto en el que nos embarcábamos, no que-daría cerrado tras la finalización de este TFC.

El TFC iba a servir de punto de despegue para definir este amplio proyecto y para em-pezar a desarrollarlo mediante la implementación de dos herramientas (Localizador y Generador) que se pondrían en marcha en unas primeras versiones con vocación de ser ampliadas y mejoradas.

Por tanto, tras la conclusión del presente TFC, el proyecto que nos ocupa va a perma-necer abierto para futuras mejoras y ampliaciones mediante nuevos TFC, prácticas en institución, trabajos de investigación, o cuantos cauces seamos capaces de encontrar; sin perder de vista que la utilidad última del proyecto es poder llevar a cabo investigación social participativa.

Como último punto de esta primera gran fase en el proyecto que ha supuesto este TFC, aprovecharemos para indicar posibles vías de trabajo en el futuro. Empezaremos con cuestiones generales del proyecto y aspectos comunes a las dos aplicaciones imple-mentadas. Y seguiremos, apuntando vías de trabajo en cada una de estas dos aplicacio-nes por separado.

6.2.1. En general

Vamos a ir enumerando algunas mejoras o vías de trabajo generales, aunque no neces-ariamente por orden de prioridad o importancia.

1. Un primer paso, no demasiado complejo técnicamente, pero sí muy laborioso, puede ser completar el dibujo de todas las demarcaciones parroquiales. Como apuntábamos en el apartado 4.4., en el punto 1., queda pendiente dibujar 533 de-marcaciones parroquiales, de las cuales, al menos 207, habrá que deslindarlas prácticamente sin apoyos de otros límites oficiales disponibles como el de los términos municipales. Este trabajo puede suponer, en primer lugar, un buen ejer-cicio de documentación para recabar la información que nos haga saber por dónde van los límites de estas demarcaciones en cada uno de los municipios que cuentan con más de una parroquia. Y en segundo lugar, también implica una gran tarea de delineación, principalmente en Google Earth, aunque con apoyo de gvSIG como hemos podido ver ya en el trabajo realizado (apartado 4.4.3., pág 60 y siguientes).



2. Otra vía de trabajo, puede ser la implementación de un sistema más sencillo de mantener (actualizar, editar) las distintas demarcaciones. Puede ser objeto de es-tudio el desarrollar una herramienta que permita dibujar o editar, desde las mis-mas aplicaciones, dichas demarcaciones. Para ello, de entrada se nos ocurre que debería cambiarse el modo en que se almacenan las coordenadas de los puntos que definen cada polígono. Podría haber una tabla de puntos en la que no hubie-ra elementos repetidos; en ella, para cada punto, se almacenaría su identificador, latitud y longitud. Y en las tablas de polígonos, en vez de coordenadas, se alma-cenarían listados de puntos que los componen. Esto podrían ser unas primeras ideas para comenzar, pero aún podría mejorarse mucho más.

3. Un trabajo que ya podría iniciarse, sería la integración total de las dos aplicacio-nes en el sistema de Drupal, para contar así con un sistema global más compac-to. Actualmente tenemos separado, aunque relacionados entre sí, por un lado las aplicaciones, programadas en html/CSS – PHP – JavaScript, y, por otro lado el sistema de administración implementado en Drupal.

4. La opción de impresión de informes en ambas aplicaciones no ofrece la posibili-dad autónoma de generar archivos PDF, podría implementarse esta funcionali-dad.

6.2.2. Para el Localizador

Posibles vías de trabajo, serían las siguientes:

1. La API v3 no facilita el cálculo de rutas con transporte público, mientas que la página principal de Google Maps sí lo ofrece. Se podría implementar la cone-xión a esa página para calcular en ella la ruta deseada en caso de seleccionar el modo de transporte público, en vez de a pie o en coche.

2. Los informes paso a paso del cálculo de rutas que aparece en el panel lateral, por el momento no se pueden añadir a un informe para ser impresos. Lo mismo ocurre con la información gráfica de la ruta en el mapa. Podría implementarse la generación de informes de rutas con estos dos contenidos.

3. Para editar la información alfanumérica es necesario acceder al sistema de ad-ministración implementado en Drupal. Se podría desarrollar el modo de poder editar los datos desde los globos de información, conservando el sistema de per-misos.

4. El área de trabajo del Localizador prácticamente se circunscribe a la ciudad de Valencia, queda pendiente su ampliación.


Capítulo: Conclusiones

5. En la sección de “Informe” podrían añadirse nuevas funcionalidades para admi-nistrar los elementos ya añadidos: cambiando el orden, eliminando uno o va-rios...

6.2.3. Para el Generador

Posibles vías de trabajo, serían las siguientes:

1. Con los datos de Cáritas que ya se gestiona, sería interesante implementar la po-sibilidad de almacenar, año tras año, dichos datos, de manera que se pudieran realizar consultas de “históricos” eligiendo el año de consulta.

2. En la misma línea que el punto anterior, contando con datos de diferentes años, sería interesante poder hacer consultas que mezclara datos de diferentes años.

3. De momento, toda la información con la que trabaja el Generador son datos pro-pios de Cáritas. Queda pendiente el poder introducir nuevos datos de distintas fuentes, tanto de entidades privadas (organizaciones del campo social) como pú-blicas (censos, Servicios Sociales...)

4. El tipo de herramientas de las que dispone el Generador podríamos decir que, de momento, lo establecen como un visualizador de contenido cartográfico que tie-ne vinculado contenido alfanumérico. Una gran línea de investigación podría ser implementar en la aplicación herramientas de análisis de tipo SIG más comple-jas (áreas de influencia, intersecciones de polígonos...).

5. También quedan pendientes posibles mejoras de déficits detectados de fácil so-lución. Por ejemplo, sería interesante poder personalizar el tamaño y el color del texto de las leyendas, así como su color de fondo.


Capítulo 7Bibliografía

7.1. Libros

(1) Cáritas Diocesana de Valencia. (2009). Memoria 2009.

(2) Danesh, A., (2004). JavaScript in 10 Simple Steps or Less. Indianapoli s: Wiley Publishing, Inc.

(3) Goodman, D. (2001). JavaScript Bible. New York: Hungry Minds.

(4) Goodman, D. (2001). JavaScript Examples Bible. New York: Hungry Minds.

(5) Purvis, M., Sambells, J., Turner, C. (2006). Beginning Google Maps Applicationswith PHP and AJAX. USA: Apress.

7.2. Páginas web

(6) Archidiócesis de Valencia. Guía de la Archidiócesis. Recuperado 20 diciembre, 2010, de http://www.archivalencia.org/

(7) Ayuntamiento de Valencia. Regidoría de Benestar. Recuperado 22 diciembre, 2010, de http://www.valencia.es/

(8) Darel Rex Finley. (2007). Point-In-Polygon Algorithm - Determining Whether A Point Is Inside A Complex Polygon. Recuperado 10 octubre, 2010, de http://alienryderflex.com/polygon/

(9) Dirección General de Catastro. Servicios WMS de la Dirección General de Catastro (apartado de Google Earth). Recuperado 5 octubre, 2010, de http://www.catastro.meh.es/esp/wms.asp


http://www.catastro.meh.es/esp/wms.asp

http://alienryderflex.com/polygon/

http://www.valencia.es/

http://www.archivalencia.org/


(10) Federación Valenciana de Municipios y Provincias. Guía Turística de la Comunidad Valenciana. Recuperado 26 febrero, 2011, de http://www.fvmp.es/fvmp3/guia/

(11) Fox, P. Google Code, Google Maps API Family (2009). Creación de un localizador de tiendas con PHP, MySQL y Google Maps. Recuperado 5 de octubre, 2010, de http://code.google.com/intl/es-ES/apis/maps/articles/phpsqlsearch_v3.html

(12) Fox, P., Appleton, B., Stucker, L. Google Code, Google Maps API Family (2007). Uso de PHP/MySQL con Google Maps. Recuperado 3 de octubre, 2010, de http://code.google.com/intl/es-ES/apis/maps/articles/phpsqlajax_v3.html

(13) Fox, P., Manshreck, T. Google Code, Google Maps API Family (2007). Codificación geográfica de direcciones con PHP/MySQL. Recuperado 7 de octubre, 2010, de http://code.google.com/intl/es/apis/maps/articles/phpsqlgeocode.html

(14) Georget, S. Geostats, javascript library for classification. Recuperado 25 mayo, 2011, de https://github.com/simogeo/geostats

(15) Google Code, Google Static Maps API. Guía para desarrolladores de la versión 2 de Google Static Maps API . Recuperado 20 febrero, 2011, de http://code.google.com/intl/es-ES/apis/maps/documentation/staticmaps/

(16) Google Code, Versión 3 de Google Maps JavaScript API. Referencia de la versión 3 de Google Maps JavaScript API. Recuperado 25 febrero, 2011, de http://code.google.com/intl/es-ES/apis/maps/documentation/javascript/reference.html

(17) Google Code, Versión 3 de Google Maps JavaScript API. Página principal. Recuperado 25 febrero, 2011, de http://code.google.com/intl/es-ES/apis/maps/documentation/javascript/

(18) Google Maps Utility Library. KeyDragZoom. Recuperado 5 febrero, 2011, de http://code.google.com/p/google-maps-utility-library-v3/

(19) Google Maps Utility Library. MarkerWithLabel. Recuperado 22 abril, 2011, de http://code.google.com/p/google-maps-utility-library-v3/

(20) Instituto Cartográfico Valenciano. Catálogo, serie cartográfica CV300. Recuperado 10 abril, 2011, de http://www.icv.gva.es/secciones/catalogo/CARTOGRAFICA/CV300i.html


http://www.icv.gva.es/secciones/catalogo/CARTOGRAFICA/CV300i.html

http://code.google.com/p/google-maps-utility-library-v3/

http://code.google.com/p/google-maps-utility-library-v3/

http://code.google.com/intl/es-ES/apis/maps/documentation/javascript/services.html

http://code.google.com/intl/es-ES/apis/maps/documentation/javascript/services.html

http://code.google.com/intl/es-ES/apis/maps/documentation/javascript/reference.html

http://code.google.com/intl/es-ES/apis/maps/documentation/javascript/reference.html

http://code.google.com/intl/es-ES/apis/maps/documentation/staticmaps/

https://github.com/simogeo/geostats

http://code.google.com/intl/es/apis/maps/articles/phpsqlgeocode.html

http://code.google.com/intl/es-ES/apis/maps/articles/phpsqlajax_v3.html

http://code.google.com/intl/es-ES/apis/maps/articles/phpsqlsearch_v3.html

http://code.google.com/intl/es-ES/apis/maps/articles/phpsqlsearch_v3.html

http://www.fvmp.es/fvmp3/guia/

Capítulo: Bibliografía

(21) Macías, C. (2008). Un sencillo sistema de pestañas. Recuperado 1 abril, 2011, de http://www.cmacias.com/un-sencillo-sistema-de-pestanas/

(22) MySQL. MySQL 5.0 Reference Manual. Recuperado 15 octubre, 2010, de http://dev.mysql.com/doc/refman/5.0/es/

(23) Sanford, J. Drawing complex GeoJSON Polygons with the Google Maps API v3. Recuperado 11 abril, 2011, de http://geojason.info/demos/

(24) W3C España. Guías de Referencia Rápida. Recuperado 20 diciembre, 2010, de http://www.w3c.es/Divulgacion/GuiasReferencia/

(25) W3SCHOOLS. JavaScript and HTML DOM Reference. Recuperado 20 diciembre, 2010, de http://www.w3schools.com/jsref/

(26) WikiGIS. Jenks' optimization. Recuperado 25 mayo, 2011, de http://wiki.gis.com/wiki/index.php/Jenks'_optimization

(27) Wikipedia, la enciclopedia libre. AJAX. Recuperado 5 noviembre, 2010, de http://es.wikipedia.org/wiki/AJAX

(28) Wikipedia, la enciclopedia libre. Diseño centrado en el usuario. Recuperado 5 noviembre, 2010, de http://es.wikipedia.org/wiki/Diseñoo_centrado_en_el_usuario

(29) Wikipedia, la enciclopedia libre. Drupal. Recuperado 5 noviembre, 2010, de http://es.wikipedia.org/wiki/Drupal

(30) Wikipedia, la enciclopedia libre. Geography Markup Language. Recuperado 5 nov.iembre, 2010, de http://es.wikipedia.org/wiki/Geography_Markup_Language

(31) Wikipedia, la enciclopedia libre. Hojas de estilo en cascada. Recuperado 5 noviembre, 2010, de http://es.wikipedia.org/wiki/Css

(32) Wikipedia, la enciclopedia libre. HTML. Recuperado 5 noviembre, 2010, de http://es.wikipedia.org/wiki/HTML

(33) Wikipedia, la enciclopedia libre. Interfaz de programación de aplicaciones. Recuperado 5 noviembre, 2010, de http://es.wikipedia.org/wiki/Interfaz_de_programación_de_aplicaciones

(34) Wikipedia, la enciclopedia libre. JavaScript. Recuperado 5 noviembre, 2010, de http://es.wikipedia.org/wiki/JavaScript


http://es.wikipedia.org/wiki/JavaScript

http://es.wikipedia.org/wiki/Interfaz_de_programaci%C3%B3n_de_aplicaciones

http://es.wikipedia.org/wiki/HTML

http://es.wikipedia.org/wiki/Css

http://es.wikipedia.org/wiki/Geography_Markup_Language

http://es.wikipedia.org/wiki/Drupal

http://es.wikipedia.org/wiki/Dise%C3%B1oo_centrado_en_el_usuario

http://es.wikipedia.org/wiki/AJAX

http://wiki.gis.com/wiki/index.php/Jenks'_optimization

http://www.w3schools.com/jsref/

http://www.w3c.es/Divulgacion/GuiasReferencia/

http://geojason.info/demos/

http://dev.mysql.com/doc/refman/5.0/es/

http://www.cmacias.com/un-sencillo-sistema-de-pestanas/


(35) Wikipedia, la enciclopedia libre. KML. Recuperado 5 noviembre, 2010, de http://es.wikipedia.org/wiki/KML

(36) Wikipedia, la enciclopedia libre. Mashup (aplicación web híbrida). Recuperado 5 noviembre, 2010, de http://es.wikipedia.org/wiki/Mashup_(aplicación_web_híbrida )

(37) Wikipedia, la enciclopedia libre. MySQL. Recuperado 5 noviembre, 2010, de http://es.wikipedia.org/wiki/MySQL

(38) Wikipedia, la enciclopedia libre. PHP. Recuperado 5 noviembre, 2010, de http://es.wikipedia.org/wiki/Php

(39) Williams, M. (2010). Google Maps API Tutorial. Recuperado 1 octubre, 2010, de http://econym.org.uk/gmap/


http://econym.org.uk/gmap/

http://es.wikipedia.org/wiki/Php

http://es.wikipedia.org/wiki/MySQL

http://es.wikipedia.org/wiki/Mashup_(aplicaci%C3%B3n_web_h%C3%ADbrida)

http://es.wikipedia.org/wiki/Mashup_(aplicaci%C3%B3n_web_h%C3%ADbrida

http://es.wikipedia.org/wiki/KML

Documents

mashup_CaritasValencia-Lorenzo_Sicilia