19 Nov Desarrollo aplicación SIG en Android.

Aplicación SIG de actualización de censo de locales y actividades.

Hemos realizado un aplicación SIG para la empresa Dephimática S.L, con sede en Madrid, con el objeto de realizar un trabajo de campo destinado a generar una base de datos de aproximaciones postales segundas, basadas en la información catastral y el callejero municipal facilitado por el Ayuntamiento de Madrid, conectando las inscripciones padronales a la base de datos obtenida, y actualizando el censo de locales y actividades.

El objeto de este proyecto es mantener actualizado el censo de locales y actividades para toda la ciudad de Madrid, trabajando en equipos de personas con dispositivos móviles (tablets Android en este proyecto en concreto).

El personal trabaja recorriendo por distritos y sectores toda la ciudad de Madrid, con un censo alfanumérico y gráfico de locales y actividades, localizándolos uno a uno en ese recorrido de campo y actualizando su actividad y la localización exacta del local, ya no solo a nivel de calle, sino a nivel de plantas de edificios.

El mantenimiento de estos locales y actividades incluye el alta y/o baja de ellos, para luego volcar estos datos en la base de datos del Ayuntamiento de Madrid.

Requerimientos del cliente para la aplicación SIG.

Dephimática S.L, ya disponía de una aplicación nativa para Android, realizada en Java, donde hacían ese recorrido de campo, pero de manera totalmente alfanumérica, con todos los datos de locales y actividades almacenados en los dispositivos móviles, de manera local.

La problemática estaba en cómo implantar un SIG en su aplicación Android ya realizada, sin tener que rehacer el proyecto prácticamente desde cero para dar cabida a un nuevo modelo de datos, esta vez con la componente gráfica de esos locales y empresas.

La propuesta que le lanzamos desde Avantgeo fué la de realizar una aplicación SIG en entorno web (webmapping), que sería incrustada dentro de la aplicación Java.

Desde el punto de vista puramente técnico, estas son 2 aplicaciones totalmente independientes, es decir, por un lado una aplicación Android nativa, y por otro una aplicación SIG ejecutada desde un navegador. ¿Cómo establecer una comunicación fluida entre ambas aplicaciones y que el usuario de la misma pueda trabajar de manera coordinada sin tener que saltar de un aplicativo a otro?

La solución pasaba por programar un webView en Java. Este componente de java, nos permite incrustar una página web o aplicación web, dentro de una aplicación Java, de modo que podemos visualizarla dentro del aplicativo sin necesidad de abrirnos un navegador por separado.

Esto nos solventaba la primera parte, que era el poder ver la aplicación SIG en web desde la aplicación nativa en Java. Pero ahora bien, ¿cómo coordinamos ambas aplicaciones para que se comporten como solo una?

Los webView permiten una cosa muy útil en este caso, que es la posibilidad de llamar a funciones propias de la web desde Java, y viceversa. Es decir, desde la aplicación SIG (siempre y cuando se ejecute dentro de la aplicación Java), podemos ejecutar funciones de Java y obtener sus datos, y desde la aplicación alfanumérica de Java, decirle, por ejemplo, a la aplicación SIG que muestre el mapa y nos geolocalice en el plano automáticamente.

De este modo, mediante la compartición de esas funciones de un lado y del otro, podemos no sólo mostrar un SIG dentro de la aplicación Java, sino interactuar entre ambas partes.

En un futuro artículo sobre los webView en Java explicaremos en detenimiento cómo funciona internamente.

Funcionalidades de la aplicación SIG

La aplicación alfanumérica del cliente tiene muchas y muy potentes funcionalidades, pero en este caso nos vamos a centrar en la parte que nos compete, que son las funcionalidades desarrolladas en el SIG.

Toda la información gráfica y alfanumérica necesaria para enlazar con la aplicación del cliente se encuentra en una base de datos PostgreSQL a la que le hemos instalado PostGIS, como componente espacial, para poder almacenar la geometría de los elementos, tales como el callejero y los locales y nº de policía de Madrid.

Las tablas de base de datos principales que componen este proyecto son:

• FXCC, plantas significativas: contiene los datos de la geometría de todas las plantas de los edificios de la ciudad de Madrid. En total 1.224.302 registros con un tamaño en Mb de ocupación en disco de 6,7 Gb.
• Junto con los datos gráficos de cada planta, vienen sus datos alfanuméricos asociados, con un total de 2.605.1181 registros.
• Tablas gráficas facilitadas por el Ayuntamiento de Madrid, (aproximadamente 385 Mb y unos 719.439 registros) que corresponden con elementos como:
  • Parcelas
  • Aceras
  • Distritos censales
  • Sectores
  • Manzanas
  • Parcelas
  • Edificios
  • Rotulación de elementos viales
• Tabla de nº de policía: usadas para asociar los locales / actividades con una dirección concreta: 205.741 registros
• Tabla de locales: 129.433 locales / actividades

El funcionamiento del equipo de trabajo, y cómo se distribuyen el mismo está supeditado siempre a las secciones censales, es decir, siempre son enviados a una sección en concreto, para pasar a la siguiente cuando hayan completado el trabajo.

Es por eso, que desde la aplicación alfanumérica siempre se cargan los datos por secciones. De este modo el usuario que tiene asignada una sección no puede ver el resto, evitando así posibles errores de campo.

En la captura que tenemos a la izquierda, podemos ver los datos de nº de policía y locales, agrupados en un cluster, que nos permite visualizar la concentración de esos elementos a niveles de zoom donde nos encontramos alejados de la sección.

Como podemos comprobar en la imagen, el resto de secciones no contienen datos gráficos. Conforme nos vayamos acercando más y más al mapa, podremos ver los símbolos de nº de policia y locales, con sus códigos de color dependiendo del estado de inspección en el que se encuentren.

Las funcionalidades se centran principalmente en 2 elementos gráficos: nº de policía y locales.

Opciones sobre el nº de policía.

Las opciones a realizar sobre el nº de policía son:

• Abrir: llamada a la parte alfanumérica de la aplicación, abre el formulario alfanumérico con todos los datos asociados a ese nº de policía y sus locales asociados.
• Tareas: llamada a la aplicación alfanumérica, donde gestionar las tareas realizas sobre ese elemento
• FXCC: carga una capa gráfica nueva, con la planta general + las plantas significativas de la referencia catastral vinculada a ese nº de policía. En el plano se puede hacer zoom sobre las plantas y seleccionar qué planta deseas ver para poder visualizar el plano.
• Mover: mueve el nº de policía de lugar, siempre teniendo en cuenta que debe pertenecer a la misma referencia catastral de la parcela donde se encuentra.
• Alta local: da de alta gráficamente un local vinculándolo al nº de policía y por lo tanto a la parcela. Una vez posicionado el local en el mapa, se cargan todos los datos alfanuméricos de la aplicación.
• Eliminar: elimina un nº de policía del mapa.

Opciones sobre los locales

La ventana muestra el código del local, además del nombre del negocio y la dirección física donde se encuentra.

Mover: mueve el local dentro de la misma parcela donde se encuentra

Ndp secundario: algunos locales tienen acceso por 2 portales o nº de policía. Esta opción permite establecer el nº de policía (ndp) secundario

Eliminar: elimina el local de la aplicación

Se puede realizar un alta de local pero no se realiza desde este menú, hay un apartado con funciones específicas para eso, junto con otra función para geoposicionarte en el mapa.

Caraterísticas del hardware del proyecto SIG

Este proyecto SIG se encuentra alojado en un servidor en la nube con todas las medidas de seguridad. Sus características físicas son las siguientes:

• 2 procesadores Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz
• Disco duro 40 GB SSD HD
• 2 Gb RAM
• Sistema Operativo: Ubuntu 16.04.3 LTS

Para mover esta cantidad de datos, no ha sido necesaria una máquina muy potente, y se comporta de manera muy correcta con una concurrencia de 50 operarios en campo. Esto es posible debido a que cacheamos en el servidor toda aquella información gráfica que no va a cambiar en el tiempo. Eso nos ahorra mucho proceso y carga al servidor. Sólo aquellos elementos susceptibles de ser modificados, como son el nº de policía y los locales, son cargados dinámicamente, consultando directamente a la base de datos.

En este corto vídeo podemos ver la fluidez con la que se mueve la aplicación.

Conclusiones finales del proyecto

Este proyecto se ha llevado a cabo en un plazo aproximado de 3 semanas. La experiencia a la hora de hacer convivir un proyecto ya realizado y consolidado en una aplicación Android nativa, junto con un proyecto de webmapping SIG ha sido muy satisfactoria, ya que al ser 2 aplicaciones totalmente separadas, ambos grupos de trabajo (alfanumérico formado por la gente de Dephimatica S.L) – (SIG formado por el equipo de Avantgeo), hemos podido trabajar de forma paralela sin problema ninguno. Al final del desarrollo simplemente hemos tenido que facilitar al otro grupo de trabajo qué funciones deben ejecutarse para poder llevar a cabo determinadas acciones.

Ese es uno de los motivos por el que el desarrollo ha podido llevarse a cabo en tan poco tiempo.

Todo el proyecto SIG ha sido desarrollado con software Open Source. Sus componentes principales han sido:

• Mapnik: para el renderizado de capas
• PostgreSQL + Postgis: base de datos relacional + extensión espacial que le dota de todas las funciones que hacen posible un SIG.
• Mapproxy: servidor de teselas usado para cachear las imágenes que se van a publicar y disminuir drásticamente la carga del servidor.
• Tilelive: servidor de teselas para las capas que varía su información en tiempo real.
• PHP, Javascript, AJAX, JQuery: lenguaje de programación / script.