funvisis / microzn Goto Github PK

Los factores de la norma son:

1,0; 1,25; 1,5; 1,75; 2,0; 2,25; 2,5; 2,75; 3,0; 3,5; 4,0; 4,5; 5,0; 6,0.

Se mantienen los parámetros viejos. Tal vez no sea la misma gráfica, pero sí se mantiene la gráfica de los parámetros de la ventana previamente cerrada con la nueva microzona seleccionada.

Utilizar algún mecanismo de templates para quitar el HTML que está cableado en microzonelib.js.

1. Incluir siempre los puntos notables.

Primera rama: 2 puntos
Resto de las ramas: 4 puntos
Última rama: Delta de 0,2.

1. Colocar un enlace al documento de las microzonas.
2. Añadir elementos a la interfaz de usuario para que los usuarios puedan aprender a utilizar la aplicación.

Idea: Dibujar todos los gráficos posibles, y hacerlos visíbles o invisibles sobre el mismo gráfico, así no se modifica la escala con cada cáculo, ya que el cálculo se hace una vez.

Etiquetas

• Abscisas: Periodo (s).
• Ordenada: Aceleración (g).

El proyecto tiene actualmente en control de versiones una cantidad de archivos javascript de terceros.

Lo primero que se debe hacer es definir cuáles realmente hacen falta.

Colocar la documentación que por ahora está solo en el README en español y dejar la versión en inglés.

Contribuye a #3 y #4.

Esquema:

• package.js #Contiene la lista de requerimientos.
• README.rst # Docu
• LICENSE
• .gitignore # Ahora debería incluir las carpetas example/*/{css,js/lib}
• src/
  • js/
    • microzonelib.js
    • spectrum.js
    • spectrum_parameters.js
• examples/ # Contiene páginas WEB que utilizan la aplicación
  • applicación_1/
    • index.html # o cualquier nombre
    • js/
      • main.js # o app.js o el punto de entrada del atributo data-main que usa require.js. Aquí iría toda la configuración tanto de la aplicación como de require.js.
      • lib/ # Esta carpeta no estará en realidad en el contro del versiones. Aquí deberían residir los enlaces a las bibliotecas de terceros que se necesiten, incluyendo esta aplicación y require.js. Se puede hacer a mano, o automatizar la creación de estos enlaces con un script, con JAM, volojs o algo parecido.
    • package.json # lista de requerimientos. Debería ser simplemente microzonespectrumjs, spectrum y spectrum_parameters.
    • css/ # Punto de entrada de los CSS. Tanto de terceros como propios de la página. Momentáneamente se pasará el CSS a los ejemplos.
      • aplicación_2 [+]
      • ...
      • aplicación_n [+]

Dos conductas puede tener la aplicación:

1. Bajarse toda la base de datos de parámetros
2. Consultar la base de datos de parámetros para una microzona específica cada vez que se elija una microzona

Para que el código no se cambie en cada caso, el código consultará una estructura de datos suponiendo que ya está toda la base de datos bajada. Pero esta estructura en realidad será un Proxy que pudo haber bajado toda la base de datos o consultará otra fuente de datos cada vez que le consulten a ella.

Por ahora, es necesario hacer una de dos cosas:

1. modificar el archivo microzonelib.js para que apunte a la ruta completa del lugar donde esté instalado microzn.
2. Copiar el archivo div_content.html' en la carpetamarkupde la página que esté instalandomicrozn`.

Por supuesto, nada de esto es deseable. Hay que dejar el archivo en el componente y que funcione.

Para eliminar dependencias.

Específicamente el parámetro de la pendiente T*.

Ya sea en este repositorio o un enlace al código de alguna página que utilice esta aplicación.

Actualmente, la aplicación no permite la existencia de una capa que no tenga polígonos con los atributos para el cálculo de los espectros. Por esta razón, no se puede colocar una capa base.

Entonces, se desea tener la posibilidad de colocar una capa base. Por ahora, cablearla, luego, cablear diferentes posibilidades configurables. Por último, permitir cualquier capa base.

Luego de hacer el análisis de los paquetes javascript de terceros que sí hacen falta, se pueden determinar las relaciones de dependencia entre las mismas y el proyecto.

Contribuye a la conclución del issue #4. Seguir las ideas de Require.js.

A saber, el control para seleccionar las capas está en inglés. Traducirlo al español.

1. Implementar un proxy con API unificada para acceder los datos sin importar si es vía BD/WEB o JSON.
2. Implementar acceso vía JSON.

El primer punto es importante para mantener el funcionamiento actual de BD/WEB.

Esta propuesta plantea eliminar la ventana que aparece al hacer click sobre un polígono y cambiarlo por un espacio dedicado y siempre a la vista a los gráficos.

También hacer que la aplicación agarre bastante espacio y divida si es posible en dos la pantalla dependiendo del radio del aspecto. Si es horizontal, el lado izquierdo queda reservado para el mapa y el derecho para el gráfico junto con el formulario para los parámetros de diseño y ladera. Si es horizontal la parte de arriba estaría dedicada a los gráficos y las entradas y la da abajo para el mapa.

Dejar documentado cómo esperamos que el usuario de este proyecto (un programador) lo utilice.

Está relacionado con la página de ejemplo y también con el flujo de trabajo del desarrollo del módulo mismo: ¿Cómo es el ciclo de desarrollo de este proyecto?. Tal vez falte definir las pruebas.

Si se está utilizando OpenStreetMap, dar el reconocimiento en algún lugar. Igual con cualquier otra fuente.

Incluso, establecer una manera en la que el servicio de las capas a utilizar en la aplicación pueda ser utilizado para establecer en algún lugar el origen de las capas y el uso que el usuario les puede dar.

Ya que los servicios de parámetros actualmente generan un JSON con los parámetros de una microzona, y son tan pocas microzonas, los servicios de parámetros deberían ser consultados una sola vez para obtener todas las microzonas.

Para agilizar el proceso de desarrollo, mantendremos en este proyecto la base de datos de parámetros de microzonas como una solo archivos JSON. La forma en que se "sirva" ese JSON es independiente de este proyecto.

Debido a que obtenemos OpenLayers solo del archivo .js, perdimos las referencias a el arte que viene con la carpeta de distribución de OpenLayers. Hay que arreglar la referencia a OpenLayers en el Shim de Require.js.

Debido a que son finitas microzonas y finitos posibles parámetros, la cantidad de reportes posibles también es finita. Lo que sugiere la posibilidad de generarlos todos en tiempo de instalaición. Esto haría la aplicación más "responsiva" que generar el reporte cada vez que el usuario lo solicite.

Para esto, intentaré reutilizar el código que hace los cálculos desde node.js y combinando los parámetros (factor de reducción, grupo de edificación e inclinación de laderas) crearé todos los gráficos posibles.

Luego, utilizando una plantilla de LibreOffice con sus respectivos "campos", generaré todos los reportes. Esto pudiera hacerse con un script de shell que invoque a LibreOffice así:

$ libreoffice --headless --convert-to pdf plantilla.odt

Habrá que ver cómo pasarle parámetros, aunque creo que no se puede. La solución "a la" Office es generar a partir de una plantilla un documento. Luego es que ese documento se pudiera exportar a pdf.

Entonces, los parámetros serían para el proceso de generar a partir de una plantilla un documento.

Por último, toda esta característica pudiera ser opcional.

Es importante definir lo que se necesita para generar los reportes PDF como dependencias del proyecto. Pero, si decidimos que sea una característica opcional, entonces habrá que definir estas dependencias como opcionales también: y definir esto de de manera correcta, cosa que debo averiguar.

Debido a que la palabra "elástico" es relevante solamente cuando no hay factor de reducción, se sugiere quitarla.

Nota: Una mejora más económica para aproximarse a esta funcionalidad sería mostrar la coordenada del cursor.

Docuentar y poner en uso una metodología para trabajar de manera más limpia con plugins de Jquery y el mecanismo de Require.js.

La idea principal es agrupar Jquery con los plugins que se le quieran añadir en un módulo que pueda ser "requerido" vía Require.js.

1. Número de puntos
2. Máxmo período.
3. Intervalo.

Luego de tener claro qué bibliotecas se necesitan y cuáles son sus relaciones de interdependencia, entonces se debe establecer y dejar documentada la estructura del árbol de archivos de este proyecto.

El factor de importancia es una función de T que amplifica el espectro elástico por entre 1,14 y 1,70 o no lo amplifica en algunos casos.

Para implementar el factor de importancia, se necesita determinar un parámetro denominado Grupo que puede valer: A, B1 o B2. En el caso de B2, no se amplifica (es decir, el factor vale 1). B2 = (1 + A)/2. A depende de la Macrozona a la que pertenezca la el polígono elegido.

Para determinar la Macrozona del polígono elegido, trabajaremos por ahora analizando el nombre de dicha microzona con la siguiente regla:

1. Si empieza en R: obtener el siguiente dígito D. Si no empieza en R: asignar a D el valor 7.
2. Determinar la macrozona a partir de la siguiete tabla, en función de D:

D -> Macrozona
1 -> Sur
2 -> Centro-Sur
3 -> Centro Norte
7 -> Norte

Entonces, la función del factor de importancia F(T) =

• 1,28 * e^0,06T <= 1,5 si la Macrozona es Sur
• 1,30 * e^0,06T <= 1,6 si la Macrozona es Centro-Sur o Centro-Norte
• 1,35 * e^0,06T <= 1,7 si la Macrozona es Norte

básicamente construir una versión con las herramientas que OpenLayers trae en el directorio build y a su vez mantener juntos el script OpeLayers.js y las carpetas img y theme. Esto lo logro con enlaces simbólicos.

1. Mostrar la coordenada del puntero al moverse por el mapa.
2. Agregar una entrada de texto para que los usuarios puedan introducir las coordenadas.
   • Opcional: Agregar entonces un control que permita establecer en que Sistema de Coordenadas se está trabajando.
3. Opcional: Habilitar un Geocoder para Venezuela.

Microzonas: 2-1, 2-2, 3-1 y 3-2
Grupo: A
Factor de reducción: 1