UNIVERSIDAD NACIONAL DE INGENIERA

Facultad de Electrotecnia Y Computacin

TRABAJO MONOGRAFICO PARA OPTAR AL TITULO DE

INGENIERO EN COMPUTACION.

Propuesta de implementacin de una plataforma geoinformtica para

la

digitacin,

validacin,

integracin

difusin

hidrometeorolgicos.

Elaborado por:
Br. Cristhian Xavier Mendieta Campos
Br. Glenda Suyen Morales Lpez
Br. Kevin Alberto Gaitn Meja

Tutor:
Dr. Federico Vladimir Gutirrez Corea

Managua, Nicaragua.
Noviembre, 2016

de

datos

RESUMEN
En la presente monografa se presenta la propuesta para la elaboracin de una
plataforma que facilite la recoleccin de datos hidrometeorolgicos en un
repositorio geoespacial y poder generar informacin de vital importancia para la
toma de decisiones en distintos mbitos.
El desarrollo de la plataforma implica el llevar a cabo una metodologa que en
primer lugar se encarga de cumplir la recoleccin de datos hidrometeorolgicos
de dos fuentes: Estaciones convencionales y estaciones telemtricas; Luego de
esto, cuando los datos son debidamente almacenados asegurando su espacio
en el tiempo (georreferenciados), se procede a su validacin en distintos niveles
que certifiquen la calidad de los mismos; Una vez tenemos los datos
debidamente validados, se habilita la interoperabilidad de los datos, basado en
la familia de estndares ISO 19100, facilitando el acceso a los mismos para
comenzar a la generacin de informacin desde distintos medios; Por lo cual, la
plataforma propone la generacin de informacin a travs de reportes en
distintos

formatos

(Tabulados,

Grficos,

Mapas),

as

como

reportes

especializados.
El proceso de desarrollo de la plataforma fue llevado a cabo basado por el
enfoque de desarrollo guiado por el dominio y procesos de desarrollo de
software gil, patrones y principios que tratan asegurar la calidad, usabilidad y
mantenibilidad del mismo.
Es importante destacar que el presente trabajo monogrfico sirve como gua
para estudiantes y profesionales interesados en introducirse a las ciencias
geoinformticas, dado que contiene el material necesario para conocer ciertos
fundamentos para trabajar con datos georeferenciados.
Este

trabajo

fue

desarrollado

en

la

direccin

general

de

sistemas

geoinformaticos, del instituto Nicaragense de Estudios Territoriales (INETER) y

la Universidad Nacional de Nicaragua (UNI), amabas de Managua, Nicaragua.

INDICE
I.

INTRODUCCIN........................................................................................1

II.

ANTECEDENTES......................................................................................4

III. JUSTIFICACIN........................................................................................7
IV. OBJETIVOS...............................................................................................9
4.1. Objetivo General...................................................................................9
4.2. Objetivos Especficos...........................................................................9
V.

MARCO TERICO...................................................................................11
5.1. Red de estaciones hidrometeorolgicas............................................11
5.2. Almacenamiento geoespacial de los datos........................................12
5.3. IDE (Infraestructura de Datos Espaciales).........................................14
5.4. Interoperabilidad estndar de datos geoespaciales..........................14
5.5. Validacin de Datos............................................................................23
5.6. Sistema de referencia espacial (SRS, Spatial Reference System)...24
5.7. Servidores para el intercambio de datos geoespaciales...................25
5.8. Clientes de Mapeo.............................................................................29
5.9. Proceso de desarrollo de software.....................................................29

VI. METODOLOGA.......................................................................................32
6.1. Base de datos.....................................................................................32
6.2. Migracin de los datos de las estaciones telemtricas automticas a una
base de datos geoespacial..........................................................................33
6.3. Metodologa de Desarrollo de Software.............................................34
6.4. Sistema de Recoleccin de Datos Hidrometeorolgicos de Estaciones
Convencionales............................................................................................39
6.5. Validacin automtica de los datos de estaciones hidrometeorolgicas.
43

6.6. Habilitacin de interoperabilidad basada en estndares OGC e ISO

19100...........................................................................................................46
6.7. Anlisis

desarrollo

del

sistema

de

presentacin

de

datos

hidrometeorolgicos.....................................................................................51
6.8. Desarrollo del sistema de reportes FM12..........................................51
6.9. Implementacin de clientes IDE.........................................................54
VII. RESULTADOS..........................................................................................57
7.1. Base de datos.....................................................................................57
7.2. Migracin de datos.............................................................................59
7.3. Resultados

del

Sistema

para

la

recoleccin

de

datos

hidrometeorolgicos de las estaciones convencionales.............................67

7.4. Resultados de la Validacin automtica de los datos de estaciones
hidrometeorolgicas.....................................................................................77
7.5. Resultados Habilitacin de interoperabilidad basada en estndares OGC
e ISO 19100.................................................................................................83
7.6. Resultados del anlisis y desarrollo del sistema de presentacin de
datos hidrometeorolgicos...........................................................................88
7.7. Resultado de sistema de reportes FM12...........................................97
7.8. Implementacin de clientes IDE estndares....................................100
VIII. CONLCUSIN........................................................................................104
IX. RECOMENDACIONES..........................................................................106
X.

BIBLIOGRAFIA.......................................................................................107

XI. ANEXOS.................................................................................................113
A.1. Anexos Base de Datos.....................................................................113
A.2. Anexos Migracin de Datos.............................................................122
A.3. Anexos de SIMET............................................................................123

A.4. Anexos Norma UNE.........................................................................154

A.5. Anexos Interoperabilidad..................................................................155
A.6. Anexos CAELUS..............................................................................158
A.7. Anexos Sistema de Reportes...........................................................180
A.8. Anexos Clientes IDE........................................................................186
A.9. Otro Anexos......................................................................................191

LISTADO DE TABLAS
Tabla 1. Comparacin de Servidores...................................................................27
Tabla 2. Periodos por Hora de las Observaciones...............................................41
Tabla 3. Tabla Comparativa de mtodos implementados en sistemas de gestin
de bases de datos espaciales..............................................................................58
Tabla 4 Requerimiento - Maquetacin responsiva para visin en tablets............68
Tabla 5 Requerimiento - Fiabilidad.......................................................................69
Tabla 6. Prueba de Usabilidad SIMET..................................................................73
Tabla 7 Requerimiento - Visualizacin espacio-temporal del comportamiento de
variables hidrometeorolgicas..............................................................................90
Tabla 8 Pruebas de usabilidad del sistema de presentacin de datos
hidrometeorolgicos.............................................................................................93
Tabla 9 Mens del sistema de presentacin de datos hidrometeorologicos........96
Tabla 10 Diccionario de datos de tabla observacin..........................................115
Tabla 11Diccionario de datos de tabla numericvalue.........................................116
Tabla 12 Diccionario de datos de tabla countvalue............................................116
Tabla 13 Diccionario de datos de tabla textvalue...............................................116
Tabla 14 Diccionario de datos de tabla featureofinterest....................................116
Tabla 15 Diccionario de datos de tabla validproceduretime...............................117
Tabla 16 Diccionario de datos de tabla observableproperty...............................118
Tabla 17 Diccionario de datos de tabla unit........................................................118
Tabla 18 Diccionario de datos de tabla offering..................................................118
Tabla 19 Diccionario de datos de tabla observationcontellation.........................119
Tabla 20 Diccionario de datos de tabla featureofinteresttype............................120
Tabla 21. Plantilla de requerimiento Funcional - Login......................................138
Tabla 22. Plantilla de requerimiento Funcional - Crear observacin..................138
Tabla 23. Plantilla de requerimiento Funcional - Almacenar Variables..............139
Tabla 24. Plantilla de requerimiento Funcional - Visor de Aeronutica y Sinptica
............................................................................................................................139
Tabla 25. Plantilla de requerimiento Funcional - Reportes Grficos..................140
Tabla 26. Plantilla de requerimiento No Funcional - Tiempo de Respuesta......141

Tabla 27. Plantilla de requerimiento No Funcional - Seguridad.........................141

Tabla 28. Plantilla de requerimiento No Funcional - Mantenibilidad..................142
Tabla 29. Plantilla de requerimiento No Funcional - Usabilidad.........................142
Tabla 30. Prueba de Accesibilidad - SIMET.......................................................143
Tabla 31. Prueba de Indexacin de Buscadores................................................144
Tabla 32. Prueba de Seguridad..........................................................................145
Tabla 33. Prueba de Rapidez de acceso............................................................147
Tabla 34 Requisito funcional para visualizar reportes tabulares con distintos
niveles de agregacin y clculos estadsticos....................................................163
Tabla 35 Requisito funcional - Visualizacin de series temporales de las
variables hidrometeorolgicas............................................................................163
Tabla 36 Requisito funcional para permitir la comparacin de series temporales
de las estaciones hidrometeorolgicas..............................................................164
Tabla 37 Requisito funcional para visualizacin geogrfica de las estaciones
hidrometeorolgicas...........................................................................................164
Tabla 38 Requisito funcional para exportar datos de cada sensor en distintos
formatos..............................................................................................................165
Tabla 39 Pruebas de concepto de usabilidad de Caelus...................................165
Tabla 40 Pruebas de conceptos de accesibilidad..............................................168
Tabla 41 Prueba de indexacin de buscadores de caelus.................................169
Tabla 42 Pruebas de seguridad de Caelus........................................................171
Tabla 43 Pruebas de rapidez de acceso de Caelus...........................................173

LISTADO DE IMGENES
Imagen

1. Estaciones

Hidrometeorolgicas. (A)

Estacin

meteorolgica

automtica telemtrica. (B) Estacin meteorolgica convencional......................12

Imagen 2. Captura de pantalla de PostgreSQL + Postgis...................................13
Imagen 3. Funcionamientos de los Geo-Servicios...............................................18
Imagen 4 Modelo Conceptual Observation & Mesurement.................................21
Imagen 5 Ejemplo de esquema O&M,..................................................................22
Imagen 6 Carencia de Integridad referencial.......................................................61
Imagen 7 Consultas compara la cantidad de datos en la bases de datos...........67
Imagen 8. Caso de uso de la funcionalidad del Sistema.....................................70
Imagen 9.Crear Observacin como observador..................................................76
Imagen 10. Catlogo de Observaciones del Observador....................................77
Imagen 11 Proceso de los datos de las estaciones meteorolgicas automticas
..............................................................................................................................78
Imagen 12 Histograma de registros no validos en la prueba de limites rigidos...80
Imagen 13 Sub regiones de referencia................................................................81
Imagen 14 Lmites flexibles basados en estadsticas..........................................82
Imagen 15 Histograma de datos no validos en prueba de lmites flexibles.........83
Imagen 16 Respuesta de servidor SOS a la peticin de una observacin..........84
Imagen 17. Resultado GetMap del WMS.............................................................85
Imagen 18. Resultado WFS GetFeature...........................................................87
Imagen 19. Resultado WFSDescribeFeatureType.............................................88
Imagen 20 Diagrama de caso de uso del sistema de presentacin de datos
hidrometeorolgicos.............................................................................................91
Imagen 21 Diagrama de paquetes.......................................................................92
Imagen 22 Pgina principal de Caelus.................................................................96
Imagen 23 Reportes tabulares.............................................................................97
Imagen 24 ndex de SIMET donde est el men Reportes FM12.......................98
Imagen 25 Catlogo de reportes..........................................................................98
Imagen 26. Reporte Codificado FM12..................................................................99
Imagen 27. Reporte Codificado FM12..................................................................99

Imagen 28. Vista a cliente del servicio SOS.......................................................100

Imagen 29. Vista grafica de una serie temporal en el cliente SOS....................101
Imagen 30. Resultado del Visor con Vista Satelital Google Maps.....................102
Imagen 31. Consulta a un punto en el mapa.....................................................103
Imagen 32 Versin de PostGIS utilizada............................................................113
Imagen 33 Tablas de la base de datos 52N SOS...............................................113
Imagen 34.Diagrama de base de datos SOS 2.0...............................................114
Imagen 35 Contenido de la tabla XC_SITES,....................................................120
Imagen 36 Contenido de tabla XC_SITESENSOR............................................121
Imagen 37 Contenido de tabla XC_DATA1........................................................121
Imagen 38 Imagen de servicio de migracin de datos.......................................122
Imagen 39. Diagrama de clases SIMET.............................................................123
Imagen 40. Caso de Uso - Administrar Estaciones............................................124
Imagen 41. Caso de Uso - Administrar Tipo Horarias........................................124
Imagen 42. Caso de Uso - Administrar Tipos de Nube......................................125
Imagen 43.Caso de Uso - Administrar Usuarios................................................125
Imagen 44. Caso de Uso - Administrar Variables...............................................126
Imagen 45. Caso de Uso - Administrar Tipos de Fenmenos............................126
Imagen 46. Caso de Uso - Administrar Tiempo Horarias...................................127
Imagen 47. Caso de Uso - Administrar Clasificacin de Fenmenos................127
Imagen 48. Caso de Uso - Clasificacin de Nubes............................................128
Imagen 49. Caso de Uso - Generar Reportes Grficos.....................................128
Imagen 50. Caso de Uso - Crear Observacin Observador...........................129
Imagen 51. Caso de Uso - Crear Observacin en Control de Calidad..............129
Imagen 52. Diagrama de Secuencia - Crear Observacin-Observador............130
Imagen 53. Diagrama de Secuencia - Crear Observacin-Control de Calidad. 130
Imagen 54. Diagrama de Secuencia - Administrar Estaciones..........................131
Imagen 55. Diagrama de Secuencia - Administrar Tipo Horaria........................131
Imagen 56. Diagrama de Secuencia - Administrar Tipos de Nube....................132
Imagen 57. Diagrama de Secuencia Administrar Variables............................132
Imagen 58. Diagrama de Secuencia - Administrar Tipos de Fenmeno............133

Imagen 59. Diagrama de Secuencia - Administrar Clasificacin de Fenmenos

............................................................................................................................134
Imagen 60. Diagrama de Secuencia - Administrar Tiempo Horaria...................134
Imagen 61. Diagrama de Secuencia - Generar Reporte Grafico.......................135
Imagen 62. Diagrama de Secuencia - Administrar Usuarios.............................136
Imagen 63. Diagrama de Paquetes SIMET........................................................137
Imagen 64. Prueba 1 de la W3C Validador Unificado.....................................149
Imagen 65. Prueba 2 de la W3C - Markup Validation........................................150
Imagen 66.Hoja de observacin.........................................................................151
Imagen 67. Reporte grafico por estacin, variable y rango de fechas...............152
Imagen 68.Reporte grafico por variable y por da de todas las estaciones.......153
Imagen 69 Mapa de las estaciones meteorolgicas automticas que se validaran
............................................................................................................................154
Imagen 70 Histograma de datos resultantes despus de haber aplicado
validacin............................................................................................................154
Imagen 71 Vista tabular de serie temporal en el cliente SOS............................155
Imagen 72 Formato de consulta al servicio SOS...............................................155
Imagen 73. Resultado de la operacin GetCapabilities WMS........................156
Imagen 74. Resultado operacin GetMap de la lluvia 72hrs WMS................156
Imagen 75. Resultado operacin GetCapabilities WFS..................................157
Imagen 76. Resultado de la operacin Transaction WFS...............................157
Imagen 77 Diagrama de clases de Caelus........................................................158
Imagen 78 caso de uso - Administracin de acceso a estaciones....................159
Imagen 79 Caso de uso - Administracin de estaciones...................................160
Imagen 8|0 Caso de uso Reportes..................................................................161
Imagen 81 Diagrama de secuencia de administracin de estaciones...............162
Imagen 82 Diagrama de secuencia de reportes................................................162
Imagen 83 Reportes grficos de Caelus............................................................175
Imagen 84 Reporte por estacin en Caelus.......................................................176
Imagen 85 Reporte geogrfico en Caelus..........................................................177
Imagen 86 Administracin de estaciones (Detalles)..........................................178

Imagen 87 Detalles de las estaciones................................................................179

Imagen 88. Caso de uso - Sistema de Reportes...............................................180
Imagen 89. Diagrama de Secuencia - Sistema de Reportes.............................180
Imagen 90. Reporte Metar por rango de fechas................................................181
Imagen 91. Reporte Metar por rango de fechas................................................181
Imagen 92. Reporte Diario de las estaciones convencionales..........................182
Imagen 93. Reporte Mensual del Viento (Direccin y Velocidad)......................182
Imagen 94. Reporte de los valores medios y extremos.....................................183
Imagen 95. Reporte de los valores medios y extremos.....................................183
Imagen 96. Reporte del Resumen Mensual de la Evaporacin y Temperatura del
suelo...................................................................................................................184
Imagen 97. Reporte del Resumen Mensual de la Evaporacin y Temperatura del
suelo...................................................................................................................184
Imagen 98. Reporte Registro de Evaporacin...................................................185
Imagen 99. Cdigo de visor web para consumo de geo-servicios....................186
Imagen 100. Cdigo para las capas de los mapas............................................187
Imagen 101. Consumo de Servicio WMS con JavaScript..................................188
Imagen 102. Cdigo de Panel de Informacin...................................................188
Imagen 103. Construyendo SLD........................................................................189
Imagen 104. SLD donde se asigna color #FF8C00 si es igual a 0....................189
Imagen 105. Resultado del Visor con Vista Terreno de Google Mapas.............190
Imagen 106. Resultado de Visor Vista de Open Street Map..............................190
Imagen 107. Crear un Espacio de trabajo en GeoServer..................................191
Imagen 108. Seleccionar espacio de trabajo Creado........................................191
Imagen 109. Editar espacio de trabajo...............................................................192
Imagen 110. Agregar nuevo almacn de datos..................................................192
Imagen 111. Agregar nuevo origen de datos......................................................193
Imagen 112. Editando el nuevo origen de datos................................................193
Imagen 113. Agregar una nueva capa................................................................194
Imagen 114. Agregar una nueva capa con el nuevo espacio de trabajo y almacn
de datos..............................................................................................................194

Imagen 115. Calcular los encuadres en base al SRS correspondiente.............195

Imagen 116. Capa editada para publicar............................................................195
Imagen 117. Aadir WMS a QGIS+....................................................................196
Imagen 118. Configurar la conexin con el servidor..........................................197
Imagen 119. Aadir capas..................................................................................198
Imagen 120. Capa WMS desde QGIS...............................................................199

I.

INTRODUCCIN

Los datos y el conocimiento hidrometeorolgicos en forma de la geoinformacin 1

perteneciente a un pas o regin son de vital importancia para la toma de
decisiones en materia econmica y social en general (Ehlers, 2008).
muchos aos la generacin de datos hidrometeorolgicos

Hace

en forma de

geoinformacin era un recurso privilegiado (Calle-Jimenez & Lujn-Mora, 2016),

pero ahora gracias al avance tecnolgico, el abaratamiento de los dispositivos
electrnicos como los Sistemas de Posicionamiento Global (GPS) que se logran
encontrar en la mayora de los telfono mvil inteligentes (Santitamnont, 2008) y
la madurez de los Sistemas de geoinformacin (SIG) la creacin de informacin
geoespacial se ha facilitado. Gracias a esto, se ve como una inversin que
ayuda a la administracin en la creacin de riqueza y conocimiento. La
accesibilidad, junto con la interoperabilidad 2 y la subsidiaridad3 son pilares que
ayudan a la evolucin optima del mundo de la geoinformacin (Torres Saura &
Valenzuela Daz-Moreno, 2010).
Con la plataforma geoinformtica propuesta, se pretende facilitar el anlisis de la
informacin hidrometeorolgica que tiene una importancia relevante en el
monitoreo de la amenaza, vulnerabilidad y el riesgo (GIS), 2013); ayudando a :
(i) determinar la posibilidad y la magnitud en la que un territorio puede ser
afectado por una amenaza natural peligrosa, (ii) minimizar las prdidas de vidas
con alerta temprana, la gestin integral de riesgo y vulnerabilidad; (iii) ayudar en
la toma de decisiones, (iv) reducir los efectos producidos por las variables
1 Geoinformacin es todos aquellos datos que pueden relacionarse con
localizaciones en la superficie de la tierra.
22 Interoperabilidad, es el intercambio entre procesos o datos de sistemas
heterogneos.
3 Subsidiaridad, la informacin es generada por quin la tiene ms cerca y mejor
la conoce.
1

hidrometeorolgicas en los planes del desarrollo econmico del pas, entre otras
(GIS), 2013), y todo desde una perspectiva geoespacial 4. Tambin la plataforma
propuesta en el presente documento, les servir a las instituciones relacionadas
al mbito, de la investigacin en ciencias de la tierra, de la atencin de
desastres, entre otras, como fuente para futuros estudios (eje: establecer niveles
de alerta en puntos crticos del pas, as como un instrumento que ayude a
prever con antelacin la sequa, inundaciones, prdidas humanas entre otras).
En INETER una de los bases fundamentales para la generacin de
geoinformacin de amenazas (anlisis, reportes, estudios y etc.) son las redes
de estaciones ubicadas en el territorio nacional. En el caso de la informacin
hidrometeorolgica,

los

datos

son

recolectados

desde

las

estaciones

convencionales, as como desde los sensores de las estaciones automticas

(telemtricas).
La gran cantidad de datos generados por las redes de estaciones
hidrometeorolgicas en INETER, que con el paso del tiempo ha venido
aumentado y que se prev que esto siga as, implica un gran esfuerzo de
recoleccin, depuracin e integracin de estos datos con los dems sistemas,
como pasos previos al anlisis y generacin de informacin de estudios. Los
datos de las estaciones convencionales primarias se recopilan mediante
documentos Word, Excel compartidos a travs la Red de rea Local (Local rea
Network, LAN). En la actualidad de forma paralela a este trabajo se desarrolla
una iniciativa para ayudar a automatizar el proceso de colecta de las
observaciones de las estaciones convencionales primarias, sin embargo, su
alcance no incluye a las estaciones convencionales secundarias (pluvimetro),
que son la mayora. El proceso de integrar datos provenientes de distintas
tecnologas de estaciones, implica un pre-proceso manual por parte de los
especialistas, que segn se conoce de forma general (no slo en Nicaragua)
puede llegar a representar ms del 70% del esfuerzo total, lo que provoca que
4 Geoespacial: Palabra que usa para indicar que los datos tienen una
componente geogrfica.
2

se dediquen a esta actividad ms tiempo que al proceso de anlisis y estudios

de las variables hidrometeorolgica.
El presente trabajo, propone auxiliar a los tcnicos del INETER en el proceso de
anlisis de la gran cantidad de datos generados por las estaciones, mediante la
implementacin de una plataforma que permita la recoleccin, depuracin,
integracin, difusin de los datos desde distintas perspectivas (tabulares,
grficos, geogrficas, y segn estndares para interoperabilidad de informacin
geoespacial). A su vez esta propuesta de plataforma consta de implementar
parte de las normas de la familia ISO 19100 y UNE 500540, lo que permitir
agilizar la integridad y la calidad de los datos recolectados a travs de
estndares internacionales establecidos. Con esto se pretende que los tcnicos
puedan disponer de un mayor tiempo en tareas de anlisis, generacin de
reportes y estudios, y hacerlo desde distintas aplicaciones gracias a la
interoperabilidad. Se espera que la implementacin de la plataforma aqu
propuesta tenga cierto impacto en la sociedad por permitir agilizar la generacin
de informacin para los tomadores de decisiones, lo cual a su vez ayuda en el
proceso de salvaguardar la vida y los bienes de la poblacin.

II.

ANTECEDENTES

En INETER los ltimos aos se han realizado algunos intentos de

automatizacin del registro y visualizacin de los datos hidrometeorolgicos, a
travs de sistemas informticos, sin embargo, el uso de estos no ha sido
completamente satisfactorio por los alcances los mismos, y no se han
contemplado estndares de interoperabilidad para la informacin geoespacial.
Por parte de las estaciones convencionales, uno de los intentos de
automatizacin fue brindado de parte de la Organizacin Meteorolgica Mundial
(OMM) con una aplicacin web llamada BUFR, la cual permite registrar las
variables hidrometeorolgicas de las estaciones convencionales primarias, otro
intento fue Meteo Tiempo Real, el cual se desarroll a medida por un
extranjero, sin embargo no se lleg a poner en produccin; as mismo para las
estaciones telemtricas se desarrollaron sistemas para la visualizacin de estos
datos, como el denominado REDHINA.
La manera en que operan en la actualidad las estaciones hidrometeorolgicas
(Convencionales y Telemtricas) y los intentos de automatizacin antes
mencionados se describirn a fondo a continuacin:

1 Estaciones convencionales primarias

Un conjunto de observadores meteorolgicos se encarga de la recoleccin de
los datos en las estaciones convencionales desde distintos artefactos anlogos y
los anota en hojas que luego se transcriben en documentos de Word y Excel
para ser compartidos ya sea por una red LAN o por correo electrnico. A partir
de estos datos se generan registros de las observaciones diarias, las cuales son
enviadas a distintos grupos de inters al menos una vez al da; cuando hay
situaciones especiales como cuando las lluvias son frecuentes y acumulan
grandes niveles de precipitacin los datos de inters son enviados la cantidad de
veces segn solicitados por los grupos interesados. De las observaciones
realizadas se generan reportes horarios mensuales, reportes codificados,
reportes de direccin del viento y reportes de las nubes por rumbo y por horas.
Luego de varias semanas los registros recolectados de las observaciones se
4

envan al Banco de Datos localizado en INETER para su integracin, en donde

igualmente llegan los datos de las estaciones convencionales secundarias.
2 Estaciones automticas telemtricas
Estas estaciones colectan automticamente la informacin de sus sensores y las
envan de forma codificada hacia INETER mediante telemetra. Una vez los
datos en la institucin, se proceden a decodificar y enviar a la Base de Datos
mediante el software XConnect, desarrollado por Sutron Corporation; este
sistema se encarga de proveer una interfaz para la generacin de reportes
tabulares, sin embargo, a l slo se puede conectar un usuario a la vez. El
sistema es privado y cerrado, con lo cual slo se pueden utilizar los reportes
tabulares que actualmente trae, y aunque presenta cierto grado de
personalizacin de reportes, estos muestran ciertas limitaciones (p. ej. El
formato de exportacin slo en formato .docx, y no permite la generacin de
nuevos reportes).
La base de datos de estaciones automticas, registra datos desde el ao 2001,
con el tiempo la cantidad de estaciones activas ha incrementado, actualmente,
hasta abril del 2016, existen 96 estaciones registradas, recibe un aproximado de
20,000 registros diarios por cada variable y posee un historial de estimado en 50
millones de registros correspondientes a los distintos sensores de las
estaciones.

3 Intentos previos de automatizacin digital

BUFR: Es una aplicacin web facilitada por la OMM, para el ingreso y envi
codificado (en cdigo BUFR) de las variables hidrometeorolgicas de estaciones
convencionales primarias. A pesar de que BUFR tiene varios aos de existir, se
aprecia que el uso de la su aplicacin web asociada; tambin, ha tenido poco
uso en los distintos pases miembros de la OMM, debido a que, segn los
operadores, esta presenta inconvenientes en usabilidad. La razones que se
indica en Nicaragua son: (i) Esta aplicacin posee vocabulario un poco distinto a
las utilizadas nacionalmente y que la manera de ingresar los datos en BUFR es
mediante mens desplegables, lo cual les hace utilizar ms de los minutos de
5

tiempo estipulado para enviar la informacin de las observaciones que se realiza

hora a hora (ii) se limita al ingreso y envo de la variables hidrometeorolgicas
sin permitir realizar un control de calidad de los datos una vez enviados (iii) no
cuenta con un mdulo de reportes donde se pueda visualizacin de los datos
registrados. Por las razones antes mencionadas la aplicacin web no est en
operacin en la actualidad.
Meteo Tiempo Real: En el ao 2009 fue desarrollado un sistema a medida para
INETER. La aplicacin era monousuario, su objetivo era recopilar la informacin
proveniente de las observaciones de las variables meteorolgicas en forma de
lista y las mostraba en un slo reporte. Solo se utiliz a nivel de pruebas dado
que el desarrollo de este no fue concluido por el consultor, en estas mismas se
apreci que la aplicacin careca de usabilidad y adecuacin funcional. Esos
inconvenientes evitaron que se pudiera interactuar gilmente con los datos, y
que los usuarios mostraran poca aceptacin a la aplicacin.
Red hidromtrica nacional (REDHINA): Esta fue una aplicacin web donde se
presentaban datos relacionados con alguna de las estaciones automticas y
algunos de sus sensores como son: precipitacin, lluvia y nivel de mar o rio. Esta
aplicacin tena la capacitad de generar grficos y mostrar los datos arrojados
por cada una de las estaciones, los cuales tambin habilitaban un control de
calidad visual. Sin embargo, careca de dinamismo por la forma de presentar los
datos, con grficos muy estticos y sin que se pudieran enlazar y superponer
datos de ms de una estacin en un solo grfico. La aplicacin presentaba en un
mapa de Google Earth la ubicacin de las estaciones desde donde se poda
acceder a sus datos, sin embargo, esto no deriv la generacin automtica de
mapas sobre los valores de las distintas variables, ni implic la implementacin
de estndares geogrficos de interoperabilidad que facilitase el intercambio de
datos dentro y/o fuera de la institucin.

III.

JUSTIFICACIN

En la actualidad existen distintos pasos para la obtencin informacin

hidrometeorolgica, provocando que el procesar los datos fuentes sea una tarea
laboriosa y compleja. Esto resta tiempo al personal especializado, el cual
pudieran utilizar para generar anlisis y estudios hidrometeorolgicos. Los pasos
inician con centralizar los datos, los mismos son provenientes distintos medios
como: (i) base de datos, (ii) hojas de clculos, (iii) documentos de texto, entre
otros; posterior deben de ser estructurados para su depuracin y validacin.
Considerando el volumen de datos generados por las redes hidrometeorolgicas
y su tendencia de aumento, estas actividades se vuelven cada vez ms
complejas de realizar sin la asistencia de procesos automatizados.
Adems, el hecho de compartir informacin con diferentes entidades (las que
salvaguardan a la poblacin, instituciones cientficas, entidades de colaboracin)
y habilitar estos datos para su consumo desde nuevos sistemas de informacin
(Chaglla, 2014), fortalecen la justificacin de crear una plataforma interoperable
y estandarizada. Estos estndares permitirn que los datos hidrometeorolgicos
puedan ser consumidos en herramientas GIS y que otros sistemas
especialmente desarrollados para accesos interoperables.
As mismo, esta plataforma contara con la implementacin de estndares de
validacin para datos meteorolgicos como la norma UNE 500540 [4] la cual
ayudara a mantener la integridad de los datos 5, con lo que se pretende agilizar
las labores del personal, dotndolos de ms tiempo para realizar anlisis,
adems de que brindara un medio para dar seguimiento al estado de los
sensores, ayudando a tomar decisiones importantes para el mantenimiento o
remplazo de los mismos.
Una vez implementada la plataforma, permitir la digitacin de las observaciones
meteorolgicas

de

estaciones

convencionales,

proporcionara

un

medio

5 Integridad de los datos : Correctitud y completitud de la informacin en

una base de datos
7

estructurado y eficiente para la captura de los datos, a su vez se podr visualizar

informacin integrada de las distintas redes hidrometeorolgicas en tiempo
cuasi-real, facilitando las labores como la creacin de reportes, anlisis
comparativos y estadsticos, a como se dispondrn de perspectivas visuales
como mapas y grficos en los que se podr observar el comportamiento de las
variables hidrometeorolgicas a nivel nacional.
Por ltimo y no menos relevante, la plataforma a desarrollarse implementar
estndares, patrones y buenas prcticas en el desarrollo de todas las
aplicaciones lo cual permitir que sea estable, escalable y mantenible (Oriente,
2013), dado que estar abierta a mejoras y extensiones para una mayor
robustez, lo que le dar flexibilidad para integrar nuevas caractersticas en el
futuro de ser requerido.

IV.
4.1.

OBJETIVOS
Objetivo General

Auxiliar

en

la

obtencin

de

datos

la

generacin

de

informacin

hidrometeorolgica que facilite la toma de decisiones y la generacin de estudios

brindando una visin integrada de los datos necesaria, mediante la propuesta de
la implementacin de una plataforma geoinformtica que comprende los
procesos de digitacin de datos, validacin, visualizacin e intercambio,
considerando las normas UNE-500406 y estndares de la familia ISO-191007.
4.2.

Objetivos Especficos
Conceptualizar el conjunto de pasos que sern automatizados y que se
siguen en INETER para el procesamiento de datos de las estaciones
hidrometeorolgicas; mediante la implementacin de la plataforma que
incluir la norma UNE-500540 y la familia de estndares OGC/ISO 19100
para la digitacin, validacin, difusin e intercambio de informacin de los
datos hidrometeorolgicos.

Reducir los pasos necesarios desde la colecta de las observaciones para

estaciones convencionales primarias hasta su registro estructurado en
una base de datos relacional.

Disear e implementar un mdulo web que permita capturar los datos de

las estaciones convencionales optimizado para Smartphone y Tablet.

Aprovechar las tecnologas geoespaciales para almacenar los datos de

las

estaciones

hidrometeorolgicas

mediante

bases

de

datos

geoespaciales que permita tratar estos datos de forma geogrfica nativa.

6 Directrices para la validacin de registros meteorolgicos procedentes de
redes de estaciones automticas.
7 Normas ISO de la informacin geogrfica.
9

Auxiliar la confiabilidad de los datos recolectados de las estaciones

hidrometeorolgicas mediante la propuesta de identificacin de datos
correctos y/o anmalos, implementando las directrices de la norma
UNE500540.

Auxiliar en el anlisis de los datos para la toma de decisiones mediante su

fcil acceso y adecuada estructuracin.

Integracin de los datos de las estaciones hidrometeorolgicas.

Implementar

patrones,

estndares

buenas

prcticas

de

la

Programacin Orientada a Objetos (POO) en la programacin de los

sistemas y subsistemas necesarios para llevar a cabo esta plataforma.

10

V.

MARCO TERICO

Considerando el rea de estudio de INETER y de la hidrometeorologa, toda la

informacin cientfica tcnica que la compone, est referido a una ubicacin
geoespacial, el marco terico aqu presentando est estrechamente relacionado
a los aspectos geoinformaticos y de normalizacin de informacin geoespacial
(normas UNE 500540 e ISO 19100).
5.1. Red de estaciones hidrometeorolgicas
La fuente fundamental de los datos proviene de dos tipos de estaciones, las
estaciones convencionales y de las estaciones automticas telemtricas, ambos
tipos de estaciones tienen variables o parmetros de observacin en comn,
entre las principales variables observadas se tiene: precipitacin, temperatura
del aire, presin atmosfrica, direccin de viento, velocidad de viento, niveles
(ejemplo: ros y mar), humedad relativa, punto de roci, entre otras (Direccion
General de Meteorologia INETER, 2012).
En la Imagen 1, se presenta una estacin automtica telemtrica (Imagen 1A), la
cual captura y enva los datos de manera independientes mediante dispositivos y
conversores electrnicos. Tambin se aprecia una estacin convencional
(Imagen 1B), en la cual que se aprecian instrumentos mecnicos, lo que implica
que un observador tenga que ir a tomar los valores que miden estos
instrumentos, y as registrarlos en la hoja de observacin pre-establecida.

11

Imagen 1. Estaciones Hidrometeorolgicas. (A) Estacin meteorolgica automtica telemtrica. (B)

Estacin meteorolgica convencional.
Fuente:http://www.directindustry.es/prod/schiltknecht-messtechnik/product-15070-1525291.html#productitem_374430

La OMM ha puesto a disposicin una aplicacin web para la digitacin y envo

de variables meteorolgicas desde estaciones convencionales primarias. Como
se dijo en los antecedentes, los distintos pases han presentado cierta
resistencia de la interfaz de usuario web para su uso. Sin embargo, el objetivo
de BUFR es codificar los datos en formato en binario de flujo continuo y as
lograr un intercambio eficiente de datos hidrometeorolgicos. Una vez que la
aplicacin recibe los datos, los almacena temporalmente, hasta ser enviados
automticamente a la OMM. (DOC/NOAA/NESDIS/NCDC > National Climatic
Data Center, 2015).
Las estaciones hidrometeorolgicas ubicadas en el pas, se encuentran
georreferenciadas, por lo tanto se conoce el origen geogrfico de los datos
observados, estos datos deben de ser almacenados de manera adecuada para
lograr el procesamiento ptimo (Vargas, 2012), por ello la necesidad de hacer
uso de un sistema de base de datos espacial que proporcione funcionalidades
para apoyar en el anlisis espacio temporal de los datos (Malinowski, 2014).
5.2. Almacenamiento geoespacial de los datos
El almacenamiento adecuado de los datos geogrficos es un factor clave para
lograr el procesamiento y compresin ptima de la informacin geogrfica
12

(Vargas, 2012). Las bases de datos (BD) son estructuras de informacin que
permiten organizar de manera estructurada y eficiente un conjunto de los datos.
Una base de datos geoespacial brinda soporte a objetos geogrficos,
permitiendo el almacenamiento, indexacin geogrfica, consulta geoespacial y
manipulacin de datos geogrficos.
Algunos de los sistema gestores de base de datos (SGBD) proporcionan
complementos u extensiones espaciales, las cuales pueden ser agregadas a las
base de datos, habilitndoles as tipos y funciones espaciales, tiles para
modelar objetos geo referenciados y la explotacin de los datos (Vargas, 2012).
Entre los SGBD con soporte de extensiones espaciales se puede mencionar:
Oracle + OracleSpatial, PostgreSQL +Postgis, MySQL + Extensions for Spatial
Data, SQL Server + SpatialTools. Un ejemplo, es el motor de base de datos
PostgreSQL + Postgis.
En la Imagen 2 se puede apreciar una consulta geoespacial en un visor, en la
consulta se est efectuando una interseccin de dos geometras geoespaciales
mediante la funcin espacial ST_TOUCHES.

Imagen 2. Captura de pantalla de PostgreSQL + Postgis.

Fuente: http://geotux.tuxfamily.org/index.php/geo-blogs/item/293-consola-sql-para-plugin-pgadmin-postgisviewer

13

Las bases de datos geoespaciales, son parte de unos de los componentes

principales de una infraestructura de datos espaciales (IDE) (Anguix, 2013). Las
IDE cumplen con una serie normas, estndares y especificaciones que regulan y
garantizan la interoperabilidad de la informacin geogrfica (Maganto, 2013).
5.3. IDE (Infraestructura de Datos Espaciales)
Las IDE son infraestructuras que permiten compartir, intercambiar, combinar,
analizar y acceder a los datos geogrficos de forma estndar e interoperable,
mediante un conjunto de recursos cartogrficos disponibles en la red, sobre la
que los datos mismos sern ms tiles al formar parte de un todo ms completo
(Lopez-Vasquez & Bernabe-Poveda, 2012).
Estndar significa simplemente que cumple unas reglas generales, que facilitan
la adopcin de soluciones genricas y la posibilidad de gestionar todos los
componentes

del

mismo

tipo

de

la

misma

manera

(Lopez-Vasquez,

Fundamentos de las infraestructura de datos espaciales (IDE), 2012), por lo

tanto esto hace que sea interoperable, ya que la interoperabilidad 8 es por
definicin es la capacidad de un sistema para funcionar con otros productos o
sistemas existentes o futuros sin restriccin de acceso o de implementacin.
5.4. Interoperabilidad estndar de datos geoespaciales
La plataforma propuesta en este trabajo ser completamente interoperable, esto
permitir el consumo de los datos por sistemas de informacin geogrfica (GIS),
estos son sistemas informticos para la captura, almacenamiento, control y la
visualizacin de datos relacionados con las posiciones en la superficie de la
tierra (Caryl-Sue, 2011). Esto se lograr mediante la implementacin de normas
de la familia ISO 19100; estas son una serie de normas para definir, describir y
8 La interoperabilidad es la capacidad que tiene un producto o un sistema, cuyas
interfaces son totalmente conocidas, para funcionar con otros productos o
sistemas existentes o futuros y eso sin restriccin de acceso o de
implementacin.
14

gestin de la informacin geografa. Establecen un conjunto estructurado de

estndares para la informacin relativa a objetos o fenmenos asociados a su
localizacin

geoespacial.

Esta

familia

de

normas

especfica

mtodos,

herramientas y servicios para la gestin de informacin geogrfica, incluido su

definicin, anlisis, acceso, presentacin, trasferencia, en formato digital (LopezVasquez & Bernabe-Poveda, 2012) .
Entre las normas de la familia ISO 19100 que destacan para el presente trabajo
se listan:
- Norma ISO 19107: Especifica los esquemas conceptuales en trminos de
estructuras de datos y modelos de objetos que se utilizan para describir las
caractersticas espaciales de las entidades geogrficas, y un conjunto de
operaciones estndares (ISO 19107,2003). En la prctica, describe un esquema
espacial conformado por un conjunto de primitivas geomtricas (puntos, lneas,
reas, superficies, solidos) y geogrficas (sistemas de coordenadas y de
referencia) para su uso en dos o tres dimensiones. (Lopez-Vasquez & BernabePoveda, 2012).
- Norma ISO 19115: Identifica los metadatos requeridos para describir datos,
incluyendo la calidad de los mismos. (Lopez-Vasquez & Bernabe-Poveda, 2012)
- Norma ISO 19119: Proporciona el marco de trabajo para quienes proyectan
crear aplicaciones que permitan a los distintos usuarios acceder y procesar
datos geogrficos procedentes de diversas fuentes, a travs de la identificacin
y definicin de la interfaz, as como la definicin de las relaciones de los modelos
de entornos abiertos9 (Open System Enviroment, OSE). (Lopez-Vasquez &
Bernabe-Poveda, 2012)
- Norma ISO 19136: Establece la sintaxis, los mecanismos y las convenciones
del esquema XML, lenguaje marcado que se utiliza para crear documentaos con
9 OSE: Estructura los tipos de servicios de un sistema de IT. Cada capa contiene
tanto los servicios generales de IT, como los servicios extendidos GIS para esa
capa.
15

informacin estructurada. En caso de poseer informacin geogrfica, se adopta

GML, tanto para la descripcin de los esquemas de aplicacin, como para el
transporte y el almacenamiento de la informacin geogrfica. (Lopez-Vasquez &
Bernabe-Poveda, 2012)
- Norma ISO 19156: Establece interfaces y protocolos que habilitaran un sensor
web a travs de aplicaciones y servicios sern capaces de acceder a sensores
de todo tipo y las observaciones generadas por los mismos (ISO Online
Browsing Plataform(OBP), 2011).
Las normas anteriormente mencionadas, fueron elaboradas por comit tcnico
(ISO/TC 211) responsable de las normas de la informacin geogrfica. ISO/TC
211 desarrolla la familia de normas internacionales 19100 para que usuarios y
productores de la informacin geogrfica puedan utilizar los datos geoespaciales
con mayor eficiencia (Lopez-Vasquez & Bernabe-Poveda, 2012). Este comit
trabaja las normas atendiendo a los fundamentos de las especificaciones de la
OGC (Open Geospatial Consortium). OGC es una organizacin internacional
formada por agencias gubernamentales, universidades, compaas y centros de
investigacin, y tiene como misin promover el uso de estndares y tecnologas
abiertas en el rea de sistemas y tecnologas de la informacin geogrfica y
afines (Lopez-Vasquez & Bernabe-Poveda, 2012).
Los datos provenientes sensores pueden ser afectados, por distintos factores
ambientales como descargas elctricas, interferencia en la trasmisin, objetos
que alteran la medicin de sensores (canoas en el rio), entre otros. Por ello
surge la necesidad crear un mecanismo que permita discriminar datos atpicos.
5.4.1. Lenguajes geoespaciales
5.4.1.1.

GML

Este es un sub-lenguaje de XML, utilizada poa describir objetos geogrficos

fsicos o abstractos, para su fcil intercambio en el internet.

Este lenguaje

permite incluir informacin sobre la localizacin y la forma de los objetos o datos

no espaciales, as describir caractersticas del objeto geogrfico.

16

Se pueden considerar lenguajes geoespaciales aquellos que, haciendo uso de

ordenadores para su procesamiento y comunicacin, presentan algn
componente geogrfico en datos o procedimientos.
5.4.2. Geoservicios
Podemos describir un servicio (Normas ISO, 2016) como una parte destacado
de la funcionalidad atribuida por una entidad a travs de una interfaz.
Aterrizndolo un poco ms a lo que concierne el mbito geomntico podemos
decir que un servicio web no es ms que una aplicacin que est ejecutndose
continuamente en un servidor, accesible desde Internet, que cuando recibe una
peticin en el formato adecuado, proporciona una respuesta acorde a la peticin.
Los geoservicios proveen un conjunto de servicios web que ofrecen una serie de
funcionalidades tiles para un grupo dirigido de usuarios. Y que estos conjuntos
de funcionalidades sean de fcil acceso desde navegador web a travs de
Internet, la cual permita principalmente la visualizacin, consulta, anlisis y
descarga de datos geogrficos. A travs de los geoservicios podemos
conceptualizar fundamentalmente la conceptualizacin de un sistema como
servicio y no los datos como ocurre en un software SIG. Un ejemplo de esto
puede ser Google Earth, seguido de otros Globos Virtuales que, con datos de
fecha desconocida, problemas de resolucin, errores de cientos de metros en
ocasiones y otros problemas, ha tenido un xito espectacular debido a que la
calidad del servicio es excelente.
El organismo encargado de elaborar los documentos tcnicos de cada uno de
los servicios web geoinformaticos es OGC. A continuacin, se describen las
caractersticas principales de los servicios implementados en este trabajo.

17

Imagen 3. Funcionamientos de los Geo-Servicios

Fuente: http://www.ideandalucia.es/portal/ides/software/servidores

5.4.2.1.

Servicio Web de mapas (WMS)

Su principal objetivo es visualizar la informacin geogrfica almacenada en los

servidores donde se encuentra almacenada la misma. Esta especificacin define
mapa como una representacin de la informacin geogrfica en forma de
imagen digital, adaptada para la visualizacin en una pantalla. El mapa es una
imagen de los datos almacenados en los servidores.
Este servicio se solicita a travs del navegador web del usuario que enva una
peticin en forma de URL. Esta peticin se recibe y procesa por el servidor WMS
que, como respuesta, devuelve al usuario una imagen en formato JPEG, GIF,
PNG, etc. La definicin de un formato u otro garantiza la transparencia de las
capas de informacin, permitiendo la combinacin de capas procedentes de
diferentes servicios WMS. Este servicio permite tambin opcionalmente
consultar los atributos alfanumricos de la informacin que se visualiza (OGC,
OpenGIS Web Map Server Implementation Specification, 2006)

18

Los mapas generados por los WMS pueden visualizarse a travs de un

navegador web (tambin llamados clientes ligeros), como Internet Explorer,
Mozilla Firefox, Opera, Google Chrome, etc., o a travs de algn software
(llamados clientes pesados) que deben instalarse en el ordenador del usuario.
En ambos tipos de clientes los visualizadores incluyen operaciones sencillas de
visualizacin como: activar y desactivar capas, cambiar el orden y transparencia
de las mismas, acercar y alejar, desplazarse sobre el mapa, vuelo panormico,
etc.
5.4.2.2.

Servicio Web de fenmenos, entidades u objetos (WFS)

Este servicio permite acceder y consultar los atributos de un objeto (feature)

geogrfico como un ro, una ciudad o un lago, representado en modo vectorial.
Un WFS permite no slo visualizar la informacin tal y como lo permite un WMS,
sino que tambin permite acceder a la informacin y descargarla.
Este servicio dispone de operaciones obligatorias y optativas. Entre las primeras
se encuentra la que permite descargar los datos geogrficos y entre las
segundas se encuentra la que permite manipular (editar, borrar, crear) la
informacin almacenada en la base de datos (slo a los actores autorizados)
(OGC, Open Geospatial, 2016)
Hay discrepancias dentro de la comunidad geogrfica en admitir el trmino
fenmeno como el equivalente espaol del concepto ingls feature, aplicado
a la informacin geogrfica. No es de extraar, por lo tanto, que en algunas
publicaciones se podr encontrar al WFS como servidor de entidades o
servidor de objetos.
5.4.2.3.

Servicio Web de coberturas (WCS)

Es el servicio anlogo al WFS, pero en lugar de trabajar con datos en formato

vectorial, lo hace con datos rasters. Permite no slo visualizar informacin raster,
como lo permite un WMS, sino adems permite consultar el valor del o los
atributos almacenados en cada pxel (OGC, OGC WCS 2.0 Interface StandardCore:, 2012).
19

5.4.3. SWE
El grupo de trabajo de la OGC SWE fue fundado en el ao 2003; este grupo se
encarga de desarrollar estndares que para la interoperabilidad web de datos de
sensores. Por lo tanto, SWE ha especificado una serie de normas que defienden
los formatos de datos y metadatos, as como las interfaces de servicio que
permiten el acceso interoperable sensores a travs de servicios web. Las
especificaciones SWE aprobados como estndares se pueden mencionar las
siguientes funcionalidades:

Descripcin de datos del sensor.

Descripcin de los metadatos del sensor
Acceso a las observaciones y metadatos del sensor
Tareas de sensores, para la adquisicin de datos.

Las funcionalidades SWE, se pueden clasificar en dos grupos: en primer lugar, el

modelo de informacin, en el que se incluyen los modelos y tipos de
codificacin; y, en segundo lugar, el modelo de interfaz que comprende las
diferentes especificaciones de interfaz web.
5.4.3.1.

Modelo de informacin de SWE

El modelo de informacin comprende un conjunto de estndares que definen los

modelos de datos, principalmente de codificacin de las observaciones o
mediciones de los sensores y metadatos de sensores. Entre los estndares se
pueden mencionar las especificaciones O&M (Observations & Measurements) y
el modelo de lenguaje de sensor SensorML (Sensor Model Language).
5.4.3.1.1.
El

estndar

para

O&M

observaciones

medidas

(O&M,

Observations

&

Measurements), que es estndar OGC e ISO 19156, se utiliza para definir un

esquema conceptual para representar observaciones, y para las funciones
relacionadas con la toma de muestras al hacer las observaciones.
El modelo bsico de O&M 2.0 que se muestra en la Imagen 4, define que una
observacin tiene relacin con un procedimiento (procedure) que representa el
proceso que se ha llevado a cabo para realizar la observacin, por ejemplo un
20

sensor fsico o una simulacin. La propiedad observada (observeb property) es

una descripcin de la propiedad que se observa, por ejemplo: temperatura de
aire o sanidad del agua. El resultado (result) de la observacin, puede ser de
cualquier tipo, que van desde valores, hasta coberturas de N dimensiones. La
caracterstica de inters (feature of interest), que es la representacin funcional
de una caracterstica del mundo real (por ejemplo, lago Xolotlan), ello asociado a
la propiedad que observa. La observacin proporciona un valor para esta
propiedad en un momento determinado (phenomenon time).

Imagen 4 Modelo Conceptual Observation & Mesurement

Fuente: Elaboracin propia.

Adems, el modelo conceptual de O&M, define el tiempo de validez de la

observacin (validTime) y el tiempo de resultado (resultTime), el tiempo de
resultado representa el momento en el que se produjo el resultado de la
observacin. El tiempo de validez es una propiedad que define el periodo
durante el que la observacin es utilizable, til en los casos de que prediccin,
en las que cambian los tiempos de validez.

21

En la Imagen 5, se muestra un ejemplo implementacin del esquema O&M, se

puede apreciar, que la notacin utilizada por la fuente, para definir los elementos
de la observacin son URL. El ejemplo define que la observacin fue efectuada
un punto de muestreo georreferenciado (samplingGeometry), que pertenece a
un rea de inters (feature of Interest), en este caso el golfo de Mxico
(GulfOfMexico), dicha observacin se realiza del sensor (procedure) de un
planeador (glider1), que observa el fenmeno (observableProperty), de
salubridad de agua de mar (Sea Water Salinity); obteniendo un resultado
(result).

Imagen 5 Ejemplo de esquema O&M,

Fuente:
http://schemas.opengis.net/sos/2.0/examples/_useCase_mobile_sensors/GetObservation_response.xml

5.4.3.1.2.

SensorML

Para la descripcin de metadatos del sensor, SWE define un modelo de leguaje

del sensor denominado SensorML(Sensor Markup Language), en el que se
especifica un modelo de codificacin y un XML(eXtensible Markup Language)
para la descripcin de todos los tipos de sensores relacionados con sus
procesos (Procedure).
El Lenguaje SensorML define que un sensor es un proceso que es capaz de
observar un fenmeno y retornar el valor observado, permitiendo una
22

descripcin detallada de un proceso que incluye una lista destallada de sus

entradas, salidas, parmetros y mtodos del proceso; Otros metadatos del
proceso podran ser su identificacin y clasificacin, as como la disponibilidad
de sus series temporales y su descripcin y disponibilidad espacial; por ello
SWE implementa SensorML como un formato para la descripcin de sus
procesos asociados.
5.4.3.2.

Modelo de interfaz SWE

En el modelo de interfaz SWE, se especifican normas de las interfaces de los

diferentes servicios web de sensor; entre ellas se define el servicio de
observaciones de sensor (SOS, Sensor Observation Service), creado para
ofrecer acceso a los datos provenientes de sensores, as como a los metadatos
de los sensores.
5.4.3.2.1.

SOS

El acceso estandarizado a las observaciones y metadatos del sensor se

proporciona por el servicio de observaciones de sensor (SOS, Sensor
Observation Service), el servicio acta como mediador entre un cliente y un
archivo de datos del sensor (proporcionado por el servidor)]; los protocolos de
comunicacin y formatos de datos de los sensores estn ocultas por la interfaz
normalizada del SOS.
Las operaciones del servidor SOS, se dividen en dos: (i) las operaciones de
ncleo, que son operaciones obligadas para la recuperacin de metadatos del
servicio y sus contenidos; y (ii) las operaciones de extensin, especificadas para
las operaciones transaccionales y de recuperacin de resultados de la
observacin como tal, sin especificar metadatos de observacin, aumentando la
escalabilidad y el rendimiento.
5.5. Validacin de Datos
Considerando que actualmente los datos se almacenan a como provienen de
sensores e instrumentos de las estaciones automticas telemtricas y
estaciones convencionales primarias, estos datos pueden ser afectados por
23

mltiples factores como: descargas elctricas, interferencia de trasmisin o fallos

humanos en el proceso de digitacin, el mantenimiento y la calibracin de
instrumentos o sensores, el procesamiento de los datos al convertir los datos de
los sensores, interferencia en trasmisin de datos, entre otros (AENOR, 2004).
Este trabajo se contemplan la implementacin de parte de la norma UNE
500540, la cual estable directrices mnimas acerca de la validacin de los datos
procedentes de datos en tiempo cuasi-real (como es el caso de las estaciones
automticas y convencionales primarias) que permitan no solo saber el grado de
validez de los datos, sino tambin las manipulaciones a las que han sido
sometidos (AENOR, 2004). Mediante esta norma se realizar la clasificacin de
los datos atpicos recolectados en las estaciones.
5.6. Sistema de referencia espacial (SRS, Spatial Reference System)
Los sistemas de referencia espacial (SRS) se utilizan para poder ubicar objetos
geogrficos en un mapa, para la realizacin de los visores que consuman los
servicios WMS y WFS, se necesita la referencia espacial para que los puntos del
servicio se ubiquen en el lugar correcto en el mapa, en este caso de estudio
Nicaragua.
Destacan los siguientes:

WGS (World Geodesic System)

NSRS (National Geodetic Survey)
EPSG(European Petroleum Survey Group)

Un SRS est determinado por:

Un datum (Que a su vez est determinado por un elipsoide)

Una proyeccin cartogrfica.
Parmetros adicionales como la ubicacin del eje Y (meridiano central) o

del eje X (paralelo central).

Cada SRS tiene tambin asociado una unidad de medida (metros,
grados, etc.)

24

El WGS84, permite localizar cualquier punto en la tierra (sin necesitar otro de

referencia) por medio de tres unidades, este hace sus clculos tomando la tierra
como un elipsoide.
El conjunto de cdigos EPSG (European Petroleum Survey Group) hacen
referencia a una gran cantidad de sistemas SRS y se usan como un estndar
para configurar bases de datos geogrficas y SIG. Algunos cdigos EPSG de
uso comn son:

4326. Del SRS WGS84 (coordenadas geogrficas, latitud y longitud). Es

usado por el sistema GPS.

3857. Del SRS WGS84/Pseudo Mercator, usado por los principales
servicios de mapas en Internet (Google Maps, OpenStreetMap, Bing
Maps y otros). Puede encontrarse con el cdigo alterno 900913
(CeReGeo, s.f.).

El EPSG: 4326 toma la tierra como un elipsoide mientras que el EPSG:900913

la toma como una esfera, esto afecta en los clculos donde el mapa se toma
como un plano.
Algunos servidores de aplicaciones de mapas en la web:

Google Earth: sistema de coordenadas geogrficas con el datum WGS84.

(EPSG: 4326)
Google Maps: sistema de coordenadas proyectadas que se basa en el

datum WGS84. (EPSG 3857)

Open Street Map: Los datos en la base de datos de se almacenan en una
GCS (Geographic Coordinate System) con grados y datum WGS84 de
unidades decimales. (EPSG: 4326)

5.7. Servidores para el intercambio de datos geoespaciales.

Los servidores de mapas permiten la interaccin con la informacin espacial
almacenada en servidores de datos espaciales accesibles va web. El usuario
accede a la informacin de manera que puede visualizarla, consultarla y, en
funcin de las caractersticas de los servidores y de los servicios prestados,
25

descargarla o realizar anlisis espaciales a travs de clientes tanto ligeros, como

aplicaciones web que permiten la consulta de estos servidores de mapas desde
el navegador o pesados, como aplicaciones SIG de escritorio con mdulos que
permiten la conexin a servidores de mapas (Junta de Andalucia, s.f.).
En las IDE, estos servidores de mapas deben ser interoperables por medio de
especificaciones estandarizadas; dichos estndares o especificaciones son
desarrollados por organizaciones internacionales cuyo fin es la estandarizacin
ya sea ISO u OGC, que son las encargadas del desarrollo de dichas estndares
(Instituto de Estadistica y Cartografia de Andaluca, n.d.).
Algunos servidores Open Source:

GeoServer

GeoServer es un servidor de cdigo abierto desarrollado en Java, lo que le hace

ser multiplataforma, que permite a los usuarios compartir y editar datos
geoespaciales. Diseado para la interoperabilidad, publica datos de cualquier
fuente de datos espaciales con estndares abiertos.
GeoServer lee una variedad de formatos de datos, incluyendo PostGIS, Oracle
Spatial, ArcSDE, DB2, MySQL, Shapefiles, GeoTIFF, GTOPO30, ECW, MrSID y
JPEG2000. A travs de protocolos estndares es capaz de generar KML, GML,
Shapefile, GeoRSS, PDF, GeoJSON, JPEG, GIF, SVG, PNG y otros. Adems, se
puede editar datos a travs de WFS transaccionales (WFS-T). GeoServer
incluye un cliente integrado OpenLayers capaz de visualizar datos para obtener
una vista previa.
Permite la publicacin eficiente de datos geoespaciales de Google Earth a travs
de la utilizacin de enlaces de red, utilizando KML.
GeoServer es la implementacin de referencia del Open Geospatial Consortium
(OGC) para las normas Web Feature Service (WFS) y Web Coverage Service
(WCS), adems est certificado como servidor de alto rendimiento para Web

26

Map Service (WMS). GeoServer es un componente bsico de la Web

Geoespacial.

MapServer

MapServer es una plataforma de cdigo abierto para la publicacin de datos

espaciales y aplicaciones de cartografa interactiva para la web, funciona en
todas las principales plataformas (Windows, Linux, Mac OS X).
Admite mltiples formatos de datos vectoriales (ESRI shapfiles, PostGIS, ESRI
ArcSDE, Oracle Spatial, MySQL y otros a travs de OGR) y Raster
(TIFF/GeoTIFF, EPPL7, y otros a travs de GDAL). Soporta ms de 1000
proyecciones diferentes al vuelo a travs de la libreria Proj.4.
Mapserver cumple con las siguientes especificaciones de OGC: WMS
(cliente/servidor), WFS no transaccional (cliente/servidor), WMC, WCS, Filter
Encoding, SLD, GML y SOS.

52North

52North es una comunidad de socios, con el objetivo de fomentar la innovacin

en el campo de la geoinformtica, mediante la organizacin de procesos de
desarrollo de software libre. Todas las contribuciones de software son de licencia
de cdigo abierto y libre.
52North ha desarrollado diversos softwares aplicados aplicando estndares
OGC, entre los softwares de inters se encuentra servicios de datos de sensores
web (SOS, Sensor Observation Services), servicios de reprocesamiento (WPS,
Web Processing Service), entre otros.
Tabla 1. Comparacin de Servidores

Nombre

WMS

WFS

WFS

WCS

MapServer

deegree

-T

27

WMT

TM

WPS

SO|

CSW

GeoServer

GeoNetwork

52North SOS
MapGuide

OpenSource
PyWPS
GeoWebCache

TileCache

52North WPS
MapProxy

PyCSW
QGIS Server

TileStache

Zoo Project
EOxServer

TileStream

Fuente: http://panorama-sig-libre.readthedocs.io/es/latest/servidores/

GeoServer es el servidor de mapas ms completo, a como se observa en la

Imagen 4, implementa todos los servicios OGC excepto SOS, en estudios se ha
demostrado que GeoServer ha obtenido los mejores resultados de rendimiento
en todas las pruebas del servicio WMS, maneja mejor que otros servidores los
grandes volmenes de datos adems organiza por capas los elementos a definir
para una mejor localizacin de los resultados (Nstor, 2015), sus extensiones al
estndar SLD, el soporte de estilos CSS, y su amigable interfaz lo convierten en
28

un servidor de mapas ampliamente utilizado en todo tipo de contextos (Daz ,

Arias de Reyna, & Sanz , s.f.).
Para el servicio SOS, que tambin ser trabajado en esta tesis, se escogi
52North, ya que su objetivo era cubrir la necesidad en GeoServer de un servidor
de teselas que permita pre generar y acelerar la cartografa servida por este
producto. Al igual que GeoServer, destaca por su cmoda interfaz de usuario,
capacidad para limitar en disco las caches, generacin y borrado de las mismas,
etc.
5.8. Clientes de Mapeo
Clientes de mapeo Web son piezas de software (aplicaciones, los espectadores,
las bibliotecas y los marcos, entre otros) que, o bien proporcionar o extienden un
componente de mapeo basado en web para ver e interactuar con los mapas de
fuentes remotas de Internet.
La OGC promueve el uso de estndares para servicios de mapas web, que han
ayudado a establecer un marco comn para el acceso, visualizacin y descarga
de datos espaciales en Internet (Web Map Service, Web Feature Service,
servicio de cobertura de la web). (Carrillo, 2012)
5.9.

29

5.10.

5.11.

Para las estaciones convencionales principales se contempla

la creacin de un sistema web, el que permita digitar los datos de

variables hidrometeorolgicas segn estndares establecidos por la
direccin de meteorolgica de Ineter. Los datos recolectados sern
almacenados en una base de datos georeferencida.
5.12.

Los datos de las estaciones telemtricas actualmente se alojan

en un almacn de datos. Debido a que el esquema posee

limitaciones, se propone migrar a un modelo reestructurado,
normalizado y considerando la componente espacial.

30

5.13.

Validar los datos de manera automtica, basndose en pasos

de la norma UNE-50040, lo que ayudara en la discriminacin de

datos anmalos, facilitando el pre-procesamiento de los datos al
personal encargado.
5.14.

Brindar interoperabilidad basado en el estndar ISO 19119

descrito en la familia de normas ISO 19100, generando archivos en

GML e imgenes geo-referenciadas de manera automtica. Lo que
permitir que estos datos sean consumidos por herramientas SIG
de uso comn.
5.15.

Crear un sistema que permita la visualizacin integrada del

comportamiento de las variables hidrometeorolgicas a nivel

nacional,

desde distintas perspectivas como mapas, grficos,

reportes tabulares, entre otros.

5.16.

5.17.

31

5.18.
5.19.

Recoleccin de variables

5.20.

Anlisis de la recoleccin de variables

5.21.

Levantamiento

de

requerimientos

funcionales

no

funcionales.
5.22.

Realizar casos de uso

5.23.

Realizar diagramas de secuencia

5.24.

Realizar diagrama de clases

5.25.

Realizar diagrama de Interfaz

5.26.

Realizar diagrama de colaboracin

5.27.

Realizar Diagrama de Paquetes

5.28.

Disear una interfaz web para la captura de los datos

hidrometeorolgicos de estaciones convencionales primaria y

secundaria considerando los requerimientos asociados a distintos
dispositivos a utilizar.
5.29.

Realizar la maquetacin de la pgina web necesaria para la

adaptacin de los distintos dispositivos principalmente a Tablet.

5.30.

Implementacin del sistema de recoleccin de variables

meteorolgicas.
5.31.

Diseo de la base de datos espacial, basado en el diagrama de

clases realizado en la parte de anlisis.

5.32.

Programacin del repositorio base a utilizar.

32

5.33.

Programacin de la capa de entidades.

5.34.

Programacin de la capa de negocio.

5.35.

Pruebas de usabilidad del mdulo de recoleccin de variables

meteorolgicas.
5.36.

Realizar un diagnstico de la base de datos de las estaciones

meteorolgicas telemtricas.
5.37.

Verificar la existencia de documentacin del modelo de base

de datos, as como la integridad referencial y los tiempos de

respuestas.
5.38.

Creacin de una base de datos relacional con la componente

geoespacial para alojar los datos de las estaciones meteorolgicas.

5.39.

Evaluar alternativas de sistemas gestores de base de datos

que soporten mdulos u extensiones espaciales.

5.40.

Se creara una base de datos en la que se incluyan elementos

geogrficos nativos del sistema gestor de base de datos.

5.41.

Migracin de datos

5.42.

Creacin de un servicio de migracin de datos del servidor de

meteorologa a la base de datos relacional con la componente

geoespacial.
5.43.

El servicio se ejecutara peridicamente, priorizando los

tiempos en el que el volumen de datos de entrada sea alto, el mismo

se

encargara

de

realizar

las

trasformaciones

espaciales

correspondientes.
5.44.

Validacin automtica de los datos segn la norma UNE:

500540.
33

5.45.

Conocer los lmites fsicos de las variables meteorolgicas

(temperatura y precipitacin), as como otras caractersticas de las

mismas que permitan validar las entradas digitadas por los usuarios
desde las maquinas clientes.
5.46.

Identificar los lmites fsicos por efemrides mediantes

consultas estadsticas a la base de datos, agrupando por estacin y

por meses.
5.47.

Validar la coherencia a muy corto plazo de la variable(hasta 4

vecinos)
5.48.

Validacin de la coherencia de los datos agregados y los datos

en detalle.
5.49.

Validacin de la coherencia la serie temporal de las variables.

5.50.

Validacin de la coherencia espacial.

5.51.

Generacin de reportes de las estaciones convencionales y

telemtricas desde distintas perspectivas (grficos, geogrficos,

tabulares) donde la perspectiva geogrfica se implementara
tomando en consideracin la familia de estndares ISO/OGC 19100.
5.52.

Habilitar API segn estndares ISO/OGC 19100

5.53.

Desarrollo de una aplicacin web en la que se visualice el

comportamiento de las variables hidrometeorologicas con la

presentacin de Mapas, Grficos, Tablas.
5.54.
5.55.
5.56.

Proceso de desarrollo de software

34

Para el desarrollo de la plataforma geoinformtica la cual contempla las etapas

de digitacin, validacin, integracin y difusin de datos hidrometeorolgicos, se
tendr en cuenta patrones, buenas prcticas y estndares de ingeniera de
software, con los cuales facilitar un proceso de desarrollo gil y a su vez
escalable.
Con el diseo guiado por el dominio 10 (Domain-Driven Design, DDD) (Evans,
2004) se tendr un enfoque para el desarrollo de software con necesidades
complejas mediante una profunda conexin entre la implementacin y los
conceptos del modelo y ncleo del negocio. Las premisas del DDD son las
siguientes:

Poner el foco primario del proyecto en el ncleo y la lgica del dominio.

Basar los diseos complejos en un modelo.

Iniciar una creativa colaboracin entre tcnicos y expertos del dominio

para interactuar lo ms cercano posible a los conceptos fundamentales
del problema.

El DDD no es una tecnologa ni una metodologa, este provee una estructura de

prcticas y terminologas para tomar decisiones de diseo que enfoquen y
aceleren el manejo de dominios complejos en los proyectos de software.
Adems de usar el DDD, es tambin necesario tener en cuenta patrones de
desarrollo (Martin C. Robert, 2006). Los patrones de diseo son el esqueleto de
las soluciones a problemas comunes en el desarrollo de software.
En otras palabras, brindan una solucin ya probada y documentada a problemas
de desarrollo de software que estn sujetos a contextos similares. Teniendo
presente los siguientes elementos de un patrn: su nombre, el problema (cuando
aplicar un patrn), la solucin (descripcin abstracta del problema) y las
consecuencias (costos y beneficios).
10 El dominio define un conjunto de requisitos comunes, la terminologa y la
funcionalidad de cualquier software construido para resolver un problema.
35

Existen distintos tipos de patrones de desarrollo, entre los cuales podemos

encontrar:

Patrones Creacionales: Inicializacin y configuracin de objetos.

Patrones Estructurales: Separan la interfaz de la implementacin. Se

ocupan de cmo las clases y objetos se agrupan, para formar estructuras
ms grandes.

Patrones de Comportamiento: Ms que describir objetos o clases,

describen la comunicacin entre ellos.

Adems, es necesario tener en cuenta la Programacin orientada a objetos y

para esto se tomarn en cuenta el diseo orientado a objetos Responsabilidad
Simple, Abierto-Cerrado, Sustitucin Liskov, Segregacin Interfaces y Inversin
de dependencias (Single responsibility, Open-closed, Liskov substitution,
Interface segregation and Dependency inversin, SOLID) (Martin C. Robert,
2006). En ingeniera de software, SOLID es un acrnimo mnemnico introducido
por Robert C. Martin a comienzos de la dcada del 2000 que representa cinco
principios bsicos de la programacin orientada a objetos y el diseo. Cuando
estos

principios

se

aplican

en

conjunto

es

ms

probable

que

un desarrollador cree un sistema que sea fcil de mantener y ampliar con el

tiempo. Los principios SOLID son guas que pueden ser aplicadas en el
desarrollo

de

software

para

eliminar cdigo

sucio provocando

que

el

programador tenga que refactorizar el cdigo fuente hasta que sea legible y
extensible. Para que este tipo de diseo de cdigo sea utilizado debe tener en
cuenta el desarrollo guiado por pruebas (TDD) (Beck, 2003), y forma parte de la
estrategia global del desarrollo gil de software y programacin adaptativa.

36

VI.

METODOLOGA

En este captulo, se presentara con detalle cada paso de la metodologa, desde

la seleccin del gestor de base de datos para la plataforma la cual diseara en
base a la propuesta de la base de datos SOS del 52Norht, la migracin de datos
de las estaciones telemtricas a la base de datos de la plataforma seguido de la
descripcin del proceso de desarrollo de software tanto como para el sistema de
recoleccin de datos hidrometeorolgicos para las estaciones convencionales
as como para el sistema de presentacin de datos hidrometeorolgicos de las
estaciones telemtricas; una vez obtenido los datos se proceder a presentar la
metodologa para habilitar la interoperabilidad de los datos mediante la
aplicacin de estndares OGC y la norma ISO 19100, finalizando con el
desarrollo de un mdulo de reportes para las estaciones convencionales y la
presentacin del desarrollo del Cliente IDE personalizado para el consumo de
los geoservicios realizados como parte de la habilitacin de la interoperabilidad
de los datos.
6.1. Base de datos
En esta etapa se usar un esquema de base de datos geoespacial, diseada
para el almacenamiento de datos de provenientes de sensores. De esta manera
proporcionara un medio de almacenamiento adecuado, para los datos
hidrometeorolgicos, provenientes de estaciones telemtricas automticas as
tambin como de estaciones convencionales principales.
Para esta etapa, se contempla instalacin y configuracin del sistema gestor de
base de datos (SGBD), adems, tambin se instalar y configurar la extensin
espacial correspondiente al SGBD.
6.1.1. Creacin de esquema relacional de base de datos
Se crear una base de datos Geo-Espacial (GeoBD), la que implementar un
esquema de base de datos que usa el servidor 52 North SOS 2.0, este
37

esquema, est diseado para almacenar datos de sensores georreferenciados y

dado que es usado por el servidor web de observaciones, el esquema sentar
las bases para la interoperabilidad de datos. Un pre-requisito de esta GeoBD, es
haber instalado la extensin espacial del SGBD.
6.2. Migracin de los datos de las estaciones telemtricas automticas a
una base de datos geoespacial
En esta etapa se migrarn los datos de las estaciones telemtricas automticas,
estos datos se encuentran en una base de datos (BD) diseada por SUTRON
(c), esta BD ser el origen de los datos, en ella se almacenan registros de
estacin es telemtricas desde el ao 2002. Se utilizar la documentacin que
brinda SUTRON(c), para conocer la estructura de la base de datos, identificando
tablas y datos necesarios para realizar la migracin.
Una vez que se concluya el estudio de la BD de SUTRON, se realizara
ingeniera inversa a la BD desarrollada por la comunidad 52N SOS que ser la
BD destino, al elaborar documentacin de la BD 52N SOS, se podr establecer
correspondencia de los datos origen con los datos destino.
6.2.1. Identificar las tablas de almacenamiento de datos, en la base
de datos XCdata.
En la etapa inicial de la migracin de datos, se utilizar la documentacin
existente del esquema de base de datos XCdata, con el objetivo de identificar en
que tablas se almacenan los datos, y as definir las consultas para obtener los
datos desde el esquema.
6.2.2. Ingeniera inversa al esquema de base de datos 52N SOS 2.0
1. Identificar tablas y sus relaciones.
2. Auto-documentacin de la relacin de la base de datos del 52N SOS 2.0
con el estndar SOS 2.0.
a. Comprender como estn plasmado los conceptos y estndares que
considera SOS 2.0, en el modelo de base de datos.
3. Crear diagrama relacional del esquema.
4. Crear diccionario de datos de las tablas a utilizar.
38

6.2.3. Establecer correspondencia de datos entre el esquema de

base de datos origen, con el esquema de base de datos destino
Una vez se posea diagramas y diccionario de datos, se establecer una
correspondencia entre las tablas y datos del esquema XCdata contra las tablas
de datos del esquema 52N SOS 2.0, como resultado se tendrn identificadas las
tablas necesarias del esquema origen adems de metadatos necesarios para la
migracin de los datos.
6.2.4. Desarrollar servicio de migracin automtica
Se desarrollar un servicio de Windows (demonio en nomenclatura UNIX) que
trasfiera de manera automtica los datos de la base de datos origen hacia la
base de datos de sensores. Debido a que los datos de las estaciones
telemtricas automticas se registran en diferido (hasta una hora despus de
haber ejecutado la observacin), el servicio se ejecutara cada minuto, y por cada
ejecucin comprobara los datos de las ltimas horas para ambas bases de
datos.
6.3. Metodologa de Desarrollo de Software
En el presente trabajo, se desarrollarn dos sub-sistemas, uno para la
recoleccin de los datos hidrometeorolgicos de las estaciones convencionales
principales y el otro para la presentacin de los datos hidrometeorolgicos desde
distintas perspectivas tales como: tabulares, grficos y geogrficos, as como los
reportes especiales FM12 de las estaciones convencionales.
El proceso de ingeniera de software para ambos sub-sistemas es el mismo, ya
que la plataforma contemplara un marco de trabajo uniforme para el desarrollo.
A continuacin, se describirn los pasos que se llevarn a cabo para la
implementacin de la ingeniera de software.

39

El anlisis y desarrollo del sistema aplicando ingeniera de software se compone

de los siguientes pasos los cuales son:

Levantamiento de requerimientos
Modelado de requerimientos
Implementacin del sistema
Pruebas
6.3.1. Levantamiento de requerimientos

El levantamiento de requerimientos, se realizar mediante:

Entrevistas a las autoridades interesadas en el desarrollo del sistema

(Observadores, Control de Calidad, Personal de Aeronutica) con

preguntas especficas para cada tipo de actor involucrado;

Se utilizar el mtodo de observacin del procedimiento de la recoleccin
de las variables de la observacin en la estacin de Managua y la
metodologa de trabajo de CC para una mejor compresin del giro del
negocio.
6.3.2. Modelado de requerimientos

El anlisis de los requerimientos da como resultado la especificacin de las

caractersticas operativas del software, indica la interfaz de ste y otros
elementos del sistema, y establece las restricciones que limitan al software.
De la accin de modelar los requerimientos obtenidos el proceso de
levantamiento de requerimientos, dar como resultado dos tipos de modelado:

Modelos basados en el escenario de los requerimientos desde el punto

de vista de distintos actores del sistema (Casos de Uso).

Modelos orientados a clases, que representan clases orientadas a objetos
(atributos y operaciones) y la manera en la que las clases colaboran para
cumplir con los requerimientos del sistema (Diagrama de Clases).

Complementando el modelado de requerimientos con diagramas UML, se

realizarn diagramas de secuencia y diagramas de paquetes, ya que un correcto

40

modelado de requerimientos es la parte esencial para el entendimiento, diseo y

desarrollo del sistema.
6.3.3. Implementacin del sistema de recoleccin de datos de las
estaciones convencionales
En la implementacin del sistema de recoleccin de datos de las estaciones
convencionales, se tom en cuenta en el desarrollo con necesidades complejas
mediante una profunda conexin entre la implementacin y los conceptos del
modelo y ncleo del negocio, en la cual se tomaron en cuenta patrones, buenas
prcticas y estndares de ingeniera de software que ayudaran al desarrollo gil
y mantenibilidad del sistema.
El sistema se desarroll bajo la arquitectura Domain Driven Design (DDD),
programacin orientada a objetos y el patrn para desarrollo de software SOLID
(Single responsibility, Open-closed, Liskov substitution, Interface segregation and
Dependency inversin). Siguiendo este patrn de desarrollo con sus cinco
principios bsicos, brinda al programador altas probabilidades que la
mantenibilidad del sistema sea fcil, as como poder expandirlo con el tiempo sin
problemas de cdigo espagueti, ya sea duplicndolo, que sea poco legible,
entre otros; que son los problemas comunes que cualquier programador tiene al
encontrase con un sistema que fue desarrollado sin ninguna gua o buenas
practicas.
A continuacin, se describen los elementos principales tomados en cuenta en la
implantacin del sistema.

Desarrollo de las entidades del dominio

Desarrollo del repositorio base a utilizar
Desarrollo de la capa de negocios(Infraestructura)
Desarrollo de la capa de presentacin
Maquetacin responsiva del sistema
Implementacin de ASP.Net Membership para la seguridad
Prueba de usabilidad del sistema

41

Desarrollo de las entidades de dominio

Para el desarrollo del sistema de recoleccin de datos de las estaciones
convencionales, siguiendo la metodologa DDD, se inici por definir las clases de
dominio. Estos objetos son entidades desconectadas y se utilizan para alojar y
transferir datos de las entidades entre las diferentes capas. Esta capa ignora
totalmente la persistencia de los datos, ya que esas tareas deben ser realizadas
desde la capa de infraestructura.
Del diagrama de clases, se pudo obtener las entidades esenciales y necesarias
mediante un exhaustivo anlisis para el desarrollo de este sistema. Las
entidades del dominio son fundamentales y tienen que ser identificadas
cuidadosamente, ya que un error en la definicin de estas puede traer consigo
grandes complicaciones a la hora del desarrollo.
Desarrollo del repositorio base a utilizar
El punto clave de los repositorios es que deben facilitar al desarrollador el
mantenerse centrado en la lgica del modelo del dominio, a este concepto se le
conoce tambin como PERSISTENCE IGNORANCE (PI), lo cual significa que el
modelo del dominio ignora completamente cmo se persisten o consultan los
datos contra las fuentes de datos de cada caso (Bases de datos u otro tipo de
almacn).
Basado en lo anterior, se cre un repositorio base para el desarrollo de este
sistema el cual se encargar de realizar las operaciones de insercin, editar,
cargar, lista y eliminar de la base datos los datos de las observaciones
realizadas en las estaciones.
Como antes fue mencionado, la base de datos utilizada para el almacenamiento
de estos datos est basada en el estndar de sensores por lo cual fue necesario
adaptar el repositorio de manera que los datos se guardaran de la manera en
que es requerida por el estndar, aterrizando el modelo de las estaciones
convencionales a la de los sensores de las telemtricas. Esto se logra gracias a
que la arquitectura orientada a dominio permite que el dominio ignore la fuente
de donde provienen los datos lo que posibilita hacer uso de la base de datos del
42

52North SOS 2.0 y almacenar los datos mediante las operaciones del repositorio
base con el ORM EntityFramework.
Desarrollo de la capa de negocio (Infraestructura)
Esta capa proporciona la capacidad de persistir datos, as como lgicamente
acceder a ellos, esta capa de persistencia de datos expone el acceso a datos a
las capas superiores que son la de aplicacin y la de presentacin.
En esta capa se program el repositorio base, la cual a nivel prctico es clase
encargada de realizar las operaciones de persistencia y acceso a datos,
haciendo esto se centraliza la funcionalidad de acceso a datos, lo cual hace ms
directo y sencillo el mantenimiento y configuracin de la aplicacin.
Por cada entidad principal en el dominio, en la infraestructura hay una clase que
hereda el repositorio base para utilizar las operaciones heredadas y realizar
dentro de cada una las que son propias de la entidad.
Desarrollo de la capa de presentacin
El trabajo de esta capa, es presentar los conceptos del negocio mediante la
interfaz de usuario. Se dise una interfaz de usuario fcil e intuitivo que facilite
a los usuarios solucionar tareas rpidamente y en la mejor manera, siendo este
un impacto enorme sobre la productividad de usuario lo que es el caso de este
sistema.
Teniendo en cuenta que una interfaz de usuario bien diseada, y optimizada
conlleva a reducir el nmero de oportunidades de cometer errores por parte de
los usuarios, lo que deriva a su vez en una mejora de la productividad y la
eficiencia, que es en lo que pretende auxiliar a los usuarios mediante el
desarrollo del sistema.
La productividad y la eficiencia son variables que se pueden medir, lo cual
comprobara que el sistema cumple el objetivo deseado adems de ayudar en el
procesamiento y utilizacin de la informacin recolectada en las observaciones
de las estaciones convencionales realizadas durante el da mediante esta

43

herramienta (de la Torre Llorente, Zorrilla Castro, Calvarro Nelson, & Ramos
Borroso, 2010).
El patrn de arquitectura utilizado para el desarrollo de la capa de presentacin
fue MVC (Model, View, Controller), es uno de los patrones ms influyentes en la
historia de la programacin y hoy en da es aun utilizado y brindado como
plantilla en Visual Studio para el desarrollo web, el objetivo que brinda este
patrn es separar el cdigo encargado de la presentacin con el encargado de la
ejecucin de la lgica de negocio lo cual brinda orden y facilidad al momento de
realizar un cambio lo cual brinda Mantenibilidad a la aplicacin.
En la actualidad la plantilla de MVC5 en Visual Studio trae consigo integrado
boostrap, lo cual es una herramienta open source para el diseo de sitios y
aplicaciones web, esto fue de gran ayuda en la maquetacin responsiva al
sistema que era uno de los requerimientos funcionales.
6.3.4 Pruebas
Como ltimo paso del ciclo de desarrollo de software, se aplicarn pruebas para
comprobar la correcta funcionabilidad del sistema; probar es el proceso de
ejecucin del software con la intencin de encontrar (y a final de cuentas
corregir) errores (Pressman, 2010).
Por lo tanto, se realizarn las siguientes pruebas:

Prueba de Navegacin
Prueba de Usabilidad
Prueba de Interfaz

6.4. Sistema de RecoleccionRecoleccin de Datos Hidrometeorolgicos

de Estaciones Convencionales
INETER es un ente de gobierno descentralizado encargado de la investigacin
meteorolgica, geolgica, cartogrfica, catastral, hidrolgica, y la agencia
encargada de la evaluacin de recursos fsicos de Nicaragua.

44

La direccin general de meteorologa (DGMET) es la encargada de operar la red

nacional de estaciones meteorolgicas, esto con el objetivo de prever los
desastres producidos por fenmenos de origen meteorolgico.
La DGMET cuenta con las direcciones de sinptica y aeronutica las cuales
tienen como principal objetivo brindar a la poblacin informacin acerca del
estado del clima en el pas, esto gracias al monitoreo de las estaciones
convencionales y automticas existentes a nivel nacional. Para obtener la
informacin de las diecisis estaciones convencionales del pas, se pasa por un
proceso la cual involucra a las reas: observatorio, control de calidad, sinptica,
aeronutica.
El proceso de cada una de las areas ser descrito a continuacin:
Observador: es la persona encargada de recolectar los datos de los
instrumentos analgicos de las estaciones meteorolgicas, llena la hoja de
campo la cual contiene todas las variables de la observacin, sin embargo, esta
se llena acorde al periodo. Los periodos establecidos son: Metar, Sinptico Trihorario, Sinptico principal y Especial; los cuales tienen sus propias variables
como se describe a continuacin:

Metar11: Nubosidad, visibilidad, termometra y humedad, pluviometra,

viento, bargrafo y barmetro.

Sinptico principal: Nubosidad, visibilidad, termometra y humedad,
pluviometra,

termometra

del

subsuelo,

evaporacin,

viento,

bargrafo, barmetro.
Sinptico Tri-horario: nubosidad, visibilidad, termometra y humedad,

termometra del subsuelo viento, barmetro y bargrafo.

Especial: Nubosidad, visibilidad, fenmeno y viento.

Estos periodos se realizan en diferentes horas:

Tabla 2. Periodos por Hora de las Observaciones

11 Informe rutinario de las observaciones de aerdromo que se realiza durante las 24 horas del
da a intervalos fijos de tiempo. (Take Off Briefing, 2012)

45

Hora
12am
1am
2am
3am
4am
5am
6am
7am
8am
9am
10am
11am

Periodo
Sinp-Principal
Metar
Metar
Sinp Tri-horario
Metar
Metar
Sinp-Principal
Metar
Metar
Sinp Tri-horario
Metar
Metar

Hora
12pm
1pm
2pm
3pm
4pm
5pm
6pm
7pm
8pm
9pm
10pm
11pm

Periodo
Sinp-Principal
Metar
Metar
Sinp Tri-horario
Metar
Metar
Sinp-Principal
Metar
Metar
Sinp Tri-horario
Metar
Metar

Fuente: de elaboracin Propia

Lo especiales se realizan cada vez que suceda un fenmeno en el da,

entendiendo fenmeno como lluvias, chubascos, tormentas de polvo, entre
otras.
Una vez que los observadores llenan la hoja de campo en el periodo
correspondiente, estos tienen un tiempo de diez minutos para enviar la
informacin recolectada a control de calidad quien procesa la informacin
recibida y la enva a la Direccin General de Meteorologa(DGMET) del INETER.
Tambin la informacin enviada por los observadores es recibida por
aeronutica, la cual es de suma importancia ya que esta es utilizada para el
despegue de los aviones del aeropuerto Augusto C. Sandino de Managua.
El tiempo que le lleva al observador llenar la hoja de campo, llamar a control de
calidad y llamar a aeronutica en ocasiones da como resultado no cumplir con el
tiempo establecido por la direccin de meteorologa.
As mismo el observador, luego de pasar el dato a las reas correspondientes,
tiene que pasar la informacin recolectada en la hoja de observacin en un
documento de Word compartido con control de calidad, aeronutica y sinptica,
y luego llenar los reportes FM12

12

que pasaran a la direccin de meteorologa a

final de mes.
12 Informe de observacin de superficie proveniente de una estacin terrestre
fija, establecido por la OMM.
46

Control de calidad (CC): es el rea encargada de recibir los datos de las 16

estaciones convencionales primarias y las dems estaciones secundarias
ubicadas en el territorio nacional. La manera de obtener los datos es mediante
llamadas que realizan hora a hora desde las distintas estaciones a control de
calidad donde dictan el dato al encargado de y el encargado de CC lo registra en
el documento Word compartido en red con aeronutica y sinptica.
Luego de escribirlo en el documento Word, llenan tambin un documento Excel
como especie de reporte y as mismo un documento fsico donde escriben las
variables principales de la observacin de cada estacin hora a hora.
Sinptica: Esta rea toma de insumo todas las observaciones (codificadas) que
son registrados por el observatorio de Managua y el rea de control de calidad.
Esto con el fin de realizar distintos reportes de pronsticos (horaria mensual,
tabla resumen 24 Horas, reporte diario y codificado, entre otros). A la vez ocupan
las codificaciones (METAR y SYNOP) de 7 estaciones para enviarlas a un
intercambio regional en donde se comparten los datos con distintos pases de
Centroamrica. Todos ellos miembros de la Organizacin Mundial de
Meteorologa mejor conocida como la (OMM).
Aeronutica: Al igual que sinptica ocupa la misma informacin que es
compartida en red, y a su vez comparte dicha informacin con el aeropuerto
directamente con la torre de control, esto por medio de un sistema propio, el cual
mandan las observaciones (codificaciones METAR) hacia la torre de control y
estos ltimos se las proporcionan a los pilotos para saber si las condiciones del
clima (velocidad del viento, visibilidad, precipitacin y presin) son las normales
para que ellos aterricen sin problema alguno. Es un rea es muy importante que
proporciona informacin vital para el aeropuerto. Es por ello que trabajan las
veinticuatro horas del da.
A manera de reducir el tiempo de llenado de la hoja de observacin, el margen
de error humano en la recoleccin de los datos de las estaciones
convencionales, y as mismo tambin brindar ayuda para el trabajo de control de
calidad en la digitacin de los datos de las 15 estaciones restantes en el pas, y
47

fundamentalmente almacenar esta informacin en una base de datos georeferenciada para estudios avanzados de estos datos; uno de los subsistemas
de la plataforma propuesta consta de un sistema web para la recoleccin de
datos de las estaciones convencionales tanto como primarias como secundarias.
El proceso a llevar a cabo para el desarrollo de este sistema, esta descrito en la
seccin Metodologa de Desarrollo de Softwar.
y as , el dato(informacin) sea compartida de manera inmediata con las
autoridades correspondientes a ver dicha informacin .

Requisito
Complejidad
Prioridad
Descripcin

RF1
RF1
Media
Alta
El sistema permitir la visualizacin adecuada del sistema
en dispositivos Tablets para el futuro uso de estas en cada
uno de las estaciones.

Proceso
Entrada
Salida

RF2
Requisito
Complejidad
Prioridad
Descripcin

RF2
Media
Alta
El sistema permitir la visualizacin de las opciones del sistema

Proceso

segn su rol y estacin.

Usuario deber ingresar sus datos (Usuario y Contrasea)

Entrada
Salida

asignados.
Nombre Usuario y contrasea.
Visualizacin del sistema segn su rol y estacin.

Anlisis de los requerimientos o Anlisis de las necesidades del sistema.

48

El segundo paso consta del anlisis de requerimientos mediante diagrama UML

tales como:

Casos de uso
Diagrama de clases
Diagrama de Secuencia
Diagrama de Paquetes
Diagrama de Interfaz
Diagrama de Colaboracin

3
Implementacin del sub-sistema de recoleccin de datos de las estaciones
convencionales

Desarrollo de la capa de negocios

Desarrollo del repositorio base a utilizar
Desarrollo de la capa de negocios
Desarrollo de la capa de presentacin
Maquetacin responsiva del sistema
Prueba de usabilidad del sub-sistema

SOS 2.0

49

INTEGRACIN DE DATOS ESTACIONES TELEMTRICAS AUTOMTICAS

METODOLOGA

Esta etapa de la metodologa se implementara normas de la familia ISO 19100

complementados con estndares OGC, para crear una base de datos
geoespacial orientada a sensores, el poseer un esquema estndar de sensores
permitir almacenar los datos de las variables hidrometeorologicas tanto de
estaciones telemtricas automticas como de estaciones convencionales
principales.
Base de datos
Se ha decidi utilizar como sistema gestor de base de datos PostgreSQL, la
razn principal de la eleccin es que postgresSQL, posee un complemento
denominado PostGIS en cual atribuye soporte para objetos geogrficos.
El esquema de base de datos para almacenar los datos hidrometeorolgicos,
est basado en el usado por el esquema de datos que implementa el servidor
52 north SOS 2.0, es un esquema de dase de datos diseado para almacenar
datos de sensores georeferenciados. El estndar OGC SOS incluye la norma
ISO 19156 Observations and Measurements (O&M), as como el estndar
OGC SensorML (lenguaje de modelado de sensores) [2], de manera que al
utilizar un esquema de base de datos diseado para OGC SOS se garantiza una
implementacin del esquema conceptual de O&M adems complementa con el
estndar SensorML para la codificacin de metadatos. En el esquema de base
de datos desarrollado por 52north para el servidor SOS 2.0, se identificaron un
total de 34 tablas, sin embargo algunas de estas tablas son usadas para
mantener la compatibilidad con el servidor SOS 1.0, por lo tanto no son
relevantes, se identificaron 18 tablas necesarias para almacenar datos y
metadatos asociados a sensores, a continuacin se enumeran las tablas
necesarias, as como tambin la funcin de cada una de ellas.

50

Tablas de para almacenar metadatos del estndar

FeatureOfIntesresType: Se utiliza para especificar el tipo geometra de
muestreo, se necesita para especificar el metadato de la geometra del
FeatureOfIntesres, en el caso de estaciones hidrometeorologicas se trata de un
punto en el espacio, por lo que su tipo segn el estndar O&M es un
SF_SamplingPoint [2].
ProcedureDescriptionFormat: Se utiliza para especificar el estndar de
codificacin del procedimiento, para el caso de estudio se utilizara el estndar
SensorML 2.0.
ObservationType: Se utiliza para especificar el tipo de observacin, segn el
estndar O&M, se pueden utilizar observaciones numricas, de textos, de
categora, booleanas, entre otras.
Tablas para almacenar metadatos de observaciones
FeatureOfIntesres: Es un identificador de la caracterstica geomtrica de
muestreo a la cual se asocia la observacin [1]. Para el caso de observaciones
hidrometeorologicas, el FeatureOfIntesres es la identificacin de la estacin
modelada con geometra de punto (segn O&M: SF_SamplingPoint).
ValidProcedureTime: Se utiliza para especificar el periodo en el que un
procedimiento ha registrado datos, la fecha de inicio corresponder a la fecha
del primer dato del sensor y la fecha final, se especifica cuando el procedimiento
se ha deshabilitado o dado de baja.
ObservableProperty:
corresponden

los

Se

utiliza

datos

[2].

para
En

el

especificar
caso

de

el

fenmeno

estudio,

de

al

cual

estaciones

hidrometeorologicas las propiedades observadas corresponden a las variables

hidrometeorologicas o una clasificacin de los datos emitidos por el sensor
(Procedure).
Unit: Se utiliza para especificar la unidad de medida de los fenmenos
observados, para el caso de estudio de estaciones hidrometeorologicas existen

51

mltiples unidades de medida tales como: milmetros (mm), grados centgrados

( C), metros por segundo (m/s), entre otros.
Offering: Se utiliza para especificar la oferta de datos para un sensor, es de
utilidad para agrupar de manera lgica las observaciones.
ObservationConstellation: Se utiliza para relacionar el sensor (procedure), el
fenmeno

observado

(Observable

property),

el

tipo

de

observacin

(ObservationType), y la oferta del sensor.

Series: Se utiliza para

para relacionar el featureofinteres, procedure,

observableproperte, unit, los que corresponde a los metadatos de la

observacin. Para el caso de estudio, en estaciones hidrometeorologicas, en
donde el featureofinteres corresponde a la identificacin de la estacin,
procedure a los sensores que posee la estacin, observableproperte a los
fenmenos que registra el sensor, unit a la unidad de medida del fenmeno.
Existe cierta semejanza entre Series y ObservationConstellation, sin embargo su
funcin difiere, esto es debido a que series considera la ubicacin
(featureofinteres) de la observacin, por lo tanto un determinado sensor que
observa un fenmeno podra tener una cantidad indefinida de series, esto es de
utilidad en el caso de sensores mviles, en el que sensor realiza las
observaciones en mltiples puntos de muestreo (featureofinteres), sin embargo
aunque se estaran generando series distintas, los datos generados pertenecen
a

un

solo

fenmeno

del

seor,

cuya

relacin

es

descrita

en

ObservationConstellation.

Tablas para almacenar datos de las observaciones

Observation: Contiene datos de cada observacin, sin embargo no el valor y
smbolo medido, esto se debe a que existen mltiples tipos de observaciones,
por lo tanto cada observacin tendr una relacin 1:1 con la tabla que alacena el
smbolo o valor medido, la tabla Observation posee una relacin 1:N con la
serie, de manera que cada observacin pertenece a una serie. En esta tabla se
52

especifica la fecha de inicio de la observacin, fecha final, el tiempo que tomo

realizar la observacin, la fecha de validez inicial, la fecha de validez final,
adems de otros datos en el caso de que sea requerido, como el identificador, el
nombre y descripcin de la observacin.
NumericValue: Se utiliza para almacenar el valor nmero de la observacin, en
el caso que el tipo de observacin sea OM_Measurement, posee una relacin
1:1 con la tabla Observation.
CountValue:
BooleanValue
BlodValue

Para esto se programaron servicios (demonios) para la transferencia de datos

provenientes de la base de datos de estaciones hidrometeorologicas
automticas, se trasferirn a la base de datos geoespacial, aplicando
trasformaciones para los tipos de datos (alfanumrico/espacial) y distribuyendo
los datos en el esquema de base de datos de sensores geo referenciados.
Origen de datos
Las estaciones telemtricas automticas envan sus datos al satlite GOES13,
estos datos son envidados a un receptor en tierra adems de ser almacenados
en los servidores de la NOAA como respaldo. Una vez en tierra tienen la seal
debe de ser decodificada de anloga a digital, para posteriormente ser
decodificada y almacenada en una base de datos. Lo descrito anteriormente, es
realizado por un sistema de la empresa Sutron, la misma encargada de proveer
el hardware

de las estaciones telemtricas convencionales. El sistema

especfico para la administracin de la base datos es Cerrado al igual que la

base de datos, lo que hace imposible que se realicen modificaciones u mejoras
por parte de otra entidad distinta al proveedor.

53

El sistema gestor de base de datos usado para la base de datos de las

estaciones telemtricas automticas es un MySQL versin 3.X, el cual fue
configurado para el ao 2002. Esta base de datos recibe aproximadamente
50,000 (cincuenta mil) registros diarios correspondientes a las variables las
distintas hidrometeorologicas. El esquema creado por Sutron Corporation(c)
consta de un total de 8 (ocho) tablas, segn Sutron Corporation(c) [6], la funcin
de cada una de ellas se describe de la siguiente manera.
Tres tablas de para la gestin:
1. XC_SITES - Contiene estaciones en el sistema XConnect.
2. XC_SITESENSORS - Contiene sensores de las estaciones en el sistema
XConnect.
3. XC_VER - Contiene el nmero de versin de esquema de base de datos.
Las cinco tablas de datos son:
1. XC_DATA1 - Contiene los datos numricos del sensor.
2. XC_TXTDATA1 - Contiene los datos del sensor de texto.
3. XC_PPDATA1 - Contiene los datos de las instrucciones post-procesamiento y
operaciones.
4. XC_GOESQC - Contiene los datos de calidad del mensaje por satlite.
5. XC_RTUQC - Contiene datos de comunicacin SSP.
A continuacin se presenta una imagen del esquema relacional de la base de
datos principal en la que se almacenan los datos una vez codificados. La tabla
xc_data1 contiene los datos decodificados, correspondientes a todas las
variables hidrometeorologicas, en la tabla xc_sites se almacenan metadatos de
cada estacin, estos son utilizados para la decodificacin.
Debido a que lLa tabla xc_data1 posee una llave principal compuesta por tres
columnas, son: el nombre e identificador de la estacin, nombre e identificador
del sensor o variable y la fecha, lo que se considera correcto, debido a que
54

almacena series temporales por cada variable que observa cada una de las
estaciones hidrometeorolgica, sin embargo no existe una relacin con la tabla
xc_sites, lo que provoca que en el caso de cambiar el dato station_id o
eliminar un registro de la tabla xc_sites se pierdan los identificadores de las
series.
La siguiente imagen se puede apreciar una consulta SQL realizada en la base
de datos, el resultado de esta consulta visualiza que la cantidad de estaciones
que han registrado series temporales en xc_data1, es mayor a la cantidad de
estaciones registradas en la tabla xc_sites.

Migracin de datos de estaciones telemtricas automticas.

Para automatizar la migracin de los datos recibidos por las estaciones
meteorolgicas automticas, se desarroll un servicio/demonio que se ejecuta
en un tiempo establecido, los momentos en que se ejecuta el servicio se han
definido por el personal a cargo de la base de datos como los momentos
ptimos en que la mayor cantidad de datos ya se han racionado de manera
local.

55

El servicio verifica la correspondencia en las bases de datos considerando un

intervalo de tiempo (seis horas atrs del momento actual) y el volumen de datos
correspondiente a este intervalo de tiempo, esto se realiza en el caso de que
alguna estacin meteorolgica automtica no trasmita los datos en el tiempo
esperado por motivos externos; adems se ha configurado el servicio para que
semanalmente verifique la correspondencia de los datos en intervalos de tiempo
ms amplios (dos semanas atrs).
Correlacin entre esquemas
El esquema de datos de la base de datos en el que se alojan los datos despus
de ser decodificados, presenta una tabla de nombre XC_DATA1, en esta tabla
almacenan los campos necesarios para crear series temporales como el
sensor, estacin y fecha, la tabla SITES almacena los metadatos de las
estaciones sin embargo no se han establecido coordenadas o algn elemento
geogrfico que identifique a la estacin, adems la tabla SITES presenta
algunos problemas de relacin (ver seccin Origen de datos), por lo tanto es de
nula utilidad.
Los datos sern tomados directamente de la tabla XC_DATA1, la que
especficamente contiene los siguientes campos:
STATION_ID: Identificador de la estacin, es el nombre nico que se le da a la
estacin.
SENSORNAME: Identificador del fenmeno que observa el sensor. Nombre
nico del fenmeno que observa el sensor
TIME_TAG: Fecha que fue realizada la observacin.
VALUE: Dato medido correspondiente al fenmeno observado.

56

6.5. Ejemplo de datos:

6.6. STATION_I
D
6.10.
YAPA

6.7. SENSORNA
ME

ACO

6.11.

6.8. TIME_TA
G

DIRVIE

NTO

6.12.

E
201

4-10-01
00:00:00

57

6.9. VALU

6.13.
6

6.14.
6.15.

Metadatos Faltantes

6.16.

Para establecer la ubicacin de las estaciones, se solicit las

coordenadas de las estaciones a la Direccin General de Meteorolgica

del INETER, los documentos facilitados se utilizaron para crear un
archivo XML serializado, con el objetivo de facilitar la manipulacin de
estos datos por parte del software encargado de migrar los datos. En el
caso de los metadatos de sensores, se observa no se posee el metadato
del sensor como tal, se tiene el nombre del fenmeno, por lo tanto se
clasifico estos fenmenos en dependencia al sensor fsico usado. Esta
informacin fue facilitada por la direccin general de meteorologa, del
INETER. La unidad de medida de los fenmenos observados fue
facilitada por la direccin general de meteorologa del INETER.
6.17.

Los campos mnimos necesarios para realizar la migracin a loa

base de datos son: Estacin, Fecha, Sensor, Fenmeno, Valor, Unidad

Medida, Locacin (Geometra); la correspondencia de estos campos en
la base de datos de sensores es de la siguiente manera.

6.18.

Campos necesarios

6.19.

Base

de

datos

sensores
6.20.

Estacin

6.21.

FeatureOfInterest

6.22.

Locacin

6.23.

FeatureOfInterest

6.24.

Fenmeno

6.25.

ObservableProperty

6.26.

Sensor

6.27.

Procedure

6.28.

Unidad Medida

6.29.

Unit

6.30.

Fecha

6.31.

Observation

6.32.

Valor

6.33.

NumericValue

58

de

6.34.
6.35.

Las siguientes figuras muestran de manera descriptiva la

relacin entre los campos antes mencionados, en el caso de

estaciones meteorolgicas automticas, emiten valores numricos,
por lo tanto estara asociado a la tabla NumericValue.
6.36.

6.37.

En la imagen representa la distribucin de los datos, en las

relaciones de las tablas de la base de datos de sensores.

6.38.

Requisitos de almacenamiento

59

6.39.

Actualmente 96 estaciones telemtricas automticas, ubicadas

en el territorio nacional, estas estaciones realizan observaciones de

8 variables hidrometeorologicas cada 15 minutos. En el caso de
estaciones convencionales principales en la que la cantidad es de
16, realizan observaciones horarias, en cada observacin recolectan
mltiples datos de cada variable, se estima al menos 50 datos por
observacin correspondiente a mltiples variables, todas las
estaciones envan sus datos durante todo el ao, se har un
estimado del volumen de datos que se generara.

6.40.
N

6.41.

6.42.

antida

Est

Observ

aci

acione

Hora

one

6.43.
Horas al
Ao

otal de
Obser
vacion
es

s
6.45.

6.44.

al

ao
6.46.

6.47.

96

6.48.
8760

6.49.

691072
0

6.50.
16
6.55.

6.51.

6.52.

0
6.56.

6.53.
8760

6.57.

Total

6.58.

6.54.

008000
6.59.

391872
0

60

6.60.

Validacin

automtica

de

los

datos

de

estaciones

hidrometeorolgicas.
El tamao requerido por observacin es de 578B [7], para la cantidad de
33918720 anuales, por lo tanto es estima un almacenamiento anual de
18.25 GB, esta cantidad como mnimo debido a que no se est
considerando en su totalidad la cantidad de datos

de las estaciones

convencionales principales.
El manejo de este tipo de datos es un tema muy sensible, dado que es
necesario asegurar la integridad de estos para poder generar informacin
confiable. Por lo que es ineludible establecer un mtodo automatizado que se
encargue de esto para facilitar el trabajo a las personas encargadas de hacer
control de calidad y estas puedan encargarse de otras tareas de mayor
prioridad.
La norma UNE 500540 establece directrices para la validacin de datos
meteorolgicos, por ello, se desarrollar una metodologa de validacin
automtica, para los datos medidos en la red de estaciones hidrometeorolgicas
de INETER. La norma UNE 500540 define distintos niveles de validacin o
control, sin embargo, no todos estos niveles son obligatorios.
La norma une define seis niveles de validacin, cada nivel establece una prueba
que debe de aplicarse a lo(s) dato(s); a su vez estos niveles deben de ser
aplicados secuencialmente siguiendo el orden de la norma; cabe mencionar que
el nivel seis, puede aplicarse posterior a aplicar el nivel cero y uno de la norma.
A continuacin, se enumerarn los niveles que se aplicarn en este trabajo, a su
vez la metodologa para aplicar cada nivel.
Nivel 0: Validacin de la estructura de registro y del instante de medida.
Este Nivel, se comprueba que si existen errores en la trasmisin del dato y de su
hora y fecha (instante), por lo tanto, este nivel, es aplicable al proceso de
trasmisin, recepcin, decodificacin y almacenamiento de los datos.
61

Nivel 1: validacin de datos segn lmites.

En este nivel, se pueden utilizar dos tipos de pruebas: (a) lmites rgidos y (b)
lmites flexibles, sin embargo, solo los lmites fsicos son obligatorios y
apropiados para discriminar valores errados; los lmites flexibles se pueden
utilizar para discriminar valores anmalos que requieren de inspeccin.
a) Lmites rgidos: fsicos o instrumentales.
Los lmites rgidos son utilizados para discriminar las observaciones con
valores no reales, al implementar este nivel, se establecern lmites al
filtrar los datos, de manera que el valor de cada observacin se encuentre
entre los lmites mnimos y mximos.
b) Limites flexibles
Estos lmites deben de basarse, en valores extremos para la variable a la
que se aplicaran, lo ideal es considera la zona en la que est ubicada la
estacin, adems de considerar las efemrides meteorolgicas para cada
mes (AENOR, 2004).
Los valores que no superen la prueba de lmites flexibles, deben de ser
considerados sospechosos (AENOR, 2004) y no sern considerados para
su uso operativo, hasta que la validez de estos datos sea comprobada por
una prueba de inspeccin visual (K. G. Hubbard, 2005).
Para establecer un umbral de valores se pueden utilizar mtodos
estadsticos (K. G. Hubbard, 2005), con la ventaja que al aplicarlos, se
adaptan a las necesidades y caractersticas de cada red de estaciones
(Estvez Gualda & Gaviln Zafra, 2008). Una manera de establecer un
umbral mximo de valores, es considerar la media de valores mximos de
cada da del mes de cada ao que se tenga registro; posterior a ello
calcular la media y desviacin estndar de los valores calculados
anteriormente, agrupados por mes (K. G. Hubbard, 2005).
Considerando la antes mencionado, se ha creado una metodologa para
calcular umbrales por regin y por mes; la metodologa para calcular los
umbrales de precipitacin, est compuesta por 4 etapas:
62

1. Establecer ubicaciones geogrficas (Sub-regiones) que presenten

condiciones climticas similares.
2. Agrupar los registros de precipitacin por la ubicacin geogrfica en
que se encuentre la estacin que los observo.
3. Calcular promedio de valores mximos diarios, para los datos de cada
sub-regin; por ejemplo: promedio de mximos diarios para todos los
01 de enero que se tenga registrado (de manera que s que al final de
este procedimiento, se tenga un promedio de los valores mximos
para cada da del ao); esto para cada sub-regin.
4. Calcular media y desviacin estndar de cada mes, para cada subregin, esto se realizar con los valores obtenidos en la etapa 3.
Segn K. G. Hubbard, una vez que se tiene la media y desviacin estndar de
cada mes, cada valor (V) que se pretenda validar debe de cumplir la condicin
(Ec1), en la que X es la media de los valores mximos para el mes i y para la
regin j; D es la desviacin estndar valores mximos para el mes i y para la
regin j; f es un nmero que determinara la amplitud del intervalo, por lo tanto
determinara la cantidad de datos que pasan la prueba (K. G. Hubbard, 2005).
X ij f D ij V X ij + f Dij

(Ec. 1)

Sin embargo, para implementar esta ecuacin (Ec1) en la variable precipitacin,

se est discriminado con umbrales mnimos y mximos, lo que resultara
incorrecto para el fin de esta variable, debido a que esta variable es un
acumulado de precipitacin, por lo que sus los valores de los registros de
precipitacin pueden ir desde 0 (prueba de lmites fsicos) hasta un umbral
superior, considerando el planteamiento anterior, la ecuacin que se usara
validara los registros (Ec2) queda de la siguiente manera:
V X ij + f Dij
6.61.

(Ec. 2)

HabilitarHabilitacin de lL interoperabilidad ser habilitada

basadao en estndares OGC e ISO 19100.

63

1. Configurar servidor de mapas WMS (Web Maps Service).

2. Configurar servidor de WFS (Web Feature Service)
3. Habilitar servidor SOS (Sensor Observation Services)
En Nicaragua se cuenta con muchas instituciones que velan por el bienestar
ciudadano, entre ellas INETER, SINAPRED, MARENA, otras. Estas instituciones
comparten geoinformacin de manera que los distintos trabajos que se realizan
con estos datos genere el conocimiento necesario para tomar decisiones
adecuadas en distintos aspectos como lo es la prevencin y atencin rpida ante
desastres naturales sobre el territorio, con el objetivo de salvaguardar vidas y los
bienes de los ciudadanos.
Es de suma importancia que la geoinformacin que se comparte sea
estandarizada, para facilitar el acceso de la misma por las distintas
organizaciones interesadas. La normalizacin de la informacin geoespacial
tiene como objetivo la compresin, acceso, integracin y reutilizacin de manera
eficiente; facilitar la interoperabilidad con herramientas SIG. (Anguix, 2013)
Para cumplir los objetivos antes mencionados es necesario contar con una
arquitectura de servicios geoinformaticos que contemple lo siguiente:

Proveer un entorno de trabajo abstracto que permita el desarrollo

coordinado de servicios especficos.

Disponer de servicios de datos interoperables a travs de normalizacin

de interfaces.
Definir un entorno de trabajo abstracto que pueda ser implementado de
mltiples formas.

Basado en lo anterior, el presente trabajo brindara interoperabilidad mediante

estndares OGC y normas de la ISO 19100, lo que permitir que los datos sean
consumidos por: instituciones que generen informacin, herramientas SIG, entre
otros.
Para habilitar la interoperabilidad fue necesario seguir los requerimientos
descritos por la norma ISO 19119, lo cual es una arquitectura basada en modelo
multicapas, la cual est definida como un conjunto de componentes, conexiones
64

y topologas definidas a travs de un punto de vista computacional, que

considera la interaccin de servicios, esto descrito a travs de tres principales
interfaces:

La informacin, la cual son todos los datos recolectados de las distintas

estaciones hidrometeorolgicas para su procesamiento.

El tcnico, que trata la forma en como esta informacin ser distribuido,
es decir, la infraestructura requerida para soportar la distribucin de los

datos.
El tecnolgico, que describe la implementacin del sistema RM-ODP en
trminos de la configuracin de los servicios e implementacin de los
mismos.

Para lograr lo anterior se configuraron de tres servicios IDE definidos por la

OGC, los cuales son:

WMS para la localizacin y visualizacin de mapas

WFS para la gestin de informacin geogrfica de manera discreta o

vectorial
SOS para compartir series temporales segn el estndar O&M y
SensorML.4

Todos los servicios antes enumerados, sern configurados en GeoServer

v.2.7.0, este es un servidor de cdigo abierto para compartir informacin
geoespacial. GeoServer contiene todos los geoservicios exceptuando SOS, el
cual ser implementado con un software de 52North.
Para la configuracin e implementacin de estos servicios se necesita en primer
lugar la instalacin de Apache Tomcat y GeoServer.
A continuacin, se describe paso a paso la instalacin y configuracin tanto de
Apache Tomcat, GeoServer, as como la configuracin de los servicios IDE a
implementar.

65

6.61.1.

Instalacin de Apache Tomcat y GeoServer

Apache Tomcat es una aplicacin de software de cdigo abierto de Java Servlet.

Por medio de este software, se ejecutar el archivo .war de GeoServer para la
configuracin de los servicios IDE.
Para la instalacin de este, solo basta con descargar su versin para Windows y
ejecutarlo. En este caso de estudio se usar la versin 7 de Apache Tomcat.
Luego de ejecutarlo, se descarga el archivo .war de la pgina oficial de
GeoServer, en este caso se utilizar la versin 2.7.0 y desde Apache Tomcat se
subir el archivo .war y una vez arriba en el Tomcat se corre el GeoServer.
Una vez que se ha puesto en funcionamiento GeoServer, se proceder a realizar
la configuracin de los servicios IDE que consultaran la base de datos de las
estaciones hidrometeorolgicas del INETER.
6.61.2. Configuracin WMS
En GeoServer, el servicio WMS se realiza de la siguiente manera:
1. Crear un espacio de trabajo en GeoServer.
2. Editar el espacio de trabajo donde habilitara los servicios que desea ver en
este espacio de trabajo (WMS, WFS, WCS).
3. Crear un almacn de datos. Donde se configurar el acceso a la base de
datos con componente geoespacial. Se selecciona el gestor de base de
datos a utilizar, en este caso es PostGIS que es la componente espacial de
PostgreSQL (el gestor de base de datos que se utiliza).
4. Luego ingresar los parmetros requeridos para crear el almacn de datos,
tales como: Seleccionar espacio el espacio de trabajo, nombre de la base de
datos, usuario y contrasea del gestor de base de datos, IP o DNS del
servidor.
5. Una vez terminado de configurar el almacn de datos, este redireccina a la
opcin de crear capa donde muestra todas las vistas y/o tablas que se
encuentran en el gestor de base de datos.
6. Se selecciona la vista tabla que se va a consumir (utilizar), este recurso,
debe de contener un campo georreferenciado, adems de los datos de

66

inters que se deseen publicar, una vez seleccionada la vista o tabla, se

procede a publicar la capa seleccionando la opcin publicacin.
7. A continuacin se edita la capa a publicar, donde se llenan los parmetros de
srs declarado donde se busca el EPSG:432613 y en la seccin encuadres
se calculan con las opciones calcular de los datos y calcular desde el
encuadre nativo, se guarda la capa.
8. Una vez publicada, se va a la opcin pre visualizacin de capas y se busca
la que se public. Luego se selecciona la opcin OpenLayers donde se
podr ver la operacin GetMap del servicio WMS. (Ver en resultados)
Ver pasos en anexo A.9.1
6.61.3.

Configuracin WFS

Este servicio permite acceder y consultar los atributos de un objeto (feature)

geogrfico, permite no solo visualizar la informacin, sino que tambin permite
acceder a la informacin y descargarla tambin permite manipular (editar, borrar,
crear) la informacin almacenada en la base de datos con WFS-T (LopezVasquez & Bernabe-Poveda, 2012).
Continuando el ejemplo anterior una vez publicada la consulta o vista que se va
a consumir, en la pre visualizacin de capas se selecciona la opcin GML
donde genera una operacin GetFeature del servicio WFS, su salida es en
formato GML. (Ver en Resultado)
6.61.4.

Instalacin y configuracin de 52North SOS

Se instalar el servidor de observaciones de sensores (SOS) desarrollado por la

comunidad 52North (52north, s.f.), el servidor SOS en su versin 4.2.0, para
ello se descargar en el archivo de extensin .war, que ser desplegado en el
servidor web con soporte JAVA, en este caso se usar Apache Tomcat,
previamente instalado. Una vez instalado se procede a configurar.
Se empieza por crear o seleccionar una base de datos, en el gestor que se
utilizara (ej. PostgreSQL), a su vez esta base de datos, debe de tener habilitada
la componente espacial (ej. PostGIS); una vez creada, se procede a ingresar las
13 European Petroleum Survey Group
67

configuraciones del gestor de base de datos en la ventana de 52north SOS.

Para finalizar se ingresan metadatos de identificacin del servidor, como
propietario,

locacin,

descripcin,

contacto,

entre

otros.

Para

finalizar

configuracin, se establecen las credenciales de administracin del servidor

52north SOS.
El software 52North SOS, cumple con la especificacin OGC SOS 2.0 que se
especificada en el ao 2012; ofrece retro-compatibilidad con las operaciones de
consulta de la especificacin OGC SOS 1.0 (52north, n.d.), el software SOS
permite realizar peticiones SOAP, o bien con mtodo POS en formato JSON,
peticiones POX en formato XML y una implementacin parcial de peticiones con
mtodos GET bajo el estndar OGC KVP (Codificacin para peticiones GET)
(Documentacion, n.d.).
6.62.

Anlisis

Sistema

para

presentacin

de

datos

hidrometeorolgicosdesarrollo del sistema de presentacin de

datos hidrometeorolgicos.
En INETER, la DGMET cuenta con un conjunto de estaciones telemtricas
automticas, las cuales cuentan con un conjunto de sensores entre ellos el de
lluvia. Estas estaciones estn extendidas sobre todo el territorio nacional y
envan los datos recolectados segn el tiempo que tengan configurados en cada
estacin (10 min, 15 min, 30 min) al satlite GOES12 el cual se encarga de
enviar a una estacin terrena en el INETER el paquete completo con la
informacin recolectada por los sensores de las estaciones automticas
telemtricas.
Estos paquetes son decodificados y almacenados en una base de datos
PostgreSQL por un sistema comercial llamado XCONNECT desarrollado por la
compaa SUTRON.
Una vez los datos fueron almacenados y validados a travs de los pasos
anteriores descritos en la metodologa es necesaria la presentacin de estos
datos

en

distintas

perspectivas

(Reportes
68

tabulares,

grficos,

mapas

georreferenciados) por lo cual es necesaria la creacin de una aplicacin que

cumpla con ciertos requerimientos para la generacin de esta informacin,
Adems, esta herramienta deber ser capaz de brindar distintos niveles de
seguridad a los usuarios segn privilegios de acceso a la informacin y as sirva
como una herramienta en la toma de decisiones agilizando el proceso de trabajo
de los usuarios.
El proceso a llevar a cabo para el desarrollo de este sistema, esta descrito en la
seccin Metodologa de Desarrollo de Softwar.
6.63.

Desarrollo del sistema deLos reportes FM12

Los observadores de la estacin de Managua, realizan una serie de reportes

solicitados por la direccin de meteorologa que trae consigo cierto grado de
dificultad y les toma bastante tiempo realizarlos. En total son 12 reportes los que
se realizan, algunos diarios, otros mensuales.
Es una necesidad que estos reportes se realicen de manera digital para as
ahorrar una gran cantidad de dinero en papelera, as como ayudar a los
observadores en la generacin de estos reportes ya que una vez ingresada la
observacin en el sistema, se almacena en una base de datos de la cual se
pueden extraer los datos necesarios para la generacin de los reportes.
Es importante que los reportes digitales sean los ms similar posible a los
reportes fsicos, ya que as los usuarios finales no tengan dificultad para
procesar la informacin mostrada en ellos.
Los reportes son los siguientes:
1. Reporte cdigo Metar
Los reportes Metar, son los reportes de todas las codificaciones Metars en el da
por estacin, por hora o por rango de fechas.

69

2. Reporte diario
Los reportes diarios, son reportes de las variables de temperatura mxima y
mnima de del da adems de la precipitacin acumulada, por rango de fechas
y/o estacin.
3. Reporte codificado
Este reporte, tambin conocido como FM12, se realiza una vez al da, muestra el
valor las 24 horas de variables tales como: nubosidad, visibilidad, temperatura
mxima, temperatura mnima, fenmenos entre otras dando al final de este la
suma y promedios de cada una de ellas.
4. Reporte horarias mensual
En este reporte se muestran las mismas variables que en el reporte codificada
de una hora especifica registrada en todo el mes.
5. Reporte tabla resumen 24 horas
Muestra el promedio de todas las variables meteorolgicas registradas en el da.
6. Reporte medias mensuales horarias
Este reporte muestra el promedio por hora de todo el mes de las variables:
temperatura, humedad, presin, duracin de fenmenos.
7. Reporte valores mensuales medios y extremos
Promedio total del mes de las variables velocidad, velocidad del viento,
temperatura del aire, presin a nivel de la estacin.
8. Reporte resumen mensual del viento (direccin y velocidad del viento)
Muestra el promedio de la velocidad y direccin del viento por hora de todo el
mes.
9. Reporte tabla resumen mensual evaporacin y temperatura

70

Este reporte muestra el promedio mensual de las 24horas de las variables

tanque clase A, piche y la temperatura del suelo.
10. Reporte registro de evaporacin
Muestra los valores en el mes de las variables tanque clase A, anemmetro
totalizador y piche.
11. Reporte registro de temperatura del suelo
Reporte mensual de una hora especfica de la temperatura del subsuelo a 2, 5,
10, 20, 30, 50 y 100cm de profundidad.
12. Reporte tabla climtica de resumen mensual
Muestra el promedio del da de variables como termmetro hmedo, punto de
roci, humedad relativa, precipitacin entre otras. Adems, muestra las
temperaturas mnimas y mximas del da.
Los reportes se realizarn utilizando Visual Studio con el componente
XtraReport de DevXpress, el cual ayuda al desarrollo rpido de aplicaciones con
controles que ayudan que la usabilidad del sistema sea adecuada para los
usuarios.
6.64.

Clientes EstndaresImplementaImplementacin der clientes

IDE
En esta etapa se configuran algunos clientes estndares que harn uso de los
servicios web estandarizados, que fueron configurados en la etapa de
interoperabilidad.
6.64.1.

Cliente SOS

Se publicarn series de datos hidrometeorolgicos, a travs de servicios web

bajo el estndar OGC SOS (Sensor Observation Service), se implementar un
software desarrollado por la comunidad 52North, bajo la licencia de cdigo
abierto. El origen de los datos ser la base de datos en la que se almacenan
datos de las estaciones hidrometeorologicashidrometeorolgicas.
71

El cliente que se implementara ser SOS.JS, este es un cliente ligero, de cdigo

abierto; SOS.JS proporciona un nivel de abstraccin a las capas que se
comunican con los servicios, utiliza OpenLayers-SOS para la integracin con
servicios WMS, y como librera base para la comunicacin con el servidor SOS
(52north, n.d.).
SOS.JS es un cliente ligero desarrollado en JavaScript por la comunidad
52north, es de cdigo abierto. SOS.JS utiliza OpenLayers-SOS como base para
comunicarse con el servidor SOS, adems de la integracin con servicios WMS.
Los mdulos de SOS.JS proporcionan un nivel un nivel de abstraccin a las
capas de comunicaron con servicios SOS [13].
6.64.2.

Clientes IDE (WMS)

Los datos publicados en la seccin de interoperabilidad en los servicios WMS y

WFS sern consumidos por un visor web, el cual es una aplicacin web
diseada con lenguaje HTML5; en complemento con Heron14 un cliente de
mapeo en la red que facilita la creacin de aplicaciones web de mapas con el kit
de herramientas GeoExt y JavaScript.
Heron permite la construccin de mapas, paneles, barras de herramientas,
capas, arboles de capas, y sus caractersticas tales como: colores, tamaos
entre otras. En conjunto con GeoExt y JavaScript se logra una robusta aplicacin
para el consumo de servicios geogrficos.
La aplicacin web se publicar en un servidor Apache Tomcat, donde se
adjuntar la aplicacin web en la carpeta webapps del Tomcat, y con el editor de
texto HTML sublime text se editar el diseo del visor luego con la librera
OpenLayers de JavaScript (js) se consumir el Geoservicio WMS previamente
publicado en GeoServer.
Con SLD se realiz el estilo de los puntos en el mapa para diferenciar por
colores la cantidad de lluvia acumulada en periodos de tiempo.
14 Heron: Librera de Mapeo y grficos con GeoExt para el consumo de
Geoservicios.
72

SLD, es una extensin del WMS basado en XML. Es un estndar descrito por la
OGC para la descripcin de estilos aplicables a las capas de una cartografa de
manera que puedan elegirse colores, grosores, tamaos, etc. Los datos
geoespaciales, no tienen una componente visual por lo tanto para ser
visualizados

deben

tener

estilo

(Lopez-Vasquez,

Fundamentos

de

las

infraestructura de datos espaciales (IDE), 2012); estos atributos que ayudan a

visualizar el dato de manera ms sencilla para el usuario.

73

VII.

CASOS DE USO

VIII.

IX.

CLIENTES ESTNDARES

X.

En esta etapa se configuran algunos clientes estndares que harn

uso de los servicios web configurados en la etapa de interoperabilidad.

XI.

CLIENTE SOS

74

XII.

SOS.JS es un cliente ligero desarrollado en JavaScript por la

comunidad 52north, es de cdigo abierto. SOS.JS utiliza OpenLayersSOS como base para comunicarse con el servidor SOS, adems de la
integracin

con

servicios WMS. Los

MDULOS

de

SOS.JS

proporcionan un nivel un nivel de abstraccin a las capas de

comunicaron con servicios SOS [11].

75

XIII.
XIV.
XV.

EL

MODULO

APLICACIN

SOS.APP
SOS

SE

UTILIZA

GENRICA,

EN

PARA

CREAR

UNA

ESTA APLICACIN

SE

VISUALIZAN SERIES TEMPORALES, AS COMO METADATOS DE

LAS ESTACIONES, ADEMS PERMITE EXPORTAR LOS DATOS
DE LA SERIE EN FORMATO .CSV. SOS.APP HACE USO DE
MLTIPLES MDULOS DEL CLIENTE SOS.JS, A CONTINUACIN
SE ENUMERAN LOS MODELOS QUE LA APLICACIN UTILIZA.
XVI.
XVII. SOS.MENU: SE UTILIZA PARA DESPLEGAR DATOS DE LOS
OFFERING (AGRUPACIN LGICA DE VARIABLES) Y SUS
VARIABLES (OBSERVABLEPROPERTY), DE MANERA QUE DADA
UNA ESTACIN SE PUEDEN CONOCER SUS SENSORES, UNA
VEZ SELECCIONADO UN SENSOR DE INTERS SE PUEDE
ESTABLECER LA VARIABLE QUE OBSERVA EL SENSOR.
XVIII.
XIX.

SOS.TABLE: SE UTILIZA PARA MOSTRAR UNA LISTA DE LAS

OBSERVACIONES DE LA SERIE TEMPORAL. ADEMS EN EL
CASO QUE LOS DATOS DE LA SERIE SEAN NUMRICOS,
PERMITE REALIZAR CLCULOS ESTADSTICOS A LOS DATOS,
COMO CUARTILES, DESVIACIN ESTNDAR, ENTRE OTROS.

XX.
XXI.

SOS.INFO: ESTE MDULO TIENE EL OBJETIVO DE PRESENTAR

METADATOS DE LA SERIE, TALES COMO DISPONIBILIDAD EN EL
TIEMPO DE LA SERIE.

XXII.
XXIII. SOS.PLOT: SE UTILIZA PARA GRAFICAR SERIE TEMPORAL DE
MANERA LINEAL.
XXIV.

76

XXV. SOS.MAP: SE UTILIZA PARA VISUALIZAR LAS ESTACIONES

(FEATUREOFINTERES) EN EL ESPACIO, PARA ELLO CONSUME
WMS, UTILIZA COMO BASE OPENLAYERS, SE PUEDE ASOCIAR
EVENTO DE SELECCIONAR ESTACIN, PARA SOLICITAR DATOS
DE LA ESTACIN.
XXVI.
XXVII. DEBIDO A QUE LA LIBRERA OPENLAYERS, EN LA QUE SE
BASA LA APLICACIN SOS.JS EST ORIENTADA PARA LA
VERSIN SOS 1.0 SE HAN REALIZADO MODIFICACIONES, ESTO
SE DEBE A QUE LA RETRO-COMPATIBILIDAD SOLO SOPORTA
CANTIDAD MNIMA DE TRANSACCIONES PARA SOS 1.0. BASE
DE DATOS
XXVIII.
XXIX.
XXX.
XXXI.
XXXII. 4. LOS DATOS DE ESTACIONES HIDROMETEOROLGICAS
SERN

VALIDADOS AUTOMTICAMENTE, BASNDOSE EN

PASOS DE LA NORMA UNE-50040, LO QUE AYUDARA EN LA

DISCRIMINACIN DE DATOS ANMALOS, FACILITANDO EL PREPROCESAMIENTO DE LOS DATOS AL PERSONAL ENCARGADO.
XXXIII.

EL MANEJO DE ESTE TIPO DE DATOS ES UN TEMA MUY

SENSIBLE,

DADO

QUE

ES

NECESARIO

ASEGURAR

LA

INTEGRIDAD DE ESTOS PARA PODER GENERAR INFORMACIN

CONFIABLE. POR LO QUE ES INELUDIBLE ESTABLECER UN
MTODO AUTOMATIZADO QUE SE ENCARGUE DE ESTO PARA
FACILITAR EL TRABAJO A LAS PERSONAS ENCARGADAS DE
HACER

CONTROL

DE

CALIDAD

ESTAS

PUEDAN

ENCARGARSE DE OTRAS TAREAS DE MAYOR PRIORIDAD.

77

XXXIV.

LOS DATOS RECOGIDOS SON ALOJADOS EN UNA BASE DE

DATOS QUE GRACIAS A SU ESTRUCTURA AYUDA AL MANEJO Y

GENERACIN DE ESTE TIPO DE INFORMACIN, SIN EMBARGO,
ES PRECISO CONTAR CON UN SISTEMA QUE SE ENCARGUE DE
ASEGURAR LA CALIDAD DE LOS REGISTROS, QUE CON
FRECUENCIA SON DUDOSOS.
XXXV. GRACIAS A LA NORMA UNE 500540 SE PUEDEN APLICAR
DISTINTOS MTODOS. DESDE AQUELLOS QUE IMPLICA EL
MANTENIMIENTO PERIDICO DE LAS ESTACIONES Y LA
VERIFICACIN

EN

CAMPO

DE

LA

INFORMACIN

PROPORCIONADA POR LOS SENSORES, HASTA LOS BASADOS

EN LA VALIDACIN DE LOS DATOS REGISTRADOS UTILIZANDO
PROCEDIMIENTOS

ESTADSTICOS,

PASANDO

CALIBRACIN PERIDICA DE LOS SENSORES.

78

POR

LA

XXXVI.

LA NORMA UNE 500540 (2004) DEFINE SIETE NIVELES DE

VALIDACIN LOS CUALES CONVIENEN APLICARSE DE MANERA

CONTINUA, SIN EMBARGO, EL ULTIMO NIVEL SE PUEDE
APLICAR UNA VEZ SE REALIZ LA APLICACIN DE LOS DOS
PRIMEROS NIVELES. LOS DOS PRIMEROS NIVELES SON DE
OBLIGADA APLICACIN, MIENTRAS QUE EL RESTO SON
OPCIONALES.

NICAMENTE

SE

CALIFICAN

DE

FORMA

AUTOMTICA COMO NO VLIDOS AQUELLOS DATOS QUE NO

SUPEREN EL NIVEL 0 O EL TEST DE LMITES RGIDOS. LOS
DATOS QUE NO PASAN CON XITO CUALQUIERA DE LOS
OTROS TESTS SE CONSIDERAN SOSPECHOSOS Y SE DEBER
DISCERNIR SI EL DATO ES VLIDO O NO POR INSPECCIN
VISUAL. POR LO CUAL NOSOTROS DECIDIMOS APLICAR LOS
NIVELES

POR

DOS

MOTIVOS,

PRIMERO

POR

LA

COMPLEJIDAD Y EL POCO TIEMPO EN RELACIONA LAS

DISTINTAS QUE SE TUVIERON QUE REALIZAR Y SEGUNDO,
DADO QUE LOS

NIVELES SUPERIORES AL

1 NO SON

OBLIGATORIOS, DECIDIMOS QUE LOS NIVELES. NO ERA

NECESARIA SU APLICACIN.
XXXVII. NIVEL 0. VALIDACIN DE LA ESTRUCTURA DEL REGISTRO
DE DATOS.
XXXVIII. ESTE NIVEL ES UNO DE LOS MS IMPORTANTES, SE LLEVA
A CABO CON EL PERSONAL DE METEOROLOGA DE INETER,
SIN EMBARGO, LOS PRINCIPALES ENCARGADOS SON ELLOS,
DADO QUE ES TRABAJO DE CAMPO Y SOLO PUEDE SER
LLEVADO A CABO POR LOS ESPECIALISTAS, YA QUE ESTE
NIVEL CONTEMPLA QUE SE COMPRUEBE QUE LA ESTRUCTURA
DEL REGISTRO, AS COMO EL NMERO DE DATOS QUE LLEGO
A LA BASE DE DATOS SEAN LOS QUE SE ESPERABAN.

79

XXXIX.

OTROS DE LOS ASPECTOS A CONSIDERARSE EN ESTE

NIVEL ES LA INTEGRIDAD DEL DATO Y QUE PUEDA SER

MANEJADO SIN NINGN PROBLEMA, AS COMO QUE LA
FECHA/HORA SEAN CORRECTOS PARA EL DATO. DE NO
CUMPLIRSE ESTO, LOS DATOS SON CONSIDERADOS NO
VLIDOS.
XL.
XLI.

NIVEL 1. VALIDACIN DE LOS DATOS SEGN LMITES

XLII. PARA ESTE NIVEL SE TOMAN EN CUENTA DOS TIPOS DE

LMITES: LMITES FSICOS E INSTRUMENTALES Y LIMITES
FLEXIBLES (EFEMRIDES).
XLIII. PARA LOS LMITES FSICOS E INSTRUMENTALES SE HICIERON
REUNIONES PARA DEFINIR EL RANGO PARA CADA UNA DE LAS
VARIABLES METEOROLGICAS TOMADAS EN CUENTAS PARA
ESTE TRABAJO, SIN EMBARGO, ESTO NO QUIERE DECIR QUE
ESTA METODOLOGA SOLO SE PUEDA APLICAR CON ESAS
VARIABLES

METEOROLGICAS,

AL

CONTRARIO,

ESTA

METODOLOGA FUE DESARROLLADA CON UN NIVEL DE

FLEXIBILIDAD PARA QUE SE PUDIERAN CONTEMPLAR MUCHOS
ESCENARIOS, LO CUAL TAMBIN ES SOPORTADO POR LA
NORMA UNE 500540.CUALQUIER VALOR QUE ESTE FUERA DEL
RANGO ESTABLECIDO SE CONSIDERARA COMO NO VALIDO.
XLIV. PARA LOS LIMITES FLEXIFLES SE ESTABLECI UN CONJUNTO
DE EFEMRIDES METEOROLGICAS PARA CADA MES SEGN
EL LUGAR DONDE EST LA ESTACIN, DONDE SE TOMAN MUY
EN CUENTA LOS VALORES EXTREMOS RECOLECTADOS EN LA
ESTACIN DE LA QUE SE EST HABLANDO
XLV.
XLVI.
XLVII.
XLVIII.
80

XLIX.
L.
LI.
LII.
LIII.

LIV.
LV.
LVI.
LVII. RESULTADOS

En este captulo, se presentarn los resultados de cada uno de los pasos

metodologa en el orden en el que fueron descritos. Comenzando los resultados
de la base de datos y las migraciones, se continua con proceso de desarrollo de
software para la recoleccin de los datos, se continua con la validacin de los
datos con la norma UNE; ya una vez validados se contina presentando los
resultados de la habilitacin de interoperabilidad mediante los geoservicios
(WMS, WFS y SOS) as como tambin los resultados del sistema de
presentacin de los datos hidrometeorolgicos con reportes grficos, tabulares y
geogrficos, se finaliza con los resultados del sistema de los reportes FM12 de
las estaciones convencionales y la implementacin de los clientes IDE.
7.1. Base de datos
En esta etapa se seleccion, instal y configuro un gestor de base de datos
espacial PostgreSQL/PostGIS, as mismo se cre una base de datos (BD)
espacial; el esquema de esta BD, est diseado para el almacenamiento de
datos provenientes de sensores, lo cual permitir almacenar todos los datos u
observaciones provenientes de las estaciones telemtricas automticas, as
como de las estaciones convencionales principales.

81

7.1.1 Seleccin del sistema gestor de base de datos

PostGIS/PostgreSQL es considerada la mejor opcin, en comparacin a otros
gestores como Oracle, SQLServer, MySQL. La razn es que posee la mayor
cantidad de tipos geomtricos y mtodos, tiene un almacenamiento eficiente y
tiempo de ejecucin bajo en comparacin con Oracle y SQL Server que tambin
proporcin una cantidad considerable de tipos y mtodos; sin embargo,
SQLServer requiere ms espacio de almacenamiento y por parte de Oracle que
tiene el peor tiempo de ejecucin para las consultas; tambin est el caso de
MySQL que tiene menor cantidad de tipos y mtodos geomtricos (Malinowski,
2014).
En la Tabla 3. Tabla Comparativa de mtodos implementados en sistemas de
gestin de bases de datos espaciales se presenta una tabla comparativa segn
el estndar ISO/IEC 13249-3:2011 SQL/MM,

se puede observar que

PostGIS/PostgreSQL proporciona la mayor cantidad de mtodos (54 mtodos)

segn el estndar ISO/IEC 13249-3:2011 SQL/MM.
Tabla 3. Tabla Comparativa de mtodos implementados en sistemas de gestin de bases de datos
espaciales

Categora
Tipo de geometra

SQL/
ML
18

PostGI MySQ
S
L
9
7

Oracl
e
13

SQLServ
er
9

Mtodos para recuperar propiedades

50

27

13

13

22

Mtodos para crear geometra a partir

de otra

13

Mtodos para crear nueva geometra

vacas

Mtodos para las relaciones

topolgicas

Mtodos para la interoperabilidad

Total de mtodos

82

54

32

37

46

Sistema de referencias espacial

No

Si

No

Si

Si

Fuente: Evaluacin de los sistemas de administracin de bases de datos con extensiones espaciales por
Malinowski, Elzbieta

82

7.1.2 Instalacin y configuracin de gestor de base de base de datos

Segn la documentacin de 52North, para el soporte de SOS en versin 4.0 o
mayor, es necesario tener un servidor PostgreSQL 9 o mayor, en conjunto con
su extensin espacial PostGIS en su versin 2.0 o superior; por lo tanto, se
instal el gestor PostreSQL con su extensin espacial PostGIS, en sus
versiones: PostgreSQL 9.4 y PostGIS 2.1.7 respectivamente (ver seccin de
anexos A.1.1 Versin de gestor de base de datos, se aprecia la versin de
PostGIS instalada y las libreras axilares que implementa).
7.1.3 Creacin de esquema de base de datos espacial
Se cre una base de datos y a la misma se le aadi la extensin espacial
PostGIS, as dar soporte a los tipos geomtricos del esquema de base de datos
de 52North SOS. Posterior a ello se ejecut el script que crea el esquema.
Una vez se ha creado la base de datos, se pueden ver las distintas secciones
que componen la base de datos, segn el visor de bases de datos, en este caso
es PgAdmin; se puede ver que se el esquema tiene las 2 extensiones instaladas,
entre ellas PostGIS, adems de que el esquema tiene un total de 34 tablas de
datos (ver seccin de anexos A.1.2, se muestra la lista de tablas, desde el gestor
de base de datos PostgreSQL).
7.2. Migracin de datos
En esta etapa se desarroll un servicio Windows, el que sincroniza
peridicamente las bases de datos, este servicio se encarga de distribuir los
datos que provienen del esquema XCdata, hacia la base de datos de sensores
genricos, diseada por 52north (52N SOSBD).
7.1.1 Origen de los datos
En esta etapa se utiliz la documentacin que provee SUTROM (c), as como
tambin la inspeccin visual de los datos, con el objetivo de identificar campos
con datos tiles a migrar.
83

Las tablas del esquema XCdata se pueden clasificar en 2 tipos de tablas: (1)
tablas de datos, en las que se almacenan datos de las observaciones
efectuadas por las estaciones y (2) tablas catlogos, en las que se almacenan
configuraciones y metadatos de las estaciones y sus sensores.
La tabla XC_SITES (ver imagen en seccin de anexos A.1.3, captura de pantalla
de parte del contenido de la tabla XC_SITES), almacena los identificadores de
las estaciones (station_id), as como metadatos de la estacin, tales como: hora
y fecha de la ltima trasmisin (last_update), estado (enabled), canal de
trasmisin (satlite_id), entre otros campos. El campo station_id es la clave
primaria de la tabla XC_SITES.
La tabla XC_SITESENSOR (ver imagen en seccin de anexos A.1.4, captura de
pantalla de parte del contenido de la tabla XC_ SITESENSOR), contiene datos
de la estacin y sus sensores; como: el identificador de la estacin
(ste_staion_id), los sensores instalados en la estacin (sensorname), el estado
(enable), el nombre de la tabla donde se almacenan los datos de la estacin
(data_table), ecuacin de decodificacin o conversin, para los datos de satlite
(equation), entre otros. Para las tablas XC_SITES y XC_SITESENSOR, existe
una relacin, en el que el campo ste_station_idde la tabla XC_SITESENSOR,
es una clave fornea, hacia el campo station_id de la tabla XC_SITES
La tabla XC_DATA contiene todos los datos numricos de las observaciones que
realizan los sensores (ver imagen en seccin de anexos A.1.5, muestra de datos
de la tabla XC_DATA), en esta tabla se guarda la fecha y hora del dato, as como
el sensor y la estacin a la que pertenece el dato. Cabe mencionar que a esta
tabla no posee una clave primaria y no existe integridad referencial hacia las
otras tablas de estaciones y sensores.
Se encontr que no existe integridad referencial entre la tabla de datos y las
tablas de sensores y estaciones. En la Imagen 6 se puede apreciar una consulta
en la que se hace coincidir todas las estaciones y sensores registrados en la
tabla de datos (XC_DATA1) contra las estaciones y sensores en la tabla
XC_SITESENSOR, se evidencia que en la tabla XC_DATA1 se han registrado
84

estaciones y sensores, que no estn registrados (celdas de la tabla en blanco)

en la tabla XC_SITESENSOR.

Imagen 6 Carencia de Integridad referencial

Fuente: Elaboracin Propia

Debido que se carece de integridad referencial de la tabla de datos contra las

tablas de sensores y estaciones, la tabla utilizada para extraer datos de la
migracin ser XC_DATA1, de la que se puede obtener: (1) el nombre de la
estacin, (2) el nombre del sensor, (3) hora y fecha u momento en que el sensor
realizo la observacin, (4) valor o resultado de la observacin efectuada por el
sensor; de estos 4 datos se puede conocer, una ubicacin de referencia, el
objeto fsico o medio para utilizado para obtener resultado del sensor, el
momento y el valor medido por el medio fsico, respectivamente.
7.1.2 El esquema de base de datos
En el esquema de base de datos desarrollado por 52north para el servidor SOS
2.0, se identificaron un total de 34 tablas, sin embargo algunas de estas tablas
son usadas para conservar la compatibilidad con el servidor SOS 1.0, por lo
tanto no son relevantes, se identificaron 15 tablas necesarias para almacenar

85

datos y metadatos asociados a sensores (ver seccin de anexos Diagrama de

base de datos 52N SOS).
Las tablas se pueden clasificar en tres grupos: (a) tablas para almacenar
metadatos del estndar, (b) tablas para almacenar metadatos de observaciones,
(c) tablas para almacenar datos las observaciones, a continuacin, se detallan
las tablas de estos grupos.
a) Tablas para almacenar metadatos del estndar
FeatureOfIntesresType: Se utiliza para especificar el tipo geometra de
muestreo, se necesita para clasificar la geometra del FeatureOfIntesres,
es decir, que este metadato describe el tipo de geometra de con la que
describe ser modelado el FeatureOfIntesres.
ProcedureDescriptionFormat: Se utiliza para especificar el estndar de
codificacin del procedimiento, para el caso de estudio se utilizar el
estndar SensorML 2.0.
ObservationType: Se utiliza para especificar el tipo de observacin, segn
el estndar O&M, se pueden utilizar observaciones numricas, de textos,
de categora, booleanas, entre otras.
b) Tablas para almacenar metadatos de observaciones
FeatureOfIntesres: Es un identificador de la caracterstica de inters
descrita como geomtrica de muestreo a la cual se asocia la observacin
[1], el FeatureOfIntesres es la abstraccin de la entidad del mundo real
[8].

Para

el

caso

de

observaciones

hidrometeorologicas,

el

FeatureOfIntesres es la identificacin de la estacin, modelada con un

tipo de geometra de punto (segn O&M: SF_SamplingPoint), este tipo
se asocia a con la tabla FeatureOfIntesresType.
ValidProcedureTime: Se utiliza para especificar el periodo en el que un
procedimiento ha registrado datos, la fecha de inicio corresponder a la
fecha del primer dato del sensor y la fecha final, se especifica cuando el
procedimiento se ha deshabilitado o dado de baja.
86

ObservableProperty: Se utiliza para especificar el fenmeno al cual

corresponden los datos [7]. En el caso de estudio, de estaciones
hidrometeorologicas las propiedades observadas corresponden a las
variables hidrometeorologicas o una clasificacin de los datos emitidos
por el sensor (Procedure).
Unit: Se utiliza para especificar la unidad de medida de los fenmenos
observados, para el caso de estudio de estaciones hidrometeorologicas
existen mltiples unidades de medida tales como: milmetros (mm),
grados centgrados ( C), metros por segundo (m/s), entre otros.
Offering: Se utiliza para especificar la oferta de datos para un sensor, es
de utilidad para agrupar de manera lgica las series de datos y sistemas
de sensores [8].
ObservationConstellation: Se utiliza para relacionar el sensor (procedure),
el fenmeno observado (Observable property), el tipo de observacin
(ObservationType), y la oferta del sensor, con el objetivo de crear una
agrupacin de manera lgica.
Series: Se utiliza para para relacionar el featureofinteres, procedure,
observableproperte, unit, los que corresponde a los metadatos de la
observacin. Para el caso de estudio, en estaciones hidrometeorologicas,
en donde el featureofinteres corresponde a la identificacin de la estacin,
procedure a los sensores que posee la estacin, observableproperte a los
fenmenos que registra el sensor, unit a la unidad de medida del
fenmeno.
c) Tablas para almacenar datos de las observaciones
Observation: Contiene datos de cada observacin, sin embargo no el
valor y smbolo medido, esto se debe a que existen mltiples tipos de
observaciones, por lo tanto cada observacin tendr una relacin 1:1 con
la tabla que alacena el smbolo o valor medido, la tabla Observation
posee una relacin 1:N con la serie, de manera que cada observacin
87

pertenece a una serie. En esta tabla se especifica la fecha de inicio de la

observacin, fecha final, el tiempo que tomo realizar la observacin, la
fecha de validez inicial, la fecha de validez final, adems de otros datos
en el caso de que sea requerido, como el identificador, el nombre y
descripcin de la observacin.
NumericValue: Se utiliza para almacenar el valor nmero de la
observacin, en el caso que el tipo de observacin segn los estndares
de la OGC es OM_Measurement [9], posee una relacin de cardinalidad
1:1 con la tabla Observation. En este tipo de valores estn la temperatura,
radiacin solar, velocidad de viento, entre otros.
CountValue: Se utiliza para almacenar un valor numrico que cuenta
algn fenmeno. Su tipo de observacin segn el estndar es
OM_CountObservation [9], su relacin con la tabla Observation es de
cardinalidad 1:1. Un ejemplo de ello es una propiedad que contara el
acumulado de precipitacin para un periodo de tiempo indefinido.
TextValue: Se utiliza para almacenar un valor textual que cuenta algn
fenmeno.

Su

tipo

de

observacin

segn

el

estndar

es

OM_TextObservation [9], su relacin con la tabla Observation es de

cardinalidad 1:1. Un ejemplo de este tipo de observaciones son los
cdigos Metar utilizados por aeropuertos.
7.1.3 Correspondencia entre origen de datos y esquema destino
En esta sub-etapa, se establecern los datos necesarios para realizar la
migracin del esquema de datos origen, hacia el esquema de datos destino.
Para dar inicio a esta etapa se identificarn los datos necesarios por el esquema
destino, clasificando los tipos de datos en orden requerido por las dependencias
(en parntesis) en base de datos: metadatos del esquema, datos del sensor,
datos de la serie y datos de observaciones.
Metadatos de Observaciones y sensores
1. FeatureOfInterestType
2. ObservationType
88

3. ProcedureDescriptionFormat
Datos del sensor
1.
2.
3.
4.
5.

Procedure
ValidProcedureTime (Procedure)
ObservableProperty
Offering
ObservationConstellation (Offering,ObservableProperty, Procedure)

Datos de la serie
1. FeatureOfInterest (FeatureOfInterestType)
2. Unit
3. Serie (FeatureOfInterest, Procedure, ObservableProperty,Unit)
Datos de observaciones
1. Observation (Serie)
2. NumericValue (Observation)
Para insertar una estacin en la base de datos destino (52N SOSBD), se
requiere definir los siguientes elementos: (1) sitio de inters o ubicacin de la
estacin (2) los sensores que conforman la estacin, (3) los fenmenos que
observa o mide cada sensor instalado en la estacin; estos elementos
corresponden

las

tablas:

(1)

FeatureOfInterest,

(2)

Procedure,

(3)

ObservableProperty de 52N SOSBD.

El Procedure que corresponde al sensor fsico, tiene una relacin 1:1 con la
tabla ValidProcedureTime, en la que se indica el periodo de funcionamiento del
sensor, es decir la fecha inicial y la fecha final. En el caso de que el sensor aun
est en funcionamiento, la fecha final es nula, que significara que el sensor an
no tiene una fecha final.
Para definir el Offering, que es la agrupacin lgica de las observaciones, es
necesario insertar en las tablas Offering y relacionarla con la propiedad
observada y el sensor fsico mediante la tabla ObservationConstallation.
Para insertar las observaciones, es necesario definir la serie y la unidad de
media. La serie relaciona sitio de inters o lugar donde se realiz la observacin
(FeatureOfInterest) en este caso es la estacin, el sensor (Procedure) que
89

efectu la observacin, el fenmeno que observa (ObservableProperty) y la

unidad de medida (Unit). En la observacin se debe de especificar la serie a la
que pertenece la observacin, y la fecha de la observacin, adems la tabla
observation tiene una relacin 1 a 1 con la tabla que almacena el valor de la
observacin dependiendo su tipo, en este caso por tratarse de un valor
numrico, corresponde a la tabla numvalue.
7.1.4 Servicio de migracin automticas
Se desarroll un servicio, sincroniza automticamente las bases de datos,
comprobando cada minuto la cantidad de datos en ambas bases de datos (ver
en seccin de anexos A.2.1. la imagen de la ventana de servicios de Windows),
para las ltimas 12 horas de datos, tomando de referencia el tiempo que registre
la ltima observacin que ingreso en la base de datos de origen; adems
comprueba una vez por semana que los datos de los ltimos 7 das coincidan.
Considerando que la migracin podra ser afectada por un fallo en la red local
(LAN), desperfecto en los equipos, entre otros, se considera, sincronizar las
ltimas 12 horas de datos, a esta media de contingencia, se aade el comprobar
los ltimos 7 das una vez por semana.
A continuacin, en Imagen 7 se muestra una consulta SQL, con el objetivo de
conocer la cantidad de datos por estacin o FeatureOfInteres, para un periodo
especificado; en la imagen se presenta la base de datos origen (izquierda) y la
base de datos destino (derecha); en el resultado de ambas consultas aprecia
que ambas bases de datos tienen cantidades de datos por estacin iguales.

90

Imagen 7 Consultas compara la cantidad de datos en la bases de datos

Fuente: Elaboracin Propia

7.3. Resultados

del

Sistema

para

la

recoleccin

de

datos

hidrometeorolgicos de las estaciones convencionales.

A continuacin, se presenta a detalle el desarrollo del sistema de recoleccin de
datos de las estaciones convencionales, as como sus resultados.
7.3.1.
7.3.2. Levantamiento de Requerimientos
Para el desarrollo del sistema, se obtuvieron una serie de requerimientos
funcionales y no funcionales que se obtuvieron mediante entrevistas al personal
involucrado, as como la observacin del proceso de llenado de la hoja de
observacin hora a hora.
En los requerimientos funcionales resaltaba con importancia que esteel sistema
debe ser visto de manera responsiva en tablets considerando que en el futuro,
como proyecto de la institucin, se pretende brindar una Tablet a cada estacin
convencional de manera que el observador al realizar el proceso de observacin
ingrese los datos directamente en el sistema y esta de manera casi instantnea
se almacene a la base de datos.
91

Una vez almacenada la informacin de las estaciones convencionales, esta ser

compartida de manera inmediata con las reas correspondientes a revisar,
enviar y procesar esta informacin para la generacin de conocimiento y
pronsticos.
A continuacin, se muestran los requisitos funcionales y no funcionales:
Requerimientos Funcionales:
RF1: Maquetacin responsiva para visin en tablets.
RF2: Login segn rol y estacin.
RF3: Crear observacin segn rol.
RF4: Almacenar todas las variables de la hoja de observacin.
RF5: Visor de observaciones para el rea de sinptica y aeronutica.
RF6: Reportes grficos de series temporales de precipitacin y temperatura.
Plantillas de Requerimientos Funcionales
Tabla 4 Requerimiento - Maquetacin responsiva para visin en tablets.

Maquetacin responsiva para visin en tablets (RF1)

Requisito
Complejidad
Prioridad
Descripcin

RF1
Media
Alta
El sistema permitir la visualizacin adecuada del sistema en
dispositivos tablets para el futuro uso de estas en cada uno de las

Proceso
Entrada
Salida

estaciones.
Ingresar al sistema con sus credenciales(Usuario y Contrasea)
Credenciales(Usuario y Contrasea)
Pgina de inicio del sistema
Fuente: elaboracin propia

Ver en el anexo A.3.5 el resto de las plantillas requerimientos funcionales

92

Requerimientos No Funcionales
RNF1: Fiabilidad
RNF2: Tiempo de Respuesta
RNF3: Seguridad
RNF4: Mantenibilidad
RNF5: Usabilidad
Plantillas de Requerimientos No Funcionales
Tabla 5 Requerimiento - Fiabilidad

Fiabilidad (RNF1)
Requisito
Complejidad
Prioridad
Descripcin

RNF1
Media
Alta
El sistema deber tener la capacidad para operar segn lo
previsto en presencia de fallos hardware o software, as
como, recuperar los datos directamente afectados y
reestablecer el estado deseado del sistema en caso de

Proceso
Entrada
Salida

interrupcin o fallo (iso2500, 2015) .

Desarrollo del sistema
Desarrollo del sistema.
Sistema.
Fuente: elaboracin propia

Ver en el anexo A.3.6 el resto de las plantillas requerimientos funcionales

7.3.3. Modelado de los requerimientos.
El xito de un sistema o producto basado en computadora se mide de muchas
maneras, la satisfaccin del usuario ocupa el primer lugar de la lista (Pressman,
2010).
Si se entiende cmo desean interactuar los usuarios finales (y otros actores) con
el sistema entonces, el modelado de los requerimientos con UML comienza con
la creacin de escenarios con casos de uso, diagramas de actividades entre
otros.

93

Tomando en cuenta lo antes mencionado, el segundo paso consta del modelado

de requerimientos del sistema de recoleccin de variables meteorolgicas
mediante diagramas UML.
A continuacin, los diagramas que se utilizaron para el modelado del sistema:

Casos de uso
Diagrama de clases
Diagrama de Secuencia
Diagrama de Paquetes

Casos de uso
Un caso de uso capta las interacciones que ocurren entre los productores y
consumidores de la informacin y el sistema en s. En la siguiente imagen se
muestra el caso de uso general de la funcionalidad del sistema de recoleccin
de datos meteorolgicos. (Pressman, 2010)
En la Imagen 7 se observa el caso de uso general del sistema con los diferentes
actores que sern los futuros usuarios que utilizaran el sistema.

Imagen 8. Caso de uso de la funcionalidad del Sistema

Fuente: Elaboracin Propia

94

A continuacin, se enumeran y describen todos los casos de usos de los

requerimientos previamente definidos.
1. Crear observacin segn rol
El sistema permitir crear la observacin segn el rol y estacin del usuario en
sesin. Si el rol es observador, la observacin ser creada para Managua, si es
control de calidad se crean n-1 observaciones, siendo n la cantidad de
estaciones convencionales en Nicaragua.
Usuario deber registrarse para crear la observacin, la cual se generar segn
el rol.
2. Editar observacin con las variables correspondientes al periodo y la
estacin.
El usuario observador podr editar la observacin previamente creada, donde
podr llenar las variables de la hoja de observacin segn su periodo.
3. Gestin de usuarios
El sistema permitir crear usuarios y asignar roles al administrador del sistema.
4. Visualizar observaciones
Las reas sinptica y aeronutica podrn visualizar los Metars de las
observaciones, mas no podrn editarlas.
5. Ver Diagramas de temperatura y precipitacin.
El sistema permitir ver reportes grficos de series temporales de temperatura
y precipitacin al administrador del sistema.
6. Gestin de Catlogos
El Sistema permitir a los usuarios administradores la gestin completa de los
catlogos que conforman la observacin los cuales son:

Periodos
Clasificacin de Nubes
95

Tipos de Nube
Clasificacin de Fenmenos
Tipos de Fenmenos
Variables
Estaciones
Usuarios

Ver casos de uso en anexo A.3.2.

Diagrama de Paquetes
Con el siguiente diagrama se muestran los principales segmentos de
funcionalidad del sistema, donde cada paquete representa los grupos que
contienen elementos, con el propsito de ayudar a organizar estos elementos
para poderlos comprender fcilmente.
Ver diagrama de paquetes en anexo A.3.4.
Diagrama de Secuencia
Los diagramas de secuencia, indican la forma en la que los eventos provocan
transiciones de un objeto a otro; muestra los objetos que intervienen en el
escenario con lneas discontinuas verticales, y los mensajes pasados entre los
objetos como vectores horizontales15.
En el caso del sistema de recoleccin de variables meteorolgicas, los objetos
se obtuvieron del anlisis de los casos de uso previamente realizados, por lo
tanto, ya que cada uno de estos representa un escenario del sistema, se realiz
un diagrama de secuencia a manera de representar el modo en que los eventos
causan el flujo de un objeto a otro, as permite tener otra visin de la
funcionalidad del sistema.
Ver diagrama de secuencia en anexo A.3.3.
Diagrama de clases
El diagrama de clases, representa los objetos que manipulara el sistema. Las
clases presentadas en el diagrama se identificaron mediante el anlisis de los

15 Popkin Software and System. Modelado de Sistemas con UML.

96

escenarios de casos de uso desarrollados como parte del modelado de

requerimientos. (Pressman, 2010)
Ver diagrama de clases en anexo A.3.1.
7.3.4. Pruebas y Resultados
Pruebas
Probar es el proceso de ejecucin del software con la intencin de descubrir
errores en el contenido, funcin, utilidad, navegabilidad, rendimiento, capacidad
y seguridad de esa aplicacin (y a final de cuentas corregir) errores 16.
Basado en lo mencionado en el prrafo anterior, se realizar las pruebas de
navegacin, usabilidad, accesibilidad, seguridad y rapidez de acceso al SIMET,
estas pruebas se realizaron basadas en libro de Ingeniera de Software un
Enfoque Prctico y con el auxilio de el sitio web Gua Digital (Digital &
Presidencia, n.d.).
Prueba de usabilidad
Tabla 6. Prueba de Usabilidad SIMET

Conceptos de usabilidad
Identidad Corporativa
1.
La portada del Sitio refleja la identidad y
pertenencia de la institucin?
2.
Existen elementos de la imagen
corporativa del Gobierno en la Portada de su
Sitio? Se repiten en todas las pginas?
3.
El logotipo del Gobierno ha sido incluido
en un lugar importante en la Portada y en las
pginas interiores del Sitio?
4.
Todas las pginas cuentan con un ttulo
que indique el nombre de la institucin e
informacin de contactos virtuales y fsicos al pie
de la pgina?
Navegacin

Cumple Comentarios
u
Si No observaciones
X
X
X
X

Comentarios

observaciones
1.
El diseo del Sitio es eficiente, rpido e
intuitivo?

16 Roger S. Pressman, Ingeniera de Software un Enfoque Prctico, McGrawHill, pgina 453.

97

2.
Aparece el men de navegacin en un
lugar destacado? Se ve fcilmente?
3.
Verific la consistencia de todos los
enlaces?
4.
El Sitio cuenta con un mapa o buscador
que facilite el acceso directo a los contenidos?
5.
El Sitio mantiene una navegacin
consistente y coherente en todas las pantallas?
Consistencia y cumplimiento de estndares

X
X
x
X
Comentarios

observaciones
1.
El HTML del Sitio ha sido validado
satisfactoriamente segn w3c.org?
2.
El Sitio Web diferencia entre enlaces
visitados y enlaces por visitar?
3.
Comprob la consistencia de Links
usando el verificador de w3c.org?
Esttica y diseo

x
X
x
Comentarios

observaciones
1.
Usa jerarquas visuales para determinar
lo importante con una sola mirada?
2.
Las imgenes tienen tamaos
adecuados que no dificultan el acceso a las
pginas?
3.
Las imgenes tienen etiqueta ALT en el
cdigo HTML para facilitar la navegacin?
Atencin de errores

1.
Usa JavaScript para validar formularios
durante su llenado y antes de enviarlos?
2.
Usa elementos destacados para indicar
los campos obligatorios dentro de un formulario?
3.
Despus de que ocurre un error, es fcil
volver a la pgina donde se encontraba antes
que se produjese o entrega recomendaciones
de los pasos a seguir?
Ayuda ante errores

1.
En caso de errores de consistencia
dentro del sitio, se ofrece un mensaje de
personalizado mediante una pgina explicativa?,
(Por ejemplo: Error 404 para pgina inexistente)
2.
Entrega informacin de contacto fuera
de Internet? (Por ejemplo: telfono institucional,
fono 600, mesa de ayuda, OIRS)
3.
Ofrece rea de Preguntas Frecuentes
con datos de ayuda a usuarios?
4.
Ofrece pginas de ayuda que explican
cmo usar el Sitio?

X
x
Comentarios

observaciones
X
X

Comentarios
observaciones

98

X
X
x

Retroalimentacin (Feedback)

Comentarios

observaciones
1.
Puede el usuario ponerse en contacto
con el encargado del Sitio Web para hacer
sugerencias o comentarios?
2.
Funcionan correctamente los
formularios de contacto?, Ha probado cada
uno de ellos?
3.
Hay alguien encargado de recibir y
contestar estos mensajes?

X
X
X

Fuente: elaboracin propia

Ver las dems pruebas en anexo A.3.7.

Resultados
A continuacin, se muestras las imgenes del resultado del SIMET basado en
los requerimientos obtenidos en la fase de ingeniera de software del desarrollo
del sistema:
Uno de los requerimientos funcionales que los usuarios del sistema de
recoleccin de datos hidrometeorolgicos de las estaciones convencionales, fue
que la observacin se creara de acuerdo al rol que el usuario que estaba
logueado en ese momento.
En la Imagen 9 se muestra el formulario para crear la observacin (como usuario
observador), donde se ingresa el cdigo Metar/Sinop y las variables principales
requeridas por presidencia (Direccin del Viento, Velocidad del Viento,
Temperatura Seca y Precipitacin).

99

Imagen 9.Crear Observacin como observador

Fuente: Elaboracin Propia

En la Imagen 10 se presenta en el catlogo de observaciones en orden

descendente (la primera es la ltima creada) con todas las opciones posibles a
aplicar a la observacin, tales como: ver detalle
observacin

y eliminar

, editar

, editar la hoja de

(solo con permiso de administrador) luego se

edita la hoja de observacin de esta observacin.

100

Imagen 10. Catlogo de Observaciones del Observador

Fuente: Elaboracin Propia

7.4. Resultados de la Validacin automtica de los datos de estaciones

hidrometeorolgicas.
En esta etapa se validaron los datos de precipitacin de las estaciones
meteorolgicas automticas, se aplicaron pruebas de lmites, adems de
mtodos estadsticos establecer lmites flexibles (o dinmicos), adaptados a las
condiciones climatolgicas de la regin; los limites flexibles sern usados para
identificar los registros de precipitacin con valores sospechosos.
Datos
Los datos a validar corresponden a las estaciones meteorolgicas automticas,
cuyo intervalo de medicin es de 15 minutos, resultando 107 estaciones que
trasmitieron un total de 12,362,528 registros de precipitacin; en un periodo de
aproximadamente 14 aos, que inicia desde el 2004 hasta parte del ao 2016.
La mayor parte de estaciones, se encuentra ubicada en la regin pacfico y
central-norte del pas (Vase seccin de anexos A.4.1). Las estaciones tienen un
intervalo entre medidas de 15 minutos, para la variable de precipitacin.
101

Nivel 0: Estructura del registro de datos

Los registros de las estaciones meteorolgicas automticas, siguen un proceso
que garantiza que los datos que se persisten en la base de datos, corresponden
a los datos tal como los observo o midi el sensor de la estacin. El proceso que
sigue cada registro de datos costa de 6 etapas, desde la observacin que realiza
el sensor, hasta la persistencia en la base de datos; a continuacin, se enumera
cada etapa y se muestra una imagen que representa el proceso que siguen los
datos:
1.
2.
3.
4.

Sensor de la estacin realiza la observacin o medicin.

Estacin trasmite los datos hacia el satlite (GOES 12)
El satlite enva los datos hacia la antena receptora ubicada en INETER.
El receptor satlite convierte la seal anloga en archivos (crudos) y los

almacena en un directorio de archivos.

5. Un software decodificador consume los archivos desde el directorio y
almacena temporalmente una copia del archivo ya decodificado.
6. El archivo decodificado, es consumido por un software que ingresa los
registros en la base de datos.

Imagen 11 Proceso de los datos de las estaciones meteorolgicas automticas

Fuente: Elaboracin Propia

Algunas de las etapas antes mencionadas funcionan de manera inherente

para controlar que no existen errores en la trasmisin del dato.

102

a.Convertir el archivo de la seal anloga a un archivo decodificado

(etapa 5 de registro de datos), implica que solo los datos correctos podrn
convertirse; por ello los datos que presentaron fallos no pasaran por esta
etapa.
b.

Al convertir los archivos decodificados

a su estructura SQL para

su ingreso a la base de datos, se asegura que los todos los datos se

encuentren completos (etapa 6 de registro de datos), en el caso de que algn
dato falte, el gestor generara cdigo error.
c.

Una vez los datos llegan a la base de datos (BD), la misma BD

validara que los datos y sus tipos de datos (etapa 6 del registro de datos),
coinciden con los definidos en la BD, por ello, algn error en los datos no
ser persistido en la BD.
Nivel 1: Limites
A) Limites rgidos
Se estableci lmite mximo de precipitacin, basndose en la mxima
precipitacin en 15 minutos, registrada por la NOAA a nivel mundial, de manera
que cualquier valor de precipitacin superior al registro que tiene la NOAA, se
considera errneo.
El mximo valor registrado por la NOAA es de 198mm en 15 minutos, fue
registrado en Jamaica (NOAA, s.f.); por lo tanto, todos aquellos valores de
precipitacin superiores a 198 milmetros (mm), no pasaran la prueba de lmites
rgidos.
Al aplicar los limites rgidos, se encontraron 42,179 registros de precipitacin no
vlidos, correspondientes al 0.034% sobre el total de datos registrado. En la
Imagen 12 se presenta un histograma de los valores registrados superiores a
192mm en 15 minutos, se puede apreciar, que a medida que los valores de
precipitacin son ms altos, la frecuencia de estos valores disminuye.

103

Imagen 12 Histograma de registros no validos en la prueba de limites rigidos

Fuente: Elaboracin Propia

Considerando que los niveles de la norma UNE 500540 deben de aplicarse en

orden secuencial, es decir, solo los datos que superen la prueba de lmites
rgidos, podrn ser considerados para aplicarle la prueba de lmites flexibles. Por
lo tanto 12, 320,349 registros de precipitacin, superan la prueba de lmites
rgidos, correspondientes al 99.66% sobre el total registros.
B) Limites flexibles
Segn la norma UNE 500540, los limites flexibles, pueden ser considerados
valores extremos de una zona determinada, por ello, la direccin general de
meteorologa (DGMET) del INETER, establece 7 sub-regiones de referencia,
cada sub-regin presenta su propio comportamiento climtico. En la Imagen
13 se pueden apreciar cada sub regin coloreada en color marrn, dividida
por la traza negra, en esta imagen se puede apreciar que el pacifico de
Nicaragua se sub-divide en 3: pacifico norte, pacifico centro, pacifico sur; la
regin central se sub-divide en 2: central norte y central sur: mientras que la
regin caribe, se mantiene la sub-divisin de las regiones autnomas. Los
crculos azules, representan las estaciones meteorolgicas automticas con
periodicidad de 15 minutos.
104

Imagen 13 Sub regiones de referencia

Fuente: Elaboracin Propia

Una vez fueron establecidas las zonas u regiones donde se encuentra la

estacin, es necesario considerar un valor mximo extremo, para cada mes y
regin, este valor ser utilizado como un umbral, discriminado valores atpicos.
En la Imagen 14 se muestra una grfica de lneas, los valores verticales
representan el umbral aceptable de precipitacin, mientras que los horizontales
son los meses (12); cada lnea, representa una sub-regin, y sus valores de
umbrales de precipitacin aceptables para esta prueba.

105

Central Norte

Central Sur

RAAN

Pacifico Norte

Pacifico Centro

Pacifico Sur

RAAS

140
120
100
80
60
40
20
0

10

11

12

Imagen 14 Lmites flexibles basados en estadsticas

Fuente: Elaboracin Propia

En la prueba de lmites flexibles se consideraron 12, 320,349 registros de

precipitacin; de los que una cantidad de 12, 316,407 se consideran vlidos,
mientras que 12,365 son considerados anmalos para esta prueba.
En la Imagen 15, se muestra un histograma, de los valores considerados
anmalos en la prueba de lmites flexibles, se puede apreciar que la mayor parte
de los registros son superiores a 100mm en 15 minutos; sin embargo, tambin
se aprecian registros con valores menores a 50mm en 15 minutos, esto se debe
a que los lmites mximos admitidos, estn variando su valor mximo en
dependencia al mes y la regin.

106

Imagen 15 Histograma de datos no validos en prueba de lmites flexibles

Fuente: Elaboracin Propia

8.
8.1. Resultados

HabilitarHabilitacin

de

lL

interoperabilidad

ser

habilitada basadao en estndares OGC e ISO 19100.

En esta etapa se presentan los resultados de habilitar los servicios web
estndares, se implementaron dos servicios para el acceso a datos, tanto
resultado vectorial (WFS) en formato GML, de series temporales de
observaciones (SOS); y un servicio para la visualizacin de datos en mapas
(WMS).
8.1.1. SOS
Al realizar consulta a servidor SOS se deben especificar mltiples parmetros,
que son definidos por la estructura de O&M, un ejemplo es al ejecutar la funcin
GetObservacion (ver seccin de anexos A.5.1), en la que se quiere obtener
una observacin, para ello en l, se especifica: el sensor (Procedure), la variable
(ObservedProperty), un intervalo de tiempo (TemporalFilter), la estacin

107

(FeatureOfInterest) y el formato de respuesta que en este caso es

http://www.opengis.net/om/2.0 el que corresponde a la especificacin O&M 2.0
La Imagen 16 es la respuesta de una peticin GetObservation, la observacin
(OM_Observation) esta descrita en formato O&M 2.0, en esta observacin se
aprecia el identificador de dicha observacin (identifier), este contiene los datos
codificados de la serie temporal, bajo la restriccin de que solo puede existir un
elemento por variable de la estacin para un momento determinado; posterior se
especifica el tipo observacin (type), para este caso es OM_Mesurement
correspondiente a un nmero con unidad de medida, posterior se muestra el
instante en que fue realizada la observacin (phenomenonTime) este es descrito
en formato estndar GML, despus se muestra el sensor que realizo la
observacin (procedure) seguido de la variable (observedProperty), continua con
el identificador de la estacin (feaatureOfInterest), al final se muestra el
resultado de la observacin(result) corresponde un valor numrico (1.5) y su
unidad de medida(m/s).

Imagen 16 Respuesta de servidor SOS a la peticin de una observacin

Fuente: Elaboracin Propia

8.1.2. WMS
De la consulta de prueba que se seleccion para ser publicada se obtuvo
lo siguiente:

108

http://localhost:8080/geoserver/IDEIneter/wms?
service=WMS&version=1.1.0&request=GetMap&layers=IDEIneter:lluvia_
12h&styles=&bbox=-87.1672210693359,10.7908334732056,83.0630111694336,14.7441663742065&width=512&height=493&srs=EP
SG:41001&format=application/openlayers

Imagen 17. Resultado GetMap del WMS

Fuente: Elaboracin Propia

Analizando el resultado en la Imagen 17 se observa que es un servicio WMS

(http://localhost:8080/geoserver/IDEIneter/wms?service= WMS) y la operacin es
un GetMap (request=GetMap) una de las operaciones, sino las ms utilizada en
el servicio WMS la cual permite al usuario seleccionar la extensin geogrfica,
tamao de la imagen, el formato en que la imagen se va a generar, el
sistema de referencia de coordenadas, entre otros.
Seguido del nombre de la capa, el nombre de la consulta, vista o shape ,
adicionando luego los limites , el tamao y la altura de la imagen as como el
formato en que es presentado el request , ya que GeoServer permite generar en
ms de un formato el WMS ya sea PNG, GIF, JPEG, KML entre otros.

109

Al seleccionar un punto del resultado del GetMap automticamente se realiza la

operacin GetFeatureInfo que es otra de las operaciones del WMS que da como
resultado los metadatos del punto en cuestin en forma de tabla a como se pude
observar en la imagen anterior (Imagen 13).
El resultado de la operacin GetMap del WMS, ser consumido por un visor que
ser explicado en los siguientes captulos de este trabajo.
Adicionalmente, en GeoServer se pueden agregar estilos a las capas los cuales
se programan con SLD, que es una extensin del WMS que permite a los
usuarios utilizar estilos de simbolizacin propios, permitiendo definir cmo se va
a representar la IG a travs de la web (Lopez-Vasquez, Fundamentos de las
infraestructura de datos espaciales (IDE), 2012).
8.1.3. WFS
El WFS tiene como objetivo proporcionar al usuario datos geogrficos discretos
(geometras y atributos) para que pueda utilizarlos y manipularlos segn sus
necesidades (Lopez-Vasquez & Bernabe-Poveda, 2012).
En las siguientes imgenes se observaran los resultados del servicio WFS con
dos de sus principales operaciones:

GetFeature
GetCapabilities

De la consulta de prueba que se seleccion para ser publicada se obtuvo lo

siguiente:

GetFeature

http://localhost:8080/geoserver/IDEIneter/ows?
service=WFS&version=1.0.0&request=GetFeature&typeName=IDEIneter:lluvia_
12h&maxFeatures=10

110

Imagen 18. Resultado WFS GetFeature

Fuente: Elaboracin Propia

Analizando el resultado de la Imagen 18, en la primera parte del link se

especifica el tipo de servicio al cual se est realizando la peticin
(http://localhost:8080/geoserver/IDEIneter/ows?service= WFS ) seguido de eso la
versin y luego la peticin donde especifica la operacin que desea realizar, en
este caso es GetFeature (request=GetFeature), la cual devuelve una coleccin
de objetos geogrficos previamente almacenados en el servidor en funcin de la
consulta; como ltimos parmetros se especifica el typeName que es el recurso
al cual se va a consultar que se escribe el espacio de trabajo seguidos de dos
puntos(:) la consulta, vista o tabla de la base de datos. Adicionalmente esta la
propiedad maxFeatures con la cual se puede limitar la cantidad de registros
devueltos en la consulta; El resultado de esta operacin regresa los datos
geogrficos de forma vectorial, codificados en GML

DescribeFeatureType

111

http://localhost:8080/geoserver/IDEIneter/ows?
service=WFS&version=1.0.0&reques=DescribeFeatureType

Imagen 19. Resultado WFSDescribeFeatureType

Fuente: Elaboracin Propia

En la Imagen 19 se observa el resultado de la operacin DescribeFeatureType

la cual tiene como funcin mostrar la estructura del el/los Feature(s) (consultas,
tablas o vistas) publicados en el espacio de trabajo al cual se est consultando,
en este caso los mostrados son lluvia_12h, lluvia_1h, lluvia_72h.
8.2. Resultados del anlisis y Sistema para presentacin de datos
hidrometeorolgicosdesarrollo del sistema de presentacin de
datos hidrometeorolgicos.
Como resultado de la metodologa aplicada se obtuvieron una serie de
elementos que dan como producto la presentacin de los datos tratados en las
etapas anteriores. Estos elementos se detallan a continuacin.
8.2.1. Levantamiento de requerimientos.
Como primera etapa definida en la metodologa, se realiz un proceso de
ingeniera de software, donde se realizaron reuniones con el personal de la

112

DGMET que estar directamente relacionado con la informacin generada, para

entender el giro de negocio y sus necesidades.
Durante estas reuniones se captaron los requerimientos funcionales y no
funcionales en los cuales sobresala la necesidad de acceso a la informacin de
una manera rpida y en distintas perspectivas (Datos tabulados, mapas,
grficos) para agilizar los procesos de generacin de informacin, adems, que
estos datos fueran accesibles desde cualquier punto sin la necesidad de
instalacin de ningn software.
Otro punto importante que se requiere en este sistema es que presente distintos
niveles de acceso en los cuales se restringiera a un grupo de usuarios al acceso
a solamente los datos que se requera, haciendo una vista ms ligera de la
informacin y a su vez una mejor proteccin de los datos.
Adems de lo anterior mencionado se requiero que todos los datos mostrados
en la aplicacin en distinta perspectiva fuesen fcilmente exportables en
distintos formatos para su difusin y generacin de reportes ms personalizados
por parte de los usuarios del sistema.
A continuacin, se detallan cada uno de los requerimientos funcionales y no
funcionales recolectados en las sesiones de trabajo con el personal de la
DGMET
8.2.1.1.
RF1:

Requerimientos funcionales.

Visualizacin

espacio-.temporal

del

comportamiento

de

variables

hidrometeorologicashidrometeorolgicas.
RF2: Visualizar reportes tabulares con distintos niveles de agregacin y clculos
estadsticos.
RF3:

Visualizacin

de

series

temporales

de

las

variables

hidrometeorologicashidrometeorolgicas.
RF4: Permitir la comparacin de series temporales de las estaciones
hidrometeorologicashidrometeorolgicas.
113

RF5:

Visualizar

geogrfica

de

las

estaciones

hidrometeorologicashidrometeorolgicas.
RF6: Capacidad de exportar datos de cada sensor en formatos: CSV, Excel,
PDF, Word.
8.2.1.2.

Plantillas de requerimientos funcionales

Tabla 7 Requerimiento - Visualizacin espacio-temporal del comportamiento de variables

hidrometeorolgicas.

Visualizacin

espacio-.temporal

del

comportamiento

de

variables

hidrometeorologicashidrometeorolgicas (RF1)
Requisito
RF1
Complejidad
Alta
Prioridad
Alta
Descripcin
El sistema permitir la visualizacin de rasters correspondiente a
los parmetros que especifique.
El usuario seleccionara los parmetros de inters
Variable hidrometeorolgica

Proceso
Entrada

Regin (Agrupacin geogrfica)

Rango de fechas de inters (Limitacin temporal)
Nivel de agregado (Mensual, Semanal, Diario, Horario)
Serie temporal de rasters resultados de interpolacin espacial

Salida

Fuente: Elaboracin propia.

Para ver las dems plantillas ir a A.6.4

8.2.1.3.

Requerimientos no funcionales

Para ver las plantillas de requerimientos no funcionales ir a A.3.6

8.2.2. Modelado de los requerimientos.
En esta etapa se requiri elaborar una serie de diagramas y platillas para tener
la documentacin necesaria para facilitar el anlisis y ejecucin del desarrollo de
cada elemento contemplado para esta parte de la plataforma, dado que esto
facilitara la implantacin de la misma y que a su vez sea escalable y mantenible.
A continuacin, se presentan los diagramas que se utilizaron para el modelado
de este sistema:

114

Casos de uso
Diagrama de clases
Diagrama de Secuencia
Diagrama de Paquetes
8.2.2.1.

Casos de uso

Los casos de uso sirven para describir la interaccin entre los usuarios y el
sistema. En la siguiente imagen se muestra el caso de uso general de la
funcionalidad del sistema de la presentacin de datos meteorolgicos.
En la Imagen 20 se observa el caso de uso general del sistema con los
diferentes actores que sern los futuros usuarios que utilizarn el sistema.

Imagen 20 Diagrama de caso de uso del sistema de presentacin de datos hidrometeorolgicos.

Fuente: Elaboracin Propia

Para ver los dems casos de uso ir a A.6.2

8.2.2.2.

Diagrama de Paquetes

Con este diagrama se presenta la funcionalidad de cada uno de los paquetes del
sistema, donde cada paquete representa grupos que contienen elementos,

115

siendo su propsito ayudar a organizar estos elementos para comprenderlos

fcilmente.

116

Imagen 21 Diagrama de paquetes

Fuente: Elaboracin Propia

117

8.2.2.3.

Diagrama de Secuencia

Los diagramas de secuencia muestran la interaccin de un conjunto de objetos

en una aplicacin a lo largo del tiempo. Estos diagramas son importantes porque
detallan a los casos de uso, clarificndolos a nivel de mensajes de los objetos
existentes, as como tambin muestran la interaccin entre las clases diseadas.
Para ver los diagramas de secuencia ir a A.6.3
8.2.2.4.

Diagrama de clases

Con el diagrama de clases se representan los objetos que manipulara el

sistema. Este diagrama es resultado que se obtuvo mediante el anlisis de los
escenarios de casos de uso desarrollados como parte del modelado de
requerimientos. (Pressman, 2010)
8.2.3. Pruebas y Resultados
Pruebas
A continuacin, se muestran las pruebas realizadas con la intencin de encontrar
errores en el contenido, funcin, utilidad, navegabilidad, rendimiento, capacidad
y seguridad de esta parte de la plataforma.
Tabla 8 Pruebas de usabilidad del sistema de presentacin de datos hidrometeorolgicos

Conceptos de usabilidad
Identidad Corporativa

Cumple
Si
No

1.

La portada del Sitio refleja la identidad y

pertenencia de la institucin?
2.
Existen elementos de la imagen corporativa del

Comentarios u
observaciones

Gobierno en la Portada de su Sitio? Se repiten en todas

las pginas?
3.
El logotipo del Gobierno ha sido incluido en un

lugar importante en la Portada y en las pginas interiores

del Sitio?
4.
Todas las pginas cuentan con un ttulo que

indique el nombre de la institucin e informacin de

contactos virtuales y fsicos al pie de la pgina?
Utilidad de la aplicacin web

Si

No

Comentarios u
observaciones

El Sitio ofrece informacin sobre las actividades y

servicios ms recientes e importantes que est

118

llevando a cabo la institucin?

Los usuarios pueden encontrar fcilmente en la

portada la informacin acerca de las actividades y

servicios ms importantes de la institucin?
Navegacin

Si

No

Comentarios u
observaciones

1.
2.

El diseo del Sitio es eficiente, rpido e intuitivo?

Aparece el men de navegacin en un lugar

destacado? Se ve fcilmente?
3.
Verific la consistencia de todos los enlaces?
4.
El Sitio cuenta con un mapa o buscador que

X
X
X
X

facilite el acceso directo a los contenidos?

5.
El Sitio mantiene una navegacin consistente y

coherente en todas las pantallas?

Consistencia y cumplimiento de estndares

Si

1.

No

Comentarios u
observaciones

El HTML del Sitio ha sido validado

satisfactoriamente segn w3c.org?

2.
El Sitio Web diferencia entre enlaces visitados y

enlaces por visitar?

3.
Comprob la consistencia de Links usando el

verificador de w3c.org?
Esttica y diseo

Si

1.

Usa jerarquas visuales para determinar lo

importante con una sola mirada?

2.
Las imgenes tienen tamaos adecuados que no

No

Comentarios u
observaciones

dificultan el acceso a las pginas?

3.
Las imgenes tienen etiqueta ALT en el cdigo

HTML para facilitar la navegacin?

Atencin de errores

Si

1.

No

Comentarios u
observaciones

Usa JavaScript para validar formularios durante

su llenado y antes de enviarlos?

2.
Usa elementos destacados para indicar los

campos obligatorios dentro de un formulario?

3.
Despus de que ocurre un error, es fcil volver a

la pgina donde se encontraba antes que se produjese o

entrega recomendaciones de los pasos a seguir?
Ayuda ante errores

Si

1.

No

Comentarios u
observaciones

En caso de errores de consistencia dentro del sitio,

119

se ofrece un mensaje de personalizado mediante una

pgina explicativa?, (Por ejemplo: Error 404 para pgina
inexistente)
2.
Entrega informacin de contacto fuera de

Internet? (Por ejemplo: telfono institucional, fono 600,

mesa de ayuda, OIRS)
3.
Ofrece rea de Preguntas Frecuentes con datos

de ayuda a usuarios?
4.
Ofrece pginas de ayuda que explican cmo usar

el Sitio?
Retroalimentacin (Feedback)

Si

No

Comentarios u
observaciones

1.

Puede el usuario ponerse en contacto con el

encargado del Sitio Web para hacer sugerencias o

comentarios?
2.
Funcionan correctamente los formularios de

contacto?, Ha probado cada uno de ellos?

3.
Hay alguien encargado de recibir y contestar

estos mensajes?
Fuente: Elaboracin propia.

Para ver las dems pruebas ir a A.6.5

Resultados
A continuacin, se muestras las imgenes del resultado de Caelus basado en los
requerimientos obtenidos en la fase de ingeniera de software del desarrollo del
sistema:
En el sistema podemos observar en la Imagen 22 los mens a los cuales el
usuario segn su rol, tiene acceso y la pantalla principal del sistema.

120

Imagen 22 Pgina principal de Caelus

Fuente: Elaboracin Propia

Los mens disponibles para esta parte de la plataforma estn descritos en la

siguiente tabla.
Tabla 9 Mens del sistema de presentacin de datos hidrometeorologicos

Men

Descripcin
En este men desplegable podemos encontrar sub tems
donde podemos seleccionar el reporte de preferencia,
entre los cuales podemos encontrar:
Tabulares agregados, tabulares raw, reportes grficos,
reportes de las estaciones y reportes de mapas de lluvia.
En el men de administracin podemos realizar la
administracin de las estaciones, en la cual podemos ver
los detalles de las estaciones, modificar estos detalles, y
establecer a cuales estaciones y sensores tiene acceso
un usuario especfico.
En el men de sugerencias los usuarios pueden enviar
comentarios acerca del sistema para realizar mejoras o
notificar si el sistema est fallando para su respectiva
correccin
Fuente: Elaboracin propia.

En la Imagen 23 vista de reportes tabulares agregados y reportes raw nos

encontraremos con un pequeo panel en el cual se pueden establecer

121

parmetros para generar un reporte tabular. Tambin se cuenta con opcin de

exportar los reportes en distintos formatos.

Imagen 23 Reportes tabulares

Fuente: Elaboracin Propia

8.3. Resultado de sistema deLos reportes FM12

El caso de uso de los reportes, as como el diagrama de secuencia de este
mdulo del sistema se muestran en el anexo A.7.
En las siguientes imgenes, se muestra el resultado del sub-sistema de reportes
FM12, incluido como modulo en el SIMET.

122

Imagen 24 ndex de SIMET donde est el men Reportes FM12

Fuente: Elaboracin Propia

En la siguiente Imagen 25, se observa el mdulo de reportes y los diferentes

reportes solicitados por la Direccin de Meteorologa en conjunto con los
observadores.

Imagen 25 Catlogo de reportes

Fuente: Elaboracin Propia

En las siguientes imgenes (Imagen 26 e Imagen 27), se observa el resultado

del reporte ms importante para la direccin de meteorologa y ms tedioso de
realizar para los observadores, el cual es el reporte de las codificadas tambin
llamado reporte FM12, se ejecuta diariamente donde se llenan las 24 horas del
123

da con los datos de las variables solicitadas; este reporte es solicitado por la
NOOA a la direccin de meteorologa.

Imagen 26. Reporte Codificado FM12

Fuente: Elaboracin Propia

Imagen 27. Reporte Codificado FM12

Fuente: Elaboracin Propia

En el anexo A.7.3, se mostrarn el resto de los reportes plasmados en la seccin

de metodologa del desarrollo del sub-sistema de reportes.

124

8.4. Clientes EstndaresImplementaImplementacin der clientes IDE

estndares
En esta se seccin se muestra los resultados de los clientes y visores que
consumen los servicios web estndares, entre los servicios usados se tienen:
SOS, WMS, WFS.
8.4.1. Cliente SOS
En Imagen 28 se presenta la implementacin del mdulo App.sos de la librera
SOS.JS, esta aplicacin integra mltiples mdulos de la librera SOS.JS, el
modulo App.sos, presenta tres pestaas: Map, Plot,Table; a continuacin
una descripcin de la funcionalidad de cada una de estas pestaas.
En la pestaa Map de la Imagen 28, se presenta un mapa con las estaciones
representadas como puntos rojos, ubicadas geogrficamente, para ello se est
consumiendo los servicios WMS y SOS. Al seleccionar una estacin en el mapa
se presentan los offering (Agrupacin lgica de variables) que posee la estacin,
posterior al seleccionar un offering se mostraran sus ObservedProperties
(variables) del offering seleccionado.

Imagen 28. Vista a cliente del servicio SOS

Fuente: Elaboracin Propia

125

En la pestaa Plot de la Imagen 29 se presenta una serie temporal graficada

de manera lineal, en este caso corresponde a la ObservedPropertie (Variable)
seleccionada que es PuntoRocio tambin conocido como punto de roci, se
puede apreciar una lista en la pestaa ObservedProperties, esta lista fue
agrupada como un Offering, dado que existe una relacin lgica entre estas
variables.

Imagen 29. Vista grafica de una serie temporal en el cliente SOS

Fuente: Elaboracin Propia

En la pestaa Table (ver seccin de Error: Reference source not found) se

presenta una tabla con las columnas Time (Tiempo) y Value (Valor), en ellas
se lista los valores a travs del tiempo para una variable de una la estacin,
adems en esta tabla se puede obtener clculos estadsticos como cuartiles,
media, varianza, desviacin estndar, mnimo, mximo y un pequeo grafico
para visualizar la distribucin de los valores.

126

8.4.2.
8.4.3. Cliente WMS
En la Imagen 30 se observa el resultado del cliente que consume el servicio
WMS y WFS previamente realizados en GeoServer.
La aplicacin presenta la opcin de ver tres distintos mapas como son Google
Maps desde la perspectiva satelital y la de terreno adems de Open Street Map.
Debajo de la opcin del tipo de mapa se encuentran las consultas que pueden
ver en el mapa como son la lluvia de la ultima hora (1h) ,6h, 12hrs y 24hrs.

Imagen 30. Resultado del Visor con Vista Satelital Google Maps
Fuente: Elaboracin Propia

Adems en la Imagen 31 se muestra que dando click el botn de info

luego en un punto en el mapa se despliega un panel con la informacin donde

este realiza una operacin WMS para mostrar los datos del punto.

127

Imagen 31. Consulta a un punto en el mapa

Fuente: Elaboracin Propia

Ver los dems mapas en anexo A.8

128

LVIII. CONLCUSIN
Durante el desarrollo de esta monografa se pudo concluir lo siguiente:
1) Teniendo en cuenta que uno de los aspectos ms importantes en esta
plataforma y en cualquier otro ambiente, son los datos, almacenarlos de
una manera estructurada y estandarizada hace posible que el consumo de
estos datos se realice de manera fcil y eficiente.
2) La plataforma aporta a la reduccin del tiempo y el nmero de pasos que
se requieren para realizar la recoleccin de este tipo de datos y los
estudios que se ejecutan con los mismos.
3) Con un subsistema dedicado para la recoleccin de los datos de las
estaciones se reducen los errores humanos en el ingreso de los datos,
pasando los mismos por un proceso de validacin lo cual conserva la
integridad de los mismos.
4) La validacin de los datos mediante directrices de la norma UNE500540,
fortalece la credibilidad de los datos utilizados para la generacin de
estudios auxiliando de gran manera a la DGMET del INETER reduciendo
horas de trabajos en la generacin de la informacin.
5) La plataforma permite visualizar cada uno de los datos ingresados, as
como los recolectados de manera automtica, as poder realizar estudios
histricos de los datos comparando datos recolectados con anterioridad
con datos ms actuales mediante grficos y reportes tabulares de las
estaciones de inters seleccionadas.
6) Los datos provenientes de las estaciones hidrometeorolgicas, son de
suma importancia para distintas instituciones del estado, por lo cual la
interoperabilidad de estos datos mediante geo-servicios fue una de las
partes ms importantes de la plataforma; mediante los geo-servicios
realizados en esta tesis las dems instituciones podrn consumir de
manera estndar la informacin del INETER.
7) Los clientes IDE permiten la facilidad de consumir los geo-servicios y hacer
estudios de los datos de las estaciones a nivel geogrfico as como
predicciones climticas.

129

8) Los clientes SIG pueden consumir los servicios estndares, lo que facilita la
generacin de informacin y estudios, aprovechando las herramientas de
procesado de datos que dispones los software SIG.

130

LIX.

RECOMENDACIONES.

1) Se recomienda aplicar los niveles faltantes de validacin de la norma

UNE500-540

tambin

aplicarla

en

las

distintas

variables

hidrometeorolgicas recolectadas por todas las estaciones.

2) Completar los metadatos de las estaciones hidrometeorolgicas.
3) Utilizar navegador Google Chrome o Microsoft Edge para una mejor
experiencia de la plataforma.
4) Garantizar las conexiones de red en todo momento.
5) Actualizar los equipos obsoletos por equipos ms nuevos para enriquecer
la experiencia de usuario.
6)

131

LX.

BIBLIOGRAFIA

52north.

(n.d.).

Sensor

Observation

Service.

Retrieved

from

52north:

http://52north.org/communities/sensorweb/sos/
52north. (n.d.). sosjs. (52north) Retrieved from http://sosjs.readthedocs.org/
AENOR. (2004). Directrices para la validacion de registros meteorolgicos
procedentes de redes de estaciones automaticas. AENOR.
Andrew, C. (2013). Contaminantes atmosferics de la estacin de monitore en
tiempo real de la ciudad de Cuenca, utilizando servicios estndares de
OGC.
Anguix, . (2013). Introduccion al software libre para las IDE.
Ariza Lopez, F. J., & Rodriguez Pascual, A. F. (2008). Introduccin a la
normalizacin en informacin geogrfica: La familia iso 19100. Espaa.
Beck, K. (2003). Test-driven Development: By Example. Addison-Wesley
Professional.
Bill, R. (n.d.). GRID COMPUTING AND GIS. Werte Leserinnen und Leser.
Calle-Jimenez, T., & Lujn-Mora, S. (2016, Febrero 1). Web Accessibility Barriers
in Geographic Maps. International Journal of Computer Theory and
Engineering, 8(1), 80-83.
Carrillo, G. (2012, 01 03). GeoTux. Retrieved from Soluciones GeoInformaticas
Libres:

http://geotux.tuxfamily.org/index.php/en/geo-blogs/item/291-

comparacion-clientes-web-v6
Caryl-Sue, N. G. (2011, Marzo 26). National Geographic. Retrieved from
http://nationalgeographic.org/encyclopedia/geographic-informationsystem-gis/
CeReGeo.

(n.d.).

CeReGeo

Mapas

en

la

Web.

https://ceregeo.wikispaces.com/Datos+espaciales
132

Retrieved

from

Chaglla, L. E. (2014). Estructuracin de una plataforma de acceso a datos

georeferenciados para la gestin de riesgos en el Ecuador. Quito,
Ecuador.
Cory A. Henson, J. K. (2009). SemSOS: Semantic sensor Observation Service.
IEEE.
Cox,

S.

J.

(n.d.).

www.opengis.net.

(OGC)

Retrieved

from

http://www.opengis.net/def/observationType/OGC-OM/2.0/
de la Torre Llorente, C., Zorrilla Castro, U., Calvarro Nelson, J., & Ramos
Borroso, M. (2010). GUA DE ARQUITECTURA N-CAPAS ORIENTADA
AL DOMINIO CON .NET 4.0. Espaa: Krasis Press.
Daz , A., Arias de Reyna, M., & Sanz , J. (n.d.). Panorama sig libre. Retrieved
from http://panorama-sig-libre.readthedocs.io/es/latest/servidores/
Digital, U. d., & Presidencia, M. d. (n.d.). GUIA DIGITAL. Retrieved from
http://www.guiadigital.gob.cl/articulo/pruebas-de-interfaces-y-contenidos
Direccion General de Meteorologia INETER. (2012). (INETER) Retrieved from
http://servmet.ineter.gob.ni/Meteorologia/RedEstacionesNac/Estaciones/E
staciones.html
DOC/NOAA/NESDIS/NCDC > National Climatic Data Center, N. N. (2015, 03
12). NCEP-GTS Marine Observations in BUFR format. Retrieved from
https://data.noaa.gov/harvest/object/fca8e991-ecb2-4568-879715b2f4bb17b5/html
Documentacion,

5.

(n.d.).

wiki.52north.org.

(52north)

Retrieved

from

wiki.52north.org:
https://wiki.52north.org/bin/view/SensorWeb/SensorObservationServiceIV
Documentation
Ehlers, M. (2008). GeoInformatics and Digitals earth initiatives: a German
Perspective.

133

e-infraestructures, T. e. (2009). Craig A. Lee, George Percivall. Open Grid

Forum, The Aerospace Corporation, Open Geospatial Consortium.
Estvez Gualda, J., & Gaviln Zafra, P. (2008). Procedimientos de validacin de
datos de estaciones meteorolgicas automticas. Andaluca, Espaa.
Evans, E. J. (2004). Diseo guiado por el dominio.
Gamma, E. (2002). Patrones de diseo. Pearson Educacin.
GIS), J. B. (2013, Septiembre 24). The Value of Geoinformation for Disaster and
Risk Management (VALID). Copenhagen, Denmark. Retrieved from
http://www.directionsmag.com/entry/applying-geoinformation-to-disasterand-risk-management-impact-and-ben/280430
Gutierrez Corea, F. V., & Schillinger, S. (2009). Lluvia en tiempo real y sistema
de alerta temprana por deslizamientos para Centro Amrica en base a
imgenes de Satlite NOAA y aplicaciones con ArcObjects. Brazil: XIV
Brazilian Remote Sensing Symposium 2009.
IEEE. (1990). IEEE Standard Glossary of Software Engineering Terminology.
Inc, O. G. (2006). OpenGIS Web Map Server Implementation Specification.
Iniesto Alba, C. C. (2004). Sensor Web Enablement: Todos los sensores
conectados a la web. VIII Congreso de topografia y cartografia. Madrid.
Instituto de Estadistica y Cartografia de Andaluca. (n.d.). IDEAndalucia. (Instituto
de Estadistica y Cartografia de Andalucia) Retrieved 10 15, 2016, from
http://www.ideandalucia.es/portal/ides/software/servidores
ISO

Online

Browsing

Plataform(OBP).

(2011).

(ISO)

Retrieved

from

https://www.iso.org/obp/ui/#iso:std:iso:19156:ed-1:v1:en
iso2500.

(2015).

ISO2500.

Retrieved

from

http://iso25000.com/index.php/normas-iso-25000/iso-25010/24-fiabilidad
Junta

de

Andalucia.

(n.d.).

Junta

de

Andalucia.

Retrieved

http://www.ideandalucia.es/portal/ides/software/servidores
134

from

K. G. Hubbard, S. G. (2005). Performance of Quality Assurance Procedures for

an Applied Climate Information System. Sociedad Americana de
Meteorologia.

Retrieved

from

http://journals.ametsoc.org/doi/full/10.1175/JTECH-1657.1
Lopez-Vasquez, M. A., & Bernabe-Poveda, C. (2012). Infraestructura de Datos
Espaciales (IDE). Espaa: Ulzama Digital.
Lopez-Vasquez, M. A.-P. (2012). In Fundamentos de las infraestructura de datos
espaciales (IDE) (pp. 42-43).
Luis E. Bermdez, J. M. (2012). Open Geospatial Consortium (OGC). UPM
Press.
Maganto, A. S. (2013). Componente de una IDE.
Malinowski, E. (2014). Evaluacin de los sistemas de administracin de bases
de datos con extensiones espaciales.
Mansberger,

R.

(2003).

GEOINFORMATION

IN

SUPPORT

OF

DECENTRALISATION AND COMMUNITY EMPOWERMENT. Austria.

Martin C. Robert, M. M. ( 2006). Agile Principles, Patterns, and Practices in C#.
Prentice Hall.
Microsoft Corporation. (Diciembre 2006). La Arquitectura Orientada a Servicios
(SOA) de Microsoft aplicada al mundo real.
Nstor, M. F. (2015). COMPARATIVA DE RENDIMIENTO DE SERVIDORES DE
MAPAS OPEN SOURCE. CATALUNYA: Universidad Politecnica de
Catalunya.
NOAA. (n.d.). World record point precipitation measurements. Retrieved 09 15,
2016,

from

http://www.nws.noaa.gov/oh/hdsc/record_precip/record_precip_world.html
Normas ISO. (2016, Enero 15). Normas ISO 19119:2016: Geographic
Information-Services.

Retrieved
135

from

ISO:

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?
csnumber=59221
OGC. (2006). OpenGIS Web Map Server Implementation Specification.
OGC. (2008). Modelo de Referencia OGC.
OGC. (2012). OGC WCS 2.0 Interface Standard- Core:.
OGC.

(2015,

Diciembre).

Open

Geospatial

Members.

Retrieved

from

opengeospatial: http://www.opengeospatial.org/ogc/members
OGC.

(2016,

10

26).

Open

Geospatial.

Retrieved

from

http://docs.opengeospatial.org/is/04-094r1/04-094r1.html
OGC. (n.d.). Welcome to the OGC. (The OGC Interoperability Program)
Retrieved from OpenGeospatial: http://www.opengeospatial.org/
Open Geospatial Consortium. (2005). The Importance of Going Open. OGC.
Organizacion

Meteorologica

Mundial.

(n.d.).

Retrieved

from

http://www.wmo.int/pages/index_es.html
Oriente, J. (2013, Septiembre 28). joaquinoriente Web site. Retrieved from
http://joaquinoriente.com/2013/09/28/calidad-de-producto-softwareprimeros-certificados-aenor-iso-25000/
Pressman, R. S. (2010). Ingenieria de Softaware. Un Enfoque Practico. New
York: McGRAW-HILL.
Reference,

P.

(n.d.).

http://postgis.net/.

(postgis)

Retrieved

from

http://postgis.net/docs/reference.html#Geometry_Constructors
Reichardt, M. (2004). The Havoc of Non-Interoperability . OpenGIS Consortium
(OGC).
Rumbaugh, J., Jacobson, I., & Booch, G. (1999). El Lenguaje Unificado del
Modelado. Espaa: ADDISON WESLEY.

136

Santitamnont, D.-I. P. (2008, Enero). http://geospatialworld.net/. Retrieved from

http://geospatialworld.net/magazine/MArticleView.aspx?
aid=19227&Itemid=358
Sutron Corporation. (2015, Enero 29). Sutron. (Sutron Corporation) Retrieved
from http://www.sutron.com/wp-content/uploads/2015/01/XC_Desktop.doc
Take

Off

Briefing.

(2012,

11

27).

(ToB)

Retrieved

from

http://www.takeoffbriefing.com/metar/
Tirado, V. R. (2013). Modelo de Pronostico de Precipitacion para La Hoya 69 de
Nicaragua. Managua,Nicaragua: UNAN-MANAGUA.
Torres Saura, M., & Valenzuela Daz-Moreno, A. (2010, Agosto).
geoinformacin:

una

necesidad

creciente.

Retrieved

La
from

http://cartografiaunpsjb.jimdo.com/art%C3%ADculos-para-compartir-yreflexionar/la-geoinformaci%C3%B3n-una-necesidad-creciente/
Uslnde, T. (2012). OGC Best Practices for SWE: Provision of Observations
through an OGC SOS . EO2HEAVEN Consortium.
Vargas, R. B. (2012). Almacenamiento informacin geogrfica.

137

LXI.
A.1.

ANEXOS
Anexos Base de Datos

A.1.1. Versin de gestor de base de datos y extensin espacial

implementada.

Imagen 32 Versin de PostGIS utilizada

Fuente: Elaboracin Propia

A.1.2. Vista de tablas en base de datos 52N SOS

Imagen 33 Tablas de la base de datos 52N SOS

Fuente: Elaboracin Propia

138

A.1.3. Diagrama de base de datos 52N SOS

Imagen 34.Diagrama de base de datos SOS 2.0.

Fuente: Elaboracin Propia

139

A.1.4. Diccionario de datos para BD 52N SOS

Tabla 10 Diccionario de datos de tabla observacin

Tabla observation
Campo
observationid

Tipo
bigint

serieid

bigint

phenomenontimestart

timestamp

phenomenontimeend

timestamp

resulttime

timestamp

identifier

Character

Tamao

255

varying

Descripcin
PK,
clave
primaria,
identificador nico de la
observacin.
FK, clave fornea para la
tabla de series asociadas.
Indica la hora en que se
inici la observacin o el
fenmeno se observ.
Indica el tiempo final cuando
la observacin finaliza.
Tiempo marcado cuando la
observacin fue publicada.
Identificador
de
la
observacin, se utiliza como
parmetro para la consulta.
Relacin, llave fornea para
la tabla condesase
Nombre de la observacin.

codespace

bigin

name

character

255

description

varying
character

255

deleted

varying
character

Descripcin
de
observacin. Opcional.

validtimestart

timestamp

validtimeend

timestamp

unitid

bigint

samplinggeometry

geometry

Para indicar si la observacin

se elimin o no (OGC SWES
2.0)
Tiempo de inicio marcado
para la observacin.
Indica la hora final de la
observacin (opcional).
Llave fornea (FK), para
relacionar la unidad de
medida.
Indica la geometra del
muestreo,
describe
exactamente el punto donde
ha
tenido
lugar
la
observacin.

140

la

Tabla 11Diccionario de datos de tabla numericvalue

Tabla numericvalue
Campo
Observationid

Tipo
bigint

value

Double

Tamao

precision

Descripcin
Llave fornea, para relacionar la
observacin
Valor
numrico
de
la
observacin

Tabla 12 Diccionario de datos de tabla countvalue

Tabla countvalue
Campo
Observationid

Tipo
bigint

value

integer

Tamao

Descripcin
Llave fornea, para relacionar la
observacin.
Contador del valor observacin.

Tabla 13 Diccionario de datos de tabla textvalue

Tabla textvalue
Campo
Observationid

Tipo
bigint

Value

text

Tamao

Descripcin
Llave fornea, para relacionar la
observacin.
Contador del valor observacin.

Tabla 14 Diccionario de datos de tabla featureofinterest

Tabla featureofinterest
Campo
featureofinterestid

Tipo
bigint

hibernatediscriminator
featureofinteresttypeid

character 1
bigint

identifier

character 255
varying
bigint

codespace
Name

Tamao

codespacename

character 255
varying
bigint

description
Geom

character
geometry
141

Descripcin
Llave primaria, usada para
las relaciones.
Llave fornea para relacionar
featureofinteresttype.
Identificador
de
featureofinterest.
Llave fornea para relacionar
el espacio de cdigo.
Nombre del featureofinterest.
Nombre del cdigo de
espacio.
Breve descripcin.
Representa la geometra del

escriptionxml

text

url

character 255
varying

tipo de inters.
Descripcin de la funcin
XML, utilizado cuando se
admite el perfil transaccional.
URL de referencia para el
futuro si se almacena en otro
servidor.

Tabla 15 Diccionario de datos de tabla validproceduretime

Tabla ValidProcedureTime
Campo

Tipo

Tama

Descripcin

o
ValidProcedureTimeid

bigint

procedureid

bigint

Proceduredescriptionform
atid

bigint

starttime

timestam
p
text

descriptionxml

Llave primaria, usada para

las relaciones.
Llave
fornea
para
relacionar
el
procedimiento.
Llave
fornea
para
relacionar
el
proceduredescriptionforma
tid.
Marca del tiempo.
Descripcin
procedimiento
cadena XML.

del
como

Tabla 16 Diccionario de datos de tabla observableproperty

Tabla ObservableProperty
Campo
Tipo
ObservablePropertyid bigint

Tamao

identifier

character 255

codespace

varying
bigint

Name

character 255

codespacename

varying
bigint

Descripcin
Llave primaria, usada para las
relaciones.
Representa el identificador.
Llave fornea para relacionar
el codespace.
Nombre
de
la
ObservableProperty.
Llave fornea para relacionar
codespacename.

142

description

character 255

disabled

varying
character 1

Breve descripcin general.

Para su uso posterior del
SOS.

Tabla 17 Diccionario de datos de tabla unit

Tabla unit
Campo
Unitid

Tipo
bigint

Tamao

Unit

character

255

varying

Descripcin
Llave primaria, usada para las
relaciones.
Unidad de medida de las
observaciones.

Tabla 18 Diccionario de datos de tabla offering

Tabla offering
Campo
offeringid

Tipo
bigint

Tamao

identifier

character

255

Descripcin
Llave primaria, usada para las
relaciones.
Identificador de la oferta.

codespace

varying
bigint

Name

character

255

Llave fornea para la relacin

codespace.
Nombre de la oferta.

codespacename

varying
bigint

description

character

255

Llave fornea para la relacin

codespacename.
Descripcin de la oferta.

disabled

varying
character

Para su uso posterior por el

SOS.

Tabla 19 Diccionario de datos de tabla observationcontellation

Tabla observationconstellation
Campo
Tipo
observationconstellationid
bigint
observablepropertyid

Tamao

bigint

143

Descripcin
Llave primaria, usada
para las relaciones.
Llave fornea para la
relacin
observableproperty.

procedureid

bigint

observationtypeid

bigint

offeringid

bigint

deleted

character

hiddenchild

character

Llave fornea para la

relacin procedure.
Llave fornea para la
relacin,
observationtype.
Llave fornea para la
relacin, offering.
Bandera para indicar
que esta constelacin
de observacin se
elimina o no.
Bandera para indicar
que
este
procedimiento
de
observacin de las
constelaciones es un
procedimiento
secundario de otro
procedimiento.

Tabla 20 Diccionario de datos de tabla featureofinteresttype

Tabla featureofinteresttype
Campo
Tipo
featureofinteresttypeid
bigint

Tamao

featureofinteresttype

255

character
varying

Descripcin
Llave primaria, usado
para la relacin.
El
valor
de
featureofinteresttype.

A.1.5. Captura de pantalla del contenido de la tabla XC_SITES de la base

de datos XC_DATA.

144

Imagen 35 Contenido de la tabla XC_SITES,

Fuente: Elaboracin Propia

A.1.6. Captura de pantalla del contenido de la tabla XC_SITESENSOR de

la base de datos XC_DATA

Imagen 36 Contenido de tabla XC_SITESENSOR

Fuente: Elaboracin Propia

145

A.1.7. Captura de pantalla de una muestra de datos de la tabla XC_DATA

Imagen 37 Contenido de tabla XC_DATA1

Fuente: Elaboracin Propia

A.2.

Anexos Migracin de Datos

A.2.1. Imagen de la ventana de servicios de Windows

Imagen 38 Imagen de servicio de migracin de datos

Fuente: Elaboracin Propia

146

A.3.

Anexos de SIMET

A.3.1. Diagrama de clases SIMET

Imagen 39. Diagrama de clases SIMET

Fuente: Elaboracin Propi

147

A.3.2. Casos de uso SIMET

Imagen 40. Caso de Uso - Administrar Estaciones

Fuente: Elaboracin Propia

Imagen 41. Caso de Uso - Administrar Tipo Horarias

Fuente: Elaboracin Propia

148

Imagen 42. Caso de Uso - Administrar Tipos de Nube

Fuente: Elaboracin Propia

Imagen 43.Caso de Uso - Administrar Usuarios

Fuente: Elaboracin Propia

149

Imagen 44. Caso de Uso - Administrar Variables

Fuente: Elaboracin Propia

Imagen 45. Caso de Uso - Administrar Tipos de Fenmenos

Fuente: Elaboracin Propia

150

Imagen 46. Caso de Uso - Administrar Tiempo Horarias

Fuente: Elaboracin Propia

Imagen 47. Caso de Uso - Administrar Clasificacin de Fenmenos

Fuente: Elaboracin Propia

151

Imagen 48. Caso de Uso - Clasificacin de Nubes

Fuente: Elaboracin Propia

Imagen 49. Caso de Uso - Generar Reportes Grficos

Fuente: Elaboracin Propia

152

Imagen 50. Caso de Uso - Crear Observacin Observador

Fuente: Elaboracin Propia

Imagen 51. Caso de Uso - Crear Observacin en Control de Calidad

Fuente: Elaboracin Propia

153

A.3.3. Diagramas de Secuencia SIMET

Imagen 52. Diagrama de Secuencia - Crear Observacin-Observador

Fuente: Elaboracin Propia

Imagen 53. Diagrama de Secuencia - Crear Observacin-Control de Calidad

Fuente: Elaboracin Propia

154

Imagen 54. Diagrama de Secuencia - Administrar Estaciones

Fuente: Elaboracin Propia

Imagen 55. Diagrama de Secuencia - Administrar Tipo Horaria

Fuente: Elaboracin Propia

155

Imagen 56. Diagrama de Secuencia - Administrar Tipos de Nube

Fuente: Elaboracin Propia

Imagen 57. Diagrama de Secuencia Administrar Variables

Fuente: Elaboracin Propia

156

Imagen 58. Diagrama de Secuencia - Administrar Tipos de Fenmeno

Fuente: Elaboracin Propia

157

Imagen 59. Diagrama de Secuencia - Administrar Clasificacin de Fenmenos

Fuente: Elaboracin Propia

Imagen 60. Diagrama de Secuencia - Administrar Tiempo Horaria

Fuente: Elaboracin Propia

158

Imagen 61. Diagrama de Secuencia - Generar Reporte Grafico

Fuente: Elaboracin Propia

159

Imagen 62. Diagrama de Secuencia - Administrar Usuarios

Fuente: Elaboracin Propia

160

A.3.4. Diagrama de paquetes

Imagen 63. Diagrama de Paquetes SIMET

161

A.3.5. Plantillas de Requerimientos Funcionales del SIMET

Tabla 21. Plantilla de requerimiento Funcional - Login

Login segn rol y estacin(RF2)

Requisito
Complejida

RF2
Media

d
Prioridad
Descripcin

Alta
El sistema permitir la visualizacin de las opciones disponibles

Proceso

del sistema segn su rol y estacin.

1. Ingresar con las credenciales (Usuario y Contrasea)

Entrada
Salida

asignadas.
Nombre Usuario y contrasea.
Visualizacin del sistema segn su rol y estacin.
Fuente: elaboracin propia

Tabla 22. Plantilla de requerimiento Funcional - Crear observacin

Crear observacin segn rol(RF3)

Requisito
Complejida

RF3
Alta

d
Prioridad
Descripcin

Alta
El sistema permitir crear observacin segn rol, si es
observador ser solo para la estacin a la cual el usuario
pertenezca,

si

es

control

de

calidad

deber

crear

observaciones donde n representa la cantidad de estaciones

Proceso

convencionales en el pas que no tengan acceso a internet.

1. Ingresar con las credenciales correspondientes (Usuario y
contrasea).
2. Ingresar al catlogo de observaciones.
3. Seleccionar la opcin crear observacin.
4. Ingresar los datos necesarios para
(Temperatura,

Precipitacin,

Velocidad del Viento).

5. Seleccionar Tipo Horaria
6. Crear observacin.
162

Direccin

la
del

creacin
Viento

Entrada

Tipo de periodo, Cdigo Metar, Temperatura, Precipitacin,

Salida

Direccin y Velocidad del Viento.

Visualizacin de la observacin creada segn rol. Si rol es
observador la observacin ser una. De lo contrario si es Control
de Calidad sern n-1 observaciones segn la cantidad de
estaciones.
Fuente: elaboracin propia

Tabla 23. Plantilla de requerimiento Funcional - Almacenar Variables

Almacenar todas las variables de la hoja de observacin(RF4)

Requisito
RF4
Complejida
Media
d
Prioridad
Descripcin

Alta
El sistema permitir el almacenamiento de todas las variables de
la hoja de observacin de la forma ms similar posible y cmoda
al usuario.
1. Ingresar al sistema con las credenciales.
2. Recolectar
los
valores
de
las

Proceso

variables

hidrometeorolgicas de los instrumentos analgicos.

3. Editar una observacin.
Datos de las variables de las estaciones convencionales.
Pgina de la hoja de observacin.

Entrada
Salida

Fuente: elaboracin propia

Tabla 24. Plantilla de requerimiento Funcional - Visor de Aeronutica y Sinptica

Visor de observaciones para el rea de sinptica y aeronutica(RF5)

Requisito
RF5
Complejida
Media
d
Prioridad
Descripcin

Alta
El sistema permitir que aeronutica y sinptica tengan acceso
nicamente a la visualizacin de los datos ms importantes de
las observaciones como lo son:
Direccin del viento (DV), Velocidad del Viento (VV), Temperatura
163

Proceso
Entrada
Salida

(TEMP) y la Precipitacin (PREC) en tiempo cuasi real.

1. Ingresar al sistema con las credenciales correspondientes.
2. Ingresar al catlogo de observaciones.
Credenciales(Usuario y Contrasea)
Pgina de inicio nicamente con la opcin de ver observaciones.
Fuente: elaboracin propia

Tabla 25. Plantilla de requerimiento Funcional - Reportes Grficos

Reportes grficos de series temporales de precipitacin y temperatura

(RF6)
Requisito
Complejida

RF6
Media

d
Prioridad
Descripcin

Alta
El sistema permitir que los usuarios tengan como rol
administradores a la visualizacin de los reportes grficos de

Proceso

temperatura y precipitacin de las estaciones convencionales.

1. Ingresar al sistema con las credenciales (Usuario y
Contrasea).
2. Ingresar al men de reportes
3. Seleccionar rango de fechas.
4. Seleccionar la variable (Temperatura o Precipitacin) a

Entrada
Salida

graficar.
5. Seleccionar la opcin graficar.
Rango de Fechas, Variable.
Reporte grfico de la estacin/estaciones.
Fuente: elaboracin propia

A.3.6. Plantillas de Requerimientos No Funcionales

Tabla 26. Plantilla de requerimiento No Funcional - Tiempo de Respuesta

Tiempo de Respuesta (RNF2)

Requisito
Complejida

RNF2
Media

d
Prioridad
Descripcin

Alta
El sistema deber dar un tiempo de respuesta adecuado a las
necesidades de los usuarios al momento de llenar la
164

observacin y/o modificaciones as como buscar y eliminar

Proceso
Entrada
Salida

observaciones.
Desarrollo del sistema
Desarrollo del sistema.
Sistema.
Fuente: elaboracin propia

Tabla 27. Plantilla de requerimiento No Funcional - Seguridad

Seguridad (RNF3)
Requisito
Complejida

RNF3
Media

d
Prioridad
Descripcin

Alta
El sistema debe negar acceso a las personas no autorizadas,
tambin, debe tener pistas de auditoria, rechazar accesos o

Proceso
Entrada
Salida

modificaciones no autorizadas
Desarrollo del sistema
Desarrollo del sistema.
Sistema.
Fuente: elaboracin propia

Tabla 28. Plantilla de requerimiento No Funcional - Mantenibilidad

Mantenibilidad (RNF4)
Requisito
Complejida

RNF4
Media

d
Prioridad
Descripcin

Alta
El sistema deber tener la capacidad de ser modificado efectiva
y eficientemente, debido a necesidades evolutivas, correctivas o

Proceso
Entrada
Salida

perfectivas.
Desarrollo del sistema
Desarrollo del sistema.
Sistema.
Fuente: elaboracin propia

165

Tabla 29. Plantilla de requerimiento No Funcional - Usabilidad

Usabilidad (RNF5)
Requisito
Complejida

RNF5
Media

d
Prioridad
Descripcin

Alta
El sistema deber tener la capacidad para ser entendido,
aprendido, usado y resultar atractivo. Adems de operarlo y

Proceso
Entrada
Salida

controlarlo con facilidad por parte de los usuarios.

Desarrollo del sistema.
Desarrollo del sistema.
Sistema.
Fuente: elaboracin propia

A.3.7. Pruebas del Sistema

Tabla 30. Prueba de Accesibilidad - SIMET

Conceptos de Accesibilidad
1. Se proporciona un texto equivalente para
todo elemento no textual, tales como
imgenes, para explicar su contenido a
discapacitados visuales?

Cumple Comentarios
u
Si No observaciones
x

2. La informacin transmitida a travs de

los colores tambin est disponible sin
color?

3. El documento est estructurado para que x

pueda ser ledo con o sin una hoja de
estilo, utilizando adecuadamente los tags
de HTML?
4. El documento est escrito en un lenguaje x
adecuado y se deja claro cuando se
cambia de idioma?
5. Las tablas se utilizan para presentar
informacin y no para diagramar el
contenido del Sitio Web?

166

6. Las pginas que utilizan nuevas

tecnologas siguen funcionando cuando
dicha tecnologa no est presente (por
ejemplo, los plug-ins de Flash)?

7. Se asegura la accesibilidad de los

elementos de la pgina que tengan sus
propias interfaces? (Por ejemplo, para el
uso de Portlets)

8. Se permite al usuario activar elementos

de las pginas, usando cualquier
dispositivo como el mouse o el teclado y
no slo uno en particular?

9. Se ofrecen soluciones transitorias que

permiten a usuarios con browsers
antiguos, acceder a contenidos que han
sido creados en nuevas tecnologas?

10. Se usan las tecnologas y guas de

trabajo generadas por la W3C?

11. Se ofrece ayuda y orientacin a los

usuarios para entender pginas o
elementos complejos dentro de ellas? (Por
ejemplo: mapas y grficos)

12. Se ofrecen elementos de navegacin

claros?

13. Se asegura que los documentos que se

ofrecen a travs del Sitio son simples,
claros y pueden ser fcilmente
entendidos?

Fuente: elaboracin propia

Tabla 31. Prueba de Indexacin de Buscadores

Conceptos de indexacin de buscadores

1. Todos los nuevos documentos que se
agregan al Sitio Web incluyen los campos
de Metadata adecuados?

Cumple Comentarios u
Si No observaciones
x

2. Cuando un usuario accede al Sitio mediante x

un Link ofrecido en un buscador y esta
167

pgina ya no existe, se ofrece un mensaje

personalizado que le permita encontrarla en
su nueva ubicacin o le ofrezca un
contenido alternativo?
3. Tiene definido el texto que aparece en el
tag HTML <title> para indicar el Nombre del
Sitio o de la Institucin?

4. El Sitio ofrece un contenido adecuado

para el tag HTML META
NAME="description"?

5. El Sitio ofrece un contenido adecuado

para el tag HTML META
NAME="keywords"?

6. El Sitio ofrece un texto adecuado en el

texto que aparece en el META tag
NAME="robots"?

7. El Sitio cuenta con un archivo de texto

Robots.txt para los directorios que no se
desea indexar?

8. El Sitio est indexado en el directorio

DMOZ.org?

9. El Sitio est indexado en los buscadores

Google y Altavista(bing)?

Google

10. Ha definido como tarea permanente la de

revisar la presencia del Sitio en
Buscadores?

11. Ha definido como tarea permanente la

realizacin de alianzas e intercambio de
enlaces con otros Sitios de instituciones del
Sector Pblico?

12. Revisa peridicamente el LOG (bitcora)

del Sitio para identificar las palabras ms
utilizadas por los usuarios para acceder a
su Sitio?

168

Fuente: elaboracin propia

Tabla 32. Prueba de Seguridad

SEGURIDAD
1. El Sitio funciona correctamente y no
presenta fallas al navegar por sus pginas o
utilizar sus servicios? (especialmente en el
caso de Trmites en lnea)

Cumple Comentarios u
Si No observaciones
x

2. Los datos ingresados por un usuario a

travs de formularios, son validados antes
de ser enviados y procesados por el
servidor del Sitio?

3. Todos los vnculos del Sitio tienen una

pgina asociada y el contenido adecuado al
vnculo sealado?

4. Frente a una bsqueda dentro del Sitio o

cualquier operacin en el mismo los
resultados se muestran correctamente?

5. Los datos privados, entregados

voluntariamente por los usuarios, son
guardados de manera reservada?

6. Se ofrece una Poltica de Privacidad de los

Datos Personales y se informa de su
existencia en las pginas pertinentes?

7. Los servicios ofrecidos son realizados a

travs de canales de transaccin seguros?

8. En los temas que requieren de accesos

restringidos, el Sitio provee algn medio
para validar el acceso, por ejemplo: a travs
de una caja de conexin con nombre de
usuario y password?

9. La poltica de seguridad implementada

para validar el acceso restringido es
adecuada a los propsitos del servicio o de
la institucin?

10. Protege la integridad de sus programas y

169

datos?
11. Se evita que sea visto, el nombre de los
programas y los directorios?

12. Se cuenta con un protocolo de seguridad

para evitar ataques externos e intrusiones
de hackers?

13. Se cuenta con una poltica de respaldo de

informacin que permita superar efectos de
fallas derivadas del punto anterior?

14. Se ha revisado si los sitios web que

requieran login de usuarios usan
conexiones encriptadas va HTTPS??

15. Se ha revisado si las contraseas en el

servidor son almacenadas utilizando un
hash con un salt aleatorio?

16. Se ha verificado lgica de permisos para

realizar las distintas acciones en el sitio
web? Ej: Que usuarios pueden borrar,
crear, editar los diferentes elementos?

17. Se han filtrado los ataques de SQL

Injection?. Se recomienda utilizar
PreparedStatements/Consultas
parametrizadas para hacer consultas a la
base de datos.

18. Se han realizado respaldos de la base de

datos en forma peridica o se han
programado estos respaldos en tareas?

Fuente: elaboracin propia

Tabla 33. Prueba de Rapidez de acceso

Rapidez de Acceso
1. El usuario puede encontrar en no ms de
3 clics la informacin buscada?
2. Aparece el men de navegacin en un
lugar destacado? Se ve fcilmente?
170

Cumple Comentarios
u
Si No observaciones
x
x

3. El Sitio cuenta con un mapa y/o buscador

que d un acceso alternativo a los
contenidos?

4. Es fcil llegar a las secciones ms

importantes del Sitio desde cualquier
pgina?

5. El Sitio mantiene una navegacin

consistente y coherente en todas sus
pginas?

6. El diseo usa jerarquas visuales para

determinar lo importante con una sola
mirada?

7. Los formularios ofrecen opciones que

permitan al usuario evitar, cancelar o
rehacer una accin?

8. El tamao de la letra de los textos es

adecuado y ajustable o modificable por el
usuario usando las herramientas del
programa visualizador?

9. Los vnculos, imgenes e conos son

claramente visibles y distinguibles?

10. Los vnculos (links) visitados y no

visitados son claramente diferenciables?

11. Los conos son representativos de la

funcin o accin que realizan y son
aclarados mediante una etiqueta ALT en
HTML?

12. Todas las pginas cuentan con un ttulo

que indique el nombre de la institucin e
informacin de contactos virtuales y fsicos
al pie de la pgina?

13. Provee informacin del organigrama de la

institucin?, Incluye nombres
actualizados de las autoridades y la forma
de contactarlos?

171

14. El nombre de la URL est vinculado con

el nombre o funcin de la institucin y se
ofrece en la barra superior del programa
visualizador?

15. Ofrece el Sitio contenidos sobre la visin,

misin, objetivos y plan estratgico de la
institucin?

16. En el caso que existan palabras tcnicas

en los contenidos del Sitio Existe una
seccin de glosario que las explique?, es
fcil llegar a l?

17. Ofrece pginas de ayuda que explican

cmo usar el Sitio Web?

18. Ofrece rea de Preguntas Frecuentes

con datos de ayuda a usuarios?

19. En caso de errores de consistencia dentro

del sitio, se ofrece un mensaje de
personalizado mediante una pgina
explicativa?, (Por ejemplo: Error 404 para
pgina inexistente)

Fuente: elaboracin propia

A.3.7.1. Pruebas de la W3C

Imagen 64. Prueba 1 de la W3C Validador Unificado

172

Fuente: Elaboracin Propia

Imagen 65. Prueba 2 de la W3C - Markup Validation

Fuente: Elaboracin Propia

173

A.3.8. Capturas del Sistemas

En la Imagen 66, se muestra la hoja de observacin donde se ingresarn los
datos de la hoja recolectados durante la observacin de la hora correspondiente.
Otro de los requisitos es que el diseo de la hoja fuese lo ms similar la posible
a la hoja fsica en que son recolectados los datos.

Imagen 66.Hoja de observacin

Fuente: Elaboracin Propia

Uno ms de los requerimientos enumerados en la parte de anlisis del sistema,

fue los reportes grficos de las variables ms significativas definidas por el rango
de fechas que el usuario desee. Este privilegio es otorgado nicamente a los
usuarios que tengan como rol ser administradores del sistema.
En la Imagen 67 se presentan el primer reporte grafico se muestra por estacin y
por variable donde en la pgina de inicio se muestra el diagrama de la
temperatura y precipitacin de los ltimos 3 das en la estacin de Managua.

174

Imagen 67. Reporte grafico por estacin, variable y rango de fechas

Fuente: Elaboracin Propia

En la Imagen 68, se muestra la segunda opcin de reportes grficos, donde se

muestra todas las estaciones a la vez por variables por fecha seleccionada. De
esta manera se puede apreciar mejor el comportamiento de la temperatura y la
precipitacin a travs del da en todas las estaciones del pas.

175

Imagen 68.Reporte grafico por variable y por da de todas las estaciones

Fuente: Elaboracin Propia

176

A.4.

Anexos Norma UNE

A.4.1. Imagen de las estaciones meteorolgicas automticas

Imagen 69 Mapa de las estaciones meteorolgicas automticas que se validaran

Fuente: Elaboracin Propia

A.4.2. Histograma de datos resultantes

Imagen 70 Histograma de datos resultantes despus de haber aplicado validacin

177

A.5.

Anexos Interoperabilidad

A.5.1. Vista tabular de serie temporal en el cliente SOS

Imagen 71 Vista tabular de serie temporal en el cliente SOS

Fuente: Elaboracin Propia

A.5.2.

Formato de consulta al servicio SOS

Imagen 72 Formato de consulta al servicio SOS

178

Fuente: Elaboracin Propia

A.5.3. Anexo WMS

En la siguiente imagen se muestra el resultado de la operacin GetCapabilities
del servicio WMS, este devuelve un documento con los metadatos que
describen el servicio.

Imagen 73. Resultado de la operacin GetCapabilities WMS

Fuente: Elaboracin Propia

Imagen 74. Resultado operacin GetMap de la lluvia 72hrs WMS

Fuente: Elaboracin Propia

179

A.5.4. Anexo WFS

En la siguiente imagen se muestra el resultado de la operacin GetCapabilities
del servicio WFS, este devuelve un documento con los metadatos que
describen el servicio.

Imagen 75. Resultado operacin GetCapabilities WFS

Fuente: Elaboracin Propia

En la siguiente imagen se muestra el resultado de la operacin Transaction del

servicio WFS.

Imagen 76. Resultado de la operacin Transaction WFS

Fuente: Elaboracin Propia

180

A.6.

Anexos CAELUS

A.6.1. Diagrama de clases

Imagen 77 Diagrama de clases de Caelus

Fuente: Elaboracin propia.

181

A.6.2. Casos de uso

Imagen 78 caso de uso - Administracin de acceso a estaciones

Fuente: Elaboracin Propia

182

Imagen 79 Caso de uso - Administracin de estaciones

Fuente: Elaboracin Propia

183

Imagen 80 Caso de uso Reportes

Fuente: Elaboracin Propia

184

A.6.3. Diagramas de secuencia

Imagen 81 Diagrama de secuencia de administracin de estaciones

Fuente: elaboracin propia.

Imagen 82 Diagrama de secuencia de reportes

Fuente: elaboracin propia.

185

A.6.4. Plantillas de requerimientos funcionales

Tabla 34 Requisito funcional para visualizar reportes tabulares con distintos niveles de agregacin y
clculos estadsticos.

Visualizar reportes tabulares con distintos niveles de agregacin y

clculos estadstico(RF2)
Requisito
RF2
Complejida Media
d
Prioridad
Descripcin

Alta
El sistema permitir la visualizacin de rasters correspondiente

Proceso
Entrada

a los parmetros que especifique.

El usuario seleccionara los parmetros de inters
Variable hidrometeorolgica.
Funcin de agregacin
Calculo

estadstico

(Mximo,

Mnimo,

desviacin

tpica,

sumatoria, caudal)
Rango de fechas de inters (Limitacin temporal)
Salida

Nivel de agregado (Mensual, Semanal, Diario, Horario)

Reporte tabular de variable hidrometeorolgica.
Fuente: elaboracin propia.

Tabla 35 Requisito funcional - Visualizacin de series temporales de las variables hidrometeorolgicas

Visualizacin

de

series

temporales

de

las

variables

hidrometeorologicashidrometeorolgicas (RF3)
Requisito
RF3
Complejidad Media
Prioridad
Alta
Descripcin
El sistema permitir visualizar series temporales de cada
Proceso
Entrada

variable hidrometeorolgica.
El usuario seleccionara los parmetros de inters
Variable hidrometeorolgica.
Sitio de inters (Identificador de estacin)

Salida

Rango de fechas de inters (Limitacin temporal)

Grfico
de
serie
temporal
para
la
hidrometeorolgica.

186

variable

Fuente: elaboracin propia.

Tabla 36 Requisito funcional para permitir la comparacin de series temporales de las estaciones
hidrometeorolgicas.

Permitir

la

comparacin

de

series

temporales

de

las

estaciones

hidrometeorologicashidrometeorolgicas (RF4)
Requisito
RF4
Complejida
Media
d
Prioridad
Descripcin

Media
El sistema

Proceso
Entrada

temporales (RF3) para cada variable hidrometeorolgica.

El usuario seleccionara los parmetros de inters
Variable hidrometeorolgica.

permitir

visualizar

comparaciones

de

series

Sitios de Inters (N cantidad de estaciones)

Salida

Rango de fechas de inters (Limitacin temporal)

Grfico comparativo de series temporales para la variable
hidrometeorolgica.
Fuente: elaboracin propia.

Tabla 37 Requisito funcional para visualizacin geogrfica de las estaciones hidrometeorolgicas.

Visualizar

geogrfica

de

las

estaciones

hidrometeorologicashidrometeorolgicas (RF5)
Requisito
RF5
Complejida Media
d
Prioridad
Descripcin

Media
Mostrar la ubicacin geogrfica de las estaciones en un mapa,
y

Proceso
Entrada
Salida

permitir

visualizar

los

datos

de

cada

variable

hidrometeorolgica que est disponible

Opcional: seleccin de estacin.
Opcional: Seleccin de la estacin hidrometeorolgica.
Estaciones hidrometeorologicas ubicadas en un mapa.
Datos de las distintas variables hidrometeorologicas de la
estacin

187

Fuente: elaboracin propia.

Tabla 38 Requisito funcional para exportar datos de cada sensor en distintos formatos

Capacidad de exportar datos de cada sensor en formatos: CSV, Excel,

PDF, Word (RF6)
Requisito
RF6
Complejida Media
d
Prioridad
Descripcin

Alta
El sistema permite exportar los datos en formatos: Word, CSV,
Excel, PDF para cada reporte tabular y grafico que se le

Proceso

presente.
El usuario seleccionara la opcin de exportar y seleccionara el

Entrada
Salida

formato deseado
Formato de salida deseado.
Archivo con datos en el formato seleccionado.
Fuente: elaboracin propia.

A.6.5. Pruebas
Tabla 39 Pruebas de concepto de usabilidad de Caelus

Conceptos de usabilidad
Identidad Corporativa
1. La portada del Sitio refleja la identidad y
pertenencia de la institucin?

Cumpl

Comentarios

e
Si
X

observaciones

2. Existen elementos de la imagen

corporativa del Gobierno en la Portada de
su Sitio? Se repiten en todas las
pginas?

3. El logotipo del Gobierno ha sido incluido

en un lugar importante en la Portada y en
las pginas interiores del Sitio?

4. Todas las pginas cuentan con un ttulo

que indique el nombre de la institucin e
informacin de contactos virtuales y

188

No

fsicos al pie de la pgina?

Utilidad de la aplicacin web

Si

No

Comentarios

observaciones
A) El Sitio ofrece informacin sobre las

actividades y servicios ms recientes e

importantes que est llevando a cabo la
institucin?
B) Los
usuarios

pueden

encontrar

fcilmente en la portada la informacin

acerca de las actividades y servicios ms
importantes de la institucin?
Navegacin

Si

No

Comentarios

observaciones
1. El diseo del Sitio es eficiente, rpido e
intuitivo?

2. Aparece el men de navegacin en un

lugar destacado? Se ve fcilmente?

3. Verific la consistencia de todos los

enlaces?

4. El Sitio cuenta con un mapa o buscador

que facilite el acceso directo a los
contenidos?

5. El Sitio mantiene una navegacin

consistente y coherente en todas las
pantallas?

Consistencia y cumplimiento de estndares

Si

No

Comentarios

observaciones
1. El HTML del Sitio ha sido validado
satisfactoriamente segn w3c.org?

2. El Sitio Web diferencia entre enlaces

visitados y enlaces por visitar?

3. Comprob la consistencia de Links

usando el verificador de w3c.org?
Esttica y diseo
189

X
Si

No

Comentarios

observaciones
1. Usa jerarquas visuales para determinar
lo importante con una sola mirada?

2. Las imgenes tienen tamaos

adecuados que no dificultan el acceso a
las pginas?

3. Las imgenes tienen etiqueta ALT en el

cdigo HTML para facilitar la navegacin?
Atencin de errores
Si

X
No

Comentarios

observaciones
1. Usa JavaScript para validar formularios
durante su llenado y antes de enviarlos?

2. Usa elementos destacados para indicar

los campos obligatorios dentro de un
formulario?

3. Despus de que ocurre un error, es fcil

volver a la pgina donde se encontraba
antes que se produjese o entrega
recomendaciones de los pasos a seguir?
Ayuda ante errores

Si

No

Comentarios

observaciones
1. En caso de errores de consistencia
dentro del sitio, se ofrece un mensaje de
personalizado mediante una pgina
explicativa?, (Por ejemplo: Error 404 para
pgina inexistente)

2. Entrega informacin de contacto fuera

de Internet? (Por ejemplo: telfono
institucional, fono 600, mesa de ayuda,
OIRS)

3. Ofrece rea de Preguntas Frecuentes

con datos de ayuda a usuarios?

4. Ofrece pginas de ayuda que explican

cmo usar el Sitio?
Retroalimentacin (Feedback)

X
Si

No

Comentarios
observaciones

1. Puede el usuario ponerse en contacto

190

con el encargado del Sitio Web para

hacer sugerencias o comentarios?
2. Funcionan correctamente los
formularios de contacto?, Ha probado
cada uno de ellos?

3. Hay alguien encargado de recibir y

contestar estos mensajes?

Fuente: elaboracin propia.

Tabla 40 Pruebas de conceptos de accesibilidad

Conceptos de Accesibilidad

1. Se proporciona un texto equivalente

para todo elemento no textual, tales
como imgenes, para explicar su
contenido a discapacitados visuales?
2. La informacin transmitida a travs de
los colores tambin est disponible sin
color?

Cumpl

Comentarios

e
Si
X

observaciones

3. El documento est estructurado para

que pueda ser ledo con o sin una hoja
de estilo, utilizando adecuadamente los
tags de HTML?

4. El documento est escrito en un

lenguaje adecuado y se deja claro
cuando se cambia de idioma?

5. Las tablas se utilizan para presentar

informacin y no para diagramar el
contenido del Sitio Web?

6. Las pginas que utilizan nuevas

tecnologas siguen funcionando cuando
dicha tecnologa no est presente (por
ejemplo, los plug-ins de Flash)?
7. Se asegura la accesibilidad de los
elementos de la pgina que tengan sus
propias interfaces? (Por ejemplo, para el
191

No

uso de Portlets)
8. Se permite al usuario activar elementos
de las pginas, usando cualquier
dispositivo como el mouse o el teclado y
no slo uno en particular?

9. Se ofrecen soluciones transitorias que

permiten a usuarios con browsers
antiguos, acceder a contenidos que han
sido creados en nuevas tecnologas?

10. Se usan las tecnologas y guas de

trabajo generadas por la W3C?

11. Se ofrece ayuda y orientacin a los

usuarios para entender pginas o
elementos complejos dentro de ellas?
(Por ejemplo: mapas y grficos)

12. Se ofrecen elementos de navegacin

claros?

13. Se asegura que los documentos que se

ofrecen a travs del Sitio son simples,
claros y pueden ser fcilmente
entendidos?

Fuente: elaboracin propia.

Tabla 41 Prueba de indexacin de buscadores de caelus

Conceptos de indexacin de buscadores

Cumpl

Comentarios u

e
Si

observaciones

1. Todos los nuevos documentos que se

agregan al Sitio Web incluyen los
campos de Metadata adecuados?
2. Cuando un usuario accede al Sitio
mediante un Link ofrecido en un buscador
y esta pgina ya no existe, se ofrece un
mensaje personalizado que le permita
encontrarla en su nueva ubicacin o le
ofrezca un contenido alternativo?
3. Tiene definido el texto que aparece en el
tag HTML <title> para indicar el Nombre
192

No
X

del Sitio o de la Institucin?

4. El Sitio ofrece un contenido adecuado
para el tag HTML META
NAME="description"?

5. El Sitio ofrece un contenido adecuado

para el tag HTML META
NAME="keywords"?
6. El Sitio ofrece un texto adecuado en el
texto que aparece en el META tag
NAME="robots"?

7. El Sitio cuenta con un archivo de texto

Robots.txt para los directorios que no se
desea indexar?

8. El Sitio est indexado en el directorio

DMOZ.org?

9. El Sitio est indexado en los buscadores

Google y Altavista(bing)?

Solamente
aparece en
google

10. Ha definido como tarea permanente la de

revisar la presencia del Sitio en
Buscadores?

11. Ha definido como tarea permanente la

realizacin de alianzas e intercambio de
enlaces con otros Sitios de instituciones
del Sector Pblico?

12. Revisa peridicamente el LOG (bitcora)

del Sitio para identificar las palabras ms
utilizadas por los usuarios para acceder a
su Sitio?

Fuente: elaboracin propia.

193

Tabla 42 Pruebas de seguridad de Caelus

SEGURIDAD

Cumple
Si
No

1. El Sitio funciona correctamente y no

presenta fallas al navegar por sus
pginas o utilizar sus servicios?
(especialmente en el caso de Trmites
en lnea)

2. Los datos ingresados por un usuario a

travs de formularios, son validados
antes de ser enviados y procesados
por el servidor del Sitio?

3. Todos los vnculos del Sitio tienen

una pgina asociada y el contenido
adecuado al vnculo sealado?

4. Frente a una bsqueda dentro del Sitio

o cualquier operacin en el mismo
los resultados se muestran
correctamente?

5. Los datos privados, entregados

voluntariamente por los usuarios, son
guardados de manera reservada?

6. Se ofrece una Poltica de Privacidad

de los Datos Personales y se informa
de su existencia en las pginas
pertinentes?

7. Los servicios ofrecidos son

realizados a travs de canales de
transaccin seguros?

8. En los temas que requieren de

accesos restringidos, el Sitio provee
algn medio para validar el acceso,
por ejemplo: a travs de una caja de
conexin con nombre de usuario y
password?

9. La poltica de seguridad

X
194

Comentarios u
observaciones

implementada para validar el acceso

restringido es adecuada a los
propsitos del servicio o de la
institucin?
10. Protege la integridad de sus
programas y datos?

11. Se evita que sea visto, el nombre de

los programas y los directorios?

12. Se cuenta con un protocolo de

X
seguridad para evitar ataques externos
e intrusiones de hackers?
13. Se cuenta con una poltica de
respaldo de informacin que permita
superar efectos de fallas derivadas del
punto anterior?

14. Se ha revisado si los sitios web que

requieran login de usuarios usan
conexiones encriptadas va HTTPS??

15. Se ha revisado si las contraseas en

el servidor son almacenadas utilizando
un hash con un salt aleatorio??

16. Se ha verificado lgica de permisos

para realizar las distintas acciones en
el sitio web? Ej.: Que usuarios
pueden borrar, crear, editar los
diferentes elementos?

17. Se han filtrado los ataques de SQL

Injection? Se recomienda utilizar
PreparedStatements/Consultas
parametrizadas para hacer consultas a
la base de datos.

18. Se han realizado respaldos de la

base de datos en forma peridica o se
han programado estos respaldos en
tareas ?

195

Tabla 43 Pruebas de rapidez de acceso de Caelus

Rapidez de Acceso

1. El usuario puede encontrar en no ms

de 3 clics la informacin buscada?
2. Aparece el men de navegacin en un
lugar destacado? Se ve fcilmente?

Cumpl

Comentarios

e
Si
X

observaciones
No

3. El Sitio cuenta con un mapa y/o

buscador que d un acceso alternativo a
los contenidos?

4. Es fcil llegar a las secciones ms

importantes del Sitio desde cualquier
pgina?

5. El Sitio mantiene una navegacin

consistente y coherente en todas sus
pginas?

6. El diseo usa jerarquas visuales para

determinar lo importante con una sola
mirada?

7. Los formularios ofrecen opciones que

permitan al usuario evitar, cancelar o
rehacer una accin?

8. El tamao de la letra de los textos es

adecuado y ajustable o modificable por el
usuario usando las herramientas del
programa visualizador?

9. Los vnculos, imgenes e conos son

claramente visibles y distinguibles?

10. Los vnculos (links) visitados y no

visitados son claramente diferenciables?

11. Los conos son representativos de la

funcin o accin que realizan y son
aclarados mediante una etiqueta ALT en
HTML?

196

12. Todas las pginas cuentan con un ttulo

que indique el nombre de la institucin e
informacin de contactos virtuales y
fsicos al pie de la pgina?

13. Provee informacin del organigrama de

la institucin?, Incluye nombres
actualizados de las autoridades y la
forma de contactarlos?
14. El nombre de la URL est vinculado con
el nombre o funcin de la institucin y se
ofrece en la barra superior del programa
visualizador?

15. Ofrece el Sitio contenidos sobre la

visin, misin, objetivos y plan estratgico
de la institucin?

16. En el caso que existan palabras tcnicas

en los contenidos del Sitio Existe una
seccin de glosario que las explique?,
es fcil llegar a l?

17. Ofrece pginas de ayuda que explican

cmo usar el Sitio Web?

18. Ofrece rea de Preguntas Frecuentes

con datos de ayuda a usuarios?

19. En caso de errores de consistencia

X
dentro del sitio, se ofrece un mensaje de
personalizado mediante una pgina
explicativa?, (Por ejemplo: Error 404 para
pgina inexistente)
Fuente: elaboracin propia.

197

A.6.6. Capturas del sistema

En la seccin de reportes grficos, podemos observar en la Imagen 83 Se nos

muestra un pequeo panel donde podemos establecer parmetros para generar
un grfico, el cual presenta un pequeo sub-men que permite exportar el
grafico en distintos formatos.

Imagen 83 Reportes grficos de Caelus.

Fuente: Elaboracin propia.

En la Imagen 84 podemos observar un reporte por estacin, en el cual tenemos

un detalle de los ltimos datos transmitidos segn sensor y un mapa con la
ubicacin de las estaciones.

198

Imagen 84 Reporte por estacin en Caelus

Fuente: elaboracin propia

199

En la Imagen 85 podemos observar la vista para el reporte de mapa de lluvia, en

el cual tenemos la visualizacin de una estimacin de la distribucin espacial de
las lluvias registradas por las estaciones. Esta estimacin se gener utilizando el
mtodo del inverso de la distancia ponderada y la cantidad de lluvia estimada
determinstico llamado inverso de la distancia ponderada.

Imagen 85 Reporte geogrfico en Caelus

Fuente: elaboracin propia

En la seccin de administracin de estaciones podemos ver los detalles de las

mismas, los cuales se muestran en la Imagen 86

200

Imagen 86 Administracin de estaciones (Detalles)

Fuente: elaboracin propia

201

En el cual podemos ver los detalles especficos de las estaciones como se

muestra en la Imagen 87

Imagen 87 Detalles de las estaciones

Fuente: elaboracin propia

202

A.7.

Anexos Sistema de Reportes

A.7.1. Caso de Uso

Imagen 88. Caso de uso - Sistema de Reportes

Fuente: Elaboracin Propia

A.7.2. Diagrama de Secuencia

Imagen 89. Diagrama de Secuencia - Sistema de Reportes

Fuente: Elaboracin Propia

203

A.7.3. Capturas de los reportes

El siguiente reporte, es el de los Metar y Sinop por rango de fechas generados
en la estacin de Managua.

Imagen 90. Reporte Metar por rango de fechas

Fuente: Elaboracin Propia

Imagen 91. Reporte Metar por rango de fechas

Fuente: Elaboracin Propia

204

En la siguiente imagen se presenta el reporte diario de todas las estaciones

convencionales principales, donde se muestra la media obtenida del da de la
temperatura mxima, temperatura mnima y la lluvia acumulada.

Imagen 92. Reporte Diario de las estaciones convencionales

Fuente: Elaboracin Propia

En la siguiente imagen se muestra el reporte del resumen mensual de la

direccin y velocidad del viento.

Imagen 93. Reporte Mensual del Viento (Direccin y Velocidad)

Fuente: Elaboracin Propia

205

En la siguiente imagen se presenta el reporte de los valores medios y extremos.

Imagen 94. Reporte de los valores medios y extremos

Fuente: Elaboracin Propia

Imagen 95. Reporte de los valores medios y extremos

Fuente: Elaboracin Propia

206

En la siguiente imagen se muestra el reporte del resumen mensual de la

evaporacin y temperatura del suelo.

Imagen 96. Reporte del Resumen Mensual de la Evaporacin y Temperatura del suelo.
Fuente: Elaboracin Propia

Imagen 97. Reporte del Resumen Mensual de la Evaporacin y Temperatura del suelo.
Fuente: Elaboracin Propia

207

En la siguiente imagen se muestra el reporte de registro de evaporacin.

Imagen 98. Reporte Registro de Evaporacin

Fuente: Elaboracin Propia

208

A.8.

Anexos Clientes IDE

La Imagen 99 muestra el dise la aplicacin web (visor) para el consumo de los

servicios WMS, comenzando por poner las referencias a las libreras a utilizar.

Imagen 99. Cdigo de visor web para consumo de geo-servicios

Fuente: Elaboracin Propia

En la Imagen 100 se muestra como con Heron se construye el panel para

renderizar mapa y se agregan las capas de los distintos tipos de mapas donde
se podr visualizar como lo son: Google Maps vista de satlite, Google Maps
vista de terreno y Open Street Map.

209

Imagen 100. Cdigo para las capas de los mapas

Fuente: Elaboracin Propia

En la Imagen 101 se muestra la funcin js para consumir el servicio WMS donde

se especifica el servidor, el almacn de datos y la capa a la cual se va a
consultar.
210

Imagen 101. Consumo de Servicio WMS con JavaScript

Fuente: Elaboracin Propia

En la siguiente imagen se muestra como se construye un panel de informacin

para el consumo del servicio WFS.

Imagen 102. Cdigo de Panel de Informacin

Fuente: Elaboracin Propia

211

En la Imagen 103 se muestra cmo se construye un nuevo estilo en GeoServer

y luego en la Imagen 104 se observa una seccin del cdigo para el estilo de
una de las capas de lluvia que sern publicadas, con la condicional que si la
lluvia es igual a 0.

Imagen 103. Construyendo SLD

Fuente: Elaboracin Propia

Imagen 104. SLD donde se asigna color #FF8C00 si es igual a 0

Fuente: Elaboracin Propia

212

En las siguientes imgenes se muestran las vistas de google terreno y open

Street maps del visor.

Imagen 105. Resultado del Visor con Vista Terreno de Google Mapas
Fuente: Elaboracin Propia

Imagen 106. Resultado de Visor Vista de Open Street Map

Fuente: Elaboracin Propia

213

A.9.

Otro Anexos

A.9.1. Configuracin y Publicacin del WMS en GeoServer

Imagen 107. Crear un Espacio de trabajo en GeoServer

Fuente: Elaboracin Propia

Imagen 108. Seleccionar espacio de trabajo Creado

Fuente: Elaboracin Propia

214

Imagen 109. Editar espacio de trabajo

Fuente: Elaboracin Propia

Imagen 110. Agregar nuevo almacn de datos

Fuente: Elaboracin Propia

215

Imagen 111. Agregar nuevo origen de datos

Fuente: Elaboracin Propia

Imagen 112. Editando el nuevo origen de datos

Fuente: Elaboracin Propia

216

Imagen 113. Agregar una nueva capa

Fuente: Elaboracin Propia

Imagen 114. Agregar una nueva capa con el nuevo espacio de trabajo y almacn de datos
Fuente: Elaboracin Propia

217

Imagen 115. Calcular los encuadres en base al SRS correspondiente

Fuente: Elaboracin Propia

Imagen 116. Capa editada para publicar

Fuente: Elaboracin Propia

A.9.2. Conexin de QGIS con el WMS

218

Imagen 117. Aadir WMS a QGIS+

219

Imagen 118. Configurar la conexin con el servidor

220

Imagen 119. Aadir capas

221

Imagen 120. Capa WMS desde QGIS

222