Inicio >
Historias > ZoomEpi ataca de nuevo
ZoomEpi ataca de nuevo
Bueeeeno. Parece que en parte gracias a que ahora entiendo mejor el problema, a que tengo un nuevo cacharrito, a que tengo con quién comentar estas cosas, y - no sé - a que ahora lo veo más posible que nunca ... el caso es que parezco dispuesto a darle un nuevo empujón al ZoomEpi.
La idea está cada vez más clara en mi mente (y en mis dibujitos): déjame los datos de las epidemias en algún lugar accesible, y en un formato que yo pueda entender, y yo me encargo de dibujar esos datos en forma de tablas, gráficos y mapas, para que tú puedas entender qué te están
ocultando los datos. ¿Hay epidemia aquí y no allí? ¿Dónde es más intensa? ¿Afecta más a los ancianos o a los niños?
El nuevo "cacharrito" es el
vimoutliner. Se trata de un editor de esquemas basado en el conocido editor de textos
vim (libre y multiplataforma, como a mí me gustan los programas). Sobre el vim,
Steve Litt desarrolló un conjunto de scripts que luego han convertido en un "plug-in", para poder editar esquemas. El vimoutliner permite tener niveles (capítulos, subcapítulos, etc), colapsarlos o expandirlos, etc. A mí me gustan
desde hace tiempo los editores de esquemas. Este en particular tiene una lista de usuarios activa, y el amigo Heimy, de [Gulic http://www.gulic.org}], ha desarrollado un script en Python para pasar los esquemas a páginas html.
Así que yo tan contento. En particular, me he puesto a crear un "esquema" con mi renovada comprensión de los ficheros de datos (tablas principales y secundarias), de las opciones del menú, de los programas que hay detrás, y de los módulos "abstractos" necesarios para esos programas. Ya tengo claro que habrá un fichero de configuración para que el programa sepa qué directorios usar; así podrá haber un conjunto de directorios para los datos reales y otro conjunto de directorios para los datos ficticios - para distribuir sólo el segundo conjunto, claro. A esto es a lo que me refiero con mi nueva comprensión del problema: he decidido que una cosa es grabar los datos (en un único sitio o en varias localizaciones, y con uno o varios programas de grabación de datos), y otra cosa separada es hacer el procesamiento de esos datos para producir los resultados visibles.
El lenguaje que vamos a usar es el
python. Por lo que he leído el python es, a mis humildes efectos, igual de potente que el otro candidato (y no es que yo sepa como para comparar en profundidad): el
perl. Quiero decir: los dos son sobradamente potentes, y multiplataforma, y libres. Así que lo que más me importa es que sea legible (y
escribible) para mí. Seguro que es una cuestión muy personal, pero a mí me gusta más python que perl.
Usaré algunas cosas que ya tengo desarrolladas, claro. Yo ya había escrito un módulo en python para leer los ficheros .rec del
epiinfo, y para hacer las operaciones básicas:
read, select, freq, tables, sumfreq y sumtables. También puedo leer los ficheros .bnd del
epimap y dibujar polígonos coloreados. Sólo falta "todo lo demás".
Si soy capaz de crear y modificar el ZoomEpi, creo que podré producir las "salidas" (gráficos, mapas, etc) necesarias. Nuestra intención inicial es producir páginas html para un usuario individual o para una intranet (en la que varios usuarios ven los resultados para ver qué pasa con cada enfermedad o cada nivel de agregación geográfica, por grupos de edad, etc). Pero idealmente podríamos producir además ficheros en formato PDF (muy personalizados de forma que cada notificador vea la situación general y lo que pasa en su entorno o en su consultorio), o textos cortos para enviarlos como mensajes cortos a teléfonos móviles, o lo que se nos ocurra.
¿Qué va a pasar ahora? De momento habíamos llegado a la versión 0.4, y ahora creo que voy a poder llegar a la versión 1.0 en pocos días (o mejor en pocas semanas): un cambio sustancial en organización, legibilidad y funcionalidad. En ese momento lo liberaremos y, con un poco de suerte, lo pondremos en
el repositorio de unos amigos para poder tener listas de correo, cvs, área de descarga, y todas esas cosas bonitas que hacen que un proyecto hecho con "software libre" pueda respirar a sus anchas.
Personalmente, no soy informático, así que no me vendrá mal contar con un "director informático" con el que no me lleve demasiado mal, y que pueda complementar mi posible papel como "director sanitario".
En cualquier caso, una vez que esté liberada la versión 1.0 (o alguna anterior), veré dónde lo hago público de forma que los usuarios potenciales puedan verlo, evaluarlo, y tal vez usarlo y extenderlo. Una de las extensiones más claras es que sea capaz de leer ficheros de datos distintos a los que yo conozco. Si surge el interés, seguramente los gurús del lenguaje python podrán acelerar las rutinas, encontrar estructuras de datos más elegantes, y hasta desarrollar un lenguaje "natural" para pedir informes según la necesidad del momento. Mi prioridad es que nos sea útil en el trabajo diario, pero me alegraré mucho más si además es útil a otros, y aún más si algunos otros lo mejoran.
Otra posibilidad es que alguien nos señale otro programa, ya existente pero por el momento desconocido para mí, que haga "lo mismo y más". Tiene que ser libre, multiplataforma y extensible. A mí me encanta ver los mapas de la red de médicos centinelas de Francia; pero eso no es utilizable para mí. Hay cosas realmente sofisticadas en cuanto a
Sistemas de Información Geográfica. Pero nada específico o fácilmente adaptable a "lo nuestro", al menos que yo haya visto - y si alguien lo conoce supongo que ya me enteraré. En ese caso, seguramente abandonaría este proyecto y me pasaría al otro - o impulsaría este para "competir" si hay motivos objetivos o subjetivos suficientes. Con el software libre, el que es libre es uno mismo, ¿no?
2003-11-05 | 0 Comentarios
Referencias (TrackBacks)
URL de trackback de esta historia http://copensalud.blogalia.com//trackbacks/12696
Comentarios
portada | subir
