funvisis / sismocaracas Goto Github PK

El módulo decorator.py en el proyecto FUNVISIS usa el módulo ordereddict, el cual se encuentra en las versiones de 2.7 y 3+ de Python. En el caso de usar una versión anterior, ¿qué debería ser lo correcto? ¿Hacer el upgrade a python 2.7 o instalar ordereddict para Python 2.4-2.6?

Probar que los cambios realizados hasta hoy funcionen con los datos que se obtuvieron de producción.

Esta tarea solo implica que funcione en el entorno de desarrollo con los datos de producción en Postgres. Habrá otro issue para probarlo en un ambiente de prueba parecido al de producción.

Los cambios son la mayoría en el modelo. Hay que añadir algunos campos, y en la vista de la planilla hay algunos efectos deseados.

Estos cambios estarán listados por una serie de issues asociados al milestone v0.2. Por lo tanto, este issue en particular se cerrará cuando se verifique que funciona bien el sistema luego de aplicar todos los cambios.

Base de datos geográfica

Se propone que el manejo de los datos geográficos sea a través de una base de datos geográfica.

Restructuración de los modelos

Por otro lado, se propone la separación de los modelos relacionados con estructuras a los modelos que representan planillas.

• Concatenar " o paredes portantes" al texto "Discontinuidad de ejes de columnas".
• Añadir "Ausencia de muros en una dirección"
• Las opciones "Adosamiento losa contra losa" y "Adosamiento losa contra columna" serán ahora unos campos.
• "Separación entre edificios" ya no será condicional.

Es necesario concluir las funcionalidades relacionadas con el manejo de imágenes y albúnes.

Los campos mencionados están asociados a una lista de opciones de las cuales se elije una.

Hay unas opciones que tienen como textos caracteres especiales que más bien han confundido a los usuarios, así que se plantean estos nuevas listas:

Esquema de planta

• "H"
• "T"
• "U" ó "C"
• "L"
• Cajón
• Regular
• Esbeltez horizontal
• Ninguno

Esquema de elevación

• "T"
• Pirámide invertida
• Piramidal
• "U"
• "L"
• "▯"
• Esbeltez vertical
• Ninguno

La intención es picar el antiguo campo "Urb, Sector, Barrio" por dos campos:

• "Ubr. Barrio"
• "Sector"

En vez de conservar uno cambiándole el nombre y agregar uno nuevo, creo que lo correcto es simplemente agregar los dos campos nuevos y ocultar el viejo, ya que el viejo tiene datos que se levantaron alguna vez y debemos respetar la interpretación que se le dio a esos datos al estar asociados a ses campo.

Se propone la gestión de las galerías y fotografías asociadas a una inspección a través de una vista Django. El prototipo propuesto para esta vista se puede encontrar en master::doc/Bocetos.

Puesto que la versión actual del proyecto no posee respaldos de las imágenes, se propone crear un campo de tipo File para subir las fotos en formato .zip. Posteriormente, se debe hacer un script que migre los datos actuales a la nueva versión 1.0.

Seguir el issue #10. También volver a buscar aquel video del experto en bases de datos en el DjangoCon.

• Pórticos de acero con perfiles tubulares
• Sistemas cuyos elementos portantes sean muros de mampostería no confinada.

Probar que los cambios realizados funcionen en el ambiente de producción.

Depende de #7

Resumen

Este es un cambio grande. Implica agregar varios campos nuevos a la sección Tipo estructural y corregir algunos errores ortográficos.

Las modificaciones en el texto de los campos

* Pórticos diagonalizados -> Pórticos de acero diagonalizados.

Este cambio de texto modifica la interpretación, por eso se ocultará el campo anterior y se agregará uno nuevo.

Ya que el campo tenía el nombre "steel" (acero), simplemente se renombrará el texto ya que el acero fue contemplado en algún momento.

Véase el issue #10

• Sistemas cuyos elementos portantessean mampostería confinada -> Sistemas cuyos elementos portantes sean muros de mampostería confinada
• Sistemas cuyos elementos portantos sean mampostería no confinada > Sistemas cuyos elementos portantes sean muros de mampostería no confinada

En estos casos, hay unos errores ortográficos: **portantessean* y portantos. Esto se soluciona con cambiar la vista. Sin embargo, el cambio sugerido añade otra palabra: muros; lo que causa una reinterpretación de los campos y por lo tanto se procederá a realizar el cambio de la misma manera que el caso anterior y el issue #10: se ocultarán los campos viejos y se crearán unos nuevos, con la intención de respetar los datos viejos y su motivo.

Los campos nuevos

• Viviendas de bahareque de un piso
• Viviendas de construcción precaria (tierra, madera, zinc, etc).

Un campo numérico que signifique "número de pisos" asociado a cada uno de los siguientes:

• Sistemas cuyos elementos portantes sean muros de mampostería confinada.
• Sistemas cuyos elementos portantes sean muros de mampostería no confinada.
• Sistemas mixtos de pórticos y de mampostería de baja calidad de construcción.

Se propone la separación del modelo actual de inspecciones de estructuras en al menos dos modelos, uno para las estructuras y otro para las inspecciones que tengan una relación muchos a uno con las estructuras.