En Latinoamérica, el último sábado de abril es una fecha importante, porque se celebra el FLISoL. Este es un evento que comenzó hace 20 años, y los que lo apoyamos nos hace muy felices cumplir 2 décadas en esto. Pero ¿qué es realmente el FLISoL?

Comenzó como un evento de instalación de alguna distribución Linux en los computadores. Por eso sus siglas quieren decir: Festival Latinoamericano de Instalación de Software Libre, pero con el pasar de los años ha crecido de muchas formas.

Primero, ya no es solo instalaciones, también hay charlas y talleres. Las charlas son de todo lo relativo al mundo libre, ya sea algún programa de código abierto, una plataforma de datos abiertos, o comunidad libre. Por eso, como parte de los requerimientos para inscribir una charla, en ocasiones te piden qué licencia tiene de lo que vas a hablar. Los talleres son para practicar y aplicar lo que aprendes. Por ejemplo, a usar tu nuevo Linux instalado, usar alguna herramienta como Scratch, o crear algún artículo en Wikipedia.

Segundo, ha crecido también en ciudades y países. Comenzó como algo puntual en Bogotá, pero ahora está presente en muchas ciudades de Colombia, y ha llegado a más de 10 países, inclusive en España. Por lo tanto, es un evento que atrae a muchas personas que apoyan este movimiento libre, o que quieren comenzar a descubrir este mundo.

Del lado de OpenStreetMap tenemos una gran oportunidad ahí. Podemos dar charlas de experiencias con OpenStreetMap (casos en los que lo hemos usado sus datos, contribuido, proyectos, etc.) o talleres para invitarlos a usar los visores o lo que más nos interesa, que comiencen a contribuir y mejorar el mapa.

En Colombia, el año pasado hicimos unas guías que todos pueden usar, para que hacer su propio taller sea fácil. Las guías quedaron en TeachOSM (son las únicas en español, en 4 capítulos). Y consisten en darle la bienvenida a los usuarios para que comiencen con algo fácil, respondiendo preguntas en StreetComplete.

Si quieres puedes dar una charla más avanzada, o un taller de mapeo en iD o JOSM. El límite lo pones tú, pero lo que sí quiero es que desde LatAm nos apoyemos en estas conferencias, ya que nos dan la bienvenida a nuestro proyecto y podemos dárselo a conocer a muchas más personas.

Asiste al FLISoL, postula una charla o taller en tu área. Más información en: FLISoL

Después de haber participado en el evento de Wikimedia Colombia, me interesé aún más en apoyar la integración de estos proyectos, sabiendo que ya hay varias formas, pero no son muy conocidas. Por eso, aquí voy a listar las cosas que conozco, y actualizaré la entrada cuando encuentre más.

Etiquetas en OpenStreetMap

• Etiqueta wikipedia - Key:wikipedia
  • Aquí se puede ver que en muchos casos no se debe usar solo esa etiqueta, sino acompañada de:
    • artist:wikipedia
    • architect:wikipedia
    • brand:wikipedia
    • subject:wikipedia - Probablemente la más común.
    • operator:wikipedia
    • network:wikipedia
    • species:wikipedia
    • taxon:wikipedia
    • name:etymology:wikipedia
• Etiqueta wikidata - Key:wikidata
  • Para asociar ese concepto de wikidata en OSM.
  • Tiene muchas etiquetas secundarias:
    • architect:wikidata
    • brand:wikidata
    • buried:wikidata
    • flag:wikidata
    • genus:wikidata
    • manufacturer:wikidata
    • model:wikidata
    • name:etymology:wikidata
    • network:wikidata
    • operator:wikidata
    • owner:wikidata
    • royal_cypher:wikidata
    • species:wikidata
    • subject:wikidata
    • taxon:wikidata

Atributos de Wikidata

• coordinate location - P625
  • Al abrir el wikidata, se verá un mapa de OpenStreetMap con la ubicación.
• headquarters location - P159
  • Muestra el lugar de la casa matriz en un mapa.
• OpenStreetMap relation Id - P402
  • Es el identificador de OSM de una relación, sin embargo no es muy recomendada, ya que puede cambiar de Id.
  • Caso similar para los nodos P11693 y ways P402

Herramientas de edición

• Validador de etiquetas de wikipedia o wikidata en OSM - OSM-wikipedia-tag-validator-reports
  • No es un mecanismo automático, pero Mateusz muy amablemente ejecuta el proceso de actualización.
  • Es una excelente herramienta para comenzar a arreglar las entradas de wikimedia existentes. Además permite aprender cómo se deben usar.
• “Relacionador” de elementos de OSM con artículos de wikimedia - osm.wikidata.link
  • Hace un análisis de una zona, y compara en ambos lados los objetos. Permite modificar los elementos de OSM para integrar los artículos de Wikimedia. Excelente para agregar datos rápidamente.
• Plugin de JOSM de wikipedia - JOSM/Plugin/Wikipedia
• JOSM Plugin para agregar etiquetas - JOSM/RemoteControl/Add-tags
• OSMose - osmose.openstreetmap.fr
  • Herramienta para mejorar la calidad de los elementos de Wikimedia y asegurar que están bien.
• Desafíos MapRoulette - fix broken Wikipedia tags

Visores

• Página principal de OSM - osm.org
  • Hacer zoom y escoger “Consultar elementos” para ver las etiquetas de Wikipedia y Wikidata.
  • Ejemplo en youtube
• OsmAnd - osmand.net
  • Aplicación para móviles que muestra la URL del artículo de wikipedia.
• OrganicMaps - OrganicMaps.app
• Aplicación para Android que muestra parte del contenido del artículo de wikipedia.
• Maps.me - Maps.me
  • Aplicación para móviles que muestra la URL del artículo de wikipedia, y un extracto del artículo.
• Locus - locusmaps.app
  • Aplicación para móviles que muestra parte del artículo, a partir del Wikidata, en el idioma de la interfaz.
• Visualizador de elementos geolocalizados en wikimedia wikishootme - wikishootme.toolforge.org
• Visualizador de wiwosm - wiwosm.toolforge.org/osm-on-ol
  • Es necesario modificar la URL para cambiar el idioma.
• Artículos de wikipedia - osmwd.dsantini.it
• Artículos de wikipedia wikidata - map.osm.wikidata.link
• Artículos de Wikipedia wdlocator wdlocator.toolforge.org
• Visualizador de artículos de wikipedia con su ubicación sobre un mapa (funciona mejor en Polonia) - openstreetmap.pl/wp
• Visualizador de artículos de wikipedia (enfocado a Eslovaquia) - www.freemap.sk

Documentation

• Welcome_to_Wikipedia_users
• Collaboration_with_Wikipedia
• Collaboration_with_Wikivoyage
• WIWOSM

Para terminar, es necesario recordar que la licencia de Wikimedia es CC-By, y la de OpenStreetMap es ODbL. Las dos licencias no son completamente compatibles. CC-By requiere una mención “razonable” de la fuente de datos, lo cual puede ser problemático para un mapa. Además, CC-By no permite distribución de datos en dispositivos con DRM. Estos dos elementos lo vuelven incompatible con ODbL.

Me dió por investigar cómo usar los datos de Google de los edificios, y usarlos en OSM, ya que tienen licencia ODbL (Al mismo tiempo de CC-BY).

Los datos están disponibles en https://sites.research.google/open-buildings/, divididas por zonas en el mapa.

Las zonas están en el hemisferio sur, dónde más falta mapeo (USA y Europa tienen muchos datos en OSM). Es una especia de cuadrícula sobre los continentes y cada cuadrícula puede variar entre 1 GB o 20 MB aproximadamente.

Lo que se descarga en un archivo tar.gz, por lo que es necesario tener un programa para extraer GNU Zip, el cual diferente al clásico ZIP.

Una vez extraído se obtiene un archivo separado por comas CSV.

La primera línea del archivo tiene los nombres de las columnas, lo que será necesario quitar para procesarlo.

La mejor forma para usarlo es por medio de una base de datos Postgresql con PostGIS, y después publicarlo con un GeoServer, para consumir un WMS desde JOSM.

Comencemos a procesar el archivo (quitar el encabezado), configurar la DB de Postgresql y después cargar el archivo.

FILE=8e3_buildings.csv

mv "${FILE}" /tmp/buildings.csv
tail -n +2 /tmp/buildings.csv > /tmp/tmp.csv 
mv /tmp/tmp.csv /tmp/buildings.csv

psql

CREATE DATABASE gob WITH OWNER angoca;
 
psql -d gob

CREATE EXTENSION postgis;

CREATE TABLE Open_Buildings_Temp (
 latitude DECIMAL NOT NULL,
 longitude DECIMAL NOT NULL,
 area_in_meters DECIMAL NOT NULL,
 confidence DECIMAL NOT NULL,
 geometry VARCHAR NOT NULL,
 full_plus_code VARCHAR
);

CREATE TABLE Open_Buildings (
 latitude DECIMAL NOT NULL,
 longitude DECIMAL NOT NULL,
 confidence DECIMAL NOT NULL,
 geometry GEOMETRY NOT NULL
);

COPY Open_Buildings_Temp
 (latitude, longitude, area_in_meters, confidence, geometry, full_plus_code)
 FROM '/tmp/buildings.csv' csv;

INSERT INTO Open_Buildings
 (latitude, longitude, confidence, geometry)
 SELECT
  latitude, longitude, confidence, ST_GeomFromText(geometry, 4326)
 FROM
  Open_Buildings_Temp;

DROP TABLE Open_Buildings_Temp;

Una vez cargado los datos en PostGIS, ahora generemos una capa de estilos en QGIS. Para esto se configura una capa desde PostGIS, conectándose a la DB. Después de agregar la capa, se le dan propiedades a la capa para escoger los colores. En Simbología, escogemos en la parte superior “Graduated”, en valor escogemos la columna “Confidence”, podemos cambiar los colores de Ramp, a amarillo y verde. Después se le hace click en “Classify”, lo cual puede tomar un tiempo ya que tiene que analizar todos los datos, y se obtendrá una tabla de colores similares a la de la imagen.

En la parte baja se selecciona “Estilo”, y se le indica “Guardar Estilo”. en la nueva ventana se selecciona “Guardar Estilo” como “Estilo SLD”.

Después escoger los tres puntos “…” e indicar el nombre del archivo. Ahí se especifica una ruta, la cual se usará para determinar los colores desde GeoServer.

Ahora vamos al GeoServer, comencemos creando un Espacio de Trabajo, para separar todo lo de Open-Buildings.

Agregamos una nueva fuente de datos, que corresponde a la base de datos. En la imagen mostrada ya hay otros definidos.

Escogemos una DB tipo PostGIS.

Y le indicamos la configuración para acceder.

Ahora vamos a Capas, y agregamos una nueva.

En nueva capa escogemos la fuente de datos definida antes.

Para poder crearla debemos definir los límites, lo cual se define haciendo click en “Calcular desde los datos” y después en “Calcular desde el encuadre nativo”.

Ahora creamos el estilo, para poner los colores del nivel de confidencialidad de la silueta del edificio.

En la creación del estilo, le damos cargar archivo, donde escogemos el archivo generado por QGIS, el SLD. Y le damos validar.

De vuelta en la capa, la abrimos, y en configuración de WMS escogemos la de “Open-Buildings” y cambiamos el estilo por defecto, de manera que nos muestra las mismas opciones de degradé que se definieron en QGIS.

Ya podemos previsualizar la capa, haciendo click en OpenLayers.

Y puede tomar un poco mientras genera la imagen. Copiemos la URL hasta la interrogación.

Si se hace más zoom, se deben ver los edificios de diferentes colores.

Ahora configuremos JOSM. Abrimos las configuración de imágenes, donde seleccionamos agregar WMS. Ahí pegamos la ruta que copiamos en el paso anterior y hacemos Get Layers. Recomiendo cambiar el nombre de la capa a:

“Google Open-Buildings”

Y después activamos la capa en JOSM.

En Internet se encuentra el logo de Wikipedia en modo real, o sea, la esfera de rompecabezas impresa en 3D, y yo siempre había querido hacer algo equivalente para OpenStreetMap, el mapa y la lupa en modo real. Como he utilizado el logo de OSM para crear pines o calcomanías, he utilizado el archivo SVG e identificado los pliegues del mapa, los cuales son particulares desde una perspectiva del origami (papiroplexia realmente). Sin embargo, un día mientras leía Twitter, vi en la cuenta de Massimo un pliegue para despliegue de satélites, llamado Miura Fold. Lo mejor de esto es que eran exactamente los pliegues del logo de OSM.

Me puse a buscar cómo hacer este pliegue y adaptarlo a OSM. Primero siguiendo las instrucciones del doblez el cual es originalmente para una proporción de papel diferente (no cuadrado), por lo que me tocó hacer ajustes para encontrar la forma de hacerlo para un papel cuadrado.

Por otro lado, tengo en mi casa una lupa redonda, la cual se asemeja a la de OSM. Tomando las dimensiones de la lupa, busqué un tamaño de papel aproximado para hacer el logo. Ya con esto, usé el archivo SVG del logo, extraje la capa del mapa, la imprimí con las dimensiones que quería.

Marqué las zonas de doblez y de corte y me dispuse a preparar el mapa.

Para hacerlo más realista, tomé unos trozos de fomi (etilvinilacetato) agrandé el mango de la lupa, para que tuviera las zonas amarillas (foto por el revés de la lupa).

Me faltaba un detalle, el código binario que se refleja en la lupa. Pensé en cortar los números y pegarlos sobre la lupa, pero no me parecía apropiado y un poco burdo. Me puse a jugar con la lupa, y vi que mi lámpara TaoTraonics reflejaba bien en la lupa. Comencé a taparla para ver si reflejaba algo particular y sí lo hacía, pero por ser tan intensa la iluminación también traspasaba el cartón o papel que se ponía. Me tocó tapar la zona a cortar con cinta aislante, y de esta forma solo se veía lo que quería reflejar. Entonces, extraje los números del SVG del logo, los enderecé, los imprimí a un tamaño apropiado para mi lámpara, los pegué en un cartón, les puse la cinta aislante por detrás y me puse a cortarlos manualmente. ¡Esto último tomó tiempo!

Finalmente, le pedí a mi cuñada un soporte de celular, y comencé a jugar con el movimiento de la lupa con el mapa y el reflejo de la luz. El resultado lo puedes ver en:

• https://twitter.com/MaptimeBogota/status/1672355906607087617 • https://en.osm.town/@MaptimeBogota/110596183713936174 • https://www.instagram.com/reel/Ct2Ot0-JsQ5/?igshid=MzRlODBiNWFlZA%3D%3D

Si te gusta el resultado final, dale un like.

Como hice varias pruebas para que el video saliera bien, en la versión que escogí mi esposa estaba hablando cerca, y quedó el audio de ella. Fue un descuido mío, ya que me enfoque en la imagen y no en el sonido 🤦.

Este es un artículo que describe la actividad que se realizó entre mayo y junio de 2023, llamada Mapea por Mosquera, donde se mapeó en detalle el centro del municipio de Mosquera, Cundinamarca, Colombia.

Involucrar a la comunidad

Este evento buscó integrar a la comunidad, enviando invitaciones a varios grupos locales, publicando invitaciones tanto físicas como por redes sociales, y haciendo referencia a la alcaldía del municipio (este último usa OpenStreetMap en su página web.)

Por otro lado, se imprimió un sticker para pegarse en los establecimientos detallaban en el mapa. La pegatina tenía un código QR a un enlace acortado (dub.sh) que apuntaba a una subpágina del wiki de la actividad: https://wiki.openstreetmap.org/wiki/ES:Edici%C3%B3n_organizada/Actividades/Mapea_por_Mosquera/Bienvenido

Esto permitía que las calcomanías hicieran publicidad sobre el evento días después de terminado, y que las personas supieran qué se había hecho.

En conclusión en este elemento, es que si se promociona el evento con anterioridad (redes sociales, afiches, volantes) y se dejan marcas de los lugares mapeados (calcomanías), se dejará una huella visible en el área de mapeado, y se puede involucrar a la comunidad, inclusive posterior al evento.

Bitácora

El día 28 de mayo se reunieron varios mapeadores con experiencia y se hizo un levantamiento en terreno. Esto consistió en:

• Recorrer las calles identificando los elementos a mapear - 2 horas.
• Recorrer los andenes (ambos lados de la vía) tomando fotos en cámara 360 con una patineta eléctrica - 2 horas.
• Vuelo en dron manual - 1 hora.

Posteriormente, se hizo:

• Subir las fotos a Mapillary (una secuencia ha tomado 3 semanas en procesarse).
• Con las fotos del dron se creó una ortofoto (10 horas de procesamiento) y se intentó subir a OpenAerialMap.
• Crear una tarea en Tasking Manager y se dibujaron todas las construcciones, zonas verdes, árboles, andenes.
• Con las secuencias de Mapillary (las que sí se procesaron) se detallaron cosas de la zonas: bolardos, postes eléctricos, luminarias, rampas,bancas, acnecas.
• Una vez todo se mapeó con la foto satelital, se invalidaron las tareas para identificar los comercios con las fotos de Mapillary. Sin embargo, no sirvió porque no todas las secuencias se procesaron (a tiempo).

Finalmente, el evento presencial:

• Se dividieron las manzanas para trabajar de a parejas. Asignar manzanas cercanas para apoyarse. El elemento de seguridad por manipular celulares puede ser importante en algunas ciudades - 2 horas.

Conclusión, volar el drone con un vuelo programado, para que sea eficiente de batería y tenga una ruta óptima (horizontalmente sobre las calles - no predios, dar giros de 360 grados cada cierto tiempo para captar los centros de las manzanas, volar a 40 metros mínimo. Con respecto a las fotos 360, cortar las secuencias periódicamente, cada 30 minutos por mucho.

Innovación

Este evento fue innovador por muchos motivos:

• Fue un mapping party (gente en terreno) y mapathon virtual (gente en computadores) al mismo tiempo. Mas sobre esto en Resolución de notas en tiempo real.
• Se integraron varios grupos para trabajar en un área específica. Participaron varios muchachos de diferentes grupos de YouthMappers, por lo que fue una integración entre mapeadores con experiencia y equipos, con mapeadores comenzando en el mundo de OSM.
• Lo más satisfactorio, es que el centro paso de ser un mapa muy simple y poco preciso a ser un área con alto nivel de detalle, utilizable con diferentes propósitos.

Resolución de notas en tiempo real

Las notas tienen un gran potencial, ya que pueden ser creadas por personas que no saben mapear. Por otro lado, permite una comunicación entre quien la crea y quien la soluciona. Además, herramientas como Fediphoto, o inclusive StreetComplete tienen la opción de agregar fotos. Esto último permite que las personas tomen fotos de cosas que ven mal en el mapa.

Con respecto al tiempo real, había un grupo en los computadores, resolviendo las notas que se creaban. Esto permitía que el mapa se actualizara en tiempo real, y las personas en terreno debían refrescar los desafíos de MapRoulette.

Este mecanismo de resolución de notas en tiempo real tiene mucha aplicabilidad en temas de mapeo humanitario o de crisis, donde las personas en terreno no saben qué es mapear, pero reportan lo que ven.

Historia

En Bogota se hizo una GeoBeer el 13 de abril de 2023. En dicha reunión hubo participantes de varias organizaciones y miembros de diferentes capítulos de YouthMappers.

Gracias a esta integración, se propuso mapear el área de un miembro de YouthMappers, en este caso Mosquera, para así mejorar una área diferente a Bogotá y empoderar a la siguiente generación de mapeadores.

Desde ese momento, fue que GeoParche UN comenzó a organizar el evento, y MaptimeBogota como GeoLab UdeA y uamaps participaron.

Participantes

• Rafael Isturiz
• Juan Melo
• Natalia Florián
• Angie Trujillo
• Zeltzin Palacios
• Sebastián Agudelo
• Zamir Tachack
• Felipe Díaz
• Marcela
• Andrés Gómez
• Alexis Buenaventura

Junto con Rafael Isturiz - risturiz, hemos estudiado las notas de OSM en sus diferentes aspectos. Como parte de esto, nos dimos cuenta de que las notas sirven para permitir la comunicación entre personas en terreno con personas en el computador (arm-chair mappers). Por lo que le solicitamos a Qeef algunas modificaciones en DAMN-project / Divide and Map, Now., para que detecte las nuevas notas de un área, y así poder resolver las notas recientemente creadas. En otras palabras, poder resolver notas en tiempo real. Aquí explico cómo preparar un evento de estos, con un caso concreto.

El capítulo de YouthMappers de la Universidad Nacional de Colombia (UN GeoParche) está organizando varias actividades de mapeo del área de Mosquera (un municipio cerca de Bogotá). Una de esas actividades es un mapping party donde van a participar personas de la comunidad OSM Colombia, entre esos yo, AngocA. Como todo mapping party, se captura información en terreno con diversas aplicaciones, y entre las actividades, vamos a estar creando notas sobre elementos que no estén en el mapa gracias a la aplicación Fediphoto. En paralelo, se realizará un evento en línea por OSMvideo – BigBlueButton, por el canal de Notathones LatAm, el cual dirigirá Rafael. Parte del evento en línea consiste en explicar el funcionamiento básico de DAMN-project client en JOSM, para tomar un parte del área de Mosquera y monitorear la creación de nuevas notas; de esta manera se detectan y se resuelven al instante.

Lo primero que toca hacer es definir el área donde se va a trabajar. En este caso, el mapping party se va a realizar en la zona central de Mosquera, por lo que el área donde se pueden llegar a crear las notas será la misma área.

Como ya sabemos en qué área se van a crear las notas, la dividimos en espacios de trabajo para monitorear la creación de notas. Para este caso decidimos crear un área cada 3 cuadras de largo y de ancho 2 medias cuadras. Esto lo podemos dibujar con la herramienta https://vector.rocks/, asegurándonos de que no queden espacios entre las áreas, o sea que los nodos de esquinas continuas estén superpuestos (hay muchas otras herramientas, y lo importante es que se genere un GeoJSON con áreas colindantes compartiendo nodos). Una vez dibujada el área se descarga el correspondiente GeoJSON.

Con el GeoJSON descargado, ahora lo editamos para agregar la etiqueta “name” al mismo nivel de “type”: “FeatureCollection”. Esto es necesario para que DAMN-project tome los espacios de trabajo definidos en el paso anterior y no los genere automáticamente como rectángulos. Para esto también se puede usar el visor https://geojson.io/, donde mostrará el área, y el documento en texto. Si se modifica por este lado, entonces al oprimir sobre Save, y escoger GeoJSON, se bajará un archivo llamado map.geojson.

Ya en este momento tenemos el archivo para crear el proyecto en DAMN-project, en la parte de “manager”: https://manager.damn-project.org/#area=new. Para esto, llenamos el formulario con las siguientes opciones:

• Le incluimos un buen comentario de conjunto de cambios (que también sirve de nombre de proyecto):
  • Notathon Mosquera 2023 #MaptimeBogota #ONL
• Una prioridad de 2 basta.
• En la descripción indicar que lo que se busca es solucionar las notas a medida que se crean en terreno:
  • Tomar una, y abrirla en JOSM para identificar las notas creadas en dichas áreas, para resolverlas en tiempo real. Puedes comunicarte con quien creo la nota escribiendo un comentario a la nota, por si necesitas más detalles.
• En las instrucciones, indicamos que se van a resolver Notas y agregamos un link hacia https://wiki.openstreetmap.org/wiki/ES:Notas
  • También escogemos “Download notes automatically.”
• En la parte el GeoJSON boundary file, buscamos el archivo que dibujamos en vector.rocks y que después le agregamos la etiqueta name. No debemos seleccionar las opciones sobre los custom squares porque perderemos las áreas de trabajo.

Finalmente, guardamos (save new area) y la habremos creado un proyecto en DAMN-project, el cual lo podemos ver en la parte de administración https://manager.damn-project.org/ o en la parte de mapeo https://mapper.damn-project.org/.

Ahora, podemos buscarlo en el cliente de JOSM, por medio del botón GetAreas:

Nos aparecerán todos los proyectos actualmente activos en DAMN-project.

Para este caso escogemos: “Notathon Mosquera 2023 #MaptimeBogota #ONL” haciendo doble click. Ahí nos mostrará la descripción del proyecto.

imagen 10

Si hacemos click sobre “Get area geometry”, se decargan todas las siluetas de espacios de trabajo. En otras palabras, las mismas áreas que definimos antes.

Cuando hacemos click sobre Map, automáticamente nos asignará un área de trabajo, descargando las capas correspondientes.

En este momento ya estamos monitoreando nuestra área, y dependiendo de la configuración, nos descargará las notas recientemente creadas. Para esto se abre el panel de notas.

Para monitorear frecuentemente el área en búsqueda de nuevas notas, se puede reducir el tiempo de consulta, modificando la configuración de damn, bajo preferencias, avanzado: damn.download_notes_period_minutes.

Cuando se termine de monitorear, ya que el mapeador no puede seguir con la notathon, entonces debe hacer click en “Map again”, y aceptar el mensaje de texto. Esto indica que el área queda disponible para otro mapeador.

Si alguien hace click en “To review” o “Done”, será necesario volver a habilitar esas áreas desde la zona de manager: https://mappy.damn-project.org/ seleccionando el área en modo revisión o terminada, hacer click derecho y escoger “Needs mapping.

Esta es la forma como que prepara un Notes Real-time Resolution, por medio de varias herramientas, y ante todo un equipo de trabajo tanto en terreno como en el computador.

He estado haciendo una lista de aplicaciones y páginas web con propósito específico en diferentes entradas de mi diario, la cual muestro a continuación. Hoy quiero presentar una lista de aplicaciones móviles y páginas web que permiten subir fotos, que pueden ser usadas para mejorar el mapa.

Otras entradas similares de mi diario:

• Páginas web para mejorar datos de OSM.
• Aplicaciones para mejorar el mapeo en terreno

Muchas de las opciones aquí listadas se pueden usar para asociar una foto con un elemento del mapa con la etiqueta Key:image

Listado de servicios asociados a fotos:

• Mapillary: Hace parte del servicio más grande de fotos libres a nivel de calle. Permite tomar fotos desde celular (iPhone y Android) y subirlas desde la aplicación directamente. También se pueden tomar fotos con otras cámaras, como GoPro, Garmin o algunas 360, y subirlas desde la aplicación de escritorio o línea de comando. Para visualizar las fotos, también ofrece un plugin en JOSM y está integrado en iD, lo cual permite que se usen durante el mapeo. Tiene su propia etiqueta en OSM Key:mapillary.
• KartaView: Antiguamente llamado OpenStreetView, OpenStreetCam y ahora KartaView. Es un proyecto similar a Mapillary, con aplicaciones para celular (iPhone y Android) y mecanismo para subir fotos desde escritorio. También ofrece plugin en JOSM.
• Mapilio: Es un clon de Mapillary en muchas cosas, basado en el código abierto, ofreciendo la misma funcionalidad.
• Fediphoto (code): Se integra con el Fediverso para publicar fotos y asociarlas en una nota de OSM. Se puede usar con nuestra instancia de Mastodon. Disponible en Android y f-droid.
• Commons:Mobile app: Aplicación para subir fotos a Wikimedia Commons. Estas pueden ser asociadas en los elementos mapeados. Disponible en Android y F-droid. Se puede asociar una etiqueta para una sola foto en Commons: Key:wikimedia_commons.
• StreetComplete: Es una aplicación para mejorar los datos de OSM en terreno. Permite crear notas publicando una foto en un sitio web personal. Las fotos se borran cuando la nota se resuelve. No es recomendable relacionar las fotos de este portal por ser temporales.
• MapComplete: Es un editor web que funciona en computador como en celular (funciona muy bien si no se descargan mucho elementos del mapa). Permite crear notas con una imagen asociada, la cual es publicada en Igmur. El problema de Igmur es que se depende de la capacidad y términos cambiantes de esta plataforma.
• OSM Tracker: Es una aplicación para capturar datos desconectado mientras se captura una traza GPX. Entre las opciones hay la posibilidad de tomar fotos y quedan guardadas en el dispositivo. Después, es necesario descargarlas y usarlas para mapeo en JOSM. Nunca se suben a un portal, por lo que no hay problemas de privacidad o reutilización de las fotos. Disponible en Android y F-droid.

Esta entrada fue gracias al mensaje que me envió 5R-MFT.

En la entrada anterior, listé (y voy a procurar mantenerla actualizada) las aplicaciones nativas para celular que permiten mejorar los datos de OSM. En esta entrada, voy a listar las páginas web que están adaptadas tanto para computador como para celular para mejorar los datos. Esto quiere decir, aplicaciones que van más allá de ser un POI editor (que recibe datos y no más), y en cambio le genera un formulario preguntando sobre las etiquetas faltantes para ese tipo de objeto.

• MapComplete - una serie de mapas temáticos acerca de OSM, donde puedes mejorar los datos de cada tema editando directamente. Algunos temas: basuras, cafés, restaurantes, educación, puntos de carga de carros eléctricos, entre muchos otros más.
• OSM Go - una página con interfaz sencilla para editor objetos existentes y mejorar, o para agregar POIs. También existe como aplicación para Android, pero no la pude instalar.
• HealthSites - una página web para mejorar los datos asociados con la parte de salud: hospitales, clínicas, médicos, farmacias, etc.
• OSM Hydrant - una página para editar todo lo relacionado con bomberos: estaciones, hidrantes, reservas de agua.
• WheelMap - una página para editar lugares para accesibilidad en silla de ruedas.

Si conocen otra aplicación que encaje en esta lista, con gusto la incluiré.

Otras entradas similares de mi diario:

• Aplicaciones para capturar fotos y que se usan para mapear.
• Aplicaciones para mejorar el mapeo en terreno

Esta entrada la hice por la pregunta de Yéssica De los ríos sobre el uso de OSM Go y qué alternativas había.

Hay muchas aplicaciones móviles en el ecosistema de OpenStreetMap. Varias de ellas ofrecen opciones para mejorar los datos en terreno. Aquí presento las más conocidas:

• EveryDoor: Una aplicación hecha por Ilja Zverev disponible en Android (Google Play) y iPhone (AppStore); esto debido a que está desarrollada en Dart/Flatter. Permite agregar POIs y añadir información a objetos mapeado.

• StreetComplete: Una aplicación con una interfaz muy agradable, donde le hace preguntas muy intuitivas para mejorar el mapeo en terreno. Es ideal para principiantes y personas que quieren contribuir al mapa sin estar en un computador. Esta disponible en Android (Por Google Play y F-droid).

• OpenStop: Es una aplicación reciente, actualmente solo en alemán, que permite mejorar los datos de transporte público. Está basada en StreetComplete, y está disponible in Android (Google Play) y iPhone (AppStore).

• SCEE: Es la versión avanzada de StreetComplete, StreetComplete for Experienced users. Está disponible en Android solo por medio de F-droid.

Otras entradas similares de mi diario:

• Páginas web para mejorar datos de OSM.
• Aplicaciones para capturar fotos y que se usan para mapear

Esta entrada está basada en una pregunta que me hizo Juan Carlos Melo.

Sistemas para hospedar fotos a nivel de calle

OpenStreetMap no ofrece un sistema de hospedaje de fotos, ya que el propósito del proyecto es ofrecer una base de datos geográfica. Sin embargo, OSM etiquetas para referenciar imágenes en publicadas en algún servicio externo. Por ejemplo, existe la propuesta de etiqueta image - https://wiki.openstreetmap.org/wiki/Key:image que es genérica y sirve para cualquier imagen hospedada externamente. Otras etiquetas hacen referencia directa al sistema que las hospeda, y es lo que se llama foto enlazado – photo linking https://wiki.openstreetmap.org/wiki/Photo_linking:

• Mapillary - https://wiki.openstreetmap.org/wiki/Key:mapillary
• Wikimedia Commons - https://wiki.openstreetmap.org/wiki/Key:wikimedia_commons
• Flickr - https://wiki.openstreetmap.org/wiki/Key:flickr

De manera general, hay varias formas de asociar imágenes con un punto de interés (POI). Esto se debe al interés por las imágenes a nivel de calle – Street level photos, donde el más popular es Goole StreetView, pero este no es libre. Entonces, aquí es cuando descubrimos una variedad de opciones y licencias, de los que desconozco sus detalles, pero quiero listar.

Google StreetView

• https://wiki.openstreetmap.org/wiki/Google
• https://maps.google.com/
• https://www.google.com/intl/es-419_co/help/terms_maps/

Son fotos a nivel de calle, principalmente tomadas por Google con sus autos y maletas son cámaras. En algunos casos se puede pedir prestadas estas mochilas para tomar fotos de algún de interés. Las fotos quedan propiedad de Google, y se pueden visualizar por la página de Google Maps con unos términos de uso. No se pueden usar estas fotos para hacer obras derivadas, por lo que no se pueden usar para mapear en OSM.

Mapillary

• https://wiki.openstreetmap.org/wiki/Mapillary
• https://en.wikipedia.org/wiki/Mapillary
• https://www.mapillary.com/app/
• https://www.mapillary.com/terms

Es una plataforma para subir fotos, ahora propiedad de Facebook. Es un proyecto que se integra con OpenStreetMap en varios puntos: hay una etiqueta de OSM para referenciar el id de una foto. Muchas de las personas que apoyan este proyecto buscan facilitar el mapeo de OSM. La licencia de las fotos es CC-BY-SA, lo que quiere decir que se pueden usar las fotos para obras derivadas, como mapear en OSM, como también con otros propósitos inclusive comerciales.

KartaView

• https://wiki.openstreetmap.org/wiki/KartaView
• https://en.wikipedia.org/wiki/KartaView
• https://kartaview.org/map
• https://kartaview.org/terms

Tiene una larga historia, desde cuando era un proyecto básico llamado OpenStreetCam, después pasó a llamarse OpenStreetView y después de cambio de propietario llegó al nombre de KartaView. Es un proyecto que tiene historia, muchos cambios, y aún no es ampliamente usado para contribuir, pero está muy presente en la mente de los voluntarios. La licencia de las fotos también en CC-BY-SA.

Mapilio

• https://mapilio.com/app
• https://mapilio.com/terms
• https://mapilio.com/licenses

Es una app que se basa en el código abierto de Mapillary. Es un proyecto que está comenzando por lo que es prometedor, pero no alcanza a tener muchas fotos en su repositorio.

Hivemapper

• https://hivemapper.com/
• https://hivemapper.com/tos/mapping-network

Es una plataforma propietaria, donde las fotos no quedan publicadas con licencia abierta. En retorno de la contribución, pagan por las fotos.

Aquí una lista adicional de plataformas por país: https://en.wikipedia.org/wiki/List_of_street_view_services

Hasta hace poco me enteré de la aplicación OpenStop, que se parece bastante a StreetComplete y es para mejorar el mapeo de la infraestructura del transporte público. La aplicación está para iOS y Android y su página web es https://openstop.app/

La situación actual de la aplicación es que solo está en alemán, por lo que las preguntas salen solo en ese idioma. Por tal motivo he traducido todas las preguntas para que cualquier hispanohablante pueda responderla.

La traducción está aquí: https://github.com/MaptimeBogota/Varios/tree/main/OpenStop-app

El API Overpass y su lenguaje de consultas es algo que los voluntarios de OpenStreetMap debemos aprender en algún momento. Se usa en MapRoulette para definir los desafíos; en JOSM para descargar cierto de tipo de datos; directamente en la consola Overpass-Turbo. En fin, en muchos lugares podemos necesitarlo. Sin embargo, aprender este lenguaje no es tan fácil, ya que la documentación en algunos casos es abrumadora, y la mayoría está en inglés. Pero desde el grupo MaptimeBogota, hemos arreglado un tutorial y lo hemos traducido al español, para que la curva de aprendizaje sea más suave y podamos aprovechar esta excelente herramienta.

Hace 5 años, escribí una entrada en este diario donde listaba algunas páginas para aprender Overpass, de las cuales algunas entradas siguen siendo vigentes:

• Overpass API en el wiki.
• Manual de usuario.
• Overpass turbo en el wiki, que es la página web para ejecutar consultas overpass - QL.
• Overpass-turbo-turorial de datadesk

Otra entrada que había incluido, y que personalmente me parecía la mejor es LearnOverpass. Sin embargo, dicha página dejó de funcionar hace unos años por un llamado interno a Overpass había cambiado por lo que no mostraba resultados. Al parecer, en este momento no hay desarrolladores mejorando o corrigiendo el código. Por tal motivo, decidí hacer un fork y hacerle unas mejoras por nuestro lado (El problema de estas mejoras, es que han habido cambios que no permiten ser integrables con la versión original, ya que la URL base la tuve que cambiar.) La página está en: https://maptimebogota.github.io/learnoverpass/

Las diferencias con la versión original no son solo la correción de la URL hacia Overpass, sino también la corrección de las actividades, ya que un restaurante no existe, por lo que los queries no funcionan. La gran diferencia es que las actividades se tradujeron al español, con eso la comunidad hispanohablante puede aprender más fácilmente overpass.

Aprovecho para listar otros links que se han publicado desde mi entrada anterior:

• LearnOSM - Una breve introducción de qué es Overpass.
• OSM Queries - Quizás la guía más completa de Overpass. Lo único es que no es un tutorial para escribir queries, sino solo ejecutar los existentes.
• Geographic data mining and visualisation for beginners - Overpass turbo tutorial - Una guía de Mateusz Konieczny que muestra ejemplos concretos.
• Overpass turbo: Minería de datos para OpenStreetMap - Una presentación de overpass en español usando overpass-turbo.
• Descarga inteligente de datos OSM con Overpass API - Una explicación de overpass con algunos pocos ejemplos de queries.
• https://renenyffenegger.ch/notes/development/OpenStreetMap/index - Notas de René Nyffenegger sobre Overpass.
• Understanding Overpass, the API of OpenStreetMap - Artículo de presentación del API.
• Overpass QL Intro - Introducción sobre Overpass.
• Loading Data from OpenStreetMap with Python and the Overpass API - Introducción a Overpass y cómo usarlo desde Python.
• A Turbo Introduction to Overpass - Minh Nguyen

El contenido de este artículo fue enviado a: https://wiki.openstreetmap.org/wiki/ES:LatAm/Proyectos/Resoluci%C3%B3n_de_notas/Preparaci%C3%B3n_premios ya que el formato de los queries no funcionaba.

El sábado 1 de octubre de 2022, se realizó una notathon, como se acostumbra hacer una semana después de la junta Latam. En esta ocasión se hizo en México, y se coordinó por medio de BigBlueButton - OSMVideo, donde participaron varias personas.

En esta ocasión se uso DAMN-project para dividir las zonas. Para la división de áreas se filtró por solo las notas creadas a partir de la aplicación Maps.me. Esta es la tarea de DAMN: https://client.damn-project.org/?area=2407

Se enseñó cómo usar el plugin de JOSM, el cual baja automáticamente las notas, y esto permite trabajar en varias áreas, sin tener que salir del editor.

En total se resolvieron 63 notas, con participantes principalmente de México (alex_mayorga, Mapeadora, Sandra, entre otros), pero también hubo asistentes de Venezuela (risturiz), Argentina (Manuel Retamozo) y Colombia (AngocA).

Esta actividad ha permitido que trabajemos como región, apoyándonos mutuamente, y cada uno aportando desde su experiencia. Aprendimos de mapeo de árboles, de estrategias de mapeo humanitario, entre otras cosas.

Igualmente, hubo preguntas muy buenas, y vamos a crear un par de tiquetes en DAMN y OSM. Por ejemplo: el API de OSM no debería crear una nota con las misma coordenadas sobre una ya existente y abierta; en cambio, debería agregar un comentario a la existente.

Si quieres ver lo que pasó en la Notathon de México, la puedes revivir en: https://youtu.be/oXmOmT8GT7Y

En un artículo pasado de mi diario, hablé sobre las incompatibilidades entre la licencia de OpenStreetMap, la ODbL, y la licencia de muchas fuentes de datos, la CC-By: Aclaración del permiso de usar CC BY en OSM.

Hoy quiero compartir un par videos que he hecho para explicar más visualmente las dos incompatibilidades:

• Atribución.
• Gestión de derechos digitales.

Hace unos meses comencé a revisar la página del wiki acerca de Objetos del mapa buscando arreglar las entradas que aún estaban en inglés. Para mí, esta es una de las páginas más importantes del proyecto OSM, ya que es la carta de presentación de lo que se puede hacer o encontrar en el mapa. Inclusive, muchos lugares externos referencian esta página (la de inglés principalmente), para promocionar el proyecto y mostrar sus capacidades. Sin embargo, cuando uno entra al proyecto, y descubre todos los posibles caminos, esta página uno la termina olvidando. Cuando uno ha mapeado mucho, ya conoce qué se puede hacer, cómo buscar lo que desconoce, etc., pero esta página de características del mapa no se vuelve a consultar. Es verdad que es una página muy grande (y demorada en cargar) pero permite entender el potencial del proyecto. Por eso, quise arreglar su versión en español para que estuviera más sincronizada con su versión en inglés.

Primero comencé a entenderla, ya que al editarla, no se ve tan compleja. El problema es que hace referencias a muchas otras páginas que se incrustan, y estas otras páginas tienen unas tablas. Entonces toca activar el espíritu investigativo y comenzar a abrir páginas y comenzar a imaginar cómo funciona todo esto. Es verdad que la edición del wiki en esto tan básico como agregar una nueva etiqueta a este listado, no está descrito en ningún lado. Pero esta aventura me ha enseñado muchas cosas, y me ha permitido hablar con muchos editores del todo el mundo.

En esta búsqueda descubrí la plantilla Taglist. Esta es una plantilla que permite generar una tabla de etiquetas, tan solo indicando el nombre del Key o del Key+Value, y la plantilla hace todo por debajo. Al estar leyendo sobre esto, me llevó a apoyar en el wikiproyecto Taginfo/Taglists/Wiki project que busca convertir tablas de Features en TagList. Esto con el fin de tener un mantenimiento más fácil (agregar o quitar una etiqueta consiste en tan solo agregar la palabra, y no lidiar con formato de tablas y columnas).

En este punto tomé la decisión de emprender el camino solo, y no basarme en el formato en inglés (algunas están en tablas tradicionales, otras con taglists). Por lo que convertí todo a taglist en la página en Español. Fue una tarea larga.

Después descubrí que si una etiqueta no tiene página en español, esta plantilla muestra la que está en inglés. Entonces, ahí me enfrenté a muchísimas etiquetas que no tenían página en español. Por lo tanto, decidí crear las entradas para estas etiquetas. El problema, es que nunca había creado una página desde cero.

Me documenté un poco, pregunté a algunos editores, y finalmente con solo tener la etiqueta KeyDescription o ValueDescription era suficiente, sin tener que tener todos los elementos internos. Además de esta etiqueta, el grupo de traductores a español piden que se incluyan estas páginas como “incompletas” de traducción, por lo que otras etiquetas eran necesarias.

De esta forma comencé a crear cientos de páginas en español, poniendo el nombre del key, y del value, la descripción en español, la imagen y listo. Al principio copiaba todas las etiquetas del inglés, pero después de conversar con otros editores, los otros valores los puede tomar del “data item” y se evita la redundancia.

Al principio no sabía qué era un data item, e inclusive hay muchos detractores de estos metadatos (como uno de los desarrolladores de TagInfo), pero a mi me parece que es mejor centralizar las propiedades de las etiquetas que no cambian entre idiomas, y el data item es el lugar adecuado. Por ejemplo, si un tag como highway=primary aplica para un way, este hecho no va a cambiar en español, francés o aleman, siempre aplicará de la misma forma; y el hecho de tener esto redundante solo trae problemas de imprecisión que los data item buscan solucionar.

Habiendo conocido un poco de los data item, creé páginas en español y después agregaba la misma descripción en el data item. Esto para evitar el lápiz rojo en los tags. Esta tarea la he venido haciendo miles de veces, y es literal, ya que he editado o creado como 1200 páginas en español con la descripción igual en el tagDescription y en el data item.

Pero vuelvo a la página de Objetos del mapa y veo que algunas imágenes faltan. Por lo tanto investigué, y entendí que TagList toma la imagen del tagDescription. Ahí entendí que es bueno poner la misma imagen en el data item.

En este punto, la página en español estaba con buen contenido: la descripción en español, y la mayoría de etiquetas con una imagen. Pero había una cosa que aún me genera conflicto, y es el hecho de mantener la lista de Taglist. ¿Por qué no se listan automáticamente las etiquetas que tengan un estado específico? por ejemplo, todas las approved.

Para encontrar la respuesta, caí en unos archivos javascript de taginfo que son los que generan el TagList. Decidí crear un tiquete en taginfo solicitando que TagList pidiera un estado y generara todas las entradas. El problema fue que uno de los desarrolladores me dijo que los estados tienen muchos problemas de escritura. Entonces, aquí comencé mi otra tarea, la de unificar estados.

Busqué la forma de encontrar los “spelling” malos, y para esto me ayudaron varios administradores de Wiki, donde arreglé miles de páginas. En esta momento llevo como 2500 entradas de tags que he modificado. Además, uno de los administradores me mostró una página https://wiki.openstreetmap.org/wiki/Category:Feature_descriptions_with_incorrect_status_value. En dicha página se listan los estados incorrectos, y se ha vuelto mi espacio en los últimos días.

Después de corregir tantas etiquetas, creé un tema en el chat de communities, ya que considero que unos estados de etiquetas son inválidos. En paralelo, le volví a solicitar al desarrollador de TagInfo que retomara mi solicitud de Taglist, debido a que ya el deletreo de los estados estaba mucho mejor.

Es por todo lo anterior que no he mapeado mucho en los últimos meses. Y es porque he estado dedicado al wiki.

Hola comunidad de OSM,

El próximo sábado 30 de Julio a las 16:00 UTC se realizará la 4a. reunión bimensual de OSM Latam. El evento se realizará por la plataforma OSM video: https://osmvideo.cloud68.co/user/and-msl-7if-yrk. La agenda de la junta está en: https://wiki.openstreetmap.org/wiki/ES:LatAm/Eventos/20220730_Reuni%C3%B3n_virtual. Todos los miembros de la comunidad Latam están invitados, donde el país organizar presenta sus proyectos, y después se discuten problemáticas a nivel latam.

Como es costumbre, una semana después de la junta bimensual, se realiza una Notathon. Este es un evento en que cerramos notas. En esta ocasión vamos a cerrar notas de Cayambé, Ecuador. El evento se realiza igualmente por OSM video https://osmvideo.cloud68.co/user/and-hrh-m5a-trl y vamos a usar el hashtag #ONL tanto en los commits como en los mensajes en donde cerramos notas. Para más información de la Resolución de Notas, visita la Wiki.

Las notathones son eventos en línea que buscan resolver notas de OpenStreetMap. En Latinoamérica hemos decidido hacer una notathon el primer sábado de cada mes a las 15h UTC. Este evento se ajusta con las juntas bimestrales que son el último sábado de cada mes, y debido a que la notathon es una semana después de la junta, ha permitido que varios contribuidores se integren a un evento de mapeo, siendo esta actividad algo que se puede aplicar en cualquier lugar.

Como parte de la junta Latam de Mayo, se decidió hacer una notathon enfocada en Cuba, para apoyar a los nuevos contribuidores de dicha comunidad, que están trabajando fuertemente en resolver notas.

El evento se realizó por OSMVideo - BigBlueButton, y se resolvieron 70 notas durante el evento, las cuales se cerraron por contribuidores de varios lugares: Brasil, Colombia, España, Guatemala, México, Venezuela con el apoyo de miembros de la comunidad de Cuba por medio de Telegram.

Aquí puedes revivir la notathon.

La herramienta principal con la que se identificaron las notas abiertas fue la página de Neis Pascal. Esta actividad hace parte del proyecto de resolución de notas de Latam el cual está asociado a una actividad organizada.

Como parte del proceso de resolución de notas, se incluyó el hashtag #ONL tanto en el mensaje de commit a OSM, como en el mensaje de cerrado de nota. Esto permite identificar las notas que se procesaron el grupo de OSM Latam: Notas en Telegram.

Gracias a los participantes del evento: @dcruizc, @risturiz, @ alex_mayorga, @ jqngarcia, @JAAS, @matheusgomesms y a todos los estudiantes del Colegio Salesiano de Duitama y su profesor @Leonardo Gutierrez.

Hace unos días hicimos una sesión de introducción al wiki de OpenStreetMap. Fue una especie de tutorial que se puede ver completamente con el video, o seguir paso a paso con la presentación:

• Video tutorial Wiki
• Presentación.
• Quiz Porque siempre es bueno probar tus conocimientos.

En uno de los eventos de los sábados de MaptimeBogota, uno de los asistentes, Rafael Isturiz, me preguntó sobre el mapeo de los ríos. Le dije que se podían usar varias técnicas, no solo usando la imagen satelital, sino también las curvas de nivel, y las imágenes multiespectrales.

Como esto era un poco complejo de explicar de manera rápida, decidí hacer un vídeo en YouTube. En dicho vídoe muestro estas técnicas para mapear mejor el trayecto de un río.

El video está en: https://youtu.be/TD2Qe_cZak8

En el video solo hablo del trayecto del río o quebrada. No explico los siguientes elementos:

• El sentido del río que siempre debe bajar.
• Que un cuerpo de agua como un río-river o quebrada-stream debe conectar otro cuerpo.
• El banco del río - riverbank.
• El mapear el trayecto en la mitad del río, sobretodo cuando son anchos.
• El dividir el río en muchos segmentos cuando es muy largo.

Tampoco hablo de la alineación de ríos, la cual la había explicado en: https://www.youtube.com/watch?v=_Yh2iXr8UU8