¡Lo conseguimos! Tras la presentación de forma telemática de nuestro proyecto, hemos logrado obtener el primer premio en la fase local y el premio al mejor proyecto Cloud/Web en la fase nacional.
Gracias a todos por el apoyo. ¡Ha sido una experiencia muy enriquecedora!
CityReport es una herramienta que fomenta la participación ciudadana y facilita la comunicación con autoridades locales para reportar y gestionar incidencias.
La tercera edición del Concurso Universitario de Software Libre (CUSL) –Fase Local– ya tiene ganadores, después de que se haya celebrado de forma telemática, desde la Escuela Técnica Superior de Ingeniería (ETSI) y en streaming vía YouTube, el acto de presentación de los proyectos finalistas y entrega de premios, tras la deliberación del jurado. Este acto estuvo originalmente programado para el día 7 de mayo, pero tuvo que ser aplazado debido al estado de alarma decretado por la crisis sanitaria, y se ha elegido el marco del Día Internacional del Software Libre (Software Freedom Day), que se conmemoró el 21 de septiembre.
En base a la resolución de este jurado, compuesto por los profesores Iñaki Fernández de Viana y Javier Casado, el proyecto que ha resultado ganador ha sido la aplicación ‘CityReport’, desarrollada por los estudiantes del Grado de Ingeniería Informática Víctor Manuel Rodríguez Navarro y Ángel Aznar Orrego, quienes se llevan un premio en metálico de 400 euros. Ambos estudiantes, también en la Fase Final del concurso nacional (CUSL XIV) con el mismo proyecto, expusieron ante el jurado y el resto de sus compañeros su programa ‘CityReport’.
Como explicaron, se trata de una herramienta con implementación web y aplicación móvil que busca la interacción del ciudadano con la administración a través de la gestión y la alerta-reporte de incidencias (por ejemplo, árboles caídos, obstáculos en las aceras o en la calzada, semáforos apagados, pasos de peatones deteriorados, etcétera), y que permite la localización GPS, adjuntar imágenes, y descripción de esas incidencias.
El segundo premio (200 euros) ha sido para Juan Diego Morillo Reina, Graduado y Máster en Ingeniería Informática por la Onubense, así como Doctorado en Ciencia y Tecnología Industrial y Ambiental, que ha desarrollado el software ‘DCWApp’ (Devices Configurer Web App), una completa aplicación web para la configuración de dispositivos (SSH) a través de la red, independiente del sistema operativo (S.O.). Finalmente, el jurado decidió otorgar el tercer premio (150 euros) a la alumna de Ingeniería Informática Almudena García Jurado-Centurión por su herramienta GitLab Manager, para gestionar instancias de GitLab a través de la API, aplicada a la Universidad de Huelva para, por ejemplo, la creación grupos y subgrupos en asignaturas, proyectos de departamentos y materias, etcétera, facilitando sobremanera los procedimientos de gestión.
El acto fue presentado por el profesor Miguel Ángel Rodríguez, director de Software Libre y Conocimiento Abierto en la Universidad de Huelva, y también contó con la participación del vicerrector de Informática, Comunicaciones e Infraestructura de la UHU, Manuel Maña, quienes dieron la enhorabuena a todos los finalistas por la gran calidad de sus proyectos y por la originalidad y brillantez en la exposición de los mismos. Miguel Ángel Rodríguez quiso destacar el objetivo principal que persigue el Concurso Universitario de Software Libre, el de compartir conocimientos y el de mostrar el talento de los jóvenes estudiantes de la Onubense.
También dio la enhorabuena a los finalistas y ganadores Salvador Gómez de los Ángeles, diputado de la Diputación de Huelva, institución que patrocina el CUSL a través de la Cátedra de la Provincia, junto a la ETSI.
El Concurso Universitario de Software Libre busca incentivar el desarrollo de software, hardware y documentación técnica libre. El software libre es todo aquel cuyo código fuente puede ser estudiado, modificado y utilizado libremente con cualquier fin y redistribuido con cambios o mejoras (o sin ellas), y generalmente de forma gratuita. Éste año es el tercero consecutivo que la Universidad de Huelva impulsa una Fase Local, que se celebra de manera independiente respecto a la Fase Nacional (CUSL XIV). Los ganadores de la Fase Local impulsada por la Universidad de Huelva, Víctor M. Rodríguez y Ángel Aznar, han resultado también finalistas del CUSL a nivel nacional, y su proyecto ‘CityReport’, competirá con los desarrollados por estudiantes de la Universidad de Sevilla, la Universidad de Extremadura y la Politécnica de Madrid
Durante el confinamiento producido por el COVID-19 hemos estado menos activos, no obstante, hemos seguido trabajando en CityReport implementando esta nueva sección así como arreglando fallos conocidos.
Os traemos una nueva versión de la app v1.1, con las siguientes novedades:
En estas capturas, podemos ver la nueva sección, en la cual el usuario podrá obtener un listado de todos los reportes que ha efectuado y su estado.
A su vez en un futuro permitiremos que el usuario pueda verificar el estado del reporte para dar la incidencia por finalizada.
Para descargar la nueva versión de la app ir a nuestro github al apartado de realease: Última release
O bien haz click aquí para descargar directamente la app, no olvides activar la instalación de aplicaciones de terceros en tu móvil.
Tras mucho esfuerzo, es un placer para nosotros poder anunciar el lanzamiento de la versión estable v1.0.0.
La podéis descargar y probarla en el siguiente enlace: (click). en la parte de assets.
Esta versión trae como cambio más significativo la implementación del sistema de usuarios, pero eso no es todo. A continunación, os presentamos todos los cambios desde la última release.
Y tras la publicación de esta versión, ¿es esto todo? Por supuesto que no, todavía tenemos muchas ideas por plasmar, entre ellas, la más importante: incluir listas que recojan puntos de interés donde los usuarios puedan contribuir y escribir reseñas. Por ejemplo: lugares para hacer picnic, sitios adecuados para mascotas…
Todos estas ideas se pueden consultar en nuestro Project de GitHub llamado «Plan de Desarrollo», el cual a día de hoy, se encuentra así.
Se puede consultar en el siguiente enlace (click).
Como véis, todavía nos quedan muchas cosas por hacer…
¡Seguiremos manos a la obra con el proyecto!
Como fuimos comentando, estábamos trabajando en introducir un sistema de usuarios que permitiese relacionar los reportes con los usuarios, de tal forma que se tenga un mayor control sobre los reportes hechos. Finalmente, lo hemos hecho realidad.
Para ello hemos implementado unas funciones php que comprueban o introducen los datos del usuario así como su contraseña cifrada.
Esto lo hacemos de tal forma que la propia aplicación cifra la contraseña con un algoritmo de reducción criptográfico, para comprobar si el login es valido buscamos al usuario que tenga ese mail y o nombre de usuario y dicha contraseña cifrada, el id de usuario devuelto será el registrado.
Hemos añadido 2 vistas, una para el login y otra para el registro, ambas envían la información de id de usuario a la vista principal del mapa para poder tener identificados los reportes con dicho usuario registrado.
Igualmente, se han añadido procedimientos para controlar que los datos introducidos sean válidos, por ejemplo, que ambas contraseñas coincidan y que un email siga un patrón válido.
En las siguientes capturas podemos ver el resultado de estas nuevas pantallas de inicio de sesión y registro:
Actualmente, si queremos enviar un reporte de una incidencia, debemos encontrarnos en la ubicación en persona. Esto puede originar inconsistencias en algunas situaciones, por ejemplo: imagínense que yendo en coche hemos visto que un semáforo ha dejado de funcionar y queremos subirlo a CityReport. Tendríamos que pararnos y hacer una foto y rellenar el reporte en el mismo sitio, lo cual no es muy conveniente, o podríamos enviar el reporte una vez lleguemos a nuesto destino, pero la ubicación no se correspondería a la del lugar del incidente.
A raíz de esta problemática, hemos desarrollado una nueva forma de indicar la ubicación de un reporte: de forma manual.
Hemos añadido un interruptor debajo del mapa que se muestra en la aplicación y permite indicar la ubicación de forma manual tocando el mapa. Aparecerá activado por defecto si no se ha concedido permiso para acceder a la ubicación
Al desactivar el interruptor, se intentará obtener la ubicación del usuario via GPS. Además, hemos añadido control de excepciones que impiden enviar un reporte sin ubicación, y muestran un mensaje informativo al usuario.
Hemos implementado una funcionalidad que fue sugerida en este issue en GitHub. Se trata de hacer que los marcadores del mapa y la ventana que contiene la información del reporte sean del color del estado del reporte que representan, es decir: rojo si está pendiente de revisar, naranja si ya ha sido revisado y verde si ha sido solucionado.
En un principio, la implementación fue trivial, ya que la información del estado del reporte la obteníamos directamente en mapa.php al consultar a la base de datos.
Sin embargo, la cosa se complicó al ser más ambiciosos al querer hacer que el marcador del reporte seleccionado cambiara de color de la misma forma (a azul). Esto facilita la visualización de la ubicación de la incidencia en el mapa, en especial al navegar desde la página de la lista de reportes, que aunque se centra la vista en la localización cercana al reporte, si hay más reportes en esa ubicación, se dificulta distinguir a cuál corresponde el seleccionado.
Para hacer posible esta implementación, la página reportes.php debe conocer cuál es el marcador que genera ese reporte y el problema es que solo el script de mapa.php conoce las variables correspondientes.
Para solucionarlo, tras darle muchas vueltas, se nos ocurrió asociar el ID numérico del reporte al marcador como una propiedad extra, de forma que ya se puede cambiar el color del marcador activo al enviar la información del ID del reporte al navegar entra la página de la lista de reportes y el mapa.
A continuación se muestra unas capturas del resultado, que pueden consultar en la página de mapa.
Desde la creación de la página web, nos estamos encontrando con un problema muy evidente. Este es la tardanza al cargar la lista de reportes, donde aparecen las distintias incidencias acompañadas de una imagen descriptiva de la misma. El problema es que esta imagen se carga a resolución completa y retrasa la carga de la página web, perjudicando la experiencia del usuario.
Para solucionar esto, hemos creado una imagen en miniatura o thumbnail de 300px de ancho por cada imagen que se sube al servidor. Esta miniatura tiene tamaño de archivo muy inferior al original como podemos ver en la siguiente captura del directorio de archivos subidos del servidor:
Para la implementación, hemos decidido que se encargue el servidor a través de un script en PHP, para no sobrecargar más la aplicación móvil.
Tras informarnos, vimos que PHP cuenta con una serie de funciones para el procesado de imágenes, llamadas PHP-GD. Hemos hecho uso de una implementación compartida por el usuario @pquina en GitHub y la hemos adaptado simplificándola para que funcione en nuestra aplicación web, creando el archivo miniatura.php.
El funcionamiento es el siguiente: al subir una foto, la aplicación web guarda la imagen original y genera una miniatura de la misma de 300px de ancho. Ambas rutas de las imágenes se guardan en la base de datos para poder ser accedidas a la hora de listar reportes (miniatura) o ver un reporte detallado en la sección de mapa (original).
Tras el parón por los exámenes universitarios de Febrero, nos hemos vuelto a poner manos a la obra con el proyecto.
Por el momento, hemos reconfigurado el servidor web para usar un certificado SSL generado con Let’s Encrypt para cifrar la conexión del cliente con el servidor y permitir el envío/recepción de datos de forma segura. Ya no encontramos advertencias en los exploradores, como podemos ver en la siguiente captura:
Por otro lado, hemos reescrito las funciones PHP para evitar ataques de inyección SQL, aunque igualmente, el usuario que accede a la base de datos no tiene permisos que compromentan la seguridad del sistema y hemos creado un archivo de configuración para la apliación web: config.php con la siguiente estructura:
//CONFIGURACION DE LA BASE DE DATOS
$hostname="example.com"; //Dirección del servidor
$database="BD"; //Nombre de la base de datos
$username="user"; //Nombre de usuario de la BD
$password="pass"; //Contraseña
La aplicación web se compone de una parte oculta de cara al usuario, que involucra toda la configuración del VPS Ubuntu el cual lanza un servidor web Apache, así como la base de datos y los scripts en PHP que permiten subir contenido de la aplicación al servidor y hacer consultas a la base de datos desde la web.
Antes de esta versión minimalista y simple de la web, estuvimos bicheando hacerla con HTML y CSS desde cero, hasta que llegamos a un punto en el que vimos que no avanzábamos mucho y el diseño quedaba muy anticuado, comparado con las páginas web actuales que son adaptativas para todos los dispositivos móviles.
Es por eso que buscamos una plantilla de bootstrap 4 con licencia libre la cual pudiésemos modificar y adaptar a nuestras necesidades.
Además, hemos obtenido un dominio gratuito para poder visitar la página cómodamente: cityreport.ga
La web consta esta de las siguentes partes:
En la parte del mapa podremos ver las localizaciones de todos los reportes realizados por los usuarios en un mapa interactivo, el cual ha sido realizado con la librería de javascript Leaflet que nos permite implementar y controlar el mapa colaborativo de código abierto OpenStreetMap , así como poder ver el contenido cada reporte haciendo click en su marcador.
Un apartado reportes donde podremos ver un lista de todos los reportes realizados, así como ordenarlos según los campos: estado, id, descripción o fecha.
Posteriormente tenemos planeado categorizar los reportes según la naturaleza de ellos y añadiremos opciones de filtrado en esta sección.
Al tocar sobre uno de los reportes nos abrirá su localización y descripción detallada en el mapa.
En esta sección podremos ver gráficamente estadísticas de los reportes realizados: cuántos están pendientes, revisados o finalizados, así como la progresión de reportes a lo largo del año en un gráfico acumulativo.
Para implementar esta sección hacemos uso de la librería de javascript de código abierto chart.js
Esta sección es meramente informativa, donde brindamos información sobre el proyecto así como información de contacto.
Todas las secciones que muestran información así como gráficas de los reportes se generan en tiempo real con el contenido de la base de datos rellena con los reportes de colaboración ciudadana.
Desde que publicamos la aplicación, hemos recibido reportes de distintos lugares de Huelva capital así como de diferentes municipios de la provincia, gracias a multitud de personas que han conocido este proyecto y han colaborado testeando la aplicación y web.
A su vez hemos recibido ayuda de testeo de personas otras regiones de España que se han visto interesadas por el proyecto
El proyecto empieza a tomar forma y a suscitar interés en múltiples personas, lo que nos anima a seguir desarrollándolo.
Próximamente empezaremos a implementar un sistema de usuarios y lanzaremos una versión más actualizada de la aplicación que corrige los fallos encontrados.
¡Seguidnos en este blog para estar al tanto de todas las actualizaciones!
Para reportar una incidencia será necesario aportar la ubicación de la misma, una descripción del problema, así como añadir contenido visual descriptivo.
Para ello, hemos implementado en la aplicación móvil un botón que permitirá seleccionar una imagen de la galería, o bien, hacer una foto en ese mismo momento. (Se implementará compatibilidad con vídeos en un futuro).
En las siguientes imágenes veremos el proceso de escribir y enviar un reporte:
Para que sea posible enviar reportes a nuestro servidor, hemos tenido que implementar unos scripts en PHP que permiten recibir el contenido de la aplicación e insertan una nueva tupla en la base de datos.
Las tuplas de la tabla reportes se caracterizan por un ID único autogenerado, la descripción del reporte, ruta de la foto almacenada en el servidor, coordenadas de la ubicación, fecha y el estado (pendiente, revisado o completado).
Por último, mencionar que también se ha implementado la posibilidad de subir un reporte sin adjuntar imagen, de forma que se suba a la base de datos con una imagen por defecto.
Para la forja del proyecto haremos uso del conocidísimo Github que usa el sistema de control de versiones Git.
Para ello hemos creado una organización en GitHub llamada CityReportCUSL. Esto nos permite vincular varios repositorios a la misma, de forma que hemos creado el repositorio CityReportAPP y el repositorio CityReportWeb, que se usarán para el desarrollo de la aplicación móvil y web, respectivamente.
Otra función muy interesante que nos ofrece GitHub son los «projects», esto es, una especia de pizarra en la que podemos añadir notas con los objetivos del proyecto y las pequeñas tareas en las que se divide cada uno, de forma que a medida que se van completando, las iremos moviendo de To do (por hacer) a En Progreso y finalmente en Completado, como podemos ver en las siguientes imagenes.
Hemos creado un project llamado Plan de desarrollo que contendrá las tareas y objetivos de la aplicación móvil así como la web.
Por otro lado, haremos uso de los «issues» de GitHub, esto es una herramienta de GitHub que permite abrir casos para las incidencias del la aplicación. Lo usaremos para reportar los problemas y errores que se han encontrado en el funcionamiento de las aplicaciones, para poder tenerlos localizados y al implementar la solución, dar el caso por cerrado. Se encuentra en la pestaña «issues» de cada repositorio.
También estamos estudiando la posibilidad de mantener dos ramas de desarrollo de cada repositorio (branches), una llamada dev donde se publicará el código provisional y otra master con el código funcional de cada versión.
Por último, haremos uso de la pestaña releases de cada repositorio para subir las versiones funcionales de la aplicación a medida que se van desarrollando, de tal forma que cualquiera la pueda descargar y probarla.
Esto es todo por ahora. Como hemos visto, gracias a GitHub podremos llevar una buena gestión del proyecto. En futuras publicaciones os seguiremos comentando el desarrollo del proyecto.
¡Por último os deaseamos felices fiestas y próspero año 2020, de parte de Ángel y Víctor! 😀
A continuación os comentamos los objetivos del proyecto así como las tecnologías que usaremos para llevarlo a cabo.
CityReport nace de la idea de dos jóvenes estudiantes de Ingeniería Informática de la Universidad de Huelva: Víctor y Ángel, en una de nuestras rutinarias rutas de bici. (Véase foto).
¿Pero qué es exactamente CityReport?
Dada la evidente falta de comunicación entre los ciudadanos y la administración pública a la hora de notificar incidencias de diverso tipo en la ciudad (acerado o señales en mal estado, falta de papeleras, rutas cortadas, y un largo etcétera) surge la necesidad de una herramienta que pueda facilitar esta interacción: CityReport.
Nuestro objetivo es implementar una aplicación móvil Android desde la que se puedan enviar los reportes ciudadanos y una aplicación web que los recoja y permita a la administración gestionarlos.
Acompáñanos en el desarrollo del proyecto a través del seguimiento de este blog, así como el repositorio GitHub que subiremos pronto.
CityReport 