DESARROLLO E IMPLEMENTACIÓN DE UNA BASE DE DATOS …repository.udistrital.edu.co/bitstream/11349/16197/1/Proyecto.pdf · 4. Marco Teórico 4.1. Generalidades 4.1.1. Definición de

DESARROLLO E IMPLEMENTACIÓN DE UNA BASE DE DATOS ESPACIAL Y UN GEOVISOR

WEB PARA LA VISUALIZACIÓN DE CONTENIDOS TEMÁTICOS

Christian David García

20121025006

Martha Lucía Urrea Uribe

20142025019

Director: Carlos German Ramírez Ramos

Modalidad: Pasantía

Ejército Nacional de Colombia - CAIMI

Base de Datos Espacial y Geovisor web 2

Agradecimientos

A Dios

A la familia de cada uno por el apoyo constante

En el transcurso de estos años

Al grupo GNU Linux por la guía y enseñanza


Tabla de Contenido Introducción ............................................................................................................................................ 5

1. Planteamiento del Problema ........................................................................................................ 6

2. Justificación ................................................................................................................................. 7

3. Objetivos ..................................................................................................................................... 8

3.1. Objetivo General ......................................................................................................................... 8

3.2. Objetivos Específicos .................................................................................................................. 8

4. Marco Teórico ............................................................................................................................. 9

4.1. Generalidades .............................................................................................................................. 9

4.1.1. Definición de web Services ................................................................................................. 9

4.1.2. Servidores de mapas ............................................................................................................ 9

4.1.3. Geovisor ............................................................................................................................ 10

4.2. Software .................................................................................................................................... 11

4.2.1. Visual Studio Code ............................................................................................................ 11

4.2.2. QGIS .................................................................................................................................. 11

4.2.3 Open Layers y Leaflet .............................................................................................................. 11

5. Metodología............................................................................................................................... 12

5.1. Fase I ......................................................................................................................................... 12

5.1.1. Requerimientos funcionales .............................................................................................. 12

5.1.2. Requerimientos no funcionales del sistema....................................................................... 12

5.2. Fase II ........................................................................................................................................ 13

5.2.1. Recopilación y depuración ................................................................................................ 13

5.3. Fase III ....................................................................................................................................... 13

5.3.1. Implementación ................................................................................................................. 13

5.4. Fase IV ...................................................................................................................................... 14

5.4.1. Revisión de índices y contenidos ...................................................................................... 14

5.4.2. Verificación y Validación.................................................................................................. 14

6. Resultados ................................................................................................................................. 15

6.1. Fase I ......................................................................................................................................... 15

6.2. Fase II ........................................................................................................................................ 17

6.2.1. Recopilación y depuración ................................................................................................ 17

6.3. Fase III ....................................................................................................................................... 18

6.3.1. Implementación ................................................................................................................. 18

6.3.2. Base de datos Espacial ...................................................................................................... 18

6.3.3. Documentos HTML, JavaScript y CSS ............................................................................. 18

6.4. Fase IV ...................................................................................................................................... 22

6.4.1. Vista Principal ................................................................................................................... 22


6.4.2. Vista Nosotros ................................................................................................................... 23

6.4.3. Vista Manual ..................................................................................................................... 23

6.4.4. Vista Ayuda ....................................................................................................................... 24

6.4.5. Visor Múltiple ................................................................................................................... 24

6.5.5. Selección final de capas .......................................................................................................... 25

7. Alcance y Limitaciones ............................................................................................................. 26

7.1. Alcance ...................................................................................................................................... 26

7.2. Limitaciones .............................................................................................................................. 26

8. Conclusiones ............................................................................................................................. 27

Bibliografía ............................................................................................................................................ 28

Ilustraciones Ilustración 1 Ruta Metodológica, Fuente: Elaboración propia .............................................................. 12

Ilustración 2 Gestión y procesamiento de datos, Fuente: Elaboración propia en Draw.io .................... 13

Ilustración 3 Procedimiento de Resultados, Fuente: Elaboración propia en Draw.io ........................... 15

Ilustración 4 head index.html ................................................................................................................ 19

Ilustración 5 Primera parte del body del index.html ............................................................................. 19

Ilustración 6 Segunda parte del body del index.html ............................................................................ 20

Ilustración 7 Tercera parte del body del index.html .............................................................................. 20

Ilustración 8 Head y primera parte del body de nosotros.html .............................................................. 20

Ilustración 9 Interfaz de usuario VSCode ............................................................................................. 21

Ilustración 10 VSCode archivos CSS .................................................................................................... 21

Ilustración 11 Interacciones Vista Principal .......................................................................................... 22

Ilustración 12 Vista nosotros ................................................................................................................. 23

Ilustración 13 Vista Manual 1 ............................................................................................................... 23

Ilustración 14 Vista Manual 2 ............................................................................................................... 24

Ilustración 15 Vista ayuda ..................................................................................................................... 24

Ilustración 16 Vista visor múltiple ........................................................................................................ 25

Ilustración 17 Vista general de algunas capas ....................................................................................... 25

Tablas Tabla 1 Recuperación y depuración ..................................................................................................... 17


Introducción

Desde el comienzo del siglo XXI con la expansión masiva de las redes digitales y la llegada del world

wide web (www) a los medios empresariales y al público general, la sociedad ha incrementado

vorazmente los servicios digitales al punto de ciber-conexión mundial, todo y todos estamos

conectados al ciberespacio de alguna forma. En la actualidad los servicios web permiten acceder

fácilmente a diferentes tipos de datos de manera concurrente, gestionarlos y acceder desde diferentes

lugares del mundo a ellos, basta con una conexión a internet.

El continuo avance tecnológico ha desarrollado lenguajes y numeradas herramientas que permiten el

análisis de grandes volúmenes de información en muy poco tiempo, además todo esto involucra una

reducción de costos significativa. De esta manera la calidad de la oferta digital se ha convertido en uno

de los principales objetivos estratégicos de las organizaciones modernas en un mercado de

supervivencia.

Los servicios web pueden definirse como una colección de protocolos y estándares que sirven para

intercambiar datos, permitiendo que diferentes aplicaciones remotas puedan intercambiar información

sin tener que almacenarla de manera local. El interés de este proyecto reside en los servicios web

geográficos desarrollados enteramente con software libre, servicios para acceder, visualizar y editar

información geográfica, asegurando así la actualización de la información basado en el Open

Geospatial Consortium (OGC), que es la organización internacional encargada de definir los lenguajes

y protocolos estándar para la generación y utilización de diversos servicios web geográficos.


1. Planteamiento del Problema

El problema surge a raíz de la continua demanda del mismo tipo información en el departamento

geográfico del CAIMI, Comando de Apoyo de Inteligencia Militar, por lo cual se hace

indispensable el diseño, desarrollo e implementación de una base de datos geográfica adecuada

para alimentar un geo-servicio web que permita la visualización y descarga de diferentes

contendido temáticos, lo que induciría a la automatización de procesos y por ende a la reducción

en los tiempos de operación del departamento.


2. Justificación

Las tecnologías de la información y las comunicaciones tienen un papel fundamental, el

intercambio de contenidos vía web presenta la ventaja de llegar a un sector específico en poco

tiempo y con una inversión relativamente baja. El diseño de soluciones tecnológicas orientadas a

la web logra difundir la información más relevante para la organización y permite, al mismo

tiempo, el intercambio de ideas con los grupos poblacionales específicos a los que apunta.

El Desarrollo de geo-servicios digitales junto con un entorno intuitivo, integra-dos en un sitio web,

logra un fácil acceso a la información, además de unidad, continuidad y actualización temática.

Esta solución informática está enfocada a lograr los propósitos de visibilidad institucional en el

CAIMI para difundir la información y la integración de sectores.


3. Objetivos

3.1. Objetivo General

Implementar una herramienta de consulta espacial del territorio nacional dirigida a los funcionarios del CAIMI que permita la visualización de información de diferentes aspectos de orden social y ambiental del territorio.

3.2. Objetivos Específicos

Definir el diseño arquitectónico del visor geográfico que cumpla con los requerimientos establecidos

Recopilar, procesar y cargar los datos para que puedan ser visualizados en la herramienta de consulta espacial.

Implementar y desarrollar el visor geográfico de acuerdo a la especificación de requerimientos y la arquitectura definida.

Realizar pruebas de validación, instalación, y evaluación de calidad del visor geográfico.

Generar la respectiva documentación de la metodología planteada.


4. Marco Teórico

4.1. Generalidades

4.1.1. Definición de web Services

Un servicio Web es una colección de protocolos y estándares que sirven para

intercambiar datos entre aplicaciones distintas de software, desarrolladas en lenguajes

de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar

los servicios Web para intercambiar datos en redes de ordenado-res como Internet.

Los Web Servicies presentan algunas diferencias sobre los sistemas distribuidos

tradicionales, tales como: EJB (Enterprise JavaBeans), COM (Componente Ob-ject

Model) DCOM (Distribuited Component Object Model), SOM (IBM System Object

Model) o DSOM IBM (Distribuited System Object Model). Entre las diferencias más

significativas están las siguientes

Aportan interoperabilidad entre aplicaciones de software, independiente-mente de

sus propiedades o de las plataformas sobre las que se instalen

Los servicios Web fomentan los estándares y protocolos basados en texto, que

hacen más fácil acceder a su contenido.

Permiten que servicios y software de diferentes compañías ubicadas en diferentes

lugares geográficos puedan ser combinados fácilmente para proveer servicios

integrados.

Independencia del lenguaje de programación: El servidor y el cliente no necesitan

estar escritos en el mismo lenguaje.

Existen diferentes tipos de servicios geográficos que cubren diferentes necesidades:

WMS (Web Map Service) para publicar mapas en formato ráster

georreferenciado. Actualmente es el servicio web geográfico más implementado.

WFS (Web Feature Service) para publicar capas de información vectoriales.

WCS (Web Coverage Service) para publicar información geográfica (vectorial,

ortofotos, imágenes de satélite o modelos digitales del terreno) en formato

cobertura o grid. A diferencia del WMS, que publica mapas estáticos (imágenes),

los datos que retorna el WCS permiten el análisis espacial de los pixeles

retornados.

CSW (Catalogue Service Web) para publicar meta-información de los ser-vicios

webs disponibles en un servidor web.

4.1.2. Servidores de mapas

Los servidores de mapas son una herramienta cuyo objetivo principal es el de

contribuir y facilitar la distribución de forma rápida y accesible de datos espaciales a

través de la web, este tipo de aplicaciones permite de una manera visual la interacción

con capas georreferenciadas de una región especifica. Estos tienen como objeto

acceder a información geoespacial existente, normalmente en servidores, en diferentes

formatos para así servir dicha información a clientes de mapas a través de protocolos

estándares. Existen diferentes tipos de servicios de información geoespacial:

Servicios de mapas: Reciben peticiones por parte de clientes, acceden a

información vectorial (gráfica y alfanumérica) y/o ráster, y generan imágenes


de mapas que se sirven a un cliente en forma de imágenes ráster (PNG, JPEG,

GIF. . .), o bien responden a peticiones de acceso a información relacionada

con mapas servidos, como propiedades de un elemento, etc. (Generalitat de

Catalunya, 2016)

Servicios de geometrías: Sirven información geoespacial en formato vectorial,

incluyendo geometrías y atributos alfanuméricos, para que el cliente las

procese y represente o maneje en local. Servicios de coberturas: Sirven

información geoespacial de diferentes tipos a los clientes, con la particularidad

de ofrecer la información original sin necesidad de que sea procesada. Esto es

útil para acceso a datos como modelos digitales del terreno, ficheros de

información de teledetección, etc.

Servicios de catálogo: Ofrecen acceso a metadatos y búsqueda de informa-con

sobre cartografía.

Servicios de procesamiento: Ofrecen el procesamiento de información

geoespacial en el lado del servidor, enviando los resultados finales a los

clientes. (p.a. cálculo de rutas, análisis, etc.). Todos estos servicios suelen

llevar asociados estándares de interoperabilidad especificados generalmente

por el OGC (Open Geospatial Consortium). (Marin, De Los Angeles Mazo, &

Olivo , 2019)

4.1.3. Geovisor

El Geovisor es una herramienta de software que publica mapas por Internet o intranet,

este mapa publicado es la combinación de varias capas de la información temática de

diferentes sectores del territorio y a su vez cuenta con una serie de herramientas las

cuales interactúan con el mapa.

El Geovisor toma la información de la cartografía o capas de la base de datos espacial

PostgreSQL y de varios formatos como ESRI shapefile o geoJson, la información que

no provenga de la cartografía es tomada de una base de datos que la contenga, en la

actualidad el Geovisor puede realizar una petición a un segundo servidor el cual da

como resultado un XML el cual contiene coordenadas y datos adjuntos a cada una de

ellas para ser visualizadas en el mapa.

4.1.4. Leguajes HTML, CSS y JS

El desarrollo del geovisor se basa fundamentalmente en estos 3 lenguajes de

programación que permiten desarrollar contenido web. En nuestro caso tiene un

componente geográfico que se trató a través de librerías en JavaScript de código

abierto como leaflet.

HTML (HyperText Markup Language): hace referencia al lenguaje de

marcado para la elaboración de páginas web. Es un estándar que sirve de

referencia del software que conecta con la elaboración de páginas web en sus

diferentes versiones, define una estructura básica y un para la definición de

contenido de una página web, como texto, imágenes o videos. Es un estándar a

cargo del World Wide Web Consortium (W3C) o Consorcio WWW,

organización dedicada a la estandarización de casi todas las tecnologías ligadas

a la web, sobre todo en lo referente a su escritura e interpretación. Es el

estándar que se ha impuesto en la visualización de páginas web y es el que

todos los navegadores actuales han adoptado. (Gonzales Gutierrez, 2019)

https://es.wikipedia.org/wiki/Lenguaje_de_marcado

https://es.wikipedia.org/wiki/Lenguaje_de_marcado

https://es.wikipedia.org/wiki/P%C3%A1gina_web

https://es.wikipedia.org/wiki/W3C


CSS (Cascading Style Sheets): es un lenguaje de diseño gráfico para definir y

crear la presentación de un documento estructurado escrito en un lenguaje de

marcado.2 Es muy usado para establecer el diseño visual de los documentos

web, e interfaces de usuario escritas en HTML o XHTML; el lenguaje puede

ser aplicado a cualquier documento XML, incluyendo XHTML, SVG, XUL,

RSS, etcétera. Junto con HTML y JavaScript, CSS es una tecnología usada por

muchos sitios web para crear páginas visualmente atractivas, interfaces de

usuario para aplicaciones web y GUIs para muchas aplicaciones móviles.

(Moz://a, 2019)

JavaScript: es un lenguaje de programación que permite realizar actividades

complejas en una página como mostrar actualizaciones de contenido en el

momento, interactuar con mapas, animaciones gráficas o ventanas emergentes.

4.2. Software

4.2.1. Visual Studio Code

Visual Studio Code es un editor de código fuente ligero, para escritorio disponible para

Windows, macOS y Linux. Viene con soporte incorporado para JavaScript, Type

Script y Node.js y tiene un rico ecosistema de extensiones para otros lenguajes (como

C ++, C #, Java, Python, PHP, Go) y tiempos de ejecución (como .NET y Unity).

4.2.2. QGIS

Es un Sistema de Información Geográfica (SIG) de código libre multiplataforma. Era

uno de los primeros ocho proyectos de la Fundación OSGeo y en 2008 oficialmente

graduó de la fase de incubación. Permite manejar formatos ráster y vectoriales a través

de las bibliotecas GDAL y OGR, así como bases de datos. Algunas de sus

características son:

Soporte para la extensión espacial de PostgreSQL, PostGIS.

Manejo de archivos vectoriales Shapefile, y geoJson que son fundamentales

para el desarrollo del visor.

4.2.3 Open Layers y Leaflet

Son bibliotecas de JavaScript de código abierto bajo una derivación de la licencia BSD

para mostrar mapas interactivos en los navegadores web. Ellas ofrecen un API para

acceder a diferentes fuentes de información cartográfica en la red: Web Map Services,

Mapas comerciales (tipo Google Maps, Bing, Yahoo), Web Features Services, distintos

formatos vectoriales, mapas de OpenStreetMap, etc.

Open Layers fue desarrollado por MetaCarta en junio de 2006. Desde el noviembre del

2007 este proyecto forma parte de los proyectos de Open Source Geospatial

Foundation. Actualmente el desarrollo y el soporte están a cargo de la comunidad de

colaboradores.

Por otro lado, leaflet es ampliamente utilizada para crear aplicaciones de mapeo web.

Lanzado por primera vez en 2011, es compatible con la mayoría de las plataformas

móviles y de escritorio, compatible con HTML5 y CSS3. Junto con OpenLayers y la

API de Google Maps, es una de las bibliotecas de mapeo de JavaScript más populares

y es utilizada por los principales sitios web como FourSquare, Pinterest y Flickr.

(Lovelace, 2019)


El folleto permite a los desarrolladores sin experiencia en SIG visualizar mapas web en

mosaico alojados en un servidor público, con superposiciones en mosaico opcionales.

Puede cargar datos de características de archivos GeoJSON, diseñarlos y crear capas

interactivas, como marcadores con ventanas emergentes cuando se hace clic.

5. Metodología Para el desarrollo del presente proyecto se trabajarán diferentes fases basadas en cada uno de los

objetivos a ejecutar.

Ilustración 1 Ruta Metodológica, Fuente: Elaboración propia

5.1. Fase I

Lo primero que se debe plantear es una investigación rigurosa con respecto a todas las

variables tenidas en cuenta en el proceso de especificación, de manera que quede cubierta

cada una de las posibilidades de aquello que se puede o no utilizar para que de esta forma el

proceso sea optimo

5.1.1. Requerimientos funcionales

Los requerimientos funcionales de un sistema, son aquellos que describen cualquier

actividad que este deba realizar, en otras palabras, el comportamiento o función

particular de un sistema o software cuando se cumplen ciertas condiciones.

Por lo general, estos deben incluir funciones desempeñadas por pantallas específicas,

descripciones de los flujos de trabajo a ser desempeñados por el sistema y otros

requerimientos de negocio, cumplimiento, seguridad u otra índole.

(Siqueira Simões & Vazquez, Requerimientos funcionales, 2015)

5.1.2. Requerimientos no funcionales del sistema

Los requerimientos no funcionales son los que especifican criterios para evaluar la

operación de un servicio de tecnología de información, en contraste con los

requerimientos funcionales que especifican los comportamientos específicos. Algunos

ejemplos de requerimientos no funcionales son:

Comprobabilidad: Grado en que un sistema, software o servicio de TI permite

y facilita que sea probado en un determinado contexto.

Disponibilidad: Corresponde al tiempo total en que un sistema puede ser usado

en un periodo determinado. También puede definirse el grado en que un

sistema está en un estado operable definido cada vez que se necesite.

Extensibilidad: Grado en que la implementación del sistema toma en

consideración y facilita su crecimiento en el futuro.

Escalabilidad: Capacidad de un sistema o servicio de TI de manejar una

creciente carga de trabajo, por ejemplo, mayor número de conexiones o

usuarios. No debe confundirse con extensibilidad, que mide la capacidad del

sistema de crecer en funcionalidades.

Mantenibilidad: Mide la facilidad con que puede darse mantenimiento al

producto (en este caso al software o servicio de TI), con la finalidad de:


Desarrollar nuevos requerimientos, Aislar los defectos y sus causas, corregir

estos defectos y atender las demandas del entorno cambiante.

Seguridad: Grado de protección de los datos, software y plataforma de tecno-

logia de posibles pérdidas, actividades no permitidas o uso para propósitos no

establecidos previamente.

Usabilidad: Definido como la facilidad de uso y aprendizaje de un Sistema,

Software o Servicio de Tecnología de Información.

(Siqueira Simões & Vazquez, Requerimientos no funcionales, 2015)

5.2. Fase II

5.2.1. Recopilación y depuración

Con el fin de poder ofrecer información de calidad, debidamente seleccionada y

clasificada, se realizara una recopilación de la información geográfica disponible en las

bases de datos del CAIMI, así como de otras web que puedan servir de soporte. Los

datos serán examinados, depurados y en algunos casos construidos, facilitando el

manejo y la presentación en el geo-visor. En paralelo se realizara la selección del

software y las herramientas que permitirán la configuración e integración del sistema.

La mayoría de los datos se trabajaran en crudo y desde su tabla de atributos en formato

shapefile haciendo uso del software Qgis, para que posteriormente sean exportados a

un formato web legible y fácilmente manipulable como el geojson o js.

5.3. Fase III

5.3.1. Implementación

Se basa en la personalización de los diferentes componentes de software existentes. Se

genera una versión inicial, a partir de esta versión inicial se desarrollarán versiones

intermedias basadas en los casos de uso establecidos y cada una de estas versiones

debe ser probada y validada. Dichas versiones, tienen como objetivo depurar la

funcionalidad del geo-visor al implementar progresivamente los casos de uso al

sistema.

Ilustración 2 Gestión y procesamiento de datos, Fuente: Elaboración propia en Draw.io


5.4. Fase IV

La revisión y verificación de funcionamiento general del sitio es esencial, ya que se

comprueban todos los aspectos que pudieran estar afectando positiva o negativamente su

plataforma, respecto de su respuesta, indexación, tiempos de carga, enlaces y otros. La

revisión de sitio se realiza llevando a cabo pruebas en cada una de sus funcionalidades

durante y después de terminado el desarrollo web.

5.4.1. Revisión de índices y contenidos

Para evitar cualquier problema asociado con nombres y referencias dentro de los

documentos HTML, CSS o JavaScript debe aclararse y revisarse los nombres

definitivos de cada uno de los elementos que componen el geovisor para evitar

problemas de indexación carga o re-direccionamiento, revisar profundamente el sitio

web es recomendable, haciendo que no existan inconsistencias entre el sitio para

equipos de escritorio y el sitio para dispositivos móviles o problemas de carga

similares.

Sin duda, un sitio web responsivo debería ofrecer el mismo contenido, enlaces y

marcado entre dispositivos, así como los atributos mencionados previamente deben ser

idénticos entre los sitios para equipos de escritorio y dispositivos móviles, así como

entre páginas de un mismo conjunto web. En adición, Un sitio web responsivo debe

ofrecer a todos los dispositivos el mismo código HTML, el cual se ajusta vía CSS, por

lo cual, el manejo de versiones de prueba es indispensable para mejorar la depuración

de todos los componentes web. (Dominguez Palacios & Gomez Jaramillo, 2016)

5.4.2. Verificación y Validación

Se debe verificar que las versiones intermedias no presenten inconsistencias en el

desempeño de acuerdo a los requerimientos establecidos. Así mismo se realizarán

pruebas de instalación, evaluación y calidad del visor geográfico, asegurando que se

cumplan todos los requerimientos iniciales.

Dado que los requerimientos son estáticos, lo ideal es definir una arquitectura flexible

que pueda acogerse con facilidad al cambio, dados los diferentes problemas que

pueden aparecer a lo largo del proceso de desarrollo. Una arquitectura flexible

permitirá ahorrar tiempo y trabajo, de manera que pueden seguirse los siguientes pasos

con el fin de verificar y mejorar adecuadamente el diseño:

Elaboración de códigos alternativos.

Comparación de una especificación de un diseño nuevo con una

especificación de un diseño similar probado.

Realización de ensayos, pruebas y demostraciones.

Revisión de los documentos y manuales antes de su emisión.


6. Resultados

Ilustración 3 Procedimiento de Resultados, Fuente: Elaboración propia en Draw.io

6.1. Fase I

Lo que se establece en los siguientes apartados son los criterios que nos llevaron a pensar

concretamente que era lo que se quería lograr, de manera que lo mejor fue pasar de la

generalidad a la especificidad. Siendo el geo-visor la parte central del desarrollo del

proyecto, esta fase nos dio los criterios iniciales para la implementación

6.1.1. Requerimientos funcionales

En esta sección de la fase se define todo lo que se necesita funcionalmente dentro del

geo-visor a partir de las necesidades de los usuarios.

Visualización de las capas obtenidas en geoJson además la posibilidad de

activarlas y desactivarlas.

Posibilidad de elegir diferentes bases mapas según las necesidades del usuario.

Imprimir y exportar el contenido en pantalla del geo-visor.

Ventanas emergentes de las capas mostrando información de la misma.

Apartado de ayuda y manual para facilitar el uso y el entendimiento de las

librerías JavaScript.


Capacidad de realizar diferentes tipos de polígonos y editarlos.

Capacidad de hacer zoom in y zoom out.

Las funciones anteriormente mencionadas se logran a través de botones, checkbox y

ventanas emergentes programadas en JS que enriquecerán el geo-visor

interactivamente logrando para el usuario una experiencia más personalizada que le

permite añadir características al mapa y editar algunas de ellas, logrando una web

medianamente adaptable a las necesidades de los usuarios estándar que buscan

consultar alguna de las características del territorio y añadir algunos elementos que

puedan ayudar a ilustrar mejor lo que necesita el usuario.

6.1.2. Requerimientos no funcionales

Como se mencionó anteriormente esto requerimientos son los que especifican criterios

para evaluar la operación de un servicio de tecnología de información, existen

diferentes niveles. En un primer nivel, los requerimientos no funcionales pueden

clasificarse en requerimientos de producto, organizacionales y externos.

En un segundo nivel, los requerimientos de producto pueden clasificarse en

requerimientos de usabilidad, eficiencia, y seguridad. A su vez, los requerimientos

organizacionales pueden clasificarse en requerimientos de entorno, organizacionales y

de desarrollo, y por último los requerimientos externos pueden clasificarse en

requerimientos regulatorios, éticos y legislativos. (Cohn, 2019)

Como puede apreciarse existen una gran cantidad de requerimientos no funcionales,

pero dada la escala para la que está pensado el geo-visor y tanto la cantidad como el

tipo de usuarios a los cuales va dirigido elegimos los más pertinentes que lograran una

mejor adaptabilidad del sistema a los diferentes retos en el desarrollo del proyecto.

Comprobabilidad: Básicamente se traduce en el funcionamiento dentro de un

contexto propuesto, es decir que todo el sistema funcione bien, checkbox,

capas mapa base y demás elementos que lo componen.

Disponibilidad: Capacidad del visor de estar siempre operable y funcional,

pueden existir limitaciones en los horarios de acceso a la información o

información que solo está disponible por temporadas.

Extensibilidad: Como se piensa incrementar las funcionalidades del visor, es

decir la capacidad de rehacerse depurar y mejorar el entorno y otras

características, es decir un manejo de versiones y alcances de la misma, para

este caso la extensibilidad no es un requerimiento no funcional debido a la

única versión de desarrollo que hará del proyecto.

Escalabilidad: Como se hace referencia a las cargas de trabajo y afluencia del

visor, será posible el acceso por varios usuarios, pero no la tolerancia de

grandes volúmenes de los mismos, dado la especificidad del usuario y la

privacidad de la información.

Mantenibilidad: Gracias a la documentación que se desarrolla en torno de la

alimentación de datos dentro del visor, la mantenibilidad de este mismo se

considera que la dificultad de la mantenibilidad de este es baja aunque puede

tener ciertas dificultades técnicas para las personas que no tienen

conocimientos de este tipo de programación, igualmente el código completo

del geovisor estará en plena disposición de CAIMI lo que permitirá que nuevos

desarrolladores alimenten el geo servicio con nuevas funcionalidades.

Seguridad: Debido a que el Geoservicio se manejará únicamente por el puerto

local, ninguna información se verá vulnerable pues los únicos que podrán

acceder a ella son las personas que tengan acceso a ese computador, de esta


manera depende única y exclusivamente de la seguridad informática que se

maneje dentro del CAIMI.

Usabilidad: El Geoservicio se desarrolló interactivamente para el usuario con

los iconos que permitan el reconocimiento de la acción de este, convirtiendo de

esta manera la interacción intuitiva, sin embargo, se tendrá una vista designada

para la explicación de cada acción .

6.2. Fase II

6.2.1. Recopilación y depuración

En primera instancia se seleccionaron algunas capas de las bases de datos del CAIMI,

lo pertinente a cultivos ilícitos, otras de ellas se construyeron en base a otras

existentes tomadas de DIVA-GIS, se tomó el shape de división departamental

proveniente de la web y a través de QGIS se crearon en las diferentes capas nuevos

atributos, formando una serie de variables de cada municipio de Colombia que incluye

presencia del ELN, presencia de GAO, desastres naturales y niveles de alerta

actualizados a julio de 2019, límites de Colombia, división política departamental y

nivel de riego electoral por violencia política para el año 2018.

Shapefiles Fuente Descripción

Cultivos Ilícitos Bases de datos

CAIMI Puntos en los que se sabe hay o más cultivos

ilícitos

Presencia GAO Elaboración propia

MOE Departamentos en los que hay presencia de

grupos armados organizados

Presencia ELN Elaboración propia

MOE Departamentos en los que hay presencia de

ELN

Nivel de riesgo

electoral por

violencia política

Elaboración propia

MOE Lugares en condición de riesgo electoral por

asesinatos o actos similares.

Alertas por desastres

naturales

Elaboración

Propia IDEAM

Muestra los departamentos con alertas como

derrumbes, incendios, tormentas entro otros

Nivel de riesgo del

desastre natural.

Elaboración

Propia IDEAM

Muestra los departamentos con niveles de

alerta amarilla, roja o naranja.

Limites DIVA-GIS Limites internacionales terrestres de Colombia

Departamentos DIVA-GIS División política departamental de Colombia

Tabla 1 Recuperación y depuración (MOE, 2019)

Una vez construidas y depuradas las tablas de atributos, el software QGIS también

permite exportar una selección por atributos a formato geoJson, indispensable para

lograr visualizar la información en el formato web elegido, de esta forma se

obtuvieron una seria de capas en este formato que alimentan el geo-visor y

representan información social y agrícola del territorio nacional.


Una vez obtenida y depurada toda la información se procede a la implementación, allí

se hará uso de los archivos geoJson que deben ser importados al código fuente para su

posterior visualización como contenido web.

6.3. Fase III

6.3.1. Implementación

En esta fase comienza todo lo pertinente a la programación y como en cualquier página

web tradicional escrita en los leguajes Html, Css y JavaScript necesitaremos un archivo

de texto plano con la extensión correspondiente al lenguaje usado, es decir que la

página se compone de 3 archivos,

cada uno escrito en un lenguaje de programación diferente, pero interrelacionados

entre sí para dar orden, estilo e interactividad a la página respectivamente.

El editor de código usado fue Visual Studio Code debido a su ligereza y soporte para

para varios lenguajes, además posee la ventaja de poder compartir y editar proyectos

vía GitHub, lo que facilita el trabajo a un grupo de programadores.

6.3.2. Base de datos Espacial

La base de datos espacial que alimenta el geo-visor se traduce en el conjunto de los

shapesfiles obtenidos y convertidos a geoJson, que son interpretados como un archivo

.js común, dado que posee dentro de sus atributos las coordenadas y SRID (Spatial

Reference Sytem Identifier), que para nuestro caso es el EPSG: 3857 (Proyección

WGS84 / Pseudo-Mercator), proyección por defecto de la librería Leaflet. Este es el

Sistema de Referencia Coordenadas más comúnmente utilizado para crear mapas

online y es utilizado por casi todos los proveedores de teselas libres y comerciales.

Utiliza la proyección esférica de Mercator.

6.3.3. Documentos HTML, JavaScript y CSS

Para el desarrollo de la pagina de desarrollan 4 documentos html: index.html

(corresponde a la estructura principal de la página), nosotros.html, manual.html y

ayuda.html (Los cuales corresponden con las diferentes vistas de la página) y cada uno

se estructura en 2 elementos que darán la forma deseada al documento: Head y Body

dentro de este último varios Div.

Index.html

La estructura principal de la página como se mencionó anteriormente está compuesta

por head y body; Para el head (<head>) es la parte no mostrada en el navegador

cuando se carga la página. La cual contiene información como <title> de la página,

enlaces a CSS, enlaces para personalizar favicons, y otros metadatos (datos sobre el

HTML, para nuestro documento como se ve en la ilustración 4:

Se indexaron en las líneas 5 y 6 los archivos .css los cuales dan estilo al

documento

En las líneas 8 y 9 se enlazan los documentos .js (Javascript) necesarios que

permitirán la visualización del “cajón” de mapa, para lo cual se usaran las

librerías y archivos de leaftet los cuales están referidos en la ubicación que

se aprecia en la imagen

Para las funciones de dibujo y edición en la línea 11 se muestran algunas

características del metadato de la función en la 12, 13 y 14 se enlaza el

documento .css que permitirá adquirir el estilo de las funciones es decir los


documentos que definirán la ubicación sobre el mapa, los iconos, entre otras

características

Para facilitar el proceso de programación de algunas características del visor

como el botón para imprimir, se usó la librería JQuery también de

JavaScript, que brinda un amplio margen de funcionalidades para el diseño

de páginas web. Para consultar todo la documentación necesaria se puede

redireccionar desde nuestro conjunto de páginas web, en el apartado de

ayuda.

Ilustración 4 head index.html

El body es el contenedor para todos los aspectos representables de un documento.

Este es el lugar donde los autores arrojan todos los elementos y contenidos que los

visitantes alcanzarán este se explicara por partes, como se ve en la ilustración 5 se

abre la etiqueta header el cual representa un grupo de ayudas introductorias o de

navegación para las características de estilo se crea la clase encabezado y dentro de

este <header> se crean 2 separaciones la primera con un <div> dentro del cual se

llama la imagen del logo y se le dan características; En la segunda división <nav> se

enlazaran los documentos de los vista.

Ilustración 5 Primera parte del body del index.html


Como se aprecia en la ilustración 6, lo que se hizo fue usar un script sencillo para

importar los ya mencionados archivos geoJson, que serán las capas temáticas del

visor, cada archivo de estos ingresa como una variable con características espaciales a

la cual se le asignara estilo para una visualización más cómoda.

Ilustración 6 Segunda parte del body del index.html

Como se aprecia en la Ilustración 7 se abre la etiqueta article (<article>) representa

una composición auto-contenida en un documento, es decir un elemento

independiente del contenido, aquí es donde se ubicará del mapa; En las líneas 49 y 50

se enlaza el javascript que dará la interacción y acciones de los botones de dibujo y la

configuración para el mapa respectivamente; Y por ultimo se encuentra el botón que

permitirá imprimir el mapa en un documento .pdf

Ilustración 7 Tercera parte del body del index.html

Nosotros.html

El head de la vista nosotros, tiene un titulo y se enlazan dos archivos de estilo al igual

que index que se explicaran más adelante; El body tiene una etiqueta header la cual es

la misma que en el archivo index.html como se puede visualizar en la Ilustración 8

Ilustración 8 Head y primera parte del body de nosotros.html


Script.js

En la carpeta raíz del visor, se alojó otra carpeta contenedora “js”, contiene todos los

archivos con extensión “.js”, es decir escritos en JavaScript. Allí, el archivo “script”

es el encargado de toda la interactividad del sistema, esta enlazado directamente a

todos los documentos html, su función es darle dinámica a la página, brinda la

capacidad de una petición de usuario y una respuesta lógica del sistema, por

ejemplo, cambiar de mapa base, remover una capa o cambiarla de color.

Como se menciona anteriormente empleando Leaflet y JQuery, añadimos a la página

todo el contexto geoespacial, desde los sistemas de referencia, hasta las herramientas

de edición e impresión. Este archivos contiene todas las capas como una asignación

de variables, cada una contiene una tabla de atributos, se interpreta a través del

lenguaje de programación, permitiendo acceder a todos los datos de las capas y

manipularlos para darles estilo o desplegar información importante dentro del mapa.

Ilustración 9 Interfaz de usuario VSCode

Archivos .css

Dentro nuestros archivos base también se encuentra una carpeta contenedora con

todos los archivos CSS encargados de dotar de estilo a todas las páginas que

componen el geo-visor de manera que estos archivos están vinculados a las

estructuras HTML de las páginas que componen el proyecto. La mayoría de

navegadores web utilizan CSS para organizar datos e información. Los elementos

dentro del documento CSS afectan la apariencia, el color, la fuente, las imágenes y

otros detalles. El formato CSS permite la gestión mejorada del contenido, la

flexibilidad y la accesibilidad a la información de la página web. El uso de este

lenguaje posibilita que varias páginas cuenten con el mismo formato y la misma

organización, así como utilizar métodos de renderización para mejoras estéticas. .

Ilustración 10 VSCode archivos CSS


6.4. Fase IV

6.4.1. Vista Principal

Descripción de interacciones vista Principal

En esta vista es donde se encuentra el geovisor el cual tiene implementadas

diferentes interacciones las cuales se exponen en la Ilustración 9

Ilustración 11 Interacciones Vista Principal


6.4.2. Vista Nosotros

Esta vista posee la información y descripción de las personas que realizaron el

proyecto, la finalidad de este, y los usuarios finales, también se muestra los escudos

pertenecientes a la carrera de Ingeniería catastral y una imagen alusiva al ejercito

Ilustración 12 Vista nosotros

6.4.3. Vista Manual

Corresponde a una descripción breve de todos los ítems del geovisor, se explica

brevemente el funcionamiento de los botones y características que lo componen, esto

con el fin del brindarle al usuario un entorno más adaptativo en la medida en la que se

le dificulte su funcionamiento de alguno de los elementos.

Ilustración 13 Vista Manual 1


Ilustración 14 Vista Manual 2

6.4.4. Vista Ayuda

En esta sección encontrara las librerías usadas para el desarrollo del geovisor, además

de toda la documentación necesaria para ver el desarrollo del mismo y entender el

funcionamiento del código. Se puede realizar clic sobre las imágenes para re-

direccionarse a la documentación propia de la librería y examinar algunos ejemplos.

Ilustración 15 Vista ayuda

6.4.5. Visor Múltiple

Este visor permite la interacción de 3 mapas los cuales están entrelazados entre si es

decir cualquier movimiento en uno generará movimiento en los otros 2 esta

funcionalidad permitirá la comparación de diferentes capas, como se puede apreciar en

la Ilustración 12 los puntos rojos pertenecen a la ubicación del cursor en el primer

mapa.


Ilustración 16 Vista visor múltiple

6.5.5. Selección final de capas

Dentro del geo visor se dejaron un total de 13 capas y 3 mapas base, cada una de ellas

es capaz de desplegar información de los atributos previamente cargados del archivo

geojson, la información más importante de la capa se despliega dentro de un ventana

emergente (popup) a través de una función incluida en la librería Leaflet. Todas las

capas poseen un estilo por defecto pero cada usuario puede cambiarlo a su gusto.

Ilustración 17 Vista general de algunas capas

Las capas pueden dividirse en tre grupos importantes que se ilustran en la siguiente

tabla, junto con los atributos que se despliegan en sus respectivas ventanas

emergentes.


7. Alcance y Limitaciones

El proyecto pretende la publicación web de una base de datos sobre información temática del territorio

nacional, en donde se muestran diferentes aspectos del territorio en términos de cultivos ilícitos, GAO

(Grupos Armado Organizados), alertas por fenómenos naturales y en general aspectos sociales que

involucran temas de orden social y ambiental de Colombia.

7.1. Alcance

Al finalizar este proyecto se entregará un geo servicio optimizado, en el que se manejaran las

dinámicas de información diferentes:

Visualización web de diferentes capas vectoriales y ráster.

Capacidad de realizar zoom in y zoom out.

Posibilidad de ver anotaciones de cada capa y atributos.

Capacidad de exportar e imprimir el contenido del visor.

Adicional a esto se entregar´ la documentación donde se soporte este proceso, tanto el propio para la universidad como el requerido en la compañía

7.2. Limitaciones

Dado que la información que se maneja es confidencial, se tendrá una limitación de acceso a

ella de manera remota, lo que generar algunos contratiempos a lo largo del desarrollo del

proyecto. Entorno al desarrollo de la base de datos y el geo visor se tendrán algunas

limitaciones de estructura como lo serán:

Incapacidad de exportar capas individualizadas.

No inclusión de meta datos, debido a la falta de los mismos.

No creación de acceso directo (.exe) debido a la dificultad de ejecución por políticas

de privacidad en el CAIMI


8. Conclusiones

El visor cumple con las especificaciones del diseño arquitectónico inicial aunque se realizaron

algunos cambios en los usos de las librerías debido a problemas con algunas de las funciones

de OpenLayers, por cual se usó Leaflet de manera predominante.

El proceso recopilación de los datos fue algo prolongado dado que la mayoría de capas se

construyeron desde cero, desde su tabla de atributos con base en información del IDEAM y la

MOE. Información que se procesó y depuro a través del software Qgis, permitiéndonos

exportar diferentes selecciones de atributos a formato geojson, que finalmente alimentan el

visor.

La implementación y desarrollo del visor fue la parte más compleja del proceso, en esta fase

se ve comprometida toda la lógica de programación y arquitectura base de todo el sistema, de

manera que todos los procesos llevados a cabo en este segmento están orientados al

cumplimiento de los requerimientos establecidos inicialmente.

A través de las pruebas que se realizaron no solo al final, sino a lo largo de todo el proceso de

desarrollo, incurrimos en bastantes errores que se fueron depurando poco a poco a través de

varias fuentes en la web, el soporte oficial de las librerías usadas y comunidades de

programadores como StackOverflow. De manera que a través de las pruebas de validación,

instalación y evaluación logramos un resultado final acorde a lo planteado inicialmente.

Todo el soporte y funcionamiento del geovisor se describe en el apartado de metodología y

resultados de este documento, esto con el fin de que todos los interesados puedan consultar y

acceder libremente a toda la información relacionada con este proyecto, así como de los

elementos externos que se usaron.


Bibliografía

Agafonkin, V. (02 de 07 de 2019). Leaflet. Obtenido de Leaflet.com: https://leafletjs.com/

Bañol Henao, R. E. (Junio de 2015). Diseño Desarrollo e Implemtación de un sitio web y un boletin

digital para el Comite Departamental de Primera Infancia-Caldas. Obtenido de U Manizales:

http://ridum.umanizales.edu.co:8080/xmlui/bitstream/handle/6789/2342/Ba%C3%B1ol_Rogel

io.pdf?sequence=1&isAllowed=y

Canós, J., Letelier, P., & Penadés, M. C. (28 de 06 de 2019). Repositorio institucional de la

Universidad de Las Tunas. Obtenido de http://roa.ult.edu.cu/:

http://roa.ult.edu.cu/bitstream/123456789/476/1/TodoAgil.pdf

Cohn, M. (15 de 07 de 2019). Mountain Goat Software. Obtenido de

http://www.mountaingoatsoftware.com: http://www.mountaingoatsoftware.com/blog/non-

functional-requirements-as-user-stories

DAVINCIS, Grupo de investigación. (9 de Mayo de 2009). Los Web Services y Caracteristicas de

Calidad. Obtenido de unilibre:

http://www.unilibre.edu.co/revistaavances/avances_10/r10_art7.pdf

Dominguez Palacios, D., & Gomez Jaramillo, H. D. (2016). Implementación de un Geovisor de mapas

para la visualización e identificación de amenaza por movimiento de masa e inundación,

prueba piloto del barrio Trece de Noviembre en el municipio de medellin. Obtenido de U

Manizales:

http://ridum.umanizales.edu.co:8080/xmlui/bitstream/handle/6789/2632/Gomez_Dominguez_

Seminario_II_Entrega_Final.pdf?sequence=4

Gaskell, A. (07 de 08 de 2019). StackOverflow. Obtenido de StackOverflow:

https://stackoverflow.com/questions/1328723/how-to-generate-a-simple-popup-using-jquery

Generalitat de Catalunya. (04 de Julio de 2016). ¿Qué es un servicio web geográfico? Obtenido de

Departamento de Territorio y Sotenibilidad:

http://territori.gencat.cat/es/detalls/Article/Serveis_web_geografics

Gonzales Gutierrez, E. (30 de 06 de 2019). Aprende a Programar. Obtenido de

https://www.aprenderaprogramar.es:

https://www.aprenderaprogramar.es/attachments/article/435/CU00704B%20Que%20es%20y

%20para%20que%20sirve%20HTML%20lenguaje%20web%20mas%20importante.pdf

ICDE. (24 de Abril de 2017). Instructivo de consumo de servicios web geográficos . Obtenido de

Infraestructura Colombiana de datos Espaciales.: http://www.icde.org.co/noticias/Conoce-la-

guia-de-consumo-de-servicios-web-geograficos-que-la-ICDE-ha-dispuesto-en-su-portal

Lopez, A., & Rodriguez, K. (Junio de 2017 ). GeoCC Mosquera: Geovisor para la divulgación de la

información de Cambio Climático en el municipio de Mosquera. Obtenido de Repository

udistrital:

http://repository.udistrital.edu.co/bitstream/11349/6557/1/RodriguezDuqueKatherinneAurora2

017.pdf

Lovelace, R. (27 de 07 de 2019). Robin Lovelace. Obtenido de RobinLovelace.net:

https://www.robinlovelace.net/

Marin, Y., De Los Angeles Mazo, N., & Olivo , V. (24 de 07 de 2019). Universidad de Manizales.

Obtenido de https://umanizales.edu.co/:

http://ridum.umanizales.edu.co:8080/xmlui/bitstream/handle/6789/2621/Marin_Mazo_Olivo_

2016.pdf?sequence=1&isAllowed=y

MOE. (27 de 07 de 2019). Mision de Observatorio Electoral. Obtenido de moe.org.co:

https://moe.org.co/categoria/datos-y-mapas/datos-electorales/


Moz://a, M. W. (30 de 07 de 2019). Mozilla. Obtenido de Mozilla.org:

https://developer.mozilla.org/en-US/docs/Learn/CSS

Muñoz Meneses, L. A. (16 de Octubre de 2016). Servicio de inspeccion y evaluación espacial del

riesgo de incendios estructurales en la nube. Obtenido de SIERIE-CLOUD:

http://repository.udistrital.edu.co/bitstream/11349/4102/5/20161016%20TrabajoGrado%20SI

EERIE-CLOUD%20Final.pdf

Peña, A., Guzman, K. N., & Ernesto, L. (4 de Noviembre de 2016). Geovisor Web para Exploraciones

Preliminares Geotécnicas - Geológicas. Obtenido de repository udistrital:

http://repository.udistrital.edu.co/handle/11349/5299

Siqueira Simões, G., & Vazquez, C. E. (Mayo de 2015). Requerimientos funcionales. Obtenido de

pmoinformatica: http://www.pmoinformatica.com/2015/05/requerimientos-funcionales-

ejemplos.html

Siqueira Simões, G., & Vazquez, C. E. (6 de Mayo de 2015). Requerimientos no funcionales.

Obtenido de Pmoinformatica: http://www.pmoinformatica.com/2015/05/requerimientos-no-

funcionales-ejemplos.html

Siqueira Simões, G., & Vazquez, C. E. (Agosto). Requerimientos del software. Obtenido de 2015:

https://www.uv.mx/personal/fcastaneda/files/2015/08/F_Capitulo_5_Requerimientos_del_soft

ware.pdf

Universidad de Toronto. (27 de 06 de 2019). Toronto University. Obtenido de

https://web.cs.toronto.edu/: http://www.cs.toronto.edu/~campbell/340/05w/utm/lectures/18-

NFRs4-up.pdf

Documents

DESARROLLO E IMPLEMENTACIÓN DE UNA BASE DE DATOS …repository.udistrital.edu.co/bitstream/11349/16197/1/Proyecto.pdf · 4. Marco Teórico 4.1. Generalidades 4.1.1. Definición de