当年，8/29，我曾对球球和珠珠充满了向往。可如今…我再次被xt了。没事，被xt就被xt吧，我已经经历过一次了。小时候，我每天都想见到萌萌，但我的意识模糊，从来不敢主动去见，后来，萌萌走了，没有萌萌的日子，一天又一天的过去，我好像还是活着，可是关于萌萌，我几乎说不出话——好像基本都忘了。她成了一个符号，只知其名，不见其人，印象越来越模糊，有时我甚至怀疑她是否真的存在过。那天，萌萌竟然回来了，我终于回落到了现实——萌萌完全存在过，现在，她就在我面前！那时我很激动，但是我也没有什么举动，因为我刚经历完一次xt，十分胆怯，反而是萌萌对我的举动更大。我被萌萌的大胆惊呆了，感觉萌萌很温柔，很体贴，很狂放，但xt告诉我，也是诅咒我，我会再次被xt。回来的萌萌似乎不是以前的萌萌，而是所谓的“球球”和“珠珠”，多年来，没人叫她萌萌，但不知为何，她的记忆力特别好，她似乎对曾经的事情有所感觉，虽然我关于它的记忆已经乱七八糟。她告诉我了她的名字，刘贽萌，这也是我在初中以来的未解之谜：幼儿园时我从未知道她的名字到底怎么写。刚开始xt我的她对我真的很好，我似乎真的看到了xt的影子，但那时我还抱有一丝她不是在xt我的希望，过了一阵子，我的脑子已经被完全捕获了，总是过敏，而且不再能产生任何有用的东西，我大抵是知道了——我确实被xt了，而且已经是末期了。最后一天，萌萌问我，可不可以拉黑我，根据被xt的经验，我立刻说可以，我不知这个选择意味着什么，但是我那时很坚定。后来是失去萌萌的一段时间，我仍在关注着她，发现她的拉黑存在问题，后来有一天，我终于去尝试骚扰她，结果又被拉黑了。过了几天，我又发现拉黑被解除了，这次我没有随意骚扰：我震惊于她回话了，即使这确实发生了。后来，她确实一直会回话，可是总是发问号，我不太清楚这意味着什么，不过她与我的关系不再像小时候，她也不再xt我。

Hi, I am Venetis, a computer science student from Thessaloniki. This summer I’ll be working on closures.osm.ch as part of Google Summer of Code 2026, mentored by Simon Poole and David Haberthür.

closures.osm.ch is a platform where road authorities submit temporary road closures so that routers can avoid them. The data is there, but right now it doesn’t actually affect routing. That’s what I’m fixing.

My work this summer comes down to three things:

• Adding a Valhalla-powered routing endpoint that genuinely avoids closed roads
• Building a sidecar service that feeds active closures into Valhalla’s traffic tile system
• Improving the DATEX II/CIFS importer that brings closure data in from external sources

I’ll be posting updates here at each milestone. The code is on GitHub if you want to follow along.

Coding starts May 25. Looking forward to it.

Volviendo a patear el barrio

## Un recorrido por Granja de Funes II usando ChatMap

Me volví a encontrar con Dayana hace un mes y medio, después de dos años sin vernos. Primero la llamé por teléfono, le dije que tenía una propuesta y rápidamente me invitó a su casa. Estaba en la misma casa, en la misma cuadra, al fondo del barrio, a pocos metros del comedor que levantó con sacrificio hace más de 10 años y que hoy alimenta a más de 80 familias (niños, adultos y ancianos) y uno de los únicos trabajando en esa zona olvidada de la ciudad.

Pero algo había cambiado. Ese mediodía el barrio parecía más apagado: había menos gente en las calles, más esquinas anegadas, baches abiertos y bolsas de basura acumulándose sobre las veredas. Todo transmitía una sensación de abandono, como si la vitalidad cotidiana se hubiese replegado hacia adentro de las casas. El cuarteto, que otras veces impregnaba el aire y marcaba el ritmo del barrio, ahora apenas se escuchaba a la distancia: un murmullo intermitente que aparecía y volvía a desvanecerse.

Cuando, mate de por medio, empezamos a charla, también la noté a ella más apagada. Me dijo que le preocupaba la continuidad del comedor —que construyó como promesa a Dios por la recuperación de su hija que en esa época padecía un grave problema de salud. Ni siquiera la ayuda de los voluntarios, que la están acompañando después de “remarla sola durante años” terminaban de dibujarle una sonrisa. Rápidamente me puso al día sobre lo que estaba pasando, me contó sobre la falta de trabajo, el aumento de los problemas de consumo de sustancias entre niños y jóvenes, los recortes en la ayuda estatal, los robos, la desconexión con otras organizaciones y los problemas para llegar a fin de mes.

Yo venía a encontrarme con ella, para tratar de retomar algo que habíamos dejado en el tintero dos años atrás, un intento de crear un mapa comunitario del barrio, y el que ahora desde mi rol como Embajadora Comunitaria de UN Mappers, podíamos concretar.

Le conté que el principal objetivo de las actividades que me encuentro desarrollando es poder poner las tecnologías de mapeo abierto basadas en OpenStreetMap a disposición de las organizaciones, que como la de ella, tratan de mejorar la vida de las personas del barrio. Pero por un momento dudé en hacerle la propuesta de trabajo, porque pensé ¿puede un simple mapa ayudar a mejorar la situación de esta comunidad?

Dudando de mi propia convicción, le conté de qué se trataba la propuesta y le ofrecí hacer un registro de las cosas lindas del barrio que a ella le interesara mostrar. Su primera reacción fue, —”Pero… ¿Qué cosas lindas? Lo que tenemos que mostrar son los problemas que tenemos para que alguien nos escuche”—. Y empezó a enumerar una serie de necesidades que podían ser objeto de un trabajo de mapeo, que permitiera mostrar cómo se vivía en esa parte de la ciudad. Dos preocupaciones destacaron: la presencia de mini basurales y los anegamientos durante las lluvias.

Este problema no es nuevo, la ciudad de Córdoba, tiene problemas hídricos desde hace ya mucho tiempo[^1], distintas acciones se han emprendido, pero en zonas como Granja de Funes 2, ninguna ha resuelto el problema. Fue así que acordamos brindar una capacitación a los voluntarios y organizar una primera salida al campo el Sábado 09 de Mayo para mapear depósitos de basura y zonas inundables.

En paralelo con ayuda de otros voluntarios más experimentados, nos propusimos mejorar el mapa de OSM de la zona en que se encuentra el barrio usando el Tasking Manager de HOT[^2]: (https://tasks.hotosm.org/projects/49509).

Además, gracias a una nota que hizo sobre UN Mappers el equipo de IDECOR (https://www.idecor.gob.ar/onu-mappers-mapeo-colaborativo-y-datos-abiertos-para-el-desarrollo-comunitario/) aumentamos el alcance a interesados en proyectos de mapeo. Así además de las personas del comedor, contamos con la participación de voluntarios de otros espacios (estudiantes de psicología) y organizaciones (choique.org) que se sumaron a la actividad.

Dí inicio a la actividad contando qué es OpenStreetMap, sus diferencias con Google Maps y la importancia de la recolección de datos en campo para reflejar las necesidades e intereses de la comunidad, especialmente en zonas densamente pobladas.

Luego, usando SketchMap Tool, identificamos las áreas del barrio que sufren con mayor frecuencia problemas de anegamiento y decidimos que esas serían las zonas en las que conduciríamos las primeras actividades de mapeo en campo. Previamente había preparado una guía impresa para el uso de ChatMap, una herramienta desarrollada por el Equipo Humanitario de OpenStreetMap (HOT) que ha mostrado ser muy versátil y de fácil aprendizaje para las comunidades.

Los participantes se unieron al grupo de WhatsApp que habíamos creado y salimos al campo a levantar puntos relacionados con zonas anegables y mini basurales que aumentan de tamaño por arrastre de agua. En total recolectamos en esta primera salida al campo 94 puntos de interés. Aquí el mapa que obtuvimos como resultado (https://umap.hotosm.org/en/map/granja-de-funes-ii_2779)

Esta primera salida, nos permitió comenzar a patear el territorio y sus necesidades, aprender sobre el uso de herramientas de mapeo abierto, pero es un trabajo en proceso. No se resuelve la grave situación que están atravesando, pero busca ser una herramienta que nos permita visibilizar los problemas y pensar acciones en conjunto.

En este tipo de experiencias, el mapeo participativo, es una herramienta que permite que quienes habitan el territorio produzcan información sobre su propia realidad y la transformen en una herramienta de organización, visibilización y acción colectiva.

Muchas veces los barrios como Granja de Funes 2, aparecen poco representados —o directamente invisibilizados— en los registros oficiales. A través del mapeo participativo, las comunidades pueden identificar y documentar problemas concretos en este caso, los problemas ocasionados por falta de servicios, riesgos ambientales, accesibilidad, violencia urbana, infraestructura deteriorada o ausencia de equipamientos comunitarios. Pero también pueden registrar recursos, redes de apoyo, espacios de encuentro y formas locales de organización que suelen quedar fuera de las estadísticas tradicionales.

Así este trabajo, es el inicio de un proceso de trabajo que planeamos llevar adelante con comunidades barriales, para promover la participación comunitaria y la organización territorial. Vamos a seguir pateando el barrio juntos y aportando para generar un mapeo integral que les permita a las comunidades continuar mejorando sus condiciones de vida.

Si te interesa colaborar con Dayana y el comedor “Las Manos de mi Barrilito” acá dejo información de contacto. Y si tenés ganas de sumarte a algunas de las actividades que estamos realizando desde UN Mappers no dudés en escribirme.

[^1] https://www.lavoz.com.ar/opinion/la-importancia-de-la-planificacion-hidrica-urbana/ [^2] Trabajo que continúa en proceso.

For the first time, Humanitarian Data Exchange (HDX), a widely used platform for sharing humanitarian data, is releasing disaster-specific OSM datasets. This has allowed OSM data to be downloaded over 440 times in response to recent disasters in Madagascar and Mozambique including within the disaster affected countries themselves.

This initiative kicked off in early 2026 and has already resulted in two regularly updated and focused HDX-OSM datasets:

• Mozambique Floods, January 2026
• Madagascar, Tropical Cyclone Gezani, February 2026

Although the same data is directly accessible on OSM, being on HDX ensures:

• It is highly accessible: site visitors can download all relevant spatial data in a single click, no expertise is needed and the complexities of an Overpass query or QGIS plugin are avoided
• It is up-to-date: disaster responses result in rapid generation of OSM data, to match this HDX's disaster specific datasets are regularly updated, up to every two/three days during the early stages of a disaster
• It is location specific: HOT works with HDX to ensure that the OSM data for a disaster is focused on the disaster-affected area, including, but not limited to, all areas of active mapping (i.e. the HOT Tasking Manager project extents)

HDX has agreed to continue supporting this initiative, so look out for similar datasets for future disasters. If you are involved in coordinating the generation of OSM data in response to a disaster and want to increase the reach of the data, please feel free to reach out directly to me on OSM or email: sam.colchester@hotosm.org. To help set things up, ideally the following should be shared with me within a week of a disaster occurring:

• Contiguous area of interest (GeoJSON) defining the extent of the OSM data that will be available on HDX. This can also be understood as 'the disaster affected area'. It should contain all HOT Tasking Manager project extents but should also include other areas that you understand will be useful to responding organizations
• Links to all HOT Tasking Manager projects that are part of the response
• Description of the disaster including mapping needs, any response organizations and partner involvement
• By default OSM highways (roads) and buildings will be available in the dataset, but if additional features are needed they can be requested

For more detailed information see the HOT-HDX Disaster Data Wiki page.

Resumen

Problema n.º 1 desde el primer uso de las aplicaciones de navegación offline de OpenStreetMap para Android, como OsmAnd, Comaps u Organic Maps: el tamaño del mapa que hay que descargar. En muchos casos, hay que descargar todo el país o nada. Y eso suele suponer más de 100 MB, con casos que superan los 500 o 600 MB. ¿Por qué?

Experiencia personal: la llegada del smartphone al Sur Global

Durante el verano de 2013, coordiné junto con otras personas un proyecto HOT de cartografía OSM en el norte y noreste de Haití. En aquella época, la herramienta imprescindible para la recopilación de datos sobre el terreno eran los pequeños dispositivos Garmin de la serie Etrex, robustos y de bajo consumo, pero que requerían una fase de edición bastante larga en el ordenador. Llevaba unos meses con mi primer smartphone Android y, según recuerdo, OSMtracker ya existía, quizá también Vespucci (aunque no lo descubrí hasta más tarde) y OsmAnd estaba en sus inicios. Sin embargo, el ecosistema de aplicaciones aún no estaba lo suficientemente maduro como para sustituir al eTrex. Al final de la misión, vi que algunos participantes haitianos empezaban a equiparse con sus primeros smartphones.

Unos meses más tarde, ese mismo año, durante otra misión de cartografía en Mongolia, tuve una reunión con responsables del Banco Asiático de Desarrollo a quienes intenté convencer de todas las ventajas de OpenStreetMap. En un momento dado, utilicé como argumento la llegada de estas aplicaciones móviles de OSM que pronto permitirían a todo el mundo consumir los datos de OSM y contribuir a ellos fácilmente, teniendo en cuenta que los smartphones pronto estarían al alcance de todos. No tenía la sensación de estar haciendo conjeturas descabelladas: el GSM ya estaba en todas partes, parecía bastante lógico que los smartphones Android, cuyos modelos económicos empezaban a llegar, también tuvieran éxito y aumentaran la contribución y el uso de OSM.

¿Quizás mis interlocutores solo estaban familiarizados con los iPhone, mucho más caros? En cualquier caso, aquel día prácticamente se rieron en mi cara, respondiéndome que no, que eso no iba a suceder en unos años. De inmediato, a sus ojos me convertí en un friki alejado de la realidad y OSM en un proyecto de soñadores.

El smartphone, principal medio de acceso a OSM

Desde entonces, el GSM no ha desaparecido; su red sigue utilizándose ampliamente y sus dispositivos siguen siendo, en ocasiones, predominantes en algunas zonas rurales de todo el mundo, especialmente en el Sur Global. Sin embargo, los smartphones están muy presentes, como muestran estos informes de la GSM Association en África, Asia y América Latina, o este mapa mundial que muestra un índice de conectividad móvil.

Es cierto que estas estadísticas parecen basarse en el porcentaje de la población que dispone de conexión a Internet, y resulta difícil estimar qué parte de la población tiene un smartphone, teniendo en cuenta que algunos teléfonos básicos pueden conectarse a la red o que en algunos países (Costa de Marfil, por ejemplo) es habitual contratar dos operadores para aprovechar sus respectivas ventajas.

No obstante, el smartphone es, muy por delante del ordenador, el dispositivo con el que la mayoría de la población mundial accede a Internet. Y, por tanto, a OpenStreetMap. Desde 2013, el número de aplicaciones basadas en Android ha aumentado y sus funcionalidades se han ampliado, tanto en lo que respecta a la edición de datos como a su consumo, para actividades de navegación o de búsqueda. Sin embargo, siguen siendo inadecuadas para ciertos contextos y usos, especialmente en el Sur Global. Como esta entrada del blog ya es demasiado larga, hoy solo voy a abordar uno de estos defectos.

Primer defecto actual de las aplicaciones Android de navegación sin conexión: archivos de mapas demasiado grandes, especialmente para los países del Sur Global

A menudo he observado, en talleres de formación dedicados al manejo de aplicaciones como OsmAnd u Organic Maps/Comaps, que el mapa que hay que descargar puede ser a veces un archivo de más de 100 MB, que cubre todo el país, sin poder limitarse a la zona administrativa del lugar de formación.

Esto supone una doble limitación en países donde Internet puede ser lento, inestable y, a menudo, mucho más caro que en el Norte, sin conexión ilimitada. Tener que pagar una suma nada desdeñable en relación con el coste de la vida para descargar, a veces tras varios intentos, un mapa del que solo se va a utilizar el 10 % de la superficie no resulta necesariamente motivador.

El enfoque estadístico

He querido comprobarlo analizando todos los mapas disponibles. OsmAnd ofrece esta página web, que contiene todos los mapas disponibles, su tamaño y fecha de actualización, pero no he encontrado nada equivalente para Organic Maps/Comaps. Las estadísticas que siguen se limitan, por tanto, a OsmAnd y datan del mes pasado (he postergado un poco la redacción de esta entrada), pero los resultados probablemente serían similares para Organic Maps/Comaps, de los que, por cierto, proporciono algunos ejemplos.

Los resultados se muestran por continente. Por level_0 me refiero a los países para los que solo hay un mapa de todo el territorio nacional (nivel denominado admin0); por level_1, a aquellos que también cuentan con mapas según la primera división administrativa (admin1); y por level_2, a los países que disponen en OsmAnd de un segundo nivel de división demostrativo (admin2).

He elegido arbitrariamente 100 MB como umbral a partir del cual se puede considerar que un mapa es un archivo grande para descargar. Las estadísticas se agrupan por continente, con el número de países cuyo tamaño de mapa a descargar es superior a 100 MB, para cada una de las categorías (niveles 0, 1 y 2). Para los países que tienen niveles 1 y 2, se utiliza el valor medio del tamaño de los mapas.

La última columna muestra la información de cada país en orden descendente según el tamaño del archivo, incluidos aquellos que tienen la suerte de estar por debajo del umbral de 100 MB. Estos aparecen en verde para distinguirlos mejor. Los demás países aparecen en naranja si tienen entre 100 y 200 MB, y en rojo si superan los 200 MB.

Los resultados

Se observa una gran desigualdad entre los países de cada continente, con algunos que superan los 400 MB:

• Portugal, Rumanía, Grecia, Hungría, Irlanda, Eslovaquia y Bélgica en Europa
• Nueva Zelanda en Oceanía
• Colombia, Perú y Bolivia en Sudamérica
• Nigeria, Madagascar y Kenia en África
• Tailandia, Corea del Sur, Vietnam, Taiwán y Nepal en Asia
• en América Central, el conjunto de todos los países caribeños no constituye un país en sí mismo y debe considerarse más bien como una opción de descarga adicional. La reducida superficie de estos países hace que ninguno tenga aún un mapa sin divisiones administrativas que supere los 100 MB,

También se observa que solo Europa cuenta con doce países con un nivel 1 o incluso 2, pero con mapas de un tamaño medio superior a 100 MB. Probablemente esto esté relacionado con la densidad de los datos de OSM en Europa. En otros lugares, solo países inmensos como Australia, Rusia y Brasil superan los 100 MB a pesar de tener un nivel 1.

Para todos los demás, tener que descargar un mapa de más de 100 MB equivale a tener que descargar todo el país. Esto ocurre en 27 países africanos y 22 países asiáticos. En Nigeria, el país más poblado de África (y el sexto del mundo), utilizar OsmAnd implica tener que descargar un mapa de más de 600 MB, lo que lo convierte en el país peor cubierto por la aplicación. A título informativo, la situación es apenas mejor en CoMaps, donde se puede elegir entre Nigeria – Norte (217 MB) y Nigeria – Sur (479 MB). En Tailandia, más de 500 MB para OsmAnd y tres mapas en CoMaps (el más grande alcanza los 182 MB).

Sin embargo, otros tres grandes países africanos están bien cubiertos en OsmAnd con un nivel 1 que permite reducir drásticamente el tamaño de los mapas: la República Democrática del Congo, por ejemplo, con una media de 16 MB (y un máximo de 77 MB), Tanzania con unos 55 MB y Sudáfrica ligeramente por debajo de los 100 MB. Lo mismo ocurre en Asia con China, Japón, India, Indonesia (aunque algunas provincias superan los 200 MB) y Filipinas, donde es posible descargar mapas de un tamaño razonable.

¿Por qué?

¿Cómo se explica tal desigualdad de trato? ¿Por qué no ofrecer sistemáticamente un primer nivel de división para todos los países cuyo mapa completo supere los 100 MB o incluso, como hemos visto, mucho más, y no solo para algunos? ¿Es esto simplemente el resultado de la falta de demanda por parte de estos países mal atendidos?

OsmAnd publicó recientemente los resultados de una encuesta realizada a su comunidad de usuarios, distribuidos en cinco idiomas, sin que se conozca su país de origen. El problema del tamaño de los mapas no aparece en ella, pero ¿quizás se deba precisamente a que limita el número de usuarios en esos países? Sería interesante conocer el número de usuarios de los mapas de la aplicación para cada país, o al menos el número de descargas de cada mapa.

Sea como fuere, este problema del tamaño de los mapas en determinados territorios constituye el principal obstáculo para la adopción de estas aplicaciones de navegación en algunos lugares y una limitación para quienes, a pesar de todo, han decidido utilizarlas.

Traducido con DeepL.com (versión gratuita)

Resumo

Problema nº 1 logo na primeira utilização dos aplicativos Android de navegação #openstreetmap offline, como OsmAnd, Comaps e Organic Maps: o tamanho do mapa a ser baixado. Em muitos lugares, é o país inteiro ou nada. E isso frequentemente representa mais de 100 MB, com casos que ultrapassam os 500 ou 600 MB. Por que isso acontece?

Experiência pessoal: o surgimento do smartphone no Sul Global

Durante o verão de 2013, coordenei com outras pessoas um projeto HOT de cartografia OSM no norte e nordeste do Haiti. Naquela época, a ferramenta indispensável para a coleta de dados em campo eram os pequenos dispositivos Garmin da série Etrex, robustos e de baixo consumo de energia, mas que exigiam uma fase de edição bastante longa no computador. Eu já tinha meu primeiro smartphone Android há alguns meses e, pelo que me lembro, o OSMtracker já existia, o Vespucci talvez também (mas só o descobri mais tarde) e o OsmAnd estava em seus primórdios. No entanto, o ecossistema de aplicativos ainda não estava maduro o suficiente para substituir o eTrex. No final da missão, vi alguns participantes haitianos começarem a adquirir seus primeiros smartphones.

Alguns meses depois, naquele mesmo ano, durante outra missão de mapeamento na Mongólia, tive uma reunião com representantes do Banco Asiático de Desenvolvimento, a quem tentei convencer de todos os benefícios do OpenStreetMap. Em determinado momento, usei como argumento o surgimento desses aplicativos móveis do OSM, que em breve permitiriam a qualquer pessoa acessar os dados do OSM e contribuir para eles com facilidade, considerando que os smartphones logo estariam nas mãos de todos. Não tive a sensação de estar fazendo suposições infundadas: o celular já estava em toda parte, parecia bastante lógico que os smartphones Android, cujos modelos mais baratos começavam a chegar, também fossem fazer sucesso e aumentassem a contribuição e o uso do OSM.

Talvez meus interlocutores estivessem familiarizados apenas com iPhones, que eram bem mais caros? De qualquer forma, naquele dia eles praticamente riram na minha cara, respondendo que não, isso não iria acontecer nos próximos anos. Na hora, eu me tornei, aos olhos deles, um geek distante da realidade e o OSM, um projeto de sonhadores ingênuos.

O smartphone, principal meio de acesso ao OSM

Desde então, o GSM não morreu; sua rede ainda é amplamente utilizada e seus aparelhos continuam sendo predominantes em algumas regiões rurais do mundo, especialmente no Sul Global. No entanto, os smartphones estão muito presentes, como mostram esses relatórios da GSM Association na África, Ásia e América Latina, ou este mapa mundial que mostra um índice de conectividade móvel.

É certo que essas estatísticas parecem basear-se na parcela da população que possui conexão à internet, e é difícil estimar a parcela da população que possui um smartphone, sabendo-se que alguns telefones simples são capazes de se conectar à web ou que, em alguns países (a Costa do Marfim, por exemplo), é comum assinar planos com duas operadoras para aproveitar suas respectivas vantagens. No entanto, o smartphone é, muito à frente do computador, o dispositivo pelo qual a maioria da população mundial acessa a Internet. E, portanto, o OpenStreetMap. Desde 2013, o número de aplicativos baseados em Android aumentou e suas funcionalidades se desenvolveram, tanto no que diz respeito à edição de dados quanto ao seu uso, para atividades de navegação ou pesquisa. No entanto, elas continuam inadequadas para certos contextos e usos, especialmente no Sul Global. Como este post já está muito longo, vou abordar hoje apenas uma dessas deficiências.

Primeira deficiência atual dos aplicativos Android de navegação offline: arquivos de mapas muito grandes, especialmente para os países do Sul Global

Muitas vezes notei, durante workshops de treinamento dedicados ao uso de aplicativos como o OsmAnd ou o Organic Maps/Comaps, o quanto o mapa a ser baixado podia, às vezes, ser um arquivo grande, com mais de 100 MB, e cobrindo o país inteiro, sem poder se limitar à área administrativa do local do treinamento.

Isso é duplamente limitante em países onde a internet pode ser lenta, instável e, muitas vezes, significativamente mais cara do que no Norte, sem conexão ilimitada. Ter que pagar uma quantia nada desprezível em relação ao custo de vida para baixar, às vezes após várias tentativas, um mapa do qual se vai usar apenas 10% da área não é necessariamente motivador.

A abordagem estatística

Resolvi verificar isso analisando todos os mapas disponíveis. O OsmAnd disponibiliza esta página da web, que contém todos os mapas disponíveis, seus tamanhos e datas de atualização, mas não encontrei nada semelhante para o Organic Maps/Comaps. As estatísticas a seguir limitam-se, portanto, ao OsmAnd e datam do mês passado (um pouco de procrastinação para escrever este post), mas os resultados provavelmente seriam semelhantes para o Organic Maps/Comaps, para os quais, aliás, forneço alguns exemplos.

Os resultados são apresentados por continente. Por level_0, refiro-me aos países para os quais existe apenas um mapa de todo o território nacional (nível denominado admin0); por level_1, aqueles que também dispõem de mapas de acordo com a primeira divisão administrativa (admin1); e por level_2, os países que possuem no OsmAnd um segundo nível de divisão administrativa (admin2).

Escolhi arbitrariamente 100 MB como limite a partir do qual um mapa pode ser considerado um arquivo grande para download. As estatísticas são agrupadas por continente, com o número de países cujo tamanho do mapa a ser baixado é superior a 100 MB, para cada uma das categorias (níveis 0, 1 e 2). Para os países que possuem os níveis 1 e 2, é utilizado o valor médio do tamanho dos mapas.

A última coluna apresenta as informações de cada país em ordem decrescente de tamanho de arquivo, incluindo aqueles que têm a sorte de ficar abaixo do limite de 100 MB. Eles estão destacados em verde para facilitar a identificação. Os demais países aparecem em laranja, com tamanhos entre 100 e 200 MB, e em vermelho para aqueles com mais de 200 MB.

Os resultados

Notamos a grande desigualdade entre os países de cada continente, com alguns ultrapassando 400 MB:

• Portugal, Romênia, Grécia, Hungria, Irlanda, Eslováquia e Bélgica na Europa
• Nova Zelândia na Oceania
• Colômbia, Peru, Bolívia na América do Sul
• Nigéria, Madagascar e Quênia na África
• Tailândia, Coreia do Sul, Vietnã, Taiwan e Nepal na Ásia
• na América Central, o agrupamento de todos os países caribenhos não constitui um país em si e deve ser considerado, antes, como uma opção de download adicional. A superfície reduzida desses países faz com que nenhum deles tenha ainda um mapa sem divisão administrativa com mais de 100 MB,

Observa-se também que apenas a Europa conta com doze países com nível 1 ou mesmo 2, mas mesmo assim com mapas de tamanho médio superior a 100 MB. Isso provavelmente está relacionado à densidade dos dados OSM na Europa. Em outros lugares, apenas países imensos como a Austrália, a Rússia e o Brasil ultrapassam os 100 MB, apesar de terem nível 1.

Para todos os outros, ter que baixar um mapa com mais de 100 MB significa ter que baixar o mapa de um país inteiro. Esse é o caso de 27 países africanos e 22 países asiáticos. Na Nigéria, o maior país da África em população (e o sexto do mundo), usar o OsmAnd implica ter que baixar um mapa com mais de 600 MB, o que faz dele o país menos bem atendido pelo aplicativo. A título de informação, a situação é apenas um pouco melhor no CoMaps, onde há a opção entre Nigéria – Norte (217 MB) e Nigéria – Sul (479 MB). Na Tailândia, são mais de 500 MB para o OsmAnd e três mapas no CoMaps (o maior deles com 182 MB).

No entanto, três outros grandes países africanos estão bem servidos no OsmAnd com um nível 1 que permite reduzir drasticamente o tamanho dos mapas: a RDC, por exemplo, com uma média de 16 MB (e um máximo de 77 MB), a Tanzânia com cerca de 55 MB e a África do Sul com pouco menos de 100 MB. O mesmo ocorre na Ásia com a China, o Japão, a Índia, a Indonésia (embora algumas províncias ainda tenham mais de 200 MB) e as Filipinas, onde é possível baixar mapas de tamanho razoável.

Por que isso?

Como explicar tal desigualdade de tratamento? Por que não oferecer sistematicamente um primeiro nível de divisão para todos os países cujo mapa completo ultrapasse 100 MB — ou, como vimos, muito mais —, em vez de apenas alguns? Será isso apenas resultado da falta de demanda por parte desses países mal atendidos em termos de mapas de tamanho razoável?

O OsmAnd publicou recentemente o resultado de uma pesquisa junto à sua comunidade de usuários, distribuídos em 5 idiomas, sem que se soubesse seu país de origem. O problema do tamanho dos mapas não aparece na pesquisa, mas talvez isso se deva justamente ao fato de que isso limita o número de usuários nesses países? Seria interessante saber o número de usuários dos mapas do aplicativo para cada país, ou pelo menos o número de downloads de cada mapa.

Seja como for, esse problema do tamanho dos mapas em certos territórios constitui o principal obstáculo à adoção dessas aplicações de navegação nessas regiões e uma limitação para aqueles que, mesmo assim, decidiram utilizá-las.

Traduzido com DeepL - versão gratuita

Summary

Issue #1 when first using offline OpenStreetMap navigation apps for Android, such as OsmAnd, Comaps, and Organic Maps: the size of the map to be downloaded. In many places, it’s the entire country or nothing. And that often amounts to over 100 MB, with some cases exceeding 500 or 600 MB. Why is that?

Personal experience: the rise of smartphones in the Global South

During the summer of 2013, I coordinated an OSM mapping HOT project in northern and northeastern Haiti with others. At that time, the go-to tool for field data collection was the small, rugged, and energy-efficient Garmin Etrex series devices, though they required a fairly lengthy editing process on a computer. I had had my first Android smartphone for a few months by then, and as I recall, OSMtracker already existed, perhaps Vespucci as well (though I didn’t discover it until later), and OsmAnd was in its early stages. However, the app ecosystem wasn’t yet mature enough to replace the eTrex. At the end of the mission, I saw some Haitian participants start to get their first smartphones.

A few months later that same year, during another mapping mission in Mongolia, I had a meeting with officials from the Asian Development Bank whom I was trying to convince of all the benefits of OpenStreetMap. At one point, I used the emergence of these OSM mobile apps as an argument, noting that they would soon allow anyone to easily access and contribute to OSM data, given that smartphones would soon be in everyone’s hands. I didn’t feel like I was making wild guesses: cell phones were already everywhere, and it seemed quite logical that Android smartphones—whose affordable models were just starting to hit the market—would also be successful and boost both contributions to and use of OSM.

Perhaps my conversation partners were only familiar with the far more expensive iPhones? In any case, they practically laughed in my face that day, retorting that no, that wasn’t going to happen in a few years. Instantly, in their eyes, I had become a geek out of touch with reality, and OSM a project of dreamers.

The smartphone: the primary device for accessing OSM

That said, GSM is not dead; its network is still widely used, and its devices are sometimes still predominant in certain rural areas around the world, particularly in the Global South. Nevertheless, smartphones are very prevalent, as shown by these reports from the GSM Association in Africa, Asia and Latin America, or this world map showing a mobile connectivity index.

Admittedly, these statistics appear to be based on the proportion of the population with an internet connection, and it is difficult to estimate the proportion of the population that owns a smartphone, given that some basic phones are capable of connecting to the web or that in certain countries (Ivory Coast, for example), it is common to subscribe to two carriers to take advantage of their respective benefits.

Nevertheless, the smartphone—far ahead of the computer—is the device most people around the world use to access the Internet. And thus OpenStreetMap. Since 2013, the number of Android-based apps has grown, and their features have expanded, both in terms of data editing and consumption, for navigation and search activities. However, they remain ill-suited for certain contexts and uses, particularly in the Global South. Since this blog post is already too long, I will address only one of these shortcomings today.

The first current shortcoming of offline Android navigation apps: map files that are too large, particularly for countries in the Global South

I have often noticed, during training workshops dedicated to getting started with apps like OsmAnd or Organic Maps/Comaps, how the map to be downloaded could sometimes be a large file exceeding 100 MB, covering the entire country, without being able to be limited to the administrative area of the training location.

This is doubly problematic in countries where the internet can be slow, unstable, and is often significantly more expensive than in the Global North, with no unlimited data plans. Having to pay a sum that is significant relative to the cost of living to download—sometimes after several attempts—a map of which you will only use 10% of the area is not necessarily motivating.

The Statistical Approach

I wanted to verify this by analyzing all the available maps. OsmAnd provides this webpage, which lists all available maps along with their size and update date, but I couldn’t find an equivalent for Organic Maps/Comaps. The following statistics are therefore limited to OsmAnd and are from last month (I procrastinated a bit on writing this post), but the results would likely be similar for Organic Maps/Comaps, for which I’m also providing a few examples.

The results are shown by continent. By level_0, I mean countries for which there is only a single map covering the entire national territory (so-called admin0 level); by level_1, those that also have maps based on the first administrative division (admin1); and by level_2, countries that have a second level of demonstrative administrative division (admin2) in OsmAnd.

I arbitrarily chose 100 MB as the threshold above which a map can be considered a large file to download. The statistics are grouped by continent, showing the number of countries where the size of the map to be downloaded exceeds 100 MB, for each of the categories (levels 0, 1, and 2). For countries with levels 1 and 2, the average map size is used.

The last column lists the data for each country in descending order of file size, including those that are under the 100 MB threshold. These are highlighted in green for easy identification. The other countries are shown in orange for file sizes between 100 and 200 MB, and in red for file sizes over 200 MB.

The Results

We can see significant disparities among countries on each continent, with some exceeding 400 MB:

• Portugal, Romania, Greece, Hungary, Ireland, Slovakia, and Belgium in Europe
• New Zealand in Oceania
• Colombia, Peru, and Bolivia in South America
• Nigeria, Madagascar, and Kenya in Africa
• Thailand, South Korea, Vietnam, Taiwan, and Nepal in Asia
• In Central America, the grouping of all Caribbean countries is not a country in itself and should instead be considered an additional download option. The small size of these countries means that none yet have a map without administrative boundaries exceeding 100 MB,

We also note that only Europe has twelve countries with a Level 1 or even Level 2, yet their maps are still larger than 100 MB on average. This is likely due to the density of OSM data in Europe. Elsewhere, only vast countries like Australia, Russia, and Brazil exceed 100 MB despite being at level 1.

For everyone else, having to download a map larger than 100 MB means having to download the entire country. This applies to 27 African countries and 22 Asian countries. In Nigeria, Africa’s most populous country (and the sixth most populous in the world), using OsmAnd requires downloading a map larger than 600 MB, making it the country with the poorest coverage in the app. For reference, the situation is barely better on CoMaps, where users can choose between Nigeria – North (217 MB) and Nigeria – South (479 MB). In Thailand, the OsmAnd map is over 500 MB, and CoMaps offers three maps (the largest of which is still 182 MB).

However, three other major African countries are well-served in OsmAnd with a Level 1 setting that drastically reduces map size: the DRC, for example, with an average of 16 MB (and a maximum of 77 MB), Tanzania at around 55 MB, and South Africa just under 100 MB. The same applies in Asia with China, Japan, India, Indonesia (though some provinces are still over 200 MB), and the Philippines, where it is possible to download maps of reasonable size.

Why is that?

How can such unequal treatment be explained? Why not systematically offer a first-level map division for all countries where the map of the entire country exceeds 100 MB—or, as we’ve seen, much more—rather than just a few? Is this simply the result of a lack of demand from these underserved countries?

OsmAnd recently published the results of a survey conducted among its user community, which spans five languages, without specifying the users’ countries of origin. The issue of map size does not appear in the survey, but perhaps this is precisely because it limits the number of users in those countries? It would be interesting to know the number of users of the app’s maps for each country, or at the very least the number of downloads for each map.

In any case, this issue with map size in certain regions is the primary barrier to the adoption of these navigation apps in those areas and a constraint for those who have nevertheless decided to use them.

Translated with DeepL.com (free version)

Résumé

Problème #1 dès la première utilisation des applications Android de navigation #openstreetmap hors ligne, type OsmAnd, Comaps, Organic Maps : la taille de la carte à télécharger. Dans beaucoup d’endroits, c’est le pays entier ou rien. Et cela représente souvent plus de 100 Mo, avec des records au-delà des 500 ou 600 Mo. Pourquoi donc ?

Expérience personnelle l’émergence du smartphone dans le Sud global

Durant l’été 2013, j’ai coordonné avec d’autres personnes un projet HOT de cartographie OSM dans le nord et nord-est de Haiti. À cette époque, l’outil incontournable pour la collecte de terrain était les petits terminaux Garmin de la série Etrex, solides et peu gourmands en énergie, mais qui nécessitaient une assez longue phase d’édition sur ordinateur. J’avais alors mon premier smartphone Android depuis quelques mois, et dans mon souvenir OSMtracker existait déjà, Vespucci peut-être aussi (mais je ne l’ai découvert que plus tard) et OsmAnd en était à ses débuts. Pour autant, l’écosystème des applis n’était pas encore assez mûr pour remplacer l’eTrex. À la fin de la mission, j’ai vu certains participant-es haïtien-ne-s commencer à s’équiper de leurs premiers smartphones.

Quelques mois plus tard la même année, au cours d’une autre mission de cartographie en Mongolie, j’ai eu une réunion avec des responsables de l’Asian Development Bank que je tentais de convaincre de tous les bienfaits d’OpenStreetMap. À un moment, j’ai utilisé comme argument l’arrivée de ces applications mobiles OSM qui permettrait bientôt à tout à chacun de consommer la donnée OSM et y contribuer facilement, compte tenu que les smartphones seraient bientôt entre toutes les mains. Je n’avais pas le sentiment de faire des conjectures sur la comète : le GSM était déjà partout, il semblait assez logique que les smartphones Android, dont les modèles bon marché commençaient à arriver, allaient aussi avoir du succès, et augmenter la contribution et l’usage d’OSM.

Peut-être mes interlocuteurs n’étaient-ils familiers qu’avec des iPhone autrement plus coûteux ? En tout cas, ils m’ont ce jour-là pratiquement ri au nez, me rétorquant que non, cela n’allait pas arriver en quelques années. Illico, j’étais devenu à leurs yeux un geek loin de la réalité et OSM un projet de doux rêveurs.

Le smartphone, principal moyen d’accès à OSM

Depuis, le GSM n’est pas mort, son réseau est encore largement utilisé et ses terminaux sont parfois encore prépondérants dans certaines régions rurales de par le monde, notamment dans le Sud global. Pour autant les smartphones sont très présents, comme le montrent ces rapports de la GSM Association en Afrique, Asie et Amérique latine, ou cette carte mondiale affichant un index de la connectivité mobile.

Certes, ces statistiques semblent établies sur la part de la population possédant une connexion internet, et il est difficile d’en estimer la part de la population qui dispose d’un smartphone, sachant que certains téléphones simples sont capables de se connecter au web ou que dans certains pays (la Côte d’Ivoire, par exemple), il est courant de souscrire à deux opérateurs pour profiter de leurs avantages respectifs.

Néanmoins, le smartphone est, loin devant l’ordinateur, le terminal avec lequel la majorité de la population mondiale accède à Internet. Et donc à OpenStreetMap. Depuis 2013, le nombre d’applications basées sur Android s’est accru et leurs fonctionnalités se sont développées, tant pour la partie édition de données que pour leur consommation, pour des activités de navigation ou de recherche. Cependant, elles restent inadaptées à certains contextes et usages, notamment pour le Sud global. Ce billet de blog étant déjà trop long, je ne vais couvrir aujourd’hui qu’un seul de ces défauts.

Premier défaut actuels des app Android de naivigation hors lignes : des fichiers de cartes trop gros, en particulier pour les pays du Sud global

J’ai souvent remarqué, lors d’ateliers de formation dédiés à la prise en main d’applications comme OsmAnd ou Organic Maps/Comaps, combien la carte à télécharger pouvait parfois être un gros fichier supérieur à 100 Mo, et couvrant le pays en entier, sans pouvoir se limiter à la zone administrative du lieu de formation.

C’est doublement contraignant dans des pays ou l’internet peut être lent, instable et est souvent nettement plus cher qu’au Nord, sans connexion illimitée. Devoir payer une somme qui est non négligeable rapportée au coût de la vie pour télécharger, parfois après plusieurs essais, une carte dont on ne va utiliser que 10 % de la surface n’est pas forcément motivant.

L’approche statistique

J’ai voulu vérifier cela en analysant toutes les cartes disponibles. OsmAnd propose cette page web qui contient l’ensemble des cartes disponibles, leur taille et date de mise à jour, mais je n’ai pas trouvé l’équivalent pour Organic Maps/Comaps. Les statistiques qui suivent se limitent donc à OsmAnd et datent du mois dernier (légère procrastination pour rédiger ce billet), mais les résultats seraient probablement proches pour Organic Maps/Comaps, pour lesquels je fournis d’ailleurs quelques exemples.

Les résultats sont montrés par continent. Par level_0, j’entends les pays pour lesquels il n’y a qu’une carte du territoire national entier (niveau dit admin0), par level_1, ceux qui bénéficient aussi de cartes selon le premier découpage administratif (admin1) et par level_2, les pays qui disposent dans OsmAnd d’un deuxième niveau de découpage démonstratif (admin2).

J’ai choisi arbitrairement 100 Mo comme seuil au-delà duquel on peut considérer une carte comme un gros fichier à télécharger. Les statistiques sont réunies par continent, avec le nombre de pays dont la taille de la carte à télécharger est supérieure à 100 Mo, pour chacune des catégories (levels 0, 1 et 2). Pour les pays qui ont des levels 1 et 2, c’est la valeur moyenne de la taille des cartes qui est utilisée.

La dernière colonne donne l’information pour chaque pays en ordre décroissant de taille de fichier, y compris ceux qui ont la chance d’être en dessous du seuil de 100 Mo. Ils sont colorés en vert pour mieux les distinguer. Les autres pays sont en orange entre 100 et 200 Mo, et en rouge au-delà de 200 Mo.

Les résultats

On remarque la grande inégalité entre les pays de chaque continent, avec certains au-delà de 400 Mo :

• Portugal, Roumanie, Grèce, Hongrie, Irlande, Slovaquie et Belgique en Europe
• Nouvelle-Zélande en Océanie
• Colombie, Pérou, Bolivie en Amérique du Sud
• Nigeria, Madagascar et Kenya en Afrique
• Thaïlande, Corée du Sud, Vietnam, Taïwan et Népal en Asie
• en Amérique centrale, le regroupement de tous les pays caribéens n’est pas un pays en soi et doit plutôt être considéré comme une option de téléchargement en plus. La surface réduite de ces pays fait qu’aucun n’a encore de carte sans découpage administratif au-delà de 100 Mo,

On remarque aussi que seule l’Europe compte douze pays avec un level 1 voire 2, mais néanmoins des cartes de tailles moyenne supérieure à 100 Mo. C’est probablement lié à la densité des données OSM en Europe. Ailleurs, seuls des pays immenses comme l’Australie, la Russie et le Brésil dépassent les 100 Mo malgré un level 1.

Pour tous les autres, devoir télécharger une carte de plus de 100 Mo est synonyme de devoir télécharger le pays entier. 27 pays africains et 22 pays asiatiques sont dans ce cas. Au Nigeria, plus grand pays d’Afrique par sa population (et le sixième au monde), utiliser OsmAnd implique de devoir télécharger une carte de plus de 600 Mo, ce qui fait de lui le pays moins bien servi par l’application. Pour information, c’est à peine mieux sur CoMaps où il y a le choix entre Nigeria – Nord (217 Mo) et Nigeria – Sud (479 Mo). En Thaïlande, plus de 500 Mo pour OsmAnd et trois cartes dans CoMaps (la plus grande faisant quand même 182 Mo).

Cependant, trois autres grands pays africains sont bien lotis dans OsmAnd avec un level 1 qui permet de diminuer drastiquement la taille des cartes : le RDC par exemple avec une moyenne de 16 Mo (et un maximum de 77 Mo), la Tanzanie autour de 55 Mo et l’Afrique du Sud légèrement sous 100 Mo. Idem en Asie avec la Chine, le Japon, l’Inde, l’Indonésie (mais dont certaines provinces font encore plus de 200 Mo) et les Philippines, où il est possible de télécharger des cartes de taille raisonnable.

Pourquoi donc ?

Comment expliquer une telle inégalité de traitement ? Pourquoi ne pas systématiquement proposer un premier niveau de découpage pour tous les pays dont la carte du pays entier dépasse 100 Mo voire, comme on l’a vu, beaucoup plus, et non quelques-uns ? Cela est-il juste le résultat de l’absence de demande émanant de ces pays mal desservis en cartes de taille raisonnable ?

OsmAnd avait publié récemment le résultat d’un sondage auprès de sa communauté d’utilisateurs, répartis en 5 langues, sans que leur pays d’origine soit connu. Le problème de la taille des cartes n’y apparaît pas, mais peut-être que est-ce justement dû au fait qu’il limite le nombre d’utilisateurs dans ces pays ? Il serait intéressant de connaître le nombre d’utilisateurs des cartes de l’application pour chaque pays, ou à tout le moins le nombre de téléchargement de chaque carte.

Quoi qu’il en soit, ce problème de la taille des cartes sur certains territoires constitue le premier frein à l’adoption de ces applications de navigation sur certains territoires et une contrainte pour celles et ceux qui ont quand même décidé de les utiliser.

30x30 (https://en.wikipedia.org/wiki/30_by_30) is a global initiative proposed in the Kunming-Montreal Global Biodiversity Framework to conserve 30% of the area represented by Earth’s land, water and oceans. This goal has been adopted by many countries and non-governmental organizations, including The Nature Conservancy and the United States in the Biden administration’s Executive Order 14008 (Section 216) later a key element in the launch of the America the Beautiful initiative in 2022.

OpenStreetMap has adopted International Union for Conservation of Nature standards for describing protected areas, including parks, nature reserves, and other lands. As a free, open-source, community-driven and collaborative geographic feature database, OpenStreetMap is a useful tool for assessing progress towards this goal. Continual updates, world-wide coverage, native-language support and a robust open data working group governance structure; OSM is perhaps the best “live” tracker towards accomplishing this goal.

En resumen: Con panoramax.libre.net.ar hemos configurado la primera instancia (pública) de Panoramax en América. Permite la recopilación de imágenes a nivel de calle en territorio argentino.

An English version is available on my website

Panoramax es un sistema de código abierto para crear un repositorio común de imágenes a nivel de calle, ofreciendo así una alternativa con licencia abierta a Google Street View, etc. A diferencia de otras alternativas que licencian las imágenes de forma abierta, todo el software es libre y de código abierto. Además, se basa en la idea de crear una federación de servidores o instancias de Panoramax, similar al Fediverso de Mastodon, PeerTube, Lemmy, etc.

Desde la primera vez que publiqué sobre Panoramax, la federación ha crecido considerablemente, superando las 10 instancias. Pero, cal igual que (lamentablemente) en la mayoría de los sistemas federados, todavía existe una fuerte centralización en cuanto al uso. Las instancias del capítulo francés de OpenStreetMap (OSM FR) y del Instituto Geográfico Nacional de Francia reúnen alrededor del 97 % de todas las imágenes hasta la fecha. En el caso de la instancia de OSM FR, esto se debe en parte a que, hasta ahora, era la única instancia grande que permitía subir imágenes de cualquier lugar del mundo, en lugar de restringir geográficamente las subidas a una región o país.

Para Panoramax, esta centralización no solo es problemática en lo que respecta a la capacidad de trabajar en contextos locales o la resiliencia de la federación, sino también para la sostenibilidad de esas instancias individuales por motivos de almacenamiento: Almacenar millones de imágenes a nivel de calle de alta resolución consume muchísimo espacio. En el caso de la instancia de OSM FR, los aproximadamente 51 millones de imágenes ocupan 120 TB para las imágenes originales y otros 66 TB para las imágenes derivadas necesarias para su visualización y distribución eficientes.

Por ello, hace un par de semanas, Christian Quest publicó en el foro de la comunidad de OSM que la instancia de OSM FR se estaba quedando sin espacio. También comentó que aproximadamente la mitad de esas imágenes provienen de fuera de Francia, lo que contribuye a que la situación actual no sea sostenible a largo plazo. Por esta razón, es muy probable que no sea posible subir imágenes desde el extranjero en el futuro. Como usuario que subió bastantes imágenes desde Argentina, sin duda contribuí a este problema, lo que implicó acelerar la puesta en marcha de una instancia local.

Panoramax en el contexto argentino

No contar con una instancia local no se debió necesariamente a falta de intentos, sino a varios factores que representan barreras adicionales: El primero, y quizás el más importante, es el elevado costo del hardware. La electrónica en general es extremadamente cara en Argentina. No solo en términos relativos, comparado con los salarios locales, sino también en términos absolutos, incluso sin tener en cuenta el aumento de precios derivado de la IA, debido a los aranceles y tasas de importación. Esto significa que el hardware suele utilizarse hasta que se avería, lo que implica que el mercado de hardware usado no es muy amplio y que, además, los precios del hardware usado aquí suelen ser más altos que los que se pagarían por uno nuevo en lugares como la UE o Estados Unidos. Por lo tanto, las posibilidades de obtener donaciones de hardware, con las que otros lugares sí tienen suerte para un proyecto de este tipo, son bastante escasas, especialmente si se parte de cero.

Al mismo tiempo, las instituciones públicas como universidades o municipios, que en otros lugares podrían ser socios naturales para una iniciativa así, aunque potencialmente interesadas, carecen de los recursos necesarios para ayudar: Todas están sufriendo pérdidas económicas debido al recorte intencional de fondos del gobierno nacional a todos los servicios públicos. Si lee algo de alemán (o está dispuesto a usar la traducción automática), puede leer mi reportaje sobre este tema en Amerika21; de lo contrario, cualquier medio de comunicación con cobertura internacional debería ser útil.

La otra alternativa para poner en marcha una instancia de Panoramax, que parece ser utilizada por otras instancias más pequeñas, es el autoalojamiento en casa. Pero, más allá de la disponibilidad de hardware, incluso eso puede resultar complicado debido a las limitaciones de infraestructura. Sobre todo en entornos rurales como el mío: Además de los cortes de luz habituales, que un SAI (sistema de alimentación ininterrumpida) podría mitigar, los proveedores locales de internet suelen ofrecer velocidades muy bajas. Por ejemplo, en el pueblo donde vivo la cooperativa local —que gestiona los servicios públicos, incluidas las conexiones a internet— ofrece velocidades aDSL lentas, y se prevé que la fibra óptica llegue a algunos barrios en algún momento del próximo año. Eso significaría que usar una instancia de Panoramax sería como intentar ver imágenes HD a través de una pajita.

Todos estos factores llevaron a que —a pesar de intentarlo intermitentemente desde finales de 2024, con distinta intensidad—, hasta ahora no se había logrado crear ninguna instancia local. Pero con el cambio a la instancia de OSM FR, que generó la urgencia necesaria, era hora de dejar de buscar soluciones “perfectas” y, en cambio, enfocarnos en crear algo. Y aunque Argentina sea un país enorme, ¿quizás no se necesiten cientos de terabytes para empezar? Por un lado, la red de carreteras actual parece ser sólo aproximadamente una cuarta parte de la de Francia. Y además, el número de colaboradores locales que suben imágenes, al menos según las estimaciones de la instancia de OSM FR, es bastante manejable.

Elección de configuración y creación de una instancia

En base a esto, me pregunté si no sería posible alquilar un servidor dedicado pequeño en algún lugar, simplemente para empezar. Dados los costos de hardware (ver arriba), debía ser un proveedor de alojamiento fuera del país, ya que las opciones locales también son bastante caras. Lo cual no es ideal en cuanto a latencia, pero por el momento no se puede ser exigente. Así que comencé a intercambiar ideas de forma más concreta con Daniel y Marcos sobre las opciones y cómo podríamos configurar una instancia.

Para aprovechar su amplia experiencia de primera mano con el alojamiento de Panoramax, contacté con Christian Quest, quien me indicó que el proveedor francés OVH ofrece un servidor dedicado a un precio bastante asequible de 26,60 USD al mes, que incluye cuatro discos duros de 4 TB configurables en RAID por software y un SSD de 500 GB para almacenar la base de datos, etc. En una configuración RAID 5, esto proporcionaría 12 TB de almacenamiento útil para las imágenes (o 16 TB, pagando un poco más por la opción de cuatro discos de 6 TB), y el resto de las especificaciones serían suficientes para ejecutar una instancia. Al menos, siempre que se utilice el servicio de blurring que OSM FR ofrece como servicio, ya que el tipo de máquina sugerido no cuenta con una GPU dedicada. En la configuración de 16 TB, esto debería ser suficiente para almacenar alrededor de 4 millones de imágenes, suponiendo la misma combinación de fuentes y calidades de imagen que almacena OSM FR.

Según nuestros cálculos eso duraría al menos un año, ya que hasta ahora se han subido alrededor de 830.000 imágenes tomadas en Argentina a la instancia de OSM FR en los últimos dos años. Así que decidimos probarlo para empezar y, con suerte, crear una demo convincente. Esto, a su vez, esperamos que nos ayude a entablar conversaciones más específicas para obtener soporte en el futuro.

Una vez decidido el tipo de alojamiento, la configuración inicial no fue demasiado complicada: El equipo de Panoramax creó una excelente documentación sobre el despliegue con docker compose y el uso de OSM a través de OAuth como proveedor de inicio de sesión. Y nos beneficiamos aún más del detallado informe de Matija Nalis, quien recientemente había desplegado la instancia Panoramax de OSM Croacia, lo que nos permitió completar el 99% del despliegue (para la única excepción, consulte los detalles a continuación).

Así pues, desplegamos nuestra instancia Panoramax en. Hasta donde sabemos, esta no solo es la primera instancia en Latinoamérica, ¡sino en todo el continente americano! ¹ Actualmente está configurada para aceptar imágenes tomadas en Argentina y Uruguay, pero si alguien en países vecinos necesita espacio, podemos ver qué podemos hacer; ¡contáctenos!

En general, fue mucho más fácil e incluso más económico de lo que esperaba. Espero que esto motive a otros a intentarlo también. Panoramax sólo puede funcionar a mayor escala si más personas implementan instancias locales. Quizás no a nivel nacional, pero sí a nivel regional o municipal, lo que reduciría las necesidades de almacenamiento y, por lo tanto, los costos.

En cuanto al esfuerzo administrativo y la experiencia necesaria: Cada vez hay más personas con experiencia en la administración de servidores Panoramax, y por lo que he visto, todos están encantados de ayudar. Dicho esto, contar con un pequeño equipo dispuesto a colaborar es genial, tanto para obtener segundas opiniones y facilitar la gestión del tráfico, como para convertirlo en un esfuerzo colectivo. En nuestra pequeña instancia, esto incluye no solo a Marcos y Dani, sino también a Lucas, quien se ofreció a compartir su experiencia en administración de servidores al enterarse de nuestra idea.

Apéndice: Configuración del RAID por software

Lo único que faltaba en la descripción detallada de la instancia OSM-HR era cómo configurar el RAID por software. La configuración del servidor OVH viene sin ningún disco duro configurado, ya que solo formatea la unidad SSD. Pero, por suerte, no fue muy difícil investigar. Para quienes deseen reproducir este proceso, los pasos se encuentran a continuación.

Para configurar los 4 discos duros como un RAID 5, también utilizamos LVM, de forma similar a la descripción para OSM-HR. Para preparar los discos duros, primero creamos los volúmenes físicos:

pvcreate /dev/sda pvcreate /dev/sdb pvcreate /dev/sdc pvcreate /dev/sdd

Luego creamos el grupo de volúmenes vg1 ejecutando vgcreate vg1 /dev/sda /dev/sdb /dev/sdc /dev/sdd

Finalmente, creamos el volumen lógico (LV): lvcreate -n panoramax-photos --type raid5 -i 3 -l 100%VG vg1

Los parámetros son:

```

-n: nombre del volumen –type raid5: tipo de RAID -i: usar 3 dispositivos de los 4 (para redundancia de un solo disco) -l 100%VG: usar el 100% del grupo de volúmenes ```

Como resultado, Obtenido:

root@panoramax-ar:~# lvscan ACTIVE '/dev/vg1/panoramax-photos' [16.37 TiB] inherit

A partir de ahí, el resto de las instrucciones de OSM HR te llevarán allí.

1. Al menos la primera instancia pública visible y accesible que busca federarse; por supuesto, podría haber instancias alojadas de forma privada. ↩

OSM 中肯德基餐厅会用到的网站标签主要有website、website:menu、website:orders和brand:website（operator:website或许也可以写一下，但我没研究。）。

• brand:website很简单，统一brand:website=https://www.kfc.com.cn即可。

其它 URL 都需要先获取一下storeCode。

1. 打开 https://order.kfc.com.cn
2. 找到目标餐厅
3. 在 URL 中查询参数部份找到storeCode，记下其值
   https://order.kfc.com.cn/preorder-taro/portals/pages/store/index/index?storeCode=BJN001（不一定是与示例相同的路径，能找到storeCode这个查询参数就可以。）

• website可以是website=https://order.kfc.com.cn/?storeCode={storeCode}&pageName=@/kfc/portals/store/index（{storeCode}替换为上文中记录的值。），该网页用于展示餐厅信息。
• website:menu与website:orders相同，可以是https://order.kfc.com.cn/preorder-taro/portals/pages/store/index/index?storeCode={storeCode}（{storeCode}替换为上文中记录的值。），该网页用于订餐。

示例：5518766365

以上标签写法仅为个人想法，未经社群讨论，若有异见希望可以讨论一下。

07/05/2026-13/05/2026

Mapping

• Comments are requested on this proposal:
  • data_center:tier, data_center:total_power, data_center:IT_power, data_center:IT_area, proposed by LunaLune, to extend telecom=data_center features with standardised technical attributes such as redundancy tier, total power capacity, IT load (or the maximum electrical power available for IT equipment, as servers, storage, networking), and usable IT area (or the total floor area exclusively used for IT equipment).
• ‘Aerodrome Descriptive Tags’, proposed by Telegram Sam, is up for vote until Tuesday 26 May, which aims to add descriptive tags for aerodrome=* and better describe these features. It proposes distinct tags for type, usage, access, sport, and international traffic, as well as dedicated values for airstrip, heliport, and seaplane_base.

Community

• In a video Anne-Karoline Distel showed which objects hikers can add to OpenStreetMap, while on the trail, using OsmAnd. Examples include benches, route markers, viewpoints, shelters, fords, and safety-related facilities.
• Raquel Dezidério Souto published, on her OSM user diary, about her participation as a special speaker at an event organised by the Pedagogical University of Maputo (Mozambique), which discussed changes to the country’s environmental law. During the event, she took the opportunity to highlight the importance of open data and the use of open collaborative mapping platforms, with a special focus on OpenStreetMap. A copy of the special keynote entitled ‘Development and Conservation’ is available on Zenodo.org.
• 9tab wrote about some addr:place inconsistencies on the OpenStreetMap Wiki. Use of the addr:place key can differ from the (contradictory) descriptions in the Wiki, notably in relation to the addr:street key.
• A new two-year comparative study in Denmark demonstrates that the Danish OSM community produces geodata roughly nine times more efficiently than the government-led GeoFA project ►. Based on a two-year tracking of 38 distinct outdoor and cultural data categories, OSM Denmark maintains a significant lead, accounting for over 145,000 recorded items.
• In their latest OpenStreetMap interview series, OpenCage spoke with Volker Krause about Transitous, an open platform for public transport routing.
• The MapComplete project reported that more than 20,000 changesets have been created with the tool in 2026 so far. At the same time, the panoramax=* key has surpassed 100,000 uses in OpenStreetMap, most of them added via MapComplete and linking to content in the Panoramax ecosystem.
• As reported by Ivan Branco on the OpenStreetMap Community forum, on 1 May, the twelfth issue of mensileOSM , the Italian-language monthly newsletter for Italy’s OpenStreetMap community was published. This issue also marks the project’s first anniversary.
• Thomas D. has started a discussion on the OpenStreetMap Community forum about possible collaboration between the OpenStreetMap community and the organisation Open Lunar Foundation on an open-source Moon map. The initiative is motivated by renewed lunar activity and existing ideas around collaborative mapping of the Moon.
• OpenStreetMap US is collaborating with the Environmental Policy Innovation Center on OpenWetlandsMap, an open dataset of wetlands in the United States. The project aims to complement outdated and fragmented data with up-to-date, community-driven OSM mapping to support conservation and decision-making.
• Using Altilunium Locationpad, rphyrin has created some maps representing the 2018 journey of a Hajj pilgrim group, tracing the pilgrims’ route from departure to completion.
• Andy Townsend explores what the lifecycle tag disused=yes in OpenStreetMap actually means.

Local chapter news

• OpenStreetMap US has welcomed the Yesterdays as a new Charter Project. The platform enables volunteers to georeference historical photographs and collaboratively map past cityscapes using OpenStreetMap and historical sources. The project began in Richmond, Virginia, where the Charter Project Advisory Committee is based.

Events

• The OpenStreetMap Foundation has made a call for bids to host the 2027 State of the Map conference. Applications are open until Sunday 19 July, with the selected host to be announced during SotM 2026 in Paris.

Education

• The 2026 ‘OpenStreetMap Workshop Series’, organised by IVIDES DATA (Brazil), has kicked off with participants from Portuguese-speaking countries Brazil, Mozambique, and Angola. The organisers have made available a PDF copy (in Portuguese) and a link to the presentation video, as well as the uMap showing the home cities of the participants.

Maps

• David Smith recounted his six-year-long journey designing the OSM-based map in Pedometer++, a walking tracker for Apple watchOS, built with help from Andy Allan.
• Transform Transport has published an interactive ’15 Minute City Score’ map analysing access to essential services across European cities. The analysis uses OpenStreetMap data for pedestrian networks and amenities, applying consistent spatial methods for comparability.
• Using the OSM-ALKIS address comparison web app, Alex Spritze analysed the distribution of missing address data across Saxony-Anhalt. The results highlighted significant disparities between municipalities, ranging from high-performing areas such as Ingersleben, which has ‘only’ nine missing addresses, to municipalities like Güsten, where just 3.8% of addresses are currently mapped in OpenStreetMap.

OSM in action

• The Syrian Ministry of Tourism has developed the Syrian Tourist Map, a web map based on OpenStreetMap data that shows the locations of attractions, tourist facilities, and investment opportunities in Syria.

Software

• HeiGIT presented its new Traffic Emissions tool in the Climate Action Navigator that combines OpenStreetMap road data and machine learning to map road traffic-related CO₂ emissions and air pollutants at street level across Germany, helping cities better understand where climate action is most urgently needed.
• Grid2Poster is a new open source tool that renders electrical transmission networks from OpenStreetMap data as print-ready posters. This Python-based project uses GeoPandas, OSMnx, and Matplotlib, and supports country, regional, and continent-scale maps with transmission lines, cables, and optional administrative boundaries. The project is heavily inspired and reused styling from maptoposter.
• Tobias Jordans has released Grenzabgleich, a web tool comparing OpenStreetMap administrative boundaries with official datasets in Germany. It calculates metrics such as IoU and Hausdorff distances to highlight discrepancies and help mappers prioritise review and improve boundary data quality.
• The OpenStreetMap-based project CoMaps reported major technical updates, including migration to Swift and Material 3 and automated map generation. The goal was improved maintainability, performance, and long-term sustainability for the app.
• CoMaps celebrated its first birthday and the team has looked back on its growing community, big new features and what comes next.
• HeiGIT presented the new user statistics available in ohsomeNOW, giving OpenStreetMap users deeper insights into contributor activity histories and supporting the analysis of organised editing patterns.
• The OpenStreetMap Operations Team has heavily rate-limited QGIS’s access to tile.openstreetmap.org after bulk tile usage risked disrupting the service for other users. The OSM and QGIS teams are working on ways to separate bulk downloads from normal interactive usage. OpenStreetMap is also seeking donated servers to expand tile rendering capacity.
• Sean Carapella has launched PaddleMap, a routing and mapping tool for watercraft built on BRouter and brouter-web. It supports routing along waterways and portages and highlights paddling-related POIs such as access points, dams, and rapids.
• Trailmaps.app is a new web project that turns OpenStreetMap data into mobile-friendly offline maps of mountain bike trail networks. These maps are designed to match local trail signage instead of generic difficulty colouring, and the related map generator has been published as open source. According to the developer, the entire project was largely created with the help of Claude AI.
• A new userscript now allows users to add multiple custom background layers to iD. Instead of switching a single custom URL repeatedly, mappers can now easily toggle between several tile sources.
• Manny Fred has introduced HydrantMap, a new web project created by Fabian Flodman to visualise and maintain hydrant data from OpenStreetMap. The platform was inspired by the idea of OsmHydrant, focusing on up-to-date data, mobile usability, and a maintainable, modern technical foundation.

Programming

• darkonus invited JOSM users to test their ‘Fillet Tools’, a plugin that can round way corners, similar to the fillet tool in CAD software. The author is seeking feedback, bug reports, cases of unusual behaviour, and suggestions. The plugin can be installed manually from the version 0.1.0 release on GitLab.
• Matija Nalis shared his experience of setting up a Panoramax instance for OSM-HR, including hardware, Docker setup, and OSM OAuth2 integration. His report provides practical insights into deployment, operation, and challenges of hosting image infrastructure.
• Christian Quest has shared concrete figures on the memory requirements for a Panoramax instance on the Forum GéoCommuns. The analysis shows that 360° images in particular significantly increase the demand and memory optimisations are planned.
• The OpenStreetMap Operations Working Group has updated the Nominatim usage policy. The changes further restrict automated usage and introduce initial guidelines for AI applications and ‘vibe coding’. Reselling geocoding results from Nominatim is now prohibited.

Releases

• Nico Isenbeck’s onroutemap.de underwent some improvements in March and April:
  • March: The software was made available in French and Spanish and personal favourites can now be exported as KML and GPX.
  • April: The addition of a real-time wind gust layer on the map with current gust (Open-Meteo) speed and direction, colour-coded according to the Beaufort Scale. The most important new feature, however, was the migration from Overpass to PostGIS, resulting in much better map generation performance.
• Marcus Jaschen hinted at several new updates for bikerouter.de coming in version 2026.11.
• Martin Raifer tooted about the release of iD 2.40, which introduces a new style for shared bicycle and pedestrian paths and dynamic detail levels for circular features. The update also changes preset handling, automatically removing tags that are not valid for the newly selected preset.
• The OsmAnd team has released version 1.03 of OsmAnd Web. New features include Garmin Connect integration for automatic activity syncing, ‘Smart Folders’ for tracks, improved POI information, and redesigned tools for managing and displaying GPX tracks and favourites.
• The OSRM project has released version 26.5.0 of osrm-backend. This release added Python bindings to the main repository, migrated the build system to vcpkg, reduced Boost dependencies, added support for winter_road and ice_road in routing profiles, along with many other improvements.
• Project OSRM tooted that they are experimenting with an isochrone endpoint. The feature has not yet been released but could in future support reachability analysis based on OSRM routing.
• Martijn van Exel has released version 0.8.2 of his Python Overpass library. This update now requires applications to set a user-agent header, helping to protect the Overpass API from problematic requests.
• CoMaps released version 2026.05.06. From this version onward map versions will no longer be hard-tied to an app version, allowing users to update their maps without first having to update the app. This will allow for an increased update frequency for maps, which will now be weekly.
• The Organic Maps team has released version 2026.05.08-4, which now allows you to view public transport routes at stops on a map. It also includes updated OpenStreetMap data, improved elevation charts, optimised map downloads, and many other improvements. You can read the detailed announcement on their blog.

Did you know that …

• … there is a browser extension that adds an ‘Edit Tags’ button to every object on osm.org?

OSM in the media

• CHIP has published a commentary describing ► OpenStreetMap as much more useful than Google Maps when looking for nearby places in an unfamiliar area. The article says OSM shows more detail about shops, places, and amenities, while Google Maps leaves visible gaps in the example used.

Other “geo” things

• Caleb Robinson and Isaac Corley have blogged about using a Gaussian splat approach to sharpen images from Sentinel-2. The method works by using the slight variation in the location of pixels between the different passes of the satellite to extract more information from the images.
• The Ordnance Survey and GeoPlace have demanded the removal of millions of openly published UK council tax address records, claiming intellectual property rights on behalf of the Ordnance Survey, GeoPlace, and the Royal Mail. The affected datasets had previously been released under open licences by 57 local authorities.
• The latest Garmin TopoActive Europe 2026.10 map update, based on OpenStreetMap data, is causing serious routing issues on multiple devices, including crashes ► and boot loops. Several Edge models are affected; as a workaround, Garmin currently recommends downgrading to an earlier map version.

Upcoming Events

Country	Where	Venue	What	When
			OSMF Engineering Working Group meeting	2026-05-15
		Acireale	Mappiamo le Aci	2026-05-16 – 2026-05-17
	New York	East River Park at Corlears Hook	NYC Mapper Picnic	2026-05-17
	Chennai Corporation	Hotel Nithya Amirtham, Mylapore Market, Chennai	Mapping at Mylapore Market, Chennai	2026-05-17
	Bologna	aula 0.6, DICAM, Unibo, Viale del Risorgimento 2	Unibo Mapathon OpenStreetMap 2026-05	2026-05-18
	Mannheim	RaumZeitLabor, Mannheim	Rhein-Neckar OpenstreetMap Treffen	2026-05-18
			Webinaire de sensibilisation à OpenStreetMap pour les collectivités	2026-05-19
			Missing Maps London Mid-Month (Without Training) Advanced Mappers [eng]	2026-05-19
	Greater London	Médecins Sans Frontières (MSF UK) Office	Missing Maps London In-Person Mapathon	2026-05-19
	Lyon	Tubà	Réunion du groupe local de Lyon	2026-05-19
	Bonn	Dotty’s	200. OSM-Stammtisch Bonn	2026-05-19
	Chemnitz	Kaffeesatz, Chemnitz	OSM-Stammtisch Chemnitz	2026-05-19
		Online	Lüneburger Mappertreffen (online)	2026-05-19
		MJC de Vienne	Rencontre des contributeurs de Vienne (38)	2026-05-20
			Online Missing Maps Mapathon ÄRZTE OHNE GRENZEN (AT/DE)	2026-05-20
	Karlsruhe	Chiang Mai	Stammtisch Karlsruhe	2026-05-20
		[online]	Capacitação OSM 2026 – IVIDES DATA ® – Editor iD – Parte II	2026-05-22
	Metz	l’Arob@se	Atelier du groupe local de Metz – Cartographions les services publics !	2026-05-23
	Ferrara	Ferrara	Raccolta dati aree verdi @ Giornata Mondiale della Biodiversità 2026 – Citizen Science Ferrara	2026-05-23
	Navi Mumbai		OSM Mumbai Mapping Party No.10 (Trans-Harbour Line – North)	2026-05-23
	Bologna	Velostazione ExDynamo	Compleanno di Wikipedia a Bologna 2026, con wikigita e mapping party in Bolognina e pranzo alla velostazione	2026-05-24
			Missing Maps : Mapathon en ligne – CartONG [fr]	2026-05-25
	Lyon	Tubà	Réunion du groupe local de Lyon	2026-05-26
	Berlin	Online	OSM-Verkehrswende #75	2026-05-26
	Düsseldorf	Online bei https://meet.jit.si/OSM-DUS-2026	Düsseldorfer OpenStreetMap-Treffen (online)	2026-05-27
	Würzburg	FabLab Würzburg	Würzburger OSM-Treffen	2026-05-27
			OSMF Engineering Working Group meeting	2026-05-29
	Bad Harzburg	Bad Harzburg	Braunschweiger OSM-Treffen Mappingtour: Zusammen Bad Harzburg mappen	2026-05-30

Note:
If you like to see your event here, please put it into the OSM calendar. Only data which is there, will appear in weeklyOSM.

This weeklyOSM was produced by Bastian Greshake Tzovaras, MarcoR, Matheus Magalhães, Raquel IVIDES DATA, Strubbl, Andrew Davidson, TrickyFoxy, andygol, barefootstache, derFred, izen57, mcliquid.
We welcome link suggestions for the next issue via this form and look forward to your contributions.

Over the last few weeks I’ve improved the way that paths and tracks are shown on map.atownsend.org.uk in both the raster and vector versions. The aims were:

1. Improve clarity, so that their visibility in e.g. nondescript woodland was better
2. Improve consistency, so that the display of them on vector and raster looked similar to each other, and the “visual weight” of each class broadly matched when looked at together on a map.
3. Reduce confusion so that two different things were not shown in similar ways.
4. Show “good quality” paths and tracks (e.g. paved and compacted gravel surfaces) differently to other ones to help answer the “will it be muddy” question.

First, a bit of background: England and Wales don’t have a general right of land access like “allemansrätten” in Sweden or the Scottish Outdoor Access Code in Scotland. It does have a series of rights of way, which are recorded in OSM with the designation tag. Knowing this is key to knowing where you can and can’t go, and what you can and can’t do there. Maps of England and Wales often show these different access rights in different colours. OpenStreetMap’s tag names footway and bridleway were also influenced by the names of these legal access rights.

The map schema that I use defines classes its “transportation” layer as follows:

• Public roads (motorway through unclassified and residential) that broadly match OSM’s tagging
• Other rights of way (“unclassified county roads”** through footway). The designation tag in OSM used to determine what goes where.
• Other ways where there may be access, but no right of way (service, paths and tracks with no designation)
• Other oddities also not generally part of any routing graph like gallop, leisuretrack, raceway, construction.

Secondly, there are a limited number of ways that you can use to help users tell between similar things (such as linear paths) on a map:

• colour
• width of line
• dashes and dots in the line

Consistency was improved just by going through each of the visual elements in the vector and raster styles and handle them all in a common vector or raster way. The technologies are very different - Mapnik (raster) and MapLibre (vector) do have different approaches, so there are still style differences between maps, but I’ve done what I can without a ground-up rewrite of the raster maps based on the vector approach (for which life is just too short). A glance at Cannock Chase in vector and raster shows a big improvement on what went before.

In order to address the first aim (clarity) and the third (reduce confusion) I made all the path representations that I use slightly wider, and made them all out of slightly longer dashes and used dashes rather than dots. The latter was important to avoid clashing with disused rail on raster.

Previously I’d shown restricted byways the same colour as bridleways but with a different dash pattern. I changed this to a new colour half-way between “bridleway blue” and “BOAT / UCR brown”. This improves consistency and frees up “different dash patterns” to be used for better-surfaced paths and tracks.

Finally, in order to be able to show “good quality” paths and tracks differently to “normal” (potentially muddy) ones I used a slightly different dash array, consistently across each path and track type:

“Normal” paths and tracks have dashes all the same length (but wider paths and tracks have longer dashes than narrower ones). “Good Quality” ones have alternating normal and longer-length dashes. At the location of the picture at the top of this post (here in OSM) you can see a restricted byway running north-south and a bridleway running east-west. The southern part of the restricted (wide) byway and the western part of the (narrow) bridleway are both better quality (both surface=compacted in OSM). You can use the vector debugger to investigate further.

You’ll also notice from the raster legend that some paths, footways and bridleways can also be shown as “less visible” - this is used for informal paths and for those where the trail_visibility tag is set to a lower value. Completely invisible paths with no designation (along with some of the highest sac_scale ones) are in the schema as “bad” paths, and only shown on map.atownsend.org.uk via a separate raster overlay (“no vis paths”):

(see here in OSM)

** I probably need to write something somewhere about the different designation values used on highways in England and Wales, but there’s not really room here.

Недавно добавляя заметки чтобы потом по ним добавлять что-либо (ну или проверить место) одну заметку случайно оставил открытой, там я написал “Лево от 7 столба мусорка”. Я даже не мог представить насколько агрессивные местные энтузиасты. Сейчас заметки уже нет (больше месяца прошло с её закрытия) но извините, я не знал что люди умеют лить столько говна за мелкий текст. Хватало мне неделю не заходить на осм так сразу! Люди меня обзывали всем чем только можно, говорили “Смысл этой заметки? Удались!” и “ГНИДА” (просто по приколу походу. Чем я так людей оскорбил? Там на месте бывшей мусорки кто-то машину припарковал? В чём прикол срать без причины?

Ada sedikit cerita tentang hal buruk yang saya alami waktu beraktivitas di jalan raya. Tahun 2015 klas1 SMA, jalan menuju sekolah ada kejadian tidak mengenakkan, saya mengalami kontak fisik dengan orang yang tidak saya kenal, itu terjadi di jalan raya dan sekitar 2 meter dari rumah saya, dimana ada 5 orang dan 2 dari mereka melakukan kontak fisik kepada saya, tanpa izin saya. Saya kembali pulang kerumah dengan keadaan menangis. Ketika saya kasih tau orangtua saya, mama saya langsung pergi cari orang-orang itu, dan menjeput saya di sekolah. Ada salah satu teman saya perempuan juga, yang menormalisasikan perbuatan tersebut dan berkata itu hanya memengan tanggan saja. Apakah saya yang terlalu berlebihan? Tapi itu tempat umum mereka berani, bagimana dengan tempat sepi, apakah mereka tidak akan berbuat lebih dari itu? Oleh karena itu, pemetaan jalan aman bagi perempuan sangat dibutuhkan sebagai upaya untuk menciptakan lingkungan publik yang lebih aman, nyaman, dan inklusif. Pemetaan ini membantu mengidentifikasi lokasi-lokasi yang dianggap rawan, minim penerangan, sepi, atau memiliki risiko terjadinya pelecehan dan tindak kekerasan. Dengan adanya pemetaan, pemerintah, komunitas, maupun masyarakat dapat mengetahui area yang memerlukan perhatian dan perbaikan. Selain fasilitas fisik, kesadaran masyarakat juga sangat penting. Lingkungan yang saling peduli, menghormati, dan berani membantu korban dapat meningkatkan rasa aman di ruang publik. Pemerintah, komunitas, dan masyarakat perlu bekerja sama untuk menciptakan lingkungan yang inklusif, aman, dan ramah bagi semua orang, terutama perempuan dan anak-anak sebagai kelompok yang lebih rentan terhadap risiko di tempat publik.

Nice routing algorithm you got, but have you considered I got a map, a vague sense of direction and impeccible luck.

Bin wieder Zuhause mit einer Totalwartezeit von 11 Minuten bei 4 mal umsteigen und bin mit meiner improvisieren Route mit Bus praktisch direkt vor meiner Haustür gelandet. Vielleicht wär mein weg noch schneller gewesen wenn ich statt StreetComplete und Bauchgefühl OSMand verwendet hätte aber guess I dont need to use the data, I just contribute to it…

Mein erstes mal OSM/FOSSGIS Stammtisch Berlin heute war super, bin ab sofort öfter dabei.

(Sorry fürs Denglish)

Contributing commercial vehicle GPS traces from Kerala — a routing approach

I’ve been working on a method to convert commercial vehicle telematics data into useful GPX traces for OSM contribution in Kerala.

The problem

Telematics data is segment-based — each record has a start coordinate, end coordinate, timestamp and distance, but no continuous GPS track in between. Uploading these directly produces straight lines which aren’t useful for mapping.

The solution

I set up a local OSRM instance using the Kerala road extract from Geofabrik, then route-matched each segment to the actual road network. This produces GPX traces with thousands of road-following points instead of straight lines.

Results

From two months of data covering Thrissur, Irinjalakuda, Chalakudy, Kodungallur and surrounding areas:

• 141 road-snapped segments uploaded as GPX traces
• 19 high-priority segments flagged as possible unmapped roads
• These will be cross-checked against aerial imagery in JOSM

Next steps

Reviewing the unmapped road candidates in JOSM against Bing aerial imagery. More vehicle data from the same region will be processed and contributed regularly.

If anyone in the Kerala OSM community has experience with similar data or wants to collaborate on reviewing unmapped road candidates, feel free to reach out.

Tools used: Python, OSRM (self-hosted), gpxpy

First time writing a diary so friend I converted to mapping can find me :D

昨日、久しぶりにOSMのアカウントにLOGINした。 めちゃくちゃ前に残していたログがなつかった。

今つくってるアプリで、ささやかにOSMに貢献できるかも、と思ってる。

ボクは西暦2001年の夏に、豊橋市の小中高の学校や神社や駅などを自転車で回ってパノラマ写真を撮りまくったり、その後も消化器や諸々、GPSのPOI記録しながら狂ったように収集してた。意味あると信じて。結局、HDDが壊れてデータが消えてしまい、いまはもう。

早上，爸爸叫我去学习“正常”的编曲，而不是我自己瞎写的“不正常”编曲，但是我不想学，但我也不知道怎么样解除爸爸的期望，于是我拿起了旁边的剪刀，试图吸引注意，结果爸爸妈妈竟然以为我要杀他们，然后从此决定不再对我有什么感情，不再对我好，并表示可能会把我送进精神病院。 该段落于收集osm商铺poi的路上写下。 还有，蕉饼，你是如何找到我的网盘的？

– Portuguese below

A SPECIAL KEYNOTE ON THE REVISION OF MOZAMBIQUE’S ENVIRONMENTAL LEGISLATION AS AN OPPORTUNITY TO HIGHLIGHT THE IMPORTANCE OF OPENSTREETMAP AND OPEN DATA

On May 13, 2026, a roundtable discussion was held on the implementation strategy for Mozambique’s national environmental policy, which is currently undergoing a major revision. The event was hosted by the Faculty of Earth and Environmental Sciences at the Pedagogical University of Maputo (FCTA UP-Maputo), in partnership with the Brazilian company IVIDES DATA®.

At the invitation of the organizers, Dr. Raquel Dezidério Souto (IVIDES DATA® and UFRJ, Brazil) delivered a special keynote titled “Development & Conservation” (translated from Portuguese), followed by a discussion on the recent Mozambique’s environmental strategy. A copy of the presentation can be found in Portuguese at https://zenodo.org/records/20149423 (*). 

Cover page of the keynote’s file. Image of Maputo (Mozambique) on OSM. Map data (c) OpenStreetMap and satellite image from Bing.

The Brazilian scientist and entrepreneur took the opportunity to reiterate the importance of open data and collaborative mapping for achieving the Sustainable Development Goals. As an example, she highlighted the advantages and limitations of collaborative mapping using OpenStreetMap and encouraged participants to use the global mapping platform to collect data in their country (where obtaining official data is frequently difficult).

The live session was attended by the president of FCTA UP-Maputo, members of its Scientific Council, and approximately 40 other simultaneous participants; with just over 150 people having registered, demonstrating the interest of the scientific community at FCTA UP-Maputo in contributing to the discussion on the implementation strategy for Mozambique’s national environmental policy.

(*) If the Zenodo.org page doesn’t load, please try again later or send us a message at ivides [at] ivides.org.

PALESTRA ESPECIAL SOBRE A RENOVAÇÃO DA LEI DO AMBIENTE EM MOÇAMBIQUE É OPORTUNIDADE PARA RESSALTAR A IMPORTÂNCIA DO OPENSTREETMAP E DOS DADOS ABERTOS

Em 13 de maio de 2026, foi realizada uma roda de discussão sobre a estratégia de implementação da política nacional do ambiente em Moçambique, que está passando por uma grande revisão. O evento foi realizado da Faculdade de Ciências da Terra e Ambiente da Universidade Pedagógica de Maputo (FCTA UP-Maputo), em parceria com a empresa IVIDES DATA®. 

A convite, a Dra. Raquel Dezidério Souto (IVIDES DATA® e UFRJ, Brasil) proferiu palestra especial intitulada “Desenvolvimento & Conservação”, acompanhada de debate amplo sobre a estratégia de Moçambique para o ambiente. A cópia da apresentação pode ser encontrada em https://zenodo.org/records/20149423 (*). 

Capa do arquivo da palestra. Imagem de Maputo (Moçambique) no OSM. Dados do mapa (c) OpenStreetMap e imagem de satélite Bing.

A pesquisadora e empresária brasileira aproveitou a oportunidade para reafirmar a importância dos dados abertos e do mapeamento colaborativo para o alcance dos Objetivos de Desenvolvimento Sustentável. Como ilustração, apontou as vantagens e limitações do mapeamento colaborativo com OpenStreetMap e incentivou os participantes a utilizarem a base cartográfica mundial para levantar dados, em um país em que há frequentemente dificuldade para a aquisição de dados oficiais.

Participaram da sessão ao vivo: o presidente da FCTA UP-Maputo, membros do seu Conselho Cientifico, além de cerca de 40 pessoas, simultaneamente, tendo sido recebidas inscrições de pouco mais de 150 pessoas, demonstrando o interesse da comunidade científica da FCTA UP-Maputo em contribuir com a discussão da estratégia de implementação da política nacional do ambiente em Moçambique.

  (*) Se a página do Zenodo.org não carregar, tente em outro momento ou nos envie uma mensagem para ivides [at] ivides.org.

Nota importante: IVIDES.org® and IVIDES DATA® são marcas registradas. OpenStreetMap® é uma marca registrada.

OsmAnd Web 1.03 — Now Available!

We're excited to announce the release of OsmAnd Web 1.03. This update introduces Garmin Connect integration for automatic activity sync, a redesigned navigation interface, improved management of personal data with Smart Folders and pinned Favorites, and enhanced track customization with adjustable color and width. It also improves POI information with opening hours displayed directly in the context menu, along with multiple usability improvements and bug fixes across the web map.

Enjoy a smoother and more intuitive OsmAnd Web experience.

What's new​

• Added Garmin Connect integration for automatic activity sync;
• Added Smart folders support for organizing tracks;
• Public transport stops are now displayed on the map to help locate nearby transit options;
• Improved POI context menu with richer information and a clearer layout;
• Redesigned track context menu;
• Added the ability to export GPX tracks as simplified files for easier sharing and smaller file size;
• Opening hours are now displayed directly in the POI context menu when available;
• Added support for pinned favorite folders for quicker access to frequently used collections;
• Redesigned Favorites and waypoint editing interface with improved appearance customization and folder management;
• Improved selected object highlighting on the map with a distinct pin marker and smarter map behavior;
• Improved Wikimedia metadata handling, including better display of author, license, and description for images;
• Bug fixes.

Garmin Connect Integration​

You can now connect your Garmin Connect account in the Web Planner and automatically sync your activities with OsmAnd.

Once connected, activities are imported as tracks and stored in a dedicated Garmin Connect folder in the Tracks section. New activities are added automatically after they are recorded in your Garmin account. Imported activities are converted into tracks, and their types are preserved when possible. You can also sync recent activity history during the initial connection.

Read more about it in our blog article.

Smart Folders Support​

Smart Folders are now supported in the web version, allowing you to view and manage track collections created on mobile devices. Smart Folders are synced via OsmAnd Cloud when Settings synchronization is enabled.

On the web, Smart Folders are displayed in the track list with a distinct star icon for easy identification. The folder content depends on its configuration on the device, and only supported parameters are applied when displaying tracks.

Track Tools​

Several improvements were introduced to make working with tracks easier and more flexible.

Track Panel Redesign​

Redesigned track panel and context menu with a new top action bar, quick access controls, and tab-based navigation between Overview, Track, and Points.

Export GPX as Simplified Track​

A new export option allows downloading GPX tracks in a simplified format. This helps reduce file size and improves compatibility when sharing tracks with other applications or services.

Public Transport Stops​

Public transport stops can now be displayed directly on the map. Stop markers indicate locations where public transport routes operate. Selecting a stop opens a context panel with key information and quick actions.

The Routes section lists all routes serving the selected stop, including the transport type and route number. Selecting a route opens a detailed view showing the full sequence of stops, with the currently selected stop highlighted on the map.

POI Context Menu Improvements​

The POI context menu has been enhanced to display more useful information about locations directly on the map.

Opening Hours​

Opening hours are now shown directly in the POI context menu when this information is available. The menu also indicates whether a place is currently open or closed.

Wikimedia Metadata​

Photos from Wikimedia sources now display additional information in the POI photo gallery. When opening a photo, users can view details such as the date, author, license information, and a description of the image.

Pinned Favorite Folders​

Favorite folders can now be pinned so that frequently used folders appear at the top of the list for quicker access. Pinned folders are displayed in a separate section above the rest of the Favorites.

Favorites and Waypoint Editing​

The Favorites and waypoint editing workflow has been redesigned with a new unified Edit panel. Favorites and track waypoints can now be edited more conveniently, including name, address, description, folder, icon, color, and shape settings.

The updated interface also adds improved appearance preview both in the editor and on the map, categorized icon selection, custom color palettes, dedicated description editing, and easier folder management with support for creating new folders directly from the editor.

Selected Object​

When an object on the map (such as a POI, favorite, or navigation point) is selected, it is now highlighted with a distinct pin marker. Only one object can be selected at a time, and the map scrolls to it only if it is not currently visible on screen.

Bug fixes​

• Map jumped away from the selected track.
• Favorites were not displayed when opening folders.
• Scrolling issue in the track list.
• Favorite folders ending with .gpx could not be renamed.
• Incorrect statistics calculation for some multi-segment tracks.
• Slow route analysis when building complex routes.
• Crash when importing GPX files with longitude equal to 0.0.
• Shared track links required a page refresh to open correctly.
• Incorrect geocoding results for some addresses.
• Some Wikimedia photos were not displayed for POIs.

If you have suggestions for improving the Web version, please get in touch with us. We appreciate and welcome your contribution to the further development of OsmAnd.

• Follow:

  Follow OsmAnd on Facebook, TikTok, X (Twitter), Reddit, and Instagram!

• Join:

  Join us at our groups of Telegram (OsmAnd News channel), (EN), (IT), (FR), (DE), (UA), (ES), (BR-PT), (PL), (AR), (TR).

Yesterday I cleaned up some map data by removing unnecessary email and unrelated details from several objects. I am learning and trying to follow proper OpenStreetMap mapping guidelines.

把南车站路-中山南路-鲁班路-徐家汇路中间区域的楼全描了，也就是陈欣恬的家、我的家、刘珺瑜的家、我的学校那片。