Tesis Malbran-Trouillet

Nomenclador cartográco para personas
con discapacidad visual
Malbrán, Francisco G. - Trouillet, Germán E.
17 de septiembre de 2008
Resumen
El presente trabajo describe el desarrollo de una herramienta informática

que intenta apaciguar la problemática de la orientación de las personas con
discapacidad visual en un contexto urbano. Se efectúa un análisis de la relación
sociedad-individuo y una investigación acerca del problema particular, de la
disponibilidad y nalidad de recursos tecnológicos, y de los diferentes modos en
los que se ha intentado lograr el mismo objetivo. A partir de los conocimientos
adquiridos se realiza una propuesta de solución y se describe la especicación,
el diseño y la implementación de la utilidad resultante. Finalmente, se realiza
una evaluación sobre las características de la solución creada y se detalla un
conjunto de espectativas a satisfacer en el futuro próximo.
Índice general
1.. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.. Descripción del problema . . . . . . . . . . . . . . . . . . . . . . . 10

2.1. Contexto General . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2. La Discapacidad Visual . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1. El Mapa Mental . . . . . . . . . . . . . . . . . . . . . . . 11
2.3. La Solución Ideal . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.. Relevamiento de Herramientas Existentes . . . . . . . . . . . . . 17

3.1. Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.1. Trekker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.2. Sendero GPS . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.3. Otros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2. Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.1. Mapbender . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.2. Quantum GIS . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.3. El proyecto MBROLA . . . . . . . . . . . . . . . . . . . . 23
3.2.4. Navicore . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.5. TomTom . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.6. MapRed . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.7. Dragon NaturallySpeaking . . . . . . . . . . . . . . . . . . 24
3.2.8. Sphinx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.9. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3. Librerías . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.1. Mascopt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.2. GeoTools . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.3. FreeTTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.4. GDAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.5. FDO (Feature Data Object) . . . . . . . . . . . . . . . . . 28
3.3.6. OpenLayers . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.7. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5. Propuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.. Especicación y Diseño . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1. Especicación Z . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.1. Grafo simple de la ciudad . . . . . . . . . . . . . . . . . . 35
4.1.2. Con Costo para las aristas . . . . . . . . . . . . . . . . . . 38
4.1.3. Con nombre para las calles . . . . . . . . . . . . . . . . . 39
Índice general 4
4.1.4. Con numeración para las calles . . . . . . . . . . . . . . . 40

4.1.5. Con georeferencias . . . . . . . . . . . . . . . . . . . . . . 42
4.2. Diseño de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.1. Descripción del diseño . . . . . . . . . . . . . . . . . . . . 44
4.2.2. Descripción del diseño en TDN . . . . . . . . . . . . . . . 45
5.. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1. Comunicación Cliente-Servidor . . . . . . . . . . . . . . . . . . . 49
5.1.1. Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1.2. Servidor web . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.1.3. Computación Distribuida . . . . . . . . . . . . . . . . . . 50
5.1.4. Comunicación Cliente-Servidor del proyecto . . . . . . . . 51
5.2. Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.1. A estrella . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.2.2. Comparación entre las implementaciones de Dijkstra y A* 56
5.3. Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.3.1. Cliente para computadoras de escritorio . . . . . . . . . . 59
5.3.2. Cliente para dispositivos móviles . . . . . . . . . . . . . . 60
6.. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Apéndice 64
A..Manual de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
A.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
A.2. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
A.3. Instalación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
A.3.1. Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
A.3.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
A.3.3. Notas generales . . . . . . . . . . . . . . . . . . . . . . . . 66
A.4. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
A.4.1. Descripción y atajos de teclado . . . . . . . . . . . . . . . 67
A.4.2. Favoritos . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.5. Presentación de los resultados . . . . . . . . . . . . . . . . . . . . 69
B..Capturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
B.0.1. Capturas de Tiresias . . . . . . . . . . . . . . . . . . . . . 71
B.0.2. Capturas del cliente móvil sobre emulador java . . . . . . 77
1. Introducción
De los 85 millones de personas de América Latina que padecen dis-

capacidad, sólo el 2 por ciento encuentra respuestas a sus necesi-
dades, en tanto que las acciones de promoción de la salud, preven-
ción, recuperación, integración, rehabilitación e inclusión se hacen
imperativas. [1]
Es evidente que si bien la sociedad actual en la que nos vemos inmersos

va logrando día a día un mayor conocimiento cientíco acerca de la salud del
hombre y de cómo mejorarla, queda todavía una amplia gama de problemáticas
que al día de la fecha no son tratadas adecuadamente. La discapacidad es una
de ellas.
Según la Organización Mundial de la Salud, discapacidad es cualquier re-
stricción o carencia (resultado de una deciencia) de la capacidad de realizar
una actividad en la misma forma o grado que se considera normal para un ser
humano. Esta denición explicita simplemente una diferencia en la capacidad
de los individuos. Por otra parte, el enfoque sociológico de la palabra nos per-
mite entender que en la mayoría de los casos el problema principal del individuo
con discapacidad no sólo se conforma por el hecho biológico en sí, sino que es
gravemente acentuado por las incapacidades de la sociedad que lo contiene para
incluirlo de forma completa y precisa. El resultado es un conjunto de obstácu-
los impuestos por el entorno que complican considerablemente el desarrollo y
progreso en la calidad de vida de este grupo social.
Desde siempre la tecnología tiene a su disposición un amplio abanico de op-
ciones que, bien utilizado, puede disminuir de manera notable el conjunto de
restricciones establecidas por la sociedad. Si bien la soluciones óptimas posible-
mente se obtendrían estableciendo una comunión profunda entre modicación
estructural, máximo aprovechamiento de la tecnología y promoción de la con-
ciencia social, este trabajo intentará hacer un aporte a la comunidad a través de
la creación de una herramienta tecnológica. En particular, será la discapacidad
visual el eje motivador del desarrollo en cuestión.
Uno de los problemas más importantes que plantea la discapacidad visual
está íntimamente relacionado con la dependencia que genera. Especialmente a
nivel movilidad. El individuo precisa hacer un mapa mental del lugar por donde
se quiere mover, para lo cual le resulta indispensable entender e internalizar las
relaciones de espacio que existen en ese lugar. Esto sucede tanto en una casa (en
la que existe una cierta disposición de los dormitorios, muebles, llaves de luz,
enchufes, etc.), como en un mueble (con diferentes estantes, puertas, cajones,
etc.), como en un ómnibus (con asientos, ventanas, timbre, pasillo), como en
una ciudad.
No resulta difícil imaginar que las relaciones de espacio en una ciudad pueden
ser algo muy complicado de internalizar. Tampoco resultaría insólito pensar que
1. Introducción 6
ha de ser imposible mantener en la mente una cantidad tan inmensa de variables.

Cabe entonces preguntarse cómo es posible que una persona con discapacidad
visual (particularmente, un no vidente) sea capaz de viajar de un punto a otro
de la ciudad.
Para responder esta pregunta, intentemos pensar primero cuál es la serie de
pasos que realiza una persona vidente para lograr el mismo objetivo: supong-
amos que no conoce la ubicación de la dirección de destino. Entonces puede pre-
guntarle a un tercero, o consultar un mapa. Una vez que entiende hacia dónde
debe dirigirse, establece un trayecto que le resulte fácil de recordar. Finalmente
recorre el trayecto establecido y da cuenta de su posición relativa consultando
los nombres de las calles por las que se mueve o alguna referencia que haya nota-
do particularmente (una estación de servicio, una plaza, un museo, una avenida,
etc.).
En Córdoba, una persona discapacitada visual adquiere información del
medio generalmente a través de la consulta a un tercero. Esta consulta resulta
inevitable debido a que la información cartográca de la ciudad no se encuentra
disponible en un formato que tenga en cuenta su problemática. No existe, por
ejemplo, un nomenclador cartográco con relieve que permita identicar la for-
ma en que se conectan las calles y que esté referenciado enteramente en braille.
Este tipo de información tampoco se encuentra disponible para el público gen-
eral en un formato auditivo (como podría ser si existiera un número de teléfono
gratuito al cual llamar, en el cual una persona podría explicar qué proceso hemos
de seguir para llegar a un destino especíco). No se han producido mapas cuyos
colores y tamaños sean tales que personas con disminuciones visuales medias a
graves puedan interpretar. Concluyendo, toda la información cartográca de la
ciudad de Córdoba está disponible sólo para personas con buena visión.
Se genera casi automáticamente una interrogante fundamental: ¾por qué
existe esta carencia en nuestra sociedad? Existen varias posibles respuestas a
esta pregunta:
Para el caso hipotético de un nomenclador con relieve y en braille debemos
tener en cuenta que las letras en braille ocupan mucho más espacio que las letras
en tinta. Cualquier letra o símbolo en este método de escritura tiene dimensiones
de 7 milímetros de alto por 5 de ancho, además de necesitar una separación
de 3,5 milímetros entre los puntos 6 y 3 de dos símbolos consecutivos. Para
darse una idea de la diferencia de dimensiones que esto implica, un renglón de
este informe contiene aproximadamente 77 (setenta y siete) caracteres de ancho
contando los espacios. Un renglón de escritura braille puede variar la cantidad
de caracteres de ancho entre 26 (ventiséis) y 30 (treinta) como máximo (con
márgenes mínimos). Y en una hoja completa el porcentaje de diferencia es aún
mayor, debido a la altura de los símbolos.
Podría pensarse que dadas las circunstancias mencionadas (un símbolo braille
no se puede comprimir porque se vuelve ilegible) la construcción del tal producto
revelaría como resultante a un nomenclador cartográco gigantesco, inmanejable
o poco práctico para el usuario. Pero no puede negarse la presencia de la du-
da ante la ausencia del intento. Sin ir más lejos, recientemente (en Febrero del
2008) en San Francisco, Estados Unidos, la empresa LightHouse for the Blind
and Visually Impaired
1 en colaboración con el Smith-Kettlewell Eye Institute2
1 http://www.lighthouse-sf.org/
2 http://www.ski.org/
1. Introducción 7
lanzó un programa de creación y distribución a pedido de mapas táctiles. El

proyecto consiste en un servicio gratuito de creación de mapas táctiles con ref-
erencia braille del barrio que se solicite. Un individuo puede realizar su petición
a un teléfono particular, y una semana más tarde el producto deseado llega a
sus manos a través del correo.
Para el caso de la información disponible a través de audio y la propues-
ta planteada como ejemplo, se puede argüir simplemente que no ha habido
una iniciativa al respecto. Esta solución sería poco costosa y podría ser muy
útil. Asimismo, la tarea de creación de mapas (o nomencladores) en colores y
tamaños útiles para personas con disminución visual podría ser asumida por
alguna entidad gubernamental (o institución sin nes de lucro).
Existen, por supuesto, ciertos productos comerciales que podrían satisfacer
distintas partes de las necesidades aquí mencionadas. Los navegadores GPS
3
comúnmente utilizados en vehículos de alta gama realizan cálculos y dan in-
strucciones precisas sobre el lugar en que uno se encuentra y cómo ir hacia
dónde uno quiere dirigirse. Todo dinámicamente. Si bien no están construidos
especícamente con el objetivo de tener en cuenta a las personas con discapaci-
dad visual (muchos de ellos utilizan touch-screens
4 y en general son pequeños)
algunos poseen la característica de reconocer comandos de voz y dar instruc-
ciones vía una voz electrónica. Además su propiedad característica de reconocer
la posición global del aparato a través de satélites le ahorra al individuo el tener
que explicar dónde se encuentra (incluso podría no saberlo).
Han existido algunos inventos que intentaron disminuir la dicultad que
representa caminar por una zona desconocida sin un grado de buena visión. A
nes del 2006, por ejemplo, la Universidad Tecnológica Nacional (UTN) (Buenos
Aires) estaba desarrollando una serie de proyectos con este n liderados por
el ingeniero José Luis Cabrera. Entre los productos que se crearon se puede
destacar un bastón ultrasónico que adherido al bastón tradicional avisa cuando
hay obstáculos próximos a una altura media o alta, y una brújula electrónica
que emite diferentes tipos de sonidos dependiendo de la orientación en que se
encuentra.
Existen otros sistemas basados en GPS (Trekker, Sendero GPS entre otros)
construidos especícamente para el caminante no vidente. Sin embargo el prob-
lema de estos, así como de la mayoría de los productos que tienen en cuenta
alguna problemática particular y son desarrollados por empresas privadas, es
que el objetivo de su desarrollo apunta a un mercado, en vez de a un aporte hu-
manitario. Esto implica que su construcción no será masiva, y los costos serán
más parecidos a los de un producto artesanal. Como consecuencia los precios
nales que manejan estas instituciones son deliberadamente altos, lo que dismin-
uye notablemente la posibilidad de erradicar un problema de integración social.
Todo lo contrario. Este hecho promulga una nueva sectorización y establece un
nuevo obstáculo por vencer: el económico.
Surge a partir de esta última conclusión un punto de debate: ¾por qué una
empresa que desarrolla productos se va a ver privada de su derecho a obtener
una retribución económica? ¾Sólo porque sus productos apuntan a un sector
social minoritario? Detrás de cada empresa hay un grupo de trabajadores que
3 GPS: Global Position System (Sistema de Posicionamiento Global)

4 Los touch-screens o pantallas sensibles al tacto podrían utilizarse de manera muy prove-
chosa en pro de la problemática tratada, sin embargo todavía no se ha explotado su capacidad
en este sentido
1. Introducción 8
merece una retribución por su trabajo, más allá de la nalidad de los pro-
ductos que desarrollen. Entonces, indefectiblemente, entra en escena el Estado.
Quizás si el Estado tuviera un rol más protagónico en esta interacción particu-
lar de empresa-cliente (como sucede en algunos países de Europa y en Estados
Unidos) se podrían alivianar los precios al consumidor nal. Incluso podría ser
que las empresas desarrolladoras de este tipo de productos fueran directamente
estatales, y no privadas.
En base a este análisis de la sociedad y apuntando a la disminución de la
brecha existente entre las posibilidades de todos sus integrantes, en este trabajo
se plantea la creación de un software que ponga a disposición de la comunidad
toda los datos cartográcos de la ciudad de Córdoba en un formato audiovi-
sual adecuado a la problemática que se remarca. Se desea brindar facilidades
tales que la interacción con una persona discapacitada visual sea lo más amena
posible. Se espera que aquella pueda entonces realizar consultas sobre el cómo
desplazarse de un punto a otro del mapa y cuáles son las relaciones espaciales de
un trayecto sugerido. Es esperable también que la utilización de este software
facilite la creación de mapas mentales tanto de trayectos a realizar como de
zonas particulares de la ciudad.
Es importante mencionar que dependiendo de las funcionalidades que se
deseen, podríamos encontrarnos con que el desarrollo planteado en este proyecto
sea un trabajo de inmensa envergadura. Para paliar este hecho se utilizarán, en
lo posible, otros desarrollos ya existentes y de libre disponibilidad. Se propone,
por supuesto, que una vez concluido, este desarrollo se ponga a disposición de
la comunidad de manera libre.
Un obstáculo que podría haber comprometido el éxito de este trabajo es
el de la obtención de las bases de datos geográcos de Córdoba. Las mismas,
por el inmenso trabajo de relevamiento que implica generarlas, tienen un costo
comercial que nos priva de su obtención a menos que logremos encontrar los
mecanismos tales que, sin comprometer la funcionalidad del sistema propuesto,
protejan la condencialidad de los datos.
En el siguiente capítulo se desarrollará una descripción más detallada del
contexto social y la problemática particular sobre los que se basa este trabajo.
A partir de este análisis se describirá una solución ideal que, sin tener en cuenta
las limitaciones de recursos y posibles dicultades, ponga de maniesto todas
las características deseables.
El capítulo 3 estará conformado por un relevamiento de material que resulte
pertinente a la hora de diseñar la aplicación. Se pretende estudiar la forma en que
la problemática ha sido tratada en oportunidades anteriores, concebir ideas para
la solución a desarrollar, y encontrar herramientas que faciliten este desarrollo.
A partir de los resultados de tal relevamiento, se propondrá una aplicación
teniendo en cuenta tanto las dicultades por sortear como las facilidades que
estén a disposición.
En el capítulo 4, se utilizarán métodos formales para detallar tanto la es-
pecicación del sistema a contruir como su diseño. La especicación estará fo-
calizada en el manejo de la representación abstracta de los datos cartográcos
y se realizará incrementalmente a los nes de facilitar su entendimiento.
El capítulo 5 abarcará todo aquello que se relacione con la implementación
del programa. Esto incluirá un análisis de las opciones que podrían adoptarse a
la hora del desarrollo, la justicación de la elección de una de ellas, y nalmente
la descripción de la forma en que se contruyó la herramienta.
1. Introducción 9
El capítulo 6 incluirá conclusiones acerca del trabajo tales como: funcional-

idades ofrecidas, impacto social, características (robustez, extensibilidad, mod-
ularidad, etc), posibilidades de extensión, necesidades del marco contextual,
propuestas generales, etc.
En los apéndices se ofrecerá: un manual del usuario para la aplicación desar-
rollada (impreso en tinta y en braille), un CD con la aplicación y datos extras,
y una demostración de funcionalidad con imágenes.
2. Descripción del problema
2.1. Contexto General

En el libro Discapacidad: lo que todos debemos saber [1] los doctores E. Alicia
Amate y Armando J. Vázquez
1 señalan que un alto porcentaje de las personas
con pérdidas funcionales que han atendido no sufrirían deciencias o discapaci-
dades si hubieran sido tratados al comienzo de su enfermedad o trauma por un
médico con conocimientos básicos sobre las funciones inherentes a la indepen-
dencia física, social, educacional y laboral. Y agregan a esta armación que La
falta de información y de un enfoque que encare globalmente la patología y sus
consecuencias con frecuencia origina discapacidades.
Nótese el peso y la importancia de la palabra origina. Estos datos explicitan
de manera unívoca que las sociedades latinoamericanas sufren de un conjunto
importante de falencias en lo que reere a la atención y prevención de discapaci-
dades. En consecuencia, la persona con discapacidad se enfrenta continuamente
a una sociedad que no está enteramente preparada para integrarlo. Surge como
resultado de este enfrentamiento la imposibilidad de gozar de buena salud, en
el sentido más amplio y abarcativo de este concepto. La sociedad discapacitada
aumenta la discapacidad individual.
En Córdoba capital existen innumerables falencias que, al convertirse en
obstáculos o dicultades, disminuyen la salud del grupo de personas referido.
Por nombrar algunas:
Casi no existe transporte público con puertas sucientemente amplias y/o

facilidades para permitir el ascenso o descenso de individuos en silla de
ruedas.
Carencia de rampas para silla de ruedas en numerosos sectores de la ciu-

dad.
Carencia de semáforos especiales para personas discapacitadas visuales en

casi la totalidad de la ciudad, salvo excepciones.
Prácticamente no existen indicaciones en braille en sitios estratégicos tales

como los postes de nombre de las calles, paradas de colectivo, ascensores,
Centros de Participación Comunal (CPC's), cajeros automáticos, etc.
Es importante notar que estos obstáculos convergen a un papel fundamen-

tal como limitadores de la autonomía de la persona con discapacidad. También
cabe recalcar que la discapacidad no sólo afecta a la persona que la sufre, sino
también a todo su entorno: las personas que toman cuidado de ella, los famil-
iares, la sociedad misma. La ausencia de políticas, legislaciones y proyectos que
1 Tanto el Dr Vázquez como la Dra Amate son médicos especialistas en rehabilitación

2. Descripción del problema 11
tengan en cuenta la discapacidad y que sean efectivamente aplicadas conlleva un

agravamiento en la calidad de vida de la sociedad en general, afectando partic-
ularmente la salud de las personas referidas y extensivamente el entorno social
que las contiene.
Cuando una persona se ve afectada por la sociedad en su capacidad de ser
independiente, ve a la vez mitigada su calidad de vida. Se encuentra impedida
por el entorno a realizar tareas para las cuales posee la capacidad, y en conse-
cuencia interioriza la certidumbre de una dependencia que la limita. Se genera,
por lo tanto, un acontecimiento particular que podría denominarse discapaci-
dad social. Es evidente que esta situación es una poderosa fuente de malestares
en las personas que la sufren, y entonces puede percibirse que resulta un obje-
tivo primordial el de realizar las acciones pertinentes que sean necesarias para
maximizar el grado de autonomía de todos los individuos con discapacidad.
En la 138a Sesión Del Comité Ejecutivo llevada a cabo por la Organización
Mundial de la Salud y la Organización Panamericana de la Salud se hace ref-
erencia al Manual de Desarrollo Inclusivo [2] haciendo incapié en el punto que
explicita la importancia y necesidad de La elaboración e implementación de ac-
ciones y políticas encaminadas para el desarrollo socioeconómico y humano que
apuntan a la igualdad de oportunidades y de derechos para todas las personas, in-
dependientemente de su estatus social, género, condiciones físicas, intelectuales
o sensoriales y de su raza
2.2. La Discapacidad Visual

Discapacidad visual reere a una pérdida total o parcial de la visión. Partic-
ularmente, se dice que una persona padece de ceguera cuando su grado de visión
en el ojo es menor a 20/400 (considerando el ojo con mayor sentido de visión
y con la mejor correción posible). Por otra parte, el concepto de baja visión
está relacionado a individuos que, aún con la mejor corrección y su mejor ojo,
no tienen un grado de visión suciente (no supera los 3/10) y/o presentan un
campo visual de 20 grados o menos.
2.2.1. El Mapa Mental

Las personas con un buen grado de visión utilizan el sentido de la vista
para adquirir aproximadamente un 80 (ochenta) por ciento de la información
generada por el entorno social. Esta información incluye datos acerca de la dis-
posición de los objetos, las relaciones de distancia entre ellos, los materiales
que los conforman, la dinámica de los integrantes del entorno (individuos, ve-
hículos, objetos), etc. y en consecuencia permite realizar conclusiones acerca de
qué sectores son más aptos para desplazarse de manera segura, los posibles peli-
gros u obstáculos que se pueden presentar, el esfuerzo que presentará realizar un
trayecto particular, etc. En pocas palabras, las imágenes son el recurso principal
que utiliza el vidente para relacionarse con su entorno.
La persona discapacitada visual genera mapas mentales que le permiten in-
teriorizar muchas de las relaciones que el vidente realiza dinámicamente. Una
vez que logra tener una conciencia interiorizada acerca de las relaciones espa-
ciales de su entorno, se puede mover a través de él con mucho más seguridad
que cuando desconoce por completo cuáles serán los obstáculos que se puede
encontrar.
Alex Wade, partícipe del proyecto llevado a cabo por la empresa LightHouse
for the Blind and Visually Impaired en el que se brindan mapas en relieve a per-
2
sonas discapacitadas visuales , comenta en un reportaje realizado por la estación
3
de radio KQED que existe una parte del cerebro encargada de conservar la in-
formación visual adquirida. Esto implica que se conserva no sólo la sensación de
la imagen, sino toda la información que a través de ella se adquiere, incluyendo
todas las relaciones que una persona vidente utiliza para desplazarse a través
de su entorno. Particularmente, esta parte del cerebro es capaz de conservar la
imagen de un mapa que se haya consultado para saber como llegar a un punto
especíco de una ciudad. Se remarca en este reportaje que la discapacidad visual
está vinculada exclusivamente a una deciencia de algún tipo en el órgano visual,
pero que carece de relación alguna con las funcionalidades del cerebro (excepto
por un tipo muy particular de ceguera en la que el cerebro es el casuante de la no
visión). Luego las personas que sufren de esta discapacidad poseen aquélla parte
del cerebro totalmente funcional. Sin embargo, como cualquier parte del cuerpo
que no se está acostumbrado a utilizar, debe existir un proceso de aprendizaje
y estímulo para permitir un aprovechamiento máximo de esta facultad.
Cabe distingir en este punto entre las personas cuya discapacidad fue adquiri-
da a una edad avanzada (adolescente, adulto) y aquéllas que la poseen desde el
nacimiento o desde los primeros años de vida. La persona que adquiere la dis-
capacidad a una edad avanzada, cualquiera fuera el causal, ya está acostumbrada
a utilizar la funcionalidad mencionada de manera regular para relacionarse con
su entorno. De esta manera, tiene la capacidad de realizar analogías entre la
información que adquiere ya sea verbalmente o a través del sentido del tacto y
aquella que recibía anteriormente a través del sentido de la visión. Conoce la
diferencia entre ver y no ver, y entonces puede generar una imagen mental a
través de los datos que adquiere y conservarla para utilizarla luego como guía a
la hora de desplazarse por el entorno detallado.
La persona que posee la discapacidad desde el nacimiento o la temprana edad
puede tener mayores dicultades para lograr el mismo cometido. Sin embargo,
es totalmente posible. La contínua práctica y experimentación de relacionar lo
detallado verbalmente o diagramalmente y la actividad misma de recorrer los
espacios descriptos le permite desarrollar la habilidad de crear mapas mentales
de una forma tan útil como lo es para el resto de las personas. Alex Wade padece
ceguera desde la edad temprana de 4 años, y está seguro de que este método es
sumamente útil y enriquecedor para la persona discapacitada visual.
2.3. La Solución Ideal

¾Cuál sería, entonces, la solución ideal que le permita a una persona con
discapacidad visual desplazarse de manera autónoma por una ciudad? En lo
particular, se va a suponer una solución ideal desde el punto de vista de lo
tecnológico, sin hacer referencia a cambios estructurales en la sociedad (como
rotular todos los postes de nombre de calle con braille) ni en las políticas de la
comunidad para promover la conciencia social respecto de esta problemática.
2 ver Introducción
3 http://www.kqed.org/quest/radio/view/747
Algunos puntos a considerar para imaginar el desarrollo de una herramienta

tecnológica ideal podrían ser los siguientes:
Que ponga a disposición la información cartográca de la ciudad en un

formato adecuado.
Que permita consultar acerca de cómo llegar a una zona especíca de la

ciudad.
Que pueda dar cuenta de la posición actual del individuo en el trayecto

que está realizando.
Que sea portable
Que la forma de interacción con el usuario sea lo más sencilla y dinámica

posible
Que brinde información acerca de los medios de transporte utilizables para

llegar a un punto de la ciudad. Esta información podría incluir no sólo el
recorrido del transporte, sino también sus puntos de parada, los horarios
a los que se puede acceder a éstos, cómo llegar desde el punto actual hasta
un punto de parada, algún método que permita entender en qué punto de
parada se debe descender, y la información para llegar desde el punto de
descenso hasta el punto de destino deseado.
Que brinde información acerca de posibles puntos de interés (hospitales,

farmacias, centrales de policia, comercios, plazas, polideportivos, estadios,
etc.). Esta información podría brindarse conjuntamente a la forma de
recorrer un trayecto (los puntos cercanos a los lugares por donde se fuera a
caminar) o solicitarse respecto de un punto especíco (como por ejemplo:
¾qué hospitales existen cerca de esta dirección?)
Que pueda informarse y brindar información acerca de eventos especícos

relevantes a el recorrido de un trayecto (por ejemplo: una calle que se en-
cuentra en remodelación, un accidente vial, una manifestación anunciada,
etc.)
Para empezar a gurarse la solución buscada, se puede pensar que la misma

será un artefacto. Una computadora de bolsillo. De esta forma ya tendríamos
solucionado el ítem de la portabilidad. Esta computadora ofrecería característi-
cas técnicas avanzadas que le permitieran toda la funcionalidad que se precise
para lograr los objetivos deseados.
La interacción con el usuario podría realizarse por medio de un mini teclado
incorporado (como sea el de un celular o el de algunos modelos de Pocket PC)
y parlantes o auriculares. Parte de la funcionalidad del software instalado en
la máquina podría ser que una voz electrónica indique qué botones se están
apretando, al igual que realizan tantos paquetes de software existentes para las
PC estándares que se encuentran hoy en el mercado.
Una alternativa a este modelo de interacción con el usuario podría ser la
utilización de las anteriormente mencionadas touch-screens, o pantallas sensi-
bles al tacto. Muchos modelos de pocket PC utilizan este medio como medio
fundamental de interacción con sus usuarios, sin embargo, la utilización de este
mecanismo se realiza de manera estrictamente visual. Para adaptar esta fun-

cionalidad de manera tal que sea útil al grupo de personas referido, se precisaría
que el software del aparato indique sobre qué partes de la pantalla se está pasan-
do el dedo (la utilización de un lápiz electrónico quizás no sería aprovechable,
el dedo resulta una herramienta harto instintiva para apuntar a lo que se quiere
y entender la disposición de objetos en la pantalla).
Finalmente, como última alternativa de modelo de interacción, se puede pen-
sar en la utilización de la voz y el sonido. Esto requeriría que la herramienta
disponga de un micrófono incorporado. En la actualidad existe una amplia var-
iedad de software de reconocimiento de voz. Si bien éste es un apartado en
contínuo desarrollo e investigación, existen ya en el mercado algunos productos
que utilizan esta característica. Este parece ser el medio más intuitivo y sencillo
que podría considerarse para interactuar con el usuario, ya que es el método que
se utiliza normalmente para interactuar con las personas. Es lo más cercano posi-
ble a realizar consultas a un tercero. Si bien existiría un período de aprendizaje
en el que se deberían aprender los comandos a los que el aparato reacciona
y cuáles son las consecuencias de ejecutarlos, este detalle estaría presente en
cualquiera de los métodos anteriormente mencionados. Quizás el método de la
pantalla sensible al tacto fuera el que menos precisara de un manual o intructivo
introductorio, debido a que resultaría el más intuitivo. Sin embargo, con una
interfaz lo sucientemente amigable, la interacción a través de la voz y el audio
podría brindar resultados óptimos.
Para poner a disposición del usuario la información cartográca de una ciu-
dad en un formato adecuado a la problemática que se trata, sería necesario que
estos datos se encuentren digitalizados. Debe existir una base de datos que con-
tenga toda la información de la ciudad a la que se reera, teniendo en cuenta
no sólo la disposición relativa de las calles entre sí, sino también la georefer-
enciación
4 de cada ítem que se encuentre en la base. La información, evidente-
mente, sería presentada en formato de audio, dadas las características de la her-
ramienta que hemos hipotetizado hasta el momento. Esta presentación podría
incluir datos como: el barrio en que se encuentra una dirección solicitada, calles
cercanas a la misma, construcciones importantes (museos, monumentos, etc.),
comercios y servicios (hoteles, farmacias, shoppings, cines, etc.), entre otras.
Otra información importante que se brindaría sería qué tipo de infraestructura
especíca existe en una zona particular, o en la zona que atraviesa el camino.
Esta información incluiría semáforos con sonido, indicaciones braille, etc.
Sería útil también que se pudiera congurar un conjunto de lugares que
fueran de consulta frecuente, como por ejemplo la casa del usuario y las de sus
parientes, su escuela o lugar de trabajo, etc. Esta utilidad permitiría referenciar
tales lugares por un pseudónimo tal como Hogar en vez de tener que precisar
la dirección especíca.
Otra característica deseable sería que la herramienta en sí misma sea in-
dependiente de los datos sobre los cuales se desea realizar consultas de tipo
cartográco. Es decir, que se conserve toda la funcionalidad más allá de si los
datos digitalizados detallan a la ciudad de Córdoba, Argentina, o bien a la ciu-
dad de Córdoba, España. Esto permitiría que usuarios de distintas partes del
mundo puedan utilizar la herramienta si en su ciudad ya existe una base de
datos digitalizada de la cartografía del lugar, simplemente intercambiando las
4 Posición absoluta de latitud-longitud

bases de datos que se utilizan. Sería importante que el método a través del cual
se intercambien los datos sea lo más sencillo y ameno posible, por ejemplo, a
través de una opción de conguración simple que permita seleccionar alguna
de las distintas bases que ya estén cargadas en la herramienta. Otra opción de
actualización podría conectarse a un sitio de internet para buscar bases de datos
nuevas. En este sitio usuarios de todo el mundo podrían subir bases de datos
de su ciudad. Sería altamente productivo si los gobiernos pudieran colaborar en
este sentido, brindando sitios de internet con información geográca digitalizada
y actualizada que se pueda acceder a través de este mismo medio para mantener
las bases de datos de la herramienta tan al día como fuera posible.
La presentación de los datos cartográcos también incluiría conjuntos de in-
strucciones verbales para realizar un trayecto particular, con indicaciones que
permitirían al usuario sentirse lo más seguro posible acerca de cómo llegar hasta
el destino deseado. Para ser óptimos en la utilización de este recurso, la her-
ramienta debería ser capaz de guiar al usuario paso por paso, y para ello el con-
junto de instrucciones debería ser entregado de manera paulatina. Como efecto
de tener en cuenta este detalle, podría considerarse la existencia de un comando
que pause la instrucción hasta nuevo aviso. De esta forma el usuario podría
avisar cuándo se encuentre en el punto próximo y escuchar la/las instrucciones
siguientes (según él considere necesario). Como alternativa, las instrucciones po-
drían pronunciarse de a un paso por vez, teniendo el usuario que avisar cuándo
quiere que se pronuncie la siguiente. Puede pensarse en comandos similares a
disposición del usuario tales como avanzar y retroceder.
Sería útil que el usuario pueda consultar en cualquier momento en qué punto
del trayecto se encuentra y cuál es la próxima instrucción que debería realizar.
Para lograr esto la herramienta debería contar con algún tipo de sensor de
movimiento o accesorio que le permita estar al tanto de cuál fue el trayecto
recorrido real hasta ese momento. La tecnología actual que permite la adquisi-
ción de esos datos es la basada en GPS (Global Position System). Entonces,
supondremos que la herramienta cuenta con un sistema de posisicionamiento
global que le permite darse cuenta de cuál es la posición actual del individuo.
Este accesorio solucionaría la forma en que se deben ir dando las instrucciones,
ya que éstas serían brindadas sólo cuando deban ser ejecutadas y no en otro
momento. Esta capacidad también permitiría saber si el individuo se ha desvi-
ado del trayecto que deseaba realizar y avisar ante este hecho. Si el individuo
se ha desviado porque se encontró con un obstáculo insuperable (como un corte
de calle o una construcción nueva) aquél podría informarle a la herramienta
(a través de algún comando especíco) el dato de que allí hay un obstáculo y
en consecuencia la herramienta regeneraría el trayecto evitando pasar por ese
punto, de ser esto posible, o informaría que no existen caminos alternativos que
permitan llegar a destino.
De esta situación analizada se puede pensar en la posibilidad de que exista la
opción de permitir al usuario establecer que existen ciertas partes de la ciudad
por las que no se quiere transitar. Por ejemplo, un usuario podría saber que
cierta calle, a una determinada altura, carece de vereda. O bien que existen
determinados barrios que se consideran marginales y por los cuales preferiría
no tener que caminar. Sería importante que tales conocimientos puedan quedar
plasmados en los datos que maneja el programa para que este genere trayectos
que no incluyan estos puntos de conicto. Si no existiera trayecto posible la
herramienta debería avisarle al usuario que no es posible realizar el trayecto
deseado si no se atraviesa determinado obstáculo por él especicado.

Una característica que sería de suma utilidad, sería la posibilidad de contem-
plar dentro de los datos que utiliza el artefacto, una base de datos del transporte
que circula por la ciudad. Esta base de datos serviría como fundamento de una
funcionalidad que resuelva una alternativa a generar un trayecto para realizar
a pie. Esta funcionalidad permitiría saber qué medios de transportes son útiles
para llegar al destino solicitado, cuál es el trayecto desde la posición actual has-
ta el lugar más cercano donde podamos hacer uso de este transporte, cuál es
el trayecto desde el lugar de descenso del medio de transporte hasta el destino
solicitado, cuál sería el costo del pasaje (o los pasajes si tuvieramos que utilizar
más de un medio), horarios, etc. La característica de tener la información de
la posición del trayecto en que se encuentra el usuario en todo momento sería
la encargada de realizar la advertencia oportuna cuando el usuario esté cerca
del lugar de descenso. Sería importante que todas esta información se encuentre
disponible en un servidor que se mantenga actualizado para evitar brindar datos
erróneos.
3. Relevamiento de Herramientas
Existentes
En este capítulo se describirá el resultado de un relevamiento realizado en

busca de herramientas y/o soluciones existentes. El objetivo de tal relevamiento
fue el de analizar las formas en que se ha atacado la problemática en el pasado,
prever contratiempos, contemplar dicultades y basados en esta información ser
capaces de tomar buenas decisiones en lo que respecta al diseño y el proceso
de implementación del software que se desea. En esta búsqueda fue también
una expectativa primaria la de encontrar herramientas especícas de software
libre que permitieran reducir y simplicar la cantidad de tareas que plantea el
desarrollo de este proyecto de tesis.
3.1. Dispositivos
Existen algunas herramientas en el mercado cuya funcionalidad es la misma
que se busca conseguir con este proyecto:
3.1.1. Trekker
Trekker
1 es un dispositivo creado por HumanWare, que utiliza tecnología
GPS y mapas digitales para ayudar a la persona discapacitada visual a abrirse
camino tanto en zonas urbanas como rurales. Permite a los usuarios conocer
la localización en la que se encuentran (el nombre de la calle, calles cercanas),
descubrir lugares interesantes cerca de su posición (como hoteles, restaurantes,
etc.), establecer puntos de interés y notas tanto de manera escrita como oral,
conocer el cómo llegar hasta un destino especicado, y actualizar el software
del dispositivo desde internet. Ofrece la posibilidad de comprar mapas digitales
online para luego utilizarlos como base de datos para planeamiento de rutas y
reconocimiento de áreas y es completamente actualizable. Sus principales car-
acterísticas son:
Detección de información en tiempo real (intersecciones, puntos de in-

terés).
Navegación de mapas en tiempo real y o-line (previsualización de rutas)
Planeamiento y almacenamiento de rutas.
Creación vocal de puntos de interés.
1 http://www.humanware.com/en-international/products/gps/trekker
3. Relevamiento de Herramientas Existentes 18
Fig. 3.1: Dispositivo GPS Trekker
Acceso a la información de estado del GPS.
Liviana y portable
Su costo aproximado es de 1700 euros y los mapas se compran por separado.
3.1.2. Sendero GPS

Sendero GPS
2 es un dispositivo creado por el Sendero Group que ofrece car-
acterísticas similares a Trekker, permitiendo a la persona discapacitada visual
establecer rutas, realizar paseos virtuales para el planeamiento de las mismas
(simular el recorrido del sendero para saber por ejemplo con qué facilidades se
encontrará en el camino), agregar puntos de interés, informar acerca de facili-
dades y servicios cerca de la localización del usuario (hoteles, farmacias, etc.),
tomar notas, crear, guardar y borrar rutas tanto para realizar a pie como en al-
gún vehículo, invertir rutas guardadas, conocer intersecciones, consultar cuántos
satélites se encuentran conectados en un momento particular, adquirir informa-
ción de latitud, longitud, altura, y direcciones. Su costo aproximado también
media los 1700 euros.
3.1.3. Otros
Existen otros productos que ofrecen características muy similares a los an-
teriormente mencionados. Entre ellos se puede mencionar el PAC Mate GPS,
desarrollado por FreedomScientic
3 que consiste en tres productos trabajando
mancomunadamente para lograr un sistema de navegación GPS para la per-
sona discapacitada visual con las mismas funcionalidades que los anteriormente
mencionados. Esta pack precisa de:
2 http://www.senderogroup.com/shopgps.htm
3 http://www.freedomscientic.com/
Fig. 3.2: Dispositivo GPS Sendero
Fig. 3.3: Dispositivo PAC Mate
PAC Mate: Un dispositivo PDA para personas discapacitadas visuales.

4
StreetTalk: Software instalable en PAC Mate utilizado para la navegación

GPS.
5
Bluetooth GPS Receiver: El receptor de señal GPS.
Para adquirir el paquete completo es necesario un presupuesto aproximado

de entre 3000 y 6500 dólares (dependiendo de si la PDA contiene visualización
braille, si se adquieren todos los mapas disponibles, etc). A mediados del 2003
la European Space Agency
6 junto a otras organizaciones estaban testeando
un producto de características símiles a las aquí expuestas denominado Tormes,
utilizando un sistema de navegación por satélite denominado Egnos. Sin embargo
sólo se encontró información acerca de un probable lanzamiento del cuál no se
han conocido mayores detalles.
Existen también otra serie de dispositivos que si bien no son especícos al
problema que se plantea podrían ser de utilidad a la hora de establecer una
solución:
4 http://www.freedomscientic.com/products/fs/pacmate-product-page.asp
5 http://www.freedomscientic.com/products/fs/streettalk-gps-product-page.asp
6 http://www.esa.int/esaCP/index.html
Fig. 3.4: Sonic Pathnder
The Sonic Path Finder (Buscador sónico de caminos)

El Sonic Path Finder
7 es un artilugio para facilitar la movilidad de personas
con discapacidad visual en entornos abiertos. Surge a partir de la Unidad Blind
Mobility Research en la Universidad de Nottingham, Inglaterra, alrededor de
los años '80. Este dispositivo le da al usuario advertencias avanzadas sobre
objetos que se encuentren en el recorrido que aquél se encuentra realizando. Si
no hay objetos en su camino se congura automáticamente a un modo de baja
prioridad en el que se detectan límites entre tierra y agua.
El dispositivo es un sistema sonar controlado por un microprocesador que
utiliza ecos y pulsos y que se monta en la cabeza del usuario. Cuenta con 5
(cinco) transductores, 2 (dos) emisores y 3 (tres) receptores que se encargan de
emitir señales y capturar ecos respectivamente. Los receptores están ubicados
uno al frente y uno a cada lado de la cabeza. Cuando los receptores reciben un
eco, la señal es enviada al micro procesador que se encarga de generar señales
que serán enviadas a alguno de los parlantes ubicados en los oídos dependiendo
de la ubicación del objeto detectado. Un sonido se enviará al parlante derecho
si el objeto se encuentra a la derecha del usuario, o a la izquierda en situación
análoga, o bien será reproducido por ambos auriculares si el objeto se encuentra
al frente del caminante.
C2 Talking Compass:
C2 Talking Compass
8 se trata de una brújula de mano operada con baterías
y con salida de voz digital. Creada por Sensory Tools, contiene en su parte
superior un botón de activación y en un lateral un botón de tres posiciones que
permite cambiar el estado de apagado a encendido con alguno de los dos idiomas
disponibles (que pueden ser determinados al momento de la compra). La brújula
pronuncia cada uno de los 8 puntos cardinales determinables con una voz digital
7 http://web.aanet.com.au/tonyheyes/pa/pf blerb.html
8 http://www.sensorytools.com/c2.htm
Fig. 3.5: C2 Talking Compass
Fig. 3.6: Laser Cane
clara. Para las personas con baja visión se representa un código de tres luces
que puede verse a través de la carcasa semitransparente y que representa cada
una de las direcciones posibles.
Su precio varía entre 70 y 90 dólares dependiendo de si se eligen los idiomas
por defecto (inglés y español) o se requieren idiomas personalizados.
Laser Cane:
Laser Cane
9 es un bastón blanco para ciegos con el agregado tecnológico
de la electrónica. El bastón provee información avanzada sobre obstáculos en el
camino. Puede detectar objetos en tres niveles de altura y advierte al usuario
de la existencia de los mismos a través de tonos audibles o de vibraciones bajo
el dedo índice. Permite estimar distancias hacia adelante así como hacia los lat-
erales, se puede doblar en dos secciones para su almacenamiento, utiliza baterías
y puede ser utilizado en cualquier tipo de ambiente (abierto, cerrado, amplios,
pequeños, etc.)
Su precio es de 2995 dólares.
9 http://www.maxiaids.com/store/prodView.asp?idstore=1&idproduct=6247
3.1.4. Conclusiones
Respecto de este relevamiento, pueden realizarse varias reexiones. En primer
lugar, los productos que apuntan directamente a la problemática tratada por este
proyecto poseen un precio comercial elevado (por encima de los 2000 dólares) lo
cual diculta su adquisición en países sin políticas sociales importantes (como
Argentina). Además, en general estos productos sólo cuentan con información
geográca de países muy desarrollados, dejando en segundo plano al resto y en
consecuencia limitando su utilidad.
En segundo lugar, es notable cómo se ha detenido el progreso de la mayor
parte de los productos relevados. A pesar de que las tecnologías utilizadas (el
GPS, los lectores de pantallas, etc.) se han visto en una constante evolución,
los productos (en general) no han sido modernizados con el correr de los años.
El ejemplo más contundente es el Sonic Path Finder, desarrollado alrededor de
los 80 y sobre el cuál no se halla nueva información acerca de su desarrollo. Así
como el producto Tormes, que alguna vez estuvo en desarrollo y del cual no se
conocen noticias desde su anuncio de lanzamiento (2003). Trekker parece ser el
dispositivo más actualizado y con mayor vigencia y seriedad en este sentido.
Por último, hay una amplia variedad de artefactos muy útiles y accesibles
pero que no atacan la problemática central del proyecto. Este tipo de dispositivos
resulta útil como complemento a la persona invidente o disminuida visual en su
tarea diaria de movilización (la brújula parlante, el bastón blanco con detector
de obstáculos) pero no ofrecen información alguna acerca de la cartografía del
contexto en el cual la persona se desenvuelve.
3.2. Aplicaciones
3.2.1. Mapbender
Mapbender
10 es una aplicación programada en PHP y JavaScript para la
consulta de mapas. Todos los datos son leidos directamente y de forma dinámi-
ca desde un banco de datos, de la misma manera que en un Sistema de Gestión
de Contenidos
11 . Se puede decir por tanto, que Mapbender es un CMS de datos
geográcos y por ello se suele usar a menudo como software para la creación
de portales web con información geográca. El software incluye una interface
denida que ofrece funciones de visualización, navegación y consulta de servicios
estándar OGC
12 . Mapbender se puede integrar practicamente en cualquier sis-
tema homogéneo y página de internet. El software es compatible con cualquier
servicio de mapas y datos que sea creado basado en las especicaciones OGC y
por eso puede ser usado para un amplio abanico de programas GIS y clientes
de IDEs de fabricantes diversos.
10 http://www.mapbender.org/index.php/Main Page
11 Un Sistema de gestión de contenidos (Content Management System en inglés, abrevia-
do CMS) es un programa que permite crear una estructura de soporte para la creación y
administración de contenidos por parte de los participantes principalmente en páginas web
12 Del inglés: Open Geospatial Consortium. Se trata de una organización voluntaria interna-
cional sin nes de lucro cuyo n es la denición de estándares abiertos e interoperables dentro
de los Sistemas de Información Geográca. Persigue acuerdos entre las diferentes empresas
del sector que posibiliten la interoperación de sus sistemas de geoprocesamiento y facilitar el
intercambio de la información geográca en benecio de los usuarios
3.2.2. Quantum GIS

Quantum GIS
13 es un sistema de información geográca gratuito de código
abierto. Corre en Linux, Windows, Mac, OSX y otros y soporta formatos de
vectores, de retículas y de bases de datos. QGIS permite navegar y crear mapas
en una computadora, soporta muchos formatos de datos espaciales comunes
(shapele, geoti, etc.) así como también la inserción de complementos para
realizar tareas como mostrar un camino a partir de datos obtenidos de un GPS.
Entre las tantas funcionalidades que ofrece, vale la pena mencionar:
Marcadores espaciales
Editar, ver, y buscar atributos de los datos espaciales
Etiquetado de elementos
Crear, editar, y exportar datos espaciales
Análisis espaciales
Publicar mapas en internet
Adaptar la herramienta a través de los plugins
3.2.3. El proyecto MBROLA

MBROLA
1415 es un proyecto iniciado por el laboratorio TCTS de la Fac-
ultad Politécnica de Mons (Bélgica) que apunta a tener un conjunto de sin-
tetizadores de voz para la mayor cantidad de lenguas posibles y proveerlos de
manera gratuita para aplicaciones no comerciales ni militares. El objetivo nal
de este proyecto es impulsar la investigación académica en la síntesis de voz, y
particularmente en la generación prosódica
16
El foco central de MBROLA es un sintetizador de voz homónimo basado
en la concatenación de difonos
17 . Este sintetizador toma una lista de fonemas
como entrada junto con información prosódica y produce muestras de habla.
(por lo tanto no es una sistema Text-to-Speech o Texto a Voz ya que sólo
un texto plano no es suciente para convertir el texto en sonido). En el CD que
acompaña a esta tesis pueden escucharse diversos ejemplos de voces sintetizadas
por este sintetizador.
13 http://www.qgis.org
14 http://tcts.fpms.ac.be/synthesis/mbrola.html
15 T. DUTOIT, V. PAGEL, N. PIERRET, F. BATAILLE, O. VAN DER VREKEN, "The
MBROLA Project: Towards a Set of High-Quality Speech Synthesizers Free of Use for Non-
Commercial Purposes"Proc. ICSLP'96, Philadelphia, vol. 3, pp. 1393-1396 .
16 Relativa a la rítmica, acentuación y entonación de las palabras
17 Un difono representa el sonido que abarca desde la mitad de la realización de un fonema
hasta la mitad de la realización del fonema siguiente. El propósito de esta unidad de sonido
es incorporar a la unidad de síntesis la transición de sonido entre fonemas, detalle que había
causado dicultad en los sistemas iniciales. La síntesis consiste, entonces, en la concatenación
de segmentos de señal en el tiempo, siendo los segmentos difonos
3.2.4. Navicore
Navicore
18 es un software de navegación por satélite para teléfonos móviles.
Entre sus características principales está la de encontrar la ruta más corta o
más rápida hasta un destino especicado, teniendo en cuenta detalles como:
congestiones en el tráco, información de cámaras de seguridad, si el recorrido
se realiza a pie, en bicicleta o en un automóvil. El programa utiliza instrucciones
precisas con voz para guiar al usuario a través del recorrido establecido y pre-
senta una pantalla con mapas en dos y tres dimensiones donde se marca la ruta
a realizar. Posee la posibilidad de recalcular rutas si el usuario determina que
hay un bloqueo en la ruta previamente calculada, así como de mencionar puntos
de interés cercanos (estaciones de servicios, farmacias, hoteles, etc.) y establecer
puntos favoritos. Es actualizable desde internet.
Es compatible con algunos modelos de celulares, no posee información car-
tográca de América Latina (sólo de Estados Unidos y algunos países de Europa
y de Asia). Su precio ronda los 150 euros y puede aumentar con las actualiza-
ciones y accesorios.
3.2.5. TomTom
El TomTom
19 es un navegador satelital para PDAs con similares característi-
cas que Navicore. Utiliza tecnología GPS como complemento a su funcionalidad,
crea rutas dinámicamente, genera un conjunto de instrucciones con voz que se
van transmitiendo al usuario a medida que recorre el camino, recalcula rutas
cuando hay bloqueos o tráco pesado, permite recibir llamadas, comprar ma-
pas de distintas regiones (Oeste de Europa, Estados Unidos, Sudáfrica, pero
carece de mapas de Sudamérica). Permite comprar voces en diferentes idiomas
a 6 libras esterlinas cada una (aproximadamente 12 dólares), establecer pun-
tos de interés, conocer el clima de los próximos 5 días en una ruta planeada,
personalizar la visualización de los mapas, etc. Su precio ronda los 150 dólares.
3.2.6. MapRed
MapRed
20 es un servicio web para conocer direcciones, establecer recorridos,
determinar rutas más cortas y puntos de interés. Su mayor ventaja es que se
focaliza en la zona de Latino América, brindando datos cartográcos de las
principales ciudades de dicha región.
3.2.7. Dragon NaturallySpeaking

Dragon NaturallySpeaking
21 es un software de reconocimiento de voz de-
sarrollado por la corporación Dragon Systems y comercializado por Nuance
Communications. Está especícamente diseñado para trabajar en computadoras
personales con sistemas operativos Windows
c . Basicamente posee tres áreas de
funcionalidad:
1. Dictado: en la que el programa transcribe en tiempo real la voz del usuario
18 http://www.navicoretech.com/Consumer/Product/Description/es ES/description/
19 www.tomtom.com
20 www.mapred.com
21 http://spain.scansoft.com/naturallyspeaking//
2. Reconocimiento de comandos: en la que el programa interpreta las pal-

abras del usuario como comandos que ejecutan determinadas acciones
3. Texto a sonido: en que se convierte texto escrito en voz hablada
En las versiones actuales de este software, no es preciso realizar entrenamiento

de voz (un proceso mediante el cual el programa incorpora datos acerca de la
voz de un usuario particular para aumentar la precisión del reconocimiento de
palabras). Esto signica una gran ventaja en comparación no sólo a versiones
anteriores sino a otros softwares similares, ya que permite que una multiplicidad
de usuarios utilice el sistema sin ningún requerimiento previo. El costo de este
producto ronda los 200 dólares.
3.2.8. Sphinx
Sphinx
22 es una aplicación, desarrollada por la Universidad Carnegie Mel-
lon, que permite crear software de reconocimiento de voz. El paquete estándar
provee un par de bases de datos con nalidad didáctica, para que el usuario
pueda entender el cómo se crean los datos necesarios y sucientes para poner
en funcionamiento un sistema completo de reconocimiento de voz. Crear un sis-
tema de este tipo necesita un conocimiento previo importante y es una tarea
complicada de llevar a cabo. Sphinx provee una serie de herramientas a los nes
de facilitar este proceso, que sin embargo, sigue siendo exclusivo para personas
con conocimientos avanzados en la materia. Entre los recursos necesarios para
contruir un sistema de reconocimiento de voz con Sphinx, encontramos:
Diccionario: es un archivo que contiene un mapeo entre palabras a ser

reconocidas y sus transcripción fonética.
Modelo de lenguaje: el lenguaje es comunmente modelado (SLM

23 ) a
través de modelos estadísticos de lenguaje o mediante el uso de gramáti-
cas de estado nitas (FSG
24 ). Sphinx provee herramientas para construir
modelos del primer tipo. Las gramáticas deben ser construidas a mano o
a través de aplicaciones externas.
Entrenador de modelo acústico: se trata básicamente de un seleccionador.

Su función principal consiste en elegir las palabras que mejor se ajusten
al sonido que fue analizado.
Decodicador: un decodicador está encargado de transformar la señal

analógica generada por el habla en una señal digital analizable por el
resto del sistema.
3.2.9. Conclusiones
Existe una amplia variedad de aplicaciones disponibles que trabajan con
datos geográcos. Muchas de estas aplicaciones son de código abierto o de libre
distribución, pero su funcionalidad principal (así como el método de interacción)
es demasiado visual y consiste fundamentalmente en la manipulación de los
22 http://cmusphinx.sourceforge.net/html/system.php#data
23 Del inglés: Statistical Language Models
24 Finite State Grammar
datos más que en la funcionalidad pretendida por este trabajo. En contrapartida,

las aplicaciones que brindan la funcionalidad buscada (tomtom, navicore), son
en general cerradas y comerciales, y tienen como desventaja esencial que carecen
de datos cartográcos de Argentina (y en general de Latino América).
Por otra parte, los softwares de conversión de texto a sonido no comerciales
carecen en general de datos del idioma español, aunque muchos ofrecen la posi-
bilidad de crear estos datos, esta tarea es no trivial y requiere una inversión de
tiempo importante así como conocimientos en el tema.
En lo que respecta al reconocimiento de voz, es evidente que el área se
encuentra en un momento de intensa actividad (desarrollo e investigación).
Esto tiene como consecuencia que las herramientas no comerciales que están
disponibles se encuentren en su gran mayoría en una etapa de evolución, lo
cual, conjuntamente con la complejidad intrínseca de la materia, diculta no-
tablemente su utilización.
Como conclusión nal de esta sección, es interesante mencionar que no resul-
ta de radical importancia incluir el reconocimiento de voz como característica de
la aplicación que se intenta desarrollar. Esto se deduce a partir de que la mayoría
de los programas de reconocimiento de voz poseen la capacidad de interpretar
comandos para manejar aplicaciones de escritorio, así como del hecho de que las
versiones comerciales de estos programas tienen (en general) precios accesibles
y toda la funcionalidad que se desea (en particular, manejo del Español).
3.3. Librerías
3.3.1. Mascopt
Mascopt
25 es una librería Java cuyo objetivo principal es proveer un con-
junto de herramientas para mitigar la problemática de optimización de redes.
Se propone lograr tal objetivo brindando modelos de datos de redes y grafos,
métodos para la manipulación de los mismos, e implementaciones de algoritmos
lineales comunes a la problemática. También facilita herramientas grácas para
visualización de grafos.
Es una librería creada en el INRIA, actualmente en desarrollo bajo una
licencia de código abierto (LGPL).
3.3.2. GeoTools
GeoTools
26 es una librería Java de código abierto y gratuita que provee
una serie de métodos estándar para la manipulación de datos geoespaciales.
Es un proyecto joven, activo y en continuo desarrollo, con un gran número de
contribuyentes. Provee una amplia gama de funcionalidades relacionadas con la
manipulación, visualización, transformación y análisis de datos geoespaciales lo
cual resulta idóneo para la creación de sistemas de información geográca, ya
sea como aplicaciones de escritorio o servicios web. Al ser un proyecto abierto
permite ampliar y adaptar sus funcionalidades según la necesidad particular del
proyecto en que desee utilizarse.
25 http://www-sop.inria.fr/mascotte/mascopt/
26 http://geotools.codehaus.org/
Soporta un gran número de formatos en los que pueden destacarse Shape-

File (SHP), Geographic Markup Language (GML), extensión Oracle para datos
espaciales, objetos geográcos para PostgreSQL (PostGIS), entre otros.
Entre sus funcionalidades más importantes pueden apreciarse herramien-
tas para manipulación topológica de datos geoespaciales, manipulación de ge-
ometrías, transformación de coordenadas, un módulo de manejo de grafos, mane-
jo de imágenes satelitales, módulos de representación gráca de datos, y muchos
más.
Originalmente fue desarrollado como parte de un proyecto Master en la Uni-
versidad de Leeds, Inglaterra. Actualmente está liderado por un grupo de con-
tribuyentes denominado el Project Management Committee (comité de ad-
ministración de proyecto) y abierto a la contribución del público en general.
3.3.3. FreeTTS
FreeTTS
27 es un sistema de síntesis de voz escrito por Speech Integration
Group de Sun Microsystems Laboratories, enteramente en el lenguaje de pro-
gramación Java. Está basado en Flite
28 , un pequeño motor de síntesis de voz
desarrollado en la Universidad de Carnegie Mellon. Flite está derivado del sis-
tema de síntesis de voz Festival
29 desarrollado por la Universidad de Edimburgo
y el proyecto FestVox
30 también de la Universidad de Carnegie Mellon.
Sus principales características incluyen:
Motor primario de síntesis de voz
Soporte de un número de voces en inglés
Soporte para importar voces tanto de FestVox como de MBROLA (sólo

en inglés)
Soporte parcial para JSAPI 1.0 (Java Speech API 1.0)
Extensa documentación API
Varias aplicaciones de demostración
3.3.4. GDAL
GDAL
31 es una librería que provee funcionalidades para la lectura y escritu-
ra de datos geoespaciales en un variado número de formatos de tipo RASTER .
32
Liberada bajo una licencia de código abierto estilo X/MIT (una licencia com-
patible con GPL) por la OSGEO. Provee un modelo abstracto de datos para
todos los formatos aceptados entre ellos:
27 http://freetts.sourceforge.net/docs/index.php
28 http://www.cmuite.org/
29 http://www.cstr.ed.ac.uk/projects/festival/
30 http://festvox.org/
31 http://www.gdal.org/
32 El modelo de SIG raster divide el espacio en celdas regulares donde cada una de ellas
representa un único valor
Nombre largo Código

Arc/Info ASCII Grid AAIGrid
ADRG/ARC Digitilized Raster Graphics (.gen/.thf ) ADRG
Arc/Info Binary Grid (.adf ) AIG
Microsoft Windows Device Independent Bitmap (.bmp) BMP
NASA ELAS ELAS
Graphics Interchange Format (.gif ) GIF
TIFF / GeoTIFF (.tif ) GTi
También ofrece una variedad de utilidades de línea de comandos para trans-

formación y procesamiento de datos. Se provee originalmente en C++ y además
existen adaptaciones para múltiples lenguajes (python, perl, java, ruby, C#),
aunque muchas de éstas no se mantienen al día.
3.3.5. FDO (Feature Data Object)

FDO
33 es una API desarrollada para C++ y .Net para manipular, denir,
y analizar datos geoespaciales, sin importar dónde están almacenados. Provee
modelos para soportar una amplia variedad de tipos de datos. Es libre, de código
abierto (con licencia GPL) y multiplataforma (Windows, Linux). Su modular-
ización y estructura permite extenderla tanto para aceptar nuevos formatos
como para agregar nuevas funcionalidades.
3.3.6. OpenLayers
OpenLayers
34 es una librería escrita en JavaScript de código abierto para
la visualización de mapas en navegadores web. Provee una API para construir
aplicaciones geográcas web similares a Google Maps y MSN Virtual Earth.
Entre las características principales encotramos:
Posibilidad de cargar datos desde diversas fuentes:
Web Map Service (WMS)
Google Maps
OpenStreetMap
Virtual Earth
Yahoo! Maps
MapServer
GeoServer
ka-Map
servidores World Wind
Soporte GeoRSS
Marcadores
Selección de capas
33 http://fdo.osgeo.org/
34 http://www.openlayers.org/
3.3.7. Conclusiones
Es notable la cantidad de material en desarrollo que existe en las áreas de
interés para este proyecto.
El reconocimiento de voz y la traducción de texto escrito a sonido dan cuenta
de una continua investigación y de un activo crecimiento. Sin embargo la natu-
raleza intrínsecamente humana de estos procesos conlleva un grado de compleji-
dad importante. Como consecuencia los proyectos que encaran esta problemática
se encuentran en un nivel medio a bajo de desarrollo (en el caso de las librerías
de distribución libre) y en general trabajan con un número reducido de idiomas.
En lo que respecta a la manipulación de información geográca, también
existe una variada oferta de librerías de libre distribución y en continuo de-
sarrollo. Aunque la tendencia general se inclina a herramientas que facilitan la
creación de aplicaciones web, existen algunas librerías interesantes de propósito
general (GeoTools, FDO) y de libre distribución que permiten crear sistemas de
información georeferenciada. En este sentido, la única desventaja es que si bien
la oferta es amplia, existe una profunda escasez en lo que respecta a la docu-
mentación de los proyectos y sus funcionalidades. Otro punto que vale la pena
mencionar es que, al tratarse de manipulación de información geoespacial, las
funcionalidades ofrecidas por las librerías en general apuntan a maximizar las
posilibilidades de visualización de los datos y a la modicación de sus valores,
más que a la representación abstracta de los mismos. Es claro que las funcional-
idades de índole visual tendrán un caracter secundario en el desarrollo de esta
tesis, sin embargo, una representación abstracta de los datos cartográcos que
se utilicen resultará fundamental para la programación de ciertos algoritmos
(como por ejemplo, aquéllos relacionados a la búsqueda de caminos).
Existe también una amplia variedad de librerías que trabajan con grafos que
podrían ser de utilidad para el desarrollo de este proyecto y que son de libre
disponibilidad.
3.4. Resultados
Debido a que el objetivo principal de este proyecto es generar un software (y
no un dispositivo), se ha tomado la primer parte de este relevamiento como un
ejemplo a seguir en lo que reere a la forma en que se interactúa con la persona
discapacitada visual así como a las funcionalidades de asistencia de orientación.
Un denominador común en los dispositivos relevados, es la comunicación a
través de sonidos. En el caso óptimo, el usuario puede dar instrucciones a través
de la voz o de un teclado braille, y recibir resultados a través de una voz elec-
trónica. En lo particular, todos los productos pretenden que esta comunicación
sea lo más uida posible, intentando que sea similar a la conversación humana.
En pro de la consecución de tal objetivo, se decidió incorporar como parte del
proyecto a la herramienta relevada MBROLA. Esta aplicación se presenta como
la mejor opción en lo referido a transformación de texto a sonido. No sólo proce-
sa texto en español sino también en inglés, francés, alemán y otros. Además es
de libre distribución para usos no comerciales ni militares y puede utilizarse
dentro de otros programas.
Como se mencionó anteriormente, será fundamental para el desarrollo de
este trabajo la manipulación de datos geoespaciales y la construcción de una
Fig. 3.7: Tabla de comparación: Software GIS. Parte 1

Fig. 3.8: Parte 2 (http://en.wikipedia.org/wiki/Comparison of GIS software)

representación abstracta de los mismos. En la subsección de conclusiones del

relevamiento de librerías se destacó la gran variedad de oferta existente en todo
lo referente a librerías SIG. En Wikipedia, se encuentra una tabla de compara-
ción entre gran parte de los productos pertenecientes a esta categoría. Esta tabla
puede verse en las guras 3.7 y 3.8 y brinda información acerca de la forma de
distribución (si son libres y si son de código abierto), los sistemas operativos en
los cuales funcionan, y accesibilidad via web. Atendiendo la necesidad primero
expresada, el relevamiento, y la información de la tabla de comparación, se con-
sideró la librería GeoTools como la más apta para conformar las bases del de-
sarrollo propuesto. GeoTools ofrece tipos de datos abstractos (TADs) para una
gran cantidad de fuentes de datos geográcos. Entre los TADs básicos que se
ofrecen, encontramos una variedad que permite trabajar tanto con datos raster
como con datos vectoriales
35 lo cual brinda la mayor amplitud a la espectativas
de encontrar datos cartográcos de la ciudad en un formato que sea manipu-
lable. Otro punto a favor reside en la existencia de una extensión de creación
y manipulación de grafos y redes. A pesar de que este paquete está en fase de
desarrollo, ya ofrece abstracciones para tales estructuras y una gran variedad de
funcionalidades y facilidades como una implementación del algoritmo de búsque-
da de caminos mínimos de Dijkstra[5]. Además, como la mayoria de la librerías
relevadas, contiene módulos que facilitan la tarea de realizar representaciones
grácas.
La decisión de trabajar sobre esta librería también se fundamentó en el hecho
de que la misma está programada en Java. Trabajar con Java supone una serie
de ventajas no menores:
Permite crear aplicaciones cuya funcionalidad no dependa de la plataforma

en la que se ejecute (Linux, Windows, etc.)
Existe una versión para dispositivos móviles (celulares, PDAs y otros),

denominada J2ME (Java 2 Micro Edition)
Es un lenguaje muy completo, robusto y en continua evolución
Permite crear aplicaciones tanto de escritorio como web
Extensa documentación.
3.5. Propuesta
Como se viene tratando a lo largo de este trabajo, se plantea la contrucción
de una herramienta que ponga a diponibilidad de las personas discapacitadas
visuales, la información cartográca de la ciudad de Córdoba. Así mismo, se
propone que este producto brinde asistencia en todo aquello que reera a la
orientación dentro de la ciudad.
Especícamente, se intenta crear una aplicación tal que:
Permita ingresar una dirección de la ciudad y recibir información al re-

specto,
35 En un SIG, las características geográcas pueden ser representadas por vectores, expresán-
dolas con diferentes tipos de geometrías (puntos, líneas y polígonos). Se utiliza además una
base de datos para describir sus atributos.
Fig. 3.9: Diagrama de la estructura de módulos de GeoTools. Descripción de

extensiones. (http://docs.codehaus.org/display/GEOTDOC/Home)
Permita ingresar dos direcciones diferentes y recibir información acerca

del camino más corto entre ambas,
Posea una interfaz desarrollada especícamente teniendo en cuenta la

problemática abarcada,
Los resultados de cualquier consulta sean expreasados en forma de:
• Sonido: Un archivo de sonido que se pueda reproducir, detener, retro-

ceder, y avanzar desde la interfaz. así como guardar para reproducir
en otros programas/dispositivos (por ejemplo, un reproductor de
MP3)
• Texto: Texto plano para facilitar la utilización de impresoras braille

(los archivos de texto con formato introducen codicaciones que pueden
causar incompatibilidades)
• Imagen: Un mapa con colores especiales y un tamaño adecuado para

que pueda ser intepretado por personas con baja visión.
Sea utilizable tanto en computadoras de escritorio como en dispositivos

moóviles (celulares, PDA's, y tantos como sea posible)
Sea sotware libre, fomentando así la participación de la comunidad en su

evolución y con espectativas de generar tanta retroalimentación como sea
posible para lograr el programa que mejor se adapte a las necesidades de
los usuarios.
Básicamente, la funcionalidad principal de la aplicación será la de dar in-

strucciones sobre cómo llegar de un punto a otro de la ciudad. Se espera que el
usuario ingrese una dirección de orígen y una de destino y reciba información
detallada sobre el cómo transitar el camino que las une. El programa presentará
resultados tales como:
1. Suba por la calle X1 unos 50 metros.
2. Cruce la calle X2 y continue por la calle X1 unos 75 metros.
3. Doble en diagonal a la derecha por la calle X3 unos 40 metros.
4. Ha llegado a destino.

4. Especicación y Diseño
En este capítulo se mostrará la especicación del grafo que representa la

ciudad, realizada en el lenguaje para especicaciones Z. También se expondrá
el diseño de las partes que se consideran importantes en la estructura de la
aplicación, a través del lenguaje TDN (Textual Desing Notation), desarrollado
por Carlo Ghezzi [7].
4.1. Especicación Z
Esta fue elaborada gradualmente; primero se realizó una especicación de
un grafo simple, que sólo contine vértices y aristas (los primeros representan
las esquinas y los últimos las cuadras en la ciudad), y se denió el concepto de
camino y operaciones para agregar y quitar componentes. En un paso posterior
se agregó costo en la aristas; luego se añadió nombres a las calles y numeraciones.
Por último, se tuvo en cuenta la georeferencia de las partes del grafo.
En cada etapa se extendieron las operaciones denidas en pasos anteriores,
para que contemplaran los cambios agregados; además se introdujeron algunos
invariantes y operaciones que surgieron por la ampliación del estado.
4.1.1. Grafo simple de la ciudad

Se denen los tipos básicos ARISTA y VERTICE
[ARISTA, VERTICE ]
Como toda arista está intrínsecamente relacionada a dos vértices, creamos

una abreviación de tipos genérica que dado un tipo representa al conjunto que
contiene todos los conjuntos de dos elementos de ese tipo.
D X == {s ∈ P X | #s = 2}
El siguiente esquema representará nuestro estado básico. La ciudad es un

grafo formado por cuadras (aristas que representan calles), esquinas (los ex-
tremos de las cuadras) y una función que relaciona esas cuadras con sus es-
quinas.
CIUDAD
cuadras : F ARISTA
esquinas : F VERTICE
vs : cuadras → D VERTICE
S
esquinas = ran vs
4. Especicación y Diseño 36
Será importante determinar cuándo una secuencia de cuadras de la ciudad

se considera un camino. Para eso se realiza el siguiente esquema que representa
todos los posibles caminos de la ciudad desde v a w .
Camino Esquinas
CIUDAD
c : seq cuadras
e : seq esquinas
v , w : esquinas
e 6= hi
v = head (e ); w = last (e )
∀ i : 1 . . #c • vs (c (i )) = {e (i ), e (i + 1)}
A continuación se dene un esquema que dice que c es un camino que une

v con w , luego el conjunto de tales caminos, y nalmente el conjunto de todos
los caminos (entre todo par de esquinas):
Camino b Camino Esquinas \ e

=
camino == {SCamino • c }
caminos == {Camino • camino }
La propiedad fundamental que debe conservarse en el grafo que representa

nuestra ciudad, es que sea conexo. El predicado del siguiente esquema, expresa
que dado dos nodos cualesquiera de la ciudad, se puede establecer un camino
que los una.
CONEXO
CIUDAD
∀ v , w : esquinas • camino 6= ∅
La forma básica de modicar el grafo será agregando y quitando vértices del

mismo. Para agregar un vértice, tomamos una cuadra y la dividimos en dos.
Esto se representa en nuestra estructura quitando una cuadra y reemplazandola
por dos cuadras nuevas (en realidad, sólo una necesita ser nueva, la otra podría
ser la propia cuadra que se quita) que tienen un vértice en común (una nueva
esquina) y cuyos vértices no comunes sean los vértices de la arista original.
AgregarVerticeOk
∆CIUDAD
v : VERTICE
a , b : ARISTA
c ? : cuadras
(a 6∈ cuadras ∨ b 6∈ cuadras ) ∧ v 6∈ esquinas

0
cuadras = (cuadras \ {c ?}) ∪ {a , b }
0
esquinas = esquinas ∪ {v }
0 0
vs a ∩ vs b = {v }
(vs 0 a ∪ vs 0 b ) \ {v } = vs c ?
∀ d : cuadras | d 6= c ? • vs 0 d = vs d
AgregarVerticeError
ΞCIUDAD
c ? : ARISTA
c? 6∈ cuadras ;
Para agregar un vértice no importa cuáles sean los vertices y aristas nuevos
AgregarVertice b AgregarVerticeOk \ (a , b , v ) ∨ AgregarVerticeError

=
La operación análoga sería la de quitar un vértice. Esto se representará a
través de la unión de aristas adyacentes. Para unir dos aristas del grafo necesi-
tamos que sean aristas diferentes, que tengan un único vértice en común y que
no haya otras aristas que contengan a ese vértice como una de sus esquinas. La
unión de estas aristas resulta en una nueva arista cuyos vértices son los vértices
no comunes de las aristas originales.
QuitarVerticeOk
∆CIUDAD
v ? : esquinas
c , d : cuadras
a : ARISTA
#{b : cuadras | v ? ∈ vs b } = 2
vs c ∩ vs d = {v ?}
0
cuadras = (cuadras \ {c , d }) ∪ {a }
0
esquinas = esquinas \ {v ?}
0
vs = ({c , d } −
C vs ) ∪ {a 7→ (vs c ∪ vs d) \ {v ?}}
QuitarVerticeError
ΞCIUDAD
v ? : VERTICE
v? 6∈ esquinas ∨ #{b : cuadras | v ? ∈ vs b } =

6 2
QuitarVertice b QuitarVerticeOk \ (c , d , a ) ∨ QuitarVerticeError

=
4.1.2. Con Costo para las aristas

Ahora queremos que nuestras cuadras tengan asociadas un costo. Este costo
representará la longitud de las mismas, permitiéndonos encontrar los caminos
óptimos dentro de la ciudad.
COSTO == N
Nuestro esquema básico de ciudad cambia entonces ligeramente, agregándose

al mismo la función que relaciona cuadras con costos.
CIUDAD C
CIUDAD
costo : cuadras → COSTO
Para determinar el costo de un camino se dene el siguiente esquema que

relaciona cada camino con su costo correspondiente. A posteriori se dene el
conjunto de todos los pares (camino, costo del camino).
CostoCamino
CIUDAD C
c : caminos
valor : COSTO
P#c −1
valor = i =0 costo (c (i ))
costo camino == {CostoCamino • c 7→ valor }
A partir de estas deniciones podemos entonces denir el conjunto de caminos

óptimos de un nodo a otro de la ciudad.
CaminoMin
CIUDAD C
v, w : esquinas
c : camino
∀ d : camino • costo camino c ≤ costo camino d
caminoMin == {CaminoMin • c }
EncontrarCaminoMinimo
CIUDAD C
v1 ?, v2 ? : esquinas
c ! : caminoMin
v1 ? = v ∧ v2 ? = w
Ahora necesitamos expandir la función AgregarVertice denida en la sección

anterior. Para ello debemos tener en cuenta los costos de las aristas que vamos
a agregar.
AgregarVerticeOk C
∆CIUDAD C
AgregarVerticeOk
j,k :N
costo c ? =j +k
0
costo = ({c ?} −
C costo ) ∪ {(a , j ), (b , k )}
AgregarVerticeError C =
b [ΞCIUDAD C ; AgregarVerticeError ]
AgregarVertice C =
b AgregarVerticeOk C \ (a , b , v , j , k )
∨ AgregarVerticeError C
Análogamente, expandimos la función QuitarVertice de manera que la arista

resultante de la unión tenga un costo igual a la suma de los costos de las aristas
originales.
QuitarVerticeOk C
∆CIUDAD C
QuitarVerticeOk
0
costo = ({c , d } −
C costo ) ∪ {(a , costo c + costo d )}
QuitarVerticeError C =
b [ΞCIUDAD C ; QuitarVerticeError ]
QuitarVertice C =
b QuitarVerticeOk C \ (a , c , d )
∨ QuitarVerticeError C
4.1.3. Con nombre para las calles

Agregaremos ahora al proyecto el tipo CALLE, que representará los nombres
de las calles de la ciudad.
[CALLE ]
Por lo tanto se agregará al esquema básico una función que relacione las
cuadras de nuestra ciudad con su nombre de calle correspondiente.
CIUDAD N
CIUDAD C
calle : cuadras → CALLE
Para expandir la función AgregarVertice C sólo bastará decir que las dos
nuevas aristas deberán tener el nombre de calle de la arista original.
AgregarVerticeOk N
∆CIUDAD N
AgregarVerticeOk C
0
calle = ({c ?} −
C calle ) ∪ {(a , calle c ?), (b , calle c ?)}
AgregarVerticeError N =
b [ΞCIUDAD N ; AgregarVerticeError C ]
AgregarVertice N =
b AgregarVerticeOk N \ (a , b , v , j , k )
∨ AgregarVerticeError N
También expandimos la operación QuitarVertice C de manera trivial.
QuitarVerticeOk N
∆CIUDAD N
QuitarVertceOk C
calle c = calle d
0
calle = ({c , d } −
C calle ) ∪ {(a , calle c )}
QuitarVerticeCalleError
ΞCIUDAD N
v ? : VERTICE
c , d : cuadras
vs c ∩ vs d = {v ?}
calle c 6= calle d
QuitarVerticeError N =
b [ΞCIUDAD N ; QuitarVerticeError C]
∨ QuitarVerticeCalleError \ (c , d )
QuitarVertice N =
b QuitarVerticeOk N \ (a , c , d )
∨ QuitarVerticeError N
4.1.4. Con numeración para las calles

Para tener en cuenta la numeración de las calles agregaremos a nuestro
esquema básico una función que tome un par (nombre calle,numeración), y nos
devuelva la cuadra correspondiente a tal dirección si es que existe tal cuadra.
CIUDAD A
CIUDAD N
dirs : CALLE × N →
7 cuadras
Ahora que nuestro esquema considera nombres de calles y numeración de

las mismas, se modica ligeramente la operación AgregarVertice que pasará a
tomar un nombre de calle y una dirección como parámetros para colocar el
nuevo vértice justamente en ese lugar. También por el hecho de conocer las
numeraciones de una calle, podemos hacernos una idea más especíca de cuál
será el costo que deberán tener las cuadras nuevas. El costo de la arista a dividir
se repartirá de manera proporcional según la cantidad de direcciones que tenga
cada cuadra nueva.
AgregarVerticeOk A
∆CIUDAD A
AgregarVerticeOk N [c /c ?]
calle ?: CALLE
d? :N
A, B : P(CALLE × N × ARISTA)
(calle ?, d ?) ∈ dom dirs

c = dirs (calle ?, d ?)
A = {(l , n ) ∈ dom dirs | dirs (l , n ) = c ∧ n ≤ d ? • (l , n ) 7→ a }
B = {(l , n ) ∈ dom dirs | dirs (l , n ) = c ∧ n > d ? • (l , n ) 7→ b }
0
dirs = (dirs −
B {c }) ∪ A ∪ B
j = (costo c ∗ #A) div (#A + #B )
k = costo (c ) − j
El error de la operación pasará a denirse de una manera sutilmente distinta,

pero seguirá siendo esencialmente el mismo. Si la calle y numeración que bus-
camos no representa ninguna cuadra, entonces no podemos agregar un vértice
nuevo.
AgregarVerticeError A
ΞCIUDAD A
calle ? : CALLE
d? : N
(calle ?, d ?) ∈
/ dom dirs
AgregarVertice A =
b AgregarVerticeOk A \ (a , b , j , k , A, B )
∨ AgregarVerticeError A
La operación de quitar vértice simplemente restituirá la función dirs , aso-

ciando a la arista de resultado las direcciones de las aristas a unir.
QuitarVerticeOk A
∆CIUDAD A
QuitarVerticeOk N
0
dirs = (dirs −
B {c , d }) ∪ {(l , n ) ∈ dom dirs | dirs (l , n ) = c
∨ dirs (l , n ) = d • (l , n ) 7→ a }
QuitarVerticeError A =
b [ΞCIUDAD A; QuitarVerticeError N ]
QuitarVertice A =
b QuitarVerticeOk A \ (c , d , a )
∨ QuitarVerticeError A
La operación que encuentra el camino mínimo entre dos esquinas se expande

de manera trivial, ya que no modica el estado.
EncontrarCaminoMinimo A =
b
[ΞCIUDAD A; EncontrarCaminoMinimo ]
La siguiente operación es la encargada de realizar todo el proceso que implica

una petición de encontrar el camino óptimo entre dos direcciones. Este proceso
radica esencialmente en:
Pedir dos direcciones (calles y alturas)
Agregar dos vértices en los lugares correspondientes
Buscar un camino mínimo entre los dos nuevos vértices
Devolver el camino
Restituir las aristas que fueron divididas cuando se agregaron los vértices
nuevos a nes de dejar el grafo de la ciudad en su estado original
Utilizamos las herramientas de Z de composición, pipe y renombre para re-

utilizar las operaciones hasta aquí desarrolladas y simplicar la lectura de la
especicación.
CaminoOptimo =
b
( AgregarVertice A [calle1 ?/calle ?; d1 ?/d ?; v1 !/v ]
9 AgregarVertice A [calle2 ?/calle ?; d2 ?/d ?; v2 !/v ]
)
o
>> ([EncontrarCaminoMinimo A; v1 !, v2 ! : VERTICE

| v1 ? = v1 ! ∧ v2 ? = v2 !])
>> ( QuitarVertice A[v1 ?/v ?] o9 QuitarVertice A[v2 ?/v ?] )
4.1.5. Con georeferencias

Para poder hablar de coordenadas vamos a suponer que Z puede traba-
jar con números racionales (Q) y que las operaciones matemáticas que incluye
pueden trabajar con este conjunto de datos. Dado que la inclusión de la car-
acterística de la georeferencia no implica grandes cambios en la especicación
ni una complejidad muy elevada en su desarrollo, consideramos fútil el realizar
una especicación de los números racionales y sus operaciones (una extensión
innecesaria que no agrega ningún valor al entendimiento de la funcionalidad).
Denimos entonces el tipo COORD que representará a una coordenada carte-
siana, como un par de números racionales.
COORD == Q × Q
Al esquema básico de la ciudad agregamos dos funciones: una que relaciona

esquinas con coordenadas, y otra que relaciona direcciones (calle, número) con
coordenadas.
CIUDAD G
CIUDAD A
posesq : esquinas COORD
posdir : calles × N → COORD
El invariante que surge a través de la consideración de las georeferencias,

tiene básicamente dos aspectos:
1. Que el dominio de la función dirs sea el mismo que el de posdir (existe

una coordenada para cada dirección)
2. Que si una coordenada (x,y) está asociada a una dirección de una de-
terminada cuadra, entonces ésta se encuentra situada sobre el segmento
determinado por las esquinas de la cuadra recién referenciada
Queda parte del invariante implícita en el hecho de que la función posesq sea una
función total e inyectiva. Esto nos dice que no puede suceder que dos esquinas
tengan la misma coordenada asociada.
EnMedio
(x , y ), (x1 , y1 ), (x2 , y2 ) : COORD
((x1 ≤ x ≤ x2 ) ∨ (x2 ≤ x ≤ x1 ))
((y1 ≤ y ≤ y2 ) ∨ (y2 ≤ y ≤ y1 ))
y −y1 y1 −y2
x −x1 = x1 −x2
enMedio == {EnMedio • ((x , y ), (x1 , y1 ), (x2 , y2 ))}
Posiciones Correctas
CIUDAD G
dom posdir = dom dirs

∀(l , n ) ∈ dom dirs •
let {e1 , e2 } = vs (dirs (l , n )) •
enMedio (posdir (l , n ), posesq e1 , posesq e2 )
Las expansiones de las operaciones de agregar vértice y quitar vértice son

simples: la función posdir nunca se modica, ya que en ningún momento se
agregan o quitan direcciones. Por lo tanto sólo nos queda modicar posesq ya
que varía su dominio a medida que se agregan o quitan esquinas.
AgregarVerticeOk G
∆CIUDAD G
AgregarVerticeOk A
0
posesq = posesq ∪ {v 7→ posdir (calle ?, d ?)}
0
posdir = posdir
AgregarVerticeError G =
b [ΞCIUDAD G ; AgregarVerticeError A]
AgregarVertice G =
b AgregarVerticeOk G \ (a , b , j , k , A, B )
∨ AgregarVerticeError G
QuitarVerticeOk G
∆CIUDAD G
QuitarVerticeOk A
let {v1 , v2 } = (vs c ∪ vs d) \ {v ?} •

enMedio (posesq v ?, posesq v1 , posesq v2 )
0
posesq = {v ?} −
C posesq
0
posdir = posdir
QuitarVerticeErrorSegmento G
∆CIUDAD G
v ? : esquinas
let {v1 , v2 } = (vs c ∪ vs d ) \ {v ?} •

¬ enMedio (posesq v ?, posesq v1 , posesq v2 )
QuitarVerticeError G =
b [ΞCIUDAD G ; QuitarVerticeError A]
QuitarVertice G =
b QuitarVerticeOk G \ (c , d , a )
∨ QuitarVerticeError G
∨ QuitarVerticeErrorSegmento G
4.2. Diseño de la aplicación

Para el desarrollo del diseño se tuvieron en cuenta propiedades fundamen-
tales que la implementación debería mantener. Entre estas se destacaban la
preservación de la integridad y protección de los datos y la aspiración de ejecu-
tar la herramienta en dispositivos móviles.
Teniendo en cuenta estas características, se consideró que la arquitectura
cliente-servidor era una buena opción para el desarrollo del proyecto. Esta ofrecía
la posibilidad de mantener los datos en el servidor, resguardándolos del acce-
so directo por parte de los clientes, logrando así su protección y preservación.
Por otro lado, como los dispositivos móviles cuentan con poca capacidad, con
cliente-servidor, el mayor costo de procesamiento y memoria se podría colocar
en el servidor, con lo cual, el cliente (interfaz) sería sucientemente liviano para
ejecutarse en este tipo de dispositivos.
4.2.1. Descripción del diseño

El servidor es el encargado de mantener el grafo que representa a la ciudad,
proveer las operaciones de búsqueda de caminos y consulta de direcciones, man-
tener los clientes conectados, administrar sus consultas y generar los resultados
Fig. 4.1: Diagrama de módulos del Servidor
deseados. El cliente por otra parte, es el encargado de interactuar con los usuar-
ios, es la interfaz que permite a los mismos realizar las consultas y conocer los
resultados.
El servidor está constituido básicamente de tres partes; La encargada de
matener el grafo de la ciudad y proveer las operaciones de consulta (Nomen-
clador), la que manteniene las conexiones, interactua con los clientes y admin-
istra la cola de sus peticiones (Conexiones)y por último la que genera los resul-
tados en los formatos deseados (Resultados).
El cliente está formado por dos partes, la que intractua con el servidor,
realizando peticiones y recibiendo los resultados correspondientes; y la interfaz
que interactua con el usuario, que se encarga de permitir al mismo ingresar sus
consultas y conocer las respuestas.
4.2.2. Descripción del diseño en TDN

Nomenclador
Nomenclador es el encargado de mantener el grafo de la ciudad, el módulo
Ciudad provee los métodos para realizar las consultas disponibles; e interna-
mente tiene las operaciones de agregar y quitar vértices. El módulo ArmaGrafo
es el encargado de armar el grafo a partir del archivo que contiene los datos de
la ciudad.
module Ciudad
uses ArmaGrafo
exports method Ciudad(dirArchivo: in String)
raises ArmaGrafoFalloException;
Arma el grafo que representa a la ciudad a partir del
archivo apuntado por dirArchivo.
method existeDiereccion(nom calle: in String,
num: in int): LinkedList;
Consulta en el grafo por la existencia de una
dirección.
method CaminoMinimo(IDArista1: in int,
num1: in int,
IDArista2: in int,
num2: in int): Path
raise Exception;
Consulta en el grafo el camino mínimo entre
las direcciones dadas por IDArista1,num1 y
IDArista2,num2 y devuelve el camino.
implementation ArmaGrafoFalloException es lanzada ante
cualquier inconveniente al tratar de armar
el grafo.
end Ciudad
module ArmaGrafo
exports method ArmaGrafo(dirArchivo: in String): Graph
raises Exception;
Arma un grafo a partir del archivo apuntado por
dirArchivo, este debe ser un tipo de archivo aceptado.
end ArmaGrafo
Resultados
Este paquete tiene los módulos que son utilizados para generar los resultados
que se envían a los clientes. Estos son texto, archivo de sonido e imagen.
module PathATexto
exports method PathATexto (camino: in Path);
method ultimasInstrucciones(): String;
Devuelve las últimas instrucciones generadas.
method setPath(p : in Path);
method getPath():Path;
method darInstrucciones(): String;
Crea y devuelve instrucciones asociadas al camino.
end PathATexto
module ShapeAPng
exports method ShapeAPng (s : in ShapeleDataStore)
raise IOException;
Crea a partir de un ShapeFileDataStore un Png.
end ShapeAPng
module TextoASonido
exports method TextoASonido();
method asignarTexto(texto: in String);
method ASonido(): File raise IOException;
Devuelve un archivo de sonido creado a partir del texto
ingresado en el método asignarTexto.
method borrarArchivos();
Borra los archivos temporales creados durante la
traducción a sonido.
end TextoASonido
module PathAShape
exports method PathAShape(p: in Path);
method PathAShape();
Constructores de la clase.
method setPath(p: in Path);
method getPath(): Path;
method getShape(): ShapeFileDataStore;
Devuelve el ShapeFileDataStore que contiene el path
ingresado en el método setPath o seteado en el
constructor.
end PathAShape
Conexiones
Los siguientes modulos administran las conexiones de los clientes y maneja
los pedidos de los mismos.
module ConexionClientePc
extends Java.Thread
exports method ConexionClientePc(conexion: in Socket,
colap: in ColaPeticiones)
raise IOException;
Constructor de la clase.
method run();
Método para poner a correr el hilo.
end ConexionClientePc
El modulo ConexionClienteMovil, tiene los mismos dos métodos que el ante-
rior, es el encargado de mantener la conexión de clientes de dispositivos moviles.
Estos se diferencian internamente en los servicios prestados y en la forma de
mantener la comunicación. Los dispositivos moviles, por ejemplo, no reciben la
imagen de los resultados, además la forma de intercambio de datos varia míni-
mamente, por lo que en algunos casos la comuniocación es ligeramente distinta
a la de clientes Pc.
module ColaPeticiones
uses Peticion
exports method ColaPeticiones();
method encolarPeticion(p: in Peticion);
Este método se encarga de encolar la petición p.
method obtenerPrimera(): Peticion;
Devuelve la primer petición de la cola.
method peticionesEncoladas(): Boolean;
Devuelve verdadero si hay peticiones encoladas.
end ColaPeticiones
module AdministradorPeticiones
uses ColaPeticiones, Ciudad
extends Java.Thread
exports method AdministradorPeticiones(c: in Ciudad,
cp: in ColaPeticiones);
method run();
Método que pone a corre el hilo.
implementation Mientras haya peticiones encoladas, se toma
la primera y se la atiende en la ciudad, luego
se informa que la petición fue atendida.
end AdministradorPeticiones
5. Implementación
A la hora de determinar el lenguaje de programación en el cual se iba a de-

sarrollar la aplicación, se tuvieron en cuenta algunas cualidades deseadas de la
misma. Entre éstas se destacan la necesidad de que la aplicación esté bajo una
arquitectura cliente servidor (como se vió en el capítulo anterior), la posibilidad
de realizar clientes para diversas plataformas (como es el caso de dispositivos
móviles) y la facultad de trabajar con sonido. En el caso del servidor, que uti-
lizaría la librería GeoTools, elegida para el manejo de los datos geográcos y
búsqueda de caminos, se consideró que Java además de cubrir apropiadamente
las características deseadas, facilitaría la interacción con dicha librería. Por el
lado de los clientes, se tuvo en cuenta el hecho de que se quería realizar una in-
terfaz para dispositivos móviles, lo cual también ofrecía a Java como una buena
opción, además su uso podría evitar posibles problemas de comunicación. Por
ello, tanto el Servidor como los clientes se desarrollaron en Java. En el presente
capítulo, se comentarán las opciones disponibles para la comunicación cliente-
servidor que se analizaron con el lenguaje Java, la justicación de la opción
elegida, una breve descripción de la misma y por último se mencionarán las
implementaciones de los clientes y del servidor.
5.1. Comunicación Cliente-Servidor

Se analizarán las siguientes alternativas que se tienen en el lenguaje Java
para realizar la comunicación:
Comunicación a través de Sockets
Servidor web
Computación Distribuida
• Remote Method Invocation (RMI)
• Common Object Request Broker Architecture (CORBA)
5.1.1. Sockets
Un socket es un punto de comunicación entre procesos (posiblemente cor-
riendo en diferentes máquinas), compuesto de un protocolo, una dirección IP y
un número de puerto. Los protocolos más usados en la comunicación de socket
son TCP y UDP. La diferencia entre ambos, es que los que usan TCP (también
conocidos como sockets de ujo), mantienen una conexión, garantizan que el
envío de datos sea libre de pérdida de información y errores de transmisión y
que se respete el orden en el cual fueron mandados los mismos; mientras que los
que usan UDP (conocidos como sockets de datagrama), no mantienen conexión
5. Implementación 50
y no aseguran la llegada de los datos, ni el orden en el cual llegan. Éstos últi-

mos tienen un mejor rendimiento de velocidad, debido a la falta de controles de
secuencia y de errores.
Java provee por medio de la clase java.net los dos tipos de sockets:
Socket: Socket de ujo, orientado a conexión, la cual permanece activa

incluso aunque no haya transferencia de datos, hasta que se realice ex-
plícitamente una desconexión. La comunicación se realiza a través de los
ujos de entrada y salida asociados al socket.[11]
DatagramSocket: Trabaja con un protocolo sin conexión, mediante la

transferencia de datagramas, y no se asegura la llegada y el orden de
los datos.[11]
5.1.2. Servidor web

Un servidor web está a la espera de peticiones HTTP
1 llevadas a cabo por
un cliente HTTP, conocido como navegador web. El cliente HTTP, efectúa una
petición al servidor, éste la procesa y devuelve los resultados correspondientes;
éstos son generalmente documentos HTML (HyperText Markup Language),
pero también pueden ser archivos de sonidos, imágenes o algún otro tipo de
documento.[12]
El navegador web es el encargado de interpretar lo recibido desde el servidor
y mostrarlo en la máquina del cliente. En el caso de HTML, es el que se encarga
de mostrar los distintos tipos de letras, colores y disposiciones del texto en la
página.
Existen dos posibilidades a la hora de ejecutar un pedido. Una es que el
servidor realice el trabajo, generando código HTML con el resultado y envián-
dolo al cliente. La otra opción es la ejecución de aplicaciones en la máquina
del cliente (aplicaciones Java, javascript, etc.), es decir que el servidor genere el
código de la aplicación, lo envíe y el navegador se encargue de la ejecución. Las
desventajas de la segunda son que se sobrecarga al cliente, y que este debe estar
preparado para poder ejecutar este tipo de aplicaciones.
5.1.3. Computación Distribuida

La computación distribuida es una forma de procesamiento en la cual las
diferentes partes de un programa corren simultáneamente en dos o más com-
putadoras conectadas entre sí. El objetivo principal de la misma es lograr pro-
gramas abiertos, escalables y transparentes. [13]
Una de sus ventajas es que pueden realizarse tareas que serían muy costosas,
o imposibles de realizar por un solo ordenador, fragmentando el trabajo en
muchas partes. Entre las desventajas encontramos la dicultad en el diagnóstico
y seguimiento de fallas y en realizar un buen diseño para lograr una división de
tareas eciente y efectiva.
Una manera de implementar en java computación distribuida es mediante
Java RMI. Éste nos ofrece la posibilidad de ejecutar métodos de objetos alma-
cenados en computadoras remotas de manera similar a como se ejecutarían si
1 HTTP (hypertext transfer protocol): protocolo que sigue un esquema de petición-

respuesta, entre un cliente y un servidor, y no guarda estado de conexión.
fueran locales, manteniendo así la naturaleza de la programación orientada a

objetos. Una ventaja de este modelo es que la sintaxis para hacer este tipo de
llamadas es similar a la sintaxis para realizar llamadas locales, lo cual hace que
sea sencillo de aprender para los programadores. Una alternativa para RMI es
Common Object Request Broker Architecture (CORBA), que al ser independi-
ente del lenguaje, brinda la posibilidad de comunicación entre un cliente y un
servidor programados en diferentes lenguajes. Sin embargo, también introduce
dicultades a la hora de la programación. [11] En un sentido general CORBA
envuelve un objeto en un paquete que contiene información sobre las capaci-
dades del mismo y sobre cómo llamar a sus métodos. Los objetos que resultan
pueden entonces ser invocados desde otro programa (u objeto CORBA) desde
la red. [14]
5.1.4. Comunicación Cliente-Servidor del proyecto

Considerando las características del desarrollo a realizar observamos que
valerse del enfoque de la programación distribuida para implementar una arqui-
tectura cliente-servidos obligaría a abordar problemas de difícil solución. Uno
de ellos es la protección de los datos. En efecto, al accederse en forma remota
a los propios objetos que contiene los datos, su obtención sería simple (de he-
cho la misma librería GeoTools proporciona los métodos necesarios para ello).
Otro problema que surge es que se introducen dicultades a la hora de la cod-
icación de la aplicación. También existen algunas restricciones, en el caso que
se utilizara la API RMI, provista en Java, se obligaría a programar los clientes
en dicho lenguaje, mientras que si se utilizara CORBA, se tendía una mayor
libertad, pero seguirían existiendo limitaciones en los lenguajes disponibles.
Por otro lado, la implementación usando servidor web, tiene restricciones a
la hora de proporcionar facilidades para el usuario. Es importante mencionar
que en la actualidad hay disponibles herramientas para generar interfaces web
potentes, como son el uso de JavaScript, ash, ajax, etc.; pero la codicación se
torna más compleja, por diversos factores, como por ejemplo, la incompatibilidad
existente entre los distintos browsers; Además las velocidades dismunuyen, ya
que, no sólo se utiliza la conexión para obtener resultados, sino que también
para obtener cambios en la interfaz, es decir, el intercambio de información
entre cliente y servidor es mayor.
Por ello, se prerió implementar la arquitectura cleinte-servidor utilizando
el enfoque de comunicación a través de sockets TCP. Se optó por TCP y no
UDP, ya que estos últimos se preeren cuando la perdida de información no
es relevante y lo que se busca es una mejor performance. En nuestro caso, es
necesario que se asegure la llegada total de la información. El hecho de codicar
con sockets UDP introduciría complejidad a la codicación del protocolo de
comunicación, se debería realizar un control de envío de datos, el cual haría
incrementar la comunicación entre las partes y bajaría el rendimiento. De este
modo no se estaría obteniendo ventaja alguna, es decir, se estaría construyendo
sockets TCP mediante el uso de sockets UDP.
Los sockets TCP proporcionan la seguridad necesaria para la protección de
los datos, ya que la información no es manipulada por los clientes, sino que estos
emiten un pedido y luego reciben los resultados. Además ofrecen la posibilidad
de codicar clientes y servidores con lenguajes distintos. Por último, permiten
tener interfaces de escritorio potentes y no se descarta la posibilidad de con-
Fig. 5.1: Diagrama de la comunicación Cliente-Servidor
struir interfaces web, ya sea, ampliando el servidor, para que interprete HTTP
o construyendo una aplicación que conecte un servidor web con el servidor de
datos geográcos.
Descripción del protocolo de comunicación

El protocolo desarrollado es orientado a conexión, es decir, una vez que el
cliente se conecta al servidor, puede realizar consultas sobre caminos mínimos o
pedir informacón sobre direcciones, hasta que se efectúe una desconexión. A par-
tir de ese momento las partes están incomunicadas. Para lograr la desconexión,
el cliente emite un mensaje especial para tal n.
Durante la conexión el servidor está a la espera de una petición de búsqueda
de camino o información de dirección, el cliente le informa qué tipo de consulta
desea realizar, y el servidor se encarga de pedir los datos necesarios para tal
consulta. El intercambio de información se realiza de manera intercalada, es
decir, el servidor solicita un dato, el cliente lo envía, y luego, de ser necesario,
pide datos adicionales. Por ejemplo, como se ve en la gura 5.1.4, en el caso
de consulta de dirección, el cliente emite consultaDir (para avisar que desea
información sobre una dirección) y queda a la espera de la solicitud de los datos;
el servidor, una vez procesada la petición, transmite el mensaje direccion y
aguarda a que se emita la direccion. El cliente, luego de contestar, queda a la
espera del resultado, mientras que el servidor, realiza la consulta en el grafo de
la ciudad, para una vez obtenida la respuesta, transmitirla. Una vez nalizada
esta conversación, el servidor vuelve a la espera de una consulta o solicitud de
desconexión.
Para la consulta de camino mínimo, el servidor pide dos direcciones, el pro-
cedimiento es similar, salvo que luego de pedir cada dirección, se corrobora si
existe y es única. Por ejemplo, si el cliente transmite como dirección Juan 200,
existen varias calles en la ciudad de Córdoba que contienen ese nombre y altura;
En tal caso el servidor manda una lista con opciones, para que desde el cliente
se seleccione alguna. Por otro lado, si no existen coincidencias con los datos
recibidos, se informa al cliente, para que éste envíe nueva información. Cuando
ambas direcciones son aceptadas, es decir, existen únicas direcciones que corre-
spondan a los datos enviados, el servidor realiza la búsqueda de camino mínimo,
para posteriormente transmitir los resultados.
5.2. Servidor
El servidor fue programado en el lenguaje Java, se utilizarón las librerías
estandar del lenguaje y la librería GeoTools, para el manejo de la información
geográca. Además se utilizó un scrip en Perl y el sintetizador de voz MBROLA.
La funcionalidad principal del Servidor, es la de recibir conexiones de clientes
remotos y contestar sus consultas de camino mínimo e información de dirección.
En la inicialización, el servidor genera, utilizando la librería GeoTools, una
estructura con los datos de la ciudad de Córdoba, más precisamente un grafo.
Éste se encuentra ubicado en un módulo que posee métodos para trabajar con
el, como son agregar y quitar vértices, buscar aristas que satisfagan ciertas car-
acterísticas y las que realizan las consultas de búsqueda de camino y existencia
de dirección. También es inicializada una cola donde se irán almacenando las
peticiones de los clientes, junto a ésta, se crea un hilo (Thread), que a lo largo
de la ejecución, se encarga de controlar la cola. Al momento que es encolada
una solicitud, este hilo es el encargado de atenderla, para ello realiza la consulta
correspondiente al grafo y luego devuelve el resultado. Como se puede apreciar,
la política aplicada a la hora de atender las peticiones es FIFO, esto se pen-
só así, por el hecho de que la consulta de camino mínimo modica el grafo, y
tal modicación debe existir sólo para esa consulta, por lo tanto, mientras este
método es accedido, las demás consultas debes esperar que la que está en curso
nalice. Con FIFO se asegura que no se produzca inanición, es decir, todas las
consultas serán atendidas en algún momento.
Una vez inicializado, el servidor queda escuchando un socket de tipo Server-
Socket (de la clase java.net) esperando clientes, cuando un cliente realiza un
pedido de conexión y éste es aceptado, se crea un socket (de tipo socket, tam-
bién de la clase java.net) y un hilo encargado de manejar la conexión con el
cliente. Este hilo se comunica a través del socket, creado cuando se aceptó la
conexión, más precisamente, a través de los streams asociados a ese socket (uno
para entrada y otro para salida). El hilo también tiene como tarea encolar los
pedidos de los clientes, esperar a que sean atendidos y generar los resultados
que se enviarán.
Para generar los resultados, el servidor cuenta con un módulo que está com-
puesto de varias clases encargadas de generar los distintos tipos de presenta-
ciones de resultados. Entre las presentaciones disponibles, se tiene la que rep-
resenta un camino como un conjunto de instrucciones en forma de texto, de
manera similar a la forma que una persona daría tales instrucciones. Éstas son
armadas utilizando un modulo programado para interpretar la geografía del
camino, es decir, un modulo que provee funcionalidad para obtener longitudes
de cuadras, nombres de calles, sentido de giro y amplitud de los mismos, entre
otras. Este modulo fue programado utilizando herramientas de GeoTools. Otra
forma de presentación, es un archivo de sonido con las instrucciones del camino
traducidas a voz. La traducción es realizada utilizando la librería MBROLA [15]
y un script perl programado por Alistair Conkie (adc@cstr.ed.ac.uk). MBROLA
es un sintetizador de voz, que junto al sript perl forman un sistema conocido
como TTS (del ingles Text To Speach). Hay que señalar que antes de pasar a voz
las instrucciones generadas como se describió anteriormente, se debe realizar un
pequeño formateo al texto, para que tanto el script, como MBROLA, puedan
realizar la traducción correctamente. Por último, se tiene la representación del
camino como una imagen, estas también son armadas con herramientas provis-
tas en la librería GeoTools.
Se debe mencionar que para este proyecto se programó el algoritmo de
búsqueda de caminos mínimos A estrella, y que dicho algoritmo fue aceptado
por la comunidad de desarrolladores de GeoTools y formara parte de la librería.
La misma sólo contaba con el algoritmo de Dijkstra.
5.2.1. A estrella
Como se mencionó anteriormente, la librería GeoTools cuenta, en la exten-
sión de grafos, con el algoritmo de búsqueda de caminos de Dijkstra. El mismo
no está destinado a resolver el problema que en este trabajo se intenta solu-
cionar, pues para un nodo origen, encuentra el menor camino entre él y cada
uno de los nodos del grafo. Mientras que la solución deseada es el camino mínimo
entre dos vértices determinados. Por ello, se empleó el algoritmo de grafos A*
(A estrella), que encuentra el menor camino entre un nodo origen y uno destino;
siendo esto, precisamente, el problema que se intenta resolver. Es claro que con
Dijsktra puede obtenerse el camino que se desea, pero al ser A* especico para
tal n, es conveniente su utilización, que puede resultar más eciente.
Funcionamiento del algoritmo

A estrella utiliza para iterar sobre los nodos, una función de evaluación
llamada f:
f(n) = g(n) + h(n)
Donde,
n es el nodo actual.
h(n) representa el valor heurístico desde n hasta el nodo destino.
g(n) es el costo real del camino recorrido hasta n (es decir, el costo desde
el nodo origen hasta el nodo actual).
La función h debe ser una función de heuristica admisible, es decir, no debe

sobrestimar el costo de alcanzar el nodo destino. Tiene que ser una cota inferior
al costo real del menor camino. [16]
Además se mantienen dos estructuras de datos auxiliares, que se denominan
abiertos y cerrados. Se trata de listas de vértices que se emplean para guardar
información sobre los nodos iterados.[17]
El algoritmo también guarda para cada nodo de la lista abiertos, cuál fue el
nodo que lo agregó a la misma, siendo este último conocido como el padre del
nodo. Esta información es útil a la hora de reconstruir el camino.
En cada paso del algoritmo, se toma el vértice de abiertos con menor costo f,
y de no ser el destino, se agregan a la lista abiertos todos los nodos adyacentes
a éste que no estaban ya en la lista. Para los que se encontraban en la misma,
si se mejora su costo real (g(n)) por ir a través del nodo actual (es decir, si se
cumple que g (nodo actual ) + costo de ir de nodo actual al vecino < g (vecino )),
actualizamos la g del vecino y marcamos como su nuevo padre al nodo actual.

Por último se agrega a cerrados el nodo actual. Cuando el nodo de menor costo
f en la lista abiertos es el destino, se naliza la iteración. El camino búscado es
el que puede construirse viajando desde el nodo destino al origen, a través de
los padres.
func Vecinos(n) // devuelve el conjunto de nodos vecinos de n

func Costo(n,n') // devuelve el costo real para ir de n a n'
func Camino(n)
camino = [n]
while ( n != origen ) do
agrego padre(n) a camino
n = padre(n)
endwhile
return camino
endfunc
func AStar(origen, destino)
ABIERTOS = {origen}
CERRADOS = ∅
while ( |ABIERTOS| >0 ) do

n = nodo en ABIERTOS con menor f;
sacar n de ABIERTOS;
agregar n a CERRADOS;
if n == destino
return Camino(n); // Devolvemos el camino
else
for each n' ∈ Vecinos(n) and n' ∈/ CERRADOS do
if ( n' ∈ ABIERTOS )
if ( (g(n) + Costo(n,n')) <g(n') )
//Si se mejoro el costo real que tenía el nodo n'
// por ir por n, actualizamos el nodo n'
g(n') = g(n) + Costo(n,n');
padre(n') = n;
endif
else
g(n') = g(n) + Costo(n,n');
padre(n') = n;
agregar n' a ABIERTOS;
endif
endfor
endif
endwhile
endfunc
Complejidad
La complejidad computacional del algoritmo está íntimamente relacionada
con la calidad de la heurística que se utiliza en el problema. En el peor caso (con
una mala heurística) la complejidad será la del algoritmo de Dijkstra mejorado,
2
n + e, donde n es el número de vértices y e el de aristas. Si la heuristica es
buena (como usualmente lo es cuando se dispone de la ubicación geográca de
los nodos y el costo es la distancia que se recorre) el algoritmo resulta del orden
de la cantidad de aristas del camino óptimo.
Implementación de A estrella
Dada la intención de contribuir con la librería GeoTools, la implementación
de A*, se vio fuertemente condicionada a la manera de implementar algoritmos
similares en dicha librería. La misma, implementa este tipo de algoritmos como
el trabajo conjunto de tres clases. En el caso de A* estas son:
AStarShortestPathFinder
AStarIterator
BasicGraphTraversal (provista por GeoTools)
La clase AStarIterator es la más importante, ésta provee un método, llamado

cont, para realizar un paso del algoritmo A*, además mantiene la representación
de las listas abiertos y cerrados. La primera está implementada a través de
una cola de prioridades, disponible en la librería, mientras que la segunda, no
está implementado como un objeto en sí, su representación es por medio de
un atributo en los nodos, que indica si los mismos se encuentran en la lista
o no. El método cont, recibe como parámetro un nodo, y realiza un paso del
algoritmo A*. Este busca todos los vértices vecinos al nodo parámetro, los que se
encuentran en cerrados son ignorados y el resto son agregados a la lista abiertos,
o modicados de ser necesario, si ya se encontraban en la misma.
AStarShortestPathFinder, es la encargada de inicializar las otras dos clases
y provee métodos para iniciar la búsqueda de camino y obtener el camino resul-
tante. La clase BasicGraphTraversal, tiene como función intermediar la comu-
nicación de las otras dos clases.
Cuando se pide el camino mínimo entre dos nodos, AStarShortestPathFinder
le pide a BasicGraphTraversal que ejecute un paso del algoritmo A*, esta última,
lo realiza a través del método cont de la clase AStarIterator. Una vez nalizado
el paso, la clase BasicGraphTraversal obtiene el nodo de menor f de la lista
abiertos y lo pasa a la clase AStarShortestPathFinder. Ésta controla si es el
nodo destino, en cuyo caso, la búsqueda naliza. Caso contrario, se avisa a
BasicGraphTraversal que no es el destino, por lo que se realiza otro paso del
algoritmo. Esto se da hasta que se encuentre un camino, es decir, el menor nodo
de la lista abiertos es el nodo destino, o se hayan agotado todos los nodos.
5.2.2. Comparación entre las implementaciones de

Dijkstra y A*
La comparación fue realizada en una máquina con micro Intel Core 2 duo 2.8
Ghz, 2 Giga RAM, en un sistema SUSE Linux 10.3 x86 64 bajo la jre 1.6.0 06.
Tabla de promedios de tiempos:
5.3. Cliente
Para este proyecto se realizaron dos tipos de clientes, uno que se ejecuta en
computadoras de escritorio y otro en dispositivos móviles. La programación de
los mismos fue realizada en java, el cliente de dispositivos móviles se codicó
con j2me, mientras que el cliente pc fue realizado en Java se.
La funcionalidad principal de los clientes es la de proveer una interfaz para
que los usuarios puedan realizar las consultas y ver sus resultados. Además
maneja el protocolo de comunicación con el servidor.
5.3.1. Cliente para computadoras de escritorio

Cuando se inicia el cliente, éste trata de conectarse a un servidor, en una di-
rección y puerto almacenados en un archivo de conguración. Si en tal dirrección
no hay servidor escuchando o es rechazada la conexión, el cliente informa que
no ha podido conectarse. Los usuarios desde un menú de conguración pueden
cambiar tanto la dirección como el puerto al cual el cliente va ha intentar conec-
tarse, es decir, el lugar donde se encuentra el servidor.
Una vez establecida la conexión, el cliente ofrece una interfaz sencilla y dis-
eñada con algunas características especiales orientada a personas no videntes o
con disminución visual. Estas particularidades en la interfaz, fueron realizadas
con la ayuda de profesoras del Instituto Helen Keller, capacitadas para enseñar
a personas, para las cuales está destinado el software. Entre algunas de estas
propiedades podemos mencionar, los colores y textos utilizados, la disposición
de los componentes y la forma en que se presentan los resultados.
A través de la interfaz se pueden realizar consulta de camino mínimo o pedir
información sobre una dirección. Ante la selección de cualquiera de estas con-
sultas, se solcita al usuario que ingrese datos para poder realizarla, luego, el
clinte se encarga de la comunicación con el servidor y de ser necesario deman-
da al usuario que ingrese más o nuevos datos para poder nalizar la consulta.
Por último, se muestran los resultados recibidos desde el servidor, en el cliente.
También se ofrece la posibilidad de guardar puntos favoritos, estos son direc-
ciones que los usuarios pueden almacenar en el programa para luego desde las
interfaz de las consultas utilizarlas como parámetros de las mismas. Al guardar
un punto favorito el usuario relaciona un nombre con una dirección (calle y al-
tura). Además se provee la posibilidad de aumentar el tamaño de los textos y
componentes, para facilitar la visualización a personas con disminución visual.
Otra característica del cliente, es que pueden agregarse módulos para visulizar
la interfaz en distintos idiomas, esto se realizó, utilizando las funcionalidad de
internacionalización, conocida com I18N, del lenguaje Java.
El cliente cuenta un módulo para comunicarse con el servidor, en éste se
encuentra programado el protocolo mencionado anteriormente. Además tiene
módulos encargados de manejar la interfaz gráca y módulos que manejan los
archivos de conguración, tanto los de parámetros de conexión, como los de
conguración de idioma y tamaño de visualización.
5.3.2. Cliente para dispositivos móviles

Debido a la reducción de capacidades disponibles en dispositivos móviles, el
cliente de este tipo es más limitado en cuanto a funcionalidad y presentación.
Cuando se inicializa el cliente, se muestra una pantalla en donde debe ingresarse
la dirección y el puerto en el cual recide el servidor con el que se quiere conec-
tar. Si se logra establecer la conección, se muestra una pantalla para realizar
la consulta de camino mínimo, en donde deben introducirse dos direcciones,
por ultimo, si se consultó al servidor, se tiene una pantalla para visualizar los
resultados recibidos.
El cliente de dispositivos móviles cuenta con una cantidad menor de clases
que el cliente pc. Tiene modulos para el manejo de la conexión con el servidor,
la comunicación con el mismo, y la obtención y presentación de los datos.
6. Conclusiones
En primera instancia, no se puede dejar de notar que la sociedad en que

nos desenvolvemos está exenta de la infraestructura necesaria para lograr la
integración total de las personas con discapacidad, cualquiera sea el origen de
la misma. Esta ausencia de facilidades es un obstáculo diario para este grupo
social, que podría ser solventado a través de planes gubernamentales e iniciativas
institucionales.
En segundo lugar, y teniendo en cuenta la temática sobre la que se basa
este trabajo, es indispensable notar que gran parte de las herramientas o util-
idades diseñadas para mejorar la calidad de vida de las personas referidas con
discapacidad visual tienen un alto costo comercial. Esto resulta un obstáculo
económico para el grupo social así como también una restricción para el desar-
rollo de la sociedad misma, que se ve privada de contar con la contribución y
producción del grupo referido al impedirle acceder a las tecnologías y facilidades
que permitan desarrollar al máximo sus capacidades.
Este trabajo intenta contribuir a la resolución de los puntos mencionados
proporcionando una herramienta cuyo objetivo principal es asistir al individuo
discapacitado en la construcción de mapas mentales y por ende en el desarrol-
lo del sentido de orientación. También, dadas las numerosas posibilidades de
extensión asociadas al proyecto realizado y la nalidad solidaria del mismo, se
consideró fundamental distribuir el programa de manera gratuita, con una li-
cencia libre (GPL). El software libre es un medio para lograr la contribución
de toda la comunidad en el desarrollo de herramientas de software, permitiendo
que aquél que lo desee y sepa cómo hacerlo, pueda extender las funcionalidades
del proyecto y compartir tales ampliaciones. Esto convierte a la comunidad to-
da en potencial desarrolladora, lo que maximiza las posibilidades de crecimiento
del proyecto y permite la existencia de una retroalimentación fructífera entre
todos sus integrantes. En este sentido, la elaboración del proyecto también ha
contribuido a la comunidad del software al hacer una colaboración al desarrollo
de la librería GeoTools. Tal aporte consistió en la ampliación de la libreria, que
agregó módulos que implementan un algoritmo de búsqueda de caminos que no
era brindado hasta el momento. La ampliación realizada fue aceptada por la
comunidad desarrolladora de GeoTools y formará parte del paquete distribuido
por esta organización.
Es necesario insistir en que existe una amplia variedad de extensiones posi-
bles para este proyecto, lo cual deja en claro que sería positivo que no se detenga
en este punto la continuidad en el desarrollo. Entre las extensiones más impor-
tantes y necesarias que existen, cabe mencionar:
La integración de los recorridos del transporte urbano de pasajeros,

junto a la funcionalidad de dar instrucciones precisas de cómo realizar
un trayecto utilizándolo como medio principal
6. Conclusiones 62
Cuando el trayecto que se desea realizar es prolongado, movilizarse a pie

puede ser poco factible. En estos casos es corriente utilizar medios de trans-
porte (auto, colectivo, etc.). La persona discapacitada visual encontraría de gran
utilidad acceder a la información que detalle qué medios se dirigen cerca de su
destino, y cómo utilizarlos. La ide básica que persigue esta extensión es que el
programa realice varios conjuntos de instrucciones que permitan al usuario uti-
lizar los medios de la manera más intuitiva posible. En particular, se esperaría
que se genere un conjunto de instrucciones verbales para el recorrido desde el
origen hasta el punto de la ciudad donde se accede al medio de transporte, otro
para saber cuándo el usuario debe nalizar el uso del medio, y nalmente, un
tercero para determinar cómo complementar el recorrido del medio para llegar
a destino.
Agregar la tecnología GPS (Global position system)

Esta tecnología permitiría una interacción más uída, dinámica y realísta
entre el usuario y el software. El objetivo principal de esta extensión está fun-
damentado en la idea de aumentar la inteligencia articial del producto. Sería
notorio, por ejemplo, que de suceder que el usuario se desvíe del trayecto prop-
uesto (ya sea porque encuentra un obstáculo que le impide seguir, o porque
perdió la orientación), el programa le indicara de tal evento y le preguntara si
desea reformular el recorrido o recibir instrucciones para retornar al original. A
su vez, al tener un indicador de la posición exacta del usuario, no sería nece-
sario ejecutar un comando para recibir la próxima instrucción; el programa la
suministraría en el momento en que se debe realizar, evitando la necesidad del
usuario de conocer su posición.
Integrar tecnología de reconocimiento de voz, para facilitar la in-

teracción con el usuario
Como se ha visto en el capítulo 3, varios de los dispositivos diseñados con
funcionalidades símiles a las ofrecidas por este trabajo, apuntan a utilizar la
tecnología mencionada conjuntamente a las voces electrónicas para establecer
una comunicación verbal con el usuario. Esta funcionalidad evitaría toda
necesidad de interactuar manualmente con el dispositivo que se esté utilizando,
otorgando mayor practicidad y simplicando la utilización de otros recursos de
asistencia como podría ser el bastón blanco. Es muy probable también que, a
través de este recurso, se logre una interacción más eciente (en rapidez, y u-
idez por ejemplo) con el programa, lo cual minimizaría los tiempos necesarios
para obtener resultados.
Crear un sistema de actualización de bases de datos

Dado la cantidad de datos que se manejan en el programa desarrollado, y
la constante variación de los mismos debido a las obras públicas, el crecimiento
urbano, etc. se vuelve básico pensar en mantener tales datos tan actualizados
como sea posible. Una solución idónea consistiría en la existencia de un servi-
dor de datos cartográcos actualizados y ociales, a partir del cual se puedan
hacer actualizaciones periódicas. Una solución más simple consiste en brindar
la funcionalidad de actualizar los datos de manera manual, desde una fuente
determinada por el usuario. Esto también sería necesario si se contara con la
funcionalidad que tiene en cuenta los medios de transporte, ante la necesidad
de tener los datos de sus recorridos tan actualizados como sea posible.
6. Conclusiones 63
Crear un dispositivo especíco para el software realizado

La creación de un dispositivo especíco permitiría optimizar al máximo todas
las capacidades del producto que se brinda. Al construir un artilugio especial-
mente diseñado a los nes de la capacidad del software, se puede pensar en
las características fundamentales para la interacción con el usuario, eliminando
todo aquello que no sea especíco de su funcionalidad. La realización de esta
extensión, en conjunto a la concreción de las anteriormente mencionadas, per-
mitiría acercarse de manera más profunda a la solución ideal detallada en el
capítulo 2.
Apéndice
A. Manual de Usuario
A.1. Introducción
Tiresias es un programa que intentará asistir a la persona discapacitada
visual en la tarea frecuente de movilizarse en un entorno urbano. Se trata de
una aplicación que brinda información cartográca de una ciudad particular en
tres formatos, a saber:
Sonoro: los resultados de las consultas son presentados de manera oral por
el programa. Se crea un archivo .wav que puede ser guardado en un medio
móvil como un reproductor de mp3 o un celular.
Textual: los resultados de las consultas son presentados de manera textual,

a los nes de tener la posibilidad de imprimirlos. Aquéllos se presentan en
texto plano, lo que maximiza la posibilidad de ser utilizados conjuntamente
con impresoras braille.
Visual: los resultados de las consultas son presentados de manera visual,

en un mapa con una combinación de colores particular que espera permitir
a la persona disminuida visual distinguir los componentes que se presentan
de la manera más concisa posible.
Tiresias funciona como un nomenclador cartográco digital, proveyendo dos

funcionalidades principales:
1. Consultar información sobre una dirección particular. Dado el un nombre

de calle y una numeración, permite conocer si esa dirección es válida (existe
una calle con ese nombre y esa altura), y de ser así, cuál es el barrio en
que se encuentra.
2. Consultar cuál es el camino más corto para realizar a pie entre dos direc-
ciones cualesquiera de la ciudad. Se genera un conjunto de instrucciones
que le dirán cómo desplazarse a través de camino sugerido.
En las secciones siguientes encontrará instrucciones precisas sobre los requerim-

ientos del sistema, las formas de instalación particulares a cada sistema oper-
ativo, y descripciones más detalladas acerca de las funcionalidades, interfaz, y
manejo de Tiresias.
A.2. Requerimientos
Procesador: Equivalente Pentium 3 o superior.
Memoria: mayor o igual a 256 RAM.
A. Manual de Usuario 66
Disco: 100 Megabytes.

Sonido: Cualquier placa de sonido estándar.
Video: Cualquier placa de video que soporte una resolución de 800x600
pixels o superior.
Software: Máquina Virtual de Java 1.6 o superior. Para mayor rendimien-

to con lectores de pantalla, se recomienda instalar el AccessBridge de Sun.
A.3. Instalación
A.3.1. Windows
La instalación bajo windows se realiza de forma totalmente automática. No
es necesario tener la máquina virtual de Java previamente instalada. En caso de
que ésta no se encuentre en su sistema, el instalador le ofrecerá la posibilidad de
instalarla. El instalador también ofrecerá la posibilidad de instalar AccessBridge
para lograr la mejor interacción posible entre la PC y el software.
Para instalar Tiresias ejecute el archivo instalar.exe. Se ejecutará un asistente
de instalación que lo guiará a través del resto del proceso.
Tiresias se distribuye con una licencia GPL(GNU General Public License ó
Licencia Pública General) que se detalla durante el proceso de instalación, y
que deberá ser leída y acordada para poder proseguir con tal procedimiento.
Una vez instalado podrá ejecutar el programa entrando al menú de inicio,
programas, y seleccionando la carpeta correspondiente a Tiresias. Aquí también
encontrará una opción para desinstalar el programa.
A.3.2. Linux
Para instalar Tiresias bajo Linux se deberá descomprimir el archivo insta-
lar.tar.gz. Una vez realizada esta acción tendrá la posibilidad de instalar la
máquina virtual de java accediendo a la carpeta adicionales y utilizando el
método que mejor se adapte a su versión de este sistema operativo.
Tiresias se distribuye con una licencia GPL(GNU General Public License ó
Licencia Pública General) que se detalla en el archivo licencia.rtf. Si el usuario
realiza las acciones de instalación y utiliza Tiresias, se asumirá que ha leído y
acordado tal contrato.
Una vez que tenga todas las dependencias necesarias, podrá correr su cliente
ejecutando el comando java -jar ClientePC.jar.
A.3.3. Notas generales

Tiresias está diseñado con un conjunto de sonidos que indican las carac-
terísiticas básicas de la interacción con el usuario (éxito, fracaso, opciones, etc.).
Sin embargo, se prevee un aprovechamiento máximo de sus cualidades a través
de la utilización conjunta con herramientas que normalmente se utilizan como
medios de accesibilidad ante la discapacidad visual. Este tipo de herramientas
inluye lectores de pantalla (como Jaws), magnicadores de pantalla, y cualquier
otra utilidad que ayude a la persona discapacitada visual a utilizar recursos
informáticos.
A.4. Interfaz
Cuando ejecute Tiresias se desplegará la ventana principal del programa,
que cuenta con los siguientes elementos:
En la parte superior, una barra de menú tradicional, conteniendo las op-

ciones: Archivo, Preferencias, Herramientas, Ayuda.
En la zona central de la ventana, tres botones ubicados de manera vertical

con los siguientes textos: Camino Mínimo, Consulta Dirección, Ampliar.
La interfaz de Tiresias se maneja también con un conjunto de sonidos informa-

tivos que intentarán hacer el funcionamiento del programa más intuitivo para el
usuario. Estos sonidos son básicamente 5, y expresan las siguientes situaciones:
1. Exito: Una operación fue realizada exitosamente.
2. Selección: se presionó un botón, o una opción de menú.
3. Advertencia: Existe algún problema ligero (un error de parámetros, por

ejemplo).
4. Error: Existe algún problema grave. Por ejemplo, no se puede comunicar

con el servidor (puede que el servidor de Tiresias esté caído, o que esté
mal congurada la dirección de comunicación o el puerto).
5. Opciones: Se presentan una serie de opciones. Por ejemplo, cuando debe

elegir un punto favorito de entre todos los que tiene guardados.
A.4.1. Descripción y atajos de teclado

ALT+Q Cerrar
ALT+C Conguración
ALT+M Camino mínimo
ALT+D Consulta dirección
ALT+F Editar favoritos
ALT+R Ampliar/Reducir
ALT+U Ayuda
ALT+N Acerca de
Archivo (ALT+A): Este menú sólo muestra la opción de salir del programa.
Para salir del programa sin necesidad de acceder a este menú también puede
utilizar el atajo de teclado ALT+Q.
Preferencias (ALT+P): Este menú sólo muestra la opción congurar. Para
acceder directamente a esta opción puede presionar el atajo de teclado ALT+C.
Esta opción desplegará una nueva ventana en la que podrá congurarse la di-
rección del servidor de Tiresias, el puerto de comunicación con el mismo, y el
idioma en el que está escrita la interfaz. La tecla TAB permite desplazarse entre
los elementos de la ventana. Utilice ALT+G para guardar los cambios realiza-
dos y cerrar la ventana o bien ALT+S para salir de la ventana sin guardar los
cambios.
Herramientas (ALT+H): Este menú es otra forma de obtener acceso a los
botones principales de la aplicación. En él encontrará acceso a las funcional-
idades principales (Camino Mínimo, Consulta Dirección, Ampliar) así como
también acceso a la funcionalidad de Favoritos.
Camino Mínimo (ALT+M): Esta es la funcionalidad principal de Tiresias.

Su utilización generará un conjunto de instrucciones sobre cómo llegar
desde un punto de la ciudad a otro. Al acceder a ella se abrirá una nueva
ventana que dispondrá de cuatro campos de texto, dos botones para ac-
ceder a favoritos, y los botones Consultar (ALT+C) y Salir (ALT+S). Se
podrá avanzar a través de los campos de texto a utilizando la tecla TAB
del teclado. Para retroceder podrá utilizar la combinación SHIFT+TAB.
Apenas se abra esta ventana, el cursor estará situado en donde se debe

escribir el nombre de la calle de origen. En el segundo cuadro de texto se
espera que se introduzca la numeración correspondiente a la dirección de
origen. Los siguientes dos cuadros de texto funcionan de manera análoga,
esperando el nombre de calle y la numeración de la dirección de destino.
Con TAB también puede acceder a los botones consultar (ALT+C) y salir
(ALT+S).
Puede suceder que una vez ejecutada la consulta, el servidor de Tiresias

no encuentre alguna de las direcciones especicada. En estos casos se oirá
el sonido de advertencia a la vez de que una ventana se desplegará infor-
mando cuál es la dirección que ha presentado conicto. Una vez cerrada
esa ventana (se puede cerrar con ENTER, barra espaciadora, o ESCAPE),
volveremos a la ventana de camino mínimo, pero la dirección conictiva
habrá sido borrada. El cursor estará en posición para ingresar una nueva
dirección.
También es posible que alguna de las direcciones ingresadas no sea lo su-

cientemente precisa. Por ejemplo, escribir como dirección de origen Juan
523 hará que Tiresias descubra muchas calles cuyos nombres contienen
la palabra Juan, y que a su vez contengan la numeración 523. En estos
casos, Tiresias reproducirá el sonido de Opciones y se abrirá una nueva
ventana con todas las opciones disponibles. En ella se detallarán el número
de opción seguido del nombre de la calle y del barrio al que ésta pertenece.
Para elegir una opción basta con ingresar el número de la opción deseada
y presionar Aceptar (ALT+A). Si no se selecciona ninguna opción (se pre-
siona Salir o el atajo ALT+S) el cursor se situará en el primer cuadro de
texto de la dirección que haya dado conictos, y los valores que hubiera
habido allí habrán sido borrados.
Consulta Dirección (ALT+D): Cuando se selecciona esta opción, se abre

una nueva ventana que contiene dos campos de texto, y dos botones. Los
campos de texto corresponden al nombre de la calle y la numeración de la
dirección sobre la cual se quiere hacer la consulta. Los botones son Con-
sultar y Salir (ALT+C y ALT+S respectivamente). Esta opción funciona
prácticamente de igual forma que Camino Mínimo, dando información
sobre la o las direcciones que resulten como resultado de la consulta.
Ampliar (ALT+R): Ampliar permite magnicar el tamaño de los compo-

nentes de la interfaz. Al seleccionar esta opción el texto del botón mismo
cambiará a Reducir. Se puede presionar este nuevo botón con el mismo
atajo de teclado (ALT+R) para volver al tamaño original de la interfaz.
Editar Favoritos (ALT+F): Esta opción permite ir guardando una serie

de puntos de uso frecuente dándoles un nombre identicatorio fácil de
recordar como puede ser mi casa, almacén, etc. Se describirá con más
detalle en la siguiente sección.
A.4.2. Favoritos
Al presionar la combinación de teclas ALT+F desde la ventana principal
de emphTiresias, se abrirá la ventana de edición de puntos favoritos. El cursor
estará situado sobre algún punto favorito que se haya almacenado. En esta
ventana se detallan todos los puntos favoritos existentes. A través de las echas
arriba y abajo puede ir desplazándose entre los favoritos guardados para luego
modicarlos (ALT+M) o borrarlos (ALT+B). Para agregar un nuevo favorito
deberá desplazar el cursor hasta el botón Agregar, o bien presionar el atajo
de teclado ALT+A. Tanto al modicar como al agregar un punto favorito, se
despliega un nuevo cuadro de diálogo que tiene dos campos de texto: El primero
para el nombre de la calle del favorito, y el segundo para la numeración. En el
caso de agregar habrá un campo adicional que le permitirá escoger un nombre
para su nuevo favorito. Si presiona borrar (o si se ejecuta su atajo), se abrirá
un cuadro de diálogo que preguntará si está seguro de que desea ejecutar dicha
acción. Todos los menúes tienen un botón salir que se accede a través del atajo
de teclado ALT+S.
Para acceder a la lista de puntos favoritos en las consultas de camino mín-
imo, podremos presionar el atajo de teclado ALT+F dentro de la ventana de
consulta. Esta lista tiene un conjunto de direcciones de uso frecuente. Cada
punto favorito tiene un número de ubicación en esta lista de direcciones que
nos permite identicarlo. Ingresando el número del punto favorito deseado y
presionando el botón Aceptar (ALT+A) habremos rellenado automáticamente
los campos de dirección en el que el cursor haya estado situado. Para cancelar
esta operación es posible apretar el botón Salir con la barra espaciadora o bien
utilizar el atajo de teclado ALT+S. Si se presiona Aceptar y no se ha escrito
ningún número de opción o se ha escrito un número de opción erróneo (inexis-
tente, por ejemplo) se oirá el sonido de advertencia y se mostrará una ventana
de información. Para salir de tal ventana presione ENTER, barra espaciadora
o ESCAPE. Volverá a estar en la ventana de Favoritos.
A.5. Presentación de los resultados

En el caso de la consulta más simple (información acerca de una dirección)
se despliega un diálogo con una lista de todas las direcciones (calle, barrio) que
satisfacen los parámetros de búsqueda ingresados anteriormente.
Para la consulta más compleja de encontrar el camino más corto entre dos
direcciones, se abrirá un nuevo cuadro de diálogo que constará de 3 secciones,
a saber:
Un mapa de alto contraste: En este mapa se muestra el camino a recorrer.

Los colores que se utilizan son: negro para el fondo, verde para las calles,
rojo para el camino, y blanco para las marcas de comienzo y nal de
camino. Las marcas del mapa representan el comienzo del camino con un
círculo y el nal con una cruz.
Una sección de sonido: en esta sección hay tres botones que permiten re-
producir, pausar, continuar, y detener el audio de las indicaciones acerca
del cómo ir desde el punto de origen hasta el punto de llegada. El botón
Reproducir (ALT+R) dará comienzo a este sonido, y se convertirá inmedi-
atamente en el botón Pausa (ALT+P). El botón Detener (ALT+D) de-
tendrá la ejecución del sonido y lo rebobinará hasta su comienzo. Además
de estas funcionalidades, existe un botón Guardar Sonido (ALT+G), que
abre un diálogo para seleccionar una ubicación para guardar el archivo de
sonido de las instrucciones en formato WAV. Esto puede resultar útil si se
utiliza con un reproductor de mp3 tradicional.
Una sección de instrucciones: esta sección permite acceder a las instruc-

ciones de recorrido en forma de texto escrito. Cuenta con tres funcional-
idades: Ver (ALT+V), Imprimir (ALT+I), y Guardar Texto (ALT+T).
Ejecutar Ver desplegará un diálogo con las instrucciones escritas, de modo
tal que puedan ser leídas por un lector de pantalla. Imprimir mandará el
texto sin formatos adicionales para ser impreso en braille o en una im-
presora de tinta. Guardar Texto permitirá guardar un archivo en formato
TXT en alguna ubicación a escoger en el cuadro de diálogo subyacente.
B. Capturas
B.1. Capturas de Tiresias

Ventana Principal:
Ventana de conguración (ALT+C):

B. Capturas 72
Ventana de administración de puntos favoritos (ALT+F):
Dialodo para agregar un punto Favorito:
Dialodo de Modicación de un punto Favorito:

B. Capturas 73
Dialogo de Busqueda de camino mínimo:
Dialogo de Busqueda de información de dirección:
Ventana de elección de un punto favorito:

B. Capturas 74
Ventana opciones de dirección:
Ventana de resultado de la consulta de información de dirección:

B. Capturas 75
Ventana Resultado de la consulta de camino mínimo:
Ventana de instrucciones del camino mínimo:

B. Capturas 76
B.1.1. Comparación modo normal y modo ampliado

B. Capturas 77
B.2. Capturas del cliente móvil sobre emulador

java
Ventana de conexión: Ventana de ingreso de párametros:
B. Capturas 78
Ventana de opciones de dirección: Ventana de resultados:

Bibliografía
[1] Organización Panamericana de la Salud. Discapacidad: Lo que todos

debemos saber. 5 de mayo del 2006
[2] Manual de Desarrollo Inclusivo. Banco Mundial. Río de Janeiro, 2005
[3] Programa de acción mundial para las personas con discapacidad. Res-
olución 37/52 de 3 de diciembre de 1982, de la Asamblea General de las
Naciones Unidas.
[4] Normas uniformes de las naciones unidas. Resolución 48/96, anexo,

aprobado por la Asamblea General de las Naciones Unidas el 20 de
diciembre de 1993.
[5] Libro
[6] An Introduction to Text-To-Speech Synthesis,

T. DUTOIT, Kluwer Academic Publishers, Dordrecht
Hardbound, ISBN 0-7923-4498-7 April 1997, 312 pp.
[7] FUNDAMENTAL OF SOFTWARE ENGINEERING. Carlo Ghezzi,

Mehdi Jazayeri, Dino Mandrioli.
Prentice Hall, 1991.
[8] THE WAY OF Z Practical Programming with Formal Methods. Jonathan

Jacky.
Cambridge UIniversity Press, 1997
[9] USING Z Specifcation, Refnement, and Proof. Jim Woodcock, Jim Davies.
1995.
[10] The Z Notation, A Reference Manual. Second Edition. J. M. Spivey

J. M. Spivey Oriel College, Oxford, OX1 4EW, Inglaterra. 1998
Bibliografía 80
[11] JAVA TECH. Clark Lindsey, Johnny Tolliver, Thomas Lindblad.

Editorial Cambridge.
[12] http://es.wikipedia.org/wiki/Servidor web

http://en.wikipedia.org/wiki/Web server
[13] http://en.wikipedia.org/wiki/Distributed computing
[14] http://es.wikipedia.org/wiki/CORBA
[15] Página oial del proyecto MBROLA. http://tcts.fpms.ac.be/synthesis/mbrola.html
[16] http://en.wikipedia.org/wiki/Admissible heuristic
[17] http://es.wikipedia.org/wiki/Algoritmo de búsqueda A*
[18] http://en.wikipedia.org/wiki/A star

Tesis Malbran-Trouillet

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Tesis Malbran-Trouillet

Hochgeladen von

Copyright:

Verfügbare Formate

Nomenclador cartográco para personas

con discapacidad visual

Malbrán, Francisco G. - Trouillet, Germán E.

El presente trabajo describe el desarrollo de una herramienta informática

2.. Descripción del problema . . . . . . . . . . . . . . . . . . . . . . . 10

3.. Relevamiento de Herramientas Existentes . . . . . . . . . . . . . 17

4.. Especicación y Diseño . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1.4. Con numeración para las calles . . . . . . . . . . . . . . . 40

De los 85 millones de personas de América Latina que padecen dis-

Es evidente que si bien la sociedad actual en la que nos vemos inmersos

ha de ser imposible mantener en la mente una cantidad tan inmensa de variables.

lanzó un programa de creación y distribución a pedido de mapas táctiles. El

3 GPS: Global Position System (Sistema de Posicionamiento Global)

El capítulo 6 incluirá conclusiones acerca del trabajo tales como: funcional-

2.1. Contexto General

Casi no existe transporte público con puertas sucientemente amplias y/o

Carencia de rampas para silla de ruedas en numerosos sectores de la ciu-

Carencia de semáforos especiales para personas discapacitadas visuales en

Prácticamente no existen indicaciones en braille en sitios estratégicos tales

Es importante notar que estos obstáculos convergen a un papel fundamen-

1 Tanto el Dr Vázquez como la Dra Amate son médicos especialistas en rehabilitación

tengan en cuenta la discapacidad y que sean efectivamente aplicadas conlleva un

2.2. La Discapacidad Visual

2.2.1. El Mapa Mental

2.3. La Solución Ideal

Algunos puntos a considerar para imaginar el desarrollo de una herramienta

Que ponga a disposición la información cartográca de la ciudad en un

Que permita consultar acerca de cómo llegar a una zona especíca de la

Que pueda dar cuenta de la posición actual del individuo en el trayecto

Que sea portable

Que la forma de interacción con el usuario sea lo más sencilla y dinámica

Que brinde información acerca de los medios de transporte utilizables para

Que brinde información acerca de posibles puntos de interés (hospitales,

Que pueda informarse y brindar información acerca de eventos especícos

Para empezar a gurarse la solución buscada, se puede pensar que la misma

mecanismo se realiza de manera estrictamente visual. Para adaptar esta fun-

4 Posición absoluta de latitud-longitud

deseado si no se atraviesa determinado obstáculo por él especicado.

En este capítulo se describirá el resultado de un relevamiento realizado en

Detección de información en tiempo real (intersecciones, puntos de in-

Navegación de mapas en tiempo real y o-line (previsualización de rutas)

Planeamiento y almacenamiento de rutas.

Creación vocal de puntos de interés.

Fig. 3.1: Dispositivo GPS Trekker

Acceso a la información de estado del GPS.

Su costo aproximado es de 1700 euros y los mapas se compran por separado.

3.1.2. Sendero GPS

Fig. 3.2: Dispositivo GPS Sendero

Fig. 3.3: Dispositivo PAC Mate

PAC Mate: Un dispositivo PDA para personas discapacitadas visuales.

StreetTalk: Software instalable en PAC Mate utilizado para la navegación

Bluetooth GPS Receiver: El receptor de señal GPS.

Para adquirir el paquete completo es necesario un presupuesto aproximado

Fig. 3.4: Sonic Pathnder

The Sonic Path Finder (Buscador sónico de caminos)

Fig. 3.5: C2 Talking Compass

Fig. 3.6: Laser Cane

3.2.2. Quantum GIS

Editar, ver, y buscar atributos de los datos espaciales

Crear, editar, y exportar datos espaciales

Publicar mapas en internet

Adaptar la herramienta a través de los plugins

3.2.3. El proyecto MBROLA

3.2.7. Dragon NaturallySpeaking

Nomenclador cartográco para personas

4.. Especicación y Diseño . . . . . . . . . . . . . . . . . . . . . . . . 35

De los 85 millones de personas de América Latina que padecen dis-

Casi no existe transporte público con puertas sucientemente amplias y/o

Que ponga a disposición la información cartográca de la ciudad en un

Que permita consultar acerca de cómo llegar a una zona especíca de la

Que pueda informarse y brindar información acerca de eventos especícos

Para empezar a gurarse la solución buscada, se puede pensar que la misma

deseado si no se atraviesa determinado obstáculo por él especicado.

Navegación de mapas en tiempo real y o-line (previsualización de rutas)

Fig. 3.4: Sonic Pathnder

Decodicador: un decodicador está encargado de transformar la señal

Posea una interfaz desarrollada especícamente teniendo en cuenta la

1. Suba por la calle X1 unos 50 metros.

2. Cruce la calle X2 y continue por la calle X1 unos 75 metros.

3. Doble en diagonal a la derecha por la calle X3 unos 40 metros.

4. Ha llegado a destino.

En este capítulo se mostrará la especicación del grafo que representa la

A continuación se dene un esquema que dice que c es un camino que une

La forma básica de modicar el grafo será agregando y quitando vértices del

Para determinar el costo de un camino se dene el siguiente esquema que

A partir de estas deniciones podemos entonces denir el conjunto de caminos

Ahora necesitamos expandir la función AgregarVertice denida en la sección

El error de la operación pasará a denirse de una manera sutilmente distinta,