Introducción

El uso de la información geográfica en el día a día de las personas, ha tomado un auge significativo en los últimos años. Servicios populares de internet como Google Maps, Bing Maps y OpenStreetMap, los cuales tienen como base el uso de datos geográficos de diversas fuentes, han provisto a la población de herramientas atractivas para la consulta y manipulación de información espacial.

Los datos geográficos son la clave para diferenciar un Sistema de Información Geográfica (SIG) de otro sistema de información. Los SIG son un potente conjunto de herramientas para recolectar, almacenar, recuperar a voluntad, transformar y presentar datos espaciales procedentes del mundo real (^{Burrough, 1986}). Comúnmente, todas estas funcionalidades se complementan con servicios basados en la localización.

Los Servicios Basados en la Localización (LBS, por sus siglas en inglés) en su forma estandarizada OpenLS (^{Open Geospatial Consortium, 2008}), definidos por la Open Geospatial Consortium (OGC), proporcionan al usuario información y datos basados en la posición geográfica. Estos servicios se basan, por lo general, en una red de comunicaciones y una o más tecnologías de posicionamiento, que en combinación con los SIG recogen la información y la presentan al usuario final (^{Sánchez, 2012}). Los LBS incluyen servicios de ruta, directorio y geocodificación de direcciones postales (^{Open Geospatial Consortium, 2008}). La geocodificación es un proceso que ayuda a organizaciones a refinar y enriquecer información existente relacionada con direcciones y localizaciones en una base de datos. Genera latitud/longitud a partir de una dirección existente, o localización, asimismo es el primer paso a tomar por cualquier aplicación que haga uso de servicios basados en la localización (^{Oracle, 2007}).

En la actualidad, la geocodificación se ha convertido en una necesidad para múltiples análisis espaciales y para la toma de decisiones (^{Jiang & Stefanakis, 2018}). Por esta razón, los investigadores se mantinenen publicando avances en la misma, ya sea desde el punto de vista de su desarrollo o de cómo puede utilizarse como medio para realizar análisis espaciales de mayor profundidad y valor agregado. En el primer caso se encuentra ^{Yin et al. (2019)} que presentan un método de geocodificación basado en la detección de objetos en imágenes a partir de un marco de Deep Learning y comparan sus resultados con sistemas de geocodificación tradicionales a partir de 22,481 direcciones. Asimismo ^{Küçük & Avdan (2018)} proponen un algoritmo basado en Procesamiento del Lenguaje Natural (PLN) que recompone una dirección a partir de una previa descomposición de los elementos significativos de la misma, eliminando errores ortográficos, abreviaturas, etcétera. Estos autores demuestran cómo, usando el API de geocodificación de Google, con las nuevas direcciones se obtienen más resultados y, a su vez, más precisión.

Por otra parte, múltiples autores hacen referencia a la geocodificación como herramienta para poder realizar análisis espaciales más complejos. Tal es el caso de ^{Präger et al. (2019)} que presentan un estudio de viabilidad en el uso de los servicios de geocodificación online de Google y OpenStreetMap (OSM) en la detección de factores que propician la obesidad, concluyendo que su validez es razonable y que puede ser utilizado en la vigilancia de la diabetes. En ^{Chopin & Caneppele (2019)}, se usa la geocodificación como medio para realizar un análisis exploratorio de la movilidad entre los agresores y las victimas en delitos de abuso infantil en Francia, mientras que en ^{McIntire et al. (2018)} se geocodifican las direcciones de 10,750 pacientes con cáncer de próstata del estado de Pensilvania, para crear un índice compuesto que identifica los vecindarios con mayor incidencia de dicha enfermedad.

En Cuba, particularmente en la CUJAE, entre los años 2011 y 2013 se realizaron avances respecto a la geocodificación de direcciones postales cubanas mediante la implementación de un sistema de geocodificación nacional (^{De Armas & Gutiérrez, 2013}). A partir del año 2015, el sistema se incluyó como parte de una Infraestructura de Datos Espaciales (^{Sánchez, 2015}) y en 2017 se comenzaron a ofrecer las funcionalidades de geocodificación a partir de GeoServer mediante la utilización de servicios Web (^{Girón & Sánchez, 2017}). GeoServer es un servidor de código abierto escrito en Java que permite a los usuarios procesar información espacial y posee la capacidad de publicar datos de gran variedad de fuentes utilizando estándares de OGC (^{GeoServer, 2014}).

Según los autores: ^{Dueker (1974)}; ^{Roongpiboonsopit & Karimi (2010)}; ^{Cetl et al. (2016)}; ^{Vargas & Horfan, (2013)} el proceso de geocodificación de direcciones postales a partir de texto libre está dividido en varias etapas: extraer los elementos necesarios para el proceso de geocodificación, normalizar dichos elementos, estandarizarlos y realizar el proceso de geocodificación mediante la utilización de una base de datos de referencia. Estos métodos “tradicionales” para realizar el proceso de geocodificación pueden llegar a demorarse tanto en un proceso de geocodificación por lotes que su utilización no sea factible en determinadas circunstancias. En ^{Sen et al. (2012)} se realizó un estudio comparativo entre diferentes servicios geocodificadores disponibles en internet (Google Maps, Bing y Yahoo Place Finder) donde se geocodificaron varias bases de datos, entre ellas una con un millón de instancias, y su geocodificación completa duró poco más de un año. El tiempo que duró la geocodificación fue, de acuerdo con los autores, muy superior a lo que necesitaban para cubrir las necesidades de geocodificación que tenían, por lo que tuvieron que desarrollar un sistema de geocodificación que utilizara técnicas de computación paralela.

Paralelismo es una propiedad de la computación en la cual las porciones de la funcionalidad a ejecutar y los datos son independientes, por lo tanto, permiten ser procesados al mismo tiempo (^{Foster, 1995}). Existen diferentes opciones para la explotación del paralelismo, desde computadoras independientes trabajando para conseguir un mismo objetivo hasta una misma computadora que contenga varios elementos de procesamiento accediendo a la misma memoria (sistemas de memoria compartida) (^{Pacheco, 2011}).

El objetivo del presente trabajo es disminuir el tiempo del proceso de geocodificación de direcciones postales cubanas. Para ello se realizará un diseño paralelo del algoritmo de geocodificación tomando como punto de partida los antecedentes de la geocodificación de direcciones postales cubanas, planteados anteriormente.

Geocodificación de direcciones postales en cuba

En la era de la información, los datos espaciales son considerados como uno de los valores añadidos que más se valoran de la información. La forma más común de obtener información espacial es mediante la interpretación de las direcciones, ya que una dirección postal es la forma fundamental en que las personas describen dónde se encuentra algo o alguien (^{Roongpiboonsopit & Karimi, 2010}). En el proceso de geocodificación es necesario conocer las diferentes variantes de escritura de las direcciones postales. En ^{De Armas & Gutiérrez (2013)} se documentaron los siguientes modelos de direcciones postales en Cuba:

En ^{Girón & Sánchez (2017)} se presentó un componente para GeoServer, cuyo objetivo fue brindar al servidor de mapas servicios basados en la localización. Entre estos servicios se encuentra la geocodificación de direcciones postales. El proceso de geocodificación realizado por esta extensión se muestra en un diagrama de actividades en la Figura 1.

Figura 1: Versión secuencial de la geocodificación de direcciones postales 

La geocodificación se realiza de forma secuencial, por ello cuando se desee procesar una petición de geocodificación por lotes, la geocodificación de una dirección comienza cuando la anterior termina. Para poder geocodificar una dirección primero se realiza un proceso de normalización mediante el cual se eliminan los caracteres extraños que pueda contener, después se extraen los elementos útiles para el proceso de geocodificación, se establece el nivel de precisión que se quiere (calle, esquina, reparto o provincia) y, por último, se procede a buscar la dirección en la base de datos de referencia. De acuerdo con los experimentos realizados, la configuración ideal para la geocodificación por lotes sería el procesamiento de cinco direcciones en cada lote. Esto trae consigo que sea necesario un pre-procesamiento de la información para dividirla en lotes pequeños cuando se quieran geocodificar grandes cantidades de direcciones con la configuración recomendada por el autor, lo que conllevaría a un esfuerzo mayor por parte del usuario y, por ende, un consumo mayor de tiempo en todo el proceso.

El componente al que se hace referencia, hace uso del sistema gestor de bases de datos Oracle para el almacenamiento de la base de datos de referencia necesaria en la geocodificación de direcciones postales. Parte de la lógica del proceso de geocodificación se encuentra anclada a la base de datos mediante procedimientos almacenados de acuerdo con lo que plantea el autor. Esta lógica se encuentra duplicada en una base de datos PostgreSQL, con su extensión espacial PostGIS, debido a la necesidad de contar con una fuente de datos que utilice tecnologías libres. Esto trae consigo diversos problemas, por ejemplo, si se necesitara utilizar otro sistema de base de datos o actualizar los actuales, sería necesario no solo migrar o actualizar los datos utilizados en el proceso de geocodificación, sino que habría que actualizar parte de la lógica del proceso en todos los sistemas donde se encuentre, lo que conllevaría un esfuerzo mayor por parte de los desarrolladores.

Particularidades de la geocodificación de direcciones postales

La geocodificación de direcciones, según el estándar OpenLS, se puede realizar en lotes de más de una dirección. Una petición que sigue el estándar OpenLS y que contiene más de una dirección a geocodificar se muestra en la Figura 2 (izquierda).

Figura 2: Formatos de geocodificación de múltiples direcciones. Izquierda: petición, derecha: respuesta 

Cuando se recibe una petición como la que se muestra en el código anterior, se geocodifica en un primer instante la dirección: “60 # 109 Apto 2 E/ Ave 1 A Y Ave 1, Miramar, Playa, La Habana” y cuando finaliza ese proceso comienza la geocodificación de la dirección: “340 E/ 107 Y 109, Rpto Alt Naranjal, Munic Matanzas, Matanzas”. Para cada una de las direcciones contenidas en el lote se debe ofrecer una respuesta al usuario.

Como se puede observar en la Figura 2 (derecha), la respuesta al cliente está compuesta por dos etiquetas GeocodeResponseList dentro de las cuales se encuentran las direcciones geocodificadas para cada una de las 2 direcciones enviadas al servidor para su geocodificación. Se le proporciona una respuesta al cliente que contiene la posición geográfica en formato longitud/latitud y la dirección encontrada escrita en formato libre de acuerdo con el modelo de direcciones cubano. Estas direcciones no dependen una de la otra para su geocodificación, por lo que este proceso se pudiera desarrollar en paralelo.

Tomando como punto de partida el sistema de geocodificación que se plantea en ^{Sánchez (2015)}, se diseñaron varias versiones del componente de acuerdo con si se emplea o no computación paralela en su funcionamiento, o si la lógica del proceso de geocodificación se encuentra anclada o no a la base de datos de referencia para la geocodificación. Dichas versiones se muestran en la Tabla 1.

Diseño paralelo del algoritmo para la geocodificación de direcciones postales

Los algoritmos de geocodificación secuenciales planteados realizan el proceso de geocodificación sobre una dirección a la vez. Esto trae consigo demoras en el proceso de geocodificación que pueden ser mitigadas utilizando un modelo de paralelismo de datos. Utilizando el paralelismo de datos se puede aplicar el algoritmo de geocodificación sobre una determinada cantidad de direcciones en forma simultánea.

Este diseño se muestra en el diagrama de la Figura 3. El proceso se inicia mediante una aplicación cliente, encargada de construir una petición de geocodificación utilizando el estándar OpenLS para su posterior procesamiento y haciendo uso del algoritmo paralelo implementado para GeoServer. Utilizando herramientas y bibliotecas nativas de Java se identifica la cantidad de elementos de procesamientos que contiene físicamente el servidor sobre el cual se está ejecutando GeoServer, por lo tanto, el algoritmo de geocodificación. Esta cantidad de elementos de procesamiento será el número de direcciones simultáneas que podrán ser procesadas por el algoritmo.

Figura 3: Versión paralela de la geocodificación de direcciones postales utilizando N elementos de procesamiento 

Posteriormente, las direcciones se normalizan con el objetivo de eliminar cualquier carácter especial que pudieran contener y así evitar algunos errores en su interpretación. A cada dirección se le realiza un proceso de interpretación donde se le extraen sus componentes o TOKENS, utilizando un módulo de interpretación de direcciones. Luego, el conjunto de direcciones se divide en la forma más homogénea posible para su geocodificación, utilizando cada elemento de procesamiento del sistema. De forma simultánea, sobre cada conjunto de direcciones, el algoritmo permite establecer el tipo de dirección a geocodificar y se construye una solicitud de geocodificación para ser comparada con los datos de referencia. Esta solicitud de geocodificación es la que puede variar de acuerdo con la versión del sistema que se esté empleando debido a que la lógica de este proceso puede encontrarse anclada o no a la base de datos de referencia.

Finalmente, del conjunto de direcciones posibles se selecciona la que mayor concordancia presente de acuerdo con la dirección de entrada y se culmina el proceso obteniendo una lista de direcciones geocodificadas en el mismo orden, las cuales se recibieron en los datos de entrada.

En la Figura 4 se muestra un diagrama de estructuración en capas que muestra la arquitectura de los componentes fundamentales del sistema mediante paquetes y subsistemas de acuerdo con el nivel de reutilización que pudieran tener.

Figura 4: Vista de la arquitectura del software desde un punto de vista de reutilización 

El sistema está compuesto por varios paquetes y cada uno de estos contiene una o más clases dedicadas, en conjunto, al proceso de geocodificación de direcciones postales cubanas. El paquete “request” contiene la gestión de la configuración necesaria para que el componente pueda procesar una petición de geocodificación, incluyendo los parámetros necesarios para que el componente se pueda conectar a la base de datos de referencia. El paquete “geocode” es el contenedor de las clases y métodos necesarios para el correcto procesamiento de una dirección postal. El paquete “queryBuilder” es el contenedor de la totalidad de la lógica del proceso de geocodificación para las versiones 2 y 4 del sistema; finalmente en la versión 3 es la encargada de ejecutar la petición a la base de datos de referencia para que continúe con el proceso de geocodificación.

El paquete “connection” modelado en la Figura 4 es el encargado del proceso de conexión a cada una de las bases de datos de referencia, tanto en Oracle como en Postgre, mientras que el subsistema “OpenLSCore” contiene todas las clases que describen los elementos que se encuentran en la especificación OpenLS de OGC necesarias para la correcta construcción e interpretación de los XML de petición y respuesta a los LBS. El subsistema “AddressParser” provee al sistema la capacidad de interpretar direcciones postales cubanas y obtener los elementos de interés de cada dirección para su posterior geocodificación (^{Girón & Sánchez, 2017}).

Como el sistema se basa en un modelo de paralelismo de datos, los paquetes diseñados corresponden prácticamente con los de un sistema secuencial. La diferencia radica en que, al recibirse una petición con múltiples direcciones, se crean tantos hilos de ejecución como elementos de procesamiento que se hayan identificado para procesar dichas direcciones. Este proceso ocurre en el paquete “geocode” y se extiende hacia los paquetes “queryBuilder” y “connection”, pues las clases de estos dos últimos son instanciadas para cada hilo de ejecución.

Evaluación

Luego del desarrollo del software es necesaria la realización de un conjunto de pruebas con las que se puedan comprobar el comportamiento del componente ante determinadas circunstancias. Con el objetivo de comparar el comportamiento de las cuatro versiones del sistema de geocodificación de direcciones postales cubanas, en cuanto al tiempo de procesamiento, se identificaron varios factores controlables y no controlables para la ejecución de las pruebas. A continuación, se definen los factores controlables identificados:

Dentro de los factores no controlables se señalan:

De acuerdo con los factores controlables del experimento se define como la cantidad de direcciones enviadas en una petición como 10,000, la cantidad máxima de direcciones de respuesta serán 10 para cada una de las direcciones enviadas y se realizarán 10 réplicas de la prueba para cada versión del sistema.

La unidad experimental que se utilizará para el despliegue de los sistemas desarrollados contiene un microprocesador Intel (R) Core (TM) i5-4200U @ 1.60HGz 2.30 GHz, 8 GB de memoria Ram, 1 TB de almacenamiento HDD y utiliza el sistema operativo Windows 8.1 Pro. La base de datos de referencia a utilizar se encuentra en 2 servidores en Real Application Cluster de Oracle que cuentan con 2 CPU AMD(R) Opteron @ 2.60GHz, 6 GB de memoria Ram, 70 GB de almacenamiento HDD y utilizan el sistema operativo SUSE Linux Enterprise Server 11. 64 bits.

Los resultados de la ejecución de la prueba utilizando las versiones secuenciales y las versiones paralelas del sistema se muestran en la Tabla 2.

Con el objetivo de demostrar que las nuevas variantes del sistema mejoran el tiempo de ejecución de la variante original y establecen comparaciones entre ellas de acuerdo con los resultados obtenidos, se utilizarán pruebas estadísticas. Dentro de las pruebas de hipótesis se encuentra la prueba de Kruskal-Wallis, que se utiliza para determinar si las medianas de dos o más muestras difieren. Esta prueba se utiliza para comprobar si existen diferencias entre los tiempos de ejecución de cada una de las variantes del algoritmo. Para ello se definen como hipótesis las siguientes:

H₀ corresponde a la hipótesis nula y H₁ es la hipótesis alternativa. Se utiliza un α = 0.05 (nivel de significación). En la Tabla 3 se muestra el resultado de realizar la prueba usando el software Minitab 16.

Al realizar la prueba se obtuvo un valor p = 0.000 como resultado de un redondeo. Como este valor es menor que α se rechaza la hipótesis nula y se acepta la hipótesis alternativa, por lo que se puede concluir que los sistemas difieren en cuanto al tiempo de respuesta.

Una vez comprobado que los tiempos de respuesta de los sistemas difieren entre sí se pasa a comprobar que las nuevas implementaciones (versiones 2, 3 y 4) ofrecen mejores prestaciones que la versión 1 en cuanto a tiempo de ejecución. La demostración se realizará apoyándose de la prueba de hipótesis Mann-Whitney.

Cuando se realizan dos o más comparaciones entre muestras para determinar cuál de ellas es menor, mayor o igual que las otras, la probabilidad de rechazar una hipótesis nula que en realidad es verdadera (error de tipo 1) es mayor que α debido a la repetición de la prueba con un nivel de significancia determinado, por lo que se debería utilizar un método que ajuste el nivel de significancia. Según ^{García & Lara (1998)} uno de los métodos que tratan este problema es el método de Bonferroni que plantea ajustar el nivel de significancia a α/m siendo m la cantidad de comparaciones que se realizarán.

En un primer momento se realizarán las comparaciones necesarias para demostrar que todas las versiones nuevas del sistema de geocodificación son más rápidas que la versión original. Para ello se define un α = 0.05 y el número de comparaciones a realizar 3 por lo que α_ajustada = 0.017.

Comparación entre la versión 3 y la versión 4

Para determinar si existen diferencias entre los tiempos de ejecución de las variantes 3 y 4 se definen como hipótesis las siguientes:

• H₀: Las versiones 3 y 4 son iguales en cuanto a tiempo de respuesta.

• H₁: La versión 3 del algoritmo presenta tiempos de ejecución mayores que la 4.

El resultado de la prueba se muestra en la Tabla 8.

Tabla 8: Prueba Mann-Whitney para comparar las versiones 3 y 4 del sistema de geocodificación 

Prueba de Mann-Whitney e IC: Versión 3; Versión 4
Versión	N	Mediana
Versión 3	10	47.319
Versión 4	10	41.50
La estimación del punto para ETA1-ETA2 es 6.274 95.5 El porcentaje IC para ETA1-ETA2 es (1.650;6.954)	W = 139.0	Prueba de ETA1 = ETA2 vs. ETA1 > ETA2 es significativa en 0.0057

Al realizar la prueba se obtuvo un valor p = 0.0057, que es menor que el α_ajustada por lo que se rechaza la hipótesis nula y se acepta la hipótesis alternativa.

De forma gráfica se puede observar el comportamiento respecto al tiempo de las diferentes versiones del sistema en la Figura 5, donde se observa una diferencia significativa entre las versiones secuenciales del sistema (versiones 1 y 2) respecto a las versiones paralelas del mismo (versiones 3 y 4).

Figura 5: Gráfica de caja del tiempo de procesamiento de las versiones del sistema 

De acuerdo con las versiones 3 y 4 del sistema en la Figura 6 se puede observar que en determinadas instancias el tiempo de procesamiento con ambos sistemas paralelos fue similar, pero en la mayoría de las ejecuciones, el tiempo que se demoró el proceso de geocodificación con la versión 4 fue inferior que con la versión 3.

Figura 6: Gráfica de caja del tiempo de procesamiento de las versiones 3 y 4 del sistema 

Como resultado de las pruebas realizadas se obtuvo que la versión 4 es la que más reduce los tiempos de respuesta del sistema de geocodificación. Dicha versión corresponde a la implementación paralela con la lógica del proceso de geocodificación independiente a la base de datos de referencia. No obstante, se recomienda la realización de otras pruebas para verificar cómo se comporta la versión 4 del sistema con lotes pequeños de direcciones, incluyendo la geocodificación de una sola dirección.

Asimismo, es recomendable realizar una nueva comparación, similar a la realizada en ^{De Armas & Gutierrez (2013)}, entre la mejor versión obtenida en el presente trabajo y un servicio online de geocodificación, como el API de geocodificación de Google o Nominatim de OSM, con el fin de verificar la calidad de las direcciones encontradas y al mismo tiempo, comparar los tiempos de respuesta de cada servicio; ya que, en este momento, dicha comparación no fue posible debido a la calidad de los datos en Cuba de estos servicios. Esta carencia trae consigo una alta probabilidad de que se queden muchas direcciones sin encontrar, lo que falsearía los resultados para comparar.

Conclusiones

A partir de la realización de este trabajo se puede concluir que los objetivos y tareas planteadas fueron cumplidos. Además, se arriba a las siguientes conclusiones: