Proyecto AAGRAFA.

Carlos Villagrá Fernández <carlosv@ee.upm.es> Juan Gozález Cárceles <jugonzal@aq.upm.es> Diego ’Mago’ de Miguel <a26979@aq.upm.es> ^{∗}

julio de 2000

Esta ponencia forma parte del III Congreso Hispalinux^{1} virtual, celebrado en Noviembre de 2000. Puedes participar en él en la sección de eventos de BarraPunto^{2}

Resumen

El proyecto AAGRAFA (Adquisición y Almacenamiento GRÁFico de Arquitectura) es un proyecto de investigación llevada a cabo en la Escuela Técnica Superior de Arquitectura de Madrid (Universidad Politécnica). Consiste fundamentalmente en la captura digital del fondo documental de la Escuela (diapositivas, vídeos, libros del fondo histórico…), su catalogación en una base de datos y la consulta posterior de todo ello a través de Internet.

Financiado por la Universidad y por los Fondos Feder de la Unión Europea, este es un buen ejemplo de como mediante software libre, se pueden acometer ambiciosos proyectos, sin recurrir a costosos productos propietarios, sino utilizando herramienta y estándares abiertos, optimizando los recursos.

Índice General

1 Introducción. 1

2 Captura de datos. 2 2.1 Algunos criterios sobre su desarrollo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2 Captura digital de fotografías. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.3 Fotografía de documentos y libros de la biblioteca de la ETSAM. . . . . . . . . . . . . . . . . . 3 2.4 Grabación, edición y distribución de vídeo en formato digital. . . . . . . . . . . . . . . . . . . . 4 2.5 Captura de documentación de gran formato, cartografía y Proyectos de Fin de Carrera. . . . . 5

3 Linux en todo esto. 5 3.1 Procesado de imágenes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Distribución de la información. La base de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 Conclusiones. 9

5 Agradecimientos. 10

1 Introducción.

El proyecto AAGRAFA nació en 1996 en una reunión en la que el entonces Director de la Escuela y otros miembros de la comunidad académica, redactaron un proyecto que permitiese a la Escuela de Arquitectura participar en un plan de inversiones en infraestructura científica de la UPM, cofinanciado por la +Comunidad Europea con fondos FEDER I+D, durante los años 1996-1999. La inversión realizada alcanzó la cifra de 84 millones de pesetas. El nombre resume una propuesta de Adquisición y Almacenamiento de material GRÁfico de Arquitectura, orientada a la toma de datos -restitución fotogramétrica- y a la digitalización de originales -principalmente los de la Biblioteca de la ETSAM y su valioso Fondo Antiguo, junto a otra documentación relativa a la Arquitectura en general.

∗\begin{matrix}c \\ ◯ \end{matrix}Carlos Villagrá Fernández, Juan González Cárceles y Diego de Miguel Lería. \begin{matrix}c \\ ◯ \end{matrix}Escuela Técnica Superior de Arquitectura de Madrid. Se otorga permiso para copiar, distribuir y/o modificar este documento bajo los términos de la Licencia de Documentación Libre GNU, Versión 1.1 o cualquier otra versión posterior publicada por la Free Software Foundation. Se considerará como Secciones Invariantes todo el documento, no habiendo Textos de Portada ni Textos de Contra Portada. Puede consultar una copia de la licencia en: http://www.gnu.org/copyleft/fdl.html

1http://congreso.hispalinux.es

2http://barrapunto.com/eventos

El único inconveniente del proyecto era que sólo cubría la infraestructura de equipos pero no los gastos de personal, material fungible y otros servicios complementarios que resultaron necesarios y que, fundamentalmente, han sido desarrollados por aportaciones voluntarias.

Las tareas que hasta ahora se ha planteado abordar se pueden clasificar en cuatro grupos diferentes que se describen a continuación.

Cabe destacar que este proyecto se ha gestado en la Escuela de Arquitectura, por arquitectos y para arquitectos, y que casi todas las personas implicadas en su desarrollo son profesores o alumnos de la Escuela. Desde luego, lo que no hemos pretendido es revolucionar el mundo de la programación, ni pretendemos que nuestro desarrollo es lo más “profesional” del mundo. Seguramente, un programador experto nos sacaría los colores rápidamente. Pero la gran virtud del proyecto es la potente herramienta que supone en el campo de la docencia y la investigación de Arquitectura. Cuando todo esto esté funcionando (no vemos el día ;-)) se podrá acceder desde cualquier parte a todo tipo de contenidos gráficos y audiovisuales de arquitectura, no sólo de nuestra Escuela, sino de otras universidades.

2 Captura de datos.

2.1 Algunos criterios sobre su desarrollo.

Uno de los criterios generales adoptados ha sido orientar el trabajo de captura de información con el mayor rigor posible. En ese sentido el marco universitario es un buen complemento por su facilidad para disponer de información actualizada y poder discutir alternativas. Ese criterio se conjuga bien con otro adicional: considerar el trabajo de captura de datos de forma independiente al de su distribución, de ese modo pueden evitarse errores debidos a que el segundo condicione la forma en que se hace el primero y resulte obsoleto en un plazo breve. Aunque ambos dependen del desarrollo tecnológico, la distribución es, al menos por ahora, el cuello de botella; lo que no obsta para que consideremos que la captura se ha de realizar con la mayor calidad posible procurando crear un modelo alternativo al original. La segunda parte, su distribución posterior, es lo que afecta más a la calidad del producto final, pero para ello se cuenta en cada momento con la tecnología disponible y con la posibilidad de generar, de forma automática, los archivos de distribución desde el modelo inicial. Otro criterio aplicado ha sido la dependencia de “sistemas propietarios”, tanto en lo que se refiere a los sistemas operativos, como al hardware o equipo utilizado y los formatos de la información almacenada.

Todo esto se entenderá mejor en la descripción de las tareas que se están llevando a cabo actualmente.

2.2 Captura digital de fotografías.

La primera tarea es la creación de un banco de imágenes en la red, que permita la distribución de recursos, útiles tanto para los profesores como para los estudiantes. Desde 1997 se está trabajando con un escáner de diapositivas de alta resolución, que es capaz de obtener una información de calidad, a partir de imágenes fotográficas en formato positivo o negativo 24x36mm. La información se almacena en formatos normalizados - tiff sin compresión y sin pérdidas- mediante un soporte muy económico -CDROM-. A partir de este punto se inicia la segunda fase, la de distribución, proceso informatizado abierto que podrá repetirse en el futuro con otros protocolos mejorados; en el proceso se reduce el tamaño de las imágenes, se comprimen en un formato normalizado -jpg-, se introduce una firma digital y otra firma óptica -el escudo de la ETSAM- y con un tamaño aceptable -100/300KB- se ponen a disposición de los usuarios.

Para explicar mejor el proceso hay que contar algunos detalles técnicos: de cada fotografía se obtiene una imagen de unos 26MB con 3bytes por canal de color -unos 16 millones de colores-. Cada imagen se analiza y en el momento de la captura se intenta aumentar la ganancia - si es necesario- en las zonas con falta de luz o contraste, gracias a que la captura en el dispositivo se hace con 36bits, aunque sólo se utilizan 24bits, lo que significa mayor rango dinámico de captura, no modificando, con ello, la información original. Con película antigua o con poca luz puede interesar modificar la luminancia o el contraste, para obtener más detalle, con alteraciones importantes sobre el original, lo que hay que discutir con el autor de la fotografía. El punto débil, en este momento, es el de la visualización, pues los monitores de tubo o los cañones de imagen no alcanzan el brillo ni el espectro de color de una diapositiva proyectada con una lámpara halógena, aunque la calidad en la reproducción cromática sigue mejorando. Por otro lado, se requeriría un monitor e 4.050x2.700x3bytes para resolver esa imagen. Bueno, eso quiere decir que hasta que se trabaje con esos monitores no nos habremos quedado cortos en el tamaño de archivo y que sigue siendo interesante tener la información almacenada con esa calidad. Lo normal, ahora, es que en un monitor medio se pueda ver sólo 1/14 ó 1/7 de toda esa información; claro que de este modo se puede ampliar y recorrer una parte de la imagen y seguir teniendo nitidez; pero para poder hacer uso de la imagen de forma rápida en intranet o en Internet, es conveniente reducirla en tamaño a la par que se comprime.

El camino que siguen las imágenes desde su captura es el siguiente: tanto las diapositivas como los negativos de formato medio (6x6) son “escaneadas” en máquinas con Windows NT. El siguiente paso, en bloques grandes de imágenes, es el tratamiento de todas ellas mediante una macro de Photoshop, que les aplica un filtro de enfoque, un ajuste automático de niveles, una marca de agua, y se guarda una copia en formato tiff y otra reducida en formato jpg. De esta manera, se obtiene un original en tiff a alta resolución y una copia en jpg, con un tamaño que oscila entre los 100 y 300KB, más apto para su distribución por Internet (al menos en los tiempos que corren).

A partir de aquí, todo el tratamiento de imágenes se hace con Linux. Los originales en tiff se guardan en CDROM y las imágenes jpg se pasan a una máquina Linux, bien a través de samba, bien a través de ftp. Una vez allí se procesan con una serie de shell scrips escritos en bash. El primero de estos scripts coloca el sello de la ETSAM en la esquina inferior derecha de cada imagen, siempre a la misma distancia del borde. Esto, que es una operación trivial, fue del todo imposible hacerla con Photoshop, pues carece de herramientas para colocar una imagen sobre otra en una determinada posición. Sin embargo, con un breve script que llama a identify y a combine, ambos parte del paquete imagemagik se resuelve de manera óptima. Posteriormente, otro par de scripts crean una serie de páginas web, dividiendo cada directorio que contiene imágenes y generando páginas web con índices sencillos para que se puedan ver con comodidad. Actualmente, las imágenes se muestran en bruto, sin más catalogación que la división en subdirectorios, ya que no está disponible el sistema de catalogación y consultad el que se hablará después. Estas imágenes se cuelgan automáticamente del servidor del proyecto.

Se ha considerado la importancia que tienen los derechos de autor, por lo que la persona o grupo que aporta los originales debe realizar una cesión de derechos de la información digital a favor de la ETSAM, que reconoce la autoría de la persona que cede su material y se compromete a los términos de difusión que ambos acuerden. A través de la información digital queda constancia del autor o persona que cede la fotografía mediante la base de datos asociada. En la cesión de derechos consta la renuncia a la explotación económica del contenido. En este momento se han digitalizado unas 15.000 fotografías, y se están introduciendo las palabras clave para su indexación en la base de datos. Con la dedicación de 3 personas se puede alcanzar una tasa de captura mantenida de unas 3 ó 4.000 fotos al mes.

El contenido del fondo de imágenes es cualquier objeto de interés arquitectónico: edificios, detalles constructivos o de ejecución, diseño de interiores, entorno urbano y diseño de la ciudad, patrimonio histórico..., se trata de un entorno muy amplio que se nutre de las aportaciones individuales del colectivo de la ETSAM, empezando por las abundantes colecciones de diapositivas que se utilizan diariamente en las aulas y que ahora empiezan ya as ser proyectadas con cañones de vídeo mediante portátiles o usando la intranet de la Escuela; por otro lado interesa poder disponer de las revistas de arquitectura más demandadas por los estudiantes, con las que se han empezado a negociar acuerdos de distribución del contenido en nuestra base, con menor calidad que la de su reproducción tipográfica; finalmente se dispone del legado e arquitectos de prestigio que han comprometido el préstamo de sus colecciones en los términos antes descritos y que tienen un gran valor en el conocimiento de su arquitectura y la de sus coetáneos.

Se puede ver el contenido de los trabajos de captura realizados en su edición jpg en la dirección: http://www.aagrafa.aq.upm.es/

2.3 Fotografía de documentos y libros de la biblioteca de la ETSAM.

La Biblioteca de la ETSAM recibió su núcleo original de la Real Academia de Bellas Artes de San Fernando en 1844, posteriormente fue incrementándose con adquisiciones, trabajos propios y donaciones, especialmente con el legado de Juan C. Cebrián en 1907; a pesar de las graves pérdidas de la guerra, el fondo antiguo tiene más de 6.000 volúmenes; está constituido por libros impresos y manuscritos, existen muchas ediciones “príncipe” y destaca un grupo catalogado como “libros raros”; además del material bibliográfico hay planos, dibujos y fotografías. El conjunto es impresionante, pero dada su importancia sólo pueden ser hojeados bajo petición expresa y gran cuidado. Su valor no es sólo histórico y artístico, la información gráfica de los libros de construcción de madera o metal de principios de siglo es una herramienta útil en el aprendizaje y que se encuentra raramente en publicaciones posteriores.

El medio más indicado para su difusión es partir de fotografía en formato grande o medio; posteriormente y desde ese soporte se puede obtener una edición facsímil o digital. La fotografía digital directa ha sido desechada ya que hasta ahora, incluso los mejores y costosos equipos proporcionan menos definición que las sales de plata de la fotografía clásica, no aportando ninguna ventaja excepto la inmediatez. De una buena foto se pueden obtener muchas cosas, reproducciones en papel fotográfico, fotolitos para imprenta, imágenes digitales para redes informáticas, y además se conoce con seguridad cómo conservarla; de nuevo el criterio de archivar con la máxima resolución y distribuir a medida, tiene sentido. Sin embargo, actualmente los equipos semiprofesionales de escáner fotográfico tienen menos resolución por pulgada para formatos grandes que para formatos pequeños, y los equipos profesionales son muy costosos, por lo es aconsejable realizar bien el trabajo fotográfico y subordinar el digital al abaratamiento y mejora de aparatos que no tardarán en estar disponibles.

Si una imagen de 6 x 6 cm tiene 4,2 veces más superficie que una de 24 x 36 mm, con la misma resolución que los equipos que ahora existen para película de 35mm se debería poder obtener 4,2 veces más información, unos 100MB. Estev alor puede parecer excesivo para muchos de los componentes del equipo: el propio sistema operativo, el procesador, la memoria, el acceso a disco; sin embargo ese tamaño empieza a dejar de ser “inmanejable”, con los mayores rendimientos y abaratamientos generales de costes y es de suponer que esto levante la barrera en cuanto al valor absoluto de la información capturada ei mpulse la obtención masiva de datos a partir de originales de gran formato, como ya sucede con la aparición de escáneres planos -formato A3 con 2.000ppp-, al nivel doméstico-semiprofesional. En este momento utilizamos tres escáneres de Nikon para 35mm, uno de ScanMate para pelicula de gran formato de 5400ppp y, finalmente, uno especial para bibliotecas, de la casa Minolta con 600ppp, que permite capturar la información directamente del libro abierto con cámara volante restituyendo la planeidad del original.

La reproducción fotográfica se realiza con una cámara Hasselblad 6x6, y se cuenta con todo el equipo accesorio: pie de estudio, focos, fotómetro, filtros, tubos de extensión, colorímetro..., se utiliza película de grano muy fino, 25 ASA, y en blanco y negro siempre que es posible, y de 64 ASA cuando se trata de reproducir en color.

Otro trabajo de interés es realizar capturas de los índices de las revistas de arquitectura y de los textos completos de los libros más importantes, quel uego se transforman mediante un OCR para permitir búsquedas de palabras en el texto.

Hasta ahora se han fotografiado cinco libros de Piranesi (“Opere Varie”, 1750, “Le Antichitá Romane”, 1756, “Della Magnificenza e D’Architettura De’Romani”, 1765, “Il Campo Marzio”, 1762 y “Diverse Maniere d’Adornare i Cammini”, 1769), la parte gráfica de “Traité Théorique et Practique de L’Art de Batir”, 1827 de Rondelet, dos libros de Luigi Canina (“L’Architettura Egiziana”, 1839 y “L’Antica cittá di Veii”, 1847) y “Histoire de L’Art par les monumens”, 1823 de Seroux. Se ha iniciado la captura de los 5 tomos de texto del Tratado de Rondelet, que por la calidad de su tipografía permiten vectorizar el texto mediante un programa de OCR y hasta ahora se ha realizado un 20% del trabajo.

En diciembre del año pasado la ETSAM editó un facsímil de la “Opera Varie” de Piranesi, a bajo costo, que fue reseñado por su calidad en el diario EL PAIS. BABELIA 25.3.2000.

Por otro lado, con los medios de este proyecto se ha realizado la edición del libro “Madrid 1979-1999, la transformación de la ciudad en veinte años de ayuntamientos democráticos”, editado por la Gerencia Municipal de Urbanismo del Ayuntamiento de Madrid, y el Catálogo de la exposición “La Poética de la Ciudad, Évora, la ciudad y el territorio”, editado por la Cámara Municipal de Évora, Portugal.

Se puede ver el contenido de los trabajos de captura de varios de estos libros, en su edición jpg en la

dirección: http://www.aagrafa.aq.upm.es/imagenes/fondo_antiguo_biblioteca/

2.4 Grabación, edición y distribución de vídeo en formato digital.

La captura de imagen con vídeo digital o analógico es una tarea actualmente asequible y que permite utilizar en la enseñanza las posibilidades de los medios visuales en toda su extensión: grabación de conferencias y clases magistrales, visitas a museos, edificios, o ciudades, recorriendo itinerarios de interés prefijados, filmación del proceso constructivo y de la fabricación de elementos, ensayos de laboratorio...

La edición de imágenes es posible con poco esfuerzo, lo que permite conseguir una presentación interesante para los fines docentes que se persigan y se puede orientar pedagógicamente la información con el grado de interactividadq ue interese.

La actual Videoteca de la ETSAM tiene unos 250 títulos en formato VHS; en el Gabinete de Vídeo se encuentran las cintas originales de las grabaciones de actos y conferencias, muchas en formato SVHS -con mucha más calidad-, algunas de las cuales no pudieron llegar a ser enviadas a la Videoteca. Con el nuevo equipo existente se está realizando una conversión a formato digital de forma relativamente sencilla.

Los formatos digitales se han desarrollado tanto últimamente, que permiten obtener a nivel doméstico una calidad incluso superior a la de algunos antiguos formatos profesionales. El soporte digital permite que se pueda tener fácilmente un respaldo en formato DV de los originales SVHS , lo que significa tener ulteriores copias sin pérdidas del material existente, además de la mayor calidad de todo lo que se ha grabado últimamente, fundamentalmente conferencias y actos, como los de “El Arquitecto enseña su obra” que todos los meses realiza el Colegio de Arquitectos en colaboración con nuestra Escuela. A corto plazo se pueden hacer copias en DV de las cintas originales existentes en SVHS, volver a editarlas -sin las pérdidas que tienen las montadas anteriormente- y tener un resultado final con mayor calidad-. Además, desde este MASTER en DV se pueden obtener las copias que se quieran para distribuir en VHS en la Videoteca o hacer proyecciones públicas en la ETSAM en DV o en SVHS, con calidad muy superior, utilizando los cañones de vídeo existentes. Los profesores tienen a su disposición la posibilidad de repasar con sus alumnos conferencias de arquitectos que pasaron por esta Escuela -algunos ya desaparecidos- y realizar debates públicos. A partir de finales de año empezaremos a lanzar copias en MPEG2 para su visión pública con magnetoscopios de coste bastante reducido.

A medio plazo se pueden instalar puestos de red para permitir la visión de las conferencias, que en este caso tendrían un tratamiento más complejo, para permitir, mediante la compresión de datos, un flujo continuo; no obstante la elección del formato DV permite las mejores expectativas de integración con el ordenador. Como pequeña muestra se pueden visitar las páginas de Internet en la ETSAM en las que desde hace tres años se han grabado en formato DV los concursos de rotura de pórticos del Dto. de Estructuras; la grabación se ha comprimido escogiendo el instante de la rotura y se ha colocado en la red en archivos menores de 1,4MB con resultados aceptables. Hay que considerar que el punto débil es que desde fuera de la UPM la velocidad de transferencia de la red no es suficiente para la transmisión de vídeo de calidad:

   http://www.aq.upm.es/ee/e2/torneo.html http://www.aq.upm.es/ee/e2/98/torneo.html

El formato DV ha sido aceptado en 1995 por las principales compañías: Sony, Panasonic, JVC, Philips, Toshiba… En USA ha crecido de forma extraordinaria, asegurándose como estándar. Ofrece 500 líneas de resolución con compresión intracuadro, lo que permite edición no lineal, sin pérdidas; en el sistema PAL utiliza un esquema de muestreo 4:2:0 y tiene una tasa fija de transferencia de 3MB/seg

El desarrollo del DVD y el formato MPEG2 de la televisión digital, están en la misma línea de desarrollo, lo que conducirá a un intercambio ágil de datos entre sistemas. Para la Escuela el futuro podría pasar por distribución desde DVD o por red digital de televisión.

En colaboración con el COAM se están registrando los actos organizados bajo el lema “El Arquitecto enseña su obra”, en los que hasta ahora han intervenido Fisac, Oiza, Corrales, Higueras y Miró, visitando obras seleccionadas de los mismos. La periodicidad es de una visita cada mes, por lo que a finales de año tendremos un núcleo importante de vídeos de gran interés. El montaje de estas visitas está en realización.

En la Biblioteca de la ETSAM se encuentran disponibles más de 200 cintas en formato VHS, y existen copias digitales, desde 1998, en formato DV.

2.5 Captura de documentación de gran formato, cartografía y Proyectos de Fin de Carrera.

Los originales en formatos grandes tienen problemas propios para su digitalización, si además se pretende vectorizar el resultado de la captura, ésta tiene que tener la mejor calidad posible.

Otro de los desarrollos en curso se basa en la adquisición de un escáner en formato A0, con 400ppp de resolución y color de 24bits, para hacer frente a la captura de documentación en soporte hoja, que pueda aceptar un escáner de rodillo: planos, dibujos, proyectos, cartografía, fotografía…, facilitando así su distribución, agilizando las tareas docentes y de investigación y preservando al mismo tiempo los originales.

El escáner de gran formato es un equipo versátil capaz de capturar incluso originales en estado delicado de conservación empleando carpetas protectoras especiales. Muestra su gran potencia con grandes formatos llegando a una calidad equiparable a la digitalización mediante fotografía inicial del original en formato 6x6 y posterior digitalización de la misma en escáner profesional de tambor (6.000 ppp ópticos) ganándose en eficacia (al ser un proceso más rápido y con menor intervención manual) y en mayor rigor de reproducción (al evitar posibles alteraciones en pasos intermedios). Por lo que para captura de originales de gran formato este equipo se hace más aconsejable. Para un original de ancho de 91cm un escáner de gran formato con resolución óptica de 400 ppp obtiene una imagen de 14.330 x L x 3 bytes (siendo L indeterminado ya que la longitud de área de escaneado no viene limitada por el equipo de captura). Para ese mismo original una vez fotografiado en formato 6x6 la captura en un escáner profesional de tambor con 6.000 ppp de resolución óptica nos facilitaría una imagen máxima de 14.173 x 14.173 x 3 bytes.

Mediante dicho equipo también se está realizando la captura de los proyectos de fin de carrera que están almacenados desde 1992 en espera de la devolución a sus propietarios. Para almacenar esa información se utiliza el formato CDROM por su rapidez y economía.

Otra aplicación a corto plazo es la entrega de trabajos de los estudiantes a sus profesores. Existe un grupo importante de estudiantes que ya trabaja con paquetes informáticos y que no necesitan digitalizar y vectorizar sus trabajos, pero para el resto esto puede ser una herramienta útil. Para el profesor tiene ventajas en cuanto a manejo de la información, anotaciones o correcciones públicas, y pocas desventajas, ya que la inmediatez de la visión en papel no tiene porqué desaparecer, al menos en algunas etapas del trabajo.

Se puede ver el contenido de los trabajos de captura de los proyectos de fin de carrera entregados en 1998

y 1999, en su versión jpg, en la dirección: http://www.aagrafa.aq.upm.es/imagenes/pfc/

3 Linux en todo esto.

Como habíamos dicho anteriormente, a lo largo del desarrollo del proyecto se ha contemplado separadamente la captura digital de la distribución del resultado final. Hasta ahora, hemos hablado de los principales trabajos de captura en los que se trabaja actualmente, pero es en la parte del procesado la de información dónde Linux se ha mostrado como una herramienta fundamental.

Todas las tareas descritas anteriormente son completamente dependientes de elementos de hardware para los que Linux hoy por hoy no ofrece el “soporte” necesario. Por ello, todos los equipos destinados a captura digital están equipados con sistemas operativos de Microsoft, principalmente Windows NT 4.0 Siendo simplistas, por lo único que se usan estos equipos es porque disponen de los controladores necesarios para los escáneres, en su mayoría equipos de gama profesional para los que desde Linux no funciona ninguna clase de controlador genérico.

Sin embargo, en la fase de tratamiento y distribución de la información, Linux no tiene rival, cubriendo desde el procesado de imágenes en grandes bloques, su almacenamiento y catalogación, y su distribución posterior a través de un servidor web. Pero veamos esto un poco más despacio.

3.1 Procesado de imágenes.

El camino que siguen las imágenes desde su captura es el siguiente: tanto las diapositivas como los negativos de formato medio (6x6) son “escaneadas” en máquinas con Windows NT. El siguiente paso, en bloques grandes de imágenes, es tratamiento de todas ellas mediante una macro de Photoshop, que les aplica un filtro de enfoque, un ajuste automático de niveles, una marca de agua, se guarda una copia en formato TIFF y otra reducida en formato jpg. De esta manera, se obtiene un original en TIFF a alta resolución y una copia en jpg, con un tamaño que oscila entre los 100 y 300KB, más apto para su distribución por internet (al menos en los tiempos que corren).

Todo al paso por estos filtros, se podría hacer actualmente utilizando software libre como GIMP (http://www.gimp.org), pero en el momento de comenzar a hacerlas el desarrollo de GIMP no era tan avanzado como ahora, y el sistema de macros de Photoshop, tanto entonces como ahora, es más sencillo y manejable que el de GIMP.

A partir de aquí, todo el tratamiento de imágenes se hace con Linux. Los originales en TIFF se guardan en CD-ROM y las imágenes jpg se pasan a una máquina Linux, bien a través de samba, bien a través de ftp.Una vez allí se procesan con una serie de shell scripts escritos en bash. El primero de estos scripts coloca el sello de la ETSAM en la esquina inferior derecha de cada imagen, siempre a la misma distancia del borde. Esto, que es una operación trivial, fue del todo imposible hacerla con Photoshop, pues carece de herramientas para colocar una imagen sobre otra en una determinada posición. Sin embargo, con un breve script que llama a identify y a combine, ambos parte del paquete imagemagick (gran paquete para el tratamiento de imágenes, por cierto) se resuelve de manera óptima.

Posteriormente, otro par de scripts crean una serie de paginas web, dividiendo cada directorio que contiene imágenes y generando páginas web con índices sencillos para que puedan ver con comodidad. Actualmente, las imágenes se muestran en bruto, sin más catalogación que la división en subdirectorios, pero se está trabajando en un sistema de catalogación y consulta del que hablaremos a continuación. Estas imágenes se cuelgan automáticamente del servidor del proyecto http://www.aagrafa.aq.upm.es

3.2 Distribución de la información. La base de datos.

Aunque lo anterior puede ser un buen ejemplo de como automatizar el procesado de grandes cantidades de información, la parte importante de Linux en el Proyecto Aagrafa es el soporte para la base de datos que cataloga toda la información. A final, la idea de todoe esto es hacer accesible todo lo que podamos del extenso fondo documental de la Escuela, tanto de la blblioteca como de los distintos profesores y Departamentos. De cara al usuario final, todo esto se presenta mediante un buscador en una página WEB. Evidentemente, el servidor es una máquina linux con Apache 1.3.9 (http://www.apache.org).

Actualmente, tenemos el trabajo dividido en dos líneas; el interfaz de consulta, vía páginas web, y el programa de catalogación de contenidos. Para el desarrollo de la aplicación de consulta, el modelo que hemos elegido es clásico en internet entre las aplicaciones que hacen consultas a bastes de datos: un interfaz web, que llama a CGI’s en perl, que resuelven la consulta y genera una página como resultado. Para lo segundo. estamos desarrollando una aplicación en java, pero vayamos por partes.

El motor de base de datos que empleamos es Postgres 6.5 (http://www.postgresql.org), sobre una Debian Potato. Este es un motor ampliamente conocido en el mundo del software libre, y aunque no es el más rápido, su seguidores son legión, por lo que no es difícil encontrar voluntarios que den “soporte” cuando surge alguna duda.

El diseño de la base de datos está basado en objetos o elementos arquitectónicos, a los cuales se les asignan propiedades, palabras claves que los identifican. Estas palabras, se organizan de un modo abstracto, como calificadores sueltos, a los que a su vez se califican con un “tipo de calificador”. De esta forma, cada elemento (objeto) arquitectónico puede tener asignadas n parejas de elementos calificador-tipo calificador. Así, se consigue una gran abstracción respecto de la clasificación de los contenidos, estado basada esta no en palabras clave, sino en relaciones.

Por otro lado, los objetos arquitectónicos pueden ser padres y/o hijos de otros objetos, definiendo relaciones jerárquicas que pueden ser incorporadas a las búsquedas.

En este contexto, la imágenes son de alguna manera “propiedades” de los objetos, y no al revés. Así, las búsquedas se hacen por parámetros que califican a los objetos como tales, no a las imágenes. Pongamos un ejemplo: un objeto puede ser la Catedral de Santiago de Compostela. Podría tener asociados calificadores como “piedra” o “románico”. Estos calificadores se relacionan con los objetos según un tipo de calificador; en el caso de “piedra” podría ser “tipología” o “material”. Con este esquema se puede discriminar en las búsquedas por el tipo de calificador. Si quisiéramos encontrar todos los objetos construidos en piedra, la búsqueda sería por el calificador “piedra”, y el tipo de calificador, “material”. Naturalmente, se puede buscar por varios calificadores simultáneamente, o discriminar por varios tipos de calificador, autores, fechas… Todo esto se vé claro en la figura 1. En la figura 2 se puede ver el diseño de toda la base. Como se ve, hay tres tablas principales (a nivel conpectual); la de objetos, la de imágenes y la de colecciones (de imágenes). Cada una de estas tablas se califica por un esquema de cuatro tablas como el descrito más arriba y mostrado en la figura 1.

Al hilo de todo esto, una de las novedades que se ha incluido en nuestro buscador es la posibilidad de hacer búsquedas con operadores lógicos anidados, con cualquier nivel de complejidad. Un ejemplo; se pueden hacer búsquedas del tipo (a|b) + (c|d), y cosas similares. Esto se hace con el módulo perl-byacc. Con esto, lo que se hace es definir el comportamiento de la gramática en formato yacc, y automáticamente se genera una código en perl que se incorpora los CGI’s de búsqueda. yacc es una generador de analizadores sintácticos, y genera el código necesario para analizar las condiciones lógicas de la búsqueda. Con el resultado que devuelve el analizador, se construye la consulta SQL que se envía a la base de datos.

En cuanto al lenguaje, como se comentó más arriba se ha elegido perl. perl es muy cómodo para este tipo de aplicaciones, pues el tratamiento de cadenas y expresiones regulares facilitan mucho la creación de filtros y sentencias SQL para consultas a la base de datos. Por otra parte, para perl existen infinidad de módulos para las más variopintas tareas. Un ejemplo es perl-byacc (bueno, realmente no es un módulo para perl como tal, sino una utilidad que genera código en perl a partir de una gramática yacc). Otra ventaja que tiene perl es la facilidad para crear clases al estilo de C++ (salvando las distancias). Además, al ser código interpretado, no necesita compilarse cada vez, lo que acelera enormemente el desarrollo. El ser interpretado, es quizá la mayor desventaja de perl respecto a otros lenguajes como C, ya que su ejecución es más lenta, pero módulos para apache como el mod_perl hacen que se reduzca al mínimo esta desventaja.

Para la conexión a la base de datos, se utiliza la combinación de módulos para perl DBD+DBI. DBI viene a ser como un API genérico de bases de datos. Este módulo (o clase) implementa una serie de métodos para la conexión a bases de datos SQL; La ventaja de usar este módulo, en lugar de librerías (módulos) para Postgres, es que si se respeta el estándar SQL, es fácil cambiar de base de datos reaprovechando todo el código. La conexión propiamente se hace a través del modulo DBD. Este módulo es específico para cada base de datos. Basta con cambiar este módulo para cambiar la base de datos. Hay módulos para casi todas las bases de datos conocidas de cierto peso; MySQL, Oracle, DB2…

Se puede acceder a una versión de trabajo del buscador en la dirección http://www.aagrafa.aq.upm.es/consulta.html La otra gran línea de trabajo es el programa de catalogación. Para facilitar la introducción de datos en la

base, definición de objetos, calificadores, etc… y no tener que vérnoslas directamente con intragables ristras de

Figura 1: Rama referente a la tabla de objetos

SQL, se decidió crear un programa con una interfaz de ventanas familiar al usuario. Para crearlo se escogió el lenguaje Java, dadas sus características de portabilidad entre plataformas, seguridad y facilidad de desarrollo. La comunicación con la base de datos se realizaría mediante JDBC.

En un principio se optó por crear una aplicación independiente, totalmente basada en Java2 (JDK 1.2) y Swing. En el momento en que se comenzó a programar, nos encontramos con el problema de la falta de herramientas RAD que soportasen Java2 en ese momento. Tras una intensiva búsqueda por la red, nos encontramos con una herramienta que lo soportase: NetBeans, programa totalmente escrito en Java2. Dicho programa, aunque comercial, poseía una licencia gratuita para uso personal y académico. Tras diseñar un primer prototipo del programa, se abandonó la herramienta por diversas razones. En primer lugar, una de las promesas de NetBeans era la de crear código Java puro, sin emplear clases propietarias que obligasen a incluirlas en la distribución del programa. No obstante, al crear una ventana el layout manager por omisión era uno particular de NetBeans que había de ser redistribuido, lo que no deja de resultar un poco molesto. Por otra parte, la concordancia entre código escrito y apariencia visual de la aplicación se lograba por el método de marcar, mediante comentarios especiales, partes del código que estaban vedadas a la modificación por parte del usuario, lo cual resulta todavía mas molesto, ya que limita la posibilidad de editar el código con cualquier otro programa que no resulte el propio NetBeans. Dado que en el momento en que estas pegas empezaban a resultar irritantes Borland lanzó al mercado la versión 3 del JBuilder, se optó por reescribir todo el código en JBuilder 3, aprovechando de paso para introducir una serie de mejoras en la estructura del programa, en otras palabras, reescribirlo desde cero para hacerlo bien, una de las ventajas de tener unos plazos de entrega realmente flexibles. De hecho, no estamos realmente seguros de tener plazos de entrega. (Aquí Carlos escribiría “Una de las ventajas de NO trabajar para Microsoft”).

Los motivos de escoger JBuilder 3 como herramienta de desarrollo son su capacidad de creación de código Java 100% puro (como Sun dice), ésta vez de verdad, la rapidez de su compilador y las herramientas de sincronización de código y representación visual, que no se basan en ningún tipo de marcadores propietarios, lo que da lugar a un código realmente limpio. De hecho, muchas veces se han hecho modificaciones al código con editores de texto normales y corrientes, y, salvo en una ocasión, JBuilder nunca ha tenido problemas en reconocer el código modificado.

La estructura interna del programa fue totalmente remodelada. En un principio existía una clase para la introducción de cada elemento en la base de datos (Objetos, Autores, Calificadores…). Dicha clase incor-Figura 2: Diagrama de la base de datos

9 poraba no solo el código visual y de interacción con el usuario, sino también el código para efectuar consultas SQL, inserción y modificación de datos, etc. Al reescribir el programa, se aboga por un planteamiento modular, tomando como base la arquitectura Modelo-Vista-Controlador (Model-View-Controller), según la cual el programa ha de subdividirse en tres partes interrelacionadas: El Modelo representa una conexión con los datos existentes en la base de datos, es el que almacena y se encarga de gestionar todas las consultas. Es una abstracción de la base de datos, que puede ser comprendida por el código Java. La Vista es el aspecto visual del programa: Se encarga de presentar al usuario los datos del Modelo, de forma razonablemente coherente. El Controlador recibe e interpreta las peticiones del usuario: Clicks del ratón, introducción de datos, etc., se las transmite al Modelo y actualiza la Vista. Como todos los excesos son malos, es práctica habitual unir la Vista y el Controlador en un mismo bloque. Así, el nuevo programa, bautizado pedantemente como AagrafaDBMS2 (DataBase Management System 2, ahí queda eso), al iniciarse establece una conexión con la base de datos y se encarga de llenar de contenido diversas clases que actúan como Modelos, existiendo un Modelo (una clase de Java) por cada tabla de datos de la base de datos. Dichos Modelos están definidos como estáticos, garantizando que únicamente existe una copia de cada uno, lo cual es necesario para mantener la integridad de los datos ante la posibilidad de que existan varios usuarios introduciendo datos simultáneamente ( parte que nunca llegó a programarse pero que fue tenida en cuenta al diseñar el programa). Las ventanas de introducción de datos enlazan con el Modelo, del que obtienen los datos, y le pasan las peticiones de introducción de datos del usuario. El Modelo introduce los datos en la base y realiza todos los enlaces entre tablas necesarios. A continuación actualiza todas las vistas que existan, ésto se efectúa mediante clases que extienden a java.util.Observable y que implementan java.util.Observer. De éste modo la sincronización entre los datos existentes y los presentados es perfecta.

Cuando todo iba viento en popa, un nuevo escollo surgió ante nosotros: El diseño de la base de datos tenía un ligero error que, en determinadas circunstancias muy particulares, podría provocar el almacenamiento erróneo de datos. Como en informática las circunstancias muy particulares se dan con una frecuencia pasmosa, se optó por rehacer la base de datos. Ésto afectó a la parte del código que lidia con el SQL, pero, aprovechando el alto en el camino, volvimos a plantearnos el diseño del programa.

Para que engañarnos: El problema con Java, aparte de la simpática política de Sun, es la necesidad de distribuir el JRE para que los programas funcionen. Además, en ese momento, el tema del JDK para Linux estaba bastante confuso (la mencionada simpática política). Toda la parte de búsqueda y consulta de datos se realizaba mediante Netscape Navigator, así que se pensó que sería una buena idea rehacer el programa de introducción de datos para que funcionase a base de applets desde Navigator, lo cual soluciona el problema de la redistribución de la mejor manera: Eliminándola. Esto planteó otro problema, ya que Navigator no soporta Java2, por lo que hay que andar con mucho cuidadito acerca de los métodos y clases a emplear… afortunadamente podemos usar el modelo de eventos del JDK 1.1. Eso sí, de componentes Swing ni hablar, así que nos vemos constreñidos al AWT. El hecho de basarlo todo en web plantea otros problemas, como la sincronización de datos o la persistencia de la información del usuario (login, password) al ir navegando por las distintas páginas, problemas que, como suele pasar en programación, acabaremos por resolver aunque no se sepa muy bien cómo. El desarrollo en applets ha comenzado hace relativamente poco, pero avanza a buen ritmo dada la facilidad de reaprovechar código genérico escrito con anterioridad.

4 Conclusiones.

Con este proyecto se demuestra que existen en el mundo Linux potentísimas herramientas libres para acometer proyectos de gran envergadura. De hecho, la parte más importante del proyecto, que es la creación del sistema de catalogación y consulta está basada enteramente en Linux. Se demuestra también que con Linux lo que hay que poner son recursos humanos a la hora de crear nuevos proyectos, sin necesidad de recurrir a caros sistemas propietarios. A todos nos hubiera gustado que la totalidad del proyecto se puediera acometer empleando herramientas libres, pero hoy por hoy esto es imposible. El hardware empleado en la captura de imágenes y videos es muy específico, de gama alta, y no existen acuetalmente controladores para este tipo de periféricos en Linux. De esta forma, en la fase de captura estamos completemente obligados a usar herramientas no libres.

Entendemos que estamos en una fase temprana del desarrollo del proyecto. Actualmente el diseño de la base y el trabajo de captura se centra sobre todo en la digitalización de imágenes. La idea es que al final se puedan distribuir todo tipo de contenidos. Lamentablemente, en Linux no existe todavía un sistema de distribución de vídeo de alta calidad, aunque también es verdad que no existen estándares definidos. Cuando se normalice la situación en cuanto a los sistemas de transmisión de imagen y sonido, esperamos que se pueda montar un servidor de este tipo de contenidos bajo Linux. Aunque existen algunos sistemas actualmente, como RealVideo, el hecho de que no sean un estándar, y además software propietario, nos ha disuadido por el momento de la investigación en ese campo (a nivel de distribución, no de captura).

Por otra parte, recientemente hemos firmado un acuerdo de colaboración con el Colegio Oficial de Arquitectos de Madrid (COAM) para acabar de desarrollar el proyecto e implantarlo en su sede para la catalogación del Registro de Edificios de Madrid. Esto para nosotros ha supuesto una especie de victoria moral, ya que se han descartado en favor nuestro otras soluciones propietarias, cerradas, para la catalogación como las que usan el Ayuntamiento o la Comunidad de Madrid. Con pequeñas modificaciones sobre el esquema actual, se podría usar nuestro desarrollo para catalogar todo tipo de fondos documentales, de patrimonio…

Otra de las ideas que tenemos para el futuro, es la distribución del sistema a otras universidades, de forma que mediante un único interfaz se puedieran consultar múltiples fondos. Organizado así, cada universidad spodría digitalizar sus fondos docuementales, y calaogarlos según nuestro esquema. De hecho, en acuerdo con el COAM establece la compartición de los respectivos fondos documentales, de forma que, aunque se “administren” de forma separada, se verán como una sola base.

Desde luego este es un proyecto ambicioso, pero de gran importancia en la enseñanza e investigación de arquitectura cuando todo funcione (sólo Dios sabe cuando).

5 Agradecimientos.

No podemos dejar de mencionar a Jaime Cervera, catedrático en el Departamento de Estructuras de Edificación y Jefe de Estudios de la ETSAM. Ha sido uno de los principales impulsores del proyecto desde el el principio, gran defensor del soft libre y nuestro gurú particular sobre bases de datos y perl, y ha proporcionado grandes idas. De hecho, el esquema de la base de datos y el sistema de catalogación abstracta se deben a él en gran medida. Además, ha sido una de las personas que más ha peleado para conseguir fondos para el proyecto.