Este artículo hace parte de una serie de artículos relacionados con notas:

• Las notas de OpenStreetMap.
• Manipulación de notas.
• Análisis de notas.
• Tipos de notas.
• Finalización proyecto de cerrado de notas en Colombia.

Recomendaciones de resolución de notas

Idioma

Normalmente, las notas que se resuelven son del área o país donde uno vive. Por ejemplo, en mi caso es en Colombia donde hablamos español. Pero no todos los que crean notas aquí hablan español, ya que puede haber turistas de otros países que aportan al mapa. Si bien yo domino el francés y el inglés, y por lo tanto puedo entender las notas escritas en esos idiomas. Aunque también me he encontrado con notas creadas en Colombia escritas en alemán, checo, árabe e inclusive turco. Como son otros idiomas que no manejo, aprovecho de la utilidad de Google Translate con la opción de identificar idioma, y me ha ayudado a resolver muchas notas.

En estos casos de notas en otros idiomas, preferiblemente las respondo en inglés si no domino el idioma en que se crearon. Si no dominara el inglés, respondería en español, pero haría el esfuerzo de traducir la nota de resolución para comunicarme con quien la creó, indicando cómo fue que la resolví, y en ese caso volvería a usar Google Translate.

En el caso de las notas anónimas, puede tomar un poco menos importancia de responder en el mismo idioma de creación; sin embargo, hay varias utilidades que las crean en otro idioma, como las de Maps.me cuya plantilla es en inglés. Aunque, puede que las personas que las crearon estén pendientes de la resolución.

Plantillas de respuestas

Dependiendo de las respuestas que quiera dar, se puede crear una plantilla para copiar/pegar como parte de la respuesta. Sin embargo, se recomienda usar una plantilla para el cuerpo de nota, pero incluyendo algo puntual sin plantilla que explique la resolución.

En el caso de la resolución de notas de Colombia, tenemos una plantilla para poner como comentario al resolver las notas. Además, en ocasiones ponemos un texto puntual relativo a la nota; por ejemplo, nombre corregido, dirección agregada, lugar borrado.

Procesar toda la nota

Algunas notas pueden tener muchos detalles, y cuando estemos resolviendo las notas podemos omitir algunos detalles. Se recomienda analizar bien la nota antes de cerrarla, y analizarla bien para transcribir todos los posibles datos al mapa.

En mi caso, se dio que algunas notas tenían redes sociales de establecimientos, y esto nunca lo había hecho, por lo que fue una oportunidad para aprender cómo agregarlas. Varias notas pueden tener elementos de este tipo, que puede que no sepas mapear: Redes sociales, presencia en Internet, horario, dirección, tipos de pago. En todo caso, hay que consultar el Wiki de OpenStreetMap que es la biblia del mapa, y muy seguramente encontrarás la solución a tu duda.

Commit por nota

Cuando se hacen cambios en el mapa, se recomienda hacerlo de manera independiente por cada nota. Esto quiere decir, que se resuelve una nota, haciendo los cambios en el mapa, y guardando los cambios.

No se recomienda resolver muchas notas como parte del mismo conjunto de cambios, para que se pueda asociar una nota con un número de conjunto de cambios. De manera similar, puede que se hagan otros cambios en el mapa además de la nota, y puede ser confuso para analizar el commit.

Esto también es bueno en caso de que toque devolver el cambio, o sea deshacerlo, y es mejor que el cambio consista en una actividad atómica (algo concreto, indivisible).

Número de nota como parte del commit

De manera similar, como parte de la descripción del conjunto de cambios, se recomienda incluir el número de nota. Con esto, cuando se analicen los cambios en un área, se puede entender que el origen de los cambios fue por una nota.

Esto toma importancia cuando hay cambios que destruyeron algo en el mapa, y se tiende acusar al contribuidor, siendo que este realmente estaba haciendo lo que la nota decía.

Hashtag

Tanto en el mensaje de resolución de la nota, como en el commit del cambio, se debe usar un hashtag que identifique el proyecto de resolución de notas.

En Colombia, usamos #ONL que se refiere a Open Notes Latam. Esto ha servido para identificar nuestros esfuerzos de cerrar notas.

Ver el historial del feature

Cuando piden cambiar algo, y se duda si es apropiado, o es un vandalismo, se puede revisar el historial del objeto: https://osmlab.github.io/osm-deep-history/

Por ejemplo, si hay una nota muy vieja de agregar un establecimiento, y ese establecimiento ya se borró, entonces no vale la pena agregarlo, pero se puede saber si existió gracias a la historia de los features alrededor de la nota.

JOSM y sus plugins

No hay nada malo en resolver notas desde iD u otro editor, pero una vez estás con JOSM, puedes encontrar mayor facilidad en hacerlo. Además que puedes trabajar más rápido. Por ejemplo puedes usar esto:

• Plugin Continuous Download – como una nota puede indicar trazar una vía, entonces con solo moverte va a descargar los datos del mapa aledaños.
• Bajar todas las notas de un área – Si vas a resolver las notas de tu ciudad, entonces bajas todas las notas desde JOSM (con botón descarga o con panel de notas) y con el plugin anterior, al hacer click en una nota te descargará los datos. Esto es muy práctico para resolver rápidamente todas las notas de tu ciudad.

Trabajo en grupo coordinado

Si varias personas trabajan en el mismo conjunto de notas, se generará un error si alguien ya la cerró, y otra persona está intentando volver a cerrarla. Por eso se recomienda dividirse las notas por áreas (ciudades, barrios, estados, departamentos), rangos de números de id, por fecha (más viejas, más nuevas, por año), para evitar colisiones.

Números de nota

Cuando se trabaja con notas, a veces es bueno saber qué tan viejas, y esto se puede identificar por el id de nota. Aquí muestro un rango de valores del id de nota, importante a tener en cuenta:

• 1 000 000 – Mayo 2017
• 2 000 000 – Noviembre 2019
• 3 000 000 – Enero 2022

Notificación y descripción en el wiki

Como la resolución de notas es una actividad coordinada, esta se debe describir en el Wiki y reportar a las comunidades que impacte, ya sea por la lista de correo y/o por el canal de Telegram. Lo mejor es que toda la comunidad implicada esté al tanto del trabajo.

Para el caso de Colombia, se hizo un descripción del proyecto inicial: osm.wiki/ES:Colombia/Resoluci%C3%B3n_de_notas y después se agregó a la lista de tareas coordinadas: osm.wiki/Organised_Editing/Activities/Notes_resolution_in_Colombia

Notas de otros proyectos

Algunos proyectos que se realizan en OpenStreetMap tienen como resultado dejar notas en el mapa. Algunas veces estas notas pueden no ser claras para cualquier persona, sino para el interior del proyecto. En estos casos se puede contactar a la persona que creó la nota y buscar que las describa mejor.

Por ejemplo, en Colombia el grupo de Microsoft está mapeando vías y Erick Leal de Oliveira ha creado miles de notas en el país. Después de contactarlo, la comunidad comenzó a apoyarlo en la resolución. Por esto, es importante crear notas con un hashtag, y también cerrrarlas y hacer commit con un hashtag.

Recomendaciones para creación de notas

Cuando se crean notas, se debe tener en cuenta que:

• Toda nota se debe crear con el objetivo de hacer un cambio en el mapa.
• Preferiblemente, las notas son observaciones en terreno, donde la información del mapa no concuerda con la realidad.
• Si la nota no es tomada en terreno, se debe describir lo mejor posible. Por ejemplo, “hace parte de un proyecto X”, “se usó una técnica particular par identificar en error en el mapa”.
• La nota la resolverá una persona que no está en terreno, que no conoce la zona, y está desde un computador con una vieja foto satelital, con otro par de fuentes (Strava Heatmap, Mapillary, datos abiertos). Por lo tanto, toda la descripción del cambio se debe poder interpretar con solo la información contenida en la nota.

Las notas de StreetComplete con fotos

StreetComplete es una aplicación genial que permite agregar datos al mapa directamente, y en otros casos crear notas sobre algunos casos puntuales. Inclusive, permite que las notas integren fotos para explicar mejor la situación. Sin embargo, estas fotos quedan en un portal externo a OpenStreetMap y no hay una clara explicación de su uso, licencia, tiempo de publicación, etc. Por lo que no se recomienda mucho su uso, ya que es muy restringido.

Además, cuando se están resolviendo dichas notas desde JOSM, la URL de las fotos tiene un carácter llamado Zero Width Character (https://unicode-table.com/en/200B/) que no es visible pero existe. Este carácter cuando se pega en la URL de un explorador se convierte a su valor hexadecimal y por lo tanto no se puede acceder a la foto.

Por lo anterior, en vez de usar este mecanismo para fotos, se debe preferir un mecanismo diseñado para geofotos, como lo son Mapillary o KartaView (OpenStreetCam).

Otros artículos de notas

Estos son unos artículos que encontré que hablan de notas desde otras perspectivas, y es interesante leerlos para mejor entender la dinámica de las notas.

• Richard Fairhurst. OpenStreetMap opens up to more contributors with easy ‘add a note’ feature. OpenStreetMap blog. 2013. https://blog.openstreetmap.org/2013/04/29/openstreetmap-opens-up-to-more-contributors-with-easy-add-a-note-feature/

• Jinal Foflia (@fofliajinal). Interacting with the local mapping community using OpenStreetMap Notes. Mapbox. 2016. https://blog.mapbox.com/interacting-with-the-local-mapping-community-using-openstreetmap-notes-1088686c88d5

• Un artículo introductorio sobre qué son las notas, cómo se crean y su propósito.

• OpenStreetMap Notes in MAPS.ME. Harrywook.co.uk. 2017. http://harrywood.co.uk/blog/2017/03/12/notes-in-maps-me/

• Joost Schouppe. OpenStreetMap Notes: some interesting stats. OpenStreetMap diary. 2018. osm.org/user/joost%20schouppe/diary/43057

• Toshikazu Seto, Hiroshi Kanasugi and Yuichiro Nishimura. Quality Verification of Volunteered Geographic Information Using OSM Notes Data in a Global Context. Mdpi.com. 2020. https://www.mdpi.com/2220-9964/9/6/372