diseÑo e implementacion de un banco de imagenes
TRANSCRIPT
DISEÑO E IMPLEMENTACION DE UN BANCO DE IMAGENES
PROVENIENTES DE SENSORES REMOTOS PERTENECIENTES AL
INSTITUTO DE HIDROLOGÍA, METEOROLOGÍA Y ESTUDIOS AMBIENTALES
(IDEAM) COMO APOYO A CONSOLIDACIÓN DE LA POLÍTICA NACIONAL DE
INFORMACIÓN GEOGRÁFICA
ROBERT ANDRÉS PULIDO ARIAS CAMILO ANDRÉS PORRAS MARTIN
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA
INGENIERÍA CATASTRAL Y GEODESIA BOGOTÁ D.C.
2017
ii
DISEÑO E IMPLEMENTACION DE UN BANCO DE IMAGENES
PROVENIENTES DE SENSORES REMOTOS PERTENECIENTES AL
INSTITUTO DE HIDROLOGÍA, METEOROLOGÍA Y ESTUDIOS AMBIENTALES
(IDEAM) COMO APOYO A CONSOLIDACIÓN DE LA POLÍTICA NACIONAL DE
INFORMACIÓN GEOGRÁFICA
ROBERT ANDRÉS PULIDO ARIAS CAMILO ANDRÉS PORRAS MARTIN
Proyecto de Grado en modalidad de monografía para optar por el título de: Ingeniero Catastral y Geodesta
Director: Ing. MsC. LUZ ÁNGELA ROCHA SALAMANCA
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA
INGENIERÍA CATASTRAL Y GEODESIA BOGOTÁ D.C.
2017
iii
Nota de aceptación _______________________ _______________________ _______________________ _______________________ _______________________ _______________________ _______________________ _______________________ _______________________ _______________________
_____________________________
Firma del director
_____________________________ Firma del jurado
Bogotá D.C., día del mes de 2017
iv
AGRADECIMIENTOS
Agradecemos en primer lugar a Dios por permitirnos llegar a este punto de
nuestras vidas.
A la Universidad Distrital Francisco José de Caldas por brindarnos los
conocimientos y espacios necesarios de aprendizaje para lograr nuestros
objetivos.
A nuestra directora de proyecto, Luz Ángela Rocha por el apoyo y conocimientos
brindados para el desarrollo de este proyecto y a lo largo de nuestra carrera.
Al Ing. MsC. Salomón Einstein Ramírez, por el apoyo, seguimiento y consejos que
nos brindó durante todo el proyecto.
Al Instituto de Hidrología, Meteorología y Estudios Ambientales (IDEAM), y en
especial a Patricia León por permitirnos desarrollar este proyecto junto al Instituto.
A nuestros compañeros Edison Robles, José García y David Garzón por
apoyarnos con los conocimientos en informática necesarios para el desarrollo del
prototipo.
Y finalmente a nuestras familias por el apoyo incondicional durante toda nuestra
carrera.
v
CONTENIDO
GLOSARIO ........................................................................................................................................1
INTRODUCCIÓN ..............................................................................................................................3
1. PLANTEAMIENTO DEL PROBLEMA ..................................................................................6
1.1 CONTEXTO SOCIAL .............................................................................................................7
1.2 CONTEXTO ECONÓMICO: .................................................................................................7
1.3 CONTEXTO TECNOLÓGICO: .............................................................................................8
2 OBJETIVOS ...............................................................................................................................9
OBJETIVO GENERAL .................................................................................................................9
OBJETIVOS ESPECÍFICOS .......................................................................................................9
3 MARCO CONCEPTUAL ....................................................................................................... 10
3.1 INFRAESTRUCTURAS DE DATOS ESPACIALES (IDES) ........................................ 10
3.2 BANCO DE IMÁGENES .................................................................................................... 12
3.3 VISORES GEOGRÁFICOS ............................................................................................... 13
3.4 MARCO INSTITUCIONAL ................................................................................................. 14
3.5 POLÍTICAS........................................................................................................................... 14
3.6 TECNOLOGÍAS Y ESTÁNDARES .................................................................................. 15
3.7 METADATO ......................................................................................................................... 16
3.7 BANCO DE DATOS ........................................................................................................... 16
3.8 OBJETOS PARA UNA BASE DE DATOS ESPACIAL ................................................ 17
4 ESTADO DEL ARTE ............................................................................................................. 18
4.1 CONTEXTO NACIONAL.................................................................................................... 18
4.1.1 Banco Nacional de Imágenes ................................................................................. 18
4.1.2 IGAC............................................................................................................................... 20
4.1.3 Servicio Geológico Colombiano ............................................................................ 21
4.1.4 Agencia Nacional de Hidrocarburos ..................................................................... 22
4.1.5 Unidad de Planeación Minero-Energética ........................................................... 23
4.1.6 Unidad de Victimas .................................................................................................... 24
4.2 CONTEXTO INTERNACIONAL........................................................................................ 25
4.2.1 United States Geological Survey ........................................................................... 25
vi
4.2.2 Instituto Geográfico Nacional de España ............................................................ 26
5 METODOLOGÍA .................................................................................................................... 27
5.1 METODOLOGÍA DE DESARROLLO DE SOFTWARE ............................................... 27
5.1.1 Desarrollo SCRUM ..................................................................................................... 32
5.2 METODOLOGÍA DE DESARROLLO DEL PROTOTIPO ............................................ 33
5.2.1 Clasificación de los Datos ....................................................................................... 34
6. DESARROLLO DE PROTOTIPO ....................................................................................... 36
6.1 DIRECTORIO DE CARPETAS ......................................................................................... 37
6.2 BASE DE DATOS ............................................................................................................... 38
6.2.1 Modelo Entidad Relación ......................................................................................... 38
6.2.2 Modelo Conceptual .................................................................................................... 41
6.2.3 Modelo Lógico ............................................................................................................ 42
6.2.4 Modelo Físico .............................................................................................................. 43
6.2.5 Script SQL .................................................................................................................... 44
6.2.6 Motor de la Base de Datos ....................................................................................... 45
6.2.7 Controlador de Base de Datos ............................................................................... 46
6.2.8 Consulta y Peticiones a la Base de Datos ........................................................... 49
6.2.9 Vista ............................................................................................................................... 51
6.3 IMPLEMENTACIÓN DEL BANCO DE IMÁGENES ...................................................... 53
6.4 VALIDACIÓN DEL PROTOTIPO ..................................................................................... 53
8. RESULTADOS ....................................................................................................................... 54
8.1 DEFINICIÓN DE USUARIOS DE LA INFORMACIÓN ............................................ 54
8.1.1 Subdirección de Ecosistemas E Información Ambiental ................................ 55
8.1.2 Sistema de Monitoreo de Bosques y Carbono (SMBYC) ................................ 56
8.1.3 Subdirección de Hidrología ..................................................................................... 57
8.1.4 Oficina del Servicio de Pronósticos y Alertas .................................................... 58
8.2 REQUERIMIENTOS ........................................................................................................... 58
8.2.1 Reglas de Negocio ..................................................................................................... 59
8.2.2 Determinación de los Actores ................................................................................ 61
8.2.3 Requerimientos Funcionales .................................................................................. 62
8.2.4 Casos de Uso .............................................................................................................. 64
8.2.5 Requerimientos No Funcionales o Especificaciones Suplementarias ........ 65
vii
9. PROTOTIPO ........................................................................................................................... 69
9.1 INICIO DE SESIÓN (LOGIN) ............................................................................................ 69
9.2 FUNCIONALIDADES DEL PROTOTIPO ........................................................................ 71
9.2.1 Tipos de Consultas .................................................................................................... 71
CONCLUSIONES .......................................................................................................................... 86
BIBLIOGRAFÍA .............................................................................................................................. 90
ANEXOS .......................................................................................................................................... 94
viii
LISTA DE ILUSTRACIONES
Ilustración 1. Banco Nacional de Imágenes. .............................................................................. 19
Ilustración 2. Geoportal IGAC. ..................................................................................................... 20
Ilustración 3. Visor Amenazas Sísmicas. ................................................................................... 21
Ilustración 4. Geovisor ANH. ........................................................................................................ 22
Ilustración 5. Visor General UPME. ............................................................................................. 23
Ilustración 6. Visor Geográfico de Víctimas. .............................................................................. 24
Ilustración 7. Visor EarthExplorer. ............................................................................................... 25
Ilustración 8. Visor Geográfico. .................................................................................................... 26
Ilustración 9. Ciclo principal de SCRUM. Fuente: (Palacios, 2009) ....................................... 33
Ilustración 10. Metodología desarrollada. Fuente: Propia ....................................................... 34
Ilustración 11. Estructura modelo vista- controlador. Fuente: Propia .................................... 36
Ilustración 12. Modelo de directorio de carpetas. Fuente: Propia .......................................... 38
Ilustración 13. Modelo entidad relación. Fuente: Propia .......................................................... 40
Ilustración 14. Modelo conceptual. Fuente: Propia ................................................................... 41
Ilustración 15. Modelo lógico. Fuente: Propia ............................................................................ 42
Ilustración 16. Modelo físico. Fuente: Propia ............................................................................. 43
Ilustración 17. Ejemplo script. Fuente: Propia ........................................................................... 44
Ilustración 18. Base de Datos en Oracle 11 G, Fuente: Propia .............................................. 45
Ilustración 19. Interfaz Netbeans 8.1. Fuente: Netbeans ........................................................ 46
Ilustración 20. Ejemplo Servlet. Fuente: Netbeans. .................................................................. 47
Ilustración 21. Definición de cada una de las carpetas dentro del prototipo. Fuente: Propia
.......................................................................................................................................................... 48
Ilustración 22. Servlets creados en el prototipo. Fuente: Netbeans. ..................................... 48
Ilustración 23. Estructura Entidad DAO Fuente: Netbeans ..................................................... 49
Ilustración 24. Petición Fuente: Netbeans.................................................................................. 50
Ilustración 25. Conexión Fuente: Netbeans ............................................................................... 50
Ilustración 26. Obtención de la informacion Fuente: Netbeans. ..................................................... 51
Ilustración 27. Archivo jsp desde NetBeans. Fuente: Netbeans. ........................................... 52
Ilustración 28. Archivo ccs en NetBeans. Fuente: Netbeans. ................................................. 52
Ilustración 29. Archivo js en NetBeans. Fuente: Netbeans. .................................................... 52
Ilustración 30. Dependencias donde se encuentras los usuarios de la información. Fuente:
Propia ............................................................................................................................................... 54
Ilustración 31. Estructura Jerárquica de los usuarios Internos. Fuente: Propia ................... 55
Ilustración 32. Información atributiva más relevante encontrada en el inventario. Fuente:
Propia ............................................................................................................................................... 56
Ilustración 33. Diagrama de Casos de Uso. .............................................................................. 65
Ilustración 34. Login del prototipo. Fuente Propia .................................................................... 69
Ilustración 35. Estructura Login Fuente: Propia ........................................................................ 70
Ilustración 36 Mensaje de Error Login Fuente: Propia ............................................................. 71
Ilustración 37. Estructura principal prototipo Fuente: Propia. ................................................. 72
ix
Ilustración 38. Consulta por atributos. Fuente Propia .............................................................. 73
Ilustración 39. Estructura Inicial Consulta por Atributo. Fuente: Propia. ............................... 73
Ilustración 40. Imágenes Consultadas por atributos Fuente Propia. ..................................... 74
Ilustración 41. Visualización preliminar Imagen Fuente: Propia. ............................................ 75
Ilustración 42. Descarga de la Imagen Fuente: Propia. ........................................................... 76
Ilustración 43. Metadato de la imagen en Geonetwork Fuente: Geonetwork ....................... 76
Ilustración 44. Consulta por grilla. Fuente Propia. .................................................................... 77
Ilustración 45. Estructura Principal de la Consulta por Grilla. Fuente: Propia ...................... 78
Ilustración 46. Visualización Grilla RapidEye. Fuente: Propia. ............................................... 79
Ilustración 47. Visualización grillas Landsat Fuente: Propia. .................................................. 79
Ilustración 48. Visualización Pop-up de información Fuente Propia. ..................................... 80
Ilustración 49. Consulta por Mapa. Fuente: Propia .................................................................. 81
Ilustración 50. Consulta por Departamento Fuente: Propia. ................................................... 82
Ilustración 51. Resultado de consulta por Departamento Fuente: Propia. ........................... 82
Ilustración 52. Consulta por Municipio Fuente: Propia. ............................................................ 83
Ilustración 53. Resultado consulta por Municipio Fuente: Propia. ......................................... 83
Ilustración 54. Consulta por Punto en mapa Fuente: Propia ................................................... 84
Ilustración 55. Visualización Imágenes consultadas por punto en mapa Fuente: Propia. . 84
Ilustración 56. Consulta por Coordenadas Fuente: Propia. ..................................................... 85
Ilustración 57. Visualización de la Imagen. Fuente: Propia. .................................................... 85
x
LISTA DE TABLAS
Tabla 1. Ventajas y desventajas metodologías de IS. Fuente: Propia .................................. 31
Tabla 2. Propuesta formato inventario de imágenes. Fuente: Propia ................................... 35
Tabla 3. Definición de Administrador Global. ............................................................................ 61
Tabla 4. Definición de Administrador Temporal. ....................................................................... 62
Tabla 5. Definición de Usuario Interno........................................................................................ 62
Tabla 6. Requerimientos Funcionales. ....................................................................................... 64
Tabla 7. Requerimientos No Funcionales .................................................................................. 68
1
GLOSARIO
ANH: Agencia Nacional de Hidrocarburos.
BD: Base de Datos.
BDE: Base de Datos Espacial.
BNI: Banco Nacional de Imágenes.
CONPES: Consejo Nacional de Política Económica y Social.
DANE: Departamento Administrativo Nacional de Estadística.
DNP: Departamento Nacional de Planeación.
EE: Earth Explorer.
ESRI: Environmental Systems Research Institute.
FK: Foreign Key (Llave Foránea).
GSDI: Global Spatial Data Infrastructure.
ICDE: Infraestructura Colombiana de Datos Espaciales.
IDE: Integrated Development Environment (Ambiente de Desarrollo Integrado).
IDEAM: Instituto de Hidrología, Meteorología y Estudios Ambientales de Colombia.
IGAC: Instituto Geográfico Agustín Codazzi.
ISO: International Organization for Standardization.
NTC: Norma Técnica Colombiana.
PK: Primary Key (Llave Primaria).
REST: Representational State Transfer.
RINEX: Receiver INdependent EXchange.
SAAI: Sistema de Administración y Almacenamiento de Imágenes.
SGC: Servicio Geológico Colombiano.
SINA: Sistema Nacional Ambiental.
SQL: Structured Query Language. (Lenguaje de Consulta Estructurada).
UPME: Unidad de Planeación Minero Energética.
USGS: United States Geological Survey.
2
WCS: Web Coverage Service.
WFS: Web Feature Service.
WMS: Web Map Service.
3
INTRODUCCIÓN
El gobierno Nacional en la última década ha venido concientizándose de la
importancia del uso y acceso a la información geográfica para la toma de
decisiones a nivel, local, regional y nacional. Es por esta razón que en el año
2009 se dan los lineamientos para el desarrollo de una política para la gestión
de información geográfica a través del documento CONPES 3585, el cual
menciona consolidar el Banco Nacional de Imágenes enmarcado en la Política
Nacional de Información Geográfica PNIG.
Para optimizar la inversión del Estado en la adquisición y uso de imágenes
provenientes de sensores remotos satelitales y aerotransportados, se
consolidará el Banco Nacional de Imágenes, bajo la administración del
IGAC, el cual dispone de un sistema eficaz de catalogación, archivo y
distribución de las mismas, y permite el acceso y uso controlado por las
entidades estatales, así como la coordinación de nuevas adquisiciones
que enriquezcan la información disponible en el Banco en beneficio de las
entidades usarías de la IG. (CONPES 3585, pág.7)
Es así como nace la necesidad para las diferentes instituciones, en especial
aquellas de carácter público, el administrar, guardar y compartir las imágenes
provenientes de sensores remotos, las cuales actualmente son un insumo
importante para la generación de datos espaciales para la toma de decisiones.
El publicar dicha información les permite a los productores y a los usuarios en
general, conocerlas, visualizarlas y utilizarlas en su quehacer diario. Para ello,
es necesario saber cómo se está administrando, cómo se gestionan los datos
geográficos, el lugar físico o virtual tanto dónde se almacenan y el cómo
consultarlo, además de cuál es la mejor manera de mostrar este tipo de
4
información, basados en los requerimientos y en lo que busca el público o
usuarios de dicha información.
En Colombia con iniciativas tales como la creación de la Infraestructura
Colombiana de Datos Espaciales ICDE se da paso a la estandarización y
generación de políticas para la gestión, acceso y uso de los datos geográficos.
Es así como según el Acuerdo número 1 del año 2000, en el cual las principales
entidades públicas (DANE, IGAC, IDEAM, ECOPETROL, DNP, INGEOMINAS y
la Federación Nacional de Cafeteros.) se reunieron para la creación, definición y
estructuración de los lineamientos generales, marco de cooperación
coordinación y operación para el manejo e intercambio de la información
geográfica producida o de propiedad de cada una de las entidades vinculadas,
quedando instaurada así la ICDE la cual se formalizó en el Documento CONPES
3585 en el año 2009.
Bajo los lineamientos dados por el ICDE y el concepto del Banco Nacional de
Imágenes las instituciones buscan la optimización de su inversión a la hora de
adquirir imágenes provenientes de sensores remotos bajo un sistema eficaz y
sencillo de catalogación, almacenamiento y descarga de las mismas, que
permita el acceso seguro por parte de la entidad y así mismo la coordinación de
nuevas adquisiciones que enriquezcan la información que posee la institución.
En ese sentido el objetivo principal de este proyecto es la estructuración de un
Banco de imágenes provenientes de sensores remotos para el Instituto de
Hidrología, Meteorología y Estudios Ambientales de Colombia IDEAM, a partir
de una base teórica y metodológica para el diseño, implementación de un
prototipo, con imágenes existentes en la entidad, con el fin de que se puedan
visualizar y descargar por cualquier usuario a través de la red desde un visor
5
geográfico institucional. Con este proyecto se busca igualmente, la
estructuración masiva de las imágenes que posee el IDEAM, para poder
controlar la gestión de la información, actividad que es relevante para esta
Institución, pues es la que proporciona apoyo científico al Sistema Nacional
Ambiental.
6
1. PLANTEAMIENTO DEL PROBLEMA
En Colombia desde los años 90 se ha venido produciendo información
geográfica a partir de diferentes fuentes. Sin embargo y teniendo en cuenta que
las Organizaciones requieren compartir datos, los cuales a menudo son
incompatibles porque no han sido generados de la misma forma con los mismos
estándares, se requirió generar herramientas para la gestión de los datos
espaciales. Es así como desde principio del siglo XXI se crearon las
Infraestructuras de Datos Espaciales, las cuales han ayudado a establecer las
políticas y los estándares para la gestión de la información geográfica, donde se
determinó que es necesario conocer la información geográfica con que cuenta el
país para su desarrollo; siendo uno de los lineamientos que se debe consolidar
el Banco Nacional de Imágenes, por lo cual las instituciones deben tener claro
con cuáles imágenes cuentan para optimizar la inversión y poder disponerlas y
compartirlas con las otras entidades que la requieran. (CONPES 3585, 2009).
En ese sentido el IDEAM siendo una de las Instituciones a nivel nacional que
cuenta con un volumen considerable de Imágenes provenientes de sensores
remotos requiere almacenar, administrar y compartir dicha información de la
manera más fácil posible y al mismo tiempo reducir problemas en duplicidad,
perdida de datos y almacenamiento; de esta forma podrá incrementar el uso y
disposición de dichos datos como miembro del ICDE. Con la realización de este
proyecto de grado se pretende solucionar el problema del IDEAM en cuanto a la
gestión y estandarización de las imágenes provenientes de sensores remotos
enmarcadas en las políticas definidas por ICDE.
7
1.1 CONTEXTO SOCIAL
Actualmente el IDEAM cuenta con imágenes tomadas desde los años 90
provenientes de sensores remotos, donde el manejo y manipulación de las
mismas por parte de los usuarios puede resultar muy compleja, por la cantidad
de información que estas almacenan y porque no se cuenta con un Banco de
imágenes que permita consultar, acceder y disponer los datos de manera
sencilla. En ese sentido la realización de este proyecto en el ámbito social, está
fundamentado en brindar al IDEAM un mecanismo de acceso a las imágenes
utilizando herramientas tecnológicas que permitan la consulta y descarga de la
información de manera más fácil y rápida, con el fin de apoyar las funciones que
tiene la institución en especial la que se centra en suministrar conocimientos,
datos y la información ambiental que requieren el Ministerio del Medio Ambiente
y demás entidades del Sistema Nacional Ambiental (SINA) como iniciativa para
la construcción de ciudades más dinámicas e inteligentes.
1.2 CONTEXTO ECONÓMICO:
Por otro lado, el IDEAM mantiene una constante adquisición de imágenes de
satélite de diversas fuentes, debido a que dicha información es muy valiosa para
cumplir con su misión por lo cual el no tener la información debidamente
almacenada, organizada y disponible, conlleva a gastos innecesarios ya sea por
adquirir imágenes ya existentes, debido al desconocimiento de donde se
encuentra dicha información, generando así duplicidad y redundancia. Por
consiguiente, con la realización de este proyecto el Banco de imágenes,
garantizará la efectividad en la búsqueda y almacenamiento de las mismas por
los diferentes usuarios.
8
1.3 CONTEXTO TECNOLÓGICO:
En cuanto al uso de la tecnología es importante resaltar que las Instituciones
que poseen y manejan grandes volúmenes de información como en este caso
el IDEAM requieren la implementación de un Banco de Imágenes utilizando las
herramientas tecnológicas que nos ofrece actualmente la Geomática para que
este accesible y disponible a través de la red o cualquier otro medio
tecnológico, con el uso de estas Geotecnológias se suplen varios problemas en
cuanto a la perdida de información y la perdida de recursos.
9
2 OBJETIVOS
OBJETIVO GENERAL
Diseñar e implementar un Banco de Imágenes provenientes de sensores remotos
en el marco de la política nacional de información geográfica.
OBJETIVOS ESPECÍFICOS
Realizar el diagnóstico de las imágenes provenientes de sensores remotos
existentes en el IDEAM.
Diseñar el modelo conceptual del Banco de Imágenes provenientes de
sensores remotos.
Desarrollar e Implementar un prototipo de Banco de Imágenes
provenientes de sensores remotos.
Validar el prototipo de Banco de Imágenes provenientes de sensores
remotos.
10
3 MARCO CONCEPTUAL
A continuación se darán a conocer algunas de las conceptos relevantes para el
logro de los objetivos de este proyecto, así como también darle al lector un
contexto de los temas que se podrán encontrar.
3.1 INFRAESTRUCTURAS DE DATOS ESPACIALES (IDES)
Las Infraestructuras de Datos Espaciales IDES nacen en el año 1984 con el fin
de crear un conjunto de políticas, estándares y recursos tecnológicos que
facilitan el acceso y uso de la información espacial, como apoyo al desarrollo
social, económico y ambiental, a nivel local, regional y nacional. Las IDES se
pueden definir como una herramienta para facilitar el acceso y el uso
responsable de la información geográfica a un costo abordable para soportar el
manejo sostenible de las tierras. (Groot, 1997). Una IDE es el marco de acción
en el cual interactúan las organizaciones y la tecnología para promover la
producción, la gestión y el uso más eficiente de los datos geoespaciales.
(Federal Geographic Data Committee, 1993). Las IDES, entonces tienen cuatro
componentes básicos: las políticas, los estándares, los datos y la tecnología.
[…]Para lograr los objetivos, las iniciativas deben ser firmes y
consensuadas. Para ello se consideran cuatro componentes esenciales en
una IDE: el marco institucional que permita la creación y el mantenimiento
eficaz de la IDE, unas políticas de datos que promuevan la creación y
accesibilidad a datos de referencia esenciales, la tecnología necesaria
11
para el funcionamiento del sistema y los estándares correspondientes para
que la información pueda ser compartida por los diferentes agentes sin
problemas. […](Capdevila, 2004, Pág. 2).
Las IDES tienen como funciones principales:
- Compartir información espacial a través del gobierno en todos los niveles:
público, privado y académico
- Difundir y distribuir la información de una forma homogénea
- Encontrar la información en una Base de datos estandarizada
- Utilizar herramientas tecnológicas para el acceso y uso de los datos
geográficos
Las IDES se pueden implementar a diferentes niveles: corporativa, local,
regional, nacional y Global. En Colombia la infraestructura de Datos a nivel
nacional es la ICDE, a la cual pertenecen todas las instituciones públicas de
carácter nacional como son, entre otras: El Instituto Geográfico Agustín
Codazzi (IGAC) quien es el coordinador, Ministerio de Ambiente y Desarrollo
Sostenible – MinAmbiente, Unidad de Planeación Minero Energética – UPME,
Instituto Nacional de Vías – INVIAS, Universidad Distrital Francisco José de
Caldas.Ministerio de Transporte – Mintrasporte, Comando General de las
Fuerzas Militares de Colombia,Instituto Amazónico de Investigaciones
Científicas – SINCHI,Instituto de Investigaciones Marinas y Costeras -
INVEMAR, Agencia Nacional de Hidrocarburos – ANH, Unidad Nacional para
la Gestión del Riesgo de Desastres, Unidad de Planificación de Tierras
Rurales, Adecuación de Tierras y Usos Agropecuarios, UPRA, Servicio
Geológico Colombiano- SGC, Ministerio de Tecnologías de la Información y las
Comunicaciones – MINTIC y el Instituto de Hidrología, Meteorología y Estudios
Ambientales – IDEAM.
12
La Infraestructura Colombiana de Datos Espaciales - ICDE se define como
un órgano de articulación, que gestiona la producción y el acceso a la
información geográfica, a través de acciones coordinadas entre el
Gobierno y la Sociedad, que promueven la implementación de políticas, la
estandarización y el desarrollo de estrategias orientadas a la accesibilidad
e interoperabilidad de recursos geoespaciales, como base para la toma de
decisiones (ICDE, 2016).
3.2 BANCO DE IMÁGENES
Con la aparición de las tecnologías de la información y las comunicaciones, las
imágenes ya no solo se están guardando en fototecas, archivos o bibliotecas sino
que también se están empezando a almacenar en los Bancos de imágenes
(DOUCET, 2009); estos Bancos de imágenes son denominados también bases de
datos de imágenes, poseen la información primaria que son las imágenes como
también información secundaria como son los metadatos (o registros descriptivos
de la información registrada, en este caso imágenes). (Codina y Palma, 2001)
La historia sobre los Bancos de imágenes se centra en que estos forman parte de
la denominada industria de la información electrónica junto con las bases de datos
científicas y académicas generando una actividad de negocio alrededor de los
servicios de búsqueda avanzados e información de valor añadido en forma de
categorizaciones conceptuales sofisticadas y metadatos descriptivos (Jaramillo y
Dolores, 2010).
El Banco de imágenes es el foco del sistema que distribuirá las imágenes ya se a
una institución pública o privada y en este punto debemos hacer una
13
diferenciación ya que el Banco de imágenes no es un motor de búsqueda, esto
especificando que un motor de búsqueda no posee los documentos secundarios
que si posee el Banco. (Codina y Palma, 2001)
En ese sentido un Banco de imágenes tiene tres funciones principales, (Lissalde,
2001):
Es una herramienta para almacenar, gestionar y salvar las imágenes, ya
que en un futuro podemos encontrar estas imágenes.
Es una herramienta de trabajo para los investigadores, ya que estas
imágenes sirven para análisis de investigación posteriores.
Es una herramienta de valorización tanto para públicos especializados
como públicos en general.
3.3 VISORES GEOGRÁFICOS
Un visor geográfico o cartográfico, es una herramienta web para la visualización
de mapas interactivos, donde existe la posibilidad de combinar múltiples variables
geográficas, actualmente son muy usados a modo de consulta, debido a que ya no
son de uso exclusivo de los profesionales en Geomática, sino que son de acceso
para un público general. (GeoIngenio, 2012)
Según el Mitchell, (2005) algunas características generales para la creación de
visores geográficos de Bancos de imágenes provenientes de sensores remotos
son:
- Generación de mapas
- Superposición visual de capas de datos espaciales en formato raster o
vectorial.
14
- Capacidad de dar respuesta a peticiones relacionadas con información
temática descriptiva asociada a los datos espaciales que son visualizados,
- Capacidad de Geoprocesamiento en cuanto a cambios de proyección
geográfica, inserción y edición de nuevos elementos espaciales
- Gestión de bases de datos alfanuméricas asociadas.
3.4 MARCO INSTITUCIONAL
Dependiendo la institución en la que se desee implementar esta tecnología de
Banco de imágenes, se deberá definir el tipo de acceso a la información;
estableciendo si será de libre acceso para todas las dependencias de la institución
o en caso diferente que sea restrictivo en algunos aspectos o que posea
información de acceso restringido; estos parámetros iniciales se ven ya que la
implementación de un Banco de imágenes exige una forma de visualización
directa, ya sea por medio de una interfaz gráfica o de un Geoportal, puesto que lo
que se busca es el acceso rápido y dinámico de la información que se está
estructurando y organizando.
3.5 POLÍTICAS
Como se dijo anteriormente uno de los componentes de la ICDE son las políticas
de información geográfica, la cuales están relacionadas en el documento
CONPES 3585. Estas políticas dan los lineamientos para la gestión eficiente de la
IG en Colombia entre los cuales se encuentra la creación de un Banco Nacional
de Imágenes. En ese sentido igualmente las instituciones que lo requieran
15
igualmente pueden implementar Bancos de imágenes institucionales con el fin de
apoyar la PNIG, como es el caso del IDEAM.
Por otro lado, para que un Banco de imágenes pueda funcionar, es necesario
conocer las políticas internas de la institución para la puesta en marcha del
proyecto, en este caso el IDEAM, ya que estas políticas dan los lineamientos
particulares de la presentación de prototipos, como también los generales a los
que se debe acoger este proyecto para la presentación; esto permitirá definir la
transparencia de acceso a los datos que se utilizarán y en dado caso a las
licencias de software que vayan a ser usadas. Por consiguiente conocer las
normas y políticas de la institución permitirá que a la hora del modelamiento e
implementación del Banco de Imágenes inconsistencias debido a que no se
cumplen con las políticas instauradas del IDEAM.
3.6 TECNOLOGÍAS Y ESTÁNDARES
En las IDES otros componentes importantes son las tecnologías y los estándares.
En ese sentido tecnológicamente fundamentalmente se utiliza el internet como
soporte y medio de comunicación al Banco de Imágenes para las diferentes
dependencias por lo que es necesario implementar tecnologías como servidores
además de Bases de Datos las cuales almacenan la información más relevante.
En relación a los estándares, es necesario estandarizar los datos en una IDE, por
esta razón la Organización Internacional de Estandarización (ISO), ha generado
una conjunto de normas para información geográfica entre la que se encuentra la
norma ISO 19115 de metadatos de información espacial (Ariza, Et al, 2008), la
cual fue usada para generar los metadatos de las imágenes almacenadas en el
16
Banco y por consiguiente se establecerá una estructuración de información
pertinente. Para este proyecto también se tendrá como guía la norma colombiana
de Metadatos NTC 4611 con el fin de seguir los lineamientos nacionales.
3.7 METADATO
La definición de metadato más conocida es datos sobre los datos, ya que
proporciona la información necesaria para poder identificar el recurso que
representa (Agudelo, 2013). Algunos autores generan definiciones más amplias al
querer incluir dentro del metadato información como el contexto, el contenido y el
control, esto con el fin de alcanzar objetivos como describir identificar y definir un
recurso para recuperar, filtrar e informar sobre licenciamiento y condiciones de
uso, autentificación y evaluación, preservación e interoperatividad (Caplan, 1995).
3.7 BANCO DE DATOS
Un Banco de Datos Espacial permite describir y almacenar los objetos espaciales
que lo forman a través de características como lo son atributos, localización y
topología. Los atributos son características de los objetos que permiten saber qué
es lo que representan. La localización representa la ubicación espacial de acuerdo
a un sistema de referencia, permite saber dónde está el objeto y qué espacio
ocupa.
Para la elaboración de las bases de datos que harán parte de nuestro Banco de
Imágenes, será necesario la utilización de herramientas como servidores y
gestores de bases de datos. Principalmente para incorporar una base de datos
espacial a una infraestructura de datos espaciales (IDE), esta debe estar
17
desarrollada siguiendo los estándares para la descripción, definición espacial,
operación y acceso a información geográfica.
3.8 OBJETOS PARA UNA BASE DE DATOS ESPACIAL
Algunas herramientas necesarias para el correcto funcionamiento de las bases de
datos espaciales y por tanto para el Banco de imágenes son los motores de bases
de datos espaciales, los cuales permitirán la cimentación del proyecto. Las bases
de datos espaciales adoptan estos estándares utilizando como lenguaje básico
SQL (Lenguaje de Consulta Estructurada), sin embargo, cada uno de los motores
puede trabajan de diferentes maneras y ofrecen una serie de características que
pueden ser muy útiles según sean los parámetros definidos dentro de las reglas
de negocio.
Si se desea acceder a las imágenes de satélite desde un Banco de datos
espaciales en este caso imágenes de satélite, se requiere que este Banco adopte
también estándares de definición de objetos geométricos y de operadores y
funciones para el tratamiento de los datos (Manozalvas, 2014).
18
4 ESTADO DEL ARTE
Debido a los grandes avances en cuestión de tecnologías y estándares tanto a
nivel nacional como a nivel internacional en la administración y manejo de la
información geográfica, es necesario conocer la vanguardia de la gestión de
imágenes provenientes de sensores remotos, por ello a continuación se mostrarán
los diferentes Geovisores y portales geográficos más representativos.
4.1 CONTEXTO NACIONAL
4.1.1 Banco Nacional de Imágenes
El Banco Nacional de Imágenes nace al igual que este proyecto primordialmente
por el manejo de información proveniente de sensores remotos, información que
ha sido recolectada en el trascurso de los años y con el fin de evitar duplicidad de
información e incurrir en gastos innecesarios de recursos por parte de las distintas
entidades, además de buscar la regulación de los procesos de producción,
adquisición, documentación, acceso y uso de la información geográfica.
El Banco Nacional de Imágenes también se define como un conjunto de políticas,
organizaciones, estándares y tecnologías que buscan la producción, el uso y el
compartir la información geográfica. (BNI, 2016). Como se mencionó
anteriormente el BNI está conformado por entidades (IGAC, DANE, IDEAM,
Ingeominas, DNE, Policía Nacional, DNP, entre otros) que a través de convenios
interinstitucionales y acogiendo a la normativa del BNI están dispuestos a adoptar
e implementar la plataforma tecnológica que permitirá consultar, catalogar y
19
distribuir imágenes producto de sensores remotos. Con estas mismas medidas se
busca implementar internamente en el IDEAM el Banco de Imágenes, con el fin de
permitir la adquisición de este nuevo tipo de tecnologías y que responda a los
lineamientos nacionales. Algunas de las metodologías que debe cumplir el BNI y
que por consiguiente es base para este Banco de imágenes son, regular y
administrar la toma, adquisición, organización, distribución, acceso y uso de las
imágenes de sensores remotos del país, y que el IGAC a través de la subdirección
de Geografía y Cartografía, realizara las funciones de administración y
mantenimiento del BNI.
Ilustración 1. Banco Nacional de Imágenes. Fuente: BNI (2016). Recuperado de: http://bni.igac.gov.co:81/home/srv/es/main.busqueda
20
4.1.2 IGAC
El segundo referente que podemos encontrar en Colombia para visor geográfico,
se encuentra dentro del IGAC el cual es el Geoportal, este proporciona un sin
número de funcionalidades e información, como por ejemplo mostrar datos RINEX
(fichero de texto orientado a almacenar y estandarizar datos GPS, GLONASS,
EGNOS, WAAS o Galileo.), estaciones, información de Catastro, Geodesia,
MAGNA-ECO, Planchas, Agrología, Relieve; también permite hacer búsquedas
detalladas por filtros, en este caso podemos diferencias por departamentos y
municipios. La visualización de este lo podemos ver en la Ilustración 2.
Ilustración 2. Geoportal IGAC. Fuente: IGAC (2017). Recuperado de http://ssiglwps.igac.gov.co/ssigl2.0/visor/galeria.req?mapaId=17
21
4.1.3 Servicio Geológico Colombiano
A través de su geoportal el servicio Geológico ofrece varias categorías
(Geociencias básicas, Recursos Minerales, Geoamenazas, Gestión de
Información) donde se encuentran un sin número de temas relacionados cada uno
con un visor geográfico. La finalidad y desarrollo de este geoportal está dada por:
[…] Presentar a los usuarios la información generada por Geociencias
Básicas, Recursos Minerales, Geoamenazas, Asuntos Nucleares, Laboratorios
y Gestión de Información, en cumplimiento de la Ley 1712 de 2014 "Ley de
transparencia y el derecho de acceso a la información Pública" y de acuerdo a
los artículos 11 literal J y K, artículo 12, artículo 13 y artículo 14. La
información está almacenada en una geodatabase corporativa gestionada por
el motor de base de datos Oracle, herramientas de la Suite de ESRI y
aplicaciones web personalizadas utilizando Geoportal Server de ESRI
(Software Open Source). Mediante esta plataforma se administra la
información de manera dinámica, y está dispuesta al usuario en línea. Así
mismo, se cumple con estándares de código abierto (open source) como
WMS, WFS, WCS y servicios REST. (SCG, 2017).
Ilustración 3. Visor Amenazas Sísmicas. Fuente: SGC (2017). Recuperado de http://srvags.sgc.gov.co/JSViewer/Amenaza_Sismica/
22
4.1.4 Agencia Nacional de Hidrocarburos
La ANH es la encargada del aprovechamiento de los recursos hidrocarburíferos
del país, ellos cuentan con el Geovisor ANH, siendo la herramienta que permite la
visualización geográfica de las capas tanto raster como vector; esta información
solo es de carácter informativo para el público; con esta herramienta se puede
extraer los datos, además de poderse realizar algunos análisis como coberturas y
zonas de influencia, estas herramientas las podemos ver mejor en la ilustración 4.
Ilustración 4. Geovisor ANH. Fuente: ANH (2017). Recuperado de https://geovisor.anh.gov.co/
23
4.1.5 Unidad de Planeación Minero-Energética
La UPME es una unidad administrativa especial del orden Nacional, esta está
adscrita al Ministerio de Minas y Energía, desde allí se planea el desarrollo minero
energético y el apoyo a la formulación de políticas públicas; esta unidad
proporciona dos tipos de visores diferentes, un visor general (donde se podrá
información geográfica básica de los servicios que se prestan), ilustración 5, y
unos visores temáticos (este es un catálogo de diferentes visores como Potencial
Hidroenergético, Potencial solar, Potencial eólico, Potencial Biomasa, entre otros,
creados por la UPME).
Ilustración 5. Visor General UPME. Fuente: ANH (2017). Recuperado de http://sig.simec.gov.co/GeoPortal/Carrusel/Visor
24
4.1.6 Unidad de Victimas
La unidad de victimas también proporciona su propio visor geográfico, el cual
permite realizar filtros del registro único de víctimas, resguardos indígenas,
comunidades afro, reservas campesinas y el Índice de riesgo de victimización, el
visor me permite la exportación de imágenes, PDF, Excel y Shapefile, además de
poseer herramientas de medición y generación de áreas de influencias.
Ilustración 6. Visor Geográfico de Víctimas. Fuente: Unidad de Víctimas (2017). Recuperado de http://vgv.unidadvictimas.gov.co/
25
4.2 CONTEXTO INTERNACIONAL
4.2.1 United States Geological Survey
La USGS es una agencia científica del departamento del Interior del gobierno de
los Estados Unidos, esta agencia estudia los recursos, amenazas y peligros
naturales de ese país; dentro de las herramientas que proporciona la USGS
podemos encontrar uno de los visores más conocidos, el EarthExplorer el cual
proporciona a los usuarios la consulta, búsqueda y descarga de imágenes
satelitales, fotografías aéreas y productos cartográficos de distintas fuentes; los
datos que se encuentran allí son de satélites como LANDSAT, datos de MODIS de
las misiones Terra y Aqua, ASTER y de una variedad de otros proveedores de
datos, la gran ventaja de este visor, es poder encontrar imágenes de todo el
mundo y tener la oportunidad de visualizar y descargar.
Ilustración 7. Visor EarthExplorer. Fuente: USGS (2017). Recuperado de https://earthexplorer.usgs.gov/
26
4.2.2 Instituto Geográfico Nacional de España
El Instituto Geográfico Nacional de España se encarga la producción, mantenimiento y
explotación de la Infraestructura de Datos Espaciales de España, estudios de geofísica,
campos magnéticos, sísmica, cálculos astronómicos, redes geodésicas, entre otras; este
Instituto cuenta con un visor geográfico llamado Sistema de Información Geográfica
Nacional (SignA), ilustración 8, donde se muestra toda la cantidad de información que se
puede consultar a través de este visor.
Ilustración 8. Visor Geográfico. Fuente: IGN (2017). Recuperado de http://signa.ign.es/signa/
27
5 METODOLOGÍA
5.1 METODOLOGÍA DE DESARROLLO DE SOFTWARE
Para el desarrollo de este prototipo se compararon las ventajas y desventajas de las diferentes metodologías o
métodos de desarrollo de software, esto con el fin de seleccionar la que mejor se adapte para nuestro proyecto, y
cumpla con las necesidades establecidas de los usuario; de allí se obtuvo la Tabla 1 mostrada a continuación.
Metodologías
de Desarrollo
de Software
Ventajas
Desventajas
¿Cuándo Aplicarla?
Build
and
Fix
Efectivo para
productos pequeños.
No se pierde tiempo en
la planificación, la
documentación, el
control de la calidad, el
cumplimiento de los
estándares, otra
actividad que no sea la
codificación pura.
Después de un número de
correcciones, el código
puede tener una muy mala
estructura.
Diseño "spaghetti", no
manejable para sistemas
grandes
Consiste básicamente en codificar y
corregir (code-and-fix), es útil
utilizarla cuando se comienza a
trabajar en desarrollo de primeros
software como por ejemplo “Hola
Mundo”.
28
Cascada Se tienen puntos de
revisión establecidos y
documentados en
cada fase.
Se acopla con otros
modelos del proceso
de ingeniería.
El producto / resultado sólo
se ve al final (para el
cliente). Si existe algún
error (diferencia) solo se
reflejara al final.
La revisión de proyectos de
gran complejidad son muy
difíciles.
La aplicación de la metodología en
cascada se encuentra orientado al
desarrollo de proyectos de corto
plazo, de poca innovación y
proyectos definitivos y detallados.
Incremental Se pueden utilizar los
incrementos iniciales
como prototipos.
Con un paradigma
incremental se
reduce el tiempo de
desarrollo inicial, ya
que se implementa la
funcionalidad parcial.
También provee un
impacto ventajoso
frente al cliente, que
es la entrega
temprana de partes
operativas del
Software.
El modelo
proporciona todas las
ventajas del modelo
en cascada
El modelo Incremental no
es recomendable para
casos de sistemas de
tiempo real, de alto nivel
de seguridad, de
procesamiento distribuido,
y/o de alto índice de
riesgos.
Requiere de mucha
planeación, tanto
administrativa como
técnica.
Requiere de metas claras
para conocer el estado del
proyecto.
La aplicación de esta metodología
incremental es particularmente útil
cuando no se dispone de mucho
personal para una implementación
completa para una fecha límite, las
primeras implementaciones se
pueden realizar por un grupo de
personas reducida y en cada
incremento se puede añadir el
personal necesario.
29
realimentado,
reduciendo sus
desventajas sólo al
ámbito de cada
incremento.
Permite entregar al
cliente un producto
más rápido en
comparación del
modelo de cascada.
Resulta más sencillo
acomodar cambios al
acotar el tamaño de
los incrementos.
Por su versatilidad
requiere de una
planeación cuidadosa
tanto a nivel
administrativo como
técnico.
Evolutivo Reutilización del
software.
Simplifica las
pruebas; pues estas
se le hacen a los
componentes antes
de probar el conjunto
completo de
componentes
Genera mucho tiempo en
el desarrollo del sistema.
Modelo costoso.
Requiere experiencia en la
identificación de riesgos.
Genera mucho trabajo
adicional.
El modelo va enmarcado como
guía en el momento de ordenar las
diversas actividades técnicas en el
proyecto, de igual manera como la
administración del desarrollo y el
mantenimiento, ya que se puede
estimar recursos, puntos de
30
ensamblados.
Simplifica el
mantenimiento del
sistema.
control entre otras.
Espiral Incluye de forma
explícita en cada giro
la especificación de
objetivos, definición de
alternativas y
restricciones y
evaluación de riesgos
Se considera el mejor
modelo para el
desarrollo de sistemas
grandes.
No es aconsejable para
sistemas pequeños debido
a su alta complejidad.
Consume muchos recursos.
El modelo espiral va enfocado a ser
un modelo más realista para el
desarrollo de software, permitiendo
al desarrollador y el cliente
entender y reaccionar a los riesgos
en cada nivel. Cuando se
requieren prototipos, en este
modelo se toma como un
mecanismo de reducción de riesgo.
Xp Se adapta al desarrollo
de sistemas pequeños
y grandes.
Permite realizar el
desarrollo del sistema
en parejas para
complementar los
conocimientos.
Optimiza el tiempo de
desarrollo.
El código es sencillo y
No se tiene la definición del
costo y el tiempo de
desarrollo.
El sistema va creciendo
después de cada entrega al
cliente y nadie puede decir
que el cliente no querrá una
función más.
Se necesita de la presencia
constante del usuario.
Xp se centra en fomentar las
relaciones interpersonales como la
principal clave para el éxito del
desarrollo. Es adecuada para
proyectos con requisitos imprecisos
y muy cambiantes, en donde los
riesgos técnicos son altos.
31
entendible.
Scrum Ofrecen una rápida
respuesta a cambios
de requisitos a lo largo
del desarrollo del
proyecto gracias a su
proceso iterativo.
Los cambios que
quiera realizar el
cliente van a tener un
menor impacto, ya que
se va a entregar en un
pequeño intervalo de
tiempo.
Importancia de la
simplicidad al eliminar
trabajo innecesario.
Falta de documentación del
diseño. Al no haber
documentación es el código
(junto con sus comentarios)
lo que se toma como
documentación.
Fuerte dependencia de las
personas.
Falta de reusabilidad
derivada de la falta de
documentación
La metodología Scrum permite
afrontar proyectos complejos en el
momento del desarrollo en el que
los entornos son dinámicos y
cambiantes de un modo flexible.
Está apoyada en entregas
parciales y constantes del producto
final en base al objetivo que
plantean los clientes.
Tabla 1. Ventajas y desventajas metodologías de IS. Fuente: Propia
32
Teniendo en cuenta cada una de las ventajas y desventajas de las metodologías
planteadas anteriormente se pudo analizar y comparar cual de todas estas
características se ajustan a los objetivos del proyecto; por lo cual se eligio la
metodología usada “Scrum” la cual al ser para un proyectos dinámico ofrece la
posibilidad de realizar entregas parciales y constantes del proceso del prototipo,
esto con el fin de obtener retroalimentaciones tanto de los usuarios internos como
para los usuarios finales.
5.1.1 Desarrollo SCRUM
Scrum al ser una metodología de desarrollo ágil y flexible para el desarrollo de
software posee la particularidad de lo que denominamos ciclos breves, en otros
métodos esta idea se le llama iteraciones pero en este método se le llaman
“Sprints” o unidad básica de trabajo como se muestra en la ilustración 9.
(Palacios, 2009)
La metodología Scrum se puede clasificar y categorizar en varias fases las cuales
definen el ciclo de desarrollo, esto puede cambiar dependiendo del autor, pero en
general representan una metodología en ciclo, estas son:
1. Concepto: Se describen las características del producto, en esta fase
también se define el equipo de trabajo que se encargara del desarrollo.
2. Especulación: En esta fase se establecen los limites (costos y agenda)
que marcaran el proceso de desarrollo; el producto se construirá a partir
de ideas principales. Esta fase consiste en ir desarrollando y revisando los
requisitos generales; Estar al día con las funcionalidades establecidas y
establecer las fechas de las versiones.
33
3. Exploración: Se revisa el producto con las funcionalidades.
4. Revisión: El equipo de desarrollo revisa y tiene en cuenta lo que ha
construido y se compara con el objetivo inicial.
5. Cierre: Se entrega en la fecha acordada la versión a la que está
establecida, esto no quiere decir que el proyecto esté finalizado, solo es el
cierre de una versión; en esta medida se seguirán haciendo los cambios
los cuales se denominan “mantenimientos”. (Palacios, 2009)
Ilustración 9. Ciclo principal de SCRUM. Fuente: (Palacios, 2009)
5.2 METODOLOGÍA DE DESARROLLO DEL PROTOTIPO
La metodología se dividió en 3 etapas claves para el desarrollo del
prototipo las cuales son: 1) Clasificación de los datos, 2) Desarrollo del
Software, 3) Validación del prototipo, estos a su vez están divididos
internamente y son representados en la siguiente gráfica (Ilustración 10).
34
Ilustración 10. Metodología desarrollada. Fuente: Propia
5.2.1 Clasificación de los Datos
5.2.1.1 Diagnóstico de las Imágenes.
El diagnóstico de las imágenes comprende la recopilación, análisis y
recomendaciones del estado actual de la información que proviene de sensores
remotos (imágenes satelitales), de propiedad del IDEAM, y de conocer cómo se
está gestionando este tipo de información y quiénes son los principales gestores y
consumidores de la misma.
Este diagnóstico se realizó por medio de reuniones con cada una de las
dependencias del IDEAM, para poder generar las ventajas y desventajas que
existen en cuanto al manejo actual de la información y además la visión tanto
35
particular de los usuarios como general de las dependencias para obtener las
necesidades de cada uno.
Además del diagnóstico para la clasificación de las imágenes se creó un formato
de inventario el cual se muestra en la tabla 2 a continuación, este formato es
planteado siguiendo parámetros de inventarios consultados en Tomlinson, 2007.
Tabla 2. Propuesta formato inventario de imágenes. Fuente: Propia
Los resultados del diagnóstico se presentan en el ANEXO A.
Nombre Imagen: Departamento:
Código Imagen: Subdirección:
Satelite: Si:
Misión: No:
Medio de datos de origen:
Formato de dato digital:
Fecha Captura:
Formato Inventario Imágenes
Proyección:
Metadato:
36
6. DESARROLLO DE PROTOTIPO
Para el diseño estructural del prototipo se tuvo en cuenta una arquitectura de
software modelo vista controlador, el cual es un patrón que separa los datos y la
lógica dentro de una aplicación con interfaz de usuario, esta arquitectura propone
tres componentes los cuales son el modelo, la vista y el controlador, es decir
separa la información del prototipo de la interacción del usuario.
Ilustración 11. Estructura modelo vista- controlador. Fuente: Propia
Los elementos a tener en cuenta son:
El modelo es la representación de la información con la cual sistema opera,
gestiona todos los accesos a la información, en él se implementan los privilegios
de acceso especificados en la lógica de negocio.
El controlador responde a acciones del usuario/cliente y envía las peticiones al
modelo en el momento que se quiera editar, consultar o hacer búsquedas en los
registros de la base de datos.
La vista, o interfaz de usuario es la representación visual de los datos contenidos.
Modelo
Actualizar Manipular
Vista Controlador
Usuario
37
Como conclusión, podemos decir que el prototipo IDEAM SAAI maneja esta
arquitectura de software (Instituto de Hidrología y Estudios Ambientales) debido a
la seguridad que maneja este modelo de construcción de software.
El desarrollo del software comprende el modelo o también conocida capa de datos
que maneja dos estructuras dentro del prototipo, un directorio de Carpetas y La
base de datos por razones que a continuación se explicaran.
6.1 DIRECTORIO DE CARPETAS
Dentro del diseño del prototipo se estableció la generación de un directorio de
carpetas el cual va a contener las imágenes satelitales es decir donde van a
quedar almacenadas, esta estructura permite no tener que almacenar las
imágenes en la base de datos con el fin de no afectar el espacio de
almacenamiento. Además esta propuesta de directorio de carpetas también viene
dada por la generación de filtros dentro del mismo prototipo, lo que ayuda a
estructurar de una mejor manera la información y poder consultarla de manera
más sencilla y eficiente. El modelo de directorio de carpetas se presenta en la
ilustración 11.
38
Ilustración 12. Modelo de directorio de carpetas. Fuente: Propia
6.2 BASE DE DATOS
Para la estructuración de la base de datos fue necesario manejar los parámetros
establecidos por el IDEAM, debido a políticas internas de la institución, dando
como resultado los diseños estructurales de la base de datos que se muestran a
continuación.
6.2.1 Modelo Entidad Relación
El modelo entidad relación elaborado para el prototipo corresponde al modelo
inicial de la base de datos, en pocas palabras el bosquejo, el cual tiene como
objetivo definir las entidades existentes sus relaciones y la forma en que
interactúan; el esquema (ilustración 13) maneja las siguientes entidades y
relaciones:
Entidades:
39
• Usuario • Imagen • Nivel de procesamiento • Grilla • Proyecto
Las relaciones del modelo son las siguientes:
• Relación usuario – imagen: es de tipo muchos a muchos, debido a que
varios usuarios pueden consultar más de una imagen, siendo estas las
dos entidades más importantes del modelo.
• Relación imagen – proyecto: es de tipo muchos a uno puesto que
existen muchas imágenes relacionadas con un solo proyecto (conjunto
de satélites lanzado por una misma organización bajo varias misiones).
• Relación imagen – nivel de procesamiento: es de tipo muchos a
muchos debido a que una imagen dentro de la base de datos tiene uno
o más niveles de procesamiento. El nivel de procesamiento dentro de la
base de datos es de cuatro tipos: imagen cruda, corrección
radiométrica, corrección geométrica y corrección por desplazamiento.
• Relación proyecto – grilla: esta relación es de tipo uno a uno porque un
proyecto maneja únicamente una grilla por misión realizada.
40
Ilustración 13. Modelo entidad relación. Fuente: Propia
41
6.2.2 Modelo Conceptual
Este modelo representa las relaciones entre las diferentes entidades, así como el
tipo de dato de los atributos y la longitud de los mismos. También indica las
obligatoriedades y llaves primarias.
A comparación con el modelo entidad relación, el modelo conceptual maneja más
características y permite entender con una mayor profundidad la estructura de la
base de datos.
Ilustración 14. Modelo conceptual. Fuente: Propia
42
6.2.3 Modelo Lógico
El modelo lógico permite estructurar datos y modelar restricciones. En la
ilustración 15 se observan las diferentes tablas de paso generadas de las
relaciones muchos a muchos entre las entidades. Además, se expresa las
dependencias entre las entidades.
Ilustración 15. Modelo lógico. Fuente: Propia
43
6.2.4 Modelo Físico
El modelo físico es el paso final del diseño general para su implementación dentro
del motor base de datos, ya que establece los parámetros, entidades y relaciones
definitivas además de pasar las entidades a tablas.
Ilustración 16. Modelo físico. Fuente: Propia
44
6.2.5 Script SQL
Después de haber, diseñado la estructura de la base de datos a través de los
modelos anteriormente descritos, es necesario pasar el Modelo físico a un
lenguaje que pueda ser interpretado por el motor de bases de datos, lo que
significa la generación de un Script en lenguaje SQL como se observa en la
ilustración 17.
SQL (Structured Query Lenguage) es un lenguaje de consulta estructurada
implementado para la gestión de bases de datos relacionales, el cual permite
especificar diversos tipos de operaciones para la consulta de información de una
manera fácil y sencilla. Al ser este lenguaje el utilizado por múltiples motores de
bases de datos en el mercado fue necesario hacer la traducción del modelo físico
a este lenguaje.
En el Anexo B de este documento se encontrara el script SQL generado al
momento de traducir en su totalidad las entidades y relaciones del modelo físico a
este lenguaje.
Ilustración 17. Ejemplo script. Fuente: Propia
45
6.2.6 Motor de la Base de Datos
El motor de la base de datos utilizado dentro del prototipo es Oracle (Versión
11g), debido a las estrictas políticas de la institución (IDEAM) como principal
razón, sin embargo después de haber realizado la estructuración de la base de
datos para este prototipo es totalmente recomendable manejar este motor si la
lógica se realizara en lenguaje Java. Debido a múltiples facilidades que se
explicaran a lo largo de este documento.
Oracle 11g es un sistema de gestión de base de datos desarrollado por Oracle
corporation, este motor es considerado como uno de los más completos y
robustos debido a múltiples características como su soporte y estabilidad las
cuales fueron de vital importancia para el desarrollo del prototipo.
Durante el montaje de la base de datos, fue necesario utilizar Oracle SQL
Developer un ambiente de desarrollo (IDE) que permitió procesar el Script
generado y explicado anteriormente de una manera mucho más fácil y sencilla,
obtenido como resultado la base de datos que se muestra en la ilustración 18.
Ilustración 18. Base de Datos en Oracle 11 G, Fuente: Propia
46
6.2.7 Controlador de Base de Datos
El controlador de la base de datos se realizó mediante lenguaje Java sobre la IDE
(Entorno de desarrollo Integrado) Netbeans 8.1 con la utilización de ActionServlets
los cuales actúan como controlador dentro del prototipo. Estos Servlets reciben las
peticiones del navegador, deciden la función que van a utilizar y retornan una
respuesta de la base de datos (Modelo), dichas funciones están declaradas dentro
del config.xml.
De manera más simple los Servlets únicamente son los comunicadores entre la
interfaz gráfica “Página Web” que utiliza el usuario y la base de datos sin que el
usuario tenga acceso directo a la misma cuando no se encuentra un Servlet
específico dentro del prototipo.
En las siguientes ilustraciones 19 y 20, se esquematiza la estructura de la IDE y la
construcción de un Servlet.
Ilustración 19. Interfaz Netbeans 8.1. Fuente: Netbeans
47
Ilustración 20. Ejemplo Servlet. Fuente: Netbeans.
Dentro del prototipo construido en Netbeans 8.1 se encuentra una carpeta llamada
Source Package la cual contiene un paquete llamado org.Controlador, el cual
contiene los Servlets empleados en el prototipo, para entender mejor esta
explicación remitirse a la ilustración 21.
De acuerdo con la ilustración 22, se observa que hay un Servlet por función dentro
del prototipo. Es decir, cada una de las funcionalidades del prototipo que implique
una consulta a la base de datos se realizó mediante un Servlet el cual controla la
entrada y salida de información.
48
Ilustración 21. Definición de cada una de las carpetas dentro del prototipo. Fuente: Propia
Ilustración 22. Servlets creados en el prototipo. Fuente: Netbeans.
49
6.2.8 Consulta y Peticiones a la Base de Datos
Las consultas y peticiones realizadas a la base de datos son estructuradas a
través componentes de software llamadas DAO (Objeto de Acceso a Datos) el
cual provee al prototipo una interface de comunicación entre la lógica del
programa y la base de datos.
Los Objetos de acceso a datos en la actualidad son una muy buena práctica que
facilita el acceso a la información que necesita la lógica del programa, desde el
motor de base de datos que la alberga, en la ilustración 23 se puede observar la
estructura de una entidad DAO.
Ilustración 23. Estructura Entidad DAO Fuente: Netbeans
50
Como se puede observar en la ilustración anterior, la entidad DAO maneja 3
partes importantes:
Petición de la información a través de una consulta en lenguaje SQL
(Ilustración 24).
Conexión a la base de datos (Ilustración 25).
Retornar la información (Ilustración 26)
Ilustración 24. Petición Fuente: Netbeans
Ilustración 25. Conexión Fuente: Netbeans
51
Ilustración 26. Obtención de la informacion Fuente: Netbeans.
Cada una de las funcionalidades del prototipo, maneja una conexión DAO para la
obtención de la informacion y retorno a la página WEB mediante los Action
Servlets.
6.2.9 Vista
Es la interfaz gráfica del prototipo; con la cual el usuario tiene contacto, son un
conjunto de páginas jsp las cuales no contienen lógica de negocio ni
funcionalidades que tengan un contacto directo con la base de datos (modelo).
Únicamente utilizan una estructura diseñada visualmente para poder presentar la
información obtenida del controlador (Servlet).
Como se puede observar en la ilustración 27 la vista del prototipo está construida
bajo un archivo jsp en la IDE de NetBeans y utilizando lenguaje HTML, este es un
lenguaje de marcas de Hipertexto que permiten la elaboración de páginas web.
En las ilustraciones 28 y 29 se puede observar los archivos de lógica y estilos js y
css (respectivamente) que le agregan al prototipo un ambiente más dinámico y
fácil de usar.
52
Ilustración 27. Archivo jsp desde NetBeans. Fuente: Netbeans.
Ilustración 28. Archivo ccs en NetBeans. Fuente: Netbeans.
Ilustración 29. Archivo js en NetBeans. Fuente: Netbeans.
53
6.3 IMPLEMENTACIÓN DEL BANCO DE IMÁGENES
Para la implementación del Banco de imágenes se realizó un documento de
especificaciones el cual detalla la especificación funcional requerida para cubrir las
necesidades funcionales identificadas en el almacenamiento y administración de la
información proveniente de sensores remotos administrada por el IDEAM.
Para cada requerimiento funcional se realizó la especificación de un caso de uso
que describe el detalle de la funcionalidad del sistema; además se complementan
las funcionalidades con la descripción de cada uno de los actores y se
complementa con un diagrama general de casos de uso el cual describe la
interacción de los mismos entre sí para dar como resultado una funcionalidad.
Para conocer el documento completo de especificaciones remitirse al ANEXO C
de este documento.
6.4 VALIDACIÓN DEL PROTOTIPO
El prototipo de Banco de imágenes se validó a través de los principales
consumidores de la información (usuarios del IDEAM), para lograr esto se
realizaron reuniones de validación constantes, en donde se presentó las vistas
preliminares de cada uno de los avances para tener en cuenta las sugerencias y
observaciones dadas por los mismos usuarios.
En último lugar para mostrar el prototipo final se realizó pruebas con imágenes
directamente del IDEAM, esto para validar y mostrar que las funcionalidades
funcionen completamente.
54
8. RESULTADOS
Los siguientes resultados reflejan el proceso correspondiente a la metodología
trabajada, esto quiere decir que lo planteado allí brindo cada uno de los resultados
que estan enmarcados en los objetivos planteados.
8.1 DEFINICIÓN DE USUARIOS DE LA INFORMACIÓN
Con las reuniones establecidas dentro del Instituto se indago sobre las
dependencias usuarias de la información, con esto se pudo identificar los
principales usuarios de los productos provenientes de sensores remotos, es decir
las personas que manejan la información, tal y como se muestra en la ilustración
30, en la cual se relacionan las Subdirecciones y oficinas, igualmente en la
ilustración 31 se muestra la jerarquía interna de estos usuarios.
Ilustración 30. Dependencias donde se encuentras los usuarios de la información. Fuente: Propia
55
Ilustración 31. Estructura Jerárquica de los usuarios Internos. Fuente: Propia
A continuación se relacionan las principales dependencias usuarias de la
información de imágenes, resultado de la investigación realizada.
8.1.1 Subdirección de Ecosistemas E Información Ambiental
En esta subdirección se maneja gran cantidad de información proveniente de
sensores, esto se ve reflejado en el inventario suministrado por ellos en un archivo
de EXCEL, en el cual se relaciona las imágenes que posee el Instituto, y se puede
visualizar la forma como se estaba estructurando dicha información.
La información más relevante que brinda este Excel en relación a los atributos, la
podemos ver en la ilustración 32.
56
Ilustración 32. Información atributiva más relevante encontrada en el inventario. Fuente: Propia
La explicación detallada de cada uno de los atributos se presenta en el ANEXO A
8.1.2 Sistema de Monitoreo de Bosques y Carbono (SMBYC)
El proyecto Sistema de Monitoreo de Bosques y Carbono (SMBYC) hace parte de
la Subdirección de Ecosistemas e Información Ambiental, este proyecto cuenta
con un gran volumen de imágenes provenientes de sensores remotos, estas
imágenes son diferentes a las que posee la subdirección de Ecosistemas.
57
El tipo de imágenes usadas dentro de este proyecto, son Landsat, RapidEye,
QuickBird, Alos Palsar, Lidar, obtenidas de manera gratuita, por compra o por
convenios con otras instituciones y con licenciamientos distintos (Monousuario,
Multiusuario). Para el caso de Landsat, se utiliza todo el catálogo disponible, en el
cual una vez obtenidas, se realiza un proceso de control de calidad (este involucra
una codificación y almacenado bajo una estructura pre-establecida por el
SMBYC) tanto para estas imágenes en crudo como para los productos resultantes
de estas; para el caso de sensores como RapidEye y QuickBird se usan imágenes
de alta resolución.
8.1.3 Subdirección de Hidrología
La subdirección de Hidrología es la encargada de realizar los estudios como
relacionados con zonas inundables, niveles de los caudales y sequias entre otros.
La información de sensores más utilizada en esta subdirección es Landsat,
RapidEye, Radarsat, y Lidar entre otras. Para casos como estudios de zonas
inundables, las imágenes usadas son Landsat, en caso de querer manejar un nivel
mayor de detalle se usa la información de RapidEye y Radarsat.
Esta subdirección posee un catálogo de imágenes para inundaciones realizado en
agosto del 2013, allí no se encuentran todas las imágenes usadas durante los
proyectos pasados, pero es lo más cercano a un inventario actual.
La información detallada de lo encontrado en este inventario se encuentra en el
ANEXO A.
58
8.1.4 Oficina del Servicio de Pronósticos y Alertas
La oficina del servicio de pronósticos y alertas esta activa las 24 horas, realizando
los diferentes análisis y pronósticos de la información que le es suministrada, por
este constante análisis son usuarios directos de las imágenes GOES que obtiene
el Instituto, tras estos pronósticos generan sus informes relacionados y posibles
alertas que se tengan en el país.
La gestión que se realiza con estas imágenes GOES no se vincula directamente
con la oficina de pronósticos; los usuarios directos de la información no son los
encargados del almacenamiento y caracterización de estas, por esta razón se
remitió a los responsables de realizar este proceso (oficina de informática).
La oficina de informática tiene un protocolo establecido para el gestionar la
información proveniente de sensores remotos, en este protocolo podemos señalar
3 pasos importantes los cuales son: 1) Antena receptora, 2) El Servidor, 3)
Transferencia de archivos.
La explicación detallada de este protocolo se encuentra en el ANEXO A.
8.2 REQUERIMIENTOS
A continuación se mostraran las reglas de negocio, que se pueden definir como
restricciones, necesidades, requerimientos o actividades especiales que existen
para asegurarse de la calidad y exactitud de los datos, evitando que sea posible
llevar acciones no validas; además se puede usar una regla de negocio para
actualizar datos automáticamente o un flujo de trabajo. (Microsoft, 2016)
59
8.2.1 Reglas de Negocio
Regla 1: El prototipo de Banco de Imágenes se nombra como SAAI.
Regla 2: El IDEAM se encuentra estructurado por subdirecciones, proyectos
y oficinas que manejan información de sensores de manera independiente,
debido a permisos y licencias; por lo tanto se debe manejar una
metodología de clasificación de las imágenes teniendo en cuenta la
estructura de la institución.
Regla 3: Manejo de un ADMINISTRADOR GLOBAL para la administración
del prototipo SAAI.
Regla 4: Manejo de un ADMINISTRADOR TEMPORAL para el Banco de
Imágenes, siendo este el encargado de subir la gran cantidad de
información al prototipo.
Regla 5: Manejo únicamente de USUARIOS INTERNOS con acceso a la
información.
Regla 6: El ADMINISTRADOR GLOBAL se encargará la administración de
imágenes (Inserción, Actualización y Eliminación), para su consulta por
parte de los usuarios internos y Administradores Temporales.
Regla 7: El ADMINISTRADOR GLOBAL tendrá libre acceso a toda la
información perteneciente al IDEAM, únicamente para su implementación
dentro del prototipo (Consulta y Descarga).
Regla 8: El ADMINISTRADOR TEMPORAL tendrá acceso limitado ya que
solo cumplirá la función de Ingresar nueva información.
Regla 9: El ADMINISTRADOR TEMPORAL podrá entregar nueva
información al ADMINISTRADOR GLOBAL para su almacenamiento y
publicación en el Banco de Imágenes.
Regla 10: El ADMINISTRADOR GLOBAL podrá eliminar información del
Banco de Imágenes, y esto deberá hacerse mediante la generación de una
60
Copia de Seguridad con el fin de evitar perdida de información valiosa para
la institución.
Regla 11: El ADMINISTRADOR GLOBAL podrá generar nuevos usuarios
(Internos), registrados en el directorio activo de la institución
Regla 12: El ADMINISTRADOR GLOBAL deberá realizar la revisión del
estado de los servidores, además del estado de la información.
Regla 13: El ADMINISTRADOR TEMPORAL no podrá eliminar información
del Banco ni actualizarla.
Regla 14: La inclusión de nueva información al Banco de Imágenes por
parte del ADMINISTRADOR TEMPORAL deberá ser realizada mediante
autorización expresa del administrador Global.
Regla 15: El USUARIO INTERNO tendrá acceso a la información que sea
pública en el Banco de Imágenes.
Regla 16: El USUARIO INTERNO únicamente tendrá permisos de consulta
y descarga de información.
Regla 17: El módulo de administración, únicamente funcionará para la
inserción de información dentro de la base de datos Oracle, no para
almacenado en el directorio de carpetas ni publicación de servicios.
Regla 18: El módulo de administración para el ADMINISTRADOR GLOBAL,
ser independiente del módulo de Administración del ADMINISTRADOR
TEMPORAL.
Regla 19: No se modificara en ningún caso el sistema de referencia de las
imágenes.
Regla 20: Se realizará la publicación de los Servicios de Imágenes en
ArcGIS SERVER.
Regla 21: Se realizará el almacenamiento de las Imágenes en el directorio
de carpetas por parte de los ADMINISTRADORES TEMPORALES O
GLOBAL manualmente, como especifica el Manual de Usuario.
61
Regla 22: Se deberán seguir los parámetros de almacenamiento de las
imágenes según el manual de Usuario adjunto a este documento.
Regla 23: Todas las imágenes que se almacenen dentro de SAAI deben ser
formato GeoTiff.
Regla 24: El sistema de referencia dentro del prototipo que se manejara
para las imágenes será el 4326 Coordenadas Geográficas WGS84.
8.2.2 Determinación de los Actores
A continuación se describen los actores que hacen parte del prototipo SAAI.
NOMBRE Administrador Global AC-IDEAM SAAI-01
DESCRIPCIÓN Representa al usuario que almacena, administra y
gestiona la información para el Instituto dentro de una
plataforma centralizada.
CAPACIDADES Crear, modificar o cambiar el estado de usuarios con rol de Administradores Temporal en el Banco de Imágenes, cuando haya terminado sus funciones de almacenamiento.
Crear, modificar o cambiar el estado de los (usuarios de consulta) dentro del Banco de Imágenes.
Realizar el procedimiento de almacenaje de la nueva información.
Verificación de la capacidad y estado de los servidores de almacenamiento.
Comprobar el estado de la información.
Generación de Copias de seguridad
Realizar informes Generales y por Subdirecciones de la información.
Tabla 3. Definición de Administrador Global.
62
NOMBRE Administrador Temporal AC- IDEAM SAAI -
02
DESCRIPCIÓN Representa al usuario que realizará el cargue de
imágenes al Banco, durante el tiempo que dure la
migración de la información.
CAPACIDADES Realizar un informe de la información cargada al prototipo, durante el proceso de migración.
Tabla 4. Definición de Administrador Temporal.
NOMBRE Usuario Interno AC- IDEAM SAAI -
03
DESCRIPCIÓN Representa al usuario que puede consultar y descargar la
información.
CAPACIDADES Consultar la información dentro del Banco de imágenes.
Descargar la información que es de manera pública para su estado.
Consultar el metadato de las imágenes que se encuentran dentro del prototipo.
Tabla 5. Definición de Usuario Interno
8.2.3 Requerimientos Funcionales
Dentro de este ítem se realiza una descripción global de las funcionalidades que
dispondrá el prototipo SAAI propuesto, detallando punto por punto cuáles serán y
su alcance.
63
ÍTEM DESCRIPCIÓN
1. ADMINISTRACIÓN
RF- IDEAM
SAAI -01
Ingresar al sistema Usuarios IDEAM
Permitir a todos los actores tener acceso al sistema mediante el
uso de un usuario y contraseña personal con los que tendrá la
entrada a diversas funcionalidades que provee el sistema de
acuerdo con los permisos otorgados al tipo de rol que tiene el
usuario.
RF- IDEAM
SAAI -02
Gestionar Usuarios IDEAM
Permitir la creación, modificación o cambio de estado de usuarios
con rol de Administradores Temporal o usuario con rol de Usuario
Interno.
RF- IDEAM
SAAI -03
Gestionar información Administrador Temporal
Permitir a los usuarios con rol de Administrador Temporal cargar
la información proveniente de sensores remotos suministrada por
la institución durante el proceso de migración al prototipo.
RF- IDEAM
SAAI -04
Gestionar Información
Permitir al Administrador Global la administración directa de toda
la plataforma, junto con el prototipo.
3 OPERACIONALES
RF- IDEAM
SAAI -05
Consultar información
Los usuarios internos podrán hacer la respectiva consulta de la
información que deseen y se encuentre dentro del Banco.
RF- IDEAM
SAAI -06
Descarga de Información
El Usuario interno podrá descargar información que haya sido
consultada.
RF- IDEAM
SAAI -07
Generación de vista preliminar
Permitir al usuario la visualización de las imágenes consultadas a
través del sistema de consulta en mapa.
RF- IDEAM Filtros de Información General
64
ÍTEM DESCRIPCIÓN
SAAI -08
Permitir al usuario la consulta de información mediante la
aplicación de filtros para una mayor rapidez de consulta, los filtros
estarán definidos por:
Tipo de Sensor
Fecha
Misión
Proyecto
Nivel de Procesamiento
RF- IDEAM
SAAI -09
Visualización Preliminar de la Imagen en un mapa
El usuario podrá visualizar la ubicación de la información sobre un
mapa lo que permitirá al determinar la ubicación exacta de la
imagen.
RF- IDEAM
SAAI -10
Consulta Espacial en mapa
El usuario podrá consultar través de interacción con el mapa,
mediante la creación de un punto.
RF- IDEAM
SAAI -11
Consulta nivel Departamental y Municipal
El usuario podrá consultar información a nivel Departamental y
Municipal.
Tabla 6. Requerimientos Funcionales.
8.2.4 Casos de Uso
Aquí se muestran las interacciones de los casos de uso identificados en los
requerimientos funcionales y los actores del prototipo SAAI (Ilustración 33). Este
describe la forma en la que los actores interactúan a través del límite del sistema y
la respuesta del mismo con sus relaciones de tipo asociación, extend e include.
65
Cada caso de uso especificado está relacionado con el requerimiento de software
al que hace referencia.
Ilustración 33. Diagrama de Casos de Uso.
8.2.5 Requerimientos No Funcionales o Especificaciones Suplementarias
ÍTEM DESCRIPCIÓN
1. ESCALABILIDAD
RNF-IDEAM
SAAI-01
Crecimiento de información
Estimación del crecimiento de la información, y capacidades
66
ÍTEM DESCRIPCIÓN
límites de almacenamiento.
RNF-IDEAM
SAAI-02
Crecimiento de Usuarios
Permitir que el sistema pueda recibir múltiples peticiones de
ingreso, consulta y descarga sin tener fallas.
RNF-IDEAM
SAAI-03
Crecimiento de almacenamiento
Permitir al sistema tener una mayor capacidad de
almacenamiento con el fin de suplir a las necesidades del
crecimiento de la información.
2. RENDIMIENTO
RNF-IDEAM
SAAI-04
Disponibilidad del sistema
La especificación de niveles de disponibilidad requeridos para el
SAAI, son de un 100 % de disponibilidad dentro de las horas
laborales estipuladas por el IDEAM y en horas no laborales en
un 80% dando paso a ese 20% a la realización de
mantenimientos del sistema.
RNF-IDEAM
SAAI-05
Concurrencia del sistema
El sistema deberá soportar una concurrencia del 80% de
usuarios (sobre una base de 100% usuarios del SAAI).
Donde los tiempos de respuesta se mantienen. Con un valor
mayor de concurrencia el sistema sigue prestando servicio pero
los tiempos de respuesta empiezan a degradarse.
3 SEGURIDAD
RNF-IDEAM
SAAI-06
Control de vigencia de sesiones de usuario
El sistema debe manejar un esquema de sesiones que permita
al usuario desenvolverse normalmente dentro del mismo. Estas
sesiones deben contar con un tiempo de time-out parametrizable
después de un período determinado. Así mismo se debe poder
parametrizar el tiempo de inactividad.
RNF-IDEAM
SAAI-07
Control de inicio de sesiones de usuario
El sistema manejara un esquema de seguridad que permita al
67
ÍTEM DESCRIPCIÓN
sistema identificar plenamente al usuario que está ingresando.
4. VISUALIZACIÓN
RNF-IDEAM
SAAI-08
Estándar de diseño gráfico
El diseño de la interfaz gráfica debe corresponder a los
lineamientos en el estándar gráfico definido por el IDEAM.
RNF-IDEAM
SAAI-09
Interfaz de usuario Web
La interfaz de usuario debe estar basada en Web, utilizando los
componentes compatibles con la arquitectura tecnológica
definida. Las interfaces de usuario deben contar con una tabla
de resultados con paginación para que no se cargue gran
cantidad de información en una pantalla. El sistema debe
mostrar 20 filas de datos por paginación.
RNF-IDEAM
SAAI-10
Resolución de pantalla
La resolución mínima definida para el sistema es 1024 x 768
RNF-IDEAM
SAAI-11
Facilidad de aprendizaje
El sistema deberá ser intuitivo y presentar un estándar de
navegación para facilitar el aprendizaje. Facilidad de
Entendimiento.
5. SOPORTABILIDAD
RNF-IDEAM
SAAI-12
Documentación
El sistema que se implante debe contar con toda la
documentación que explique y aclare su funcionamiento. Se
busca en lo posible elaborar documentación con diagramas que
ilustren fácilmente cada uno de los componentes del sistema y la
interacción de los mismos, de modo que cuando se requiera
extender la operación del sistema, se pueda implementar
fácilmente con un tiempo y costo razonables.
RNF-IDEAM
SAAI-13
Ayuda en línea
El sistema debe contar con documentación en línea para el
68
ÍTEM DESCRIPCIÓN
usuario, que le sirva de ayuda para el normal desarrollo de sus
actividades dentro del sistema.
6. OTROS REQUISITOS
RNF-IDEAM
SAAI-14
Imagen previa
Se extractara de la imagen real una imagen preliminar en
formato .png para la visualización del mismo dentro del mapa.
RNF-IDEAM
SAAI-15
Información General del Administrador y Usuario (Única
Vez)
El sistema requerirá del usuario información personal (Nombre y
Apellido) de contacto y localización dentro de la entidad (Numero
de extensión y teléfono además de la subdirección de
pertenencia) con el fin de manejar un registro de los usuarios
que están haciendo uso de la información y posterior
identificación y localización.
Tabla 7. Requerimientos No Funcionales
69
9. PROTOTIPO
A continuación se explica paso a paso el prototipo, las funcionalidades que maneja
y como obtiene la información de la Base de datos.
9.1 INICIO DE SESIÓN (LOGIN)
El prototipo SAAI en su ventana de inicial posee dos tipos de inicio de sesión, esto
permite el acceso tanto para un usuario interno como para un administrador; tanto
el usuario como contraseña están dados por el directorio activo que posee el
IDEAM (Este directorio activo ya tiene establecidos usuarios y contraseñas únicas
para cada persona que pertenece al IDEAM); en la ilustración 34 podemos ver
reflejado lo anteriormente mencionado.
Ilustración 34. Login del prototipo. Fuente Propia
70
Ilustración 35. Estructura Login Fuente: Propia
La ilustración 35 muestra la estructura principal del Login para un usuario Interno.
1. En el primer recuadro rojo los usuarios internos del IDEAM deberán
ingresar la información proporcionada por el usuario activo.
2. En el segundo recuadro rojo los Administradores deberán hacer click
para ingresar sus datos de Administrador.
3. En el tercer recuadro rojo, la persona deberá hacer click para poder
ingresar al prototipo, una vez el usuario haya ingresado sus
credenciales.
Si alguna de las credenciales del usuario interno o administrador son incorrectas el
prototipo automáticamente informara del error como se observa en la ilustración
36.
71
Ilustración 36 Mensaje de Error Login Fuente: Propia
9.2 FUNCIONALIDADES DEL PROTOTIPO
Las características principales del prototipo se ven reflejadas en las siguientes
funcionalidades, las cuales se dividen en tres tipos de consulta.
9.2.1 Tipos de Consultas
Una vez se realiza el inicio de sesión en el prototipo se encuentra la interfaz
interna, allí al lado derecho del mismo se encuentra nuestro mapa de ubicación y
al lado izquierdo podemos encontrar los diferentes tipos de consulta que se
pueden realizar como lo muestra la ilustración 37
72
Ilustración 37. Estructura principal prototipo Fuente: Propia.
.
9.2.1.1 Consulta por atributos
El primer tipo de consulta que podemos realizar es por las características propias
de la imagen, lo que significa que una vez se acceda a este tipo de consulta, el
usuario podrá realizar filtros ordenados para tener acceso a la imagen, la descarga
de la misma y del metadato; los tipos de filtros establecidos son Tipo de sensor,
Proyecto, Misión, Nivel de procesamiento y Fecha de toma de la imagen. Una vez
realizado el filtro se encuentran las imágenes que cumplan con características
definidas, dentro del Banco de Imágenes y se podrá ver una vista preliminar de la
misma. (Ilustración 38, 39, 40, 41, 42 y 43).
73
Ilustración 38. Consulta por atributos. Fuente Propia
La Ilustración 39 que se muestra a continuación, representa la estructura inicial del
prototipo para realizar la consulta de información por atributos.
Ilustración 39. Estructura Inicial Consulta por Atributo. Fuente: Propia.
74
Una vez seleccionados los parámetros que queremos escoger para la búsqueda
de nuestra imagen y dando click en el botón buscar, el prototipo mostrara todas
las imágenes con las características previamente seleccionadas, como se muestra
en la ilustración 40.
Ilustración 40. Imágenes Consultadas por atributos Fuente Propia.
Teniendo una vez la imagen o imágenes con las características deseadas,
podemos realizar una visualización de estas imágenes en nuestro visor geográfico
dando click en el botón Ver de la parte izquierda de nuestro prototipo. Ilustración
41.
75
Ilustración 41. Visualización preliminar Imagen Fuente: Propia.
Finalmente se puede descargar o visualizar el metadato de la imagen
seleccionada; cabe aclarar que el botón del metadato redirige a una página
llamada Geonetwork, esta es la página en donde se encuentran almacenados los
metadatos de las imágenes en el IDEAM ilustración 43, y además también se
encuentra el botón de descarga de la imagen, esta descarga se realiza a la
carpeta que selecciones de preferencia. Ilustración 42.
76
Ilustración 42. Descarga de la Imagen Fuente: Propia.
Ilustración 43. Metadato de la imagen en Geonetwork Fuente: Geonetwork
77
9.2.1.2 Consulta por Grilla
Este tipo de consulta está dada por grillas predefinidas dentro del prototipo; estas
grillas son fijas para algunos satélites mientras que otros satélites tienen grillas por
demanda de imágenes. Como ejemplo para una grilla fija tenemos el satélite
Landsat y para una grilla por demanda de imágenes tenemos el satélite RapidEye.
El objetivo de este tipo de consulta es seleccionar la grilla del satélite que se
requiere consultar, con el objetivo de obtener las imágenes de sólo este satélite;
una vez seleccionada la grilla esta aparecerá en el mapa y se escogerá la zona de
la cual queremos obtener las imágenes, una vez seleccionada la zona, el prototipo
mostrará una ventana emergente (Pop-up) la cual expondrá la cantidad de
imágenes que se encuentran en esta zona y se podrán descargar , así como
también consultar el metadato. Ilustraciones (44, 44, 45,46, 47 y 48).
Ilustración 44. Consulta por grilla. Fuente Propia.
78
A continuación se mostrara la estructura de la consulta por grilla en donde el
recuadro número 1 representa los diferentes satélites de los que se poseen las
grillas; el recuadro número 2 da una descripción de cada uno de los satélites; y el
recuadro número 3 muestra los checkbox o cuadros de selección, estos permitirá
seleccionar la grilla de preferencia para la búsqueda. Ilustración 45.
Ilustración 45. Estructura Principal de la Consulta por Grilla. Fuente: Propia
En las ilustraciones 46 y 47 se puede observar algunos ejemplos de las grillas que
actualmente se encuentran dentro del prototipo, disponibles para consulta.
79
Ilustración 46. Visualización Grilla RapidEye. Fuente: Propia.
Ilustración 47. Visualización grillas Landsat Fuente: Propia.
80
Finalmente la ilustración 48 me representa la forma en poder descargar y
visualizar el metadato, como se mencionaba anteriormente se muestra en forma
de ventana emergente; esta representación en ventana emergente tiene como
propósito poder navegar por las diferentes imágenes que están debajo de esa
grilla.
Ilustración 48. Visualización Pop-up de información Fuente Propia.
9.2.1.3 Consulta por Mapa
Dentro de la consulta por mapa se pueden realizar varios filtros geográficos; el
primero consiste en realizar un filtro ya sea un Municipio o Departamento del país,
al hacer esto se realizara una consulta en el mapa de todas las imágenes que
estén contenidas dentro de este filtro previo con la opción de descarga y consulta
de metadato como en los anteriores tipos de consultas. El segundo tipo de
consulta geográfica es a través de la selección de un punto en el mapa, esto con
81
el fin de seleccionar todas las imágenes que se intersecten con este punto; y
finalmente si un usuario posee las coordenadas de la zona de la cual le interesa
obtener las imágenes puede hacerlo copiando estas coordenadas dentro del
prototipo.
La ilustración 49 representa la interfaz general de la consulta de información en
mapa, con cada una de sus funcionalidades en correcto funcionamiento.
Ilustración 49. Consulta por Mapa. Fuente: Propia
Las ilustraciones 50 y 51 muestran la funcionalidad de la consulta de imágenes
por departamento dentro del prototipo, en este caso se selecciona Cundinamarca
(Ilustración 50) y como resultado muestra todas las imágenes que se intersectan
con el departamento dentro del Banco de imágenes (Ilustración 51), de igual
manera permite su descarga y la consulta del metadato.
82
Ilustración 50. Consulta por Departamento Fuente: Propia.
Ilustración 51. Resultado de consulta por Departamento Fuente: Propia.
83
El otro tipo de consulta es por municipio, como vemos en la ilustración 52
seleccionamos Bogotá y en la ilustración 53 se muestra las imágenes que se
intersectan con Bogotá, donde podemos visualizarlas, descargarlas o revisar su
metadato.
Ilustración 52. Consulta por Municipio Fuente: Propia.
Ilustración 53. Resultado consulta por Municipio Fuente: Propia.
84
Se puede apreciar en las ilustraciones 54 y 55 el funcionamiento de la consulta por
punto, en la cual se selecciona dentro del visor geográfico la zona que queremos
consultar (Ilustración 54), esto automáticamente mostrara todas las imágenes que
están intersectadas con ese punto (ilustración 55); de igual manera dentro del
prototipo encontraremos un botón de borrado para que elimine ese punto y se
pueda generar una nueva consulta.
Ilustración 54. Consulta por Punto en mapa Fuente: Propia
Ilustración 55. Visualización Imágenes consultadas por punto en mapa Fuente: Propia.
85
Y finalmente encontramos la consulta por coordenadas, esta funciona de manera
similar a la consulta anterior; en este caso se pondrán las coordenadas (Latitud,
Longitud) (Ilustración 56) de la zona que deseamos consultar, esto generará un
punto en el visor geográfico y mostrara las imágenes allí se intersecten con el
punto (Ilustración 57).
Ilustración 56. Consulta por Coordenadas Fuente: Propia.
Ilustración 57. Visualización de la Imagen. Fuente: Propia.
86
CONCLUSIONES
Como se estableció en el objetivo general se realizó el diseño e implementación
de un Banco de Imágenes provenientes de sensores remotos, en una aplicación
web o prototipo, que permite la elaboración de consultas, visualización, descarga y
almacenamiento de las imágenes satelitales que cumplen con las características
definidas en este documento para el proyecto. El desarrollo e implementación de
un Banco de imágenes complementado con un visor geográfico es un gran avance
tecnológico para las instituciones que necesitan estandarizar, administrar y
visualizar su información de una manera dinámica y sencilla; actualmente son
pocas las instituciones nacionales que poseen un Banco de imágenes propio y
más aún que este soportado o complementado por un visor geográfico, lo que
afecta en gran manera la distribución y administración de recursos para compra de
información dentro de están entidades. En este sentido el prototipo IDEAM SAAI
(Sistema de Administración y Almacenamiento de Imágenes) generado para la
administración visualización y almacenamiento de la información representa un
importante avance tecnológico para el IDEAM como institución nacional y un
ejemplo a seguir para otras instituciones nacionales que aún se ven rezagadas en
este tipo de avances tecnológicos.
Para la elaboración e implementación del prototipo se realizó inicialmente un
trabajo investigativo por medio de reuniones con las dependencias pertenecientes
al IDEAM con el objetivo de generar un diagnóstico (Diagnostico para el diseño e
implementación de un Banco de Imágenes provenientes de sensores remotos
Anexo A), el cual género como resultado, la estructura de manejo de la
información que se realiza internamente, proporcionando así la visión tanto
general como particular de la situación actual lo cual fue la base para desarrollo de
los modelos y estructuras propuestos en este trabajo.
87
Para la estructuración de la base de datos, fue indispensable la definición y
modelamiento de esta a través de un esquema general (Modelo entidad relación) y
su evolución a un modelo conceptual. Lógico y Físico; modelos que son
indispensables para entender el funcionamiento de la base de datos y sus
relaciones. Estos modelos fueron corroborados con expertos de la oficina de
Informática del IDEAM para tener un modelo de base de datos acorde con las
necesidades y capacidades de la institución.
El montaje de la base de datos se realizó sobre Oracle data Base, siendo la
principal razón la elaboración de una banco de imágenes bajo las políticas y reglas
de negocio del IDEAM definidas en el documento de requerimientos funcionales
(Anexo C), sin embargo durante la realización del proyecto se puedo concluir que
la utilización de esta motor de bases de datos fue perfecto para este proyecto
debido a el tipo de dato espacial nativo (SDO_Geometry) que maneja este motor.
Para la implementación del banco de imágenes sobre un visor geográfico fue
fundamental la utilización de un servidor de servicios geográficos, en nuestro caso
ArcGIS SERVER, siendo esta una excelente herramienta para la exposición de
servicios de Imágenes (Image Services) y capas de información geográficas
(Features Services) en la web, los cuales fueron consumidos por el prototipo de
visor geográfico a través del uso del API de Java Script for ArcGIS con el que se
construyó el visor.
Dando como conclusión que la utilización de las herramientas de ArcGIS son una
excelente opción debido a que manejan el concepto de plataforma e interconexión
entre todas sus herramientas, además el IDEAM posee licencias de estos
productos y las cuales no estaban siendo utilizadas por la entidad, lo que ayudo a
la entidad al aprovechamiento de sus recursos.
88
Se sugiere para el funcionamiento del mismo prototipo, cumplir con los parámetros
de respuesta en solicitud, esto con respecto a las redes internas de internet, ya
que estos parámetros establecidos harán que las consultas en las peticiones del
aplicativo sean eficientes, en caso contrario al realizar una consulta podría tardar
en obtener una respuesta visual de la imagen. El prototipo cumple con los
parámetros propuestos de consulta para usuarios, obteniendo así de manera fácil,
rápida y sencilla consultas de todo tipo, tanto alfanuméricas como espaciales, esta
es una gran ventaja para usuarios expertos en temas de SIG como para usuarios
que no conocen o no son muy diestros en temas geográficos; otro de los grandes
resultados es el modulo que les permite a los administradores cargar la
información bajo los parámetros que se establecen en este trabajo, permitiendo
así la gestión adecuada de los datos .
Es importante mencionar que los usuarios y contraseñas se deberán tomar del
directorio activo del Instituto y para proyecciones futuras del prototipo se sugiere la
integración de este directorio activo que alimente la base de datos del prototipo.
La validación y funcionamiento del prototipo, tomando imágenes del Instituto
suministradas dio como resultado un buen desempeño en los diferentes tipos de
consultas propuestas. Se pudo validar que la información puede ser consultada de
manera más sencilla por un usuario tanto conocedor como no conocedor de temas
geográficos. De la misma forma se puede realizar la descarga tanto de la imagen
como su metadato general proporcionado por el IDEAM, lo que hace que los
usuarios conozcan de antemano las características de sus imágenes. Igualmente
se realizó el manual de usuario (Anexo D), el cual facilita a los administradores el
manejo interno de la herramienta.
89
El proceso de investigación, estructuración y propuesta de los modelos aquí
mencionados y la creación del Banco de Imágenes, resuelve el problema
planteado, que en pocas palabras resume que hoy en día las instituciones tanto
públicas como privadas que no conocen o no poseen sus datos estructurados, no
pueden darle el mejor uso a la información, lo que genera duplicidad, perdida y
deficiencia en la gestión de los datos.
90
BIBLIOGRAFÍA
Agudelo Benjumea, Mónica, (2013), Los metadatos. Ministerio de Educación
Nacional. Colombia
Arcos Cañar CP, Eras Navarrete GA (2015) Análisis, diseño e implementación del módulo de visualización y edición de estilos para el geoportal de la comunidad Salesiana Ariza, Francisco. Rodríguez, Antonio (2008). Introducción a la normalización en Información Geográfica: la familia ISO 19100. Grupo de Investigación en Ingeniería Cartográfica. Universidad de Jaén.
Banco Nacional de Imágenes, (2016). ¿Qué es el BNI? Recuperado de: http://bni.igac.gov.co:81/home/srv/es/info Capdevila, Joan (2004). Infraestructura de Datos Espaciales (IDE). Definición y desarrollo actual en España. Universidad de Barcelona. Caplan, Priscilla (1995). You call it corn, we call it syntax-independent metadata for documentlike objects. The Public Access Computer Systems Review, v. 4, n. 6. Recuperado de: http://epress.lib.uh.edu/pr/v6/n4/capl6n4.html.
Clementine Eliseo. (2009). A Conceptual Framework for Modelling Spatial Relations. L’Institut National des Sciences Appliquées de Lyon. Universidad de Lyon. Francia.
Coba de la Torre, Carlos Alejandro. Gómez Gómez, Pablo Mauricio. (2009). Análisis, diseño, construcción e implementación de un Geoportal con las herramientas Mongo DB, Json y Geojson para el proyecto IDE-UPS. Universidad Politécnica Salesiana. Ecuador.
CONPES 3585 (2009). Consolidación de la política nacional de información geográfica y la infraestructura colombiana de datos espaciales – ICDE.
91
Departamento Administrativo de Estadística DANE, Instituto Geográfico Agustín Codazzi IGAC, DNP: DDUPA.
CODINA, L.; del VALLE PALMA, M. (2001) Bancos de imágenes y sonido y indización en la WWW. Revista Española de Documentación Científica, vol. 24,p. 251-274.
Cuenca, Jaramillo. Dolores María (2010). Bancos de imágenes (investigación, conservación y difusión del patrimonio cultural). Universidad Complutense de Madrid. España. Doucet, Anne-Vinciane (2009). La descripción de las imágenes en Internet a través del análisis de 30 bancos de imágenes. Universidad de Granada. España. Federal Geographic Data Committee (1993), Geospatial Standards, Recuperado de: https://www.fgdc.gov/ GeoIngenio, (2012), Visores Web Geográficos. Recuperado de: http://www.geoingenio.com/visores-web-geografico Groot, R. (1997). Spatial data infrastructure (SDI) for sustainable land management. ITC journal GSDI, (2015). "The Global Spatial Data Infrastructure Association - Advancing a Location Enabled World”. Recuperado de: http://gsdiassociation.org/index.php/about-gsdi.html ICDE (2016), ¿Qué es la ICDE? Recuperado de: http://www.icde.org.co/quienes-somos/que-es-la-icde
International Standards Organisation, TC 211, 19115-GI-Metadata. Mancosu, Emanuele. (2009). Desarrollo de un prototipo para el Geoportal del
92
Centro Temático Europeo de Usos del Suelo e Información Espacial de la Agencia Europea del Medio Ambiente. Universitat Autònoma de Barcelona. Departament de Geografia. Barcelona, España. Manosalvas Durán LF, Naranjo Olalla BF. (2014) .Geoportal “IDE ESPE”, usando tecnología primefaces y herramientas open source, para el manejo de infraestructura de datos espaciales de la ESPE. Microsoft (2016). Reglas de negocios (Master Data Services). Recuperado de: https://msdn.microsoft.com/es-es/library/ff487015.aspx
Millán González, Luis; Saorín, Tomás; Ferrer-Sapena, Antonia; Benavent, Rafael Aleixandre y Peset, Fernanda. (2013). Gestión de datos de investigación: infraestructuras para su difusión. Revista internacional de Información “El Profesional de la Información”. Vol 2, num 5ª.
Mitchell, T. (2005). Web Mapping Illustrated. Editorial O’Really, California. 368 pp. Monge, Luís Ángel; Torres, Juan Pablo; López, Luz Evelia; Navarro, Christian Xavier. (2010). Análisis comparativo de servidores de mapas. Universidad Autónoma de Baja California. Nuevo México. LISSALDE, Claire. (2001). L’image scientifique: définitions, enjeux et questions. BBF, vol. 46, p. 26-33. Lopes de Oliveira, Juliano; Gonçalves Marcos André, Medeiros , Claudia Bauzer. (1999), A framework for designing and implementing the user interface of a geographic digital library. International Journal on Digital Libraries. PP (190 – 206).
Palacios, Juan; Ruata, Claudia (2009). Prácticas ágiles, Gestión de proyectos. Recuperado de: http://navegapolis.com/
93
Palacio Prieto, José Luis; Bocco, Gerardo; Velázquez, Alejandro; François Mas, Jean; Takaki- Takaki, Francisco; Victoria, Arturo; González, Laura Luna; Gómez Rodríguez, Gabriela; López García, José; Palma Muñoz, Mardocheo; Trejo Vázquez, Irma; Peralta Higuera, Armando; Prado Molina, Jorge; Rodríguez Aguilar, Adriana; Mayorga Saucedo, Rafael; González Medrano, Francisco.(2000) La condición actual de los recursos forestales en México: resultados del Inventario Forestal Nacional 2000. Instituto de Geografía, UNAM Pressman, Roger. (1997). Ingeniería del software: un enfoque práctico. (1ª Ed.) Editorial Luis Joyanes Aguilar. (Adaptado al español por Rafael Ojeda Martín). Sistema Geológico Colombiano, (2017), Geoportal del Servicio Geológico Colombiano. Recuperado de http://geoportal.sgc.gov.co/geoportalsgc/catalog/main/home.page Tomlinson Roger. (2007). Pensando en el SIG, Planificación del Sistema de Información Geogéafica Dirigida a Gerentes. (3ª Ed.). Editorial ESRI press. Voisard Agnès. (1994). Designing and integrating user interfaces of geographic database applications. Freie Universität Berlin, Institut für Informatik, D-14195 Berlin, Germany. PP (133-142). New York, USA.
94
ANEXOS
Anexo A: Diagnóstico para el diseño e implementación de un Banco de
imágenes provenientes de sensores remotos pertenecientes al Instituto de
hidrología, meteorología y estudios ambientales (IDEAM) como apoyo a
consolidación de la política nacional de información geográfica.
Anexo B: Script de la estructura de base de datos (SQL).
Anexo C: Especificación de Requerimientos IDEAM SAAI.
Anexo D: Manual de Usuario.
ANEXO A
ii
DIAGNOSTICO PARA EL DISEÑO E IMPLEMENTACIÓN DE UN BANCO DE
IMÁGENES PROVENIENTES DE SENSORES REMOTOS PERTENECIENTES AL
INSTITUTO DE HIDROLOGÍA, METEOROLOGÍA Y ESTUDIOS AMBIENTALES
(IDEAM) COMO APOYO A CONSOLIDACIÓN DE LA POLÍTICA NACIONAL DE
INFORMACIÓN GEOGRÁFICA
PRESENTADO POR: ROBERT ANDRÉS PULIDO ARIAS
CAMILO ANDRÉS PORRAS MARTIN
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA INGENIERÍA CATASTRAL Y GEODESIA
BOGOTÁ 2017
iii
TABLA DE CONTENIDO
1. INTRODUCCIÓN 4
2. OBJETIVOS 5
2.1 OBJETIVO GENERAL: ......................................................................................... 5
2.2 OBJETIVOS ESPECÍFICOS: ................................................................................ 5
3. ESTADO DEL ARTE 6
3.1 SUBDIRECCIÓN DE ECOSISTEMAS E INFORMACIÓN AMBIENTAL .............. 9
3.2 SISTEMA DE MONITOREO DE BOSQUES Y CARBONO (SMBYC) ............ 14
3.3 SUBDIRECCIÓN DE HIDROLOGÍA ................................................................ 15
3.4 OFICINA DEL SERVICIO DE PRONÓSTICOS Y ALERTAS.......................... 18
4. RECOMENDACIONES 20
5. CONCLUSIONES 21
4
1. INTRODUCCIÓN
El presente trabajo comprende la recopilación, análisis y recomendaciones del
estado actual de la información que proviene de sensores remotos (imágenes
satelitales), esta información pertenece al Instituto de Hidrología, Meteorología y
Estudios Ambientales de Colombia (IDEAM); a su vez este documento viene dado
como un diagnóstico de las imágenes, el cual tiene como fin dar a conocer el
estado actual de la información que llevara a la implementación de un Banco de
imágenes como un prototipo web.
Teniendo en cuenta cómo se está gestionando este tipo de información y quiénes
son los principales gestores y consumidores de la misma el proceso que se realizó
en el presente documento consto de reuniones con expertos temáticos o gestores
de datos del IDEAM, esto generó las referencias necesarias de las ventajas y
desventajas que existen en cuanto al manejo actual de la información, además
que se obtienen las necesidades de los usuarios y al ver estas necesidades se
genera un prototipo acorde a estas mismas. Una vez concretadas las reuniones se
pudo visualizar el conocimiento tanto particular como general de las personas que
son usuarias de la información, aclarando que cada una de estas personas
pertenecen a una subdirección o dependencia del IDEAM y conocen de primera
mano los insumos, con esto se pudo generar sugerencias como conclusiones las
cuales dan sustento al proceso de realizar un prototipo web de un banco de
imágenes.
5
2. OBJETIVOS
2.1 OBJETIVO GENERAL:
Realizar el análisis y diagnóstico del proceso de adquisición, administración
y almacenamiento de las imágenes provenientes de sensores remotos
propiedad del IDEAM, con el fin de conocer el estado actual de la
información y poder generar un prototipo web con base en las necesidades
encontradas en el instituto.
2.2 OBJETIVOS ESPECÍFICOS:
Identificar los tipos de productos (para este caso imágenes satelitales),
además de los usuarios y gestores de la información que hacen parte del
IDEAM.
Determinar cuál es el estado actual de la información a través de reuniones
que reflejen las necesidades de los usuarios.
Caracterizar la información recogida bajo los parámetros del IDEAM y
parámetros sugeridos como tipo de sensor, fecha de toma, localización,
entre otras con el fin de estandarizar los procesos y facilitar el uso de los
datos.
Generar las sugerencias necesarias, así como conclusiones de los
procesos anteriores mencionados.
6
3. ESTADO DEL ARTE
El IDEAM actualmente posee gran cantidad de información proveniente de
sensores remotos y obtenida de diferentes fuentes (ya sea Open Source,
compradas a las compañías distribuidoras o realizando convenios), esta cantidad
de información va creciendo a medida que va pasando el tiempo y es captada por
varios usuarios internos dentro del instituto, además de que esta se gestiona de
maneras distintas; por esta razón mostraremos el proceso que se realizó para
conocer el estado actual de dicha información, este proceso se divide en dos
partes: (1) se identificó los principales usuarios de la información, para ello se dará
a conocer el organigrama del IDEAM (Figura 1) con el fin de contextualizar la
estructura organizacional del instituto, (2) Una vez identificados los usuarios, se
realizó una reunión con cada uno de ellos para saber cómo se gestiona esta
información.
7
Figura 1. Organigrama IDEAM. Fuente: Página oficial IDEAM
Una vez conocida la estructura organizacional del instituto se indago sobre las
dependencias que son usuarias de la información, con esto se pudo identificar
estos principales usuarios de productos provenientes de sensores remotos, en las
cuales se encuentran las personas que manejan la información, en la figura 2 se
relacionan las Subdirecciones y oficinas y además en la figura 3 se muestra la
jerarquía interna de estos usuarios.
8
Figura 2 Dependencias donde se encuentras los usuarios de la información. Fuente: Propia
Figura 3. Estructura Jerárquica de los usuarios Internos.
9
Posteriormente se concretaron reuniones con cada uno de estos usuarios, los
cuales suministraron referencias del tipo de información que están usando, el
cómo se está gestionando y el cómo se almacena.
A continuación, se hará una reseña de la información obtenida en cada una de
estas dependencias.
3.1 SUBDIRECCIÓN DE ECOSISTEMAS E INFORMACIÓN AMBIENTAL
En esta subdirecciones se maneja gran cantidad de información proveniente de
sensores, esto se ve reflejado en el inventario suministrado por ellos en un archivo
de EXCEL (se adjunta el archivo al final de este documento), en este archivo se
hace un primer acercamiento de todas las imágenes que posee el instituto, a
continuación se analizara el archivo por los atributos más relevantes y se darán
conclusiones sobre este (En este caso los campos del Excel como vacíos o sin
información no se tuvieron en cuenta).
Tabla 1. Información atributiva más relevante encontrada en el inventario
10
El inventario suministrado posee gran cantidad de información atributiva, está en
muchos casos vacía o con poca información de referencia, atributos como por
ejemplo ubicación Trinea, Escala, Número Plancha 1:100, entre otros, en la tabla 1
no se tuvo en cuenta estos atributos por esta misma razón, además es difícil de
comprender exactamente a que se refieren ya que no posee ningún documento de
referencia.
A continuación, se mostrará la información de los atributos que para el desarrollo
del trabajo pueden ser más relevantes en cuanto al desarrollo del Banco de
Imágenes, estos atributos seleccionados tienen como fin tener referencias
importantes que serán base para el modelo propuesto al final de este diagnóstico.
Tipo de Sensor
Fecha de la imagen
Formato
Resolución
Medio almacenamiento
Localización medio
Cubrimiento
Proyección Geográfica
•Cruda
•Georreferenciada
•Orthorrectificada
•Corregistrada
Nivel de Georreferenciación
N° de bandas
• Inicial
• Final
Archivo Georreferenciación
Licencia
11
Tabla 2. Tipo de Sensor
Esta es la división de imágenes por el tipo de sensor, en esta tabla 2 no se tuvo en
cuenta las imágenes que no poseen sensor relaciona y tampoco se tiene en
cuenta el tipo de sensor “Humboldt” ya que este sensor no existe, se puede
analizar que esta imagen fue obtenida del Instituto Humboldt por algún tipo de
convenio, pero al no conocer más información no se puede categorizar. Debemos
hacer una aclaración en cada uno de las categorías de la tabla 2.
ADS 80 es una cámara Leica con un rango espectral en el Pancromático,
RGB (Red, Green, Blue), Infrarrojo-Cercano.
Las aerofotografías y los DEM (Modelo Digital de Elevación) son productos
de sensores remotos por esta razón no se puede tener en cuenta como un
tipo de sensor.
Los demás tipos de sensores dentro de la tabla si están categorizados de
manera adecuada
Tipo de Sensor
ADS_80AEROFOTOGRAFÍA
ALOS_PALSARCOSMOSKYMED
GEOEYEDEM
IKONOSLANDSAT
ORBISAR_RFPQUICKBIRDRADARSATRAPIDEYESCAN_SAR
SPOTTERRASARUK_DMC
Número de Imágenes
10
168
2
137
16
4
1
207
75
5
134
845
15
106
4
31
12
Tabla 3. Formato de la Imagen
La clasificación encontrada inicialmente para esta tabla posee información
repetida (esto significa que se tiene el mismo tipo de atributo pero llamado de dos
maneras distintas) por lo que se estandarizó esta información y se representa en
esta tabla 3.
Tabla 4. Fecha de la Imagen
Formato
Formato.DAT
Formato.RAW
GeoTiff
IMG
JPE
NLAPS Data Format
RADARSAT (ACRES CEOS)
RADARSAT (CEOS)
RAPIDEYE
spot dat
TIFF
Número de Imágenes
8
29
609
219
1
109
13
90
12
16
649
Fecha de toma
1972 - 1980
1981 - 1990
1991- 2000
2001 - 2010
2011 - 2013
Número de Imágenes
50
61
246
656
700
13
Para esta tabla 4 no se tuvo en cuenta fechas ambiguas de imágenes, por
ejemplo, existen imágenes con rangos de fecha y nombres que no son muy claro
de entender, es el caso de la imagen 2 Middle East-America- Africa 1986-1996;
algo a resaltar es que después del 2013 no se tiene referencia de ninguna imagen,
lo cual lleva a entender que actualmente no se sabe en donde están inventariadas
las imágenes del 2014, 2015 y 2016.
Tabla 5. Medio de almacenamiento
Para la tabla 5 se está representando la manera como las imágenes están
almacenadas actualmente dentro del IDEAM de una manera física, cabe aclarar
que Z/IDEAM hace referencia a una unidad de almacenamiento compartido dentro
del instituto, otro punto a aclarar es que la mayoría de imágenes se encuentran en
unidades externas que no se especifica exactamente a cuales se refiere, esto lo
evidenciamos al saber que los CD-ROM y los discos también son unidades
externas pero estas si están categorizada.
Almacenamiento
CD – ROM
DISCO
EN Z/IDEAM
UNIDAD EXTERNA
Número de Imágenes
301
635
103
720
14
Tabla 6 Localización del medio de almacenamiento
Esta tabla 6 tiene relación directa con la anterior tabla 5, ya que la tabla 5 nos
muestra en que medio físico esta almacenada la información mientras que esta
tabla 6 nos muestra quien posee este medio de almacenamiento, es preciso
aclarar que se desconoce si las imágenes que hacen referencia a los tres últimos
ítems (Hidrologia - IGAC, Humboldt, IGAC) se encuentran dentro del instituto o en
las entidades a las que se hace referencia.
3.2 SISTEMA DE MONITOREO DE BOSQUES Y CARBONO (SMBYC)
El proyecto Sistema de Monitoreo de Bosques y Carbono (SMBYC) hace parte de
la Subdirección de Ecosistemas e Información Ambiental, este proyecto cuenta
con bastante volumen de imágenes provenientes de sensores remotos, estas
imágenes son diferentes a las que posee la subdirección de Ecosistemas a la que
pertenece; a continuación se verá más al detalle la información que se obtuvo de
este proyecto (1. Tipo de información usada 2.Forma de almacenar la información)
En la reunión realizada con SMBYC a cargo de Gustavo Galindo, Lider Monitoreo
D&D, se habló del tipo de imágenes usadas dentro del proyecto, tales como
Landsat, RapidEye, QuickBird, Alos Palsar, Lidar, estas obtenidas de manera
Localización del medio de almacenamiento
Centro de documentación
Ecosistemas
En Z/IDEAM
Estudios Ambientales
Hidrología
Hidrología – IGAC
HUMBOLDT
IGAC
Número de Imágenes
301
140
103
572
30
179
191
243
15
gratuita, compradas o por convenios con otras instituciones y con licenciamientos
distintos (Monousuario, Multiusuario); para el caso de Landsat, se utiliza todo el
catalogo disponible, en el cual una vez obtenidas, se realiza un proceso de control
de calidad (este involucra una codificación y almacenado bajo una estructura pre-
establecida por el SMBYC) tanto para estas imágenes en crudo como para los
productos resultantes de estas; para el caso de sensores como RapidEye y
QuickBird se usan imágenes de alta resolución.
Se conoció de igual manera que el almacenamiento se realiza en el servidor del
IDEAM en donde se realizan Backups automáticos de la información y se tiene
organizado en forma de archivos (categorizado por sensor, escena y fecha).
Esta gran cantidad de información captada por el SMBYC difiere del Excel
entregado por la Subdirección de Ecosistemas e Información Ambiental, esto deja
como primera idea que aun dentro de una misma subdirección existen
discrepancias en cuanto a la información registrada en inventarios.
3.3 SUBDIRECCIÓN DE HIDROLOGÍA
La subdirección de hidrología es la encargada de realizar estudios tales como
Zonas inundables, niveles de los caudales, sequias entre otros, en esta
subdirección la reunión se realizó con el señor José Ville Triana, contratista en el
área de Hidrología, el cual comentó que la información de sensores más utilizada
en esta subdirección es Landsat, RapidEye, Radarsat, Lidar entre otras. Para
casos como estudios de zonas inundables, las imágenes usadas son Landsat, en
caso de querer manejar un nivel mayor de detalle se usa la información de
RapidEye y Radarsat.
Al igual que las demás direcciones el almacenamiento de la información se realiza
en los servidores que hacen parte de la infraestructura del IDEAM, en muchos
16
casos esta información aún no ha sido puesta en este servidor y se almacena en
discos externos.
Esta subdirección posee un catálogo de imágenes para inundaciones realizado
para agosto del 2013, allí no se encuentran todas las imágenes usadas durante
los proyectos pasados, pero es lo más cercano a un inventario actual (Se adjunta
el catalogo al final de este documento), a continuación se mostrará la información
atributiva relevante (Tipo de Sensor, cantidad de imágenes y la entidad que es
fuente de la información) para el desarrollo de nuestro trabajo.
Tabla 7. Imágenes de RADAR
Estas imágenes de RADAR de la tabla 7 se realizaron para los años 2010 al 2013
y no se encuentran referenciadas en algún otro inventario de los demás usuarios
de la información.
Tipo de Sensor
Envisat
AlosPalsar
Radarsat
Cosmo SkyMed
Terrasar
TOTAL
Número de Imágenes
1
2
182
432
3
620
17
Tabla 8. Imágenes ÓPTICAS
Para las imágenes de la tabla 8 también se encuentran referenciadas para los
años 2010 al 2013, un punto importante a aclarar es que estas imágenes pueden
estar contenidas dentro del inventario de la subdirección de Ecosistemas
mencionado en ítems anteriores, pero no se tiene certeza de cuales imágenes
exactamente son las que se encuentran en ambos inventarios, estas imágenes se
encuentran almacenadas en disco externos.
Tabla 9. Entidades Fuentes de la información
Para la tabla 9 se encuentran las entidades o empresas que aparecen como
fuentes de la información para el catálogo de los años 2010-2013, algunas de ellas
como Charter empresa dentro del sector aeronáutico, CONAE (Comisión Nacional
Tipo de Sensor
ADS 80UK_DMC2
SPOT 5GeoEyeIkonos
QuickBirdWorldViewRapidEyeTOTAL
Número de Imágenes
10334
16173
25
99
Entidad Fuente
Charter
CONAE
FAC – GMOSAIC - CONAE
IDEAM
IGAC
FAC
UK_DMC
ASTRIUM - GMOSAIC
TOTAL
Número de Imágenes
42438
1115231054
719
18
de Actividades Espaciales) una entidad argentina, FAC (Fuerza aérea
Colombiana), G-MOSAIC o servicio para la gestión de operaciones en la Unión
Europea, Astrium o división espacial de EADS (European Aeronautic Defence and
Space), UK DMC satélite británico que fue parte de la Disaster Monitoring
Constellation (DMC), IGAC o Instituto Geográfico Agustín Codazzi y finalmente el
IDEAM.
3.4 OFICINA DEL SERVICIO DE PRONÓSTICOS Y ALERTAS
La oficina del servicio de pronósticos y alertas están activos las 24 horas
realizando los diferentes análisis y pronósticos de la información que le es
suministrada, por ello son usuarios directos de las imágenes GOES que obtiene el
instituto, desde allí generan sus informes de pronostico y posibles alertas que se
tengan en el país.
La gestión que se realiza con estas imágenes GOES no se vincula directamente
con la oficina de pronósticos, si bien son los usuarios directos de la información no
son los encargados del almacenamiento y caracterización de estas, por esta razón
se remitió a los responsables de realizar este proceso (oficina de informática), a
continuación, veremos el flujo de trabajo (Imagen 2) y como se realiza desde
obtención de las imágenes GOES hasta llegar a la oficina de Pronósticos.
19
Imagen 2. Gestión de imágenes GOES. Fuente: Propia
La oficina de sistemas tiene un protocolo establecido para el gestionar de esta
información proveniente de sensores remotos, en este protocolo podemos denotar
3 pasos importantes los cuales son: 1. Antena receptora, 2. El Servidor 3.
Transferencia de archivos.
1. La antena receptora obtiene dos imágenes por hora, la primera imagen se
capta a las 00:15 horas y la última a las 23:45 horas todos los días.
2. El servidor almacena las imágenes de GVAR GOES y se caracterizan por:
Tipo de sensor, año, mes, día, hora internacional y la extensión GeoTiff,
además el almacenado se puede dividir en los tipos de banda o el canal
que le corresponda; una imagen posee 5 canales.
3. La transferencia de archivos se realiza una vez que las imágenes estén en
el servidor, los archivos allí guardados (GeoTiff y Jpg) son empaquetados
diariamente en formatos .tgz y el día 4 de cada mes se queman en un DVD
estos archivos del mes.
20
4. RECOMENDACIONES
Realizar un inventario unificado de toda la información proveniente de
sensores remotos y propiedad de los usuarios directos dentro del IDEAM,
este inventario debe estar bajo estándares establecidos previamente por el
instituto y que cumpla con las especificaciones mínimas para el prototipo de
banco de imágenes.
Posterior a la realización del inventario se debe unificar el almacenamiento
de la información, en este caso se debe hacer en el servidor del IDEAM y
bajo los parámetros que se tienen establecidos allí, esto proyectado a que
el prototipo de banco de imágenes realice la consulta de información a
través del servidor.
Los metadatos deben poseer los mismos estándares de calidad de las
imágenes para poder ser descargadas dentro del aplicativo web.
Establecer manuales para la organización de la información, este debe
llevar parámetros tanto de almacenamiento, como de gestión, esto
encaminado al banco de imágenes propuesto.
21
5. CONCLUSIONES
A continuación, se mostrarán algunas conclusiones generales del proceso
realizado anteriormente (reuniones con los usuarios principales de la información),
allí podremos evidenciar algunos de los errores que se encontraron.
El inventario con mayor información se encuentra en un archivo de Excel,
este está sin una organización adecuada o parámetros establecidos los
cuales faciliten el entendimiento del mismo.
Se encontró que las imágenes almacenadas presentan duplicidad, ya que
al indagar sobre la información no existe conocimiento entre dependencias,
lo que lleva a usa imágenes que posiblemente ya existan dentro del
instituto.
Las imágenes almacenadas no se encuentran centralizadas en el servidor
del instituto, por el contrario se encuentras en diferentes computadores o
dispositivos de almacenamiento como se indica en el estado del arte.
No se evidencia estándares establecidos dentro de manuales o instructivos
para la administración, gestión y almacenamiento de la información de
manera unificado, actualmente se hacen de maneras separadas.
Para el prototipo web de banco de imágenes se usaran solo imágenes
digitales y no análogas, esto por la referencia que se tiene de los
inventarios existentes.
ANEXO C
2
Control de Versiones
Fecha Versión Descripción Autor
2016-08-05 1.0 Creación del documento Robert Pulido
Camilo Porras
Elaborado por: Revisado por: Aprobado por:
Robert Pulido Estudiantes
Camilo Porras Estudiante
Luz Ángela Rocha
Director de Proyecto
Salomón Ramírez Co-director de Proyecto
3
TABLA DE CONTENIDO
1. INTRODUCCIÓN ............................................................................................................... 4
2. OBJETIVO ......................................................................................................................... 4
3. ALCANCE .......................................................................................................................... 4
4. METODOLOGÍA ................................................................................................................ 5
4.1 JUSTIFICACIÓN ......................................................................................................... …...5 4.2 MÉTODO ........................................................................................................................... 5
5. REGLAS DE NEGOCIO ..................................................................................................... 7
6. DEFINICIÓN DE ACTORES .............................................................................................. 9
7. ESPECIFICACIONES DE REQUERIMIENTOS DE SOFTWARE .....................................10
8. CASOS DE USO ...............................................................................................................10
8.1 DIAGRAMA DE CASOS DE USO ..................................................................................... 11 8.2 CU-IDEAM SAAI-01. INGRESAR AL SISTEMA USUARIOS IDEAM ................................ 12 8.3 CU-IDEAM SAAI-02. GESTIONAR USUARIOS EXTERNOS ........................................... 13 8.4 CU-IDEAM SAAI-02. GESTIONAR USUARIOS IDEAM ................................................... 16 8.5 CU-IDEAM SAAI- POSIBLE. INGRESAR AL SISTEMA USUARIOS EXTERNOS ............ 20 CU-IDEAM SAAI-03. GESTION DE INFORMACION ................ ¡ERROR! MARCADOR NO DEFINIDO. 8.6 CU-IDEAM SAAI-04. DESCARGA DE INFORMACION .................................................... 22 8.7 CU-IDEAM SAAI-05. PERMISOS DE ACCESO ............................................................... 24 8.8 CU-IDEAM SAAI-06. GENERAR INFORMES DE ESTADO DE LA INFORMACIÓN ......... 25 8.9 CU-SIGEU-07. PARAMETRIZAR PERÍODO DE VOTACIÓN ........................................... 27 8.10 CU-SIGEU-08. GENERAR Y PUBLICAR RESULTADOS DE VOTACIONES ................ 28 8.11 CU-SIGEU-09. CONSULTAR TIPO DE VOTACIÓN DEL ELECTOR¡ERROR! MARCADOR NO DEFINIDO. 8.12 CU-SIGEU-10. CONSULTAR TARJETÓN ELECTORAL¡ERROR! MARCADOR NO DEFINIDO. 8.13 CU-SIGEU-11. CONSULTAR PROPUESTA DE CANDIDATO¡ERROR! MARCADOR NO DEFINIDO. 8.14 CU-SIGEU-12. ELEGIR CANDIDATO POR ESTAMENTO¡ERROR! MARCADOR NO DEFINIDO. 8.15 CU-SIGEU-13. CONSULTAR RESULTADOS ELECTORALES¡ERROR! MARCADOR NO DEFINIDO.
9. ESPECIFICACIONES SUPLEMENTARIAS (NO FUNCIONALES) ...................................30
10. DEFINICIÓN DE TÉRMINOS ............................................................................................32
12. ANEXO A. INTERFACES ..................................................................................................46
4
INTRODUCCIÓN
Este documento detalla la especificación funcional requerida para cubrir las necesidades
funcionales identificadas en el almacenamiento, administración de Información
proveniente de sensores remotos administrada por el IDEAM.
Para cada requerimiento funcional se realizó la especificación de un caso de uso que
describe el detalle de la funcionalidad del sistema. Adicionalmente se complementan las
funcionalidades con la descripción de cada uno de los actores que intervienen en el
proceso y un diagrama general de Casos de Uso que describe la interacción de los
mismos entre sí para dar como resultado una funcionalidad.
Este diseño está basado en la información obtenida durante la etapa de diagnóstico que
se realizó en la institución para evaluar las condiciones actuales de la información, las
formas de almacenamiento, manejo y administración que actualmente se evidencian.
Para mayor información acerca de la etapa de diagnóstico se deberá remitir al documento
adjunto a este.
OBJETIVO
Describir cada una de las funcionalidades necesarias para la operación de un sistema de
administración y almacenamiento de imágenes provenientes de sensores remotos en
propiedad del IDEAM con el fin de poder gestionar de una mejor manera la información.
ALCANCE
Para realizar el diseño del Sistema de almacenamiento y administración de imágenes
provenientes de sensores remotos en propiedad del IDEAM se especifica a continuación
el alcance del presente documento:
Definir las reglas de negocio del Sistema de almacenamiento y administración de
imágenes provenientes de sensores remotos. (Ver Capítulo 5. DESCRIPCIÓN DE
5
REGLAS DE NEGOCIO).
Definir los Actores del Sistema. (Ver Capítulo 6. DEFINICIÓN DE ACTORES).
Definir los requerimientos funcionales del IDEAM SAAI. (Ver Capítulo 7.
ESPECIFICACIONES DE REQUERIMIENTOS DE SOFTWARE).
Modelar los casos de uso del sistema de almacenamiento y administración que son
diseñados de acuerdo con las necesidades del sistema. (Ver Capítulo 8. CASOS DE
USO DEL SISTEMA)
Definir los requerimientos suplementarios. (Ver Capítulo 9. ESPECIFICACIONES
SUPLEMENTARIAS).
METODOLOGÍA
JUSTIFICACIÓN
En la definición de requerimientos del sistema surge la necesidad de definir una
metodología de trabajo, que permita generar elementos de conocimiento común con el fin
de coordinar y optimizar el trabajo y desarrollo del software.
MÉTODO
1. Revisión y análisis de la información entregada por el cliente.
2. Establecimiento de reuniones programadas con las diferentes subdirecciones del
IDEAM con el fin de entender las formas de almacenamiento e administración de
la información.
3. Elaboración de un diagnóstico de la información actual, junto con el análisis de las
metodologías de administración y almacenamiento de las imágenes al interior del
IDEAM.
4. Reunión preliminar de para la muestra de resultados durante la etapa de
diagnóstico.
5. Definición de las reglas de negocio del IDEAM SAAI.
6. Definición de los requerimientos de acople funcional y no funcional del IDEAM
6
SAAI.
7. Definición de los casos de uso de sistema que permite identificar la interacción de
los actores y el sistema. Las actividades propias de cada actor se verán
reflejadas en el diagrama de casos de usos que también se incluye en este
documento.
8. Revisión de documento, donde el cliente verifica que la información contenida en
el mismo, corresponda al sistema requerido.
9. Aprobación del documento, donde se formaliza la aprobación del documento de
Especificación.
Para un mejor entendimiento tanto del análisis como del sistema, se utiliza la metodología
ágil SCRUM, la cual al ser realizada bajo un proyecto dinámico nos ofrece la posibilidad
de realizar entregas parciales y constantes del proceso del proyecto.
Scrum al ser una metodología de desarrollo ágil tiene una idea clara que es la creación
de ciclos breves para el desarrollo, en otros métodos esta idea se le llama iteraciones
pero en Scrum se le llaman “Sprints”. La metodología Scrum tiene 5 fases las cuales
definen el ciclo de desarrollo, estas son:
Concepto: Se describen las características del producto, en esta fase también se define
el equipo de trabajo que se encargara del desarrollo.
Especulación: En esta fase se establecen los limites (costos y agenda) que marcaran
el proceso de desarrollo; el producto se construirá a partir de ideas principales.
Exploración: Se revisa el producto con las funcionalidades.
Revisión: El equipo de desarrollo revisa y tiene en cuenta lo que ha construido y se
compara con el objetivo inicial.
Cierre: Se entrega en la fecha acordada la versión a la que está establecida, esto no
quiere decir que el proyecto esté finalizado, solo es el cierre de una versión; en esta
medida se seguirán haciendo los cambios los cuales se denominan “mantenimientos”.
7
REGLAS DE NEGOCIO
Regla 1: El IDEAM se encuentra estructurado por subdirecciones, proyectos y
oficinas que manejan información de sensores de manera independiente, debido a
permisos y licencias; por lo tanto se debe manejar una metodología de
clasificación de las imágenes teniendo en cuenta la estructura de la institución.
Regla 2: Manejo de un ADMINISTRADOR GLOBAL para la administración del
aplicativo IDEAM SAAI.
Regla 3: Manejo de un ADMINISTRADOR TEMPORAL para el Banco de
Imágenes, siendo este el encargado de subir la gran cantidad de información al
aplicativo.
Regla 4: Manejo únicamente de USUARIOS INTERNOS con acceso a la
información.
Regla 5: El ADMINISTRADOR GLOBAL se encargara la administración de
imágenes (Inserción, Actualización y Eliminación), para su consulta por parte de
los usuarios internos y Administradores Temporales.
Regla 6: El ADMINISTRADOR GLOBAL tendrá libre acceso a toda la información
perteneciente al IDEAM, únicamente para su implementación dentro del aplicativo
(Consulta y Descarga).
Regla 7: El ADMINISTRADOR TEMPORAL tendrá acceso limitado ya que solo
cumplirá la función de Ingresar nueva información.
Regla 8: El ADMINISTRADOR TEMPORAL podrá entregar nueva información al
ADMINISTRADOR GLOBAL para su almacenamiento y publicación en el Banco
de Imágenes.
Regla 9: El ADMINISTRADOR GLOBAL podrá eliminar información del Banco de
Imágenes, y esto deberá hacerse mediante la generación de una Copia de
Seguridad con el fin de evitar perdida de información valiosa para la institución.
Regla 10: El ADMINISTRADOR GLOBAL podrá generar nuevos usuarios
(Internos), registrados en el directorio activo de la institución
Regla 11: El ADMINISTRADOR GLOBAL deberá realizar la revisión del estado de
los servidores, además del estado de la información.
8
Regla 13: El ADMINISTRADO TEMPORAL no podrá eliminar información del
Banco ni actualizarla.
Regla 14: La inclusión de nueva información al Banco de Imágenes por parte del
ADMINISTRADOR TEMPORAL deberá ser realizada mediante autorización
expresa del administrador Global.
Regla 15: El USUARIO INTERNO tendrá acceso a la información que sea pública
en el Banco de Imágenes.
Regla 16: El USUARIO INTERNO únicamente tendrá permisos de consulta y
descarga de información.
Regla 17: El módulo de administración, únicamente funcionara para la inserción
de información dentro de la base de datos Oracle, no para almacenado en el
directorio de carpetas ni publicación de servicios.
Regla 18: El módulo de administración para el ADMINISTRADOR GLOBAL, ser
independiente del módulo de Administración del ADMINISTRADOR TEMPORAL.
Regla 19: No se modificara en ningún caso el sistema de referencia de las
imágenes.
Regla 20: Se realizara la publicación de los Servicios de Imágenes en ArcGIS
SERVER con el sistema de referencia WGS84.
Regla 21: Se realizara el guardado de las Imágenes en el directorio de carpetas
por parte de los ADMINISTRADORES TEMPORALES O GLOBAL manualmente,
como especifica el Manual de Usuario.
Regla 22: Se deberán seguir los parámetros de almacenamiento de las imágenes
según el manual de Usuario adjunto a este documento.
Se consignaran más reglas de negocio en próximas reuniones con el cliente.
9
DEFINICIÓN DE ACTORES
A continuación se describen los actores que hacen parte del IDEAM SAAI
NOMBRE Administrador Global AC-IDEAM SAAI-01
DESCRIPCIÓN Representa al usuario que almacena, administra y gestiona la información para el instituto dentro de una plataforma centralizada.
CAPACIDADES Crear, modificar o cambiar el estado de usuarios con rol de Administradores Temporal en el Banco de Imágenes, cuando haya terminado sus funciones de almacenamiento.
Crear, modificar o cambiar el estado de los (usuarios de consulta) dentro del Banco de Imágenes.
Realizar el procedimiento de almacenaje de la nueva información.
Verificación de la capacidad y estado de los servidores de almacenamiento.
Verificar el estado de la información.
Realización de Copias de seguridad
Realizar informes Generales y por Subdirecciones de la información.
NOMBRE Administrador Temporal AC- IDEAM SAAI -02
DESCRIPCIÓN Representa al usuario que realizará el cargue de imágenes al Banco, durante el tiempo que dure la migración de la información.
CAPACIDADES Realizar un informe de la información cargada al aplicativo, durante el proceso de migración.
NOMBRE Usuario Interno AC- IDEAM SAAI -03
DESCRIPCIÓN Representa al usuario que puede consultar y descargar la información.
CAPACIDADES Consultar la información dentro del Banco de imágenes.
Descargar la información que es de manera pública para su estado.
Consultar el metadato de las imágenes que se encuentran dentro del aplicativo.
10
ESPECIFICACIONES DE REQUERIMIENTOS DE SOFTWARE
Dentro de este ítem se realiza una descripción global de las funcionalidades que
dispondrá el IDEAM SAAI propuesto, detallando punto por punto cuáles serán éstas y su
alcance.
ÍTEM DESCRIPCIÓN
1. ADMINISTRACIÓN
RF- IDEAM SAAI -01
Ingresar al sistema Usuarios IDEAM Permitir a todos los actores tener acceso al sistema mediante el uso de un usuario y contraseña personal con los que tendrá la entrada a diversas funcionalidades que provee el sistema de acuerdo con los permisos otorgados al tipo de rol que tiene el usuario.
RF- IDEAM SAAI -02
Gestionar Usuarios IDEAM
Permitir la creación, modificación o cambio de estado de usuarios con rol de Administradores Temporal o usuario con rol de Usuario Interno.
RF- IDEAM SAAI -03
Gestionar información Administrador Temporal Permitir a los usuarios con rol de Administrador Temporal cargar la información proveniente de sensores remotos suministrada por la institución durante el proceso de migración al aplicativo.
RF- IDEAM SAAI -04
Gestionar Información Permitir al Administrador Global la administración directa de toda la plataforma, junto con el aplicativo.
2 OPERACIONALES
RF- IDEAM SAAI -05
Consultar información Los usuarios internos podrán hacer la respectiva consulta de la información que deseen y se encuentre dentro del banco.
RF- IDEAM SAAI -06
Descarga de Información El Usuario interno podrá descargar información que haya sido consultada.
RF- IDEAM SAAI -07
Generación de vista preliminar Permitir al usuario la visualización de las imágenes consultadas a través del sistema de consulta en un preview.
RF- IDEAM SAAI -08
Visualización Preliminar de la Imagen en un mapa El usuario podrá visualizar la ubicación de la información sobre un mapa lo que permitirá al determinar la ubicación exacta de la imagen.
RF- IDEAM SAAI -09
Consulta del metadato El usuario podrá consultar través de interacción con el mapa, mediante la creación de un punto.
CASOS DE USO
En este capítulo se realiza una descripción detallada de las funcionalidades que
11
dispondrá la solución propuesta, detallando punto por punto cuáles serán éstas y hasta
donde alcanzarán.
DIAGRAMA DE CASOS DE USO
Imagen 3 Diagrama de casos de uso
La imagen 1 muestra las interacciones de los casos de uso identificados en los
requerimientos funcionales descritos en el capítulo 7 del presente documento y los
actores del IDEAM SAAI. Este describe la forma en la que los actores interactúan a
través del límite del sistema y la respuesta del mismo con sus relaciones de tipo
asociación, extent e include (Ver capítulo 10. Definición de términos). Cada caso de uso
12
especificado está relacionado con el requerimiento de software al que hace referencia.
CU-IDEAM SAAI-01. INGRESAR AL SISTEMA USUARIOS IDEAM
NOMBRE Ingresar al sistema de los Usuarios del IDEAM
IDENTIFICADOR CU-IDEAM SAAI-01
ITERACIÓN Fachada PRIORIDAD Alta TIPO Necesario
RESUMEN
Permite a los usuarios internos y administrativos acceder al sistema mediante el uso de su número de identificación personal y una contraseña para hacer uso de las diversas funcionalidades que provee el sistema de acuerdo con los permisos otorgados al tipo de rol que tiene el usuario.
ACTOR(ES)
Primario(s) Usuario Interno
Soporte Administrador Global
INFORMACIÓN NECESARIA
Información Datos del usuario Responsable(s) Todos los usuarios
Flujo Ítem Características Evento
Entrada Usuario Texto (20), Obligatorio, Cuadro de texto
El usuario ingresa su código de usuario
Contraseña Texto (10), Obligatorio, Cuadro de texto
El usuario ingresa su contraseña
FLUJO PRINCIPAL
Flujo Paso Acción Escenario
1 1 Actor
El usuario ingresa a través de un navegador web a la página del sistema.
2 Sistema El Sistema despliega un formulario de autentificación de usuarios
3 Actor El Usuario ingresa los datos requeridos por el sistema
4 Sistema El Sistema habilita la opción “Iniciar sesión”
5 Actor El Usuario selecciona la opción “Iniciar sesión” habilitada en el formulario
6 Sistema El Sistema valida la información en su base de datos, si no es correcta continua en el flujo de excepción 2
7 Sistema El Sistema autentifica al usuario
FLUJO ALTERNATIVO
Flujo Paso Acción Escenario
1 1
2
3
2 1
2
3
FLUJO DE EXCEPCIÓN
Flujo Paso Acción Escenario
1 3 Actor El Usuario no ingresa todos los datos requeridos por el Sistema
4 Sistema El Sistema no habilita la opción “Iniciar sesión”
7 Sistema El sistema notifica al usuario que la operación no fue exitosa y le sugiere verificar sus datos de acceso e intentarlo nuevamente
2
PUNTO(S) DE EXTENSIÓN
13
NOMBRE Ingresar al sistema de los Usuarios del IDEAM
IDENTIFICADOR CU-IDEAM SAAI-01
DESENCADENADOR(ES)
1. Cada vez que el usuario quiera hacer uso de las funcionalidades que provee el sistema de acuerdo a su rol.
SUPUESTO(S)
1. El Usuario tiene acceso a internet 2. El Sistema está activo 3. El Usuario se encuentra registrado en la base de datos del Sistema
PRECONDICIÓN(ES)
1. El usuario ingresa a la dirección electrónica del sistema desde un navegador web
POSTCONDICIÓN(ES)
1. En caso de haberse realizado el procedimiento de manera exitosa, el sistema habilita las funcionalidades disponibles de acuerdo a los permisos concedidos al rol del usuario.
REGLA(S) DE NEGOCIO RELACIONADA(S)
AUTOR
Nombre Cargo
FECHA
Iteración Fachada Creación Modificación
Iteración Detallar Creación Modificación
Iteración Focalizar Creación Modificación
CU-IDEAM SAAI-02. GESTIONAR USUARIOS IDEAM
NOMBRE Gestionar usuarios Externos IDENTIFICADOR CU-IDEAM SAAI-02
ITERACIÓN Fachada PRIORIDAD Alta TIPO Necesario
RESUMEN
Permite a los usuarios con rol de administrador global acceder a un módulo el cual les permitirá acceder a la cuenta para la creación, modificación o cambio de estado de usuarios con rol de Administradores Temporal o usuario con rol de Usuario Interno.
ACTOR(ES)
Primario(s) Administrador Global Soporte Administrador Global
INFORMACIÓN NECESARIA
Información Datos del Usuario Responsable(s) Administrador Global
Flujo Ítem Características Evento
Usuario Texto(20), obligatorio, modificable, cuadro de texto
El Usuario ingresa un nombre de usuario para el usuario que desea registrar
Contraseña Texto(10), obligatorio, modificable, cuadro de texto
El Usuario asigna una contraseña al usuario que está registrando
FLUJO PRINCIPAL
Flujo Paso Acción Escenario
1 1 Actor
El Administrador Global selecciona el módulo de “Gestión de usuarios” en el menú de administración
14
NOMBRE Gestionar usuarios Externos IDENTIFICADOR CU-IDEAM SAAI-02
2 Sistema El Sistema despliega un módulo de “Gestión de usuarios” con las opciones: “Registrar Usuario”, “Modificar Usuario”, “Cambiar Estado Usuario”.
3 Actor El Administrador Global selecciona la opción “Registrar Usuario”
4 Sistema El Sistema despliega un formulario para registrar los datos necesarios en la creación de Usuarios Externos
5 Actor El Administrador Global diligencia el formulario con los datos requeridos
6 Actor El Administrador Global selecciona la opción “Guardar” habilitada en el formulario
7 Sistema El sistema valida la información ingresada, si los datos no están completos continua con el flujo de excepción 1, si los datos no son válidos continua en el flujo de excepción 2
8 Sistema El Sistema despliega un mensaje mostrando el nombre del usuario a crear, solicitando confirmación por parte del Usuario en la operación de registro
9 Actor El Administrador Global confirma la operación seleccionando la opción “Aceptar”, si no continua el flujo de excepción 5
10 Sistema El Sistema registra la información en su base de datos
11 Sistema El Sistema notifica al usuario que la operación de registro fue exitosa
FLUJO ALTERNATIVO
Flujo Paso Acción Escenario
1 3 Actor
El Administrador Global selecciona la opción “Modificar Usuario” o “Cambiar Estado Usuario”.
4 Sistema El Sistema despliega un formulario de consulta para buscar el usuario que se desea modificar.
5 Actor El Administrador Global diligencia el formulario, nombre de usuario y contraseña.
6 Sistema El Sistema verifica la información suministrada en el formulario por el Usuario, si los datos no son válidos continua en el flujo de excepción 7.
7 Sistema El Sistema despliega un formulario con los datos del Usuario validado por el sistema.
8 Actor El Usuario modifica los datos del formulario
9 Actor El Usuario selecciona la opción “Guardar” habilitada en el formulario
10 Sistema El Sistema valida la información del formulario, si los datos no son válidos continua en el flujo 2, si los datos no fueron modificados continua en el flujo de excepción 3
11 Sistema El Sistema despliega un mensaje mostrando el nombre del usuario a modificar, solicitando confirmación por parte del Usuario en la operación de modificación
12 Actor El Administrador Global confirma la operación seleccionando la opción “Aceptar”, si no continua el flujo de excepción 5
13 Sistema El Sistema actualiza la información en su base de datos
14 Sistema El Sistema notifica al usuario que la operación de modificación fue exitosa
FLUJO DE EXCEPCIÓN
Flujo Paso Acción Escenario
1 7 Sistema
El Sistema despliega un mensaje notificando al usuario de forma clara cual(es) dato(s) es(son) requerido(s) y no fue(ron) ingresado(s)
8 Actor El Administrador Global cierra el mensaje
9 Sistema El Sistema regresa al formulario de registro
15
NOMBRE Gestionar usuarios Externos IDENTIFICADOR CU-IDEAM SAAI-02
2 9 Sistema
El Sistema despliega un mensaje notificando al usuario de forma clara cual(es) dato(s) no es(son) validos
10 Actor El Administrador Global cierra el mensaje
11 Sistema El Sistema regresa al formulario de registro
3 9 Sistema
El Sistema notifica al usuario que no se modificó la información del usuario seleccionado
10 Actor El Administrador Global cierra el mensaje
11 Sistema El Sistema regresa al formulario de registro
4 8 Sistema
El Sistema notifica al usuario que no se han seleccionado usuarios para la operación Cambio de estado
5 11 Usuario El Administrador Global selecciona la opción “Cancelar”
12 Sistema El Sistema regresa al menú de “Administración”
6 0 Usuario
El Administrador Global en cualquier momento selecciona la opción “Cerrar”
1 Sistema El Sistema regresa al usuario a la página de inicio de sesión.
7 7 Sistema
El Sistema despliega un mensaje notificando al usuario de forma clara cual(es) dato(s) no es(son) validos.
8 Actor El Administrador Global cierra el mensaje
9 Sistema El Sistema regresa al formulario de registro
PUNTO(S) DE EXTENSIÓN
DESENCADENADOR(ES)
1. En cualquier momento que el Administrador necesite crear o modificar un Usuario.
SUPUESTO(S)
1. El Usuario tiene acceso a internet 2. El Sistema está activo 3. El Usuario se encuentra registrado en la base de datos del Sistema si se realiza un proseos
de modificación
PRECONDICIÓN(ES)
1. El Usuario debe estar autentificado en el sistema 2. El Usuario debe seleccionar una opción del menú de administración del sistema
POSTCONDICIÓN(ES)
1. Los Administradores locales quedan registrados en el sistema
REGLA(S) DE NEGOCIO RELACIONADA(S)
AUTOR
Nombre Cargo
FECHA
Iteración Fachada Creación Modificación
Iteración Detallar Creación Modificación
Iteración Focalizar Creación Modificación
16
CU-IDEAM SAAI-03. GESTIONAR INFORMACIÓN ADMINISTRADOR TEMPORAL
NOMBRE Gestionar Información IDENTIFICADOR CU-IDEAM SAAI-03
ITERACIÓN Fachada PRIORIDAD Alta TIPO Necesario
RESUMEN
El Administrador Temporal selecciona la opción de cargar, borrar, actualizar imágenes procedentes de sensores remotos, estas imágenes estarán en formato compatible con la plataforma y con permiso de las diferentes subdirecciones, proyecto u oficinas para hacer la carga al sistema de las mismas.
ACTOR(ES)
Primario(s) Administrador Temporal Soporte Administrador Global
INFORMACIÓN NECESARIA
Información Datos procedentes de las diferentes subdirecciones, oficinas y proyectos dentro del IDEAM a si mismo también imágenes otorgadas por otras instituciones.
Responsable(s) IDEAM
Flujo Ítem Características Evento
Entrada Imagen proveniente de sensores remotos
Identificación, texto (20), obligatorio, inmodificable. Tipo de sensor, texto (20), obligatorio, inmodificable, caja de selección con las opciones de Imágenes de sensores disponibles en el mercado. Fecha de toma de la imagen, texto (20), obligatorio, modificable, caja de selección de fecha estructurado por dd/mm/yy. Formato de la Imagen, caja de selección con las opciones de formatos disponibles. Subdirección, Oficina o proyecto de procedencia, caja de selección con las opciones disponibles. Espacio de toma de la imagen, texto (20), Obligatorio, Modificable.
El administrador Temporal, desde el módulo de administrador, procederá a cargar la nueva información.
Metadato de la Imagen Identificación, texto (20), obligatorio, inmodificable, deberá tener el mismo número de identificación de la imagen con la diferenciación de la letra M al final de este.
El administrador temporal desde el módulo de administrador ingresara en el sistema el metadato de la imagen que cargo al sistema anteriormente.
FLUJO PRINCIPAL
Flujo Paso Acción Escenario
17
NOMBRE Gestionar Información IDENTIFICADOR CU-IDEAM SAAI-03
1 1 Actor
El Usuario selecciona el módulo de “Administrar Información” en el menú de administración
2 Sistema El Sistema despliega un módulo de “Administrar Información” con las siguientes opciones: “Nueva Información”, “Actualizar Información”, “Consulta de Información”, “Eliminar Información”
3 Actor El Usuario selecciona la opción “Nueva Información”
4 Sistema El Sistema despliega un módulo de registro y carga de la nueva información.-
5 Actor El Usuario ingresa la información requerida por el modulo
6 Actor El Usuario después de llenar la información, selecciona la opción validar
7 Sistema
El Sistema valida la información descrita por el Usuario, si no está completa continua con flujo de excepción 1, si alguno de los datos contenidos no es válido continua con el flujo de excepción 2, si ya existe información en la base de datos con el mismo identificador que se está intentando ingresar continua con el flujo de excepción 3.
8 Sistema El Sistema despliega un mensaje “Información Satisfactoriamente validada”
9 Actor El Usuario selecciona la opción “Cargar Nueva Información”
10 Sistema El Sistema despliega una nueva ventana para la búsqueda de la información dentro del ordenador
11 Actor El usuario busca dentro del ordenador la información a cargar y la selecciona
12 Actor El usuario selecciona la opción “Cargar”
13 Sistema El Sistema valida la información ingresada en el módulo, si dicha información no corresponde con el formato de la imagen continua con el flujo de excepción 4
14 Sistema El Sistema despliega un mensaje mostrando el nombre del archivo seleccionado, solicitando confirmación por parte del usuario en la operación cargar la nueva información seleccionada.
15 Actor El Usuario confirma la operación seleccionando la opción “Aceptar”, si no continua el flujo de excepción 5
16 Sistema El Sistema carga la información en su base de datos
17 Sistema El Sistema notifica al usuario que la operación de carga de imagen fue exitosa
FLUJO ALTERNATIVO
Flujo Paso Acción Escenario
1 3 Actor El Usuario selecciona la opción “Actualizar Información”
4 Sistema El Sistema despliega un módulo para la consulta de la imagen a actualizar
5 Actor El Usuario introduce la información necesaria, para la consulta de la imagen a actualizar
6 Sistema
El Sistema valida la información ingresada, si la información está incompleta continua flujo de excepción 1.2, si la información suministrada no se encuentra registrada continua con el flujo de excepción 6
7 Sistema El Sistema despliega una venta en donde aclara que se traerá la información relacionada con el número de identificación ingresado en el módulo anterior.
8 Actor El Usuario selecciona la opción “Aceptar”, si no es así, continua con el flujo de excepción 7
18
NOMBRE Gestionar Información IDENTIFICADOR CU-IDEAM SAAI-03
9 Sistema El Sistema trae la información de la imagen relacionada con el número de identificación ingresado
10 Actor El Usuario modifica los campos que el modulo permite actualizar
11 Actor El Usuario selecciona la opción “Actualizar Información”
12 Sistema El Sistema verifica la información actualizada, si se ha dejado un campo vacío continua con el flujo de excepción 2, si uno de los campos no es válido, continua con el flujo de excepción 2
13 Sistema El Sistema despliega una ventana donde pregunta al usuario si está seguro en actualizar la información
14 Actor El Usuario selecciona la opción “Aceptar” de lo contrario continua con el flujo de excepción 5.2
15 Sistema El Sistema actualiza la información en su base de datos
16 Sistema El Sistema notifica al usuario que la actualización de la información fue exitosa
2 3 Actor El Usuario selecciona la opción “Consulta de Información”
4 Sistema El Sistema despliega un módulo para la consulta de imágenes por Identificador
5 Actor El Usuario introduce la información necesaria, para la consulta de la imagen
6 Sistema El Sistema valida el número de identificación ingresado, si el campo esa vacío continua con el flujo de excepción 8, si el identificador no se encuentra registrado continua con el flujo de excepción 6.2
7 Sistema El Sistema despliega una venta en donde aclara que se traerá la información relacionada con el número de identificación ingresado en el módulo anterior.
8 Actor El Usuario selecciona la opción “Aceptar”, si no es así, continua con el flujo de excepción 7.2
9 Sistema El Sistema trae la información de la imagen relacionada con el número de identificación ingresado
10 Sistema El Sistema notifica al usuario que la información ha sido consultada exitosamente
3 3 Actor El Usuario selecciona la opción “Eliminar Información”
4 Sistema El Sistema despliega un módulo para la consulta de imágenes por Identificador
5 Actor El Usuario introduce la información necesaria, para la consulta de la imagen
6 Sistema El Sistema valida el número de identificación ingresado, si el campo esa vacío continua con el flujo de excepción 8.2, si el identificador no se encuentra registrado continua con el flujo de excepción 6.3
7 Sistema El Sistema despliega una venta en donde aclara que se traerá la información relacionada con el número de identificación ingresado en el módulo anterior.
8 Actor El Usuario selecciona la opción “Aceptar”, si no es así, continua con el flujo de excepción 5.3
9 Sistema El Sistema trae la información de la imagen relacionada con el número de identificación ingresado
10 Sistema El Sistema notifica al usuario que la información ha sido consultada exitosamente
11 Sistema El Sistema despliega dentro de la información traída la opción de “Eliminar”
19
NOMBRE Gestionar Información IDENTIFICADOR CU-IDEAM SAAI-03
12 Sistema El Usuario selecciona la opción “Eliminar”, si no continua con el flujo de excepción 5.3
13 Sistema El Sistema una notificación en la que se advierte al usuario que está a punto de eliminar una imagen
14 Usuario
El Usuario selecciona la opción “Eliminar”, de lo contrario continua con el flujo de excepción 5.3
15 Sistema
El Sistema despliega una notificación en donde informa que “La imagen ha sido eliminada exitosamente”
FLUJO DE EXCEPCIÓN
Flujo Paso Acción Escenario
1 8 Sistema
El Sistema despliega un mensaje notificando al usuario que la información registrada está incompleta
9 Actor El Usuario cierra el mensaje
10 Sistema El Sistema regresa al módulo de “Nueva Información”
1.2 7 Sistema
El Sistema despliega un mensaje notificando al usuario que la información registrada está incompleta
8 Actor El Usuario cierra el mensaje
9 Sistema El Sistema regresa al módulo de “Actualizar Información”
2 8 Sistema
El Sistema despliega un mensaje notificando al usuario que alguno de los campos solicitados no se llenó correctamente
9 Actor El Usuario cierra el mensaje
10 Sistema El Sistema regresa al módulo de “Nueva Información”
3 8 Sistema
El Sistema despliega un mensaje notificando al usuario que el identificador ya está en uso
9 Actor El Usuario cierra el mensaje
10 Sistema El Sistema regresa al módulo de “Nueva Información”
4 9 Sistema
El Sistema despliega un mensaje notificando al usuario que el archivo seleccionado no cumple con el formato requerido
10 Actor El Usuario selecciona la opción “Cancelar”
11 Sistema El Sistema regresa al menú de “Nueva Información”
5 16 Usuario El Usuario en cualquier momento selecciona la opción “Cancelar”
17 Sistema El Sistema regresa al usuario a la página de “Nueva Información”
5.2 15 Usuario El Usuario en cualquier momento selecciona la opción “Cancelar”
16 Sistema El Sistema regresa al usuario a la página de “Actualizar Información”
5.3 9 Usuario El Usuario en cualquier momento selecciona la opción “Cancelar”
10 Sistema El Sistema regresa al usuario a la página de “Eliminar Información”
6 7 Sistema
El Sistema despliega un mensaje notificando que no existe una imagen asociada a ese identificador
8 Usuario El Usuario cierra el mensaje
9 Usuario El Sistema regresa al módulo de “Actualizar Información”
6.2 7 Sistema
El Sistema despliega un mensaje notificando que no existe una imagen asociada a ese identificador
8 Usuario El Usuario cierra el mensaje
9 Usuario El Sistema regresa al módulo de “Consultar Información”
6.3 7 Sistema
El Sistema despliega un mensaje notificando que no existe una imagen asociada a ese identificador
8 Usuario El Usuario cierra el mensaje
9 Usuario El Sistema regresa al módulo de “Eliminar Información”
7 9 Usuario El Usuario en cualquier momento selecciona la opción “Cancelar”
10 Sistema El Sistema regresa al usuario a la página de “Actualizar Información”
20
NOMBRE Gestionar Información IDENTIFICADOR CU-IDEAM SAAI-03
7.2 9 Usuario El Usuario en cualquier momento selecciona la opción “Cancelar”
10 Sistema El Sistema regresa al usuario a la página de “Consultar Información”
8 7 Sistema
El Sistema despliega un mensaje informando al usuario que no se ha suministrado información para la consulta
8 Actor El Usuario selecciona la opción “Aceptar”
9 Sistema El Sistema regresa al menú de “Consultar Información”
8.2 7 Sistema
El Sistema despliega un mensaje informando al usuario que no se ha suministrado información para la consulta
8 Actor El Usuario selecciona la opción “Aceptar”
9 Sistema El Sistema regresa al menú de “Eliminar Información”
PUNTO(S) DE EXTENSIÓN
DESENCADENADOR(ES)
1. Cada vez que se inicie un proceso de consulta, actualización, adición o eliminación de información
SUPUESTO(S)
1. El Usuario tiene acceso a internet 2. El Sistema está activo 3. El Usuario se encuentra registrado en la base de datos del Sistema 4. Los archivos de texto cumplen con el formato preestablecido 5. El Usuario tiene permisos de Adición y Eliminación de información
PRECONDICIÓN(ES)
1. El Usuario debe estar autentificado en el sistema 2. El Usuario debe tener autorización para la modificación de la información
POSTCONDICIÓN(ES)
1. La información nueva ingresada, quedara registrada en la base de datos 2. La información eliminada, quedara eliminada de la base de datos 3. La actualización de la información, quedara registrada en la base de datos
REGLA(S) DE NEGOCIO RELACIONADA(S)
Regla 2, Regla 3
AUTOR
Nombre Cargo
FECHA
Iteración Fachada Creación Modificación
Iteración Detallar Creación Modificación
Iteración Focalizar Creación Modificación
8.4 CU-IDEAM SAAI- 4. GESTION DE INFORMACIÓN
NOMBRE Ingresar al sistema de los Usuarios del IDEAM
IDENTIFICADOR CU-IDEAM SAAI-04
ITERACIÓN Fachada PRIORIDAD Alta TIPO Necesario
RESUMEN
Permitir al Administrador Global la administración directa de toda la plataforma, junto con el aplicativo.
ACTOR(ES)
Primario(s) Usuario Global
Soporte IDEAM
21
NOMBRE Ingresar al sistema de los Usuarios del IDEAM
IDENTIFICADOR CU-IDEAM SAAI-04
INFORMACIÓN NECESARIA
Información Datos del usuario Responsable(s) Todos los usuarios
Flujo Ítem Características Evento
Entrada Usuario Texto (20), Obligatorio, Cuadro de texto
El usuario ingresa su código de usuario
Contraseña Texto (10), Obligatorio, Cuadro de texto
El usuario ingresa su contraseña
FLUJO PRINCIPAL
Flujo Paso Acción Escenario
1 8 Actor
El usuario ingresa a través de un navegador web a la página del sistema.
9 Sistema El Sistema despliega un formulario de autentificación de usuarios
10 Actor El Usuario ingresa los datos requeridos por el sistema en el módulo de administración.
11 Sistema El Sistema habilita la opción “Iniciar sesión”
12 Actor El Usuario selecciona la opción “Iniciar sesión” habilitada en el formulario
13 Sistema El Sistema valida la información en su base de datos, si no es correcta continua en el flujo de excepción 2
14 Sistema El Sistema autentifica al usuario
FLUJO ALTERNATIVO
Flujo Paso Acción Escenario
1 4
5
6
2 4
5
6
FLUJO DE EXCEPCIÓN
Flujo Paso Acción Escenario
1 5 Actor El Usuario no ingresa todos los datos requeridos por el Sistema
6 Sistema El Sistema no habilita la opción “Iniciar sesión”
2 7 Sistema
El sistema notifica al usuario que la operación no fue exitosa y le sugiere verificar sus datos de acceso e intentarlo nuevamente
PUNTO(S) DE EXTENSIÓN
DESENCADENADOR(ES)
2. Cada vez que el usuario quiera hacer uso de las funcionalidades que provee el sistema de acuerdo a su rol.
SUPUESTO(S)
4. El Usuario tiene acceso a internet 5. El Sistema está activo 6. El Usuario se encuentra registrado en la base de datos del Sistema
PRECONDICIÓN(ES)
2. El usuario ingresa a la dirección electrónica del sistema desde un navegador web
POSTCONDICIÓN(ES)
2. En caso de haberse realizado el procedimiento de manera exitosa, el sistema habilita las funcionalidades disponibles de acuerdo a los permisos concedidos al rol del usuario.
REGLA(S) DE NEGOCIO RELACIONADA(S)
22
NOMBRE Ingresar al sistema de los Usuarios del IDEAM
IDENTIFICADOR CU-IDEAM SAAI-04
AUTOR
Nombre Cargo
FECHA
Iteración Fachada Creación Modificación
Iteración Detallar Creación Modificación
Iteración Focalizar Creación Modificación
CU-IDEAM SAAI-06. CONSULTAR INFORMACIÓN
NOMBRE Consultar información IDENTIFICADOR CU-IDEAM SAAI-5
ITERACIÓN Detallar PRIORIDAD Alta TIPO Necesario
RESUMEN
El Usuario interno del IDEAM podrá hacer la respectiva consulta de la información que deseen dentro de la plataforma.
ACTOR(ES)
Primario(s) Usuario Interno Usuario Externo
Soporte Administrador Central Sistema
INFORMACIÓN NECESARIA
Información Usuario Contraseña
Responsable(s) Sistema
Flujo Ítem Características Evento
FLUJO PRINCIPAL
Flujo Paso Acción Escenario
1 1 Actor
El usuario ingresa a través de un navegador web a la página del sistema.
2 Sistema El Sistema despliega un formulario de autentificación de usuarios
3 Actor El Usuario ingresa los datos requeridos por el sistema
4 Sistema El Sistema habilita la opción “Iniciar sesión”
5 Actor El Usuario selecciona la opción “Iniciar sesión” habilitada en el formulario
6 Sistema El Sistema valida la información en su base de datos, si no es correcta continua en el flujo de excepción 2
7 Sistema El Sistema autentifica al usuario
2 1 Actor
El usuario selecciona el tipo de consulta que desea, entre, “Consulta por atributo”, “consulta por grilla” y “consulta por mapa”
2 Sistema El sistema despliega las opciones de búsqueda que el usuario escoja.
3 Actor El usuario selecciona la consulta por atributo.
4 Actor El usuario selecciona los parámetros y da click en buscar.
5 Sistema El sistema despliega los filtros de consulta, Tipo de Sensor, Proyecto, Misión, Nivel de Procesamiento, Fecha de Toma.
6 Sistema El sistema realiza la búsqueda de las imágenes que cumplan con estas características.
7 Actor El usuario selecciona la consulta por grilla.
8 Actor El usuario selecciona la grilla que desea consultar
9 Sistema El sistema despliega los diferentes tipos de grilla establecidos
23
NOMBRE Consultar información IDENTIFICADOR CU-IDEAM SAAI-5
10 Sistema El sistema muestra en el mapa la grilla seleccionada.
11 Actor El usuario selecciona la grilla de la zona que quiere consultar.
12 Sistema El sistema abre un pop-up de todas las imágenes contenidas en esta zona de la grilla.
13 Actor El usuario selecciona la consulta por mapa.
14 Sistema El sistema despliega los diferentes tipos consulta por mapa: Departamento o municipio, punto o coordenadas
15 Actor El usuario selecciona consulta por Departamento o Municipio
16 Actor El usuario selecciona consulta por punto y da click sobre el mapa.
17 Actor El usuario selecciona consulta por coordenadas
18 Sistema El sistema despliega los departamentos o municipios del país.
19 Sistema El sistema habilita la opción de poner un punto en el mapa
20 Sistema
El sistema permite colocar las coordenadas de la zona que se quiere consultar.
21 Sistema El sistema muestra las imágenes del departamento seleccionado.
22 Sistema El sistema muestra las imágenes contenidas dentro la zona que se seleccionó por el punto.
23 Sistema El sistema muestra las imágenes de las coordenadas que se seleccionaron.
FLUJO ALTERNATIVO
Flujo Paso Acción Escenario
1 1
2
3
2
FLUJO DE EXCEPCIÓN
Flujo Paso Acción Escenario
1
3 Actor El Usuario no ingresa todos los datos requeridos por el Sistema
4 Sistema El Sistema no habilita la opción “Iniciar sesión”
7 Sistema El sistema notifica al usuario que la operación no fue exitosa y le sugiere verificar sus datos de acceso e intentarlo nuevamente
2 6 Sistema
El sistema no muestra ninguna imagen porque dentro del banco no existe ninguna imagen con esas características.
12 Sistema El sistema no muestra ninguna imagen porque dentro de la grilla seleccionada no se intersecta ninguna imagen.
21 Sistema El sistema no muestra ninguna imagen porque en el Departamento o Municipio no hay ninguna imagen de esa zona.
22 Sistema El sistema no muestra ninguna imagen porque dentro del punto seleccionado no se intersecta ninguna imagen.
23 Sistema El sistema no muestra ninguna imagen ya que en las coordenadas seleccionadas no existen registros de imágenes.
PUNTO(S) DE EXTENSIÓN
DESENCADENADOR(ES)
1. Cada vez que el usuario quiera hacer uso de las funcionalidades que provee el
24
NOMBRE Consultar información IDENTIFICADOR CU-IDEAM SAAI-5
sistema de acuerdo a su rol. SUPUESTO(S)
1. El Usuario tiene acceso a internet 2. El Sistema está activo
3. El Usuario se encuentra registrado en la base de datos del Sistema PRECONDICIÓN(ES)
1. El usuario ingresa a la dirección electrónica del sistema desde un navegador web 2. El Usuario debe estar autentificado en el sistema
3. El Usuario debe seleccionar una opción del menú de consultas del sistema POSTCONDICIÓN(ES)
1. En caso de haberse realizado el procedimiento de manera exitosa, el sistema habilita las funcionalidades disponibles de acuerdo a los permisos concedidos al rol del usuario.
REGLA(S) DE NEGOCIO RELACIONADA(S)
AUTOR
Nombre Cargo
FECHA
Iteración Fachada Creación Modificación
Iteración Detallar Creación Modificación
Iteración Focalizar Creación Modificación
CU-IDEAM SAAI-07. DESCARGA DE INFORMACIÓN
NOMBRE Descarga de información IDENTIFICADOR CU-IDEAM SAAI-06
ITERACIÓN Fachada PRIORIDAD Alta TIPO Necesario
RESUMEN
El Usuario interno del IDEAM podrá hacer la respectiva descarga de la información que deseen dentro de la plataforma.
ACTOR(ES)
Primario(s) Usuarios Internos Soporte Administrador Global Administrador Temporal
INFORMACIÓN NECESARIA
Información Usuario y contraseña Responsable(s) Administrador Global
Flujo Ítem Características Evento
Entrada
Usuario Texto (20), Obligatorio, Cuadro de texto
El usuario ingresa su código de usuario
Contraseña Texto (10), Obligatorio, Cuadro de texto
El usuario ingresa su contraseña
FLUJO PRINCIPAL
Flujo Paso Acción Escenario
1 1 Actor
El usuario selecciona el tipo de búsqueda y realiza la consulta que más se le facilite.
2 Sistema El sistema realiza la búsqueda con los parámetros seleccionados.
3 Actor El usuario escoge la imagen que desea descargar y da click en el botón descarga.
25
NOMBRE Descarga de información IDENTIFICADOR CU-IDEAM SAAI-06
4 Sistema El sistema abre una nueva ventana con la que se podrá seleccionar el lugar dentro de los computadores a descargar la imagen.
FLUJO ALTERNATIVO
Flujo Paso Acción Escenario
1
1
2
2 1
2
3
FLUJO DE EXCEPCIÓN
Flujo Paso Acción Escenario
1 2 Sistema El sistema no encuentra imágenes
3 Actor El usuario escoge otros parámetros de búsqueda.
2
7
8
PUNTO(S) DE EXTENSIÓN
DESENCADENADOR(ES)
1.
SUPUESTO(S)
1. El Usuario tiene acceso a internet 2. El Sistema está activo 3. El Usuario es el Administrador Central registrado en la base de datos del Sistema
PRECONDICIÓN(ES)
1. El Usuario debe estar autentificado en el sistema 2. El Usuario debe seleccionar una opción del menú de consultas del sistema
POSTCONDICIÓN(ES)
1. Los Usuarios Internos quedan registrados en el sistema
REGLA(S) DE NEGOCIO RELACIONADA(S)
AUTOR
Nombre Cargo
FECHA
Iteración Fachada Creación Modificación
Iteración Detallar Creación Modificación
Iteración Focalizar Creación Modificación
CU-IDEAM SAAI-08. GENERACIÓN DE VISTA PRELIMINAR
NOMBRE Generación de vista preliminar IDENTIFICADOR CU-IDEAM SAAI-07
ITERACIÓN Fachada PRIORIDAD Alta TIPO Necesario
26
NOMBRE Generación de vista preliminar IDENTIFICADOR CU-IDEAM SAAI-07
RESUMEN
El Usuario podrá ver una pre-visualización de su imagen en miniatura al lado de las imágenes consultadas.
ACTOR(ES)
Primario(s) Usuarios Internos Soporte Administrador Global Administrador Temporal
INFORMACIÓN NECESARIA
Información Usuario y contraseña Responsable(s) Administrador Global
Flujo Ítem Características Evento
Entrada
Usuario Texto (20), Obligatorio, Cuadro de texto
El usuario ingresa su código de usuario
Contraseña Texto (10), Obligatorio, Cuadro de texto
El usuario ingresa su contraseña
FLUJO PRINCIPAL
Flujo Paso Acción Escenario
1 1 Actor El usuario realiza la búsqueda por la consulta que mejor se le ajuste
2 Sistema El sistema Muestra las imágenes que cumplen con estas características.
3 Actor El usuario puede ver una previsualización al lado de los botones de consulta, como mecanismo de ayuad.
4 Sistema El sistema realiza las peticiones a la base de datos para mostrar el preview
FLUJO ALTERNATIVO
Flujo Paso Acción Escenario
1 3
4
5
2 4
5
6
FLUJO DE EXCEPCIÓN
Flujo Paso Acción Escenario
1 2 Sistema El sistema no encuentra imágenes
3 Actor El usuario escoge otros parámetros de búsqueda.
2
PUNTO(S) DE EXTENSIÓN
DESENCADENADOR(ES)
1. El Usuario tiene acceso a internet 2. El Sistema está activo
3. El Usuario es el Administrador Central registrado en la base de datos del Sistema PRECONDICIÓN(ES)
3. El Usuario debe estar autentificado en el sistema 4. El Usuario debe seleccionar una opción del menú de consultas del sistema
POSTCONDICIÓN(ES)
27
NOMBRE Generación de vista preliminar IDENTIFICADOR CU-IDEAM SAAI-07
2. Los Usuarios Internos quedan registrados en el sistema
REGLA(S) DE NEGOCIO RELACIONADA(S)
AUTOR
Nombre Cargo
FECHA
Iteración Fachada Creación Modificación
Iteración Detallar Creación Modificación
Iteración Focalizar Creación Modificación
CU-IDEAM SAAI-09. VISUALIZACIÓN PRELIMINAR DE LA IMAGEN EN UN MAPA
NOMBRE Generación de vista preliminar IDENTIFICADOR CU-IDEAM SAAI-07
ITERACIÓN Fachada PRIORIDAD Alta TIPO Necesario
RESUMEN
El Usuario podrá ver una pre visualización de su imagen dentro del visor geográfico, esto para confirmar si la imagen es la que requiere o no.
ACTOR(ES)
Primario(s) Usuarios Internos Soporte Administrador Global Administrador Temporal
INFORMACIÓN NECESARIA
Información Usuario y contraseña Responsable(s) Administrador Global
Flujo Ítem Características Evento
Entrada
Usuario Texto (20), Obligatorio, Cuadro de texto
El usuario ingresa su código de usuario
Contraseña Texto (10), Obligatorio, Cuadro de texto
El usuario ingresa su contraseña
FLUJO PRINCIPAL
Flujo Paso Acción Escenario
1 1 Actor El usuario realiza la búsqueda por la consulta que mejor se le ajuste
2 Sistema El sistema Muestra las imágenes que cumplen con estas características.
3 Actor El usuario selecciona la imagen que quiere previsualizar y da click en el botón “Ver”
4 Sistema El sistema muestra en el visor la imagen seleccionada.
FLUJO ALTERNATIVO
Flujo Paso Acción Escenario
1 6
7
28
NOMBRE Generación de vista preliminar IDENTIFICADOR CU-IDEAM SAAI-07
8
2 7
8
9
FLUJO DE EXCEPCIÓN
Flujo Paso Acción Escenario
1 2 Sistema El sistema no encuentra imágenes
3 Actor El usuario escoge otros parámetros de búsqueda.
2
PUNTO(S) DE EXTENSIÓN
DESENCADENADOR(ES)
4. El Usuario tiene acceso a internet 5. El Sistema está activo
6. El Usuario es el Administrador Central registrado en la base de datos del Sistema PRECONDICIÓN(ES)
5. El Usuario debe estar autentificado en el sistema 6. El Usuario debe seleccionar una opción del menú de consultas del sistema
POSTCONDICIÓN(ES)
3. Los Usuarios Internos quedan registrados en el sistema
REGLA(S) DE NEGOCIO RELACIONADA(S)
AUTOR
Nombre Cargo
FECHA
Iteración Fachada Creación Modificación
Iteración Detallar Creación Modificación
Iteración Focalizar Creación Modificación
CU-IDEAM SAAI-10. CONSULTA DEL METADATO
NOMBRE Generación de vista preliminar IDENTIFICADOR CU-IDEAM SAAI-08
ITERACIÓN Fachada PRIORIDAD Alta TIPO Necesario
RESUMEN
El Usuario podrá ver el metadato de la imagen a través de una página emergente que proporciona el prototipo.
ACTOR(ES)
Primario(s) Usuarios Internos Soporte Administrador Global Administrador Temporal
INFORMACIÓN NECESARIA
Información Usuario y contraseña Responsable(s) Administrador Global
Flujo Ítem Características Evento
Entrada Usuario Texto (20), Obligatorio, El usuario ingresa su código
29
NOMBRE Generación de vista preliminar IDENTIFICADOR CU-IDEAM SAAI-08
Cuadro de texto de usuario
Contraseña Texto (10), Obligatorio, Cuadro de texto
El usuario ingresa su contraseña
FLUJO PRINCIPAL
Flujo Paso Acción Escenario
1 1 Actor El usuario realiza la búsqueda por la consulta que mejor se le ajuste
2 Sistema El sistema Muestra las imágenes que cumplen con estas características.
3 Actor El usuario selecciona la imagen que desea consultar y da click en el botón metadato
4 Sistema El sistema muestra la opción de metadato de las imágenes.
5 Actor El usuario es redirigido a otra pestaña donde se muestra el metadato de la imagen.
6 Sistema El sistema abre una nueva pestaña en la página GeoNetwork, donde se encuentran los metadatos de las imágenes del IDEAM.
FLUJO ALTERNATIVO
Flujo Paso Acción Escenario
1 9
10
11
2 10
11
12
FLUJO DE EXCEPCIÓN
Flujo Paso Acción Escenario
1 2 Sistema El sistema no encuentra imágenes
3 Actor El usuario escoge otros parámetros de búsqueda.
5 Sistema El sistema muestra una url dañada o rota.
6 Actor El usuario cierra la pestaña y escoge otra imagen.
2
PUNTO(S) DE EXTENSIÓN
DESENCADENADOR(ES)
7. El Usuario tiene acceso a internet 8. El Sistema está activo
9. El Usuario es el Administrador Central registrado en la base de datos del Sistema PRECONDICIÓN(ES)
7. El Usuario debe estar autentificado en el sistema 8. El Usuario debe seleccionar una opción del menú de consultas del sistema
POSTCONDICIÓN(ES)
4. Los Usuarios Internos quedan registrados en el sistema
REGLA(S) DE NEGOCIO RELACIONADA(S)
AUTOR
Nombre Cargo
FECHA
Iteración Fachada Creación Modificación
30
NOMBRE Generación de vista preliminar IDENTIFICADOR CU-IDEAM SAAI-08
Iteración Detallar Creación Modificación
Iteración Focalizar Creación Modificación
ESPECIFICACIONES SUPLEMENTARIAS (NO FUNCIONALES)
Para el caso de las especificaciones suplementarias se determina en cada una de ellas
un identificador o código único, el nombre de la especificación suplementaria o
requerimiento no funcional y una descripción detallada de la misma.
Además, en este capítulo se clasifican las especificaciones suplementarias en aspectos
como seguridad, visualización, desempeño, persistencia, comunicación y escalabilidad,
sin plantear ningún tipo de soluciones o algún diseño para ello. Es importante tener en
cuenta que los requerimientos no funcionales son necesidades que condicionan el
comportamiento del sistema, por lo que un cambio significativo en alguno de ellos
impacta directamente la estructura del sistema, es decir, la arquitectura.
ÍTEM DESCRIPCIÓN
1. ESCALABILIDAD
RNF-IDEAM SAAI-01
Crecimiento de información
Estimación del crecimiento de la información, y capacidades límites de almacenamiento.
RNF-IDEAM SAAI-02
Crecimiento de Usuarios Permitir que el sistema pueda recibir múltiples peticiones de ingreso, consulta y descarga sin tener fallas.
RNF-IDEAM SAAI-03
Crecimiento de almacenamiento Permitir al sistema tener una mayor capacidad de almacenamiento con el fin de suplir a las necesidades del crecimiento de la información.
2. RENDIMIENTO
RNF-IDEAM SAAI-04
Disponibilidad del sistema La especificación de niveles de disponibilidad requeridos para el SAAI, son de un 100 % de disponibilidad dentro de las horas laborales estipuladas por el IDEAM y en horas no laborales en un 80% dando paso a ese 20% a la realización de mantenimientos del sistema.
RNF-IDEAM SAAI-05
Concurrencia del sistema El sistema deberá soportar una concurrencia del 80% de usuarios (sobre una base de 100% usuarios del SAAI).
31
ÍTEM DESCRIPCIÓN
Donde los tiempos de respuesta se mantienen. Con un valor mayor de concurrencia el sistema sigue prestando servicio pero los tiempos de respuesta empiezan a degradarse.
3 SEGURIDAD
RNF-IDEAM SAAI-06
Control de vigencia de sesiones de usuario El sistema debe manejar un esquema de sesiones que permita al usuario desenvolverse normalmente dentro del mismo. Estas sesiones deben contar con un tiempo de time-out parametrizable después de un período determinado. Así mismo se debe poder parametrizar el tiempo de inactividad.
RNF-IDEAM SAAI-07
Control de inicio de sesiones de usuario El sistema manejara un esquema de seguridad que permita al sistema identificar plenamente al usuario que está ingresando.
4. VISUALIZACIÓN
RNF-IDEAM SAAI-08
Estándar de diseño gráfico El diseño de la interfaz gráfica debe corresponder a los lineamientos en el estándar gráfico definido por el IDEAM.
RNF-IDEAM SAAI-09
Interfaz de usuario Web La interfaz de usuario debe estar basada en Web, utilizando los componentes compatibles con la arquitectura tecnológica definida. Las interfaces de usuario deben contar con una tabla de resultados con paginación para que no se cargue gran cantidad de información en una pantalla. El sistema debe mostrar 20 filas de datos por paginación.
RNF-IDEAM SAAI-10
Resolución de pantalla La resolución mínima definida para el sistema es 1024 x 768
RNF-IDEAM SAAI-11
Facilidad de aprendizaje El sistema deberá ser intuitivo y presentar un estándar de navegación para facilitar el aprendizaje. Facilidad de Entendimiento.
5. SOPORTABILIDAD
RNF-IDEAM SAAI-12
Documentación El sistema que se implante debe contar con toda la documentación que explique y aclare su funcionamiento. Se busca en lo posible elaborar documentación con diagramas que ilustren fácilmente cada uno de los componentes del sistema y la interacción de los mismos, de modo que cuando se requiera extender la operación del sistema, se pueda implementar fácilmente con un tiempo y costo razonables.
RNF-IDEAM SAAI-13
Ayuda en línea El sistema debe contar con documentación en línea para el usuario, que le sirva de ayuda para el normal desarrollo de sus actividades dentro del sistema.
6. OTROS REQUISITOS
RNF-IDEAM SAAI-14
Imagen previa Se extractara de la imagen real una imagen preliminar en formato .png
32
ÍTEM DESCRIPCIÓN
para la visualización del mismo dentro del mapa.
RNF-IDEAM SAAI-15
Metadato de la imagen Archivo de tipo .txt que permitirá descargar el metadato de la imagen.
RNF-IDEAM SAAI-15
Información General del Administrador y Usuario (Única Vez) El sistema requerirá del usuario información personal (Nombre y Apellido) de contacto y localización dentro de la entidad (Numero de extensión y teléfono además de la subdirección de pertenencia) con el fin de manejar un registro de los usuarios que están haciendo uso de la información y posterior identificación y localización.
DEFINICIÓN DE TÉRMINOS
Para facilitar el entendimiento de la especificación funcional, a continuación se describen
los términos utilizados a lo largo del contenido del documento:
ACTOR: Es un usuario del sistema; y al referirnos a "usuario" puede significar una
persona, una máquina, o incluso otro sistema. Cualquier cosa que interactúe con el
sistema desde el exterior de los límites del sistema se considera un actor. Los actores
típicamente se asocian con los Casos de Uso. Los actores pueden usar el sistema a
través de una interfaz gráfica de usuario, de un proceso por lote o cualquier otro medio.
Una persona puede realizar el rol de uno o más actores, aunque solo asumirán un rol
durante una interacción con un caso de uso. Un rol de un actor no sólo puede ser una
persona, también puede ser una máquina, otros sistemas u otros subsistemas en el
modelo.
ACTOR PRIMARIO: Interaccionan con el sistema para explotar su funcionalidad; trabajan
directa y frecuentemente con el software.
ACTOR SECUNDARIO: Soporte del sistema para que los primarios puedan trabajar.
EXTEND: Una conexión extend, se usa para indicar que un elemento extiende el
comportamiento de otro. Las extensiones se usan en los modelos de casos de uso para
indicar que un caso de uso (opcionalmente) extiende el comportamiento de otro. Un caso
de uso extendido frecuentemente expresa flujos alternativos.
33
FLUJO ALTERNATIVO: Describe paso a paso las actividades que debe ejecutar el
sistema cuando el actor selecciona una alternativa en la funcionalidad especificada.
FLUJO BÁSICO: Describe paso a paso las actividades que deben ejecutar el sistema y
el actor para cumplir con el propósito de la funcionalidad especificada.
INCLUDE: Es una conexión de inclusión, indica que el elemento origen incluye la
funcionalidad del elemento destino. Las conexiones de inclusión son usadas en el modelo
de casos de uso para reflejar que un caso de uso incluye el comportamiento de otro.
INFORMACIÓN: Conjunto de datos procesados que sirven de insumo para el control y la
toma de decisiones así mismo INFORMACIÓN se puede definir como datos que han sido
convertidos a un contexto significativo y útil para usuarios finales específicos.
LENGUAJE UNIFICADO DE MODELADO (UML): Es el lenguaje unificado de
modelamiento. Lenguaje estándar diseñado para ser flexible, extensible y amplio, pero lo
suficientemente genérico para servir como fundamento para todas las necesidades de
modelado de sistemas.
PUNTOS DE EXTENSIÓN: Referencias al interior del caso de uso, en las que se podrán
insertar secuencias de acciones de otros casos de uso.
REGLAS DE NEGOCIO: Es un conjunto de actividades o acciones relacionadas
lógicamente llevadas a cabo para lograr un resultado de negocio definido.
REQUERIMIENTO FUNCIONAL: Define el comportamiento interno del software, es decir,
cálculos, detalles técnicos, manipulación de datos y otras funcionalidades específicas que
muestran cómo los casos de uso serán llevados a la práctica. Un requerimiento funcional
típico contiene un nombre, un número de serie único y un resumen, por lo tanto, esta
información se utiliza para ayudar al lector a entender por qué el requerimiento es
necesario, y para hacerle seguimiento al mismo durante la fase de desarrollo del
producto. Los requerimientos funcionales describen las características, el
34
comportamiento, las reglas de negocio y en general, funcionalidad que el sistema debe
soportar de acuerdo a los lineamientos del negocio.
REQUERIMIENTO NO FUNCIONAL: Es un requisito que especifica criterios que pueden
usarse para juzgar la operación de un sistema en lugar de sus comportamientos
específicos, ya que estos corresponden a los requisitos funcionales.
RUP (Rational Unified Process): Es un proceso de desarrollo de software que unido al
Lenguaje unificado de modelado (UML), conforman una de las metodologías más
utilizadas en el inicio, elaboración, construcción y transición de los sistemas.
SERVICIO WEB: Un servicio Web (Web service) es una colección de protocolos y
estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones
de software desarrolladas en lenguajes de programación diferente y ejecutada sobre
cualquier plataforma, pueden utilizar los servicios Web para intercambiar datos en redes
de ordenadores como Internet.
SISTEMA DE INFORMACIÓN: Se define como conjunto de componentes
interrelacionados que permiten capturar, almacenar, procesar y distribuir la información
para apoyar la toma de decisiones, el control, la coordinación, el análisis y la visión en
una organización.
UML (Unified Modelling Lenguaje): Ver Lenguaje Unificado.
ANEXO D
ii
DISEÑO E IMPLEMENTACION DE UN BANCO DE IMAGENES PROVENIENTES DE
SENSORES REMOTOS PERTENECIENTES AL INSTITUTO DE HIDROLOGÍA,
METEOROLOGÍA Y ESTUDIOS AMBIENTALES (IDEAM) COMO APOYO A
CONSOLIDACIÓN DE LA POLÍTICA NACIONAL DE INFORMACIÓN GEOGRÁFICA
MANUAL DE USUARIO
ROBERT ANDRÉS PULIDO ARIAS
CAMILO ANDRÉS PORRAS MARTIN
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA
INGENIERÍA CATASTRAL Y GEODESIA BOGOTÁ D.C.
2017
CONTENIDO
iii
DESCRIPCION DEL MANUAL DE USUARIO .................................................................. 1
MODELO (BASES DE DATOS) ..................................................................................... 1
CREACIÓN DE LA BASE DE DATOS ....................................................................... 1
BASE DE DATOS IDEAM SAAI ................................................................................ 3
EDICIÓN DE LA BASE DE DATOS ........................................................................... 4
INSERCIÓN DE DATOS ............................................................................................ 5
ELIMINACIÓN DE DATOS ....................................................................................... 11
DIRECTORIO DE CARPETAS .................................................................................... 12
ALMACENAMIENTO DE IMÁGENES DIRECTORIO DE CARPETAS ........................ 14
SERVICIOS ARCGIS SERVER ................................................................................... 16
iv
TABLA DE ILUSTRACIONES
Ilustración 1Aplicativo Run SQL Command Line ................................................................ 1
Ilustración 2Oracle SQL Developer .................................................................................... 2
Ilustración 3Base de Datos IDEAM SAAI ........................................................................... 3
Ilustración 4Atributos Tablas .............................................................................................. 3
Ilustración 5Visualiazcion Tabla Imagen ............................................................................ 4
Ilustración 6 Significado Columnas .................................................................................... 4
Ilustración 7Edicion de tabla .............................................................................................. 5
Ilustración 8 Insercion de Datos Alfanuméricos .................................................................. 6
Ilustración 9Tipo de Dato Espacial SDO_Geometry ........................................................... 6
Ilustración 10 Inserción de datos por lenguaje SQL ........................................................... 7
Ilustración 11Conexion en ArcGis ...................................................................................... 8
Ilustración 12Ingresar Datos de Conexión ......................................................................... 8
Ilustración 13 Información de Conexión ............................................................................. 9
Ilustración 14 Conexión ..................................................................................................... 9
Ilustración 15 Tablas obtenidas tras la conexión ................................................................ 9
Ilustración 16 Load Data .................................................................................................. 10
Ilustración 17Eliminacion de Datos .................................................................................. 11
Ilustración 18 Eliminar ...................................................................................................... 12
Ilustración 19 Nivel 1........................................................................................................ 13
Ilustración 20 Nivel 2........................................................................................................ 13
Ilustración 21 Nivel 3........................................................................................................ 14
Ilustración 22 Nivel 4........................................................................................................ 14
Ilustración 23 Visualización ArcGis .................................................................................. 15
Ilustración 24 Crear directorio de Carpetas ...................................................................... 15
Ilustración 25 Guardar Imagen ......................................................................................... 16
1
DESCRIPCION DEL MANUAL DE USUARIO
Este manual de usuario comprende todas y cada una de las tareas necesarias para el
correcto funcionamiento de la aplicación IDEAM SAAI junto con las metodologías correcta
para su mantenimiento y actualización.
La aplicación web IDEAM SAAI está construida bajo una arquitectura de software,
Modelo, Vista, Controlador que permite una separación del Usuario principal de la fuente
de información, dando como resultado una aplicación más segura para la información.
Modelo: El modelo es la representación de la información con la cual la aplicación
funciona, en pocas palabras se puede decir que es la Base de Datos.
Controlador: Responde a las peticiones del usuario, es decir que es la lógica que permite
realizar las peticiones a la base de datos y responder con lo solicitado por la vista
(Usuario).
Vista: Responde a la interfaz de usuario que visualiza y con la cual interactúa el usuario.
Teniendo en cuenta este modelo de arquitectura, se explicará paso a paso cada una de
las metodologías y estrategias de desarrollo de la aplicación, junto con la actualización en
ingreso de nueva información.
MODELO (BASES DE DATOS)
La construcción y elaboración de la bases de datos se realizó bajo los parámetros de la
oficina de informática, siendo requisito el diseño y construcción de la base de datos sobre
el motor de bases de Datos Oracle 11g y utilizando la extensión Oracle Spatial para la
utilización de las Funciones de consulta espacial sobre la base de datos.
Anexo a este documento encontraran los modelos Conceptual, Lógico y Físico junto con
el script SQL en el cual se encuentran representadas las tablas en este lenguaje.
CREACIÓN DE LA BASE DE DATOS
La creación de la base de datos, se realizó por medio de Oracle SQL Developer la cual es
una herramienta que permite la creación, actualización y eliminación de conexiones
bases de datos, sin embargo la creación de un Usuario con permisos de Administrador se
debió crear mediante Run Oracle Command Line, la cual es una aplicación de escritorio
que trae incluida la instalación de Oracle 11g.
A continuación se mostrara la interface gráfica (Ilustración 1 y 2) de las 2 aplicaciones y
se anexara una guía para la creación de una base de datos de ser necesaria esta ayuda.
Ilustración 58Aplicativo Run SQL Command Line
2
Ilustración 59Oracle SQL Developer
En el siguiente documento se podrá observa la creación de una base de datos mediante
consola (1) y la generación de conexiones a la base de datos mediante Oracle Sql
Developer.(2).
1) https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_8003.htm
2) http://www.oracle.com/technetwork/developer-tools/sql-developer/getting-started-
155046.html
3
BASE DE DATOS IDEAM SAAI
Ilustración 60Base de Datos IDEAM SAAI
Teniendo en cuenta la ilustración 3, se puede observar la estructura de la base de datos
de IDEAM SAAI en donde se pueden observar las tablas creadas a partir de los modelos
de la base de Datos que se encuentran anexos a este documento.
Ilustración 61Atributos Tablas
4
En la ilustración número 4 se observan los atributos de cada una de las tablas, lo que
ayuda a entender que la construcción de la base datos sigue los modelos realizados.
EDICIÓN DE LA BASE DE DATOS
Para la edición de la base de datos sea para la inserción de nuevos atributos para
modificación futuras, o introducción de nuevos datos dentro de las base de datos se
deberá hacer de la siguiente manera.
Ilustración 62Visualiazcion Tabla Imagen
Para la visualización de los atributos de la tabla solo se debe seleccionar la tabla en la
ventana de conexiones lo que nos mostrara la vista de las columnas junto con las
características.
Ilustración 63 Significado Columnas
En la tabla de podremos cambiar directamente las columnas o por el contrario podremos
hacerlo como muestra la ilustración 7
5
Ilustración 64Edicion de tabla
En la tabla de edición se podrá modificar todas las propiedades de la tabla y sus atributos.
INSERCIÓN DE DATOS
Datos alfanuméricos:
Para realizar la inserción de datos alfanuméricos, es decir, código de nuevas imágenes,
nuevos usuarios, nuevos niveles de procesamiento y todos aquellos atributos que tienen
como tipo de datos, Varchar , String o Date, es necesario realizarlo mediante Oracle SQL
Developer como lo muestra la siguiente imagen.
6
Ilustración 65 Insercion de Datos Alfanuméricos
Datos Espaciales:
A comparación de otras bases de datos esta maneja un tipo de dato espacial nativo de
Oracle (Oracle Spatial) el cual es un tipo e dato que almacena un punto, polígono o línea
dependiendo de lo se busque representar, en este caso en la tabla Imagen encontramos
un tipo de dato que alberga el Extent de la imagen como muestra la ilustración 9.
Ilustración 66Tipo de Dato Espacial SDO_Geometry
En la base de datos del prototipo se manejan 3 Tipos de dato Espacial en las Siguientes
tablas:
Tabla Imagen: En el atributo Extent_ Imagen se maneja un tipo de dato espacial
debido a que se almacena el extent de la imagen para posteriores consultas
espaciales dentro de la interface del aplicativo.
7
Tabla Grilla: En el atributo SHAPE se maneja un tipo de dato espacial pues se
almacena el extent de todas las imágenes diferenciadas por Misión
Tabla Departamento: En el atributo SHAPE se almacena la geometría de los
departamentos, sin embargo esta tabla no es necesario actualizar.
Tabla Municipios: En el atributo SHAPE se almacena la geometría de los
municipios, sin embargo esta tabla no es necesario actualizar.
Actualización de Datos Espaciales:
Para la actualización de los datos de tipo espacial, maneja 2 tipos de forma:
Inserción mediante SQL
Ilustración 67 Inserción de datos por lenguaje SQL
Dejo continuación un link para entender mejor el tipo de dato nativo SDO_Geometry
https://docs.oracle.com/cd/B28359_01/appdev.111/b28400/sdo_objrelschema.htm
Inserción mediante ArcGIS
Esta es otra técnica de información, sin embargo es necesario hacer una conexión a la
base de datos desde ArcGIS, como lo muestra la siguiente imagen
8
Ilustración 68Conexion en ArcGIS
Ilustración 69Ingresar Datos de Conexión
9
Se deben ingresar los datos de conexión a la base de datos, los cuales se pueden extraer
de Oracle SQL Developer como lo muestra la siguiente imagen.
Ilustración 70 Información de Conexión
Después de ingresar los datos Obtendremos la conexión a la cual daremos doble click y
desplegara las tablas contenidas dentro de la base de datos.
Ilustración 71 Conexión
Ilustración 72 Tablas obtenidas tras la conexión
10
Al tener nuestra conexión, podremos observar que ArcGIS identifica las capas que
manejan un tipo de dato espacial, por lo tanto solo deberemos hacer un load data de la
información nueva que queremos cargar.
Ilustración 73 Load Data
Al realizar el Load Data sobre las respectiva tablas que manejas un atributo espacial,
podremos cargar las capas que deseamos actualizar en la tabla, hay que resaltar que al
realizar el Load data de la información que se desea cargar, esta deberá manejar las
mismas características atributivas para así no tener problemas al cargar la información,
dichas características podrán ser encontradas dentro de los modelos que están anexos a
este documento.
Después de hacer la inserción o actualización de datos mediante ArcGIS, se podrán
observar los cambios si actualizamos nuestra base de datos. Sin embargo si existen
dudas dejo 2 links en donde se podrá encontrar las metodologías implementas con
ArcGIS.
Conexión a la Base de datos: http://desktop.arcgis.com/es/arcmap/10.3/manage-
data/gdbs-in-oracle/connect-oracle.htm
Cargar Información desde ArcGIS:
https://desktop.arcgis.com/es/arcmap/10.3/manage-data/databases/databases-
and-arcgis.htm
11
ELIMINACIÓN DE DATOS
La eliminación de datos se hará directamente en Oracle SQL Developer como lo muestran
las siguientes ilustraciones.
Ilustración 74Eliminacion de Datos
12
Ilustración 75 Eliminar
El procedimiento de eliminación es bastante sencillo como se puede observar en las
ilustraciones.
DIRECTORIO DE CARPETAS
A diferencia de otras bases de datos, las imágenes no serán almacenadas directamente
dentro de esta, en Oracle debido a problemas de Compresión y daño en la información,
las metodologías de almacenamiento dentro de base de datos relacionales para imágenes
raster, pueden generar deformaciones o perdida de información al momento de ser
ingresadas, además de problemáticas con los tipos de formato de las mismas.
Se decide implementar una estrategia de almacenamiento por carpetas, las cuales se
encontraran empaquetadas en formato .Rar o .zip según lo disponga la entidad a la hora
de hacer el cargue masivo de la información. Lo cual impedirá deformaciones o pérdida
de información, como así mismo poder conservar todas las propiedades de la imagen.
13
ESTRUCTURA ACTUAL DEL DIRECTORIO DE CARPETAS
Ilustración 76 Nivel 1
La carpeta raíz está dividida en 5 niveles, según la ilustración 19 el primer nivel inicia con
la subdivisión de las imágenes por tipo de sensor, siendo estos tipos Activo y Pasivo.
Ilustración 77 Nivel 2
Segundo nivel según la ilustración 20, está dividido por las misiones en las cuales fueron
tomadas las imágenes. Actualmente en el aplicativo se encuentran, Landsat5, Landsat7,
Landsat8, RapidEye y CEOS.
14
Ilustración 78 Nivel 3
En este nivel se clasifican las imágenes por el nivel de procesamiento que estas manejan,
siendo Cruda, Corrección Geométrica, Corrección Radiométrica y Corrección por
Desplazamiento.
Ilustración 79 Nivel 4
Este nivel tan solo es una clasificación por Mes y Año, dando como resultado que el nivel
5 sea finalmente la imagen.
ALMACENAMIENTO DE IMÁGENES DIRECTORIO DE CARPETAS
Una vez se tengan las imágenes ingresadas dentro de la base de datos Oracle, es
necesario ingresarlas dentro del directorio de carpetas mediante el siguiente proceso.
15
VISUALIZACIÓN EN ARCGIS:
Dependiendo de cómo se quiera visualizar la imagen preview, y de la subida de la imagen
al servidor de geográfico ArcGIS Server, se deberá hacer composición de la imagen en
Verdadero Color.
Ilustración 80 Visualización ArcGIS
CREAR LAS CARPETAS DEPENDIENDO DE LAS CARACTERÍSTICAS DE LA
IMAGEN:
Se deben crear las carpetas correspondientes para la imagen, teniendo en cuenta la
estructura del directorio que se explicó anteriormente.
Ilustración 81 Crear directorio de Carpetas
16
GUARDAR IMAGEN DENTRO DE LA CARPETA FINAL EN FORMATO .RAR O .ZIP:
Ilustración 82 Guardar Imagen
Se debe guardar la imagen empaquetada en .Rar o .Zip junto con la imagen preview
(formato .jpg) que se visualizara en el aplicativo. Esta imagen y preview se debe guardar
con el nombre con el que fueron registradas dentro de la Base de Datos.
Se recomienda que la imagen .jpg almacenada, tenga un peso menor a 0.5 megas para
poder ser visualizada con rapidez dentro del aplicativo.
SERVICIOS ARCGIS SERVER
La visualización de las imágenes directa mente en el visor del mapa del aplicativo se
realizó mediante la publicación de las imágenes en ArcGIS como servicios ImageService,
este servicio se encuentra cachado, por lo tanto a continuación se explicara el
procedimiento para la publicación de las imágenes.
A continuación se deja un enlace para la explicación de lo que significa un ImageService:
http://resources.arcgis.com/en/help/rest/apiref/imageserver.html
17
PUBLICACIÓN DE UN IMAGE SERVICE:
Para realizar la publicación del servicio en ArcGISserver, se debe carga la imagen
directamente en ArcGIS y guardarla directamente en una Geodatabase, como muestra la
siguiente ilustración.
Ilustración 83 Guardar Imagen en una Geodatabase
Después de realizar el guardado de la imagen dentro de la GDB se deberá dar click
derecho y escoger la opción Image Service como muestra la siguiente ilustración.
18
Ilustración 84 Image Service
Ilustración 85 Publicar
Se debe escoger la primera opción si se quiere publicar la imagen por primera vez o la
tercera si se desea actualizar la imagen ya publicada.
19
Ilustración 86 Nombre del Servicio
Se debe nombrar la publicación con el ID de la imagen asignado dentro de la base de
datos Oracle.
Ilustración 87 Carpeta de Publicación
Escoger la carpeta Imágenes para la publicación.
20
Ilustración 88 Publicar
No modificar ninguno de los atributos y solamente publicar.
Una vez termine el proceso de publicación, se debe acceder a ArcGIS Server Manager,
para ver las publicaciones.
Ilustración 89 ArcGIS Server Manager
Una vez entramos a la carpeta imágenes, podremos observar las imágenes publicadas
como muestra la siguiente ilustración
21
Ilustración 90 Imágenes Publicadas
Es necesario localizar la imagen publicada y seleccionarla para realizar el procedimiento
de Cachado de la Imagen, con el fin de poder observar con una mayor eficiencia la
imagen en el Aplicativo.
Ilustración 91 Opciones dentro del Servicio
Seleccionar la opción Almacenamiento en Cache y seguir el siguiente procedimiento.
22
Ilustración 92 Almacenamiento en Cache
Ilustración 93 Opciones de Cachado
Ilustración 94 Guardar Cachado
Después de realizar este procedimiento, finalizaremos con el proceso de publicación de la
imagen, la cual ya estará lista para ser utilizado por el aplicativo.