sistema normalizacion de direcciones.pdf
TRANSCRIPT
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • : . • • • • • • • • • • • •
005.3 e 183 1999
. .
INFORME FINAL PROYECTO ¡1 rf-/ 60G_
DE INNOVACION TECNOLÓGICA
"SISTEMA DE NORMALIZACIÓN DE DIRECCIONES"
BIBLIOTECA C ORfo
Roberto Camhi Levy
PRESENTACIÓN
l ñb ~': En el último decenio, se constata que el país ha sabido enfrentar con ·éxito el desafío impuesto por la política de apertura en los mercados internacionales, alcanzando un crecimiento y desarrollo económico sustentable, con un sector empresarial dinámico, innovador y capaz de adaptarse rápidamente a las señales del mercado.
Sin embargo, nuestra estrategia de desarrollo, fundada en el mayor esfuerzo exportador y en un esquema que principalmeme hace uso de las ·ventajas comparativas que dan los recursos narurales y la abundancia relativa de la mano de obra, tenderá a agotarse rápidamente como consecuencia del propio progreso nacionaL Por consiguiente, resulta determinante afrontar una segunda fase exportadora que debe estar caracterizada por la incorporación de un mayor . valor agregado de inteligencia, conocimiemos y tecnologías a nuestros productos, a fin de hacerlos más competitivos.
Para abordar el proceso de modernización y reconverswn de la estructura productiva del país, reviste vital importancia el papel que cumplen las innovaciones tecnológicas, toda vez que ellas confieren sustentación real a la competitividad de nuestra oferta exportable. Para ello. el Gobierno ofrece instrumentos financieros que promueven e incentivan la innovación y er desarrollo tecnológico de las empresas productoras de bienes y servicios.
El Fondo Nacional de Desarrollo Tecnológico y Productivo FONTEC, organismo creado por CORFO, cuenta con Jos recursos necesarios para financiar Proyectos de Innovación Tecnológica, formulados por las empresas
· del sector privado nacional para la introducción o adaptación y desarrollo de productos, procesos o de equipos.
Las Líneas de fmanciamiento de este Fondo incluyen, además, el apoyo a la ejecución de proyectos de Inversión en Infraestructura Tecnológica y de Centros de Transferencia Tecnológica a objeto que las empresas dispongan de sus propias instalaciones de control de calidad y de investigación y desarrollo de nuevos productos o procesos.
1
De este modo se tiende a la incorporación del concepto "Empresa -País", en la comunidad nacional, donde no es sólo una empresa aislada la que compite con productos de calidad, sino que es la "Marca - País" la que se hace presente en los mercados internacionales.
El Proyecto que se presenta, constituye un valioso aporte al cumplimiento de los objetivos y metas anteriormente comentados.
FONTEC - CORFO
• • • • • '1 .; ,, ,, () o 6)
•• fi
• e • t>
• • • • ., • • • • • • • • • • • • • ·~ ·~ • • • . , • • '
·~ V
Contenido
1.- Resumen Ejecutivo
1.1.- Ahorro de Costos 1.2.- Efectividad en los envíos por correo 1.3.- Buena imagen de servicio 1 .4.- Ingreso de datos a un sistema geográfico
2.- Exposición del problema
2.1.- Objetivos Técnicos 2.1.1.- Modos de operación
2.1.1.1.- Modo Batch 2.1.1.2.- Modo Interactivo 2.1.1.3.- Modo Mixto
2.1.2.- Rendimiento
8 2.2.- Producto Desarrollado
2.2.1.- Configurable 2.2.2.- La Normalización 2.2.3.- Búsqueda con aproximación 2.2.4.- Manejo de Datos
l~IBL/OTECA
2.2.5.- Multidiccionario
3.- Metodología y plan de trabajo
3.1.- Diseño Físico del Sistema 3.1.1.- Tablas Diccionario
3.1.1.1.- Calles 3.1.1.2.- Alias_calle 3.1.1.3.- Clases 3.1.1.4.- Comunas 3.1.1.5.- Separadores 3.1.1.6.- Letras 3.1.1.7.- Cambios
3.1.2.- Tablas de Normalizaciones 3.1.2.1.- Prueba (Archivo a normalizar) 3.1.2.2.- Normalizaciones 3.1.2.3.- Posibles 3.1.2.4.- Calles
4
4 4 5 5
6
6 7 7 7 7 8 8
10
11 12 12 12 12 12 12 12 12 13 13 14 14 14
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
4.- Resultados
4.1.- Resultados del proceso de normalización 4.1.1.- Caso Telefónica
4.1.1.1.- Creación del Diccionario 4.1.1.2.- Asignación Dica
4.1.2.- Caso Correos 4.1.2.1.- Integración del diccionario 4.1.2.2.- Asignación Código Postal
4.2.- Resultados de Interfaz de Usuario 4.2.1.- Menú Archivo 4.2.2.- Menú Normalización
5.- Impactos del proyecto
6.-ANEXOS
15
15 15 16 17 19 19 20 21 21 23
24
• • • • • • • • • • :1 • • • • • • • •• • • • • • • • • • • • • • • • • .~
• • • • • • • •
1.- Resumen Ejecutivo
El sistema de normalización de direcciones eMatch ha sido especialmente diseñado para satisfacer las necesidades reales de todos aquellos que requieran estandarizar sus bases de datos de clientes y/o ubicarlos en un plano digital (geocodificación) .
El sistema trae incorporado el diccionario de calles del Plano digital de Santiago, desarrollado por el servicio Aerofotogramétrico de la FACH y Chilectra SA Su actualización se encuentra garantizada por el SAF .
Las principales características del sistema son:
• Sistema desarrollado para correr bajo Windows 95/98/NT con configuraciones estándar.
• Importación de archivos de texto, con direcciones en lenguaje natural • Normalización automática y asistida para aquellas direcciones que no
tengan calce exacto . • Exportación de datos a archivos de texto en múltiples formatos . • Capacidad de aprendizaje del sistema, mediante la incorporación de nuevos
elementos al diccionario . • Permite encontrar direcciones escritas con errores
incompletas, configurable por el usuario . • 100% Interactivo y de fácil manipulación . • Sobre un 80% de calce automático .
ortográficos q
é:~UOTECA c_o! f ~
Las principales ventajas de incorporar eMatch en la empresa son las siguientes:
1.1.- Ahorro de Costos
Contribuye en las políticas de ahorro pues, en gran medida, evita incorrecciones y duplicidades en los envíos de correspondencia, agiliza la localización alfabética de clientes, facilita la creación de estadísticas, etc .
1.2.- Efectividad en los envíos por correo
Incrementa el número de comunicaciones eficaces en los envíos por correo, evitando ese porcentaje de expediciones que no llega a su destino final por defectos de la información (sin código postal, dirección incompleta, nombre de calle mal escrita, etc.)
4
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
1.3.- Buena imagen de servicio
Frente a una dura competencia, genera una imagen de buen servicio, reflejada, entre otros factores, por unos datos perfectamente correctos y normalizados, facultando la captación de nuevos clientes y la fidelización de los antigUos .
1.4.- Ingreso de datos a un sistema geográfico
Con el sistema de normalización de direcciones, los datos de clientes quedarán listos y preparados para ser utilizados en un sistema GIS. La geocodificación (asignación de una coordenada espacial al dato) será directa al ser utilizada con el plano del SAF .
E-Match permite disminuir hasta en un 90% los tiempos de normalización de direcciones con métodos tradicionales (manuales o a través del uso de GIS), ya que utiliza algoritmos propios, desarrollados especialmente para la estructura de direcciones utilizadas en Chile. Su indexación especial de nombres de calles, previamente realizada y configurada en el sistema, optimiza aún más la búsqueda de patrones. Cada dirección que tiene mas de una posibilidad de calce, es presentada para que el usuario, interactivamente, seleccione la dirección correcta .
Siempre es posible tener una visión global del proceso de normalización, identificando claramente aquellas direcciones normalizadas, aquellas con más de una posibilidad de calce y aquellas que no fueron encontradas en el diccionario de calles .
5
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
2.- Exposición del problema
Hoy en día, con el creciente aumento y utilización de sistemas digitales, la cartografía digital y los sistemas de información geográfica se están convirtiendo en una excelente herramienta para los más variados usos comerciales y operativos. Uno de los problemas que se encuentran cuando se desea ubicar una dirección en un plano digital (usando geocodificación) es la necesidad de conocer de manera precisa cuál es el nombre bajo el cual está archivada la calle a la que se desea referir .
En Chile no existe política alguna en cuanto a la asignación del nombre de calles por parte de municipalidades, empresas inmobiliarias ni gobierno. Esto causa que los sistemas computacionales que deben encontrar direcciones a partir de nombres de calles, no encuentran una cantidad significativa de calles, por el hecho de que están escritas de manera distinta a la usada en la base de datos. Por ejemplo si en la base de datos se ingreso una calle de nombre "Av . Libertador Bernardo O'Higgins ", y se intenta buscar una dirección en la calle "Av. Libertador Bdo. O'Higgins", el programa que realiza la búsqueda en la base datos no se dará cuenta de que ambos nombres corresponden a la misma calle. Lo mismo pasaría al buscar por "Alameda" o "Av. Lib. Bdo . O'Higgins". En caso de no encontrarse coincidencias exactas el sistema mostrara sugerencias de nombres de calles relacionadas con la buscada, que si existen en la base de datos .
Se hace necesario tener un esquema que asigne a cada calle un nombre único, que llamaremos normal o normalizado, y una herramienta que permita encontrar esa normalización, a partir de alguna forma alternativa de escribir la misma calle, o incluso nombres completamente distintos (como el caso de "Alameda") .
2.1.- Objetivos Técnicos
El objetivo perseguido en este proyecto fue crear una herramienta que permitiera dar una solución definitiva al problema de normalización de direcciones, y que permitiera manipular en forma rápida y sencilla un numero considerable de direcciones para así lograr una disminución considerable en el tiempo necesario para la normalización .
El sistema está compuesto en una serie de módulos, los que se encargan en convertir una dirección escrita en lenguaje natural (nombres de calles mal escritas, con sinónimos, puntuaciones, etc.) en una dirección normalizada (lista para ser geocodificada por el sistema GIS) .
La entrada para el sistema es una línea completa con la dirección, y la salida son cinco campos, como se muestra a continuación .
6
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
Ejemplo:
Entrada ~v. 4to. Centenano # 343 Torre A, dpto. 78, Las Condes!
Salida Tipo Calle Nombre Calle Número Comuna
Anexos Avda Cuarto Centenario 343 Las Condes Torre A dpto
78
2.1.1 Modos de operación 1 - - .. --- --
1. CIBLIOTECA c_o_RF~
El sistema provee de tres modos básicos de operación los que se describen a continuación:
2.1.1.1.- Modo Batch
Este modo de operación permite que la normalización se lleve a cabo sin la intervención del usuario además permite procesar una gran cantidad de direcciones, entregando como resultado un archivo con las direcciones, incluyendo su normalización, indicando además aquellas que presentaron problemas o no pudieron normalizarse .
2.1.1.2.- Modo Interactivo
Este modo permitirá que el usuario pueda realizar la normalización en forma interactiva, es decir, dirección a dirección, ingresada directamente desde el teclado y con proceso en tiempo real. Con este esquema el sistema entregara sugerencias, y permitirá que el usuario llegue rápidamente al elemento buscado mediante pantallas de ayuda .
2.1.1.3.- Modo Mixto
Este modo permitirá normalizar grandes cantidades de direcciones con un mejor porcentaje de aciertos ya que después de aplicar una normalización estilo Batch a las direcciones, permitirá en forma rápida y sencilla normalizar en forma interactiva las direcciones que no tuvieron éxito en la normalización, para luego poder ser exportada a un formato quizás más cómodo para el usuario.
7
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
2.1.2 Rendimiento
En cuanto el rendimiento del sistema, no se ha definidos tiempos para la normalización, pero mientras esta este dentro de los rangos normales de procesamiento de información, por ejemplo si se quisiera normalizar 50.000 direcciones se esperaría que la repuesta no pasara mas allá de un par de horas, con esto lograríamos normalizar en tiempos inalcanzables mediante búsquedas manuales dentro de un diccionario de datos .
2.2.- Producto Desarrollado : r:~~;o~[c; -coR ·¡{¡·\ '--~--- J
El producto de innovación tecnológica desarrollado, es un software de aspecto muy similar a las aplicaciones tipo en el ambiente Windows, ya que la idea es que fuera muy similar a las aplicaciones que generalmente tienen acceso lo usuarios hoy en día, de esta manera se torna relativamente fácil de operar una vez conocido el funcionamiento general del software .
2.2.1.- Configurable
Lo más importante y que detallaremos en este punto es la forma que en que se resolvió el problema de la normalización de direcciones. Primero que nada revisaremos que un aspecto importante a lograr era la capacidad de configuración del sistema para que se fuera adaptando a la forma en que la gente escribe una dirección, esto quiere decir usando sinónimos, puntuaciones, etc. Para lograr esto se hizo necesario estar apoyado por un RDBMS (Sistema Administrador de Bases de Datos) ya que la forma más sencilla y adecuada de guardar información es través de un modelo de bases de datos que soportara este RDBMS . Con este esquema logramos aprovechar todas las ventajas que nos provee un RDBMS para búsquedas de registros en tablas, tantos exactas como aproximadas .
2.2.2.- La Normalización
Dadas las posibilidades que nos otorga un RDBMS el proceso de normalización consta en aplicar los mismos criterios aplicados tanto en la creación como en la mantención del diccionario a la dirección, para luego realizar la búsqueda en el diccionario de datos. Una vez realizada esta operación se procede con la búsqueda aproximada si la dirección no quedó normalizada .
8
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
2.2.3.- Búsqueda con aproximación
Esta búsqueda es realizada bajo el porcentaje de aproximación configurado en el menú opciones del sistema, y para el cual se utiliza una la "ygrep32.dll" para realizar una búsqueda en texto, así logramos alcanzar calces que no son posibles mediante búsquedas convencionales en bases de datos. Esta biblioteca permite realizar búsquedas en texto con porcentajes determinados por el usuario, y utiliza algoritmos para búsqueda en texto, en los cuales ha tenido influencia Ricardo Baeza Yates .
2.2.4.- Manejo de Datos /_E~~ e_ 0 _R F oj El sistema provee un aceptable manejo de información tanto de importación como exportación hacia el sistema, de esta forma se hace mucho más cómodo para trabajar con datos, desde distintas fuentes, por lo cual no es necesario acceder al administrador de la bese de datos para ingresar o exportar direcciones que por el hecho de que las tablas deban tener una estructura rígida para poder ser normalizadas, no es muy fácil configurar una tabla directamente con el administrador de la base de datos, por otro lado, es posible mantener seguro los datos y tablas que conforman el sistema .
2.2.5.- Multidiccionario
El sistema provee la posibilidad de manejar mas de un diccionario de datos, pudiéndose normalizar con el diccionario que se desee en ese momento, ya que dada la configuración del sistema podemos agregar nuevos diccionarios de datos, con sus respectivos elementos básicos como por ejemplo la tabla de calles, tabla de alias, etc. Una vez agregado un nuevo diccionario, el sistema nos provee la posibilidad de cargar estas tablas de forma manual o automático .
9
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
3.- Metodología y plan de trabajo
En esta etapa se definió el funcionamiento del sistema de normalización de direcciones. Primero que nada recordaremos el o los objetivos de este proyecto. El principal objetivo es pretender dar solución al problema de la estandarización o normalización de direcciones esto quiere decir que dado cierto diccionario de datos el cual contiene todas las calles de cierta región, debemos lograr estandarizar cualquier dirección con respecto a este diccionario. Y como consecuencia posiblemente pudiéramos obtener algún resultado adicional como por ejemplo un punto en un plano digital. Para el caso de este proyecto se están realizando pruebas con el diccionario desarrollado por el SAF y CHILECTRA, este diccionario nos permite obtener el punto en el plano digital donde se encuentra determinada dirección .
El esquema válido para cualquier diccionario es el siguiente:
Se Busca Se Obtiene
La normalización de direcciones corresponde exactamente a esto, dada una dirección buscarla en el diccionario correspondiente para poder identificar cada una de las partes que la componen es decir:
Clase o tipo de vía por ej. Avenida. Nombre de la calle . Numeración Comuna Anexo, que corresponde a cualquier antecedente adicional en la definición de una dirección por ej. Piso, local, bloque, etc .
Para cumplir con este requerimiento se construyeron dos módulos bien definidos . El primero un módulo encargado de intentar obtener en forma preliminar cada una de las partes de una dirección, este modulo es vital para el éxito en la búsqueda de direcciones dentro de un diccionario de datos ya que por ejemplo se utilizan abreviaciones para las comunas, para los tipos de vía, y se realizan todos los procesos de limpieza de una dirección como por ejemplo la
10
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
eliminación de caracteres extraños por ej. "#" Y los cambios de abreviaciones de palabras, como por ej. "GRAL" por "GENERAL" en el caso del diccionario de datos que estamos usando de prueba .
El segundo módulo que es el módulo de normalización, es aquel que toma el parsing hecho anteriormente y se encarga de buscar la dirección dentro del diccionario de datos, actualmente este implementado una parte de este modulo, el cual aun es muy básico, pero para efectos de prueba es muy útil.
El sistema es capaz de soportar o manejar mas de un diccionario y tiene capacidad de cargar por el momento archivos de texto tanto de archivos con direcciones a normalizar como de archivos para crear nuevos diccionarios de datos. Con lo cual el proceso de normalización de direcciones consta de las siguientes etapas:
Carga del archivo que contiene las direcciones a normalizar . Normalizar las direcciones . Exportar dichas direcciones normalizadas a un archivo de texto .
Otra de las cualidades que se desarrollaron, es el hecho de un manejo interactivo de la normalización con lo cual todas aquellas direcciones que no fueron normalizadas con los procesos automatizados de "Parsing" y "Normalización", el usuario es capaz de normalizar en forma interactiva .
3.1 Diseño Fisico del Sistema .
El sistema fue desarrollado utilizando la herramienta de programación VisUal Basic 5.0 combinado con bases de datos ACCESS 7.0 ambas herramientas de Microsoft para ambiente Windows95, Windows98, Windows NT con Service Pack 3.0 o superior.
11
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
El esquema anterior nos muestra las tablas y atributos necesarios para cada diccionario .
3.1.1 Tablas Diccionario
3.1.1.1 Calles
ID CLASE NOMBRE COMUNA
: Identificador de la calle : Tipo de Vía. : Nombre de la calle : Comuna a la que pertenece la calle.
3.1.1.2 Alias_calle
ID ALIAS
: Identificador de la calle : Nombre con el cual se le conoce a una calle ej. ALAMEDA
3.1.1.3 Clases
ID : Identificador único de la clase CLASE :Nombre de la clase ej. AVDA PRIORIDAD : Prioridad que tiene una clase frente a otra .
3.1.1.4 Comunas
ID COMUNA ABREV
: Identificador único de la comuna : Nombre de la comuna. : Una abreviación para el nombre de comuna.
3.1.1.5 Separadores
ID SEPARADOR
3.1.1.6 Letras
: Identificador único del separador : Carácter a eliminar o reemplazar con blancos, la idea es que los caracteres que aparecen en ésta tabla no sean considerados ej. "#" .
ID : Identificador único de la letra . ENT : Letra a reemplazar SAL : Letra sustituta, la utilidad es reemplazar letras por otras que si son
usadas en el diccionario, por ejemplo en el diccionario que tenemos de prueba no se usa "til" sino "N" .
3.1.1.7 Cambios
ID : Identificador único de la abreviación
12
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
NOM ABREV
: Palabra a reemplazar : Palabra que reemplaza Esta tabla nos sirve para realizar todas las abreviaciones que contiene el diccionario de datos .
~ECA CORFO 1 El esquema anterior nos muestra como funciona la normalización. Cada" - · j archivo a normalizar se almacena en una tabla que contiene la misma estructura que la tabla prueba, esto quiere decir que por cada archivo a normalizar se crea una nueva tabla, lo que es incorrecto con respecto a la teoría de modelos relacionales, pero en cuanto a la eficiencia es mucho más eficiente. En la tabla prueba se muestran una serie de campos que comienzan con "N_", estos campos corresponden a la normalización, con lo cual por ej. Si el campo N_NOMBRE esta vacío significa que dicha dirección aún no está normalizada, a continuación se detallan cada uno de los campos que componen estas tablas .
3.1.2 Tablas de Normalizaciones
3.1.2.1 Prueba (Archivo a normalizar)
N ID
N DIR
N CLASE
N_NOMBRE
: Identificador único del registro.
: String que contiene la dirección a normalizar.
:Campo clase que se obtiene producto de la normalización.
: Campo nombre de calle que se obtiene producto de la normalización .
N_NUMERACIÓN : Campo numeración que se obtiene producto de la normalización .
13
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
N ANEXO : Campo anexo que se obtiene producto de la normalización .
N_COMUNA : Campo comuna que se obtiene producto de la normalización .
N OBSERV : Este campo nos indica el estado actual del registro, en cuanto a si esta o no normalizado .
P _• : Estos campos son idénticos a los anteriores salvo que se obtienen producto del Parsing, el cual es el proceso previo .
CAMPOS ANEXOS : Todos los campos que no están incluidos en los anteriores, son campos que venían junto al archivo cargado,
3.1.2.2 Normalizaciones
Esta tabla nos permite visualizar que archivos a normalizar tenemos dentro del sistema, además del estado general de estos archivos de normalización
3.1.2.3 Posibles
Esta tabla nos indica todas las calles con las que calza la dirección que actualmente se está buscando, asi también guarda el dato de la calle en cazo de ya estar normalizada .
3.1.2.4 Calles
Esta es la misma tabla descrita anteriormente .
14
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
4.- Resultados
Los resultados alcanzados por este proyectos se pueden dividir en dos categorías muy marcadas, por un lado tenemos los resultados de interfaz de usuario, y por otro lado, tenemos los resultados que tienen que ver netamente con el proceso de normalización .
4.1 Resultados del proceso de normalización
La normalización de direcciones tuvo varias modificaciones durante .el desarrollo del proyecto, ya que fue evolucionando a medida que el sistema fue puesto a prueba por las distintas bases datos que fueron llegando a la empresa ISG. Las pruebas hechas fueron indispensables para mejorar la normalización en dos puntos fundamentales, como lo son el tiempo de respuesta del proceso, como el porcentaje de aciertos o registros normalizados, ya que ambos contribuyen en la eficacia del sistema .
A continuación se detallan algunas pruebas hechas con sus respectivos resultados .
; --....., ........ __ _ 4.1.1.- Caso Telefónica j ~~~~C-o_R f ~
Una de las pruebas hechas fue el intento de crear un diccionario de datos para telefónica, el cual se logró a nuestro parecer con bastante éxito, ya que el diccionario de ellos constaba de una lista de direcciones con sus alturas, y esta era utilizada para la asignación de un código interno de ellos. Una muestra es la que sigue:
La muestra total constaba de 32770 registros, y la forma que se operaba era que buscaban en forma manual cada dirección dentro de esta base de datos, y
15
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
si la encontraban, incluyendo que estuviera dentro de los rangos de altura, se le asignaba el código correspondiente .
4.1.1.1.- Creación del Diccionario
El traspaso o adecuación al sistema normalización sobre esta base de datos no era directo ya que primero que nada el diccionario de calles anterior no estaba normalizado ni tenía reglas claras en su creación, por lo que el mejor esquema diseñado para dar solución a este problema fue el siguiente:
• Se tomó este diccionario y se cargo al sistema tal como si fuera otra carga a normalizar.
• Se normalizó con respecto al diccionario del SAF . • Una vez normalizado, se creó el nuevo diccionario, el cual heredó las
cualidades del diccionario SAF
Con lo anterior ya contábamos con un diccionario, que heredo las cualidades del diccionario SAF, además de poder seguir entregando el código que hasta el momento entregaba, pero al normalizar este diccionario quedaron registros sin normalizar, y para lograr afinarlo, será necesario revisar una a una las calles no normalizadas. Una visión de como quedo este diccionario es la que sigue:
Los registros con Tipo = ·•· son aquellos que quedaron sin normalizar, y los cuales deben ser revisados para afinar el funcionamiento de este diccionario . El campo 'Id' no es el mismo código de la tabla original, ya que este diccionario es un agrupamiento de los registros originales, no tomando en cuenta la numeración .
El siguiente gráfico nos muestra la eficacia de la normalización al diccionario de Telefónica:
16
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
Normalización Telefónica
1 [J Normalizados 1!1 Pendientes •Otras Comunas 1
De un total de 32770 registros, 27230 registros fueron normalizados, y 2336 quedaron pendientes y 3204 eran registros que pertenecían a comuna no manejadas por el diccionario SAF .
En cuanto al tiempo de procesamiento de esta base de datos, fue alrededor de los 20 minutos, en una máquina Pentium 11 de 450 Mhz. Con 64 MB de RAM, esto equivale a alrededor de 1600 registros procesados por minuto, lo cual está lejos de los tiempos de normalización que se lograron en los comienzos del desarrollo, valores que fluctuaban entre los 2000 y 3000 registros procesados por hora .
4.1.1.2.- Asignación Dica
"Dica" es el código que asigna Telefónica a las direcciones de sus clientes, y esta asignación se basa en buscar el código utilizando la tabla anteriormente descrita .
Una vez que el diccionario para telefónica quedó configurado, estabamos en condiciones para lograr esta asignación, solo bastaba normalizar las direcciones de clientes con respecto a este nuevo diccionario, y el paso siguiente es inmediato, ya que solo bastaba con un join entre la tabla normalizada y la tabla que contenía los códigos a asignar. Los pasos que nos llevaron a la asignación de este código fueron los que siguen .
Primero que nada se normalizó una muestra de direcciones de clientes con respecto al diccionario creado de la forma descrita anteriormente
17
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
Los registros a normalizar fueron presentados con el siguiente formato:
La muestra de clientes de Telefónica constaba de 19603 Registros. El resultado de la normalización de estas direcciones se muestra en el siguiente gráfico:
Normalización con Diccionario Telefónica
21% 7%
72%
lliJPendientes liJNormalizados []Sin Normalizar 1
Normalizados quedaron 14215 Registros, pendientes 1318, y sin normalizar 4070 .
Una vez realizada la normalización de estos registros, se procedió a la asignación del código Dica, proceso que nos arrojó como resultado: 10934 registros con código dica y 3281 sin código. Una de las principales causas de porque no todos los registros normalizados quedaron con su respectiva asignación de código, es debido a que la numeración no se valida durante el proceso de normalización, ya que al asignar el código, se hace en forma implícita esta validación .
18
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
En el siguiente gráfico podemos apreciar cuantos o que porcentaje de direcciones normalizadas tenía su numeración invalida o fuera de rangos definidos en el diccionario inicial.
Asigna e ió n e ó digo D ic a
23%
II!JCon Código I!JSin Código 1
En cuanto al análisis de los resultados obtenidos en este caso, cabe destacar que los porcentajes de registros efectivamente normalizados sin tomar en cuenta las posibilidades de aumentarlo con una revisión interactiva, es muy bueno, tomando en cuenta que siempre se trabajo con datos muy poco depurados, y el hecho de que ni siquiera el diccionario estaba normalizado, con lo cual, el sistema respondió satisfactoriamente a lo esperado .
4.1.2.- Caso Correos
Este caso nació a raíz del interés de Correos de Chile por tener una herramienta al alcance de las llamadas " Empresas Chicas ", para sus procesos de normalización de direcciones y asignación de código postal. La asignación de código postal, consiste en asignar un código a una dirección, según en que área este ubicada, cada área tiene asignado un código postal, el cual le corresponde a la dirección si es que pertenece a esa área, esto es lo que se llama "Zonificación". Dado que Correos estuvo dando el servicio de normalización y asignación de código postal gratis, se lleno de peticiones de servicio de muchas empresas, en las cuales contenían un promedio de 20.000 registros o menos, surgió la necesidad de contar con una herramienta, que permitiera a Correos, desligarse de dichas peticiones, y sólo dar servicio a sus clientes regulares, que por lo general son empresas que trabajan con gran cantidad de información .
4.1.2.1.- Integración del diccionario
En este caso hablamos de integración del diccionario, ya que Correos de Chile cuenta con su propio diccionario de calles, por lo cual esta etapa consistió en ajustar este diccionario al diccionario de calles manejado por el sistema . La adecuación comenzó por la tabla de calles, Correos tenía disponible una tabla con características similares a la tabla de calles del sistema, con lo cual
19
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
la carga de los datos fue prácticamente directa. A continuación se siguió con los sinónimos o alias, tuvimos que descartar la gran mayoría, ya que Correos casi no maneja abreviaciones .
Una vez cargado el diccionario para Correos , quedó de la siguiente forma :
Se puede apreciar además que correos no maneja el tipo de vía por separado, ante este requerimiento, para que el sistema pudiera soportar este hecho, bastó con eliminar los registros de la tabla Clases .
4.1.2.2.- Asignación Código Postal
Para la asignación del código postal bastó con buscar las direcciones ya normalizadas en la tabla que tenía la estructura siguiente:
La forma era buscar la dirección con el id de la calle asignada dentro de esta tabla, para luego buscar la numeración , si esta era par, se le asignaba el código cppar, de lo contrario se le asignaba el código cppar .
En cuanto al resultado de estas pruebas, la normalización se realizó de forma idéntica a la hecha con el diccionario SAF, alcanzando valores de eficiencia muy similares , esto quiere decir alrededor del 78% en la forma automática .
20
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
4.2 Resultados de Interfaz de Usuario
En cuanto a la interfaz de usuario , en este momento el software reúne condiciones suficientes para un manejo del sistema , una vez que se ha comprendido el funcionamiento general de este, provee fácil acceso a datos , y exportación de registros ya normalizados . En la siguiente figura se aprecia el aspecto general del E-match .
Analizaremos cada uno de los menús del E-match .
4.2.1 Menú Archivo
Esta opción nos permite interactuar con el medio , ya que es la única vía por la cual podemos ingresar registros al sistema , y exportar registros a distintos formatos .
La opción Acceso a datos permite importar y exportar datos desde cualquier formato si bien da la posibilidad de importar y exportar tablas , no es tan directo su uso en la normalización ya que es un poco genérico .
La opción importar es un diálogo que permite importar registros a normalizar , desde archivos de texto plano , y deja estos archivos listos para ser normalizados . Otra cualidad es que permite elegir el proceso Batch, que consiste en carga de registros y creación en paralelo de un archivo de salida en formato texto con los registros ya procesados. Es muy importante esta forma de normalizar, puesto que es la forma más eficiente y segura de normalizar grandes cantidades de información (más de 50.000 registros es aconsejable)
21
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
La opción exportar permite llevar los registros procesados a un archivo de texto, en el orden, y los campos relevantes que se necesiten .
Estas tres opciones se muestran en las figuras siguientes:
Una vez importada una tabla a través de este diálogo es necesario inicializarla para poder ser normalizada, esto permite definir cada columna que conforma la dirección, además de ser registrada como una normalización válida, y así ser vista en el explorador de normalizaciones. Al elegir esta opción podemos ejecutar consultas SOL, en un diálogo anexo, y se puede exportar cualquier tabla dentro del sistema, además de las consultas SQL generadas .
La carga de archivos a través de este diálogo es solo para archivos en formato texto . Una vez indicado el separador de columna se deba indicar cada parte que conforma la dirección. Archivo de Entrada: Se debe indicar la ruta completa del archivo de texto a importar Archivo de Salida: Se debe dar un nombre con el cual se reconocerá internamente este archivo a normalizar. Al elegir proceso batch normaliza el archivo sin cargarlo al sistema .
22
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
4.2.2 Menú Normalización
que registros exportar, el filtro es por el estado de la normalización En opciones podemos elegir que campos exportaremos, así como el orden en que saldrán . Esta exportación es solo hacia archivos de texto, y es más directa que la anterior, especialmente diseñada para las normalizaciones cargadas al sistema .
Este menú tiene relación directa con los procesos de normalización y las opciones son: Explorar, Cerrar, Normalizar, Revisión Manual y Buscar Calle . La opción Cerrar solo cierra la normalización actual que se encuentre abierta, las otras opciones se muestran a continuación .
La opción explorar muestra todos lo archivos a normalizar existentes en el sistema, también se utiliza para otro tipo de operaciones como por ej. Cuando necesitamos seleccionar una normalización que va a ser exportada o normalizada .
La opción abrir nos muestra el modo la normalización seleccionada en forma de grilla, con cada uno de los registros, además del estado de la normalización .
Las otras opciones del sistema no se detallaran, puesto que cumplen con los mismos formatos de las ya presentadas, en las cuales se manejan la configuración de los diccionario y de variables globales del sistema .
23
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
5.- Impactos del proyecto
En cuanto a los impactos técnico-económicos producidos por este proyecto, se podría decir que fue todo un éxito ya que en estos momentos se encuentra en uso en la empresa ISG (Ingeniería y Sistemas Gráficos), la cual nos sirvió de trampolín para la llegada al mercado, esta herramienta es en la actualidad muy útil para dicha empresa, ya que esta empresa, entre otras cosas, se dedica a la geocodificación de direcciones y distribución del producto geomedia, además se creó una especie de sociedad tecnológica, de manera informal, en la cual por nuestra parte se les facilitó el uso del sistema sin restricciones y por parte de ellos contamos con la promoción y la posibilidad de contar con muestra de datos de clientes, las cuales resultaron ser de mucha utilidad, ya que contamos durante el proyecto con una gama muy amplia de datos, para poner a prueba el sistema .
Por otro lado además se iniciaron en forma paralela, conversaciones con Correos de Chile y con Telefónica, con los primeros para facilitar la asignación de código postal a las direcciones de clientes, con Telefónica para lograr configurar su propio diccionario de calles, y así lograr asignar un código interno manejado por ellos. Otra empresa que también ya tiene este software es Chilnet, ya que con este podrán apoyar la labor desempeñada por el software GeoMedia distribuido por ISG .
Como conclusión podemos acotar que se están abriendo muchas posibilidades de distribución y desarrollo, materializado en distintos proyectos que involucran al sistema, en áreas muy variadas como la zonificación, geocodificación. y marketing .
24
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • ..
ANEXOS
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • A
DETALLE BI-MENSUAL DE GASTOS DEL PROYECTO JUNIO-JULIO 1999
(Valores en pesos)
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
DETALLE BI-MENSUAL DE GASTOS DEL PROYECTO AGOSTO- SEPTIEMBRE 1999
(Valores en pesos)
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
DETALLE BI-MENSUAL DE GASTOS DEL PROYECTO OCTUBRE- NOVIEMBRE 1999
(Valores en pesos)
- --BIBLIOTECA .. C _R f oj
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • ,.
DETALLE BI-MENSUAL DE GASTOS DEL PROYECTO DICIEMBRE-ENERO 2000
(Valores en pesos)
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
DETALLE BI-MENSUAL DE GASTOS DEL PROYECTO FEBRERO-MARZO 2000
Ingeniero 1 Ingeniero 2 Apoyo Correos
(Valores en pesos)
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •• iA
CUADRO RESUMEN GASTOS GENERALES PROYECTO DE INNOVACIÓN TECNOLÓGICA
1.- ANTECEDENTES GENERALES
CÓDIGO DEL PROYECTO: 99-I606 TITULO DEL PROYECTO : Sistema de Normalización de Direcciones E-match EMPRESA SOLICITANTE: Roberto Camhi Levy INFORME DE A V ANCE N": 2 . TOTAL DE INFORMES : 2
2.- CUADRO RESUMEN DE GASTOS (Junio 1999- Marzo 2000)
r ¡ •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
RESUMEN DE ACTIVIDADES DESARROLLADAS PROYECTO DE INNOV ACION TECNOLOGICA
IMPLEMENTACIÓN DE LOS RESULTADOS DEL PROYECTO
---BIBL!~
El proyecto ha sido exitosamente desarrollado de acuerdo a los planteamientos iniciales de la propuesta a Fontec. Actualmente se encuentran licencias en uso en las empresas Chilnet S.A. e lSG S.A. Empresas de la envergadura de Correos de Chile y Telefónica han mostrado gran interés en contar con herramientas de este tipo para apoyar su proceso de normalización y georeferenciación de clientes, por lo que nos encontramos trabajando en proyectos con ellas .
No obstante lo anterior y debido a requerimientos específicos de algunos clientes, se han incorporado funcionalidades adicionales, las que potencian en gran medida el producto .
Por tal motivo, en la actualidad se está trabajando en la incorporación de nuevos diccionarios de calles, adaptados a los requerimientos de cada cliente. Es así, por ejemplo, que uno de los principales objetivos en el corto plazo, es permitir que el sistema incorpore los códigos postales de Correos en la Región Metropolitana. Esto permitirla que el normalizador se transforme en una herramienta de ahorro de costos en el envio de correspondencia, al incorporar el código postal.
Otro de los aspectos que se encuentra en avanzadas conversaciones, es la posibilidad de llevar el sistema a Argentina, incorporando el diccionario de calles del Gran Bs. As .
En resumen, el sistema de normalización ha tenido una excelente acogida, por lo que su desarrollo será continuado en el futuro, con el fin de transformarlo en un sistema de uso masivo a todas las empresas que requieran de un producto de apoyo al trabajo con su base de clientes .