A principios de la década de los '90 se acometió la conversión a formato digital de los planos de las redes de la empresa regional de suministro eléctrico. A la representación de la red se deseaba incorporar datos como serían las referencias de consumidores, los códigos identificadores de las subestaciones transformadoras y de los nodos de interconexión, las referencias a planos de detalles del soterramiento de cables y otras informaciones relacionadas. Estas referencias y códigos serían procesados mediante programas de gestión de bases de datos para generar mapas temáticos a partir del resultado de las consultas realizadas. Como resultado de la asesoría realizada, se recomendó como único método práctico disponible en el momento del diseño de la aplicación, la inclusión de atributos alfanuméricos variables, tanto visibles como invisibles, en referencias de bloque [7].

5.1. Bloques con atributos.

Los bloques permiten reunir un número variable de entidades gráficas en un único objeto contenedor. Este objeto contenedor BLOCK o definición de bloque, puede insertarse en los espacios gráficos o anidarse en otras definiciones de bloque generando objetos referencia de bloque (entidades de tipo INSERT). El concepto de referencia de bloque corresponde a un símbolo definible por el usuario y que está ligado a una geometría de componentes gráficos almacenada en un apartado específico de la base de datos del dibujo (tabla de bloques del archivo DWG). Puede entonces el modelo construirse a partir de ocurrencias (copias transformadas) de esa geometría. La ocurrencia de un símbolo contiene las mismas entidades gráficas de la definición de bloque original, aunque sometidas a desplazamiento, rotación y cambios de escala [11].

La incorporación a la definición del bloque de cadenas alfanuméricas como entidades del tipo TEXT no presentaría dificultades de acuerdo a esta definición. Sin embargo, la presencia de datos constantes sería de una utilidad relativamente escasa. La posibilidad de incluir como parte de una definición de bloque información alfanumérica variable para cada ocurrencia constituye una anomalía respecto a la definición estricta de bloque que presenta dificultades obvias. Ya no se trataría de una simple copia transformada en un sentido estrictamente geométrico de la definición original. Para dar solución a este caso se recurre a un proceso similar al utilizado para generar el bloque mismo: se crea una entidad gráfica especial, la entidad ATTDEF o definición de atributo, que actúa como plantilla, reservando un lugar y predefiniendo las características visuales que adoptará dicha información [13].

Esta viene a concretarse en su contenido literal sólo en el momento de generarse cada ocurrencia particular, es decir en el momento de la inserción del bloque (Figura 1) y pasando a generar una entidad nueva, el objeto referencia de atributo (entidad ATTRIB), asociados siempre al objeto referencia de bloque (INSERT). La referencia de atributo se asocia a la referencia de bloque estableciendo una secuencia en la base de datos de entidades, de manera tal que la entidad INSERT actúa como cabecera de una sucesión de entidades ATTRIB que viene a concluir con una entidad especial fin de secuencia (SEQEND).

Fig. 1 Bolque con atributos y sus inserciones. En este caso los atributos se han definido como invisibles.

Tanto el objeto definición de atributo como el objeto referencia de atributo no son más que ocurrencias de subclases ("AcDbAttributeDefinition" y "AcDbAttribute") derivadas de la subclase de objetos de texto "AcDbText" que forma parte a su vez de la clase de los objetos gráficos del dibujo "AcDbEntity". En realidad lo que estamos haciendo entonces no es más que añadir al dibujo textos que se relacionan con la cabecera del bloque (INSERT) por su posición secuencial en la base de datos, modificados para añadirles una etiqueta identificadora. El recurso es aunque simple, sumamente efectivo, pero con las limitaciones que expondremos más adelante (ver apartado 5.4.).

5.2. Extracción de la información contenida en los atributos.

El programa suministra el comando _ATTEXT para la extracción de estos atributos a un fichero de texto con formato a elegir entre CDF o SDF, que pueden ser leídos a su vez desde los programas de bases de datos más usuales. Los datos a extraer y su ordenamiento deberán ser definidos mediante un fichero de texto que actúa como plantilla de extracción (figura 2). La mediación obligada de un fichero externo restaría eficacia a procesos que no exijan este paso intermedio. Esto puede obviarse, sin embargo mediante el desarrollo de funciones de usuario que gestionen dichos atributos.

Fig. 2 - Plantilla para extracción de atributos

5.2.1. Función LISP para lectura de atributos.

La Figura 3 muestra el código fuente LISP para una función de este tipo, desarrollada empleando la recursión, método usual en LISP cuando se trata de operaciones sobre listas u otras secuencias. Esta función es recursiva por la cola (tail-recursive), con lo que se asegura un alto grado de optimización una vez compilada [8].

Figura 3. Función LISP para lectura de atributos.

5.2.2. Limitaciones al uso de Bloques con atributos.

La utilización de los atributos para asociar datos alfanuméricos a los bloques tiene una limitación: las referencias de bloque son por su naturaleza entidades de carácter puntual. La única información geométrica a ellas asociada se reduce a los resultados de las transformaciones aplicadas a la definición original, es decir, un punto de inserción, los factores de escala en X, Y, Z y el ángulo de rotación. Una entidad de naturaleza lineal o de superficie, por este motivo no resultaría adecuadamente representada mediante un bloque, aún cuando su apariencia en pantalla pudiera sugerir lo contrario.

---

Inicio | Índice | Continuar...