Pre-editor: Free software to support collaborative
processes to improve Open Street Map
Abstract—Nowadays digital maps are a basic tool for decision
making. The decisions that are made affect the quality of life
of the people who inhabit the spaces that are represented. Map
making is not an objective process, organizations, institutions
and big tech companies reproduce their own interests (mainly
commercial) and biases in the map (making invisible vulnerable
populations). The use of automated decision-making technologies,
based on the analysis of big data, represents a risk for populations
underrepresented in these maps. At the same time, a reflection
is needed that leads us to create and use maps that do not
discriminate. Open Street Map (OSM) is a repository containing
open geospatial data contributed by millions of people around
the globe. With OSM data is possible to create maps that don’t
reproduce interests of a few, and also, by being open source, it
allows auditing on how a decision was made. Although OSM
is a free participation platform, it has some socio-technical
characteristics that make it difficult for volunteers to participate
in geospatial data capture and editing processes. This paper offers
a functional prototype developed as free software to counteract
these difficulties.
Index Terms—Free cartography, Open street map, Free soft-
ware, Open data, Critical cartography
I. I NTRODUCCI ÓN
Hoy en dı́a los mapas digitales son una herramienta básica
para la toma decisiones. Las decisiones que se toman reper-
cuten en la calidad de vida de las personas que habitan
los espacios que se representan. Sin embargo, utilizar datos
abiertos geoespaciales producidos de forma colaborativa, para
apoyar estos procesos de toma de decisiones requiere de
software apropiado y comunidades e instituciones tomado-
ras de decisión con una capacidad de alfabetización digital
crı́tica. Si bien, desde el punto de vista tecnológico existe
hardware y software que por su modelo de licenciamiento
pueden ser apropiados para apoyar los procesos de mapeo
aún es necesario realizar mejoras para favorecer la producción
colaborativa de datos abiertos geoespaciales. Estas mejoras
deben ser realizadas con una perspectiva que debe considerar
tanto los aspectos técnicos como los sociales, aspectos que
comodifican el proceso de desarrollo de las herramientas [1].
Al utilizar el concepto de datos abiertos nos referimos a la
caracterización ampliamente difundida: datos accesibles, que
pueden ser leı́dos por máquinas y cuyo uso no es restringido a
través de alguna licencia [2]. Los datos geoespaciales abiertos
son los que además de la caracterización anterior incluyen
una referencia a una ubicación. Según el informe del Estado
de los Datos Abiertos 2019 un 80% de los datos guberna-
mentales están georeferenciados [3]. La Comisión Económica
para América Latina y el Caribe (CEPAL) identifica una
oportunidad de colaboración entre la comunidad geoespacial
con experiencia en el uso de herramientas basadas en código
abierto para la creación, análisis y publicación de información
geoespacial que pueda nutrir oficinas nacionales, de cara a
un mejor seguimiento del progreso en el cumplimiento de los
Objetivos del Desarrollo Sostenible (ODS) [4].
Históricamente, el uso tı́pico de los datos geoespaciales
es la representación en un mapa. Pero estas representaciones
están lejos de ser objetivas, según Tetamenti, ”El mapa es un
territorio de poder donde la representación es supuestamente
a escala de una realidad indiscutible y objetiva. Esta realidad
trazó los mapas desde las más antiguas instituciones de poder:
la Iglesia, los imperios, los reinos; hasta los más modernos
sistemas de información geográfica sincronizados en Internet,
como Google Earth o Bing” [5, p. 31].
La tecnologı́a y los datos con los que se produce un
mapa pueden reforzar el pensamiento colonial y perpetuar
en el espacio digital la marginalización y vulnerabilidad de
comunidades ya discriminadas en el espacio real [6]. Un
ejemplo contemporáneo de esta posibilidad lo encontramos
en el mapa solar de Rı́o de Janeiro [7], el cual fue construido
para visibilizar el potencial de generación energı́a eléctrica por
medio de paneles solares. En este mapa se utilizaron datos de
las edificaciones de la ciudad excluyendo aquellas estructuras
ubicadas en asentamiento informales.
Con la tecnologı́a geoespacial basada en software libre y
datos abiertos se tiene el potencial de producir mapas desde
una perspectiva de inclusión, centrada en las necesidades y los
problemas de las comunidades, respetuosa de la privacidad,
transparente y democrática. Open Street Map (OSM) es un
repositorio de datos abiertos geoespaciales, construido con la
colaboración de millones de personas alrededor del mundo.
El ecosistema de herramientas alrededor de OSM ofrece la
posibilidad de hacer un viraje en la manera en la cual se ha
construido el conocimiento cartográfico. Sin embargo, aún es
necesario reducir la curva de aprendizaje que imponen las car-
acterı́sticas socio-técnicas de la herramienta para promover una
mayor participación en la generación de datos geoespaciales
colaborativos.
Este trabajo está enmarcado en un proyecto de extensión
universitaria en el que se pretende visibilizar ante instituciones
tomadoras de decisión a la comunidad de un asentamiento
informal1 , por medio de mapas libres. El problema que se
aborda en este artı́culo es la curva de aprendizaje que debe
allanar una persona que desea mejorar los datos geoespaciales
de Open Street Map utilizando como insumo datos recopilados
en el campo.
Existen varias alternativas y herramientas para llevar a cabo
un proceso de mapeo, decantarse por una u otra es una decisión
que depende de múltiples factores, la guı́a “Mapeo abierto
para los ODS“ es un buen punto de partida para tomar esa
decisión [8]. En este trabajo nos enfocamos en procesos en
los que la captura de datos ocurre en un momento previo a la
edición del mapa. Combinar la edición con la captura de datos
puede inducir a otras situaciones potencialmente problemáticas
que no se abordan en este artı́culo. En la segunda y tercera
sección del artı́culo presentamos una mirada a los aspectos
sociotécnicos que influyen en los procesos de captura de datos
y la edición del mapa. En la cuarta sección se presenta el Pre-
editor, un prototipo funcional licenciado como software libre
y diseñado para apoyar procesos colaborativos de mejora a
OSM. La última sección del artı́culo es de conclusiones y
trabajo futuro.
II. C APTURA DE DATOS GEOESPACIALES
Esta sección se enfoca en aspectos del proceso de captura de
datos utilizando la herramienta de software libre OSMTracker.
Estos incluyen: la relevancia de capturar datos geoespaciales
en el campo, accesibilidad de hardware y software, las lim-
itaciones de la herramienta OSMTracker y las formas de
sobrellevar esa limitaciones a través de ajustes metodológicos
y de implementación de mejoras al software.
El sitio web de OSM ofrece la posibilidad de mejorar
el mapa utilizando principalmente dos tipos de insumos:
imágenes satelitales y trazas producidas por voluntarios y
voluntarias. Las imágenes satelitales son visualmente muy
valiosas pero pobres para identificar estructuras en asentamien-
tos informales [9], donde el paisaje urbano es cambiante y a
la vez existe una alta densidad de estructuras. Siendo estas las
condiciones de mapeo que interesan para el proyecto en que
se encuadra el trabajo, nuestro enfoque de captura de datos
serán trazas recopiladas en el campo.
Una traza contiene tres tipos de elementos: puntos de refer-
encia, recorridos y rutas; conocidos de manera general por su
nombre en inglés, respectivamente: waypoints, tracks y routes.
La ubicación de los datos geoespaciales se obtiene utilizando
un receptor del Sistema de Posicionamiento Global (GPS).
Actualmente cualquier teléfono celular inteligente incluye un
receptor de GPS con un nivel de imprecisión manejable para
ser usado en un proceso de mapeo. OSMTracker2 es una
aplicación para Android, con licencia de software libre, que
destaca entre las más utilizadas para capturar información
geoespacial. Según datos de Google Play ha sido descargada
más de 10 mil veces3 . Esta aplicación no ofrece la posibilidad
1 Para cumplir con los requerimientos de revisión ciega se ha omitido el
nombre de la comunidad.
2 https://github.com/labexp/osmtracker-android
3 https://play.google.com/store/apps/details?id=net.osmtracker
de editar el mapa mientras se capturan datos, además consume
pocos recursos de hardware, no requiere de conectividad a
internet para funcionar y existe una comunidad de personas
desarrolladoras de software que le dan mantenimiento a la
aplicación.
Con OSMTracker una persona puede capturar trazas y
puntos de referencia. Una traza se captura de forma automática
desde el momento en que se inicia una grabación. Para guardar
un punto de referencia la persona usuaria debe presionar algún
botón de los que se presentan en la interfaz. El nombre del
botón, junto con las coordenadas donde fue presionado, serán
registrados por la aplicación.
Fig. 1. Visualización de tres archivos GPX sobre el mapa de Open Street
Map, se muestran los puntos de referencia (waypoints) con el icono de gota
de agua y con una lı́nea se visualizan los recorridos (track).
En la figura 1 se visualizan tres trazas capturadas con el
OSMTracker durante un taller de mapeo realizado con niñas y
niños del asentamiento informal4 . En esta imagen se visualiza
la utilidad de la información recopilada en campo y cómo
una adecuada metodologı́a puede corregir el problema de la
imprecisión del receptor de GPS de un teléfono celular. Con
relación al primer aspecto, la imagen muestra que el mapa
de la comunidad está desactualizado, pues las dimensiones de
la plaza no corresponden con los recorridos capturados en el
campo. Queda en evidencia que la información capturada en
el campo es vital para crear un mapa actualizado. En cuanto al
problema de precisión del GPS, la manera de sortear la defi-
ciencia es mediante un ajuste en la metodologı́a del mapeo. El
ajuste consiste en realizar varias capturas de datos en el mismo
sector que interesa, ası́ en la imagen se puede observar como
las tres trazas mostradas corresponden al mismo recorrido en
el campo y los puntos de interés capturados representan postes
de alumbrado público. Utilizando las ubicaciones de las tres
trazas es posible estimar la ubicación real de los elementos.
OSMTracker permite que se varı́e ligeramente la interfaz
(los botones y sus correspondientes ı́conos) para ajustarla a
las necesidades de mapeo. A estas variaciones de interfaz se
les llama disposiciones de botones personalizadas. La figura
4 Para cumplir con los requerimientos de revisión ciega se ha omitido el
nombre de la comunidad.
2(a) muestra una disposición de botones personalizada. Existe
un repositorio de Github5 desde donde se pueden descargar
disposiciones de botones personalizadas directamente desde el
OSMTracker, de esta forma se hace más sencillo compartirlas
entre varias personas colaboradoras con un mismo objetivo
de mapeo. La disposición de botones está definida por medio
de un archivo XML (Extensible Markup Language). Crear una
disposición de botones personalizada requiere de una persona
con destrezas técnicas [10].
Una vez que se capturan datos en el campo con el OSM-
Tracker, la aplicación genera un archivo de salida en formato
GPX (por sus siglas en inglés GPS eXchange Format). En
este archivo contiene los datos geoespaciales de puntos de
referencia y recorridos capturados (ver 2(b)). El formato
GPX es muy popular entre las herramientas de captura de
datos. Por sus caracterı́sticas estos archivos no son fácilmente
manipulables por personas sin destrezas técnicas, sin embargo
son legibles por una máquina y por lo tanto se pueden procesar
vı́a software.
Fig. 2. (a) A la izquierda se muestra la pantalla del OSMTracker con una
disposición de botones personalizada. (b) A la derecha un fragmento del
archivo GPX generado, por la misma aplicación, luego de haberse utilizando la
disposición de botones personalizada para capturar datos. En el GPX se puede
apreciar el encabezado, una sección de metadatos, seguida de dos puntos de
referencia. Los puntos de referencia corresponden a “Parada de Bus - Tipo 3”
y a “Taxis”, los dos incluyen ubicación (latitud y longitud), hora de la captura,
elevación sobre el nivel del mar y número de satélites visibles al momento
de capturar los datos.
Al terminar una grabación de datos geoespaciales con el
OSMTracker, se puede subir la traza producida al sitio de
OSM, descargarla a la computadora o compartirla desde la
aplicación vı́a correo electrónico, Bluetooth o en un mensaje
de chat. El archivo GPX producido será insumo para mejorar
el mapa.
III. E DICI ÓN DEL MAPA
La edición del mapa de OSM le plantea a una persona edi-
tora tres retos importantes. El primero es dominar el concepto
técnico de etiquetas. El segundo es buscar información en una
plataforma tipo Wiki, la cual incluye páginas que no siempre
estarán en su propio idioma y además los elementos descritos
pueden estar fuera de contexto sociocultural. El tercer reto es
tomar una decisión sobre el uso que debe hacer de los datos
capturados usando el GPS de un teléfono celular y las etiquetas
5 https://github.com/labexp/osmtracker-android-layouts
que debe utilizar, pues el mapa no siempre estará vacı́o y por
tanto no siempre se debe ingresar la información capturada.
En esta sección nos referiremos a estos tres retos.
Se explicará el concepto de etiqueta con un ejemplo. Una
persona que desea añadir al mapa de OSM un establecimiento
de atención médica de primera lı́nea puede hacerlo combi-
nando la posición geoespacial donde se ubica el local y las
caracterı́sticas del establecimiento. Entre las caracterı́sticas
sobresalientes podemos mencionar: el horario de atención
(diurno, vespertino o nocturno), el tipo de servicios que
brinda (nutrición, farmacia o enfermerı́a) y el nombre del
establecimiento (por ejemplo: Clı́nica La Esperanza).
Si prestamos atención a las caracterı́sticas del ejemplo, estas
tienen dos partes: un atributo y un detalle especı́fico sobre
ese atributo. La segunda de estas dos partes, el detalle, fue
mostrado en el ejemplo anterior encerrado entre paréntesis.
En OSM a estas dos partes se les conoce como etiquetas,
de manera especı́fica al atributo se le conoce como llave y al
detalle valor. Técnicamente las caracterı́sticas que describen un
elemento se representan como una lista de llaves y valores. Al
editar el mapa de OSM una persona debe saber qué etiquetas
utilizar para añadir o mejorar el mapa. A la combinación de
etiquetas que se utiliza para mapear un elemento se le conoce
como esquema de mapeo.
El espacio para conocer sobre qué etiquetas utilizar para
describir ciertos elementos es la Wiki 6 del proyecto OSM.
Este es un espacio virtual en donde la comunidad de ma-
peadoras y mapeadores, documenta los consensos sobre cómo
mapear. A pesar de ser un espacio abierto y libre a la
participación de quien quiera aportar, aspectos como el id-
ioma de la documentación, la cual está mayoritariamente en
inglés, y el contexto sociocultural en el cual se describen las
caracterı́sticas de los elementos pueden dificultar los aportes
de voluntarias y voluntarios.
OSM es un proyecto que nace en el contexto del norte
global, especı́ficamente en el Reino Unido en el año 2004.
Con o sin intención, en OSM hay una perspectiva eurocéntrica
que se refleja en el etiquetado que se utiliza o se sugiere
para mapear, también hay implı́cita una asignación de roles de
quienes definen y quienes solo usan etiquetas. Esta situación
puede conducir a una invisibilización de otras realidades sus-
ceptibles de ser representadas en el mapa. Esta particularidad
se puede resaltar como un rasgo de colonialismo digital, un
efecto de nuestro sistema-mundo, como dice Reyes [11], que
“... jerarquiza las diferentes regiones del mundo, mediante la
asignación de funciones dentro del mismo sistema. Dentro de
esas asignaciones Europa y, posteriormente, Estados Unidos se
arrogan la autoridad para hacer de su conocimiento el único
valedero”.
Ası́ pues, una persona de la región latinoamericana se
topa con información sobre cómo mejorar el mapa de OSM
algunas veces en español, francés o portugués, pero la mayorı́a
de las ocasiones en inglés. Considerando que, en la región
latinoamericana las personas de más de la mitad de los
6 https://wiki.openstreetmap.org/wiki/Main Page
paı́ses tienen un nivel bajo o muy bajo de inglés [12], esta
situación crea una barrera, que se amplı́a al intentar mapear
elementos propios del contexto sociocultural. Para sortear estas
limitaciones se suelen crear páginas locales (asociadas a algún
territorio como un paı́s o ciudad) donde se documentan las
combinaciones de etiquetas usadas para incluir en el mapa
elementos propios del contexto local. La Figura 3 muestra
un fragmento de la Wiki ”Bolivia/Cómo mapear un” donde
se documenta cómo debe editarse un elemento propio de la
cultura andina. Crear páginas Wiki locales, con una comunidad
interesada en mejorar el mapa de su territorio, es un ejercicio
de alfabetización digital crı́tica y de apropiación tecnológica.
Fig. 3. Fragmento de la Wiki de OSM titulada ”Bolivia ¿Cómo mapear un?”
donde se incluye el esquema de mapeo para una Apacheta. Las Apachetas son
un monumento indı́gena de valor sagrado. El esquema de mapeo sugiere el uso
de 4 etiquetas, donde destaca ”side type=cairn” la cual no está documentada
en ninguna otra página de la Wiki.
El tercer reto que se enfrenta al editar el mapa es tomar
una decisión sobre la ubicación en la que se colocará el
elemento en OSM, para lo cual hay dos posibilidades7 . En la
primera el elemento no existe en OSM, con lo cual la solución
al problema consiste en añadirlo al mapa en la ubicación
capturada y caracterizarlo utilizando las etiquetas previamente
definidas.
La segunda posibilidad es que exista un elemento similar
en el mapa, pero no está exactamente en la misma ubicación
capturada por medio del GPS. En este segundo caso se requiere
que la persona que edita el mapa decida si el elemento en el
mapa es el mismo que se capturó (que por siguiente requiere
que se mejore la ubicación) o si se trata de otro elemento
distinto al ya incluido en el mapa (lo cual se resolverı́a como
el primer caso). Si el elemento ya existe en el mapa de OSM
entonces la persona que edita debe verificar si las etiquetas
con las cuales está caracterizado coinciden con las definidas
en el esquema de mapeo, en caso de alguna diferencia debe
mejorar el etiquetado.
IV. P RE - EDITOR
En las secciones anteriores abordamos aspectos socio
técnicos que inclinan la curva de aprendizaje a quien quiere
7 Podrı́a existir una tercera alternativa, que serı́a que las ubicación del
elemento en OSM y la capturada vı́a GPS coincidan pero es poco probable
una exactitud total
colaborar en mejorar el mapa de OSM. A saber, la Wiki y los
esquemas de etiquetado; la manera en que se organizan los
archivos producidos al mapear (GPX, XML) y la usabilidad
de la herramienta OSMTracker (la forma de grabar trazas,
exportarlas y compartirlas); y cómo toda esta información y
datos son combinados por las personas que desean mejorar
el mapa. Para nivelar la curva de aprendizaje, en esta sección
se presenta un prototipo funcional desarrollado como software
libre, llamado Pre-editor.
El Pre-editor ofrece a la persona que quiere editar el mapa
apoyo para determinar qué acción debe llevar a cabo al editar
el mapa de OSM, ya sea: añadir un elemento en una ubicación
y con una lista etiquetas, mejorar las etiquetas actuales de un
elemento en el mapa (porque tiene demás o porque carece
de las etiquetas acordadas por la comunidad) o no tomar
acción alguna cuando un elemento está correctamente ubicado
y etiquetado. De esta forma la herramienta se constituye como
un apoyo previo al proceso de editar el mapa.
Fig. 4. Representación de la interacción con el Pre-editor para facilitar la
mejora del mapa de Open Street Map.
Desde una perspectiva de implementación, el Pre-editor
es una herramienta de software libre disponible a través de
un repositorio de Github8 . Está programada en el lenguaje
Python 3, lo que permite que sea ejecutada en múltiples
sistemas operativos. La interacción con las personas usuarias
ocurre por medio de la terminal del sistema operativo. Para
favorecer la colaboración con código, se decidió documentar
de manera interna y externa en Español. De esta forma se
pretende incentivar a personas que inician en la programación
a contribuir y familiarizarse con el Software Libre.
Para ofrecer la salida la herramienta requiere de tres en-
tradas: un esquema de mapeo, una traza generada con el
8 Para cumplir con los requerimientos de revisión ciega se ha omitido el
enlace al respositorio
OSMTracker utilizando una disposición de botones person-
alizada y datos geoespaciales de elementos existentes en el
mapa de OSM. La figura 4 sintetiza el funcionamiento del Pre-
editor. A continuación se explicarán estas entradas, ası́ como
el funcionamiento del Pre-editor y las salidas que ofrece.
Un esquema de mapeo es la combinación de etiquetas que
una comunidad acuerda utilizar para caracterizar una serie de
elementos que son de interés para el proceso de mapeo. Esta
definición, requiere que la comunidad desarrolle un proceso
participativo y de reflexión crı́tica sobre la manera en la
cual cada comunidad experimenta su realidad. Como resultado
de este proceso se debe producir una lista de elementos
con una breve caracterización que permita identificarlos y la
propuesta de etiquetas a utilizar al editar el mapa. Idealmente
es muy conveniente para las comunidades añadir imágenes
que permitan identificar los elementos en su contexto. Una
forma de socializar esas reflexiones es creando una página
Wiki propia donde se detallen las decisiones.
Fig. 5. Fragmento de la Wiki de OSM de la Comunidad de Alajuela, Costa
Rica en la que se explica cómo mapear paradas de bus. La primera columna de
la tabla muestra el ı́cono que presentará el botón de la disposición de botones
personalizada del OSMTracker, la segunda y tercera columna muestran una
foto y descripción del elemento, la cuarta columna indica el texto utilizado
para nombrar el punto de referencia en el archivo GPX y la última columna
el esquema de mapeo.
Aprovechando que la herramienta OSMTracker permite
modificar su interfaz para adaptarla a las necesidades de mapeo
especı́ficas, se debe construir una disposición de botones
personalizada que coincida con el esquema de mapeo definido
por la comunidad. En la figura 5 se muestra una página Wiki
local donde se documenta el esquema de mapeo y se presentan
los ı́conos utilizados en la disposición de botones creada para
mapear paradas de bus.
Para los efectos del uso del Pre-editor, el esquema de
mapeo se ingresará a la herramienta en un archivo JSON
(archivo notación de objeto de JavaScript). La construcción
de este archivo requiere el apoyo de una persona con de-
strezas técnicas. La información capturada con el OSMTracker
se ingresará por medio del archivo GPX generado con la
herramienta. Los datos del mapa de OSM serán descargados
automáticamente por el Pre-editor.
El funcionamiento del Pre-editor consiste en leer el archivo
GPX para identificar cada punto de referencia e indicarle a
la persona que ejecuta el programa qué acción debe realizar
al editar el mapa. El prototipo funcional del Pre-editor ha
sido validado con datos de campo, los resultados obtenidos
son satisfactorios para el equipo investigador. Las condiciones
sanitarias provocadas por la pandemia de COVID-19 han
dificultado una validación de la herramienta en condiciones
de mapeo (captura y edición) normales. Como ejemplo de los
resultados obtenidos se presentan las salidas ofrecidas por la
herramienta en cada uno de los casos de uso para los cuales
fue diseñada.
$ python3 pre_editor.py --gpx trazas/prueba_info.gpx
--esquema esquemas/bekuo.json
Informe
========
Analizando la ruta trazas/prueba_info.gpx con el
esquema de mapeo esquemas/bekuo.json
Analizando el waypoint con nombre ’Taxis’ ubicado en
(10.027898339757584,-84.21553829520037).
[INFO] El nodo https://osm.org/node/1361118873 esta
correctamente mapeado.
Listing 1. Ejecución del Pre-editor para el caso informativo.
En términos generales una vez que se invoca el comando
para ejecutar el Pre-editor, el software muestra información
sobre las entradas que se están utilizando para el análisis y
seguidamente la sugerencia de acción. En el fragmento de
código 1 se muestra la ejecución completa del programa,
en este caso la salida indica que ya existe un elemento en
OSM correctamente mapeado. En los siguientes fragmentos de
código no se presentará la ejecución completa del Pre-editor
sino solo la parte sustancial de la salida.
Analizando el waypoint con nombre ’Parada de Bus -
Tipo 3’ ubicado en
(10.032290950935142,-84.21384352327117).
[REVISAR] El nodo https://osm.org/node/3986175262
tiene mas etiquetas que las indicadas en el
esquema de mapeo esquemas/bekuo.json
Las etiquetas demas son:
"name": "UNADECA",
"covered": "yes",
"highway": "bus_stop"
Analizando el waypoint con nombre ’Semaforo audible’
ubicado en
(9.33366919787807,-82.88856624669424).
[EDITAR] El nodo https://osm.org/node/321371238" "
debe ser mejorado con las etiquetas:
"traffic_signals:sound": "walk;yes"
Listing 2. Salidas obtenida al ejecutar el Pre-editor cuando existen datos en
OSM pero las etiquetas deben ser mejoradas.
En el fragmento de código 2 se observa la salida esperada
cuando la persona que mapea debe mejorar el etiquetado de
un objeto presente en OSM. Se determina que el objeto de
OSM debe ser mejorado porque al menos una de sus etiquetas
coincide con las del esquema de mapeo. Esta situación puede
tener dos opciones de mejora, cuando hay más etiquetas en
el objeto de OSM de las que se consideraron en el esquema
de mapeo (ver encabezado “REVISAR” en el fragmento de
código) y la segunda cuando faltan etiquetas en el objeto de
OSM (ver encabezado “EDITAR”).

Analizando el waypoint con nombre ’Semaforo audible’
ubicado en
(10.029784051128404,-84.21501124721962).
[CREAR] Se debe agregar un nuevo nodo en
(10.029784051128404, -84.21501124721962) con las
etiquetas:
"crossing": "traffic_signals",
"traffic_signals:sound": "walk;yes"
Listing 3. Ejecucion del Pre-editor para el caso crear
Finalmente, en el fragmento de código 3 se indica que la
acción requerida es añadir el punto de referencia al mapa de
OSM con las etiquetas del esquema de mapeo.
V. C ONCLUSIONES Y TRABAJO FUTURO
Al efectuar un proceso de mapeo participativo es conve-
niente hacer la captura de datos y la edición del mapa en dos
pasos separados. Esto porque durante la edición de los datos
se debe verificar las siguientes situaciones: si el dato que se
recolectó es nuevo en el mapa, si ya existe y debe ser mejorado
(en sus etiquetas o sus coordenadas) o si es un dato que no
se debe incluir en el mapa porque ya existe.
Con el pre-editor hacemos un aporte al proceso de mapeo,
por medio de una definición previa de las etiquetas que
caracterizan a cada elemento que se quiera mapear, asociando
estas a botones de una disposición personalizada y generando
una aplicación que ayude a una persona usuaria a comprender
qué acción debe realizar con los datos que capturó en el campo
usando la herramienta OSMTracker.
Dada la curva de aprendizaje para mejorar el mapa de OSM,
es muy conveniente que una persona con experiencia en OSM
acompañe a la comunidad en la definición de un esquema
de mapeo. Este acompañamiento debe incluir la búsqueda
de información a través de la Wiki. El espacio de trabajo
en la creación del esquema de mapeo abre la posibilidad
de establecer procesos de alfabetización digital crı́tica que
podrı́an ser facilitados por la persona con experiencia en
mapeo. Algunas preguntas generadoras que pueden guiar este
espacio son ¿por qué usamos OSM y no un mapa privativo
como el de Google, Bing o Apple?, ¿Por qué utilizamos
una etiqueta y no otra? o ¿Qué caracterı́sticas diferencian un
elemento en un contexto sociocultural lationamercano de uno
europeo?.
Considerando que en la región latinoamericana mantiene un
nivel básico de destrezas en tecnologı́as de información y co-
municación [13], se considera necesario que una persona con
destrezas técnicas apoye en la construcción de la disposición
de botones (archivo XML), la creación del json y la ejecución
del Pre-editor.
Como trabajo futuro se debe mejorar la interacción entre
el OSMTracker, el Pre-editor y las personas. Una opción es
constituir un Bot de mensajerı́a instantánea (Telegram o What-
sapp) que reciba trazas compartidas desde el OSMTracker
y que responda con la sugerencia de cómo mapear. Otra
alternativa es mejorar la interfaz de usuario del Pre-Editor
por medio de una aplicación web. Finalmente la funcionalidad
del Pre-Editor podrı́a ampliarse para recibir como entrada
múltiples archivos GPX (no sólo uno) y que analice recorridos,
además de puntos de referencia.
R EFERENCES
[1] H. L. Cukierman, C. Teixeira, and R. Prikladnicki, “Um olhar so-
ciotécnico sobre a engenharia de software,” Revista de Informática
Teórica e Aplicada, vol. 14, no. 2, pp. 199–219, 2007.
[2] T. Davies, S. Walker, M. Rubinstein, and F. Perini, Eds., The State of
Open Data: Histories and Horizons. Cape Town and Ottawa: African
Minds and International Development Research Centre, 2019.
[3] R. Sieber, Open data and geospatial. Cape Town and Ottawa: African
Minds and International Development Research Centre, 2019, pp. 137–
150.
[4] C. E. para América Latina y el Caribe (CEPAL), “Segundo informe
anual sobre el progreso y los desafı́os regionales de la agenda 2030
para el desarrollo sostenible en américa latina y el caribe,” https://priv.
sh/FHV32QI, CEPAL, Santiago, Chile, Tech. Rep., 2018.
[5] J. M. Diez Tetamanti, Cartografı́a social: teorı́a y método. Estrategias
para una eficaz transformación comunitaria. Buenos Aires, Argentina:
Biblos, 2018.
[6] P. Ricaurte, “Data epistemologies, the coloniality of power, and
resistance,” Television & New Media, vol. 20, no. 4, pp. 350–365,
2019. [Online]. Available: https://doi.org/10.1177/1527476419831640
[7] P. Feitosa, A. J. Silva de Lima, and H. Cukierman, “Digital exclusion
of favelas from the solar map of rio de janeiro,” IEEE Technology and
Society Magazine, vol. 39, no. 1, pp. 30–85, 2020.
[8] Open mapping for the sdgs. Humanitarian OpenStreetMap Project.
Accessed: 2020-03-25. [Online]. Available: https://sdgs.hotosm.org/
[9] G. Yeboah, J. Porto de Albuquerque, R. Troilo, G. Tregonning,
S. Perera, S. A. K. S. Ahmed, M. Ajisola, O. Alam, N. Aujla, S. I.
Azam, K. Azeem, P. Bakibinga, Y.-F. Chen, N. N. Choudhury, P. J.
Diggle, O. Fayehun, P. Gill, F. Griffiths, B. Harris, R. Iqbal, C. Kabaria,
A. K. Ziraba, A. Z. Khan, P. Kibe, L. Kisia, C. Kyobutungi, R. J. Lilford,
J. J. Madan, N. Mbaya, B. Mberu, S. F. Mohamed, H. Muir, A. Nazish,
A. Njeri, O. Odubanjo, A. Omigbodun, M. E. Osuh, E. Owoaje,
O. Oyebode, V. Pitidis, O. Rahman, N. Rizvi, J. Sartori, S. Smith,
O. J. Taiwo, P. Ulbrich, O. A. Uthman, S. I. Watson, R. Wilson, and
R. Yusuf, “Analysis of openstreetmap data quality at different stages of
a participatory mapping process: Evidence from slums in africa and
asia,” ISPRS International Journal of Geo-Information, vol. 10, no. 4,
2021. [Online]. Available: https://www.mdpi.com/2220-9964/10/4/265
[10] B. O. Sánchez, E. Alfaro Brenes, I. M. López, A. Amador Ávila, D. M.
Molina, and J. Gutiérrez Alfaro, “Promoting community participation
in thematic mapping processes by simplifying the free software tool
osmtracker for android,” in 2019 IV Jornadas Costarricenses de Inves-
tigación en Computación e Informática (JoCICI), 2019, pp. 1–6.
[11] R. Reys Rivas, “Colonialidad y tecnociencia,” Técnica, ciencia y tec-
nologı́a. Modelos de intervención.(Segunda Edición). Cartago: Editorial
Tecnológica de Costa Rica, 2012.
[12] (2020) Índice del dominio del inglés de ef. Education First. [Online].
Available: https://www.ef.com/
[13] (2020) Measuring digital development: Facts and figures. International
Telecommunication Union. [Online]. Available: https://www.itu.int/en/
ITU-D/Statistics/Documents/facts/FactsFigures2020.pdf