UNIVERSIDAD DE COSTA RICA 

SISTEMA DE ESTUDIOS DE POSGRADO 

 

 

DESARROLLO DE UN SISTEMA DE INFORMACIÓN GEOGRÁFICA 

PARA EL REGISTRO Y LA VISUALIZACIÓN DE LOS DAÑOS CAUSADOS 

POR EVENTOS NATURALES EN LA INFRAESTRUCTURA DE LA RED 

VIAL NACIONAL DE COSTA RICA 

 

 

 

Trabajo final de investigación aplicada sometido a la consideración 

de la Comisión del Programa de Estudios de Posgrado en Geografía 

para optar al grado y título de Maestría Profesional en Sistemas de 

Información Geográfica y Teledetección (UCR-UNA). 

  

 

 

ING. GABRIEL JESÚS CORRALES JIMÉNEZ 

 

 

Ciudad Universitaria Rodrigo Facio, Montes de Oca 



 

ii 

 

Dedicatoria 

 

 

 Por toda la paciencia, comprensión, pero 

principalmente por todo su amor, a mi 

esposa Pili. Y a nuestra pequeñita Lía. 

  



 

iii 

 

Agradecimientos 

A mis compañeros de esta generación de maestría, ahora mis amigas y amigos, por ser un 

grupo de personas maravillosas. 

 

A mi amiga Ana Lucía Garita por ser mi compañera de mil batallas durante este proceso. 

 

A Marco, Johann y Rebequita por las hermosas muestras de compañerismo. 

 

A José Galdámez, programador y administrador del sitio codigocorrecto.com, por su ayuda 

desinteresada. Nunca voy a olvidar cómo rescató de un laberinto a un completo 

desconocido. 

 

A Isaac y Karla Zamora por las valiosas ideas y por recordarme las cosas lindas de nuestra 

especie humana. 

 

A Melvin Lizano Araya y Manuel Vargas Del Valle por ser profesores como los que cualquiera 

desearía tener. 

 

A Johanna Salas Jiménez por apoyarme con los permisos y vacaciones que necesité para 

dedicar a este proyecto que parecía interminable. 

 

A mi amigo Luis Ramírez Kuthe (V.) por sus honestos comentarios. 

 

A Giovania Montiel de MIDEPLAN por darme una excelente idea que implementé en la 

aplicación. 

 



 

iv 

 

A Adriana, Arturo, Eduardo, Gabriel, Andrey, Pablo, Ruth, Roger y todos mis amigos que me 

ayudaron a probar las diferentes versiones de la aplicación, por sus ideas y observaciones 

(vosotros sabéis quiénes sois). 

 

A Pucho y Verna por el apoyo que cada uno le ha dado a nuestra familia en esta etapa de 

nuestras vidas. 

 

A Óscar Luis Santos y Roberto Flores Verdejo por su amistad y por las enseñanzas que me 

han compartido, tal vez sin saberlo. 

 

A mis hermanas por siempre estar (no sé quién sería sin ustedes). 

 

Una vez más a Pili por su inconmensurable apoyo, comprensión e inspiración. ¡A donde sea! 

 

Por último, debo mencionar aquí a todos esos héroes y heroínas anónimos que han puesto 

su conocimiento sobre programación a disposición de toda la comunidad de navegantes (y 

de náufragos) a través de blogs, foros y videos. Sin ellos simplemente no lo hubiera logrado. 

  



 

v 

 

“Este trabajo final de investigación aplicada fue aceptado por la Comisión del Programa de 

Estudios de Posgrado Geografía de la Universidad de Costa Rica, como requisito parcial 

para optar al grado y título de Maestría Profesional en Sistemas de Información 

Geográfica y Teledetección (UCR-UNA).” 

 

 

 

 

M.Sc. Francisco Rodríguez Soto 

Coordinador del Programa de Maestría en Sistemas de Información Geográfica y 

Teledetección 

 

 

 

M.Sc. Melvin Lizano Araya 

Profesor Guía 

 

 

 

M.Sc. Manuel Vargas Del Valle 

Tutor 

 

 

 

Ing. Gabriel Jesús Corrales Jiménez 

Sustentante 

 



 

vi 

 

Contenido 

DEDICATORIA .............................................................................................................................................. II 

AGRADECIMIENTOS .................................................................................................................................... III 

RESUMEN ................................................................................................................................................... IX 

ABSTRACT.................................................................................................................................................... X 

CUADROS ................................................................................................................................................... XI 

FIGURAS ..................................................................................................................................................... XI 

ABREVIATURAS ........................................................................................................................................ XIV 

CAPÍTULO 1. INTRODUCCIÓN ...................................................................................................................... 1 

1.1 PROBLEMA DE ESTUDIO ................................................................................................................................... 1 

1.2 JUSTIFICACIÓN .............................................................................................................................................. 3 

1.3 OBJETIVOS ................................................................................................................................................... 4 

1.3.1 Objetivo general ................................................................................................................................ 4 

1.3.2 Objetivos específicos ......................................................................................................................... 4 

CAPÍTULO 2. MARCO CONCEPTUAL ............................................................................................................. 6 

2.1 SISTEMAS DE INFORMACIÓN GEOGRÁFICA (SIG) .................................................................................................. 6 

2.1.1 Aplicaciones SIG ................................................................................................................................ 8 

2.2 SOFTWARE LIBRE Y OTRAS CLASIFICACIONES ........................................................................................................ 8 

2.2.1 Copyleft, GPL de GNU y BSD de OSI ................................................................................................. 11 

2.3 PROGRAMACIÓN DE APLICACIONES MÓVILES ..................................................................................................... 13 

2.3.1 Flutter y el lenguaje de programación Dart .................................................................................... 15 

2.3.2 Git y GitHub ..................................................................................................................................... 16 

2.4 APLICACIONES PARA EL LEVANTAMIENTO DE DATOS EN CAMPO ............................................................................. 16 

2.4.1 QGIS: QField e Input ........................................................................................................................ 18 

2.4.2 ESRI: Collector y Survey123 ............................................................................................................. 19 

2.4.3 Otras aplicaciones para el trabajo de campo .................................................................................. 19 

2.5 BASES DE DATOS .......................................................................................................................................... 20 

2.5.1 Modelo de datos ............................................................................................................................. 22 

2.5.2 Sistemas de gestión de bases de datos ........................................................................................... 23 

2.5.3 Bases de datos espaciales ............................................................................................................... 24 



 

vii 

 

2.5.4 Gestores de bases de datos en código abierto ................................................................................ 24 

2.5.4.1 PostgreSQL y PostGIS ................................................................................................................................ 25 

2.5.5 Firebase Database ........................................................................................................................... 26 

2.6 PUBLICACIÓN DE INFORMACIÓN GEOGRÁFICA EN INTERNET .................................................................................. 27 

2.6.1 Leaflet, OpenLayers y OpenStreetMap ............................................................................................ 29 

2.6.2 R y Shiny .......................................................................................................................................... 31 

CAPÍTULO 3. METODOLOGÍA ..................................................................................................................... 32 

3.1 ALCANCE DEL PROYECTO ............................................................................................................................... 32 

3.2 LIMITACIONES DEL PROYECTO ......................................................................................................................... 33 

3.3 ESQUEMA METODOLÓGICO ............................................................................................................................ 34 

3.4 DEFINICIÓN DE LOS REQUERIMIENTOS DEL SISTEMA ............................................................................................ 35 

3.5 PROGRAMACIÓN DE LA APLICACIÓN MÓVIL PARA REGISTRO DE DATOS DE CAMPO ..................................................... 35 

3.6 CONEXIÓN DE LA APLICACIÓN MÓVIL CON LA BASE DE DATOS DE FIREBASE............................................................... 36 

3.7 OPTIMIZACIÓN DE IMÁGENES E IMPLEMENTACIÓN DE ENVÍO DE REPORTES POR CORREO ............................................ 37 

3.8 IMPLEMENTACIÓN DE LA APLICACIÓN WEB PARA LA VISUALIZACIÓN DE LOS DATOS .................................................... 38 

3.9 REGISTRO DE REPORTES DE PRUEBA ................................................................................................................. 39 

3.10 RECOMENDACIONES PARA LA IMPLEMENTACIÓN DEL SISTEMA ............................................................................ 40 

CAPÍTULO 4. REQUERIMIENTOS DEL SISTEMA ........................................................................................... 41 

4.1 REQUERIMIENTOS FUNCIONALES ..................................................................................................................... 41 

4.2 REQUERIMIENTOS NO FUNCIONALES ................................................................................................................ 42 

4.3 DESCRIPCIÓN DE LOS DATOS REQUERIDOS ......................................................................................................... 43 

4.3.1 Campos de estructura, elemento y daño ......................................................................................... 44 

4.3.2 Campos de zona, ruta y sección ...................................................................................................... 45 

CAPÍTULO 5. APLICACIÓN MÓVIL ............................................................................................................... 48 

5.1 FOTOGRAFÍAS ............................................................................................................................................. 48 

5.2 ESTRUCTURA .............................................................................................................................................. 52 

5.3 ELEMENTO ................................................................................................................................................. 53 

5.4 DAÑO ........................................................................................................................................................ 57 

5.5 SEVERIDAD ................................................................................................................................................. 59 

5.6 SERVICIO .................................................................................................................................................... 60 

5.7 EVENTO ..................................................................................................................................................... 61 

5.8 FECHA ....................................................................................................................................................... 62 

5.9 ZONA ........................................................................................................................................................ 63 



 

viii 

 

5.10 RUTA ...................................................................................................................................................... 65 

5.11 SECCIÓN .................................................................................................................................................. 70 

5.12 UBICACIÓN ............................................................................................................................................... 71 

5.13 OBSERVACIONES ........................................................................................................................................ 72 

CAPÍTULO 6. UTILIDADES DE FIREBASE ...................................................................................................... 76 

6.1 ALMACENAMIENTO DE DATOS ........................................................................................................................ 76 

6.1.1 Firestore .......................................................................................................................................... 77 

6.1.2 Storage ............................................................................................................................................ 79 

6.2 GESTIÓN DE USUARIOS E INICIO Y CIERRE DE SESIÓN ............................................................................................ 82 

6.3 OPTIMIZACIÓN DE IMÁGENES ......................................................................................................................... 85 

6.4 ENVÍO DE REPORTES POR CORREO ELECTRÓNICO ................................................................................................ 89 

CAPÍTULO 7. APLICACIÓN WEB DE VISUALIZACIÓN ................................................................................... 93 

7.1 MAPA DE UBICACIÓN DE LOS DAÑOS ................................................................................................................ 95 

7.2 MENÚ DE SELECCIÓN DE FILTROS .................................................................................................................... 99 

7.3 TABLA DE REGISTROS DE LOS DAÑOS Y DESCARGA DEL ARCHIVO GEOJSON ............................................................ 103 

7.4 BLOQUEO TEMPORAL DEL BOTÓN “GUARDAR” ................................................................................................ 109 

CAPÍTULO 8. CONCLUSIONES Y RECOMENDACIONES................................................................................112 

8.1 CONCLUSIONES ......................................................................................................................................... 112 

8.2 RECOMENDACIONES ................................................................................................................................... 115 

REFERENCIAS BIBLIOGRÁFICAS .................................................................................................................118 

ANEXOS ....................................................................................................................................................123 

ANEXO A. ELEMENTOS Y POSIBLES DAÑOS SEGÚN LAS CUATRO CLASIFICACIONES DE ESTRUCTURAS DEL CONAVI ............... 124 

ANEXO B. DEFINICIÓN DE LOS ELEMENTOS Y POSIBLES DAÑOS SEGÚN EL TIPO DE ESTRUCTURA ........................................ 126 

 

  



 

ix 

 

Resumen 

Costa Rica se ubica en una zona de alta vulnerabilidad afectada estacionalmente por el impacto de 

fenómenos naturales que ocasionan daños y pérdidas enormes de recursos. La infraestructura vial 

es uno de los elementos mayormente afectados por estos eventos. En el país, esta infraestructura 

se divide en dos: la Red Vial Nacional (RVN), de administración estatal, y la Red Vial Cantonal, de 

administración municipal. 

El Consejo Nacional de Vialidad (CONAVI) es la institución encargada de la atención de los daños y 

la conservación de la RVN. Este proyecto consiste en el desarrollo de un Sistema de Información 

Geográfica (SIG) que permitirá al CONAVI el registro y la visualización de los daños ocasionados por 

eventos naturales en la infraestructura de la RVN. 

Este SIG, entendido como tal desde el enfoque de “SIG como proyecto”, cuenta con tres 

componentes: una aplicación móvil para el reporte en campo de los daños en la RVN, un servicio en 

la nube para el almacenamiento de estos datos y una aplicación web para su visualización. El 

desarrollo de estos componentes, y del sistema en general, se basó en requerimientos funcionales 

previamente definidos por el CONAVI. 

Además de esos requerimientos funcionales se implementaron algunas mejoras en el sistema, como 

el envío automático de los reportes por correo electrónico y la optimización de las fotografías 

obtenidas como parte de los datos de campo para reducir su espacio de almacenamiento. 

Es importante destacar que este SIG fue desarrollado utilizando software de acceso gratuito y que 

su implementación en el CONAVI no representaría un costo para esta institución, con la excepción 

del pago por los servicios en la nube si eventualmente se superaran los 5 GB de almacenamiento, lo 

cual motivó la implementación del proceso de optimización de las imágenes. 

Este SIG pretende brindar al CONAVI herramientas adicionales para la planificación de las acciones 

de atención de los daños causados por eventos naturales en la RVN y, de esta manera, mejorar la 

eficiencia y seguridad de las inversiones públicas, lo que se traduce en beneficios para toda la 

sociedad costarricense en términos económicos y de seguridad vial.  

  



 

x 

 

Abstract 

Costa Rica is in a highly vulnerable area that is seasonally affected by the impact of natural 

phenomena that cause enormous damage and loss of resources. Road infrastructure is one of the 

elements most affected by these events. In the country, this infrastructure is divided into two: the 

National Road Network (Red Vial Nacional or RVN), of state administration, and the Cantonal Road 

Network, of municipal administration. 

The National Roads Council (Consejo Nacional de Vialidad or CONAVI) is the institution in charge of 

the attention of the damages and the conservation of the RVN. This project consists of the 

development of a Geographic Information System (GIS) that will allow CONAVI to register and 

visualize the damages caused by natural events in the infrastructure of the RVN. 

This GIS, understood as such from the "GIS as a project" approach, has three components: a mobile 

application for field reporting of damage in the RVN, a cloud service for storing this data and a web 

application for its visualization. The development of these components, and the system in general, 

was based on functional requirements previously defined by CONAVI. 

In addition to these functional requirements, some improvements were implemented in the system, 

such as the automatic sending of reports by e-mail and the optimization of the photographs 

obtained as part of the field data to reduce their storage space. 

It is important to emphasize that this GIS was developed using free access software and that its 

implementation in CONAVI would not represent a cost for this institution, except for the payment 

for cloud services if eventually the 5 GB of storage were to be exceeded, which motivated the 

implementation of the image optimization process. 

This GIS aims to provide CONAVI with additional tools for the planning of actions to address the 

damage caused by natural events in the RVN and thus improve the efficiency and safety of public 

investments, which translates into benefits for the entire Costa Rican society in terms of economic 

and road safety. 

  



 

xi 

 

Cuadros 

CUADRO 4.1 DESCRIPCIÓN DE LOS DATOS REQUERIDOS ........................................................................... 43 

 

Figuras 

FIGURA 3.1 ESQUEMA METODOLÓGICO DEL PROYECTO. .......................................................................... 34 

FIGURA 4.1 REGIONES Y ZONAS DE CONSERVACIÓN VIAL ......................................................................... 46 

FIGURA 5.1 PANTALLA DE INICIO DEL REPORTE ANTES DE LA CAPTURA DE FOTOS ................................... 50 

FIGURA 5.2 VISTA PREVIA DE LA FOTOGRAFÍA POR CAPTURAR ................................................................. 51 

FIGURA 5.3 PANTALLA DURANTE EL PROCESO DE CAPTURA DE FOTOGRAFÍAS ......................................... 52 

FIGURA 5.4 PANTALLA DEL MENÚ DESPLEGABLE “ESTRUCTURA”. ............................................................ 53 

FIGURA 5.5 PANTALLA “ELEMENTO” DE LA ESTRUCTURA “CARRETERA”. .................................................. 54 

FIGURA 5.6 PANTALLA “ELEMENTO” DE LA ESTRUCTURA “PUENTE”. ........................................................ 55 

FIGURA 5.7 PANTALLA “ELEMENTO” DE LA ESTRUCTURA “ALCANTARILLA MAYOR”. ................................ 55 

FIGURA 5.8 PANTALLA “ELEMENTO” DE LA ESTRUCTURA “PUENTE PEATONAL”. ...................................... 56 

FIGURA 5.9 ARCHIVO EN FORMATO CSV CON LA LISTA DE ELEMENTOS. ................................................... 56 

FIGURA 5.10 PANTALLA “DAÑO” DEL ELEMENTO “TALUD”. ...................................................................... 57 

FIGURA 5.11 PANTALLA “DAÑO” PARA LA SUPERESTRUCTURA DE UN PUENTE. ....................................... 58 

FIGURA 5.12 ARCHIVO EN FORMATO CSV CON LA LISTA DE DAÑOS. ......................................................... 58 

FIGURA 5.13 PANTALLA “SEVERIDAD”. ...................................................................................................... 59 

FIGURA 5.14 PANTALLA “SERVICIO”. ......................................................................................................... 60 

FIGURA 5.15 PANTALLA “EVENTO”. ........................................................................................................... 61 

FIGURA 5.16 PANTALLA “FECHA” Y CALENDARIO. ..................................................................................... 62 

FIGURA 5.17 MENSAJE DESPLEGADO POR LA APLICACIÓN AL SELECCIONAR UNA FECHA FUTURA EN EL 

CALENDARIO. ............................................................................................................................................ 63 

FIGURA 5.18 PANTALLA “ZONA”. ............................................................................................................... 64 



 

xii 

 

FIGURA 5.19 LISTA DESPLEGABLE DE LAS ZONAS DE CONSERVACIÓN VIAL. .............................................. 65 

FIGURA 5.20 EXPORTACIÓN DE LA CAPA DE LA RVN A FORMATO DE EXCEL. ............................................. 66 

FIGURA 5.21 LIBRO DE EXCEL HABILITADO PARA MACROS ORDENADO POR ZONA, RUTA Y SECCIÓN....... 66 

FIGURA 5.22 CÓDIGO DE VISUAL BASIC PARA ORDENAR LOS DATOS. ....................................................... 67 

FIGURA 5.23 ARCHIVO EN FORMATO EXCEL PARA LECTURA DE LA RVN. ................................................... 67 

FIGURA 5.24 LISTA DESPLEGABLE DE LAS RUTAS DE LA RVN. ..................................................................... 68 

FIGURA 5.25 CÓDIGO DE FLUTTER PARA LEER EL ARCHIVO DE LA RVN EN EXCEL. ..................................... 69 

FIGURA 5.26 LISTA DESPLEGABLE DE LAS SECCIONES DE CONTROL DE LA RVN. ......................................... 70 

FIGURA 5.27 PANTALLA “UBICACIÓN” PARA OBTENER LAS COORDENADAS DEL DAÑO. ........................... 71 

FIGURA 5.28 PANTALLA “OBSERVACIONES”. ............................................................................................. 73 

FIGURA 5.29 MENSAJE EMERGENTE FINAL DE LA APLICACIÓN. ................................................................. 74 

FIGURA 5.30 CÓDIGO DE FLUTTER PARA ACTUALIZAR LA CAPA DE PUNTOS EN FORMATO GEOJSON. ...... 75 

FIGURA 6.1 PANTALLA DE FIRESTORE DATABASE. ..................................................................................... 77 

FIGURA 6.2 CÓDIGO DE FLUTTER PARA EL ALMACENAMIENTO EN FIRESTORE DATABASE. ....................... 78 

FIGURA 6.3 EDICIÓN DE REGLAS DE FIRESTORE DATABASE. ...................................................................... 78 

FIGURA 6.4 PANTALLA DE FIREBASE STORAGE. ......................................................................................... 79 

FIGURA 6.5 CONTENIDO DE LAS CARPETAS DEL STORAGE. ........................................................................ 80 

FIGURA 6.6 CÓDIGO DE FLUTTER PARA EL ALMACENAMIENTO EN FIREBASE STORAGE. ........................... 81 

FIGURA 6.7 EDICIÓN DE REGLAS DEL STORAGE.......................................................................................... 81 

FIGURA 6.8 PANTALLA DE INICIO DE SESIÓN DE LA APLICACIÓN MÓVIL. ................................................... 82 

FIGURA 6.9 OPCIONES PARA AGREGAR, INHABILITAR Y ELIMINAR USUARIOS EN AUTHENTICATION. ....... 83 

FIGURA 6.10 CAMBIO DE CONTRASEÑA DE USUARIOS EN LA APLICACIÓN. ............................................... 84 

FIGURA 6.11 CORREO ENVIADO POR EL SISTEMA PARA CAMBIAR CONTRASEÑA DE USUARIOS. .............. 84 

FIGURA 6.12 PROCESO DE CIERRE DE LA SESIÓN DE USUARIO. .................................................................. 85 

FIGURA 6.13 CONFIGURACIÓN DE LA EXTENSIÓN RESIZE IMAGES. ............................................................ 87 

FIGURA 6.14 CÓDIGO DE FLUTTER PARA LA OBTENCIÓN DE LOS URL DE LAS IMÁGENES OPTIMIZADAS ... 88 



 

xiii 

 

FIGURA 6.15 GENERACIÓN DE UNA CLAVE DE API EN SENDGRID PARA EL ENVÍO DE CORREOS 

ELECTRÓNICOS. ......................................................................................................................................... 89 

FIGURA 6.16 CONFIGURACIÓN DE LA EXTENSIÓN TRIGGER EMAIL FROM FIRESTORE................................ 90 

FIGURA 6.17 EJEMPLO DE ENVÍO DE REPORTES POR CORREO ELECTRÓNICO. ........................................... 91 

FIGURA 7.1 TABLERO DE CONTROL DE DAÑOS EN LA RVN......................................................................... 93 

FIGURA 7.2 LECTURA DE DATOS DE ENTRADA EN FORMATO GEOJSON. .................................................... 94 

FIGURA 7.3 UBICACIÓN DE DAÑOS EN MAPA BASE VOYAGER. .................................................................. 95 

FIGURA 7.4 BOTÓN DE BÚSQUEDA DE DIRECCIONES Y UBICACIONES GEOGRÁFICAS. ............................... 96 

FIGURA 7.5 UBICACIÓN DE DAÑO EN MAPA BASE DE OSM Y CONTROL DE CAPAS. ................................... 97 

FIGURA 7.6 ETIQUETA PERSONALIZADA CON LOS DATOS DE LOS DAÑOS. ................................................ 98 

FIGURA 7.7 MENSAJE EMERGENTE CON LOS DATOS DE LOS DAÑOS. ........................................................ 98 

FIGURA 7.8 TABLERO PARA UNA CAPA DE PUNTOS DE 18 DAÑOS REPORTADOS SIN LA APLICACIÓN DE 

FILTROS. ...................................................................................................................................................100 

FIGURA 7.9 TABLERO CON FILTRO APLICADO PARA DAÑOS DE ALTA SEVERIDAD. ...................................101 

FIGURA 7.10 DAÑOS FILTRADOS POR TIPO DE ESTRUCTURA, DAÑO Y SEVERIDAD. ..................................102 

FIGURA 7.11 DAÑOS FILTRADOS POR FECHA DEL EVENTO. ......................................................................103 

FIGURA 7.12 TABLA DE REGISTROS DE DAÑOS ORDENADOS POR FECHA DE MANERA ASCENDENTE. ......104 

FIGURA 7.13 MENÚ DE SELECCIÓN DE MÁXIMO DE REGISTROS MOSTRADOS EN LA TABLA DE REGISTROS 

DE DAÑOS. ...............................................................................................................................................105 

FIGURA 7.14 EJEMPLO DE BÚSQUEDA EN LA TABLA DE REGISTROS DE DAÑOS. .......................................105 

FIGURA 7.15 PROCESO PARA EXPORTAR LA CAPA DE PUNTOS A OTROS FORMATOS EN QGIS. ................106 

FIGURA 7.16 TABLA DE ATRIBUTOS DE LA CAPA DE PUNTOS EN QGIS. .....................................................107 

FIGURA 7.17 VISUALIZACIÓN DE UN PUNTO EN LA HERRAMIENTA DE IDENTIFICACIÓN DE QGIS. ............108 

FIGURA 7.18 CÓDIGO DE FLUTTER DE LAS FUNCIONES PARA DESBLOQUEAR LA APLICACIÓN MÓVIL. .....110 

FIGURA 7.19 DOCUMENTO EN FIRESTORE UTILIZADO EN EL BLOQUEO TEMPORAL DEL BOTÓN 

“GUARDAR”. ............................................................................................................................................110 

FIGURA 7.20 MENSAJE DESPLEGADO POR LA APLICACIÓN CUANDO EL BOTÓN “GUARDAR” ESTÁ 

BLOQUEADO. ...........................................................................................................................................111 



 

xiv 

 

Abreviaturas 

API Interfaz de Programación de Aplicaciones 

CONAVI Consejo Nacional de Vialidad 

EPSG European Petroleum Survey Group 

ESRI Environmental Systems Research Institute 

FSF Free Software Foundation 

GB Gigabyte 

GNSS Sistema Global de Navegación Satelital 

GPL Licencia Pública General 

GPS Sistema de Posicionamiento Global 

HTML HyperText Markup Language 

IDE Entorno de Desarrollo Integrado 

JSON Java Script Object Notation 

kB Kilobyte 

MB Megabyte 

OGC Open Geospatial Consortium  

OSD Open Source Definition 

OSI Open Source Initiative 

OSM Open Street Map  

RAE Real Academia Española 

RVN Red Vial Nacional de Costa Rica 

SDK Paquete de Desarrollo de Software 

SGBD Sistema de Gestión de Bases de Datos  

SIG Sistema de Información Geográfica 

SQL Lenguaje Estructurado de Consultas 

WGS84 World Geodetic System 1984 

  



 

xv 

 

 

 

 

 

 

 



1 

 

 

Capítulo 1.  Introducción 

En este capítulo se explican los elementos necesarios para facilitar la comprensión del 

planteamiento de este proyecto: el problema de estudio que motivó la investigación, la justificación 

de su importancia, y la descripción de los objetivos del trabajo. 

1.1 Problema de estudio 

Costa Rica se encuentra en un escenario de multiamenaza que estacionalmente se ve afectado por 

el impacto de fenómenos naturales de origen hidrometeorológico y geotectónico, principalmente, 

por su ubicación en una de las zonas más vulnerables del mundo, cuyos riesgos han aumentado 

considerablemente en las últimas tres décadas (Mayorga, 2019). Como consecuencia, se producen 

daños sobre la infraestructura nacional que ocasionan enormes pérdidas de recursos utilizados por 

el Estado para reconstrucción o rehabilitación. Solamente en el periodo entre 1988 y 2012, las 

pérdidas directas por el impacto de fenómenos climáticos alcanzaron los 1 326 millones de dólares 

en nuestro país (Flores et al., 2013). 

Uno de los sectores más afectados por los daños a nivel nacional es el de infraestructura vial. La Red 

Vial Nacional (RVN) se encuentra expuesta a amenazas hidrometeorológicas, sísmicas y, en menor 

grado, volcánicas (Arias et al., 2018). En algunos puntos específicos de la RVN se ha observado que 

los daños ocasionados por este tipo de fenómenos se presentan de manera recurrente. Esto indica 

que las intervenciones realizadas en esos puntos no han sido las necesarias para evitar daños 

futuros, sino que, a raíz de la urgencia por atender los eventos o habilitar el paso vehicular, se han 

reconstruido elementos de la infraestructura con las mismas vulnerabilidades. Con el fin de 

subsanar esta deficiencia, se requieren intervenciones con diseños que permitan la construcción o 

rehabilitación de estructuras resilientes. 

La institución encargada de la construcción, rehabilitación y conservación de la RVN en Costa Rica 

es el Consejo Nacional de Vialidad (CONAVI). Esta institución debe llevar a cabo una planificación tal 

que permita priorizar la ejecución de proyectos entre estos numerosos casos, con el fin de llegar a 

soluciones reales para los daños en infraestructura vial ocasionados por eventos naturales.  

La base de dicha planificación es la obtención en campo de datos como el tipo de daño, su ubicación, 

el elemento dañado, la magnitud del daño y el evento que lo originó. En el CONAVI, este 



2 

 

 

procedimiento se realiza actualmente registrando las coordenadas de cada punto dañado a través 

del uso de dispositivos receptores GNSS (Sistema Global de Navegación Satelital). Posteriormente, 

estas coordenadas y los datos adicionales de cada punto se registran en tablas de hojas de cálculo 

y se envían, mediante correo electrónico, al personal de oficina encargado de la recopilación de los 

registros de todo el país. 

El proceso descrito anteriormente no es un proceso sistematizado, por lo que requiere tiempo del 

personal de campo empleado en digitalizar la información para enviarla al personal de oficina en 

hojas de cálculo de registros en los que las coordenadas de cada punto se ingresan manualmente. 

Paralelamente, deben enviar fotografías relacionadas con cada registro mediante un método 

manual que requiere ciertos cuidados para evitar confusiones entre los distintos sitios.  

Adicionalmente, ese proceso implica tiempo del personal de oficina para realizar la recopilación 

manual de los registros enviados, la validación de datos, el control de calidad y el procesamiento de 

la información con el fin de elaborar mapas para facilitar la visualización y el estudio de los daños.  

El proceso completo consiste en la manipulación directa y constante de los datos por parte de 

distintos actores y esto lo hace susceptible a equivocaciones humanas que podrían ocasionar 

resultados erróneos e incluso pérdidas de información. Es, por lo tanto, un proceso ineficiente e 

inseguro, en el que se maneja información no estandarizada, que implica una carga considerable de 

trabajo y, en consecuencia, la utilización de tiempo que podría ser empleado en otras tareas. 

Con base en lo anterior, existe la necesidad de hacer más eficiente y seguro el procedimiento de 

registro y visualización de los datos de daños en la infraestructura de la RVN ocasionados por 

eventos naturales.  

A raíz de lo anterior, se plantean las siguientes preguntas de investigación: 

1. ¿Es posible para el CONAVI la implementación de un sistema de información geográfica que le 

permita el registro y almacenamiento de datos de los daños en la infraestructura vial utilizando 

software gratuito? 

2. ¿Podría una aplicación gratuita de Sistemas de Información Geográfica (SIG) incluir un proceso 

automatizado de publicación en un visor web de los datos de daños previamente almacenados? 

 



3 

 

 

1.2 Justificación 

La importancia de un sistema de información geográfica (SIG) que registre y almacene los datos de 

los daños en la infraestructura vial ocasionados por eventos naturales, así como la posterior 

publicación en una plataforma que facilite la visualización de estos datos mediante un proceso 

automatizado, se encuentra en que permitirá sistematizar una serie de tareas realizadas 

actualmente en el CONAVI con el fin de evaluar los daños y tomar decisiones en materia de 

reconstrucciones y rehabilitaciones de la RVN.  

Es necesario aclarar el alcance del SIG propuesto, ya que no está planteado para el registro de datos 

en la infraestructura vial de Costa Rica en su totalidad, sino únicamente en la infraestructura de la 

RVN, relacionada con la actividad del CONAVI. Por lo tanto, no contempla rutas cantonales, que son 

de administración municipal. 

La sistematización de los procesos implicados en el análisis de daños en la RVN reducirá el tiempo 

en trabajos de campo y de escritorio considerablemente, debido a que algunas labores actuales 

dejarán de ser necesarias. El personal de campo responsable del reporte de los daños se evitará 

tareas como la digitalización de los registros en hojas de cálculo, el ingreso manual de las 

coordenadas de cada punto y el envío al personal de oficina de las hojas de cálculo junto con 

fotografías de cada sitio previamente identificadas. Por su parte, el personal de oficina encargado 

de recibir los datos de campo se evitará tareas tales como la validación, procesamiento, registro de 

datos y la elaboración y continua actualización de mapas para visualizar los resultados. 

Por lo tanto, la implementación del SIG hará más eficiente, en todas sus etapas, el proceso de 

reporte de los daños ocasionados por eventos naturales en la RVN y la visualización de resultados. 

Esto implica una reducción de las cargas de trabajo, que podría enriquecer el ambiente de trabajo y 

la motivación del personal, y un ahorro de tiempo que podrá ser destinado por el personal para la 

realización de otras labores, lo cual se traduce a su vez en un beneficio económico. 

La sistematización de los procesos a partir de la implementación de un SIG minimizará la 

manipulación de los datos, lo que reducirá considerablemente factores de error humano en la 

cadena de tareas comprendidas entre la captura y la visualización de los datos; adicionalmente, 



4 

 

 

permitirá el almacenamiento de datos estandarizados. Por lo tanto, la obtención de resultados no 

solamente será más ágil y eficiente, sino que también será más confiable. 

La implementación del SIG plantea mejoras institucionales en términos de eficiencia y seguridad en 

el manejo de datos y de la confiabilidad de los resultados obtenidos para el estudio de daños, que 

representarían un beneficio directo para todo el personal implicado. Sin embargo, en términos 

generales, se traduciría en beneficios indirectos para toda la sociedad costarricense, como 

consecuencia de la optimización de recursos y de la contribución en las mejoras de los procesos de 

inversión en la RVN. 

La propuesta de este proyecto consiste en la implementación de un SIG a partir del uso de software 

gratuito, considerando la situación mundial luego de la pandemia de Covid-19, cuyas implicaciones 

económicas han evidenciado la necesidad de realizar recortes en los presupuestos del Estado y han 

traído a discusión la reducción de gastos no esenciales, dentro de los cuales se podría incluir los 

pagos por licenciamiento de software no indispensable en instituciones estatales, como el CONAVI. 

1.3 Objetivos 

1.3.1 Objetivo general 

• Desarrollar un sistema de información geográfica que permita al CONAVI registrar y 

visualizar los daños causados por eventos naturales en la infraestructura de la Red Vial 

Nacional de Costa Rica sin necesidad de pagar por licencias de software. 

1.3.2 Objetivos específicos 

• Programar una aplicación móvil que permita el reporte de los datos de campo de los daños 

en la infraestructura de la RVN causados por eventos naturales, mediante el uso de software 

gratuito. 

• Almacenar en una base de datos la información obtenida en campo de los daños en la 

infraestructura de la RVN causados por eventos naturales, mediante el uso de software 

gratuito. 



5 

 

 

• Implementar una aplicación web para visualizar la información obtenida en campo de los 

daños en la infraestructura de la RVN causados por eventos naturales, mediante el uso de 

software gratuito.



6 

 

 

Capítulo 2.  Marco conceptual 

En este capítulo se explican los conceptos fundamentales requeridos para el desarrollo de un 

sistema de información geográfica acorde con los objetivos de este proyecto. 

Los conceptos sobre las tecnologías y herramientas aquí explicados permitirán una mejor 

comprensión de las áreas del conocimiento que deben estudiarse en relación con la programación 

de aplicaciones móviles para el registro de datos de campo, su almacenamiento en bases de datos 

y su visualización mediante aplicaciones web, elementos que componen el sistema de información 

geográfica propuesto en este proyecto. 

El capítulo incluye la explicación de los distintos enfoques desde los cuales se pueden conceptualizar 

los sistemas de información geográfica (SIG) y la definición de “aplicaciones SIG”; continúa con una 

introducción a la programación informática, para lo cual se explican las diferentes clasificaciones de 

software según el acceso a su código fuente, su distribución y las diferentes licencias disponibles, 

como introducción al tema de la programación de aplicaciones móviles y las tecnologías requeridas 

para su desarrollo. Más adelante se listan las principales aplicaciones para el levantamiento de datos 

de campo disponibles en la actualidad. Llegado a este punto se contemplan los conceptos 

relacionados con el primer objetivo específico del proyecto. 

El sustento conceptual del siguiente objetivo del proyecto se trata en la Sección 2.5, dedicada al 

tema de bases de datos, que contempla la inclusión de elementos espaciales a través del uso e 

instalación de extensiones y un repaso de los principales gestores de bases de datos en código 

abierto y de algunas soluciones de almacenamiento en la nube utilizados actualmente. 

Finalmente, en la Sección 2.6 se aborda la publicación de información geográfica en Internet, a 

manera de introducción al tema de programación de visores web. De esta manera se cubre la 

conceptualización del tercer objetivo específico de este proyecto. 

2.1 Sistemas de información geográfica (SIG) 

Existen tres diferentes perspectivas para definir un SIG (también muy conocidos como GIS, por su 

acrónimo en inglés). La primera de ellas se basa en las funcionalidades y en la potencialidad de las 

herramientas para crear modelos digitales de la realidad. La segunda está basada en las distintas 



7 

 

 

posibilidades de manejo de la información espacial, que define a los SIG como una extensión del 

concepto de bases de datos. La tercera es un enfoque desde el punto de vista organizacional, que 

incluye en su definición al recurso humano relacionado con el manejo de la información geográfica 

(Del Bosque et al., 2012). 

Al no existir una única definición de SIG, este término puede ser empleado para referirse a 

cuestiones esencialmente distintas entre sí: se tiene SIG como disciplina, SIG como proyecto (cada 

una de las implementaciones técnicas de la disciplina SIG) y SIG como software (los programas que 

permiten el desarrollo de esta disciplina y la implementación de sus proyectos) (Del Bosque et al., 

2012). Sin embargo, una definición completa y precisa es la de un SIG como un sistema integrador 

de tecnología informática, personas e información geográfica para capturar, analizar, almacenar, 

editar y representar datos georreferenciados (Olaya, 2020). 

Los SIG pueden ser divididos en seis componentes básicos: hardware, software, datos geográficos, 

personas, organización y productos del sistema. Esta división nace de la perspectiva que 

conceptualiza los SIG desde el punto de vista organizacional y es consecuente con la definición 

empleada por Olaya (2020). A partir de esta lógica, el software es considerado una de las partes y 

no el sistema en sí mismo. De esta manera, los productos informativos obtenidos a partir del 

software, como los mapas, son considerados parte del sistema.  

Desde la perspectiva de SIG como proyecto, esos seis componentes deben ser definidos con mucha 

claridad durante una fase de planificación, que es esencial para la implementación de un SIG en una 

organización, cuya etapa clave es la determinación de los productos esperados por el sistema, pues 

de ellos dependerá tanto la tecnología necesaria para su implementación, como los datos 

requeridos y el personal por contratar o capacitar y, por lo tanto, los otros componentes del SIG 

(Tomlinson, 2013). 

El proceso de definición de los productos del sistema se da en ocasiones de manera natural, como 

resultado del hallazgo de necesidades dentro de una organización, por lo cual, suele ser común que 

se cuente con cierta claridad de los productos esperables, y la decisión de implementar un SIG o una 

aplicación SIG se da como respuesta a esa necesidad. 

 



8 

 

 

2.1.1 Aplicaciones SIG 

Las aplicaciones SIG son “el elemento de trabajo básico dentro de todos aquellos que componen el 

concepto global de un SIG” (Olaya, 2020). Se trata de las herramientas fundamentales para el 

trabajo con datos espaciales. Actualmente existen muchos tipos de aplicaciones SIG, dentro de las 

que se encuentran elementos provenientes de distintos ámbitos como el análisis de imágenes, el 

diseño asistido por ordenador (CAD), las bases de datos y las herramientas de diseño gráfico. 

Es posible clasificar las aplicaciones SIG en tres grupos principales: las herramientas de escritorio, 

los repositorios de datos y los clientes y servidores que permiten el trabajo remoto con todo tipo de 

datos SIG (Olaya, 2020). Estos tres grupos se encuentran relacionados entre sí y se brindan apoyo 

para ofrecer todo el conjunto de capacidades actuales de los SIG. 

El grupo de aplicaciones de clientes y servidores para trabajo remoto ha cobrado gran importancia 

recientemente, pues se ha convertido en elemento fundamental y muy representativo del mundo 

SIG actual. Los clientes se pueden presentar de diferentes maneras, ya sea como aplicaciones web 

o integradas dentro de herramientas de escritorio (Olaya, 2020).  

Existen otros tipos de aplicaciones derivados de las anteriores, como las aplicaciones para 

dispositivos móviles, cuyas particularidades en relación con las aplicaciones tradicionales facilitan 

su utilización como herramientas para trabajo de campo. Estas aplicaciones pueden ser clasificadas 

de diferentes formas, según sus medios de distribución y el acceso o restricción de los usuarios a 

sus códigos fuente. 

2.2 Software libre y otras clasificaciones 

Los anglicismos hardware y software se definen en español como el “conjunto de aparatos de una 

computadora” y el “conjunto de programas, instrucciones y reglas informáticas para ejecutar ciertas 

tareas en una computadora”, respectivamente (RAE, 2014). En otras palabras, el hardware se refiere 

al componente físico de un equipo computacional, y el software, por su parte, al componente lógico 

(los programas). Ambos componentes en conjunto posibilitan el funcionamiento de los sistemas 

informáticos: el software envía instrucciones al hardware para su ejecución. 



9 

 

 

La distinción entre ambos términos es necesaria para introducir las clasificaciones de software, 

según el acceso a su código fuente y su forma de comercialización o distribución. El código fuente 

es el conjunto de instrucciones escritas en un lenguaje de programación que las convierte al sistema 

binario para ser interpretadas por máquinas. Por lo tanto, el código fuente es la base de todo 

programa informático. 

De acuerdo con su comercialización o distribución, si el programa o aplicación informática se puede 

adquirir y utilizar sin necesidad de pagar, se trata de software gratuito. Por el contrario, si el 

programa es comercializado en condiciones limitantes del número de equipos en que puede ser 

instalado y utilizado según lo estipulado por licencias pagadas, se clasifica comúnmente como 

software licenciado (Guadamuz, 2008), aunque, como se explica adelante, también existen licencias 

para software gratuito. 

De acuerdo con el acceso a su código fuente, el software se puede clasificar como software de 

código abierto (open source) o software privativo o propietario. A diferencia de este último, el 

software de código abierto mantiene disponible el acceso al código fuente original, para su 

examinación, revisión, modificación y mejoramiento (Guadamuz, 2008). 

El software libre es una especialización del software de código abierto que debe cumplir además 

con los siguientes cuatro requisitos o, en otras palabras, permitir estas cuatro libertades (Chinchilla, 

2011): 

• Libertad 0: ejecutar el programa para cualquier propósito. 

• Libertad 1: estudiar la forma en que funciona el programa y adaptarlo a necesidades 

individuales (el acceso al código fuente es una condición previa a esta libertad). 

• Libertad 2: distribuir copias para colaborar con la colectividad. 

• Libertad 3: mejorar el programa y lanzar las mejoras al público para beneficio de toda la 

comunidad (el acceso al código fuente es una condición previa a esta libertad). 

Según los principios anteriores, la clasificación de software libre responde a una iniciativa de índole 

filosófica, cuyo origen se remonta a 1984, cuando Richard Stallman, un informático del Instituto 

Tecnológico de Massachusetts (MIT, por sus siglas en inglés), crea la “Fundación de Software Libre” 



10 

 

 

o “Free Software Foundation” (FSF) para apoyar las ideas nacientes en la época sobre compartir 

información desarrollando software libre (Guadamuz, 2008). 

El concepto de software libre es motivo de confusión con el de software gratuito, debido en gran 

parte a que en el idioma inglés se utiliza la misma palabra (free) para definir los términos “libre” y 

“gratis”. Sin embargo, aunque lo más común es que el software libre sea a la vez gratuito, no es un 

requisito necesario para esta clasificación: una aplicación informática no requiere ser gratis para 

cumplir con las cuatro libertades que todo software libre debe permitir a los usuarios. 

La anterior no es la única confusión común en relación con estas clasificaciones de software. El 

software de código abierto, en un sentido amplio, es la contraposición al concepto tradicional de 

desarrollo comercial con “código cerrado”, o software privativo. Sin embargo, así como el software 

libre se basa en principios filosóficos o ideológicos, existe una clasificación de software de código 

abierto basada en este tipo de principios, y fue definida a finales de la década de 1990 por Eric 

Raymond y Bruce Perens, conocida como “Open Source Definition” (OSD). Su principal objetivo es 

la revisión conjunta de trabajos bajo el principio de que mientras más personas accedan al código 

de un programa, este mejorará en términos de confiabilidad, estabilidad y seguridad (Guadamuz, 

2008). 

Desde entonces, esta corriente y sus principios ganaron mucha popularidad, por lo que algunos 

desarrolladores etiquetaban sus productos como “Open Source” como estrategia de mercadeo, 

aunque no se acogieran a los principios de OSD en realidad. Con el fin de evitar estas prácticas, sus 

autores crearon en 1998 la “Iniciativa de Código Abierto” o “Open Source Initiative” (OSI) para la 

certificación de programas verdaderamente basados en sus principios. Esta organización mantiene 

además una lista pública del software que cuenta con esta certificación (Opensource.org, 2020). 

Existen diferencias filosóficas e incluso de índole personal entre los miembros de la FSF y de la OSI 

y, por lo tanto, también las hay entre el software libre y el de código abierto, de acuerdo con las 

definiciones de estas organizaciones. Sin embargo, algunos desarrollos pueden cumplir con los 

principios de ambos, por lo que es común la utilización del término “Software Libre y de Código 

Abierto” o “Free and Open-Source Software”, bajo el acrónimo FOSS (por sus siglas en inglés). 



11 

 

 

Si además de cumplir con las dos anteriores definiciones, un software es gratuito, se puede clasificar 

como un “Free, Libre and Open-Source Software” (FLOSS), también comúnmente utilizado 

(Guadamuz, 2008), y que en español se podría definir como un software libre, de código abierto y 

gratuito. 

Otras dos definiciones importantes y frecuentemente utilizadas en este ámbito son las de 

“Freeware” y “Shareware”, ambas subclasificaciones de software gratuito. Freeware es aquel 

software gratuito cuyo código no es abierto y se encuentra protegido por licencia, por lo que no 

puede ser modificado ni utilizado en ningún otro desarrollo. Shareware es el software de 

distribución gratuita durante un periodo de prueba, luego del cual se debe pagar para continuar con 

su uso.  

Una variante del shareware es el software ofrecido de forma gratuita no de manera temporal, sino 

con algunas de sus capacidades o herramientas desactivadas, y de esta forma, el usuario que lo 

desee debe pagar para obtener la versión completa del programa. Esta variante es algunas veces 

llamada liteware. 

2.2.1 Copyleft, GPL de GNU y BSD de OSI 

Si un programa y su código fuente se ponen a disposición del dominio público, sin copyright 

(protección legal de propiedad intelectual), para su utilización, modificación y distribución, se deja 

abierta la posibilidad de que una de sus versiones llegue a convertirse en software privativo y sus 

usuarios perderían las libertades otorgadas por el autor original. 

El copyleft es un método legal para impedir que el software libre y sus versiones modificadas sean 

convertidas en software privativo. Define términos de distribución utilizando la ley de copyright con 

el objetivo de preservar y garantizar un programa como software libre, en contraposición con su 

finalidad restrictiva habitual. De esta manera, les otorga a los usuarios del programa los permisos 

para su ejecución, copia, modificación, y redistribución de las versiones modificadas y a su vez, les 

impide añadir restricciones por su cuenta (Stallman, 2020). 

El objetivo principal del copyleft es garantizar como derechos a quienes posean una copia de un 

programa o sus versiones modificadas, las libertades básicas que definen el software libre. De esta 



12 

 

 

forma todos los desarrollos basados en el código de un programa con copyleft se encuentren 

disponibles para la comunidad en caso de publicarse. 

Un caso específico de copyleft es el de la Licencia Pública General de GNU o GPL de GNU. GNU es 

un proyecto de la FSF, cuyo objetivo es promover el desarrollo colaborativo de software y 

conocimiento mediante el uso de licencias libres. Una de ellas es la GPL, que se puede aplicar a 

software y otros tipos de obras. Con su utilización, los desarrolladores protegen sus derechos de 

autor sobre el programa a la vez que otorgan permisos legales para su copia, distribución y 

modificación.  

Uno de los requisitos de la GPL de GNU es identificar las versiones modificadas de los programas, 

de este modo, sus eventuales fallos o problemas no se atribuirán erróneamente a los autores de 

versiones anteriores. Por otro lado, y en congruencia con los principios del copyleft, la GPL garantiza 

que las patentes no se puedan utilizar para transformar un software libre en privativo (Lara, 2019). 

De la misma manera en que el copyleft y la GPL en específico están ligados a la FSF, existe un tipo 

de licencia utilizada para certificar los productos en línea con la OSI: la BSD License. Esta licencia 

garantiza que un software se ajuste a los principios del código abierto, menos comprometidos con 

la filosofía centrada en las libertades perseguidas por el software libre, por lo que cuenta con menos 

restricciones en ese sentido y permite, por ejemplo, el uso del código fuente en software privativo. 

Las versiones más actualizadas de la GPL y la BSD, son la tercera versión de la General Public License 

de GNU o GPLv3 y la Licencia BSD modificada (de tres cláusulas, originalmente contaba con cuatro) 

o 3-Clause BSD License, respectivamente. 

El uso de licencias para garantizar que un software o algunos de los productos obtenidos a partir de 

su código fuente no lleguen a convertirse en software privativo, puede aplicarse a desarrollos de 

distintos tipos. En los últimos años una de las áreas que ha experimentado un mayor crecimiento 

en este ámbito es la de programación de aplicaciones para dispositivos móviles. 

 

 



13 

 

 

2.3 Programación de aplicaciones móviles 

La programación es un proceso basado en diseñar, escribir, depurar y actualizar el código fuente de 

un programa informático para que se comporte de una manera determinada, mediante el uso de 

un lenguaje de programación. Aunque es común relacionarla únicamente con computadoras, 

actualmente la programación se puede aplicar a muchos tipos diferentes de aparatos, desde 

grandes máquinas industriales hasta pequeños dispositivos portátiles. 

Los procesadores utilizan internamente un lenguaje conocido como “código máquina”, un sistema 

binario de numeración que consiste en sucesiones de unos y ceros, y no está pensado para ser 

escrito ni leído por personas. Los lenguajes de programación funcionan como traductores entre el 

código máquina y el lenguaje humano (Hinojosa, 2016). 

Por otro lado, los dispositivos móviles son aparatos fácilmente transportables y utilizables durante 

su transporte, con capacidades de procesamiento, una memoria limitada, comunicación inalámbrica 

y conexión permanente o intermitente a una red, diseñados para una función específica, pero con 

la capacidad de llevar a cabo otras funciones generales, y que permiten la interacción con usuarios 

(Ramírez et al., 2014).  

La definición anterior se utiliza principalmente para hacer referencia a teléfonos móviles y tabletas, 

sin embargo, dentro de esta definición se pueden incluir muchos otros tipos de dispositivos tales 

como reproductores de audio portátiles, lectores de libros electrónicos o navegadores y receptores 

en Sistemas Globales de Navegación Satelital (GNSS). 

En términos generales, el desarrollo móvil se refiere a las actividades relacionadas con la creación 

de aplicaciones o programas para dispositivos como “teléfonos inteligentes” o tabletas, 

principalmente. Estos desarrollos se llevan a cabo mediante el uso de herramientas como lenguajes 

de programación, interfaces de programación de aplicaciones (API) y paquetes de desarrollo de 

software (SDK), con el fin de implementar aplicaciones en una o varias plataformas o sistemas 

operativos móviles. 

Un sistema operativo es la estructura principal, o conjunto de programas de un dispositivo, que se 

encarga de administrar sus recursos de software y hardware. Los sistemas operativos para 

dispositivos móviles más conocidos son Android (Google), iOS (Apple), Symbian (Nokia) y Blackberry 



14 

 

 

OS (Robledo, 2013). Sin embargo, actualmente son los dos primeros quienes en la práctica dominan 

el mercado (Statcounter, 2021). 

Android es el sistema operativo para dispositivos móviles impulsado por Google. Una de sus 

características principales es la capacidad para ser instalado en cualquier tipo de dispositivo móvil, 

gracias a su código abierto basado en Linux (sistema operativo de software libre). Mientras tanto, 

iOS es el sistema operativo para los dispositivos móviles de Apple, clasificado como software 

privativo y únicamente disponible para los equipos de esta empresa. 

Ya sea para Android o iOS, las aplicaciones móviles pueden ser programadas mediante 

implementación a través de la web o mediante el uso de lenguajes nativos. Si son creadas utilizando 

tecnologías web comunes como HTML, CSS y JavaScript y funcionan en cualquier plataforma que 

use un navegador compatible con esos estándares, se clasifican como “aplicaciones web 

progresivas” (PWA). Generalmente estas aplicaciones son sencillas de programar y actualizar, no 

obstante, funcionan únicamente con conexión a Internet y tienen un acceso limitado al hardware 

del dispositivo, lo que reduce sus posibilidades (Velasco, 2020). 

Los lenguajes nativos son los que desarrollan aplicaciones específicamente para cada sistema 

operativo, adaptando el lenguaje en que son desarrollados. iOS es desarrollado en el lenguaje 

Objetive-C y Android en Java. Utilizar estos lenguajes para la creación de aplicaciones permite 

aprovechar al máximo el hardware del dispositivo y evitar la dependencia de la web, pues las 

aplicaciones nativas pueden funcionar sin conexión a Internet. 

Existen otros lenguajes nativos para Android inspirados en Java, como Kotlin, además de algunos 

programas o “entornos de desarrollo integrado” (IDE, de Integrated Development Environments, no 

confundir con “Infraestructuras de Datos Espaciales”) o editores de código fuente que facilitan el 

desarrollo de software. Uno de los más populares para Android es Android Studio, un IDE basado en 

Java que contiene ayudas de sintaxis, un creador de interfaz gráfica y permite la prueba y 

depuración de las aplicaciones antes de su publicación. Sin embargo, se estima que el más utilizado 

en la actualidad posiblemente sea Visual Studio Code (VS Code), un editor de código fuente 

desarrollado por Microsoft, que es software libre y multiplataforma (F. Flores, 2022). 

 



15 

 

 

Para los dispositivos iOS, Apple creó a Swift, otro lenguaje de programación nativo tan completo 

como Objetive-C, pero más sencillo de aprender, que permite el desarrollo de aplicaciones con un 

rendimiento superior. En todo caso, las aplicaciones deben pasar posteriormente por XCode, el 

compilador de Apple para iOS (Velasco, 2020). 

Actualmente existe una alternativa que permite la creación de aplicaciones nativas y de alto 

rendimiento tanto para iOS como Android, utilizando la misma base de código. Se trata de Flutter, 

el SDK de Google. 

2.3.1 Flutter y el lenguaje de programación Dart 

Flutter es un paquete de desarrollo de software o Software Development Kit (SDK) de código abierto 

desarrollado por Google para la creación de aplicaciones móviles nativas multiplataforma, cuyos 

códigos fuente funcionan tanto en iOS como Android. Su objetivo es hacer el desarrollo lo más 

simple, rápido y con el mejor rendimiento y estética posibles. 

Este SDK se basa en el uso de widgets, que son pequeñas aplicaciones presentadas en archivos 

livianos, ejecutadas para dar acceso fácilmente a funciones frecuentemente utilizadas y proveer de 

información visual. En Flutter todos los elementos se pueden programar utilizando widgets, desde 

simples botones hasta animaciones. Una aplicación podría consistir únicamente en un conjunto de 

widgets funcionando con un objetivo común. Por lo tanto, los widgets son las principales entidades 

de Flutter (Mainkar & Giordano, 2019). 

A pesar de ser relativamente joven, Flutter es de las herramientas más utilizadas en el mundo para 

el desarrollo de aplicaciones y ha presentado un acelerado crecimiento desde su lanzamiento en 

2017. Entre sus ventajas se puede mencionar la estética de las interfaces gráficas de sus 

aplicaciones, que las hace muy atractivas para los usuarios. Desde el punto de vista del diseño, 

Flutter permite conservar la visión original de los diseñadores tal como fue concebida para las 

aplicaciones, sin comprometer los detalles durante su implementación. En términos del desarrollo, 

Flutter reduce tiempos, costos y complejidad, por lo que es recomendable para el aprendizaje de 

nuevos desarrolladores. 

El elevado desempeño de Flutter, en comparación con otras herramientas, se atribuye a la 

utilización de Dart, un lenguaje de programación de código abierto también desarrollado por 



16 

 

 

Google. Dart fue lanzado en 2013 y desde entonces ha garantizado una plataforma estable para la 

producción de aplicaciones que se pueden ejecutar en cualquier dispositivo. Mantiene cierta 

similitud con lenguajes tradicionales como Java, C# o JavaScript, pero su énfasis principal radica en 

su capacidad para crear aplicaciones complejas de alto rendimiento (Balbaert & Ridjanovic, 2013). 

2.3.2 Git y GitHub 

En el ámbito de la programación informática, es común la utilización de sistemas de control de las 

distintas versiones de códigos fuente. Uno de estos es Git, un proyecto de software libre compartido 

mediante licencia GNU GPL, diseñado para rastrear cambios en el código fuente durante el proceso 

de programación. 

Git también puede ser utilizado para llevar el control de cambios en conjuntos de archivos de 

cualquier otro tipo. Facilita la recuperación de versiones anteriores, la integración de modificaciones 

derivadas del trabajo colaborativo, la creación de distintas ramas de un mismo producto y el 

respaldo de los archivos (Vargas, 2020). 

El funcionamiento de Git se basa en la sincronización de un repositorio, o conjunto de archivos 

almacenados localmente, con la versión almacenada en sistemas remotos, como sitios proveedores 

de servicios de alojamiento de software que utilizan el protocolo de Git, entre los cuales el más 

importante es GitHub.  

En la práctica Git es una herramienta de línea de comandos y el eje alrededor del cual giran los 

elementos relacionados con ella es la plataforma de desarrollo colaborativo GitHub (en su sitio 

GitHub.com), que existe desde 2007. La mayoría de sus usuarios la utiliza para alojar proyectos de 

programación, cuyos códigos se almacenan típicamente en forma pública. 

2.4 Aplicaciones para el levantamiento de datos en campo 

Actualmente existe una gran variedad de aplicaciones de información geográfica para dispositivos 

móviles, con diferentes finalidades y funciones. La mayoría de ellas hace uso de los sistemas de 

ubicación propios del hardware de los dispositivos. Pese a no contar con la exactitud de los equipos 

especializados de navegación satelital, aparatos como teléfonos móviles se utilizan en gran escala 

como medios de posicionamiento, gracias a una combinación entre la información obtenida a partir 



17 

 

 

de sus receptores satelitales y las antenas de telefonía móvil. Esto permite niveles de exactitud 

suficientes para obtener resultados satisfactorios, principalmente en áreas urbanas, al utilizar 

aplicaciones de navegación, como Google Maps y Waze; de transporte como Uber y Didi; de orden 

y entrega de compras como Glovo y Rappi. 

Los chips receptores satelitales de los dispositivos móviles están diseñados para recibir señales 

transmitidas por los satélites a frecuencias ubicadas en la región de frecuencia ultra alta (UHF, por 

sus siglas en inglés) del espectro electromagnético (Vílches, 2019). Las frecuencias utilizadas 

tradicionalmente para este fin son las conocidas como Banda L1 y Banda L2. La mayoría de los 

receptores cartográficos y geodésicos, así como algunos teléfonos móviles cuentan con receptores 

de Banda L2. Posteriormente se sumó a ellas la Banda L5, cuyas longitudes de onda son 19, 24 y 25 

cm respectivamente, y que en la actualidad no se encuentra disponible en la mayoría de los 

teléfonos móviles, solo en algunos modelos de gama alta. 

Por tanto, esos dispositivos móviles de alta gama cuentan con receptores satelitales para esas tres 

bandas y algunos de ellos tienen la capacidad de procesar las señales de otros sistemas globales de 

navegación satelital (GNSS, por sus siglas en inglés) además del GPS. El término GNSS es el nombre 

genérico que engloba a los sistemas de posicionamiento geoespacial con cobertura satelital. El 

primero de estos fue el conocido como “Sistema de Posicionamiento Global” (GPS, por sus siglas en 

inglés) y por esto es un concepto tan extendido en la sociedad que se confunde comúnmente con 

el de GNSS (Berné et al., 2019). Los principales GNSS son el GPS, desarrollado en Estados Unidos; 

GLONASS en Rusia; Galileo en la Unión Europea; y BeiDou en China. 

Existen varias aplicaciones móviles diseñadas para el levantamiento de datos de campo. 

Naturalmente, la exactitud de cada una de ellas no depende de sí misma, sino del hardware a través 

del cual se ejecutan, es decir, de la tecnología propia de cada dispositivo móvil. Sin embargo, la 

ubicación al utilizar dispositivos móviles cuyo error sea de aproximadamente cinco metros, es 

aceptable para los estándares tecnológicos actuales. Si las labores de registro de datos de campo 

requieren una mayor exactitud, los levantamientos deberían realizarse utilizando aparatos 

especializados. 

Algunas de las aplicaciones más utilizadas para la toma de datos en campo mediante dispositivos 

móviles consisten en herramientas ajustables a las necesidades específicas de cada caso, mediante 



18 

 

 

la elaboración de formularios utilizados en campo y complementados con el uso de software de 

escritorio. Existen soluciones de este tipo en software de código abierto y en software privativo, 

como aplicaciones para el uso en conjunto con QGIS o algunas herramientas de ESRI (Environmental 

Systems Research Institute). 

2.4.1 QGIS: QField e Input 

QGIS es el software libre de información geográfica más utilizado del mundo, conocido 

anteriormente como Quantum GIS. Es distribuido mediante licencia GNU/GPL y desarrollado en el 

lenguaje de programación C++ por la Open Source Geospatial Foundation (OSGeo), una organización 

no gubernamental (ONG) que promueve y apoya el desarrollo colaborativo de tecnologías 

geoespaciales y datos abiertos. 

Dos de las herramientas para el levantamiento de datos de campo más utilizadas actualmente 

funcionan en conjunto con QGIS. Ambas permiten la sincronización con este software luego de la 

toma de los datos. Se trata de las aplicaciones gratuitas y de código abierto QField e Input. 

La primera de ellas en desarrollarse fue QField, una aplicación para la toma de datos mediante 

dispositivos móviles con sistema operativo Android, que cuenta con una gran cantidad de funciones 

como digitalización, edición de geometría y atributos, búsquedas, elaboración de formularios de 

trabajo de campo, integración de cámaras e inclusive soporte para aparatos GNSS especializados. 

Esta herramienta permite exportar a QGIS los datos obtenidos en campo y de esta forma aprovechar 

todas sus funcionalidades (Alonso, 2019). 

La aplicación Input es más novedosa que QField. También se basa en QGIS, por lo que permite 

configurar proyectos fácilmente desde el escritorio. A diferencia de QField, Input no solamente 

funciona en el sistema operativo Android, sino también en dispositivos iOS y, adicionalmente, ofrece 

una interfaz de usuario más amigable. Otra ventaja importante de Input es su servicio de 

almacenamiento en la nube, de manera gratuita hasta los 100 MB, lo que facilita la exportación a 

QGIS de los datos de campo. Sin embargo, por tratarse de un desarrollo más reciente, aún no supera 

las funciones de digitalización y edición de QField (Morales, 2020a). 

 



19 

 

 

 

2.4.2 ESRI: Collector y Survey123 

La empresa ESRI es líder mundial en desarrollo y comercialización de software licenciado de 

información geográfica. Su producto más conocido es ArcGIS, un completo sistema compuesto por 

programas y herramientas que permiten la creación y utilización de SIG. ESRI desarrolló y popularizó 

el formato vectorial de datos espaciales tradicionalmente utilizado en todo el software de este tipo, 

el shapefile, originalmente creado para el uso interno de sus productos, y que posteriormente se 

convirtió en el formato estándar de intercambio de información geográfica. El shapefile sigue siendo 

el más utilizado, aunque actualmente existen otros formatos más novedosos que corrigen algunas 

de sus debilidades y desventajas (ver Sección 3.1 “Alcance del proyecto”). 

El catálogo de productos de ESRI es muy extenso y variado. Algunos de estos productos son 

aplicaciones para el trabajo de campo, entre las cuales las más utilizadas actualmente son ArcGIS 

Collector y ArcGIS Survey123.  

Collector es una aplicación licenciada que permite la captura de información espacial desde 

dispositivos móviles, tanto iOS como Android, para recopilar y actualizar información de campo y 

almacenarla en la nube, como una manera de extender el alcance de ArcGIS para el uso de campo 

(Morales, 2020b). El registro de información de campo se apoya en la utilización de mapas base. 

Survey123 es una herramienta muy similar a Collector, sin embargo, no se basa en el uso de mapas 

base, sino que se enfoca en la elaboración de formularios para la realización de encuestas, como 

indica su nombre, con la particularidad de permitir el registro de la ubicación desde donde se llena 

el formulario con información de campo. Esta aplicación también se encuentra disponible para 

dispositivos iOS y Android y cuenta con una versión liteware para su comercialización. 

2.4.3 Otras aplicaciones para el trabajo de campo 

Aparte de las aplicaciones diseñadas para su uso en las plataformas de QGIS y ESRI, existen otras 

herramientas de diferentes categorías para la toma de datos de campo mediante dispositivos 

móviles.  



20 

 

 

Una de ellas es el software libre gvSIG Mobile, distribuido bajo licencia GNU/GPL, que permite el 

levantamiento de puntos de campo de forma rápida y de calidad, y se encuentra disponible para 

dispositivos Android. Esta aplicación se integra directamente con gvSIG Desktop y gvSIG Online, que 

forman parte de La Generalitat Valenciana Sistema de Información Geográfica (gvSIG), un proyecto 

impulsado por el gobierno regional de la Comunidad Valenciana de España. gvSIG actualmente es 

un software libre de información geográfica de los más utilizados en el mundo, después de QGIS. 

Otras aplicaciones importantes para la toma de datos en campo cuyos códigos no son abiertos se 

mencionan y clasifican a continuación, según su forma de distribución y acceso (Morales, 2020b):  

ODK Collect y Kobo Collect (aplicaciones para Android de código abierto), Oruxmaps (freeware), 

CartoDruid (freeware), GIS Cloud (liteware), Mappt™ (liteware), Fulcrum (shareware), SuperSurv 

(software de pago), iGIS (software de pago para iOS). 

En general, toda aplicación para el registro de trabajo de campo debe complementarse con el uso 

de algún tipo de almacenamiento de los datos, de manera que posteriormente puedan ser 

analizados, procesados y editados para generar la información requerida. Algunas de las 

aplicaciones mencionadas cuentan con sistemas de “almacenamiento en la nube”, que consisten en 

la utilización de bases de datos en línea a través de servidores remotos. Otras de ellas funcionan en 

conjunto con el almacenamiento físico de los datos. 

2.5 Bases de datos 

Las bases de datos son conjuntos de datos estructurados y relacionados lógicamente, con un 

propósito específico que satisface las necesidades de cierto tipo de usuarios. Son elementos 

fundamentales de las ciencias informáticas y tienen utilidad y aplicación en todas las áreas del 

conocimiento o disciplinas donde se requiera la gestión de datos.  

Una base de datos puede estar compuesta por cualquier tipo de datos, ya sean numéricos, 

alfanuméricos, imágenes, música, videos e inclusive los que constituyen la componente temática de 

la información geoespacial (Escobar et al., 2019). Sin embargo, no contiene solamente datos, sino 

descripciones de estos mismos denominadas metadatos, que se almacenan en diccionarios de datos 

o catálogos y son las que permiten la independencia lógica – física de los datos (Marqués, 2009). 



21 

 

 

Las propiedades principales de las bases de datos son la estructuración y la sistematicidad, pues son 

las responsables de facilitar su utilización y el alcance de los objetivos generales de toda base de 

datos: almacenar, recuperar y editar diferentes tipos de información.  

Las bases de datos permiten concurrencia, es decir, que pueden ser utilizadas simultáneamente por 

distintos usuarios, por tanto, se presentan las necesidades de integrarlas con una mínima cantidad 

de duplicidad y de evitar las inconsistencias, pues los datos no pertenecen a un solo individuo o 

departamento, sino que se comparten en toda una organización o, inclusive, en ámbitos mayores: 

con el auge de las telecomunicaciones e Internet, actualmente una base de datos puede tener 

usuarios en diferentes partes del mundo simultáneamente.  

A pesar de que los orígenes de las bases de datos se remontan a la Antigüedad, con el nacimiento 

de las primeras bibliotecas en la historia, el desarrollo del término como tal y su uso de manera 

sistematizada surgieron con la necesidad de almacenamiento y procesamiento de grandes 

cantidades de información que motivaron la aparición de las primeras computadoras. En 1884, 

Herman Hollerith creó la máquina automática de tarjetas perforadas, basada en el uso de sistemas 

mecánicos, para procesar datos de los censos en Estados Unidos (Escobar et al., 2019). Desde 

entonces, el desarrollo de este campo ha sido paralelo al de la informática. 

Desde sus inicios en el Siglo XIX, con la utilización de máquinas perforadoras automáticas para el 

registro y conteo de grandes cantidades de información, a partir de la década de 1950, la evolución 

de las bases de datos ha pasado por el almacenamiento en cintas magnéticas; el almacenamiento 

en discos; la creación de bases de datos relacionales o “modelo relacional”; la aparición del 

“Lenguaje Estructurado de Consultas” (SQL por sus siglas en inglés); el desarrollo de bases de datos 

orientadas a objetos; hasta llegar al desarrollo actual de aplicaciones capaces de intercomunicarse 

entre estaciones de trabajo, páginas web y dispositivos móviles (Escobar et al., 2019). 

El lenguaje de consultas SQL, desarrollado en la década de 1980, es un lenguaje declarativo de 

acceso a bases de datos relacionales, que permite la consulta, recuperación y modificación de datos, 

así como su análisis y la realización de diferentes operaciones de manera relativamente sencilla. Su 

aparición marca un hito muy importante en la evolución de las bases de datos. 



22 

 

 

En 1970, con anterioridad al desarrollo del lenguaje de consultas SQL, el científico informático Edgar 

Frank Codd implementó el modelo relacional, que consiste en un conjunto de relaciones tabulares 

tan importantes como los datos, los cuales a su vez se agrupan en tablas bidimensionales con 

información de una determinada entidad, donde las columnas representan sus atributos. La 

simplicidad de este modelo, y sus fundamentos matemáticos sólidos le dotan de una gran potencia, 

de ahí su enorme popularidad en la actualidad (Olaya, 2020). 

2.5.1 Modelo de datos 

El modelo relacional mencionado anteriormente forma parte del conjunto de herramientas 

conceptuales utilizadas para la descripción de los datos, sus relaciones, su significado y sus 

restricciones de consistencia dentro de una base de datos, lo que se conoce como modelo de datos 

(Proal, 2006). Un modelo de datos consta de tres etapas: modelo conceptual, modelo lógico y 

modelo físico. 

El modelo conceptual es general y organiza los datos en conjuntos interrelacionados de objetos o 

entidades, con atributos asociados. La manera más común de elaborar un modelo conceptual es 

mediante el modelo entidad – relación, que consiste en un diagrama para representar entidades, 

atributos, llaves, relaciones y la cardinalidad entre estas relaciones (uno a uno, uno a muchos y 

muchos a muchos). Este diagrama puede tabularse de manera que cada tabla represente una 

entidad y las columnas representen sus atributos. El modelado conceptual es la etapa básica en la 

implementación de una base de datos, por lo tanto, toda modificación al esquema de esta se debe 

realizar primero en el modelo conceptual (Proal, 2006). 

El concepto de llaves o claves es fundamental para la elaboración del modelo conceptual. Una llave 

es el atributo que identifica de manera única a cada entidad, garantizando que cada registro de una 

tabla pueda ser identificado precisamente. Existen varias clasificaciones para los atributos que 

podrían utilizarse como llaves, sin embargo, en la práctica es fundamental conocer los conceptos de 

llave primaria y llave foránea. 

Una llave primaria es el campo o atributo que identifica un registro dado exclusivamente dentro de 

una tabla y a su vez representa este registro en la base de datos completa. Esta llave permite 

establecer relaciones con otras tablas, así como evitar la existencia de registros duplicados. Cuando 

una llave es utilizada para referirse a atributos de otra tabla, se conoce como llave foránea. Estos 



23 

 

 

tipos de llaves se generan a partir de las relaciones entre entidades: una llave foránea en una tabla 

es necesariamente la llave primaria de otra tabla.  

La siguiente etapa en el proceso de modelado de datos es la definición del modelo lógico, que 

consiste en la versión completa donde se incluyen todos los detalles acerca de los datos, obtenida 

a partir de la conversión de las entidades en tablas y los atributos en las columnas de estas tablas 

(Proal, 2006). En algunos casos, las relaciones entre entidades también pueden representarse como 

tablas. En esta etapa del modelado y antes de la elaboración del modelo físico, es necesario definir 

los tipos de los datos almacenados como atributos, ya sea, números enteros, decimales o cadenas 

de texto, entre otros; así como también la cantidad de dígitos que definirán la longitud y precisión 

de los datos. 

Como última etapa en la modelación de los datos se debe llevar el modelo lógico a un modelo físico. 

Esto quiere decir que la representación de objetos como tablas deben mapearse al medio físico, 

para lo cual se requiere un profundo entendimiento del manejador o sistema de gestión de bases 

de datos utilizado donde se implementará este esquema. 

2.5.2 Sistemas de gestión de bases de datos 

La aparición del modelo relacional permitió el desarrollo del sistema de gestión de bases de datos 

(SGBD) denominado Sistema de Software Relacional, que dio origen a la empresa actualmente 

conocida como Oracle Corporation. El sistema de Oracle sigue siendo uno de los más completos y 

robustos del mundo, lo que le ha permitido liderar históricamente el mercado de servidores 

empresariales. Su más fuerte competidor en el campo es SQL Server de Microsoft, sin embargo, 

también existen sistemas gestores de bases de datos relacionales con licencia libre como 

PostgreSQL, MySQL y Firebird, ampliamente utilizados desde su aparición en la década de 1990 

(Escobar et al., 2019). 

Un SGBD es un sistema que permite la definición, creación, mantenimiento y acceso controlado de 

una base de datos. Realiza la definición mediante un lenguaje utilizado para especificar la estructura, 

el tipo de datos y sus restricciones. Los SGBD también cuentan con un lenguaje de manejo de datos, 

cuya finalidad es el ingreso, actualización, eliminación y consulta de los datos.  



24 

 

 

El acceso controlado es proporcionado por los SGBD a través de un conjunto de sistemas que evitan 

el acceso de usuarios no autorizados a la base de datos, mantienen la integridad y consistencia de 

los datos, permiten el acceso compartido, restablecen la base de datos a su estado previo en caso 

de fallos de hardware o software y contienen los metadatos de una manera accesible para los 

usuarios (Marqués, 2009). 

2.5.3 Bases de datos espaciales 

Añadir información de localización a una base de datos permite una representación visual de la 

información, el registro y edición de información geográfica, que contiene componentes temáticos 

y espaciales. De esta manera se originan las bases de datos espaciales o bases de datos geográficas. 

La incorporación de información geográfica representa una complicación adicional en relación con 

las bases de datos convencionales, pues no es sencillo mantener las características propias del SGBD 

en este contexto, así como tampoco lo es integrar esa base de datos a un SIG de manera en que 

aproveche su potencia de la mejor manera posible (Olaya, 2020). 

Las bases de datos espaciales almacenan entidades del mundo real que ocupan un lugar en el 

espacio, según un sistema de referencia de coordenadas determinado; mantienen relaciones 

espaciales entre ellas y el resto de los elementos del entorno; y poseen atributos propios que las 

diferencian en un momento determinado, incluso si se trata de entidades abstractas. En esto 

consiste la principal diferencia entre una base de datos espacial y una base de datos convencional 

(Del Bosque et al., 2012). 

Aunque la mayoría de los SGBD actuales permiten la incorporación de información geográfica, una 

de las opciones más utilizadas consiste en la utilización del sistema de código abierto PostgreSQL y 

su extensión PostGIS.  

2.5.4 Gestores de bases de datos en código abierto 

Los SGBD relacionales más populares del mundo actualmente son Oracle, SQL Server de Microsoft y 

los sistemas de código abierto PostgreSQL y MySQL. Estos dos últimos están diseñados para 

ejecutarse desde los sistemas operativos de servidores más comunes, como Windows, Linux y 

macOS. PostgreSQL y MySQL fueron implementados mediante el lenguaje de programación “C” y 

utilizan el lenguaje declarativo de acceso a bases de datos SQL. 



25 

 

 

PostgreSQL es el más antiguo de los dos, ya que su lanzamiento se dio en 1989, a cargo del “Grupo 

Global de Desarrollo de PostgreSQL”. Posteriormente se lanzó MySQL en 1995 y actualmente 

pertenece a la compañía Oracle. 

Debido a la innovación impulsada por el código abierto, actualmente existe gran cantidad de 

opciones además de PostgreSQL y MySQL. Entre estas se pueden mencionar gestores de bases de 

datos como MariaDB, CockroachDB, ClickHouse, Neo4j, MongoDB, RethinkDB, Redis, SQLite, 

Cassandra, CouchDb, entre otras (Thakur, 2021). 

A pesar de la gran candidad de alternativas, PostgreSQL se sigue considerando en muchos ámbitos 

como la mejor opción de bases de datos relacionales, por presentar características como la ventaja 

de permitir modelos de datos híbridos para trabajo en conjunto con instalaciones NoSQL parciales 

(Thakur, 2021) y su soporte para objetos geográficos a través de la extensión PostGIS.  

2.5.4.1 PostgreSQL y PostGIS 

A pesar del liderazgo histórico de Oracle, para muchos usuarios de bases de datos PostgreSQL es 

considerado el SGBD más avanzado de la actualidad, no solamente dentro del ámbito del software 

de código abierto, sino inclusive en comparación con SGBD propietarios como Oracle. Además de 

ser un servidor de bases de datos, PostgreSQL es una plataforma de desarrollo de aplicaciones, con 

ventajas adicionales de transacción de soporte, almacenamiento masivo, registro diario y 

recuperación de datos (Krosin et al., 2013). 

Existen dos herramientas para facilitar el trabajo y la utilización de PostgreSQL como SGBD. Se trata 

de pgModeler y pgAdmin. El pgModeler es una herramienta CASE (Computer Aided Software 

Engineering) que se utiliza para crear y editar el modelo físico de la base de datos, generando código 

SQL a través de una interfaz de usuario sencilla. Esta herramienta permite exportar las estructuras 

de datos a los servidores de PostgreSQL y generar secuencias de comandos (scripts) SQL para 

mantener sincronizada la base de datos con respecto al modelo (Segovia, 2018). El pgModeler es la 

herramienta más utilizada actualmente para el modelado de datos en PostgreSQL. 

Para complementar el trabajo con pgModeler se utiliza el pgAdmin, un módulo de administración 

de bases de datos que funciona como repositorio público o servidor PostgreSQL para modificar, 



26 

 

 

exportar y manejar datos de almacenamiento en línea, que utiliza los códigos SQL generados 

previamente en el pgModeler (Mora, 2020).  

De la misma forma que el PostgreSQL, esos dos módulos o herramientas son de código abierto y se 

complementan, de ser necesaria la incorporación de datos espaciales, con el uso de PostGIS, una 

extensión de PostgreSQL utilizada para convertir sus sistemas de bases de datos en bases de datos 

espaciales. PostGIS tiene licencia GNU/GPL y por lo tanto es gratuito. Además, es una alternativa 

real al software propietario, considerado en algunos ámbitos de expertos como superior en 

estabilidad y rapidez al utilizar una indexación espacial (Morales, 2016a). 

PostGIS permite otorgar permisos a usuarios de diferentes niveles, para evitar que algunos puedan 

visualizar, cambiar o eliminar cierta información, lo que lo convierte en un sistema seguro. La 

importación y exportación de datos se realiza de una manera sencilla a través de varias herramientas 

conversoras y, adicionalmente, es compatible con un gran número de aplicaciones y con los 

estándares del Open Geospatial Consortium (OGC), organización internacional sin fines de lucro 

cuyo objetivo es la creación de estándares abiertos e interoperables que faciliten el intercambio de 

información geográfica a la comunidad geoespacial global (Morales, 2016a). 

2.5.5 Firebase Database 

Firebase es una plataforma de desarrollo de aplicaciones móviles y aplicaciones web, creada por 

una compañía del mismo nombre en 2011 y adquirida por Google tres años más adelante, por lo 

que no es de código abierto, pero sí de acceso libre. Esta plataforma permite la mejora y el 

crecimiento empresarial al ofrecer una amplia variedad de productos como alternativas sencillas 

para el desarrollo de aplicaciones, páginas web, juegos de video, API’s o almacenamiento de datos 

en la nube. Técnicamente, Firebase es un “backend as a service” (Younis, 2021). 

Entre sus productos se encuentra Firebase Database, una base de datos clasificada como NO SQL, 

grupo dentro del que se clasifican las bases de datos no relacionales que no utilizan el lenguaje de 

consultas SQL (Acens, 2014). Esta, a su vez, presenta dos opciones para los diferentes 

requerimientos de los usuarios: Firebase Realtime Database y Firebase Firestore Database (Younis, 

2021). 



27 

 

 

La primera de estas opciones consiste en una base de datos de tiempo real basada en 

almacenamiento en la nube. En este tipo de bases de datos el servidor provee la información en 

tiempo real sin necesidad de solicitarla (Younis, 2021). A manera de ejemplo, las bases de datos de 

tiempo real son las que permiten el ingreso de nuevos mensajes sin necesidad de activar un botón 

para refrescar o actualizar la información en las aplicaciones de mensajería. 

Al conectar las aplicaciones a Firebase Realtime Database la conexión no se da a través del protocolo 

HTTP (Hyper Text Transfer Protocol) normal, sino a través de conectores web especiales que 

permiten una mayor velocidad de transferencia de datos. Esta alternativa almacena los datos en 

formato JSON (Java Script Object Notation).  

Otra de las características de Firebase Realtime Database es que optimiza el uso de la aplicación sin 

conexión a Internet. Una vez que el dispositivo se vuelve a conectar, los datos locales se sincronizan 

automáticamente. 

Por otro lado, Firebase Firestore Database es otra alternativa de base de datos con almacenamiento 

en la nube para aplicaciones móviles que utiliza documentos y colecciones para almacenar los datos, 

a diferencia de las tablas utilizadas en el modelo relacional. Esto permite un mejor desempeño en 

las búsquedas y consultas (Younis, 2021). 

Firebase también cuenta con un servicio en la nube que proporciona un espacio de almacenamiento 

para archivos como imágenes, videos y otros recursos multimedia que podrían ser generados por 

las aplicaciones. Este servicio se llama Firebase Storage y permite además la carga, descarga y 

gestión de archivos de manera amigable. 

Por lo tanto, la elección entre ambas alternativas dependerá de las características deseadas en cada 

aplicación. Firebase Database es compatible con Flutter, por lo que las aplicaciones desarrolladas 

mediante esta plataforma se pueden conectar con estas bases de datos a través de conjuntos de 

complementos. 

2.6 Publicación de información geográfica en Internet 

La publicación de repositorios y servicios de información geográfica en Internet es una práctica 

comúnmente utilizada en la actualidad, que tiene los siguientes objetivos (Lizano, 2020): 



28 

 

 

• Incorporar el atractivo e interactividad creciente de Internet y las redes sociales. 

• Permitir consultas y realizar análisis de los datos. 

• Incluir la participación del público general o de ciertos usuarios en la construcción del mapa, 

en los casos en que sea posible y necesario. 

Para desplegar la información en las pantallas de los diferentes navegadores, computadoras y 

dispositivos móviles, en una época donde el uso de estas últimas para la navegación por Internet 

aumenta en comparación con el de computadoras de escritorio, fue necesario pasar de un diseño 

tradicional al “Responsive Web Design” o “Diseño Web Adaptable” que es capaz de auto ajustarse a 

los distintos tamaños de pantallas entre navegadores y dispositivos móviles de diferentes 

resoluciones con énfasis en un despliegue y manejo eficiente (Lizano, 2020). 

Ese tipo de diseño permite a los usuarios obtener una mejor experiencia con el contenido visual 

desplegado en el aparato o plataforma que utilicen. Es reconocido con nombres diferentes como 

diseño fluido, elástico, adaptativo o flexible (Baturay & Birtane, 2013). Su implementación mediante 

los estándares HTML, CSS y Javascript es de gran ayuda para los diseñadores web que tratan este 

tipo de asuntos. De la misma manera, Flutter, el paquete de desarrollo de software o Software 

Development Kit (SDK) de código abierto desarrollado por Google para la creación de aplicaciones 

móviles, integra el diseño web adaptable en sus productos (Flutter.dev, 2020). 

Además de estas consideraciones, un mapa web debe cumplir con requisitos adicionales de calidad 

(Lizano, 2020): 

• Debe ser sencillo, evitar al máximo la saturación de información. 

• El contenido a publicar debe ser optimizado para considerar el desempeño en línea. 

• Debe ser exacto, no omitir las normas básicas de la cartografía. 

• Debe tener un objetivo claro que debe ser mostrado a primera vista y de forma evidente. 

• Debe ser atractivo y vistoso para capturar la atención de los usuarios finales. 

• Debe ser dinámico o interactivo. 

• En la simbología se debe evitar el uso de colores fuertes. Es recomendable utilizar colores 

pastel. 

• Los símbolos utilizados deben ser pequeños, simples, distintivos y fáciles de manejar e 

interpretar. 



29 

 

 

Actualmente existen varias plataformas de diferentes clasificaciones según las condiciones de uso y 

el acceso a su código fuente, que permiten la publicación de información geográfica de manera 

sencilla en la web, tales como: 

• “Google My Maps” (freeware). 

• “CARTO” (liteware). 

• “GeoWE” (libre). 

• “GeoJson.io” (código abierto). 

• “Mango” (shareware). 

• “UMap” (código abierto). 

• “Mapbox” (código abierto). 

• “Instamaps” (código abierto). 

• “ArcGIS Online” (liteware). 

• “GIS Cloud” (shareware). 

• “CLICK2MAP” (freeware). 

• “MapTiler” (shareware). 

• “QGIS Cloud” (plugin o complemento para el software libre QGIS). 

2.6.1 Leaflet, OpenLayers y OpenStreetMap 

Las herramientas Leaflet y OpenLayers son bibliotecas de JavaScript de código abierto utilizadas para 

la publicación de mapas en la web. Ofrecen funciones de alto rendimiento para mostrar e 

interactuar con los mapas y datos geoespaciales. Con el fin de aumentar su eficiencia, trabajan 

mediante el uso de módulos, por lo que no se requiere descargar las bibliotecas completas sino sólo 

las secciones o módulos necesarios para cada aplicación. Son las más ampliamente utilizadas en la 

actualidad. 

OpenLayers fue lanzada originalmente por la empresa Metacarta, en parte como respuesta a 

Google Maps, para luego pasar a ser de las primeras soluciones en código abierto de su clase. 

Actualmente cuenta con una gran comunidad de colaboradores (Hazzard, 2011).  Esta herramienta 

se ha desarrollado para promover el uso de información geográfica de todo tipo, por lo que 

incorpora funcionalidades avanzadas, donde radica una de sus ventajas (Hernández, 2020). Sin 



30 

 

 

embargo, su código se compone de gran cantidad de líneas complejas y su documentación es 

extensa y complicada. 

Por otro lado, los ejes principales de Leaflet son la simplicidad y la capacidad de dar respuesta a las 

funcionalidades más utilizadas en las aplicaciones de un mapa web. Leaflet nació como respuesta a 

la complejidad de OpenLayers. Utiliza un código con estilo más moderno y su documentación resulta 

más clara para los nuevos usuarios, por lo que es más sencillo y rápido de aprender (Morales, 

2016b). Su simplicidad se combina bien con el uso de plugins o complementos para extender sus 

funcionalidades. Su filosofía consiste, por tanto, en mantener una biblioteca ligera y sencilla para 

funciones básicas que se complementan con desarrollos de terceros, los cuales se incorporan 

constantemente. 

La biblioteca Leaflet se puede utilizar a través del lenguaje de programación de propósito general 

Python, cuyo uso y popularidad ha aumentado enormemente en los últimos años y tiene una 

especial aplicación en datos geoespaciales. Esta compatibilidad es posible gracias al uso de Folium, 

un módulo de Python que crea mapas web generando código fuente en JavaScript, el lenguaje 

utilizado por Leaflet (Vargas, 2020). En síntesis, es posible manejar los datos en Python para 

visualizar los resultados en Leaflet. 

Leaflet cuenta con una amigable interfaz de programación de aplicaciones (API) que permite la 

creación de aplicaciones de gran calidad estética y con ajuste de pantalla, mediante la incorporación 

de los principios del Diseño Web Adaptable. Adicionalmente, sus aplicaciones se pueden ejecutar 

en dispositivos que utilizan los sistemas operativos iOS y Android. Con esta herramienta es posible 

incorporar videos en los mapas web, así como crear mapas animados (García, 2017). 

Las características de Leaflet mencionadas anteriormente, son las que le han valido su posición de 

líder de las bibliotecas de JavaScript de código abierto para la creación de mapas interactivos aptos 

para dispositivos móviles. Entre sus principales usuarios se pueden mencionar las plataformas Flickr, 

Foursquare, Craigslist, IGN, Wikipedia, The Washington Post, OpenStreetMap y Pinterest (García, 

2017). De ellos, es importante destacar a OpenStreetMap. 

La plataforma OpenStreetMap (OSM) se utiliza a menudo junto con Leaflet. Se trata de un proyecto 

de datos abiertos para crear y proveer gratuitamente mapas e información geoespacial, para lo que 



31 

 

 

cuenta con el apoyo de una comunidad compuesta por más de dos millones de colaboradores bajo 

la figura de la OpenStreetMap Foundation (OSMF), una organización internacional sin fines de lucro. 

OSM originalmente inició, como su nombre lo indica, con información de calles, para luego 

incorporar senderos, edificios, cuerpos de agua, bosques, playas e incluso árboles individuales y 

todo tipo de puntos de referencia a lo largo del mundo. El proyecto también incluye información 

abstracta o que no forma parte del paisaje en sí mismo, como límites administrativos, detalles del 

uso del suelo, rutas de autobuses y tuberías