Propuesta para Trabajo de Gradopegasus.javeriana.edu.co/~CIS1410IS04/downloads/[01... · Web...

CIS1410IS04

FOXWAY: PROTOTIPO PARA VISUALIZAR DATOS HISTÓRICOS DEL TRÁFICO

DE BOGOTÁ

SERGIO DAVID ZORRO SÁNCHEZ

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERIA

CARRERA DE INGENIERIA DE SISTEMAS

Ingeniería de Sistemas Istar – CIS1410IS04

BOGOTÁ, D.C.

2015

Página 2

Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación práctica

CIS1410IS04

FOXWAY: PROTOTIPO PARA VISUALIZAR DATOS HISTÓRICOS

DEL TRÁFICO DE BOGOTÁ

Autor:

Sergio David Zorro Sánchez

MEMORIA DEL TRABAJO DE GRADO REALIZADO PARA CUMPLIR UNO

DE LOS REQUISITOS PARA OPTAR AL TITULO DE INGENIERO DE

SISTEMAS

Director

Ing. Javier Francisco López Parra

Jurados del Trabajo de Grado

Ing. Julio Carreño

Ing. Diego Casas

Página web del Trabajo de Grado

http://pegasus.javeriana.edu.co/~CIS1410IS04




BOGOTÁ, D.C.

Mayo 2015

Página i

Preparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008





Rector Magnífico

Jorge Humberto Peláez Piedrahita, S.J.

Decano Facultad de Ingeniería

Ingeniero Jorge Luis Sánchez Téllez

Director de la Carrera de Ingeniería de Sistemas

Ingeniero Germán Alberto Chavarro Flórez

Director Departamento de Ingeniería de Sistemas

Ingeniero Rafael Andrés González Rivera

Página ii


Página iii



Artículo 23 de la Resolución No. 1 de Junio de 1946

“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus

proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral

católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que

se vean en ellos el anhelo de buscar la verdad y la Justicia”

Página iv


AGRADECIMIENTOS

El agradecimiento más grande sea para Dios que me ha dado las oportunidades más impor -

tantes para poder llevar a cabo mis sueños y poder seguir construyendo mi proyecto de vida, a

mis padres por su infinito apoyo y que es a través de ellos que estas oportunidades se han ido

materializando.

También siento una gran deuda de gratitud con mi hermano y mis amigos, que en muchas

ocasiones sus ayudas me han permitido poder llegar hasta este nivel en mis estudios profesio-

nales.

En fin, gracias a todos aquellos que sinceramente y de corazón han regalado su tiempo y de-

dicación a lograr que se cumplan estas metas y que sé que podré contar con ellos mucho años

más.

Del fondo del corazón les agradezco por su apoyo y entendimiento durante todos estos años.

Página v



CONTENIDO

CONTENIDO.............................................................................................................VI

INTRODUCCIÓN.......................................................................................................1

I - DESCRIPCIÓN GENERAL..................................................................................2

1. OPORTUNIDAD, PROBLEMÁTICA, ANTECEDENTES............................................2

1.1. Formulación del problema a resolver......................................................................3

1.2. Justificación del problema........................................................................................3

1.3. Impacto Esperado.....................................................................................................4

2. DESCRIPCIÓN DEL PROYECTO............................................................................5

2.1. Objetivo general........................................................................................................5

2.2. Objetivos específicos.................................................................................................5

3. METODOLOGÍA...................................................................................................5

3.1 Fases Metodológicas.....................................................................................................6

3.2 Método que se propuso para satisfacer cada fase metodológica..................................7

II – MARCO TEÓRICO.............................................................................................9

1. MARCO CONTEXTUAL........................................................................................9

1.1 Experiencia 1:................................................................................................................9

1.2 Experiencia 2:..............................................................................................................10

1.3 Experiencia 3:..............................................................................................................11

1.4 Experiencia 4:..............................................................................................................12

2. MARCO CONCEPTUAL......................................................................................14

2.1 Sistemas de Información Geográfica......................................................................14

2.2 Modelos de Tráfico vehicular......................................................................................19

2.3 Representación de Datos Espaciales......................................................................21

III – ANÁLISIS..........................................................................................................24

Página vi


1. ANÁLISIS DE REQUERIMIENTOS DEL SISTEMA..................................................25

1.1 Variables.................................................................................................................25

1.2 Levantamiento de Requerimientos..........................................................................26

1.3 Priorización de Requerimientos.............................................................................28

1.4 Entorno de funcionamiento.....................................................................................30

1.5 Restricciones del Prototipo.....................................................................................30

1.6 Análisis de herramientas disponibles.....................................................................31

2. ANÁLISIS DE LOS DATOS DE ENTRADA.............................................................33

2.1 Tipos de documentos...............................................................................................33

2.2 Formato de documentos..........................................................................................34

2.3 Datos de interés......................................................................................................36

IV – DISEÑO..............................................................................................................38

1. METODOLOGÍA DE DESARROLLO......................................................................38

1.1 La metodología.......................................................................................................38

1.2 Actividades..............................................................................................................39

1.3 Hitos........................................................................................................................39

2. MODELO DE DOMINIO......................................................................................40

3. CASOS DE USO.................................................................................................42

4. DISTRIBUCIÓN DE LOS REQUERIMIENTOS SEGÚN CASOS DE USO....................43

4.1 Iniciar aplicación.........................................................................................................43

4.2 Interactuar con el mapa...............................................................................................43

4.3 Seleccionar y cargar archivo.......................................................................................43

4.4 Visualizar información.................................................................................................43

4.5 Refrescar mapa............................................................................................................43

4.6 Cerrar aplicación.........................................................................................................44

4.7 Desplegar ventana principal........................................................................................44

4.8 Actualizar mapa...........................................................................................................44

4.9 Leer archivo.................................................................................................................44

Página vii



4.10 Desplegar información..............................................................................................44

4.11 Cargar datos velocidades..........................................................................................44

4.12 Cargar datos volúmenes............................................................................................45

5. ARQUITECTURA DEL DISEÑO............................................................................45

6. VISTA DE COMPONENTES..................................................................................46

7. VISTA DE DESPLIEGUE......................................................................................46

8. DIAGRAMAS DE SECUENCIA.............................................................................47

8.1 Cargar información velocidades.................................................................................48

8.2 Cargar información volúmenes...................................................................................49

8.3 Refrescar mapa............................................................................................................50

9. INTERFAZ DE USUARIO.....................................................................................50

9.1 Vistas.......................................................................................................................50

9.2 Grafo de navegabilidad..........................................................................................54

V – DESARROLLO DE LA SOLUCIÓN...............................................................55

1. DESCRIPCIÓN DE LAS PRINCIPALES FUNCIONALIDADES DEL PROTOTIPO Y SU

COMPORTAMIENTO.......................................................................................................55

2.1 El mapa y su comportamiento......................................................................................55

2.2 Funcionalidad de carga de archivos al sistema..........................................................56

2.3 Visualización de la arquitectura interna del prototipo................................................59

2. INTERFAZ GRÁFICA DE INTERACCIÓN CON EL USUARIO...................................60

3. HERRAMIENTAS ADICIONALES.........................................................................63

3.1 Herramienta de lectura de archivos............................................................................63

3.2 Herramienta para repositorio de código.....................................................................63

4. PLAN DE PRUEBAS............................................................................................64

4.1 Carga de información de los archivos.........................................................................64

4.2 Visualización histórica de los datos............................................................................66

Página viii


VI – RESULTADOS..................................................................................................67

1. VISTA FINAL DE UNA EJECUCIÓN SIMPLE DEL PROTOTIPO...............................67

2. EJECUCIÓN DEL PLAN DE PRUEBAS..................................................................67

3. ANÁLISIS DE RESULTADOS...............................................................................69

VII – CONCLUSIONES............................................................................................74

1. ANÁLISIS DE IMPACTO DEL DESARROLLO.......................................................74

2. CONCLUSIONES Y TRABAJO FUTURO...............................................................74

VIII – REFERENCIAS Y BIBLIOGRAFÍA..........................................................76

IV - ANEXOS.............................................................................................................80

Página ix



ABSTRACT

Through the development of a software prototype that allows the visualization of traffic data

from the city of Bogota, a knowledge base can be obtained that supports the decision making

processes. The traffic data study and analysis obtained through the years must be used as a

knowledge base to the decision making processes for the present and future. Through the

analysis of the documents and the development of the prototype, a concept of SIG tool was

developed allowing easy traffic data access and easy information interpretation.

Página x


RESUMEN

A través del desarrollo de un prototipo de software que permita visualizar la información del

tráfico de la ciudad de Bogotá, se puede generar una base de información que apoye los pro-

cesos de toma de decisiones. El estudio y el análisis del tráfico de años atrás deben ser usados

como base de conocimientos para poder ejercer decisiones para el presente y el futuro. Me-

diante el análisis de los documentos y el desarrollo del prototipo se logra generar un concepto

de herramienta SIG que permite una fácil interpretación y acceso a los documentos del tráfi-

co.

Página xi


Pontificia Universidad Javeriana Memoria de Trabajo de Grado - Aplicación práctica

INTRODUCCIÓN

Los sistemas de información geográfica (o SIG’s) son herramientas muy útiles que permiten

realizar análisis exhaustivos de territorios en diversos ámbitos. Las tecnologías de los SIG’s

pueden ser utilizadas para el desarrollo de investigaciones científicas, la gestión de recursos,

la investigación arqueológica, el análisis de impacto ambiental, para la planificación urbana,

en cartografía, y en temas relacionados al marketing o logística, solo mencionando unos po-

cos.

En el presente Trabajo de Grado se buscó crear un prototipo de herramienta SIG que permita

mejorar la toma de decisiones relacionadas con el tráfico y la movilidad de la ciudad de Bo -

gotá. Para lograr este objetivo, el prototipo se alimenta a través de unos documentos de la

Secretaria de Movilidad de la ciudad de Bogotá que contienen información de velocidades y

volúmenes de tráfico de años anteriores que se encuentran guardados y almacenados en los

servidores de esta entidad. Estos documentos se encuentran con distintos formatos de nom-

bres y almacenados a través de un alto número de carpetas que dificultan un fácil acceso,

además los documentos poseen un gran número de datos y hojas con información técnica, lo

que los convierte en documentos de difícil lectura y entendimiento.

El desarrollo de esta Memoria comprende el análisis del contexto actual sobre estudios acerca

del monitoreo del tráfico y los beneficios que se obtienen al analizar los datos de los recorri -

dos de los vehículos en las vías. También se presenta un marco conceptual en donde se des-

criben las temáticas tratadas a lo largo del presente trabajo. Posteriormente se presenta el

análisis, levantamiento de los requerimientos y el diseño que conducen al desarrollo del pro-

totipo solución que se propone.

Este Trabajo de Grado se encuentra bajo la modalidad de Aplicación Práctica, por lo cual se

encuentra también una sección de pruebas, un capítulo de los resultados del prototipo obteni-

do y sus respectivos análisis.

Página 1



Para finalizar el documento se encuentran las conclusiones de este Trabajo de Grado, el análi-

sis del impacto del desarrollo y también unas recomendaciones acerca de trabajos futuros que

permitan el desarrollo posterior de este trabajo, sus ideas y del prototipo entregado.

Página 2


I - DESCRIPCIÓN GENERAL

1. Oportunidad, Problemática, Antecedentes

Un problema que se encuentra en las grandes y medianas urbes del mundo es el tráfico vehi -

cular. En las últimas décadas las ciudades han incrementado su número de pobladores de

forma considerable, y la expansión hacia arriba y hacia la periferia de las ciudades es inevita-

ble. El crecimiento vertical de una ciudad trae grandes consecuencias consigo, como la sobre-

carga de la red del acueducto, de la red eléctrica y una mayor demanda de los sistemas de

transporte. En una ciudad el costo de las adecuaciones para el mejoramiento de los servicios

es bastante alto, y en temas como el transporte los medios no suelen ser suficientes para reali-

zar ampliaciones o las adecuaciones necesarias para la infraestructura.

Un agravante de esta situación es el aumento del parque automotor (vehículos particulares y

de servicio público) que se genera para poder suplir la demanda en la necesidad de transporte

de los habitantes, y sumado a la falta de espacio en las vías, los atascamientos (trancones) son

inevitables (Thomson, 1978).

Varias medidas se han intentado tomar desde puntos políticos y sociales, medidas como el

“pico y placa” (Posada Henao, Farbiarz Castro, & González Calderon, 2011) y como incenti-

var el conocido “carpooling” estadounidense (compartir el carro con amigos, familiares,

conocidos y/o compañeros que compartan un mismo o similar trayecto) (Teal, 1987) para

poder incidir positivamente en el tráfico. Sin embargo estas medidas han demostrado ser in-

suficientes. Los desarrolladores tecnológicos no se han quedado atrás en intentar proveer una

ayuda, varias herramientas como Google Maps y Waze proveen información a los usuarios de

dispositivos móviles para que ellos puedan planear sus rutas de forma que puedan minimizar

el tiempo de recorrido. Estas herramientas ayudan grandemente debido a que reportan en

tiempo real el tráfico por donde están otros usuarios de los mismos servicios (Rodrigue,

2013).

Página 3



Con un tráfico caótico en sí, las empresas de transporte y mensajería sufren grandemente para

evitar ser afectados en sus servicios y evitar pérdidas, por eso una planeación anticipada de

las rutas de entrega es de vital importancia para ellos. De la misma forma, para las entidades

del estado y para empresas de construcción poder saber cómo una intervención, como una

construcción o adecuación sobre las vías de la ciudad, puede afectar el tráfico o en qué mo-

mento es más propicio hacer un cerramiento o desvío. Para poder llevar esto acabo se necesi-

taría saber cómo será el tráfico en esos momentos futuros o por lo menos conocer una condi-

ción aproximada de este a través de información pasada de estos lugares para así analizar su

posible comportamiento futuro.

Pero para poder llegar al nivel de analizar estos comportamientos, antes necesitamos un siste-

ma que nos permita visualizar la información ya existente del pasado de la movilidad y así

poder entenderla con mayor facilidad para después utilizarla como medio principal de análisis

y mediciones.

1.1. Formulación del problema a resolver

¿Se puede construir una aplicación de software que permita visualizar la información

histórica del tráfico de la ciudad de Bogotá?

1.2. Justificación del problema

Los problemas de movilidad son de crucial importancia para una ciudad, sin facilidad de

movilización los ciudadanos no pueden ejercer sus labores diarias, como ir a trabajar, ir

al colegio, ir a las universidades, realizar encomiendas, hacer mercado, pedir un domici -

lio, etc. Por lo tanto podemos ver como esta situación pasa de ser un inconveniente coti-

diano a un problema social que abarca toda la ciudad.

Un sistema de análisis de tráfico permite visualizar un posible escenario de cómo se va a

comportar el tráfico en un día dado y en un rango de horas del día, pero un sistema de

análisis de tráfico no solo puede ayudar a las planeaciones a futuro, sino que también es

una posible herramienta para generar escenarios para la revisión de nuevas políticas de

movilidad y su impacto. También es capaz de ayudar a reportar cambios importantes

Página 4


detectados en el comportamiento del tráfico que puede ser de relevancia a las autorida-

des.

Entre otras ideas, se podría considerar un sistema que permita visualizar la información

histórica del tráfico de la ciudad, como el inicio de un sistema más grande que permita

llegar a modelos de predicción aplicables, simulaciones, la creación de una base de datos

en constante expansión y hasta llegar a monitorear el tráfico desde distintos medios auto-

matizados. Esto generaría una mejora significativa en la ciudad, la gestión de la movili-

dad en la ciudad tomaría otra forma; reduciría los tiempos de desplazamiento, el costo

del transporte y también reduce las emisiones de gases producidas por los vehículos,

generando un bienestar general para toda la ciudadanía. (Navarro Hudiel, 2008)

El problema a resolver en este trabajo de grado se orienta a proponer una forma distinta

de gestionar los datos históricos existentes sobre la movilidad de la ciudad de Bogotá,

dado actualmente se administran a través de archivos planos, y hojas de cálculo, que

dificultan la visualización en un sistema georreferenciado.

1.3. Impacto Esperado

Con el sistema propuesto se espera:

Observar con mayor facilidad la información histórica del tráfico de la ciudad de

Bogotá.

A través del uso de herramientas de SIG, desarrollar un prototipo que permita la

visualización de la información histórica del tráfico de la ciudad de Bogotá.

Dejar propuesto un formato más adecuado para la carga de información al siste-

ma.

2. Descripción del Proyecto

Generar un sistema que permita mostrar los datos históricos del tráfico (Volumen y velocida-

des) de la ciudad de Bogotá y desplegarlos sobre un mapa de la ciudad.

Página 5



2.1. Objetivo general

Construir un prototipo que permita visualizar los datos históricos del tráfico de Bogotá y des-

plegarlos utilizando servicios de mapas web.

2.2. Objetivos específicos

El trabajo se dividió en la consecución de 5 objetivos específicos que serán realizados se-

cuencialmente y a través de varias fases metodológicas que se describirán a continuación. Los

objetivos específicos son:

Realizar estudio exploratorio sobre experiencias similares exitosas a nivel internacio-

nal y sobre conceptos fundamentales necesarios para desarrollar el Trabajo de Grado.

Analizar principales elementos del prototipo e identificar requerimientos.

Diseñar una propuesta arquitectural de la aplicación.

Implementar el prototipo para mostrar y visualizar datos históricos.

Validar el prototipo en un caso de estudio en un sector de Bogotá.

3. Metodología

Estos objetivos específicos se verán alcanzados mediante la resolución de varias fases meto-

dológicas.

3.1 Fases Metodológicas

Fase Metodológica 1

En esta primera fase se realizará la investigación preliminar que nos permitirá encontrar el

marco contextual y el marco teórico real que se usará en el Trabajo de Grado. La metodología

propuesta para esta fase es:

Se utilizará una metodología analítica (Ruiz Limón, 2006) para poder identificar los

componentes o partes que harán parte del trabajo, de esta forma se relacionarán estos

componentes con sus finalidades.

Página 6



En esta fase se analiza los principales elementos del prototipo y comienza el análisis de re -

querimientos para el desarrollo. La metodología propuesta para esta fase es:

El procedimiento a realizar será analizar los resultados de la fase anterior para poder

desarrollar los objetivos.


En esta fase se diseñará una propuesta arquitectural para la implementación del prototipo. La

metodología propuesta para esta fase es:

Se realizarán diagramas mostrando el comportamiento, la funcionalidad y la arquitec-

tura del prototipo.


En esta fase se realizará la implementación del prototipo. Para el desarrollo se usará una me-

todología RUP o Proceso Unificado de Rational (IBM, 2001). Se elige esta metodología ya

que es adaptable al contexto del proyecto y a sus necesidades. La metodología propuesta para

esta fase es:

Inicio

o Comprensión del problema y la tecnología, delimitación del proyecto y esta-

blecer la línea base de la arquitectura.

Elaboración

o Continuación de la fase de inicio pero enfocado en el desarrollo de la línea

base de la arquitectura, análisis y diseño del modelo de negocio y una parte

de la implementación.

Construcción

o Construcción de la aplicación de software por medio de iteraciones.

Transición

o Garantizar que se tiene un producto preparado para su entrega.

Página 7




En esta última fase se probará el prototipo en un ambiente de uso en el mundo real. La meto-

dología propuesta para esta fase es:

Se diseñará un caso de prueba para probar el prototipo en un ambiente de uso real y

se registrarán los resultados.

3.2 Método que se propuso para satisfacer cada fase metodológica

En cada fase metodológica se encuentran actividades e hitos que deben ser realizados para

garantizar el cumplimiento de cada fase metodológica.


Actividades - En esta fase, la investigación se verá reflejada en la creación de dos

marcos para el trabajo, estos son:

o Marco contextual

o Marco teórico

Hitos - Esta fase termina con el cumplimiento del primer objetivo específico:

o Realizar estudio exploratorio sobre experiencias similares exitosas a nivel

internacional y sobre conceptos fundamentales necesarios para desarrollar el

Trabajo de Grado.


Actividades - La actividad a realizar será

o Levantamiento de requerimientos, plantilla SRS.

Hitos - Esta fase termina con el cumplimiento del segundo objetivo específico:

o Analizar principales elementos del prototipo e identificar requerimientos.

Página 8



Actividades - La actividad a realizar será:

o La creación del documento SDD para el prototipo.

Hitos – Esta fase termina con el cumplimiento del tercer objetivo específico:

o Diseñar una propuesta arquitectural de la aplicación:


Actividades - Las actividades que se realizarán en esta fase serán las mismas iteracio-

nes que requiere la construcción del prototipo:

o Primera iteración: Comprensión del problema en medios tecnológicos e

inicio del modelado del negocio. Se utiliza una abstracción de los requeri-

mientos y del diseño propuesto del prototipo como guía.

o Segunda iteración: Aplicación de la base del diseño arquitectural propuesto

y garantizar los principales requerimientos.

o Tercera iteración: En esta iteración se concentra el desarrollo de la lógica

de negocios y pruebas iniciales.

o Cuarta iteración: Esta iteración se centra en el desarrollo de pruebas a la

lógica de negocio del prototipo y en corregir comportamientos inesperados

y/o erróneos.

Hitos - Las actividades finalizan con el cumplimiento del cuarto objetivo específico:

o Implementar un prototipo para mostrar y visualizar datos históricos.


Actividades - Las actividades a realizar serán:

o Definir sitio, zona o alcance de la prueba.

o Establecer parámetros de la prueba y resultados esperados.

o Aplicación de la prueba y análisis de resultados.

Hitos – Las actividades finalizan con el cumplimiento del quinto objetivo específico:

o Validar el prototipo en un caso de estudio en un sector de Bogotá.

Página 9



II – MARCO TEÓRICO

1. Marco Contextual

A continuación se presentarán 4 experiencias a nivel internacional que tratan los temas de

monitoreo de tráfico, formas o métodos de recolección de información y discusiones acerca

de nuevas aproximaciones para mejorar y descubrir más campos de acción en esta área.

1.1 Experiencia 1:

Evaluation of traffic data obtained via GPS-enabled mobile phones: The Mobile Century field experiment

En el año 2010, el centro de investigación de Nokia en Palo Alto, Estados Unidos y la Uni-

versidad de Berkeley realizaron un experimento de campo llamado Mobile Century (Juan C.

Herrera, 2010) – en español Siglo Móvil – que fue resultado de buscar probar el concepto y la

idea del siguiente sistema. Se ha propuesto utilizar los dispositivos electrónicos a bordo de

los vehículos como una infraestructura alternativa para poder monitorear el tráfico, dado que

estos dispositivos se ofrecen como un método de bajo costo y muy eficientes para recoger

información del tráfico, aprovechando el gran cubrimiento que ya ofrecen las infraestructuras

de comunicaciones como la red de dispositivos celulares. Un sistema de monitoreo de tráfico

basado en teléfonos inteligentes (también conocidos como smartphones) con GPS (Global

Positioning System – Sistema de Posicionamiento Global) permite hacer uso del gran cubri-

miento de las redes celulares, de la alta exactitud y medidas de velocidad provistas por los

dispositivos con GPS, y la infraestructura existente de las redes de comunicación.

Siglo Móvil utilizó 100 vehículos, cada uno con un Nokia N95 con GPS habilitado, recorrien-

do un trayecto circular con una longitud de 16 kilómetros por la autopista interestatal I-880

cerca de Union City en California, Estados Unidos, por un periodo de 8 horas. La informa-

ción fue recogida usando marcadores geográficos virtuales ubicados en zonas específicas del

Página 10


recorrido (Virtual Trip Lines) que permiten al dispositivo enviar la información de su ubica-

ción y su velocidad actual cuando este pasa por él. El sistema prototipo presentado suministró

suficiente información para poder monitorear el estado del tráfico mientras que mantuvo la

privacidad de los participantes. La información obtenida durante el experimento fue procesa-

da en tiempo real y fue publicada en internet exitosamente, logrando demostrar la fiabilidad

del sistema para el monitoreo del tráfico en tiempo real. Con los resultados obtenidos se logró

determinar que solo se necesita una penetración del 2 al 3% entre la población de los conduc-

tores para proveer medidas precisas de velocidad del flujo de vehículos.

(Juan C. Herrera, 2010)

1.2 Experiencia 2:

Selective data collection in vehicle networks for traffic control applications

En este trabajo, realizado en agosto del 2012, el autor introduce un método de recolección de

datos selectivo para aplicaciones de control de tráfico, lo cual provee una significativa reduc-

ción en cantidad de datos transmitidos por redes VANET’s (Vehicular Ad hoc Networks). La

red de sensores vehiculares (VSN por sus siglas en inglés) es una tecnología emergente, que

combina comunicaciones inalámbricas por medio de las redes vehiculares VANET’s median-

te dispositivos especiales instalados en los vehículos. Estas redes generan una gran oportuni-

dad de extender la infraestructura de sensores a lo largo de las vías de los actuales sistemas de

control de tráfico. El uso eficiente de este medio de comunicación inalámbrica es uno de los

principales problemas en el desarrollo de aplicaciones que usan VSN. La idea es poder detec-

tar la necesidad de transferir datos basados en la incertidumbre en la determinación de deci -

siones en el control de tráfico. De acuerdo a este acercamiento, los datos del sensor son trans -

mitidos de los vehículos al nodo de control solo en momentos precisos. Los datos recogidos

mediante la red VSN son procesados usando una técnica simulación en línea, que permite

predecir el flujo del tráfico, evaluación de medidas de control y la estimación de la incerti -

Página 11



dumbre. Si la precisión de la información resultante es insuficiente, la acción de control ópti-

mo no puede llevarse a cabo sin generar ambigüedad. Como resultado la decisión de control

se vuelve incierta y esta representa una señal que informa que es necesaria nueva información

del tráfico desde la red VSN para proveer predicciones más precisas y para reducir la incerti -

dumbre de las decisiones de control. El método propuesto puede ser aplicado en sistemas de

control de tráfico de diferentes tipos, con señales de tránsito, límites de velocidad variable, y

con rutas de guía dinámica. La efectividad de este método es ilustrada en un caso de estudio

experimental de control de tráfico en una intersección señalizada.

(Płaczek, 2012)

1.3 Experiencia 3:

On the applicability of fair and adaptive data dissemination in traffic information systems

En este trabajo, realizado en febrero del 2014, se propone un protocolo de diseminación de

datos para las redes VANET’s, para que distribuya la utilidad de los datos de forma justa a

los vehículos mientras se controla la carga sobre la red de forma adaptativa. El protocolo

depende únicamente de información local para asegurar justicia con conceptos de Negocia-

ción de Nash de la teoría de juegos. Se espera que las redes vehiculares VANET’s sirvan

como un soporte para el desarrollo de aplicaciones de seguridad y también de aplicaciones

ricas en información que puedan diseminar o esparcir datos a los vehículos. Debido a la con-

tinua recolección, procesamiento y diseminación de datos, un requerimiento muy importante

es el uso eficiente del ancho de banda disponible. Primeramente, la tasa de transmisión de

mensajes debe ser controlada de forma tal que permita controlar la cantidad de datos inserta-

dos en la red. Segundo, los mensajes deben ser cuidadosamente seleccionados para maximi-

zar la utilidad/beneficio para los vehículos del sector. Se debate acerca de que la selección de

mensajes debe fijar como objetivo la justa distribución de la utilidad de los datos, dado que se

puede generar la posibilidad que ocurra conflicto de interés de datos entre vehículos.

Página 12


Se muestra la aplicabilidad del protocolo con dos ejemplos de utilidad en dos tipos de aplica-

ciones de sistemas de información de tráfico:

1. Estacionamiento de vehículos

2. Aplicaciones de información de tráfico

El protocolo es validado con experiencias tanto del mundo real como de simulaciones de

grandes redes reales. Los resultados demuestran que con el protocolo se alcanzan mayores

grados de justicia y logra mantener un alto nivel de eficiencia en la utilización del ancho de

banda en comparación con otras teorías.

(Ramon S. Schwartza, 2014)

1.4 Experiencia 4:

Adaptive fast computation on a road network: a traffic mining approach

Este trabajo realizado en la Universidad de Illinois, en Urbana-Champaign (Illinois, Estados

Unidos) en el año 2007 muestra el uso de un algoritmo adaptativo de búsqueda de ruta óptima

capaz de consultar patrones de velocidad y conducción conseguidos a través de un proceso de

minería de un gran conjunto de datos. El algoritmo se basó en las siguientes observaciones:

La jerarquía de las carreteras puede ser usada para dividir la red de carreteras en

áreas, además que se pueden usar diferentes estrategias pre-computacionales para la

búsqueda de ruta óptima en ese nivel de área.

Se puede limitar la estrategia de búsqueda a vértices y segmentos de ruta que son

realmente frecuentes en los datos de viajes.

Los conductores suelen atravesar la red de carreteras a través de la vía más larga

disponible dependiendo de la distancia del recorrido, a excepción de cuando se en-

cuentra con una ruta con vías pequeñas que ofrezcan una ventaja notable en veloci-

dad sobre las vías largas.

Página 13



A través de una larga experimentación en redes de carreteras reales lograron demostrar que su

algoritmo logra proveer rutas deseables (cortas y sustentadas), y que es significativamente

más rápido que otros métodos. Este trabajo se basó en la idea en que “La historia es el mejor

maestro”.

(Gonzalez, Han, Li, Myslinska, & Sondag, 2007)

En esta sección y con la comprensión de estas experiencias podemos llegar a entender que

aún existen muchas áreas y temas que descubrir y desarrollar alrededor de estas tecnologías.

Se ha podido ver como unas implementaciones tecnológicas de recopilación de información

geográfica pueden tener un gran impacto en la sociedad y de producir un bien general. Al

mismo tiempo podemos entender el porqué es importante seguir investigando y desarrollando

en estas temática, estos estudios podrían llevarnos al descubrimiento de nuevas tecnologías y

encontrar nuevos servicios que ofrecer.

2. Marco Conceptual

En esta sección encontraremos los conceptos necesarios para poder entender el trabajo que se

mostrará en el documento. Los conceptos que se encuentran rodean la temática de la determi-

nación de la ubicación a través de dispositivos móviles y las redes celulares, al igual que los

conocimientos necesarios para entender estas tecnologías.

2.1Sistemas de Información Geográfica

Un Sistema de Información Geográfica (SIG) es una colección de herramientas y datos refe-

renciados espacialmente, lo que significa que los datos traen incorporados información de

sitios y lugares relevantes (Reynolds, 1997) (Longley, Goodchild, Maguire, & Rhind, 2005).

Las herramientas utilizadas integran y relacionan varios componentes que permiten la organi-

zación, almacenamiento, manejo, análisis y el modelado de una gran cantidad de datos prove-

nientes del mundo real encadenados a una referencia espacial. De esta forma se logran incor-

Página 14


porar temáticas de las ciencias sociales, económicas, ambientales, agricultura entre otros para

poder ser trabajados y generar nuevos campos de acción donde las ciencias de la información

proporcionan nuevas ayudas (Kresse & Danko, 2012) (Longley, Goodchild, Maguire, &

Rhind, 2005).

La inclusión de información de sitios y lugares en los datos ha demostrado ser de gran utili-

dad para el desarrollo de las áreas en las cuales son aplicadas. Por ejemplo, los SIG’s han

demostrado ser de gran utilidad en la resolución de los siguientes problemas básicos:

Cómo los administradores en el área de la salud han resuelto problemas geográficos

cuando deciden en donde ubicar nuevas clínicas y hospitales.

Compañías de transporte han resuelto problemas geográficos cuando deciden qué

rutas tomar y los horarios en los que Mandan a sus camiones.

Las autoridades de tránsito y transporte resuelven problemas geográficos cuando

seleccionan las rutas para crear nuevas autopistas.

Consultores geo-demográficos solucionan problemas geográficos cuando asesoran y

recomiendan las mejores ubicaciones para abrir nuevas tiendas.

Compañías de reforestación resuelven problemas geográficos cuando deciden en que

sitios deben cortar o sembrar árboles y en dónde se pueden ubicar vías.

Las autoridades de ambiente resuelven problemas geográficos cuando agendan man-

tenimiento y nuevas obras a los senderos recreacionales en los parques públicos.

El gobierno resuelve problemas geográficos cuando deciden en qué sitios colocar

diques para evitar inundaciones

Los viajeros y turistas resuelven problemas geográficos cuando dan y reciben direc-

ciones, buscan y seleccionan hoteles en ciudades desconocidas, y también cuando

encuentran rutas y navegan en parques temáticos.

Los agricultores resuelven problemas geográficos cuando utilizan nuevas tecnologías

de la información para tomar mejores decisiones acerca de las cantidades de fertili-

zantes y pesticidas a aplicar en las distintas zonas de sus cultivos.

Estos son solo unos ejemplos acerca de cómo los Sistemas de Información Geográficos per-

miten mejorar los aspectos de la vida de las personas y el cómo son usados estos datos a tra-

Página 15



vés de herramientas para generar soluciones inteligentes y precisas a las necesidades de las

personas (Longley, Goodchild, Maguire, & Rhind, 2005).

2.1.1 Geo-referenciación

La geo-referenciación se refiere al posicionamiento con el que se define la localización de un

objeto espacial (representado por puntos, vectores, área, volumen) en un sistema de coordena-

das definido como en entidades cartográficas (Longley, Goodchild, Maguire, & Rhind, 2005)

(Kresse & Danko, 2012). Todos los elementos de una capa de mapa tienen una ubicación

geográfica y una extensión específica que permiten situarlos en la superficie de la Tierra o

cerca de ella. La geo-referenciación es utilizada frecuentemente en los Sistemas de Informa-

ción Geográfica (SIG) dado que es fundamental para la representación cartográfica. (ArcGis

Resources, s.f.)

Para la correcta descripción, para la ubicación y representación de entidades espaciales re -

quiere un marco para definir las ubicaciones en el mundo real. Para esto se utiliza un sistema

de coordenadas geográficas, este sistema consta de coordenadas en longitud y latitud global

como marco. Otro sistema de coordenadas utilizado es el de coordenadas cartesianas sobre un

plano global. (Reynolds, 1997)

Los mapas en general, representan visualmente ubicaciones de la superficie de la tierra que

utilizan cuadrículas y marcas de graduación con etiquetas de diversas ubicaciones terrestres.

Los elementos geográficos del mapa se ubican en un orden específico (uno encima del otro)

para la extensión del mapa. (ArcGis Resources, s.f.)

Los conjuntos de datos en SIG incluyen ubicaciones en coordenadas dentro de un sistema de

coordenadas cartesianas o globales (latitud y longitud) para registrar ubicaciones y formas

geográficas. De este modo es posible superponer capas de datos SIG sobre la superficie te-

rrestre. (ArcGis Resources, s.f.)

Página 16


2.1.2 Sistemas de navegación tradicionales

Los sistemas de navegación fueron creados con el propósito de ubicarnos a nosotros mismos

sobre el globo terráqueo, esto con el propósito de poder recorrer grandes distancias sin perder

el rumbo o el trayecto recorrido, especialmente sobre el océano. Sin estos métodos o siste-

mas, los movimientos de las personas se encontraban restringidos a un área determinada por

puntos fijos y la navegación marítima hasta el punto hasta donde aún se pudiera ver la costa.

(Catalonia ORG, s.f.)

Debido a la falta de tecnología en la antigüedad la navegación se basó en el conocimiento y la

observación de los puntos fijos (o estáticos) más grandes y visibles posibles: las estrellas

(antiguamente los astros). Utilizaban la estrella polar para ubicar el norte y a través de la me-

dición de los ángulos (trigonometría y geometría esférica) lograban ubicarse espacialmente en

el plano terrestre, además también utilizaron el sol y su posición para descifrar la hora del día.

(Catalonia ORG, s.f.). Debido a que el requerimiento de la precisión se vio cada vez más

necesario, encontramos lo que es el astrolabio. El astrolabio es un computador astronómico

creado para resolver problemas relacionados con el tiempo y el posicionamiento de las estre-

llas y el sol. (Astrolabs, 2010) (Catalonia ORG, s.f.). El astrolabio permitió la realización de

medidas mucho más precisas acerca de la altura de la estrellas, lo cual también mejoró consi-

derablemente la precisión en la ubicación. (Morrison).

A medida que avanzó el tiempo se empezaron a crear mecanismos que facilitaron tareas de

ubicación, entre ellos la brújula, que permitió saber con gran facilidad la ubicación del norte

de la tierra utilizando el campo magnético que esta genera (Bhatta, 2010) (Catalonia ORG,

s.f.). También apareció el cronómetro marino que permitió ser usado como un complemento

al astrolabio debido a que este solo lograba encontrar latitudes, pero gracias al cronómetro

marino se lograron ubicar longitudes.

Un poco más moderno podemos encontrar el desarrollo de dos tipos de sistemas de navega-

ción, el primero se llama sistemas inerciales. Este primer sistema se basa en el principio de la

inercia y en la relación entre la posición y las aceleraciones físicas existentes. Este tipo de

sistemas tienen la ventaja de que son independientes del exterior y no se pueden interferir

(Catalonia ORG, s.f.). El segundo tipo de sistema se llama sistemas de radiolocalización, este

Página 17



funciona a través de la intersección de unas ondas electromagnéticas que son transmitidas a

través de unas torres de comunicación de forma sincronizada. Aunque una desventaja de este

tipo de navegación es que se necesita saber las posiciones originales de las torres, y cuando

estas dos ondas se intersectan se conoce la ubicación terrestre del receptor (Bhatta, 2010)

(Catalonia ORG, s.f.).

2.1.3 Servicios web de localización

Un servicio web es una tecnología que mediante el uso de protocolos y estándares de comuni -

cación, permiten el intercambio de datos entre aplicaciones (Morales Machuca) (Schiller &

Voisard, 2004). Distintas aplicaciones basadas en distintos lenguajes y en distintas platafor-

mas son capaces de intercambiar datos e información a través de los servicios web en las

redes de computadores (Morales Machuca). En la implementación de servicios web podemos

encontrar distintos estándares:

WSPS (Web Service Protocol Stack): Conjunto de servicios y protocolos de los ser-

vicios web.

XML (Extensible Markup Language): Es el formato estándar de los datos que se van

a pasar.

SOAP (Simple Object Access Protocol): Protocolo de intercambio.

WSDL (Web Service Description Language): Interfaz pública para servicios web.

UDDI (Universal Description, Discovery and Integration): Protocolo utilizado para

publicar la información de servicios web.

WS-Security: Protocolo de seguridad que garantiza la autenticación de los solicitan-

tes del servicio y la confidencialidad de los mensajes enviados.

(Morales Machuca)

Los servicios web aportan interoperabilidad sobre distintos productos y aplicaciones de so-

ftware, independiente de la plataforma y de las propiedades en las que se encuentren (Morales

Machuca) (Schiller & Voisard, 2004). Facilitan el acceder a los servicios, ya que los protoco-

los se basan en texto, los estándares se usan en la mayoría de las plataformas y lenguajes de

programación, y se facilita la lectura y el entendimiento de los servicios ofrecidos. También

Página 18


provee un alto grado de integración entre distintos sistemas, elimina las limitaciones geográ-

ficas y permite aumentar los servicios que pueda proveer un sistema accediendo a otro siste-

ma. Entre sus desventajas tenemos que su rendimiento es bajo si comparamos los servicios

web con otros modelos de computación distribuida como RMI (Remote Method Invocation)

y CORBA (Common Object Request Broker Architecture), como su funcionamiento está

basado en XML, este lenguaje no está diseñado para optimizar rendimiento (Morales

Machuca). Tiene fallas en seguridad, como usa HTTP, este le permite saltarse o esquivar

medidas de seguridad basadas en firewall, ya que estas buscan regular y bloquear las comuni-

caciones entre programas, sean comunicaciones de entrada o de salida. (Morales Machuca)

La facilidad de los servicios web se basa en que utiliza HTTP sobre TCP (Transmission Con-

trol Protocol) en el puerto 80, que es lo mismo en lo que se encuentra basado la comunicación

de los navegadores (Morales Machuca) (Schiller & Voisard, 2004). Debido a que las organi-

zaciones restringen y bloquean la mayoría del tráfico de internet mediante firewall, y blo-

quean la mayoría de los puertos TCP a excepción del puerto 80 (Morales Machuca). Aunque

se utiliza el protocolo TCP, los servicios web se pueden utilizar sobre cualquier protocolo.

Los servicios web también proveen gran flexibilidad, su independencia entre sistemas permi-

te que aunque un sistema presente grandes cambios, el otro sistema no se ve afectado en su

funcionamiento, y aunque requiera cambios para volver a ofrecer ciertos servicios, estos cam-

bios son mínimos (Schiller & Voisard, 2004). La flexibilidad que otorgan los servicios web

es un gran atractivo para la creciente tendencia de construir grandes aplicaciones utilizando

componentes distribuidos pequeños de distintos sistemas. (Morales Machuca)

Un servicio web de localización es un servicio web que permite ubicar objetos, vehículos o

personas desde una página web utilizando tecnologías como GPS, GSM/GPRS (redes de

comunicación celular) y satélites, para controlar y monitorear en tiempo real a través de inter -

net. (Morales Machuca)

Página 19



2.2 Modelos de Tráfico vehicular

El tráfico en las vías puede ser de peatones, animales usados como medios de transporte,

vehículos de uso particular, vehículos de uso público y otros medios de transporte, puede que

sea uno solo de estos o de todos juntos usando las vías públicas con el propósito de desplazar-

se (Robles, Ñañez, & Quijano, 2009). Las leyes de tránsito son las normas que gobiernan el

tráfico y regulan los vehículos, y se utilizan para facilitar el flujo vehicular, logrando estable -

cerlo de forma ordenada y precisa (Kerner, 2004). El tráfico es organizado bajo varias juris-

dicciones, con carriles, uniones, intersecciones, intercambios, señales de tránsito y signos

(Kerner, 2004). El tráfico suele ser diferenciado por el tipo de vehículo o sus características,

vehículos pesados a motor (como buses y camiones), vehículos livianos a motor (como carros

particulares, taxis y motos), y peatones (como bicicletas y personas de a pie) (Robles, Ñañez,

& Quijano, 2009). Grupos similares suelen compartir restricciones como límites de velocidad

y zonas de tránsito específicas al vehículo.

2.2.1 Modelo de tráfico

Un modelo de tráfico se enfoca en entender las relaciones globales del flujo del tránsito,

como lo son la velocidad de los vehículos, el flujo vehicular y la densidad del tráfico. Los

modelos de tráfico son usados para explicar los distintos fenómenos del flujo vehicular, fenó-

menos como:

• Congestión vehicular

• Cruces de avenidas

• Uso de semáforos

• Accidentes de tránsito

(Rodriguez Niño & Ardila Díaz, 2002) (Robles, Ñañez, & Quijano, 2009)

Página 20


2.2.2 Modelos Macroscópicos

Un modelo macroscópico describe el comportamiento general de un fenómeno del mundo

(Rodriguez Niño & Ardila Díaz, 2002). Las variables que se estudian quedan en términos del

promedio analizado de un grupo muestra, por ejemplo, se observa que el promedio de veloci -

dad de los vehículos a cierta hora es de 20 km/h, no se detiene al observar que la velocidad de

cierto vehículo a esa hora fue 20 km/h. Podemos observar que para describir un modelo ma-

croscópico, debemos basarnos en los modelos microscópicos para poder hallar los valores

promedios de las variables (Rodriguez Niño & Ardila Díaz, 2002). Este modelo es apropiado

para ser usado en aplicaciones de gran escala donde el interés principal se encuentra relacio-

nado a las variables de flujo vehicular, su calibración y configuración puede realizarse de

forma simple utilizando sensores de bucle inductivo (hardware especializado) (Robles,

Ñañez, & Quijano, 2009).

2.2.3 Modelos Microscópicos

Los modelos microscópicos son usados para estudiar la relación entre el comportamiento

microscópico (objeto unitario) y un fenómeno macroscópico (comportamiento en grupo), este

modelo aplica para diferentes objetos microscópicos (como carros, animales, humanos), que

determinan el comportamiento de ciertos fenómenos macroscópicos, como por ejemplo el

comportamiento del tráfico vehicular, el comportamiento de una población basándose en el

comportamiento de sus individuos entre otras (Rodriguez Niño & Ardila Díaz, 2002). Este

enfoque presenta una aproximación más individual al observar a un vehículo de manera indi-

vidual a la infraestructura, este vehículo se convierte así en la variable de interés de este mo-

delo (Robles, Ñañez, & Quijano, 2009).

2.3 Representación de Datos Espaciales

A lo largo de la historia nos hemos podido dar cuenta de cómo los seres humanos somos ca-

paces de representar o de hacer representaciones acerca de lo que nos rodea, pero para cada

Página 21



representación se debe demostrar el por qué es útil hacerla o con qué sentido se crea una re-

presentación. Específicamente hablando, nuestra representación de interés es en términos

geográficos, esto es la representación de una parte de la tierra a una altura cercana a la super -

ficie en escalas más pequeñas pero manteniendo la proporcionalidad de los objetos o vistas

reales. Las representaciones geográficas son de las más antiguas, estas tienen sus raíces en las

necesidades de civilizaciones muy tempranas en la historia humana. Un ejemplo claro es el

éxito de la caza, un cazador o un grupo de cazadores pueden tener más éxito en sus recolectas

si entre ellos mismos pasan la información acerca de lo que han cazado, en dónde y con qué

facilidad.

Cuando se recolecta la información y se junta, se conforma una base de conocimientos y a

partir de estas bases de información podemos producir modelos de datos espaciales. Estos

modelos suelen ser usados en SIG para producir mapas, realizar consultas y diferentes análi-

sis. (Longley, Goodchild, Maguire, & Rhind, 2005)

2.3.1 La Problemática Fundamental de la Representación de Datos Espaciales

La información geográfica de elementos atómicos o hechos acerca del mundo geográfico, en

su forma más primitiva, un átomo de información geográfica une un lugar, un tiempo y una

propiedad descriptiva. En primera instancia, el lugar, es especificado en una de las distintas

formas que nos ofrece la georreferenciación. La segunda, el tiempo, también tiene varias

formas de especificarlo. A la tercera, la propiedad descriptiva, se le suele llamar atributo. El

rango de atributos en la información geográfica es muy amplio. Unos de estos atributos tie-

nen cambios muy rápidos, que se pueden observar en cuestión de días o de horas, otros tiene

cambios muy lentos que solo pueden ser observados a lo largo de años, décadas o hasta si -

glos. Algunos atributos son físicos o ambientales (de la naturaleza), mientras que otros son

sociales o económicos. Unos atributos simplemente identifican un lugar o una entidad, distin-

guiéndolo de otros lugares o entidades, otros atributos miden algo en una ubicación y dentro

de un rango de tiempo o en un tiempo en específico. Otros atributos sirven para diferenciar el

tipo de suelos o el tipo de uso que se le da a ciertos lugares.

Página 22


Pero la idea de recoger estos átomos de información geográfica combinando lugares, con

tiempos y sus atributos, falla en un problema fundamental, y es que el mundo es infinitamen-

te complejo, y el número de átomos requerido para una representación completa es similar al

infinito. Entre más cerca miramos al mundo, más detalles nos revela, y este proceso puede

extenderse casi que hasta el infinito. (Longley, Goodchild, Maguire, & Rhind, 2005)

2.3.2 Objetos Discretos y Campos Continuos

Con lo visto en anterioridad, podemos darnos cuenta la importancia que tiene para una repre-

sentación, definir el nivel de detalle que se va a manejar. Como humanos nos gusta simplifi -

car el mundo a nuestro alrededor, ya sea colocando nombres a las cosas o viendo objetos

individuales como instancias de categorías más grandes. Preferimos un mundo en blanco y

negro, que el mundo real en tonos de grises.

Hay dos formas fundamentales de representar la geografía: por objetos discretos y campos

continuos.

En la vista por objetos discretos, el mundo es vacío, excepto en donde se encuentren objetos

con límites bien definidos y que son instancias de categorías generalmente reconocidas.

En la vista de campos continuos, el mundo geográfico puede ser descrito por un número de

variables, cada una medible en cualquier punto de la superficie de la tierra, pero cambiantes

de valor a lo largo de la misma. (Longley, Goodchild, Maguire, & Rhind, 2005)

Es a través de todos estos elementos y consideraciones que podemos llegar a levantar una

representación gráfica de alguna problemática en particular utilizando datos o información

espacial.

Página 23



De acuerdo con las dos secciones anteriores de este trabajo (Marco conceptual y marco con -

textual), podemos observar el gran beneficio que las tecnologías modernas combinadas pue-

den ofrecer a problemas particulares y específicos relacionados a la vida cotidiana de las per -

sonas. Este trabajo propone crear un sistema de información geográfico que permita recoger y

visualizar la información del tráfico vehicular en la ciudad de Bogotá y que además permita,

a cualquier interesado en la información que pueda poseer este sistema, utilizarla para propó-

sitos de planeación, simulación, etc… con el fin de que las empresas y/o entidades guberna-

mentales puedan tener una mejor base de información con la cual puedan mejorar sus proce-

sos de toma de decisiones. De esta forma no solo se genera un bienestar privado (sea de enti-

dades públicas o privadas) sino también un bienestar general a la ciudadanía Bogotana al ver

un menor impacto en la movilidad por causa de obras y cerramientos, y también un posible

mejoramiento de la movilidad en general a causa de que los principales actores del tráfico,

están tomando sus decisiones con información precisa y útil proporcionada por el sistema.

III – ANÁLISIS

La propuesta de solución, involucra una serie de variables a considerar para hacer del sistema

una solución sostenible en el tiempo. En lo relacionado con los datos de entrada es necesario

tener en cuenta que actualmente existen una serie de procedimientos para la captura de los

datos. En general se obtienen datos relacionados con el tráfico; el volumen entendido como la

cantidad de vehículos que circulan por una vía en un instante de tiempo (volumen de tráfico)

y la velocidad promedio de su circulación. Estos elementos de estudio son variables para el

contexto del sistema: estas variables son velocidad y volumen, y se apoyan en otros datos

relevantes como la ubicación de la información y una franja horaria correspondiente, que

juntos permiten describir el comportamiento de un tramo en específico de las vías. En la figu-

ra No. 1 se puede apreciar un esquema generalizado de lo que sería el sistema prototipo.

Página 24


Figura No. 1 – Esquema general del prototipo

El sistema consiste en la capacidad de leer varios tipos de archivos, uno para velocidades y

otro para volúmenes. Los archivos que se cargan son seleccionados a través de una selección

de criterios por parte del usuario, estos son mes, año y tipo de dato de la información deseada.

Posee la capacidad de desplegar el mapa de la ciudad resaltando las calles y mostrar la infor-

mación existente en los archivos sobre los puntos de la ciudad correspondientes (interseccio-

nes) facilitando la búsqueda de información. Estos puntos se muestran como marcadores

sobre el mapa.

Página 25



1. Análisis de requerimientos del sistema

A continuación se muestra el proceso con el cual se levantaron los requerimientos, se priori-

zaron, y se calcula el entorno adecuado para la ejecución del sistema.

1.1 Variables

Para el desarrollo de este trabajo se tomaron como variables de interés la velocidad promedio

en la cual se desplazan los vehículos y el volumen de los vehículos que se desplazan en un

tramo específico.

1.1.1 Velocidad

La velocidad describe el desplazamiento de un objeto en un tiempo específico, es una magni-

tud física vectorial. En término del tráfico, la velocidad de un vehículo es medida en kilóme-

tro por hora o km/h, que describe la cantidad de kilómetro recorridos en 1 hora de tiempo

(Adolf D., 1990).

V=X (distancia )

t(tiempo )

V=km (kilómetros )

h(hora)

La velocidad promedio, o velocidad media, es la diferencia entre dos puntos de distancia

entre los que un objeto se desplaza dividido entre el tiempo en que el objeto se demoró en

pasar del primer al segundo punto. Para este trabajo, tomaremos la velocidad promedio como

la sumatoria de velocidades de un número de vehículos dividido por el número de vehículos

(Adolf D., 1990).

V med=∆V (V 1+V 2+…+V n)

n ( Número devehículos ¿¿

Página 26


1.1.2 Volumen

Debido a que el contexto de este trabajo de grado se encuentra en tránsito y tráfico de esta

ciudad, no nos vamos a referir al volumen según su definición física, la cual es entendida

como el espacio o cantidad de espacio que ocupan los cuerpos materiales tomando como

medida su altura, su ancho y su largo. Para este trabajo, se utilizará el término Volumen de

tránsito y se definirá como el número de vehículos que pasan por un tramo o calzada de la vía

durante un periodo determinado de tiempo (Adolf D., 1990).

Q=N ( Número de vehículos)

t (Tiempo determinado de lamuestra )

Las variables numéricas, velocidad y volumen, serán manejados dentro del sistema por medio

de variables Double debido a la longitud que estas poseen.

1.2 Levantamiento de Requerimientos

Para el levantamiento de requerimientos se tomaron en cuenta las principales funcionalidades

que debe poseer el software, estas son:

Iniciar aplicación Interacción con el mapa (zoom y arrastrar) Carga de archivos Actualizar mapa Visualizar información Refrescar mapa Cerrar aplicación

Tomando en cuenta esto se encontraron 21 requerimientos esenciales para la entrega del pro-

totipo. Estos son como se muestra en la tabla No. 1.

Código-Req Especificación Requerimiento

R01El sistema debe permitir al usuario iniciar la aplicación.

R02 El sistema debe mostrar una pantalla principal

Página 27



R03El sistema debe mostrar en la pantalla principal, el menú de opciones.

R04El sistema debe mostrar en la pantalla principal, el mapa de Bogotá.

R05El sistema debe mostrar el mapa en la capa Street (calles).

R06El sistema debe permitir al usuario cerrar la aplicación.

R07 El sistema debe actualizar la información en el mapa cada vez que carga un archivo.

R08 El sistema debe permitir usar los comandos básicos de navegación en el mapa: Acercamiento, alejamiento y navegación.

R09 El sistema debe permitir utilizar el ratón y botones en la pantalla para nave-gar.

R10 El sistema debe mostrar un botón que permita la lectura de un archivo en excel.

R11 El sistema debe permitir leer un archivo excel que contenga la información del tráfico.

R12 El sistema debe mostrar un botón para confirmar la carga del archivo al sistema.

R13El sistema debe guardar la información del archivo en excel en memoria.

R14 El sistema debe permitir guardar los datos específicos de promedios de velocidades y volúmenes de los archivos.

R15 El sistema debe permitir mostrar las imágenes del sitio de interés en el archivo en la página principal del sistema.

R16 El sistema debe solicitar confirmación del usuario para mostrar los datos del archivo en una nueva venta emergente.

R17 El sistema debe permitir mostrar la información del archivo en la pantalla principal del sistema.

R18El sistema debe marcar el sitio correspondiente al archivo en el mapa.

R19 El sistema debe permitir refrescar el mapa y mostrar un mapa sin informa-ción.

R20 El sistema debe estar totalmente en español.

R21El sistema debe estar totalmente hecho en lenguaje Java.

Tabla No. 1 – Requerimientos del sistema

Para más información revisar el documento Anexo 1.

Página 28


1.3 Priorización de Requerimientos

La priorización de requerimientos se basó en la necesidad y orden en que estos deben ser

cumplidos para que la solución pueda ser implementada de forma organizada. Los requeri-

mientos con mayor importancia son los que más afectan a nivel funcional, de forma que se

puedan asegurar todas las funcionalidades al finalizar el desarrollo.

La priorización se basó en la siguiente escala numérica:

1: No importa si es implementado o no.

3: Recomendado a implementar.

5: Fuertemente recomendado a implementar, algunas funciones podrían verse com-

prometidas.

7: Obligatorio a implementar.

10: Implementación inmediata.

En la tabla No. 2 se puede apreciar el resultado de la priorización.

Código-Req Especificación RequerimientoImportancia para el pro-

yecto

R01El sistema debe permitir al usuario iniciar la aplicación. 10

R02El sistema debe mostrar una pantalla principal 10

R03 El sistema debe mostrar en la pantalla principal, el menú de opciones. 10

R04 El sistema debe mostrar en la pantalla principal, el mapa de Bogotá. 10

R05El sistema debe mostrar el mapa en la capa Street (calles). 5

R06El sistema debe permitir al usuario cerrar la aplicación. 5

R07 El sistema debe actualizar la información en el mapa cada vez que carga un archivo. 7

R08 El sistema debe permitir usar los comandos básicos de navega-ción en el mapa: Acercamiento, alejamiento y navegación. 3

Página 29



R09 El sistema debe permitir utilizar el ratón y botones en la pantalla para navegar. 3

R10 El sistema debe mostrar un botón que permita la lectura de un archivo en excel. 5

R11 El sistema debe permitir leer un archivo excel que contenga la información del tráfico. 7

R12 El sistema debe mostrar un botón para confirmar la carga del archivo al sistema. 3

R13 El sistema debe guardar la información del archivo en excel en memoria. 7

R14 El sistema debe permitir guardar los datos específicos de pro-medios de velocidades y volúmenes de los archivos. 5

R15 El sistema debe permitir mostrar las imágenes del sitio de inte-rés en el archivo en la página principal del sistema. 5

R16 El sistema debe solicitar confirmación del usuario para mostrar los datos del archivo en la pantalla principal. 3

R17 El sistema debe permitir mostrar la información del archivo en la pantalla principal del sistema. 10

R18 El sistema debe marcar el sitio correspondiente al archivo en el mapa. 10

R19 El sistema debe permitir refrescar el mapa y mostrar un mapa sin información. 10

R20El sistema debe estar totalmente en español. 3

R21El sistema debe estar totalmente hecho en lenguaje Java. 3

Tabla No. 2 – Tabla de requerimientos priorizados


1.4 Entorno de funcionamiento

En la Tabla No. 3 se encuentran los requerimientos que debe tener una máquina que desee

correr el prototipo.

Sistema operativo Windows 7, 8, 8.1, 2008 R2, 2012 R2Linux Ubuntu 12.04 y superior (Se deben modificar las rutas de los archivos para UNIX)

Procesador Intel Pentium 4, Intel Core Duo o superior.AMD Athlon o superior.

Página 30


Frecuencia de procesador Intel 2.2GHz o superior.AMD 2.4 GHz o superior.

Memoria RAM 2 GB o másDisco Duro 5 GBPantalla Resolución de 1366x768 pixeles o superior.

Profundidad de color de 24 bits.Tarjeta de Video 256MB de RAM mínimo recomendado.

Soporte para chipsets NVIDIA, ATI e Intel.Dispositivos de entrada Ratón y teclado.Conexión de Internet Conexión de 1 Mbps de descarga mínimo.Software requerido Java Development Kits (JDK) 7 update 67, y 8 update 20.

ArcGIS Runtime SDK para Java.

Tabla No. 3 – Tabla de requerimientos del entorno del sistema


1.5 Restricciones del Prototipo

Dada la naturaleza de la información y del proyecto, se deben tener en cuenta las siguientes

anotaciones.

Espacio de almacenamiento: La información que alimenta el sistema proviene de la Secre-

taría de Movilidad de Bogotá, ellos proveyeron casi 14 GB de información en documentos de

hoja de cálculo con extensión .xlsm con información de volúmenes y velocidades de aproxi-

madamente 25 corredores viales de la ciudad de Bogotá entre los años 2011 y 2014. Dado el

volumen de la muestra y la diversidad de nombres que presentan los archivos, el prototipo

funcionará con unos documentos seleccionados y que representan un pequeño porcentaje de

la muestra total. Con estos documentos seleccionados se realizará la implementación del pro-

totipo.

Conexión a Internet: Para reducir la carga del sistema, los mapas de la ciudad que se usan

para desplegar la información deben ser obtenidos mediante un servicio web de mapas, por lo

cual la conexión a internet es necesaria para poder hacer uso de la funcionalidad.

Página 31



Idioma: Esta aplicación tiene la intención de funcionar únicamente en la ciudad de Bogotá,

por lo cual la aplicación solo contará con un idioma: Español - Latinoamericano.

Alimentación del sistema: Debido a la infraestructura de la ciudad y a que el método de

monitoreo del tráfico es un proceso manual realizado por personas, la actualización de datos

al sistema queda limitado a los documentos de Excel provenientes de la entidad gubernamen-

tal Movilidad Bogotá, encargada de la gestión del tráfico en la ciudad de Bogotá.

1.6 Análisis de herramientas disponibles

Lenguaje de programación

Para la elección del lenguaje de programación a utilizar, se tendrán en cuenta los siguientes

criterios de selección:

Portabilidad: alta independencia de la plataforma.

Rendimiento: manejo óptimo de los recursos del sistema.

Interfaz: Facilidad de crear una interfaz gráfica de usuario.

Integración con herramientas de terceros: Alto nivel de soporte por parte de la comu-

nidad de desarrolladores para el uso e incorporación de nuevas herramientas.

Soporte de contenido multimedia: Alta capacidad para el manejo de distintos tipos de

archivos multimedia.

A continuación, en la tabla No. 4, una comparativa con los posibles lenguajes de programa-

ción para el proyecto.

Java C++ Python ScalaPortabilidad Alta Media Media AltaRendimiento Medio Alta Alta AltaInterfaz Alta Baja Baja BajaIntegración con herramientas de terceros Alta Media Baja MediaSoporte de contenido multimedia Alta Media Baja Media

Tabla No. 4 – Tabla comparativa de los lenguajes de programación.

Página 32


Según la Tabla No. 4, el lenguaje que mejor se acomoda a las necesidades del trabajo es Java.

Herramientas SIG

A continuación una tabla comparativa con los posibles herramientas SIG para el proyecto.

Los criterios para elegir la herramienta SIG son:

Disponible para desarrollo en Java

Permite la carga de mapas desde un servicio web

Permita la carga de mapas con capas específicas

Capacidad para personalizar mapas

Documentación

Fácil integración con entornos de desarrollo

Soporte en línea

Soporte para aplicaciones tipo Stand-Alone

A continuación, en la tabla No. 5, una comparativa con las posibles herramientas SIG para el

desarrollo.

GeoTools MapGuide Open Source ArcGIS Runtime SDKDisponible para desarrollo en Java Si Si SiCarga de mapas desde un servicio web Si Si SiCarga de mapas por capas Si Si SiCapacidad para personalizar mapas Media Media AltaDocumentación Media Media AltaFácil integración con IDE's Media Baja AltaSoporte en línea Alta Alta AltaSoporte para aplicaciones tipo Stand-Alone Alta Baja Alta

Tabla No. 5 – Tabla comparativa de herramientas SIG posibles para el desarrollo del trabajo

Según la tabla anterior fue seleccionada la herramienta:

GIS ArcGIS Runtime SDK con su implementación en lenguaje Java.

Página 33



Ambiente de desarrollo

De acuerdo al análisis realizado de herramientas disponibles el ambiente para trabajar el pro-

yecto es NetBeans 8.0 debido a su fácil integración con ArcGIS Runtime SDK y también es

el recomendado por la herramienta GIS para desarrollo en Java.

2. Análisis de los datos de entrada

En esta sección se mostrarán los archivos que son la fuente de entrada del sistema. Los archi -

vos que se muestran a continuación son los que se eligieron para alimentar el sistema y con

los que se calibrarán las funcionalidades de lectura de los datos.

2.1 Tipos de documentos

Son dos tipos de documentos los que soporta el sistema, los archivos de velocidad y los de

volumen. Estos documentos varían en la cantidad de muestras y en los tipos de vehículos, por

lo tanto solo se muestra la información disponible a través de estos documentos.

Estos documentos vienen en tipo de archivo Excel con extensión .xlsm.

La siguiente convención explica las abreviaturas utilizadas para la descripción de los vehícu-

los que aparecen en las muestras de los documentos:

TPC: Transporte público colectivo

TPI: Transporte público individual

TP: Transporte particular

2.2 Formato de documentos

A continuación se describe el formato interno con los cuales viene cada tipo de documento.

2.2.1 Documento Velocidades

En este documento se encuentran varias hojas, como se describen a continuación:

Página 34


1. Identificación: En esta hoja encontramos varia información, entre ella:

o Información general del estudio

o El esquema del tramo monitoreado o estudiado

o Datos técnicos del estudio

o Profesionales responsables

o Versiones del estudio

o Descripción de la toma de información

o Análisis puntual

o Registro fotográfico de los puntos de control

o Puntos de control

2. Base: En esta hoja encontramos la estructura de la base de datos con los siguientes

campos:

o Fecha de toma de información

o Nomenclatura del corredor de la toma de información.

o Sector del corredor

o Sentido de desplazamiento

o Número de punto de control

o Nombre de la vía o sitio asignado como punto de control sobre el corredor de

estudio.

o Tipo de vehículo

o Número de recorrido

o Periodo del día en el que se realizó la toma.

o Hora de paso por el punto de control.

o Minuto de paso por el punto de control.

o Segundo de paso por el punto de control.

3. Procesamiento: En esta hoja encontramos un análisis de los tiempos de recorridos

e indicadores de velocidad, en ella encontramos estos campos en específico:

o Base auxiliar

o Base calculada

Página 35



4. Resultados generales: En esta hoja encontramos el resumen de número de recorri-

dos, tiempos promedio de viaje e indicador de velocidad promedio por subtramo,

periodo y hora de recorrido.

4a. Gráfico de tiempos: En esta hoja encontramos una gráfica de tiempos utilizando

los resultados generales.

4b. Gráfico de velocidades: En esta hoja encontramos una gráfica de velocidades

promedio utilizando los resultados generales.

4c. Perfil de velocidad: En esta tabla encontramos el indicador de velocidad prome-

dio por subtramo y periodo, y una gráfica con el perfil del indicador de velocidad

promedio por subtramo y periodo del corredor vial en estudio.

5. Resumen cartilla: En esta hoja podemos encontrar el resumen de velocidades por

tramo en Km/h.

5a. Resumen Georreferenciación: En esta hoja encontramos el resumen georrefe-

renciado de los indicadores de velocidad.

5b. Resumen Mensual: En esta hoja encontramos el resumen mensual de los indica-

dores de velocidad.

2.2.2 Documento Volúmenes

En este documento se encuentran varias hojas, como se describen a continuación:

1. Identificación: En esta hoja encontramos varia información, entre ella:

o Información general del estudio

o El esquema del tramo monitoreado o estudiado

o Datos técnicos del estudio

o Profesionales responsables

o Versiones del estudio

o Descripción de la toma de información

o Análisis puntual

o Registro fotográfico

2. Base: En esta hoja encontramos la estructura de la base de datos:

o Fecha de toma de la información

Página 36


o Vía específica donde se efectuó la toma de información

o Localización específica donde se efectuó la toma de información

o Periodo de conteo de 15 minutos

o Accesos a los flujos vehiculares

o Tipos de vehículos

3. Procesamiento: En esta hoja encontramos los volúmenes por cuarto de hora para

el acceso a las calzadas internas y/o externas (lentas y/o rápidas).

4. Resultados: En esta hoja encontramos en tablas y gráficos los resultados por pe-

ríodo, por sentido y por tipo de vehículo para la hora de máxima demanda.

4a. Indicadores: En esta hoja encontramos el resumen de los indicadores por hora-

rios de pico y placa.

5. Resumen cartilla: En esta hoja encontramos el resumen general de la cartilla.

5a. Resumen mensual: En esta hoja encontramos el resumen de los indicadores del

mes.

2.3 Datos de interés

Debido a la gran cantidad de datos que proporcionan estos documentos, se utilizarán hojas en

específico por cada tipo de documento.

2.3.1 Documentos Velocidades

Las hojas a utilizar de este tipo de documento serán:

1. Identificación

5. Resumen cartilla

5a. Resumen Georreferenciación

5b. Resumen Mensual

2.3.2 Documentos Volúmenes

Las hojas a utilizar de este tipo de documento serán:

Página 37



1. Identificación

4. Resultados

4a. Indicadores

5. Resumen cartilla

5a. Resumen mensual

IV – DISEÑO

En este capítulo se encuentra la propuesta de diseño para el prototipo a partir del análisis

realizado anteriormente.

1. Metodología de desarrollo

La metodología de desarrollo seleccionada para el proceso de construcción del software Fo-

xWay es la metodología conocida como RUP, o Proceso Unificado de Rational (Kruchten,

2004) . La flexibilidad y gran adaptabilidad que ofrece esta metodología la convierte en una

Página 38


buena candidata para el desarrollo del sistema. En la figura No. 2 se puede observar una des-

cripción de la metodología aplicada al trabajo (Kroll & Kruchten, 2004).

Figura No. 2 – Imagen de la metodología RUP aplicada al trabajo

1.1 La metodología

Esta metodología consiste en un ciclo de vida organizado en fases e iteraciones. RUP se divi-

de en 4 fases, en las cuales se realizan varias iteraciones.

Inicio

o Comprensión del problema y la tecnología, delimitación del proyecto y esta-

blecer la línea base de la arquitectura.

Elaboración

o Continuación de la fase de inicio pero enfocado en el desarrollo de la línea

base de la arquitectura, análisis y diseño del modelo de negocio y una parte

de la implementación.

Construcción

o Construcción de la aplicación de software por medio de iteraciones.

Transición

o Garantizar que se tiene un producto preparado para su entrega.

1.2 Actividades

Las actividades que se realizarán serán las mismas iteraciones que requiere la construcción

del prototipo:

Primera iteración: Comprensión del problema en medios tecnológicos e inicio del

modelado del negocio. Se utiliza una abstracción de los requerimientos y del diseño

propuesto del prototipo como guía.

Página 39



Segunda iteración: Aplicación de la base del diseño arquitectural propuesto y garan-

tizar los principales requerimientos.

Tercera iteración: En esta iteración se concentra el desarrollo de la lógica de nego-

cio y pruebas iniciales.

Cuarta iteración: Esta iteración se centra en el desarrollo de pruebas a la lógica de

negocio del prototipo y en corregir comportamientos inesperados y/o erróneos.

1.3 Hitos

Las actividades se verán completadas con el cumplimiento del cuarto objetivo específico:

• Implementar un prototipo para acceder y visualizar datos históricos.

2. Modelo de Dominio

El modelo de dominio muestra un modelo conceptual de los temas tratados para la solución.

En la imagen Figura No. 3 se puede ver la vista del modelo de dominio.

Página 40


Figura No. 3 – Vista del modelo de dominio

VentanaPrincipal: Es la entidad que mantiene la interacción con el usuario y los despliegues

visuales de los datos. Al mismo tiempo es el que maneja el menú principal.

LeerArchivo: Entidad encargada de la lectura de los archivos de Excel. Posee la capacidad

para leer ambos tipos de archivos, velocidades y volúmenes.

DatosAdaptador: Entidad encargada de mapear los datos a su DTO (Data Transfer Object)

específico para poder ser utilizado por el programa.

Velocidades: Entidad que representa el DTO de los datos de las velocidades.

Volúmenes: Entidad que representa el DTO de los datos de los volúmenes.

CargarDatos: Entidad encargada de la lectura de los DTO para ser cargados en el mapa.

Página 41



Mapa: Entidad encargada de la carga del mapa de la ciudad y de ubicar los puntos de interés

sobre el mismo.

ActualizarMapa: Entidad encargada de generar la petición de agregar sitios de interés en el

mapa y cargar la información de estos sobre el punto geográfico específico.


3. Casos de Uso

En esta sección se muestra el diagrama de casos de uso, la Figura No. 4 muestra la descrip-

ción de los pasos que deben realizarse para llevar a cabo las principales funcionalidades del

sistema.

Página 42


Figura No. 4 – Vista del diagrama de casos de uso

4. Distribución de los requerimientos según Casos de Uso

A continuación se presentan los requerimientos específicos a cada caso de uso, se utiliza el

código del requerimiento para la asociación.

4.1 Iniciar aplicación

Requerimientos asociados: R01

Página 43



4.2 Interactuar con el mapa

Requerimientos asociados: R08, R09

4.3 Seleccionar y cargar archivo

Requerimientos asociados: R07, R10, R11, R12, R13, R14

4.4 Visualizar información


4.5 Refrescar mapa

Requerimientos asociados: R05, R07, R08, R09, R19

4.6 Cerrar aplicación


4.7 Desplegar ventana principal

Requerimientos asociados: R01, R02, R03, R04, R05

Página 44


4.8 Actualizar mapa

Requerimientos asociados: R07, R13, R18, R19

4.9 Leer archivo


4.10 Desplegar información

Requerimientos asociados: R16, R17

4.11 Cargar datos velocidades


4.12 Cargar datos volúmenes



5. Arquitectura del Diseño

Una vez levantados los requerimientos, priorizados, y con las principales funcionalidades del

sistema identificados, procedemos a generar la propuesta del diseño de la arquitectura. Según

lo visto en el capítulo anterior, se considera que el patrón Modelo-Vista-Controlador, o MVC,

Página 45



es apropiado para el desarrollo de la aplicación, el cual separa los datos del controlador y a la

vez de la vista de Usuario. A continuación, en la figura No.5 podemos observar lo que sería el

Overview Arquitectónico de la misma.

Figura No. 5 – Vista de la arquitectura del prototipo

Para ver el código fuente referirse al Anexo 5.

6. Vista de componentes

El desarrollo de la aplicación se forma a partir de tres componentes lógicos que se traducen

en tres paquetes llamados: Presentación, Controlador y Modelo. Estos tres paquetes encapsu-

lan el patrón MVC en el cual se basa el desarrollo de la aplicación, como se puede ver en la

figura No. 6.

Página 46


Figura No. 6 – Vista de componentes

7. Vista de despliegue

La unidad de despliegue de la aplicación es FoxWay.jar que permite ser desplegada como una

aplicación Stand-Alone en sistemas operativos compatibles con el Java Runtime Environment

o JRE de Java, tales como Windows y varias distribuciones de Linux. Esto le permite a la

aplicación ser ejecutada como multiplataforma, solamente dependiendo de la compatibilidad

del sistema operativo con Java. A continuación, en la figura No. 7, la vista por despliegue,

donde se ve la aplicación dentro de un computador con JRE.

Página 47



Figura No. 7 – Vista de despliegue

8. Diagramas de Secuencia

Para la trazabilidad de los requerimientos formulados, se realizaron diagramas de secuencia

para así poder ver la evolución de cada requerimiento dentro de su caso de uso respectivo.

Para esta sección se tomaron dos casos de uso que conforman tres diagramas de secuencia

que se consideran los primordiales para el funcionamiento del sistema, estos son:

Cargar información velocidades.

Cargar información volúmenes.

Refrescar mapa.

Para ver todos los diagramas favor referirse al anexo - SDD

Página 48


8.1 Cargar información velocidades

En la figura No. 8 podemos observar la secuencia básica de lo que es la carga de información

proveniente de los archivos de tipo velocidades.

Figura No. 8 – Diagrama de secuencia de la carga de Velocidades

Página 49



8.2 Cargar información volúmenes

En la figura No. 9 podemos observar la secuencia básica de lo que es la carga de información

proveniente de los archivos de tipo volumen.

Figura No. 9 – Diagrama de secuencia de la carga de Volúmenes

Página 50


8.3 Refrescar mapa

En la figura No. 10 podemos observar la secuencia básica de lo que es la función de refrescar

mapa.

Figura No. 10 – Diagrama de secuencia de la función de limpiar mapa

Para más información respecto al diseño, favor revisar el Anexo 2.

9. Interfaz de usuario

A continuación se muestra un bosquejo de las pantallas con las cuales interactúa el usuario

con el sistema.

9.1 Vistas

9.1.1 Pantalla principal

En la figura No. 11, se observa la pantalla con la que el usuario interactúa la mayoría del

tiempo. Aquí encontramos los siguientes elementos:

Página 51



Zona donde se muestra el mapa de Bogotá

Controles para el control de navegación del mapa

Menú de selección del tipo de documento y de la fecha

Zona de visualización del marcador sobre el mapa

Botón de selección para ver más información

Función de limpiar el mapa

Logo de la universidad

Logo de la aplicación

Botón Acerca de

Figura No. 11 – Prototipo pantalla principal de la aplicación

Página 52


9.1.2 Información Documento

La ventana de la figura No. 12, se ve cuando se selecciona la opción de ver Más información

en la zona de visualización del marcador. Aquí veremos una selección mayor de información

(más detalle) que lo que se ve inicialmente en la pantalla principal.

Figura No. 12 – Prototipo de la pantalla Más Información

Página 53



9.1.3 Información Proyecto

La ventana en la figura No. 13 es la ventana de información, también conocida como Acerca

de. Se desplegará a través del logo de la aplicación y mostrará la información básica acerca

del sistema, autor, el director de tesis y la universidad.

Figura No. 13 – Prototipo de pantalla de Información desplegada a través del botón Acerca

de.

Página 54


9.2 Grafo de navegabilidad

En la figura No. 14 podemos observar el flujo de navegación a través de las distintas ventanas

del sistema. Todas las funcionalidades principales del sistema se encuentran en la pantalla

principal en la zona del menú (barra del costado derecho). La ventana de Información Docu-

mento se muestra cuando el usuario ya ha cargado un archivo, ha seleccionado un marcador

dentro del mapa y desea ver aún más información que la mostrada en la zona de Información

Marcador y oprime el botón de Más Información.

La ventana de Información Proyecto se muestra a través de oprimir el botón Acerca de.

Figura No. 14 – Vista de navegación entre las distintas ventanas del prototipo.

Para más información respecto al diseño, favor revisar el Anexo 2.

Página 55



V – DESARROLLO DE LA SOLUCIÓN

Este capítulo trata acerca de la implementación y construcción del prototipo propuesto. Según

la metodología que se explicó en el capítulo I, a continuación se muestra la fase de elabora-

ción del prototipo.

1. Descripción de las principales funcionalidades del prototipo y su comportamiento

En este numeral se encuentra la descripción de las funcionalidades del sistema, sus comporta-

mientos y pequeñas muestras de códigos que ilustran de mejor manera la implementación de

la solución.

2.1 El mapa y su comportamiento

En esta sección se ve cómo funciona el mapa, su despliegue y su comportamiento.

Página 56


Figura No. 15 – Mapa de Bogotá según el despliegue en el prototipo

En la figura No. 15 se puede ver el mapa que se carga al ejecutar la aplicación. El mapa car-

gado se encuentra ubicado en una posición central de la ciudad de Bogotá con un panorama

amplio. El tipo de mapa cargado es tipo “Street” o calle, el cual muestra con especial énfasis

las vías de la ciudad sin mostrar fotografías o cualquier otro elemento no relevante a la conse-

cución de los objetivos del trabajo.

En la esquina inferior izquierda se puede observar un panel de navegación y control del

mapa, en el cual se puede manejar el nivel del acercamiento del mapa, mover el mapa en los

cuatro ejes cardinales. De igual forma, se puede manejar el mapa con el ratón del computador

de forma tal que la navegación funciona con arrastrar el mapa y el nivel de acercamiento

funciona con la rueda.

En la figura No. 16 se puede observar el componente de código que carga el mapa, sin los

controles de navegación.

Figura No. 16 – Fragmento del código que carga el mapa

2.2 Funcionalidad de carga de archivos al sistema

En esta sección se muestra la forma usada para poder alimentar el prototipo de los datos del

tráfico.

Métodos de lectura

Página 57



Como se explicará en la siguiente sección de este capítulo, se usan las librerías del API Apa-

che POI Project. Para lograr la lectura, se crean dos métodos en el modelo, encargados de la

lectura de cada tipo de archivo (velocidades y volúmenes) y donde cada uno retorna una lista

del tipo de dato correspondiente. En la figura No. 17 se puede observar la firma de los méto-

dos.

Figura No. 17 – Métodos de lecturas correspondientes

Para ejecutar la búsqueda, el usuario selecciona la información deseada como se ve en la

figura No. 18.

Figura No. 18 – Vista del menú de cargar información

El usuario selecciona un tipo de dato, después selecciona un mes del año y por último selec -

ciona un año disponible (2011-2014). Esta selección busca los archivos disponibles que co-

rrespondan a la fecha ingresada.

Métodos de visualización

Una vez cargada la información, el sistema procede a mostrar los datos ubicados sobre el

mapa en forma de marcadores de mapas, estos marcadores son ubicados dado el posiciona-

miento dentro de cada archivo respecto al punto de referencia.

Página 58


Para lograr esto se crean dos métodos, uno recibe las variables tipo String de latitud y longi-

tud en formato de coordenadas DMS (Degree, Minutes, Seconds o Grados, Minutos, Segun-

dos) y las transforma en un único String con un formato de texto que es entendido por Ar-

cGIS para transformar las coordenadas. El segundo método recibe el String anterior y usa la

clase CoordinateConversion para retornar las coordenadas en formato DD (Degree Decimal o

Grados Decimales) y estas se transforman en variables tipo Double para que el mapa las pue-

da interpretar. En la figura No. 19 se pueden observar los métodos que se encargan de las

tareas descritas.

Figura No. 19 – Métodos para trabajar las coordenadas de los archivos

El resultado de este posicionamiento se puede observar en la figura No. 20.

Página 59



Figura No. 20 – Marcadores ubicados en el mapa

Para más información acerca del funcionamiento del prototipo, favor referirse al Anexo 4.

2.3 Visualización de la arquitectura interna del prototipo

En esta sección se puede ver cómo quedó organizado el proyecto Java correspondiente a la

aplicación prototipo.

Para ver el código fuente referirse al Anexo 5.

Modelo Vista Controlador

En la figura No. 21 se ve el orden del proyecto.

Figura No. 21 – Composición interna del proyecto Java

El prototipo quedó implementado de forma tal que cumpla con el diseño MVC propuesto

inicialmente, de forma que la Pantalla Principal del prototipo se encuentra en el paquete Vis-

Página 60


ta. En el paquete controlador se encuentra la clase Controlador que posee los métodos que usa

la vista, pero estos métodos ejecutan los servicios de la clase Modelo en el paquete Modelo.

En el paquete modelo encontramos también los DTO’s correspondientes a cada tipo de dato.

Adicional encontramos un paquete de pruebas en donde se encuentran los documentos de

prueba con los que se prueba el API de Apache POI Project. También encontramos el paquete

zData, este paquete contiene los archivos de los datos de tráfico.

El link del repositorio de este trabajo para el código se encuentra en el Anexo 5.

2. Interfaz gráfica de interacción con el usuario

La interfaz gráfica se desarrolla respetando las vistas prototipo mostradas en la fase de dise-

ño. Para el desarrollo de estas, se utiliza la herramienta gráfica Java Swing para los compo-

nentes de interacción y visualización del prototipo, y para la visualización del mapa y sus

elementos relacionados se utiliza el SDK de ArcGIS.

La Pantalla Principal

A continuación en la Figura No. 22 se visualiza la pantalla principal y cómo se mantiene al

diseño original.

Página 61



Figura No. 22 – Pantalla principal del prototipo

Como se observa en la imagen, se ve el mapa de la ciudad de Bogotá y todos los elementos y

componentes gráficos que se describieron en la fase de diseño.

El menú

El menú consta de varias partes, cada una separada por sus respectivas márgenes.

La primera es el menú de carga de información, aquí se encuentra la funcionalidad de

cargar información o archivos al sistema. Ver figura No. 23.

Figura No. 23 – Elemento del menú Cargar Información

Página 62


La segunda opción es la funcionalidad de limpiar mapa. Ver figura No. 24.

Figura No. 24 – Elemento del menú Limpiar Mapa

La tercera es un espacio adicional que se muestra para el despliegue extra de datos.

Ver figura No. 25.

Figura No. 25 – Elemento del menú Más Información

El cuarto elemento son los logos de la Universidad y el del Prototipo

El quinto y último elemento es el botón Acerca de que permite ver información res-

pecto al proyecto. Ver figura No. 26.

Página 63



Figura No. 26 – Ventana de información del proyecto

Para información acerca de la instalación del prototipo favor referirse al Anexo 3.

3. Herramientas adicionales

Para el desarrollo de la solución propuesta se utilizaron un set de herramientas adicionales,

estas herramientas se describen en los siguientes numerales.

3.1 Herramienta de lectura de archivos

Como herramienta adicional se utilizan las librerías de lectura de archivos de ofimática “The

Apache POI Project” (Apache, 2014) con la cual se desarrolla los métodos de lectura de los

documentos. La versión utilizada es la última versión estable a la fecha de este trabajo, ver-

sión 3.12.

Se crea la lectura de documentos .xlsm con las clases XSSFWorkBook y XSSFSheet. Se

eligió esta herramienta debido a que es libre, está desarrollada en Java, tiene las funcionalida-

des necesarias para el trabajo y según los desarrolladores presenta un buen uso de los recursos

del sistema y posee buen rendimiento. En la figura No. 27 se puede observar una tabla que

resume las funcionalidades de este API.

Figura No. 27 – Tabla resumen del API para documentos en formatos tipo Excel

Página 64


3.2 Herramienta para repositorio de código

Se selecciona una herramienta de repositorio para poder dejar el código del trabajo disponible

a quien esté interesado en usarlo y/o modificarlo.

Se selecciona GitHub debido a su facilidad de uso y de control que se puede ejercer sobre un

proyecto de libre desarrollo. GitHub ofrece varios beneficios a este tipo de proyectos como:

Control de versiones

Facilidad de ingreso para nuevos usuarios

Fácil entendimiento del proyecto

Permite ver los cambios por usuario o desarrollador

Fácil uso/instalación.

El link del repositorio de este trabajo para el código se encuentra en el Anexo 5.

4. Plan de pruebas

El plan de pruebas consiste en 3 pruebas:

Capacidad de carga de los archivos

Rendimiento

Visualización de la información histórica sobre un punto de la ciudad

4.1 Carga de información de los archivos

Para la carga de información desde los archivos se realizarán las siguientes pruebas.

4.1.1 Prueba de carga

Se selecciona un archivo único de la muestra.

Se realiza el procedimiento de carga en el sistema.

Se muestran los resultados de la carga del archivo a través de la consola del entorno

de desarrollo.

Página 65



Se realiza una comparación directa entre la información mostrada en la consola y el

contenido del archivo directo.

Los datos a revisar se explican a continuación según su tipo de dato (velocidad o

volumen):

o Velocidad:

Nombre del archivo cargado

Nombre del corredor vial descrito

Fecha del estudio

Descripción de tramos analizados

Tipos de vehículos

Horarios de toma de muestra (Horarios periodo)

Número de equipos utilizados.

o Volumen:

Nombre del archivo cargado

Intersección descrita

Fecha del estudio

Número de periodos analizados

Número de horas que duró la toma de muestras

Horario

Número de equipos utilizados

Dado que la metodología utilizada es igual para todo el documento, se considera que

estos datos de muestra son suficientes para la prueba.

Con esta prueba se garantiza que no haya distorsiones en el paso de la información y

que los archivos están siendo leídos de forma correcta.

4.1.2 Pruebas de rendimiento

Para probar el rendimiento de la carga de archivos se realizarán dos pruebas, una de carga

sencilla de un solo archivo y otra de carga masiva.

La prueba de rendimiento de carga sencilla se explica a continuación:

o Se usa una fecha en específico que solo carga un archivo.

o Se realiza de igual forma para ambos tipos de datos

Página 66


o Se mide el tiempo que le toma al sistema en cargar el archivo

La prueba de rendimiento de carga masiva se explica a continuación:

o Se utiliza una fecha en específico que carga 8 archivos para volúmenes y 10

archivos para velocidades de forma simultánea.

o Se mide el tiempo para ambas medidas.

4.2 Visualización histórica de los datos

Para probar la capacidad del sistema de visualizar la información de un mismo punto a través

del tiempo, se realiza la prueba como se describe a continuación:

Para esta prueba se elige la intersección de la avenida calle 80 con avenida carrera

86.

Se deben cargar mínimo un archivo por año.

Se verifica para los años 2011, 2012, 2013 y 2014.

Se escogen los archivos existentes de la intersección seleccionada y se ubican en la

carpeta de pruebas durante el tiempo de la prueba.

Página 67



VI – RESULTADOS

En este capítulo se puede observar los resultados finales del prototipo, el plan de pruebas y

los análisis de resultados.

1. Vista final de una ejecución simple del prototipo

En esta sección se observa una ejecución completa y exitosa del prototipo. La figura No. 28

permite visualizar dicho resultado.

Figura No. 28 – Pantallazo de una ejecución completa del prototipo

En la figura anterior se observa cómo se cargan los componentes de la fecha seleccionada y la

visualización de la información sobre el mapa en los marcadores ubicados espacialmente.

Para más información acerca del funcionamiento del prototipo, favor referirse al Anexo 4.

Página 68


2. Ejecución del plan de pruebas

La ejecución del plan de pruebas se realizó como fue descrito en el capítulo III sección 3. Los

archivos que fueron seleccionados para la prueba se dejaron en las fechas Diciembre – 2011 y

Enero – 2011 para ambos tipos de datos.

Para la prueba de carga sencilla al sistema se utiliza Enero – 2011, donde solo se encuentra

un único archivo a cargar.

Para la prueba de carga masiva se utiliza Diciembre – 2011, donde se encuentran varios ar -

chivos (mínimo 6) para cargar.

Al mismo tiempo se monitorea el tiempo tomado para llevar a cabo las tareas, desde el co -

mienzo de la carga hasta el momento en que se pueden visualizar en el mapa.

Las pruebas

Primera prueba:

o Objetivos:

Medir el tiempo de carga de un archivo

Verificar la información cargada

o Procedimiento:

Se carga un archivo único de velocidades (Enero – 2011)

Se toma el tiempo desde que se empieza la carga desde el menú en la

pantalla principal.

Una vez realizada la carga se imprime por consola la información

cargada para ser verificada.

Repetir procedimiento para volúmenes

Segunda prueba:

o Objetivos:

Medir el tiempo de carga de varios archivos

Verificar la información cargada

o Procedimiento:

Página 69



o Se cargan varios archivos de velocidades (Diciembre – 2011)

Se toma el tiempo desde que se empieza la carga desde el menú en la

pantalla principal.

Una vez realizada la carga se imprime por consola la información

cargada para ser verificada.

Repetir procedimiento para volúmenes

Tercera prueba:

o Objetivos:

Verificar que se pueden encontrar información distinta a través del

tiempo de un mismo punto.

o Procedimiento:

Se ubican los archivos seleccionados en la ruta especificada en el

plan de pruebas.

Se modifica la ruta de lectura del prototipo para que use una ruta

especificada.

Se ejecuta la opción cargar desde el prototipo (no se selecciona nin-

gún criterio de búsqueda, la ruta se encuentra fija).

Se imprime la información por consola para realizar la verificación.

Los resultados de las pruebas se encuentran en la siguiente sección.

3. Análisis de resultados

En esta sección encontramos los resultados de las pruebas realizadas.

Prueba 1 – Velocidades

Archivos cargados: 1

Tiempo: 5.53 segundos

Verificación de datos: La información cargada al sistema y mostrada a través de la consola es

consistente a la información presentada en el archivo de carga.

Página 70


Observaciones: La prueba se desarrolla con normalidad.

Resultado: La prueba es exitosa – Se cumplen los objetivos de forma satisfactoria.

Prueba 1 – Volúmenes




consistente a la información presentada en el archivo de carga.

Observaciones: La prueba se desarrolla con normalidad.


Prueba 2 – Velocidades




consistente a la información presentada en los archivos de carga.

Observaciones: Se presenta un tiempo de casi 30 segundos para la carga de 10 archivos, lo

cual puede significar un tiempo grande de respuesta para muestras mayores.


Página 71



Prueba 2 – Volúmenes




consistente a la información presentada en los archivos de carga.

Observaciones: Se presenta un tiempo de casi 25 segundos para la carga de 8 archivos, lo cual

puede significar un tiempo grande de respuesta para muestras mayores.


Prueba 3



Verificación: Se revisa la salida por consola y se puede observar el cambio del comporta-

miento del punto seleccionado de la ciudad por los factores de velocidad promedio y cantidad

de vehículos en general que transitaron en la toma de datos.

Resumen resultados:

Año 2011

o Periodo 1

Franja: 6-7 am

Mixtos: 10001 vehículos

o Periodo 2

Franja: 2-3pm


Página 72


o Periodo 3

Franja: 5-6pm


Año 2012

o Periodo 1

Franja: 6-7 am


o Periodo 2

Franja: 2-3pm


o Periodo 3

Franja: 5-6pm


Año 2013

o Periodo 1

Franja: 6-7 am


o Periodo 2

Franja: 2-3pm


o Periodo 3

Franja: 5-6pm


Año 2014

o Periodo 1

Franja: 6:30-7:30 am


o Periodo 2

Franja: 1:15-2:15pm


Página 73



o Periodo 3

Franja: 5-6pm


Observaciones Generales

En la carga masiva de archivos, se evidencia un tiempo de demora mayor a los tiempos indi-

viduales. Se revisa la documentación del API de carga de archivos y se encuentra que el com-

portamiento de los algoritmos de lectura toma un tiempo preciso por archivo (varía según el

tamaño del archivo). Por lo tanto se determina que el tiempo de espera generado al cargar

varios archivos queda limitado a la cantidad de los archivos a cargar y la capacidad de cóm-

puto que posee la máquina en donde se ejecuta el prototipo.

En la prueba 3 podemos observar la capacidad de comparar distintas fechas de un mismo

sitio, lo cual nos genera un histórico del sitio.

Las características del equipo en el que se realizaron las pruebas son:

Procesador: Intel Core i7 4710HQ 3.4 GHz

RAM: 8GB DDR3L 1600 MHz

Gráficos: NVIDIA GTX 850m 2GB GDDR5

Página 74


VII – CONCLUSIONES

1. Análisis de Impacto del Desarrollo

El prototipo da a lugar a un buen número de oportunidades para desarrollos que permitan el

progreso de la ciudad. Al tener la capacidad de visualizar mejor la información existente del

tráfico de la ciudad, mejora el proceso de toma de decisiones respecto a la construcción, inter-

vención o cierres en las vías. Un mejor proceso de toma de decisiones permite agilizar pro-

yectos y reducir costos innecesarios al momento de ejecutar o estudiar el impacto y viabilidad

de una intervención vial.

Al poder ser desarrollado por estudiantes de la universidad, este tipo de aplicaciones de so-

ftware le brinda renombre a la institución y experiencia en el desarrollo de aplicaciones con

impacto social al mismo tiempo que fomenta la investigación.

2. Conclusiones y Trabajo Futuro

Se demuestra que es posible generar una aplicación de software que sea capaz de visualizar

los datos históricos del tráfico, mostrando una única interface para consultar y analizar los

numerosos documentos que se tienen almacenados de años atrás en la ciudad de Bogotá.

Con el prototipo se logra demostrar que es posible organizar la información a través de una

herramienta SIG para que un medio visualizador pueda utilizarla con diversos propósitos.

Página 75



También se obtiene la capacidad de poder revisar la información de varios documentos de

forma más rápida al poder ser capaces de elegir el tipo de dato, la fecha y la ubicación de

interés en vez de revisar de a un solo documento a través de numerosas carpetas y nombres de

archivos mal indexados.

De la misma forma, al poder tener la capacidad de ver y buscar información de interés, se

facilita la generación de una base de conocimientos que permitan facilitar el proceso de toma

de decisiones concernientes a la movilidad de Bogotá

El trabajo realizado abre nuevas capacidades para desarrollar más temas relacionadas a la

movilidad de la ciudad y su tráfico. A continuación una lista de posibles áreas de desarrollo

futuro a través de este trabajo:

La creación de una base de datos georreferenciada con la información utilizada en

este trabajo.

La creación de una aplicación móvil que permita recoger información del tráfico con

el objetivo de automatizar el proceso de recolección de datos y alimentar la base de

datos georreferenciada y al prototipo mismo.

A través de la información recogida, generar simulaciones de futuras posible situa-

ciones que puedan impactar negativamente el tráfico de la ciudad.

Crear la capacidad al prototipo de poder predecir impactos en la movilidad por cerra -

mientos, reparaciones e intervenciones en las vías.

Página 76


VIII – REFERENCIAS Y BIBLIOGRAFÍA

Adolf D., M. (1990). Fundamentals of Traffic Flow. New Jersey: Prentice - Hall, Inc.

Apache. (2014). Apache POI Project. Obtenido de https://poi.apache.org/: https://poi.apa-

che.org/

ArcGis Resources, A. (s.f.). ArcGis Resources. Obtenido de ArcGis Resources: http://resour-

ces.arcgis.com/en/help/getting-started/articles/026n0000000s000000.htm

Astrolabs. (2010). Obtenido de http://www.astrolabes.org/

Bhatta, B. (2010). Global Navigation Satellite Systems: Insight Into GPS, Glonass, Galileo,

Compass, and Others. BS Publications.

Catalonia ORG. (s.f.). Catalonia. Obtenido de Catalonia: http://www.catalonia.org/cartogra-

fia/Clase_06/Historia_Sistemas_Navegaci%F3n_01.html

Dow, J. M., Neilan, R. E., & Rizos, C. (2008). The International GNSS Service in a changing

landscape of Global Navigation Satellite Systems.

Gartner. (27 de Junio de 2011). Gartner. Obtenido de http://www.gartner.com/newsroom/id/

1731916

Gonzalez, H., Han, J., Li, X., Myslinska, M., & Sondag, J. P. (2007). Adaptive fastest path

computation on a road network: a traffic mining approach. VLDB '07 Proceedings of

the 33rd international conference on Very large data bases, 794-805. Obtenido de

http://dl.acm.org/citation.cfm?id=1325942

Groves, P. D. (2013). Principales of GNSS, Inertial and Multisensor Integrated Navigation

Systems.

Hegarty, C. G., & Chatre, E. (2008). Evolution of The Global Navigation Satellite System

(GNSS). Proceedings of the IEEE.

Página 77



IBM. (3 de Julio de 2001). IBM. Obtenido de http://www.ibm.com/developerworks/rational/

library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf

Juan C. Herrera, D. B. (2010). Evaluation of traffic data obtained via GPS-enabled mobile

phones: TheMobile Centuryfield experiment. Transportation Research Part C:

Emerging Technologies, 568–583. Obtenido de http://www.sciencedirect.com/scien-

ce/article/pii/S0968090X09001430

Kerner, B. S. (27 de 2 de 2004). The Physics of Traffic: Empirical Freeway Pattern Features,

Engineering Applications, and Theory. Alemania: Springer-Verlag. Obtenido de

Wikipedia: http://en.wikipedia.org/wiki/Traffic

Kresse, W., & Danko, D. M. (2012). Handbook of Geographic Information. Berlin: Springer-

Verlag.

Kroll, P., & Kruchten, P. (2004). The Rational Unified Process Made Easy A Practitioner's

Guide to the RUP. Booch Jacobson Rumbaugh.

Kruchten, P. (2004). The Rational Unified Process An Introduction. Booch Jacobson Rum-

baugh.

Laney, D. (6 de Febrero de 2001). Gartner. Obtenido de http://blogs.gartner.com/doug-

laney/files/2012/01/ad949-3D-Data-Management-Controlling-Data-Volume-Veloci-

ty-and-Variety.pdf

Longley, P. A., Goodchild, M. F., Maguire, D. J., & Rhind, D. W. (2005). Geographical In-

formation Systems and Science. John Wiley & Sons, Ltd.

Morales Machuca, C. A. (s.f.). http://www.methesis.fcs.ucr.ac.cr/. Obtenido de http://www.-

methesis.fcs.ucr.ac.cr/: http://www.methesis.fcs.ucr.ac.cr/blogs/rumana/wp-content/

uploads/2010/09/articulo2.pdf

Morrison, J. E. (s.f.). The Astrolabe.

Navarro Hudiel, S. J. (2008). Análisis del Flujo Vehicular.

Página 78


Płaczek, B. (2012). Selective data collection in vehicular networks for traffic control applica-

tions. Transportation Research Part C: Emerging Technologies, 14-28. Obtenido de

http://www.sciencedirect.com/science/article/pii/S0968090X1100180X

Posada Henao, J. J., Farbiarz Castro, V., & González Calderon, C. (2011). Analysis of "PICO

Y PLACA" as a vehicular circulation restriction in Medellin - Based on Traffic Volu-

mes.

Ramon S. Schwartza, A. E. (2014). On the applicability of fair and adaptive data dissemina-

tion in traffic information systems. Ad Hoc Networks, 428–443. Obtenido de http://

www.sciencedirect.com/science/article/pii/S1570870513002059

Reynolds, H. (1997). An Introduction To Geographical Information Systems (GIS).

Robles, D., Ñañez, P., & Quijano, N. (2009). Control y Somulación de Tráfico Urbano en

Colombia: Estado del Arte. 59-69.

Rodrigue, J.-P. (2013). The Geography of Transport Systems. Routledge Editorial.

Rodriguez Niño, D. F., & Ardila Díaz, G. O. (2002). “CONCURRENCIA EN SISTEMAS

MULTIAGENTE: IMPLEMENTACIÓN DE UN SIMULADOR DE TRÁFICO

URBANO”. Bogotá.

Ruiz Limón, R. (2006). Historia y Evolución del Pensamiento Científico. México: Euler

Ruiz.

Schiller, J., & Voisard, A. (2004). Location-Based Services. San Francisco: Morgan Kau-

fmann.

Teal, R. F. (1987). Carpooling: Who, how and why.

Thomson, J. M. (1978). Great cities and their traffic.

US Government. (11 de Febrero de 2014). GPS.gov. Obtenido de GPS.gov: http://www.gps.-

gov/systems/gps/

Página 79



Página 80


IV - ANEXOS

Anexo 1: Documento SRS

Anexo 2: Documento SDD

Anexo 3: Manual de Instalación

Anexo 4: Manual de Usuario del Prototipo

Anexo 5: Repositorio GitHub

Página 81


https://github.com/szorro89/FoxWay

Propuesta para Trabajo de Gradopegasus.javeriana.edu.co/~CIS1410IS04/downloads/[01... · Web...

Documents

Transcript of Propuesta para Trabajo de Gradopegasus.javeriana.edu.co/~CIS1410IS04/downloads/[01... · Web...