OpenStreetMap Blogs Last Update:

♦

In June 2026, UN Mappers Kenya launched its first ever Youth Climate Mapping Externship ,a seven-week virtual programme designed to put real geospatial tools in the hands of young Kenyans and point them at real climate problems in Nairobi. Nineteen university students answered the call.

A Programme Built by UN Mappers Kenya

The Youth Climate Mapping Externship 2026 is a UN Mappers Kenya initiative , born from the UN Maps chapter initiative and the belief that open geospatial data should be created by the communities it represents, not just for them. From the first session to the graduation ceremony, every element of this programme was designed and delivered under the UN Mappers Kenya banner.

The Journey

The externship ran from 29 June to 17 August 2026 across four progressive phases.

Phase 1 — Learn (Weeks 1 and 2)

Participants started from the ground up , climate issues facing Nairobi, GIS foundations, QGIS, and their first steps on OpenStreetMap. By the end of week two they had made real contributions to the global humanitarian map through the HOT Tasking Manager. For most of them it was the first time their work had ever left their laptop and gone somewhere that mattered.

Phase 2 — Map (Weeks 3 and 4)

This is where things got real. Participants trained in KoboToolbox and Chat Map, then on a Saturday in July they went to Kibera , smartphones out, GPS on, walking through Woodley and Sarang’ombe to validate a waste mapping study that had not been revisited since 2020. Then in Week 4 they came back to their desks and turned that field data into flood risk models of Nairobi subcounties.

Phase 3 — Build (Weeks 5 and 6)

Data alone does not change anything. Maps that no one can read do not either. Week 5 was about cartographic design and learning to speak to the people who hold the pen on decisions. Week 6 was group project time, teams-built climate vulnerability maps and policy briefs for their assigned areas.

Phase 4 — Present (Week 7)

Teams submitted and presented their climate vulnerability maps to a panel including Nairobi County representatives. Then they graduated.

The Numbers 19 participants from universities across Kenya 70,000+ edits contributed to OpenStreetMap 15 sessions delivered across 7 weeks 270 hours of training and field work 8 expert trainers from Kenya, Argentina, the Philippines, and the global HOT network 82 trash points validated in Kibera 6 group climate vulnerability projects produced for Nairobi County The People

This programme was only possible because extraordinary people showed up.

Lucy Kago — UN Maps Community Engagement Ambassador, Kenya

Lucy facilitated the Week 1 climate issues session, the OSM practical, Kobo Toolbox training session and led the Kibera field day on Saturday 18 July.

Arnalie Vicario — UN Mappers Community Engagement Specialist.

Analie facilitated sessions on the UN Mappers programme and community engagement, bringing the global open mapping perspective to the cohort.

Ruth Kago — Learning Designer

Ruth designed the programme curriculum, shaping the structure and learning experience from the ground up.

Ivan Kipruto — Geospatial Developer.

Ivan facilitated the Week 1 QGIS introduction and geospatial foundations session.

Laura Mugeha — UN Mappers

Laura and Arnalie facilitated Week 2 She took the cohort through the world of humanitarian mapping. She introduced participants to the UN Mappers context, how open mapping supports humanitarian response globally, and walked them through their first structured mapping campaign. She connected our Nairobi classroom to the bigger picture of why this work matters beyond the map.

Silvina Maritano — UN Mappers Ambassador, Argentina

Silvina facilitated the Week 3 Chat Map session, joining virtually from Buenos Aires.

Mr Martin Wainaina Chege — Cartographer, DeKUT

Martin facilitated the Week 4 GIS analysis and flood risk modelling sessions.

Catherine Njore — Lead Cartographer, GeoMind Solutions

Ms.Catherine facilitated the Week 5 cartographic design and map storytelling sessions. Author of Mappy Maria, Kaunti za Kenya, and My Stern Mom, she left the cohort with one line that stuck: “The tools mean nothing if the map does not speak to the person holding it.”

The Kibera Field Team — Week 3

A special recognition goes here. Nicera Wanjiku and the Kibera Community mappers team opened Kibera’s doors to our participants. They did not just provide access ,they walked alongside the cohort through Woodley and Sarang’ombe, guiding the ground-truthing exercise with the authority of people who actually live the data they helped collect. That day would not have happened without them. ♦

♦

What Was Built Group 1 Multi-Temporal Analysis of Vegetation Change in Ruai, Nairobi

Thirty years of NDVI data. One clear finding, Ruai is losing its green, and residential and industrial expansion is driving it.
Multi-Temporal Analysis of Vegetation Change in Ruai, Nairobi

Group 2 Tharaka Nithi Aridity Change 2003 to 2023

Six wards. Twenty years. A 39% fall in sorghum production. This group mapped a drought story that agriculture statistics alone could not tell.
Tharaka Nithi Aridity Change 2003 to 2023

Group 3 Analysis of Urban Heat Islands to Support Mitigation Measures

Nairobi is getting hotter and some parts of it are heating faster than others. This project mapped where, by how much, and what planting trees can actually do about it.
Analysis of Urban Heat Islands to Support Mitigation Measures

#Group 4 Mapping Greenspace Loss to Urban Development 2017 to 2026

A decade of watching green disappear under concrete and a look at where interventions are actually working.

Mapping Greenspace Loss to Urban Development 2017 to 2026

Group 5 Impact of Land Use and Land Cover Change for Karura Forest 2016 to 2026

One of Nairobi’s most important lungs, mapped over ten years. The hotspots of degradation are now visible.

Impact of Land Use and Land Cover Change for Karura Forest 2016 to 2026

Group 6 Suitability Analysis for Kibera Trash Points

Where should new waste collection points go in Kibera? This group built a GIS model to answer that question — spatially grounded, community-centred, and ready for use.

Our Partners

None of this was done alone.

IVIDES DATA -The Programme Sponsor.

Raquel Deziderio, CEO of IVIDES DATA, believed in this work before it had a single participant and funded it throughout. We called and she answered. None of this would have existed without her.

GeoMind Solutions —Technical partner

Thank you for availing two technical trainers, Ivan Kipruto and Catherine Njore. Your commitment to youth geospatial education showed in every session they delivered.

Geospatial Developers, Dedan Kimathi University of Technology — Technical Partner.

Technical Partner. Thank you for bringing your expertise to our cohort and holding Week 4 with the rigour it deserved.

Community mappers Kibera — Community Partner.

The reason the Kibera field day was possible and the reason it meant something.

UN Maps

The programme this entire externship is built within. The platform, the network, and the mission.

♦ Nineteen students. Seven weeks. Seventy thousand edits on the global map. Six projects for Nairobi County. One field day in Kibera that nobody who was there will forget.

Nairobi Cohort 1. Done. 🗺️

a day ago

En la página principal de OpenStreetMap osm.org en algunas ocasiones sale un cuadro en el borde superior derecho, con una imagen relacionada con OSM. En muchos casos es promocionando el evento State of the Map global. Aquí algunos ejemplos:

♦

Lo bueno, es que no solo se puede usar para eso, sino que puede solicitar la promoción de otros eventos de OSM. Como los SotM regionales o locales por país, o eventos de los capítulos oficiales de cada zona.

Para tu evento tendrás artes preparadas, entonces alista una imagen de 350x350 píxeles, en formato PNG, que no tenga nada importante arriba a la derecha 60x60 porque ahí se sobrepone la X de cerrar el banner y que tenga buen contraste con los colores Gray80 (Chinese Silver) y gris espacial (Spanish Gray) que son los colores de la X.

Tan solo se necesita hacer un fork del repositorio github.com/openstreetmap/openstreetmap-website en tu propia cuenta de GitHub.

Ya en tu cuenta buscas esta ruta: openstreetmap-website/tree/master/app/assets/images/banners y pones la imagen que promociona tu evento.

Después buscas este archivo: openstreetmap-website/blob/master/config/banners.yml Y agregas una nueva entrada al final, así:

sotm_col_2026:
  id: sotm_col_2026
  alt: State of the Map Colombia 2026
  link: www.osm.lat/colombia/sotm/sotm-col-2026/
  img: banners/sotm_col_2026.png
  srcset:
    - [banners/sotm_col_2026.png, 1x]
    - [banners/sotm_col_2026@2x.png, 2x]
  startdate: 2026-june-03
  enddate: 2026-july-03
  countries:
    - CO ---

• El nombre del bloque puede ser cualquiera, igual que el id.
• El alt es el texto que aparece como texto alterno. Ahí pones el nombre de tu evento.
• En link es un enlace a donde esté la descripción del evento, como la agenda, fechas, etc.
• En img pones la ruta de la imagen que pusiste en el paso anterior (bajo openstreetmap-website/tree/master/app/assets/images/banners).
• Puedes poner 2 imágenes, la segunda con doble resolución con respecto a la primera.
• startdate es la fecha de inicio de tu evento. Sigue las reglas de publicación. Los eventos locales solo se pueden poner con máximo de antelación un mes antes de comenzar.
• enddate normalmente es la fecha que comienza tu evento.
• countries es en dónde quieres que aparezca el banner. Si es un evento de tu país, pon el código ISO de 2 letras.

Después de haber agregado la o las imágenes, y modificado el archivo banners.yml, puedes hacer un pull request cuyo título indique en inglés cuándo debe comenzar a ser mostrado, y los mantenedores del repositorio oficial verificarán.

Aquí un ejemplo que hicimos para el state of the map Colombia 2026 github.com/openstreetmap/openstreetmap-website/pull/7109

La documentación completa está en inglés en github.com/openstreetmap/openstreetmap-website/blob/master/FAQ.md#how-do-i-create-a-banner-to-promote-my-openstreetmap-event

Y aquí las políticas para publicar operations.osmfoundation.org/policies/banner/

No esperes a último momento, y crea tu banner ya.

a day ago

Ein Zeitungsbeitrag zu einem neuen Defibrillator machte vor ein paar Monaten auf eine für mich erschreckende Tatsache aufmerksam: Weder für Gesamtdeutschland noch für viele Regionen gibt es eine auch nur einigermaßen vollständige Datenbank bzw. Karte zu Defibrillatoren. Keine ist wirklich umfassend erschlossen, keine bringt auch nur annähernd alle wünschenswerten Funktionen mit.

Allein für den hiesigen Landkreis, Roth (bei Nürnberg), gab bzw. gibt es mindestens fünf verschiedene Dienste: Neben großen Karten wie Defi-Kataster, Defi-Map und Björn-Steiger-Stiftung sowie OSM betreiben auch der Landkreis und verschiedene Kommunen eigene Karten.

Gleichzeitig ist es eine bittere Tatsache, dass nur etwa jeder zehnte Betroffene eines plötzlichen Herzstillstandes diesen außerhalb einer Klinik auch überlebt, wie zuletzt auch eine Pressemitteilung des Deutschen Reanimationsregisters einmal mehr unterstrich. Ein großer Teil der Menschen stirbt unerkannt (etwa im Schlaf oder allein zu Hause). Und in vielen weiteren Fällen stehen nicht ausreichend motivierte und fähige Ersthelfer zur Verfügung, um eine wirkungsvolle Herzdruckmassage zu leisten, wie auch Rettungssanitäter in Gesprächen unisono berichten. In all diesen Fällen hilft auch kein Defibrillator.

Und doch: In ungefähr jedem fünften Fall klappt jemand mit Herzstillstand in der Öffentlichkeit zusammen und beginnen ein oder zwei Personen schnell mit Herzdruckmassage. Ein dritter, vierter, fünfter … Helfer könnte ausschwärmen, um einen Defibrillator herbeizuschaffen, um das Herz in gewisser Weise zu resetten und die Überlebenswahrscheinlichkeit damit deutlich zu steigern. Eine Studie zum Frankfurter Flughafen, wo viele Menschen, potenzielle Ersthelfer und Defibrillatoren zusammenkommen, zeigt eine Überlebensrate von merklich über 50 Prozent. (Wobei freilich in diesem Umfeld ein Herzstillstand kaum unerkannt bleiben wird und auch Menschen mit an sich schlechter Prognose, beispielsweise aufgrund massiver Vorerkrankungen oder hohen Alters, hier sicher unterrepräsentiert sind.)

Von einigen lokalen und regionalen Beispielen abgesehen, liefert keine der großen Datenbanken bzw. Karten in Deutschland – auch nicht OSM – ein auch nur annähernd vollständiges und aktuelles Bild, wo sich die nächsten Defis befinden und ob diese zugänglich sind. Und wer als Helfer beispielsweise Google befragt, bekommt in der Regel eine unvollständige und zum Teil falsche Antwort. (Selbst Google nutzt selbst auf Nachfrage die in OSM vorhandenen Daten nicht.) Dazu kommen auch noch allerlei Begleitprobleme, etwa die schlechte Auffindbarkeit/Kennzeichnung vieler Geräte oder zeitlich stark eingeschränkte Zugänglichkeiten.

Das Fehlen einer einigermaßen koordinierten, nationalen Datenbank nehme ich, wie so vieles in unserem Land, als ziemliches Wursteln wahr, das offensichtlich Jahr für Jahr Menschenleben in merklicher Zahl kostet. Anstatt es einmal koordiniert “richtig” zu machen, wird mit gutem Willen, aber eben recht unkoordiniert nebeneinander her gearbeitet. Es würde mich nicht wundern, wenn wir allein aufgrund unzureichender Defi-Daten – im Internet, in den Datenbanken, in den Leitstellen – jedes Jahr in Deutschland Menschen im hohen drei- bis niedrigen vierstelligen Bereich verlieren oder es zu unnötig schweren Folgeschäden kommt.

Diese Gedanken lassen mir seit einem Vierteljahr keine Ruhe. Anhand von Recherchen in den anderen Datenbanken, im Internet, sozialen Medien und weiteren Hinweisen ist inzwischen ein großer Teil der bekannten Defis im hiesigen Landkreis erfasst. Die Defibrillator-Seite im OSM-Wiki wurde umfassend überarbeitet und wird weiter ergänzt. Dazu kommen noch ganz grundlegende Themen: etwa Gespräche mit den anderen großen Anbietern, ob nicht ein teilautomatisierter Abgleich möglich wäre oder grundlegende Überlegungen, um beispielsweise der Google-KI auf die Sprünge zu helfen.

Ich hoffe, dass all dies ein paar Beiträge zur Lösung der grundlegenden Probleme leistet. Neben der Auffindbarkeit hoffe ich, dass die durch die Daten bzw. Karte geschaffene Transparenz auch einige grundlegende Diskussionen vor Ort in Gang setzt: Wäre es beispielsweise in der Kreisstadt Roth nicht sinnvoller, statt mehrerer jeweils stark eingeschränkt zugänglicher Defis im Abstand von wenigen hundert Meter (Beispiel 1, Beispiel 2), diese besser zu verteilen und dabei auch rund um die Uhr zugänglich zu machen sowie deutlicher auszuschildern? Zumal viele dieser Geräte von ein und derselben öffentlichen Hand bzw. Stadtverwaltung finanziert werden?

Laut Tagwatch sind allein für Deutschland in OSM nunmehr rund 20.000 Defibrillatoren erfasst. Die Datenbank ist damit in gewisser Weise der zweitgrößte Anbieter für Deutschland. Der Bestand wächst exponentiell, mit inzwischen über 500 neuen Einträgen pro Monat. Erste Landkreise, Kommunen und auch Rettungsleitstellen nutzen die Daten. Der Landkreis Roth verweist seit kurzem auf seiner Defi-Seite rein auf OSM (OpenAEDMap) und trägt auch selbst dazu bei.

Es ist manches erreicht, aber es bleibt noch viel zu tun.

a day ago

כאן צירוף מקרים מעניין. המערה נמצאת בשכונת רמת אשכול. אז היינו מצפים שיש קשר בין השמות. אבל לא! השכונה נקראת על שם לוי אשכול ראש הממשלה השלישי של מדינת ישראל. ואילו המערה נקראת על שם עיטורים שעליה, בצורת אשכולות ענבים.

הנקודה לא מצויינת במפות אחרות (גם לא במפה של טרגט, אני לא יודע מה עם כרטא). אבל יש שילוט ברחוב ים סוף וגם מוצג שלט עם הודעה בסגנון “חפשו את המטמון”. אני לא בטוח שהקואורדינטות מדוייקות, אולי אלך שם עוד פעם בזמן פנוי ואנסה למפות. אם כי אין לי מכשיר GPS. ואני סומך על אומדן בלבד ועל התצלום של בינג.

2 days ago

Over the past few days, I’ve mapped several major and minor roads; some recently opened to traffic, others set to open in the coming weeks.

There is a quiet satisfaction in laying down those initial traces, knowing that countless people will rely on that geometry for decades to come. OpenStreetMap has always been my favorite way to spend spare time: shaping a digital layer that creates tangible, real-world value. While mapping can sometimes feel like a solitary or thankless effort, seeing raw satellite imagery turn into living infrastructure that guides everyday movement makes it genuinely rewarding.

Mapping on OSM is always time well spent.

3 days ago

Casale Cima Santa Cristina fraz. di Borgomanero (NO) 28021, Piemonte

24/08/2026, San Bartolomeo

E’ il santo patrono di Borgomanero e Santa Cristina, essendo che si festeggia il 24 luglio, non dovrebbe c’entrare niente, invece le pochissime attività e servizi pubblici sono chiusi anche oggi.

C’è da dire che ho apportato un po’ di modifiche alla mappa del territorio locale, oggi. Munita di mappali del Catasto di Novara, comune di Borgomanero, Foglio: 21 e Particelle: varie (es.: 191 - 193-194, etc.) ed in territorio di Gattico-Veruno, Foglio: 1, sono riuscita a ricollocare esattamente i confini dei nostri terreni, discendenti dei fratelli Valsesia Angelo Maria e Carlo, i quali avevano acquistato l’intera cascina, con tutto il territorio annesso, nel secolo scorso, dai conti Busti, a loro volta eredi dei nobili possidenti Morbio-Zapelono. Il conte Paolo Busti, a fine 1800, fece costruire le “case masserezze” per i fittavoli che lavoravano le terre, area denominata poi “La Moretta”. Casa mia era detta la Ca’ Nova, poiché era l’unica non annessa al casale vero e proprio, essendo infatti una casa indipendente con giardino, costruita intorno al 1960 e non risalente al 1700 come gli edifici adibiti ad abitazione e quelli usati come stalle e fienili del Casale Cima, originariamente chiamato Sopramonte, per il rilievo su cui si colloca.

4 days ago

13/08/2026-19/08/2026

♦

[1] Using the OSM Skeleton methodology | Severin Menard | map data © by OpenStreetMap Contributors.

Mapping

• The proposal for revising lgbtq=* , authored by Spughetti, aims to make tagging of LGBTQ+ features more accurate. It does so by deprecating keys that don’t provide added information over existing keys, changing the formatting of keys, and introducing new sub-keys. The RFC period started on 12 August 2026.A proposal, authored by Biff, suggests extending the highway=traffic_mirror node with a relation type=traffic_mirror that specifies how the traffic mirror is intended to be used for the specific highway. It extends the already defined role=from and role=to members of the relation, provides better guidance for their meaning and the selection of their location, and also covers additional situations such as bidirectional mirrors on curves and dead-angle mirrors. Additionally, the proposal defines a new and recommended role=visible member to indicate relevant ways (or nodes) that can be seen through the traffic mirror. The RFC period is open until 12 September 2026.

Community

• Rphyrin developed Warlok, a web tool for identifying the top OSM contributors in a specific local neighbourhood.
• Rphyrin compared the user experience of several OpenStreetMap-based routing apps, including brouter, OSRM, and Valhalla, to calculate the distance of an afternoon bicycle trip he had just taken.
• Rtnf explained how to correct JOSM’s satellite imagery offset using survey control marks.
• 9_tab wrote an OSM User Diary entry about Via Crucis in Switzerland (worship=stations_of_the_cross). The entry explains what to look out for to find them, presents a list of routes along stations of the cross in Ticino, Solothurn and others cantons of Switzerland, and describes how to map them.

OpenStreetMap Foundation

• The submission phase of community questions to the board candidates closed on 22 August. An official set of questions will be added by the facilitator on 6 September 2026.

Local chapter news

• Maggie Cawley has recapped the March Local Chapters and Communities Congress (LCCC), a two-hour virtual gathering of over 30 participants from Italy, Indonesia, Greece, the USA, Belgium, Kenya, Canada, Brazil, and Malawi, sharing updates from their local OSM communities. The OSMF Board also joined to report on a Sovereign Tech Fund grant of €384,000, a new local chapter in Colombia, and plans for a Belgian subsidiary, before attendees worked through discussion prompts on what makes OSM hard to join and what keeps mapping communities going. The next in-person LCCC session will take place at State of the Map on 28 August in Paris. You can also join a monthly LCCWG meeting. Contact local@osmfoundation.org.

Events

• Christopher Lorenz and Oliver Rudzick reported ♦►♦ that FOSSGIS set up a stand at this year’s Maker Faire in Hannover and organised a stand for the OpenStreetMap project at FrOSCon in Sankt Augustin.
• The French National Institute of Geographic and Forest Information posted ♦►♦ on its website about the State of the Map 2026: ‘For the first time in twenty-two years, the OpenStreetMap community’s global conference will be held in France, in Champs-sur-Marne, near Paris, on the last weekend of August!’

Maps

• [1] Following the launch of the OSM Skeleton methodology (we reported earlier), Séverin Ménard wanted to illustrate it with an example by resolving the main reports in an area of Senegal, where the demo is currently being deployed, in order to achieve a first milestone in data homogeneity. He also created a statistics dashboard to track the progress for each type of report between 5 and 19 August, when he was mapping for this case study.
• Sylvain Machefert has developed Boîtes-à-livres ♦►♦, an OpenStreetMap-powered, collaborative database of public bookcases in France.
• Nicolas Wurtz tooted ♦ that the OpenStreetMap France community recently released Tchoo, a web map that shows old railway lines from around the world in a retro style.
• Papamap is a web map that displays locations tagged with changing_table=yes, specifying the availability of changing tables where parents can change their babies’ nappies and highlighting which parent may be able to do it. The map has data from 11 countries in Europe and those places are colour-coded by location. It also includes a related MapComplete theme and an upcoming StreetComplete quest to improve the completeness of tagging information regarding changing tables.

OSM in action

• Elias Probst tooted ♦ that OpenStreetMap data is once again being used to coordinate firefighting efforts in Hürtgenwald, Germany.
• Shannon Connellan reported on DeFlock Maps, a crowdsourced app aiming to promote ‘surveillance transparency’ by pinpointing the locations of automated licence plate readers on a map.
• DVLPLONDON developed ♦►♦ Hop Earth, a multiplayer, browser-based racing game that uses real-life street data from OpenStreetMap as its race tracks.

Software

• Uggla released AquaTrace version 0.5.0, which analyses GPX routes and displays nearby drinking water points using OpenStreetMap data, along with distance, elevation gain and loss, and an elevation profile.
• DMH_AU has built the GPX Reference Point Generator, a web tool for generating GPX reference point files based on local government survey control marker plaques, helping OSM armchair-mappers to map more accurately.

Programming

• Stadia Maps explained how to use MapLibre React Native to write map code once and deploy it on both iOS and Android.

Did you know that …

• … Thomas developed Fedihood? This is a Fediverse-based microblogging platform that lets users connect with other users in the same city, powered by the ActivityPub protocol and OpenStreetMap.
• … the OpenJUMP is an open source geographic information system written in Java? It was developed primarily in Canada and is developed and maintained by a group of volunteers from around the globe.
• … there is a table that summarises the values of admin_level for various countries around the world (related to administrative levels)? And this is related to each country’s organisation? You can also check out an interesting discussion in this Hacker News thread.
• … deleting an OSM object does not actually erase the object from the OSM database? Instead, it creates a new version of that object whose state is visible=false. The object’s ID, previous versions, tags, geometry, and history remain available.
• … Steve Coast, OpenStreetMap’s creator, delivered a special keynote ‘OpenStreetMap (almost) at 20: Reflections and Future Predictions’ at the State of the Map Europe 2023?

OSM in the media

• CHIP has rated ♦►♦ OsmAnd+ as a ‘good’ navigation app.

Other “geo” things

• USGS has released several visualisations related to the magnitude 7.4 earthquake that struck western Colombia on 10 August 2026.
• The National Geographic Institute of Spain has published ♦►♦ a web portal providing information on the solar eclipses that will be visible from Spain in 2026, 2027, and 2028.
• yle noted ♦►♦ that Yandex Maps has pioneered a new method for concealing military installations in satellite images; instead of blurring and pixelation, it now uses retouching with surrounding objects, such as forests.
• Lindsey Lanquist reported that the Google team recently improved the GNSS on their Pixel Watch 5 by using three-dimensional models of buildings from Google Maps to cut down on errors caused by signal interference, as well as leveraging Google’s existing network of global GNSS reference stations.
• Hans van der Kwast explained how to publish a QGIS project to the Mergin Maps platform, making it accessible online.

Upcoming Events Country Where Venue What When ♦ Potsdam MachBar Potsdamer Mappertreffen × 218. OSM-Stammtisch Berlin-Brandenburg ♦ 2026-08-21 ♦ Stadtgebiet Bremen Online und im Hackerspace Bremen Bremer Mappertreffen ♦ 2026-08-24 ♦ Berlin Online OSM-Verkehrswende #78 ♦ 2026-08-25 ♦ Würzburg FabLab Würzburg Würzburger OSM-Treffen ♦ 2026-08-26 ♦ Düsseldorf Online bei meet.jit.si/OSM-DUS-2026 Düsseldorfer OpenStreetMap-Treffen (online) ♦ 2026-08-26 ♦ Wien Schlupfwinkel (Kleine Neugasse 10, 1040 Wien) 79. Wiener OSM-Stammtisch ♦ 2026-08-26 OpenStreetMap West Bengal Mapping Party + AnkushTheHero Day ♦ 2026-08-27 ♦ Cité Descartes State of the Map 2026 ♦ 2026-08-28 – 2026-08-30 ♦ Essen Verkehrs- und Umweltzentrum Essen OSM-Treffen ♦ 2026-08-28 ♦ Uppsala Datorföreningen Update Mapping meetup in Uppsala ♦ 2026-08-30 ♦ Hannover Kuriosum OSM-Stammtisch Hannover ♦ 2026-08-31 ♦ Heidelberg DEZERNAT#16 Rhein-Neckar OSM Treffen ♦ 2026-08-31 ♦ Salzburg Bewohnerservice Elisabeth-Vorstadt OSM-Treffpunkt ♦ 2026-09-01 ♦ Münster BRASSERIE Münster OSM-Stammtisch Münster ♦ 2026-09-01 Missing Maps London Mapathon Beginner Friendly (with Training) (Online) [eng] ♦ 2026-09-01 ♦ Praha Přírodovědná fakulta Univerzity Karlovy SOTM/2 CZ ♦ 2026-09-02 ♦ Brno Kvartální OSM pivo – SOTM/2 CZ [Brno] ♦ 2026-09-02 OSM Indoor Meetup ♦ 2026-09-02 ♦ Stuttgart Biergarten Tschechen & Söhne Stuttgarter OpenStreetMap-Treffen ♦ 2026-09-02 ♦ Bordeaux Aquilenet, 20 Rue Tourat, 33000 Bordeaux Rentrée bordelaise du groupe local OpenStreetMap ♦ 2026-09-03 ♦ Angers L’Arrière Train, 3 rue de Frémur, Angers Angers Rencontre mensuelle OpenStreetMap ♦ 2026-09-03 ♦ नई दिल्ली Jitsi Meet (online) OSM India – Monthly Online Mapathon ♦ 2026-09-05 ♦ 臺北市 MozSpace Taipei OpenStreetMap x Wikidata Taipei #92 ♦ 2026-09-07

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 MarcoR, MatthiasMatthias, Raquel Dezidério Souto, Strubbl, Andrew Davidson, barefootstache, derFred, miurahr, renecha.
We welcome link suggestions for the next issue via this form and look forward to your contributions.

5 days ago

Letztens beim Doom-Scrolling über die OSM-Karte in Oschersleben einen langen grünen Strich gesehen und gedacht, “okay, lange Hecke oder was?”

♦

Oder wieder Vandalismus a.k.a. FCK.PTN?

Beim Editieren habe ich dann gesehen, dass jemand den Anfang der Hecke wohl versehentlich weit weg verschoben hat. Ich konnte die Hecke dann reparieren: osm.org/way/301454013

5 days ago

Willkommen im Outback-Lindlar!

Ab sofort ist das Outback-Lindlar (Klauserstraße 77 in 51789 Lindlar) auch auf OpenStreetMap präsent. Als gemütliches Themenrestaurant im Bergischen Land freuen wir uns über alle Gäste, Tourenfahrer und Biker, die bei uns einen Zwischenstopp einlegen.

Kommt vorbei auf gute Küche, erfrischende Drinks und eine tolle Atmosphäre. Schaut gerne rein!

5 days ago

I’ve just joined OpenStreetMap after using the CoMaps app for a month. I’ve been a frequent Google Maps Local Guide, but want to support open source efforts.

Today, I signed up and updated a shop that was labelled as disused to a cafe that recently opened local to me.

6 days ago

Viernes 28 de Agosto de 2026.

Se realizo:

1. Se modifica Vista Sur I a Villa Vista Sur I y se ubica en lugar que corresponde.

2. Se agrega Villas Vista Sur II, Villa Florencia 1-2-3-4-5 y Terrazas de Lourdes.

3. Se elimina Bosques de San Francisco Norte y Sur, a la par se agregan Villa Bosques de San Francisco I-II-III.

4. Se agrega Condominio José Gil de Castro.

5. Se agrega Condominio Escultor Samuel Román Rojas y se cambia nombre de vía a Calle 21 de Mayo.

6. Se agrega Población 21 de Mayo y se agrega Condominio Francia con sus vías.

7. Se mueve área de construcción y se agrega Condominio Santa Josefina y Condominio Don Nicolás Anich Asís.

7 days ago

GSoC 2026 with OpenStreetMap Routing through pedestrian areas in Valhalla

During this Google Summer of Code, I’ve solved a very common problem that pedestrian routers have by adding the feature to route through open pedestrian areas, such as squares, plazas, pedestrian zones… instead of routing around the perimeter.

It’s now merged and running on the full planet build. Where pedestrians used to be sent all the way around the perimeter, Valhalla now creates a path straight across it.

Before : ♦

Now: ♦

See the Square Plaza de Santo Domingo, Murcia

You can try a demo of the feature on openstreetmap.org: Here

Table of contents

• GSoC 2026 with OpenStreetMap
• Routing through pedestrian areas in Valhalla
• Table of contents
• About the project
  • What is Valhalla
  • The problem
  • The goal
• How it works
  • The core idea: the medial axis
  • The pipeline
    • 1. Recovering the area geometry
    • 2. Building the traversal
    • 3. Synthetic OSM IDS
  • Design decisions
• Results
  • Current state
  • Full-planet build statistics
  • Performance journey
  • See it in action
• The code
  • Pull requests
  • Documentation
  • Commit history
• Challenges and what I learned
• Limitations and future work
  • Limitations
  • Future work
• Acknowledgements

About the project What is Valhalla

Valhalla is an open-source routing engine that calculates directions using OpenStreetMap data for driving, cycling, walking, and more.

It works by turning raw OSM data into routing graphs that generate routes for different means of transport.

The problem

In OpenStreetMap, open pedestrian areas are often mapped as polygons with the tags highway=pedestrian + area=yes. Valhalla treated these polygons as obstacles because these areas don’t have explicit sidewalks to route through, so it might have routed around the perimeter but never across them.

This led to some cases with extremely long and nonsensical routes. This is a long-standing pain point in pedestrian navigation, even for the big companies.

See one clear example of the problem: ♦

The goal

The goal of my project was to make Valhalla able to cross these open areas. The scope I agreed on with both my mentors was to cover the large majority of areas in the world, in a robust and mergeable way.

How it works The core idea: the medial axis

We had to choose an algorithm that could solve this problem as efficiently as possible, because there are some known algorithms that might seem like excellent options but are extremely inefficient. After doing extensive research (more detailed comparation in my past diary entry) we selected the medial axis approach.

This is how the skeleton of a medial axis looks on a complex square: ♦

The pipeline 1. Recovering the area geometry

The whole process is integrated into Valhalla mjolnir, the tile builder.

First of all, areas mapped as relations have member ways with no routable tags, so the normal parsing process discarded them. Moreover, areas mapped as ways were also discarded. So naturally the first step was to start parsing them.

This was resolved in two different ways, for the tags discarded at the beginning of the pipeline I had to make some changes to start keeping these areas in the files, see my Pull Request [GSoC] Pedestrian area routing: Detect areas during parsing.

For the member ways, it’s a more complicated case, because Valhalla’s pipeline order makes it impossible for us to collect these member ways before parsing the relations, so we came up with a new stage to recover these ways and preserve their geometry alive. This stage (ParseAreaWays) can be seen in my Pull Request [GSoC] Pedestrian area routing: Build area polygons and generate medial axis.

2. Building the traversal

Next, there is also a new stage (BuildAreas), where for each area, it assembles the polygon (including holes), densifies it, and computes a Voronoi diagram of the points to approximate the medial axis, prunes the branches reaching toward the corners, connects each entrance to the nearest skeleton vertex it can reach and materialises the result as synthetic footways.

These synthetic footways are built as normal footways so they can be processed through the rest of the pipeline just like any other footway. If you are interested in a long explanation of the algorithm you can look for my diary entry: [GSoC] Prototyping medial axis implementation for area routing

And for the explained code see: [GSoC] Pedestrian area routing: Build area polygons and generate medial axis.

3. Synthetic OSM IDS

The generated ways and nodes, as I mentioned before, are treated as “normal” ways and nodes, so they need synthetic OSM IDS. They get ids above the highest real OSM way and node ids, so they never collide with real data, and from there the rest of the pipeline treats them like any other footway.

And for the explained code see: [GSoC] Pedestrian area routing: Build area polygons and generate medial axis.

Design decisions

During the course of the project we had to do some serious thinking about some complex obstacles that I’ll explain further in this document. In addition, there are some other design decisions we made, to keep this feature robust:

• Areas below a size threshold keep their perimeter instead of having a generated traversal
• Areas that already have paths mapped inside are left untouched
• Nearby entrances that can “see” each other are merged
• The densification tolerance was tuned as a trade-off between speed and detail.

Results Current state

We achieved having it merged and running on the full-planet build. It covers most of the pedestrian areas in the world and sits behind the mjolnir.pedestrian_areas config option, so it doesn’t affect anyone who doesn’t enable it.

Full-planet build statistics

These are real numbers from a full planet build, not estimates:

Metric Value Pedestrian areas processed 127,612 Virtual (synthetic) edges generated 915,742 Area parsing time ~2 min Area building time ~9 min Tile size impact negligible

This is one of the things I’m most proud of, we achieved to have a first functional version with considerably good performance across the whole world, with a more than expected great result.

Performance journey

The first version took about 114 seconds to process Germany’s areas. Profiling with samply showed that the Voronoi computation was dominating everything else, so I focused on that part, preparing the polygon geometry once, collecting the lookup data in two passes, and feeding the Voronoi fewer points. That brought Germany’s processing time down to about 19 seconds, a ~83% reduction.

See it in action

The feature is now live on the public server, so you can try it yourself right now with no setup needed.

Valhalla powers one of the pedestrian routing engines available directly on openstreetmap.org, and it’s also on the Valhalla demo.

On either one, pick the pedestrian (foot) profile, drop a start and an end point on opposite sides of any square or plaza, and you’ll see the route go straight across the open area instead of tracing the edges of the area. It works anywhere in the world where the area is mapped in OpenStreetMap.

If you test it and find a bug, please take a minute to report it on Valhalla’s github: Valhalla Issues

The code

All the work is linked below.

Pull requests

• Main PR - pedestrian area traversal generation: #6195 the core of the project.
• Groundwork PR - optional area handling, and first parsing steps: #6127
• Documentation PR: #6266
• Future work / limitations documentation PR: #6279

Documentation

• Published docs page: Pedestrian area routing documentation in Valhalla Documentation

Commit history

• Last GSoC commit: 5b4d423 anything after this is post-GSoC work.

Challenges and what I learned

The hardest part of this project wasn’t writting the code, it was figuring out what to build. For weeks, before any real implementation, the work was research, prototyping and case studies, because the naive approaches don’t survive contact with real OpenStreetMap data.

• Choosing an algorithm: My first thought was a Visibility Graph. A Visibility Graph connects each pair of vertex of the polygon that “see” each other in a straight line. But after a case study in QGIS over 10 different real squares comparing approaches, the result was pretty interesting, the Visibility Graph generated too many edges and the routes we believed weren’t very friendly. More of this discussion in the case study mentioned above.

• Generating the skeleton: Generating the medial axis wasn’t calling a simple function. It was a whole pipeline, that led us to a lot of disorganized segments. Converting them into usable chains was a whole graph problem. Each step of the code was thought and designed.

• Fitting it into the pipeline: Maybe the biggest design challenge. Areas are detected while parsing the ways, but to build their geometry you need the node coordinates, which are not parsed until later. And the generated crossings need to be turned into edges, which happens even later. So an entirely new phase had to be designed and placed between ParseNodes and ConstructEdges

• Memory, and making it scale: Throughout the whole process, one of the biggest challenges was constantly thinking about how to make the solution scalable. It was not just about making it work for a small number of areas, but making sure the design would still work efficiently when applied to the entire pedestrian network of a continent. This meant being mindful of memory usage from the beginning, while also continuously looking for ways to improve performance as the implementation evolved

• Getting into a large codebase: One of the first challenges was getting familiar with a codebase as large as Valhalla. Before implementing anything, I had to understand how the different components interacted and how data flowed through the pipeline. A big part of the process was reading existing code and identifying patterns I could reuse, rather than introducing completely new approaches.

Limitations and future work

This is a first functional version. The known limitations are documented as TODOs in the code and in the docs, each with a plan for how it could be addressed.

Limitations

• Perimeter footways aren’t detected as mapped paths. A pedestrian way that runs exactly along an area’s boundary, or crosses it in a straight line with only two nodes, isn’t recognised as one, since it has no node strictly inside the polygon, so a traversal may be generated over it.

• Traversals generated from relations are unnamed. The name of an area mapped as a relation lives on the relation, not on its member ways. Since the name is currently taken from a member way, relation areas either inherit a member’s name or end up unnamed.

• Generated edges use generic attributes. Both traversal ways and re-emitted entrance nodes get a fixed set of pedestrian attributes rather than inheriting the area’s own tags.

• Only small areas get their perimeter back. When no traversal is generated, the perimeter is only restored for areas skipped for being too small. Areas skipped for other reasons, such as having no entrances, or having paths already mapped inside, are dropped entirely, even though some of them might still want a routable perimeter.

Future work

Each of the limitations above is a natural follow-up. This section outlines how each could be approached, as a starting point for future contributors.

• Detecting perimeter footways. The current detection relies on finding a node strictly inside the polygon, which misses ways that only touch the boundary. Adding a geometric check on the segments between consecutive perimeter hits, testing whether they run along the boundary or cross the interior, would flag these ways without depending on an interior node.

• Naming relation-based traversals. The relation name is available at parse time but isn’t carried forward. Storing it alongside the area relation data, and reading it when the traversal is generated, would let areas mapped as relations take the square’s name instead of a member way’s.

• Inheriting the area’s attributes. Rather than building traversal ways and entrance nodes from scratch, the attributes could be looked up from the source area and the original nodes and merged. The attributes are already on the source ways at that point, so carrying them through is mostly a matter of routing them through to where the synthetic ways are created.

• Restoring the perimeter more broadly. This one is more open and would need some investigation first: working out in which cases restoring the perimeter is actually desirable (small areas already do it, but areas skipped for other reasons, like having mapped paths inside, might benefit too), how to detect those cases, and then deciding per skipped area whether to give the perimeter back rather than only triggering on the size check.

• Turn-by-turn instructions for crossings. Since crossings are ordinary footway edges, they produce a sequence of small maneuvers. Tagging the traversal edges with a dedicated flag, or grouping them in the maneuver generation step, would let the router emit a single “cross the square” instruction.

Beyond those, there are a few internal refinements marked in the source or raised during review:

• Entrance distance tolerance. The tolerance for matching an entrance to its polygon is currently 0.1. This distance should ideally be zero, it would be worth investigating whether it can be tightened to an epsilon, or reworked so an exact value isn’t needed at all.

• RAII for GEOS pointers. The GEOS geometries are currently created and destroyed by hand. Wrapping them in a RAII type, as done elsewhere in the codebase, would make the cleanup automatic and safer.

• Unifying the chain-walking logic. The walk used for pruning the branches and the one used for stitching chains are nearly identical, and could be unified.

• Separating area ways into their own file. Area member ways are currently emitted into the same file as completely processed ways but in an intentionally incomplete state. Keeping them in a separate file would make the two clearly distinct and the pipeline easier to follow.

Acknowledgements

I don’t have enough words to express my gratitude to my mentors, Kevin Kreiser and Christian Beiwinkel were the best mentors I could have ever asked for. I’m extremely thankful for their guidance, patience and for making me feel encouraged and proud of every little step I was making. It’s incredible how much you can learn from people like them, who have been working on Valhalla for such a long time.

A shout-out also goes to Nils Nolde, who wasn’t my mentor but was really kind during the application process and throughout our interactions during the summer.

Also, I have to thank all the Valhalla and OpenStreetMap community, which, through the forum, diary entries, and the Valhalla repository, helped us to find some things we had to rethink or try in a different way.

This has been a life-changing process, it was a pleasure to get to know my mentors and this community. It’s the end of the program, but I’m sure not the last you’ll see of me around Valhalla.

8 days ago

Miercoles 26 de agosto de 2026. Se realizo: 1. Se agrega etiqueta de Condominio Tonsupa playa azul cerca de la calle Cervantes 2. Se agrega nombres de calles en Barrios vista al mar entre calles 3. Se corrige tramo de vía que corresponde a Av. Esmeraldas y no a Av. Atacames Desde el norte corresponde a Esmeralda y desde el sur corresponde a Atacames 4. Se agrega nombres de calles en las urbanizaciónes del Pacífico

a day ago

I have contributed several days but my contribution calendar has not been updated. I wonder what can I do about it?

a day ago

This is a generated report — written by the same agentic (Claude Code) workflow that made the edits described below, summarizing what it did. Numbers and links were pulled directly from the upload logs and cross-checked against the OSM API; flag anything that looks off.

Background

Belgium’s N-roads (national secondary roads) are tagged with ref=N<number> on the highway ways themselves, but many didn’t have a corresponding type=route / route=road / network=BE:N-road relation tying their segments together. This picks up from an earlier automated pass that got questioned on this forum — see the discussion here — and folds in the feedback from that thread.

Approach

1. Find missing refs. Query Overpass for every distinct ref value on Belgian highway ways matching the N-road pattern (N + 1-3 digits + optional letter suffix), and diff that against the refs that already have a BE:N-road route relation. Refs that look like mistagged local/vicinal road codes rather than real N-road signage (e.g. N027076, N617011, N836011) were excluded rather than turned into relations — 25 of those, left for manual review.
2. Order by connectivity, not Overpass return order. For each missing ref, fetch its matching ways and walk their shared endpoint nodes into actual connected chains, rather than leaving members in whatever order the query happened to return. This was the main fix from the community feedback — earlier relations all carried the same boilerplate fixme regardless of whether there was an actual problem.
3. Only flag real gaps. A relation only gets a fixme tag when its ways form more than one disconnected group — a genuine break in the route, worth a human look. Ordinary branching (slip lanes, dual-carriageway junctions, roundabout approaches) no longer trips a false-positive fixme.
4. One relation per changeset. Every relation is its own changeset, tagged created_by=make-route-rels, so each is individually reviewable/revertable.
5. Only ever create/reorder relations — never touch the underlying way tags.

Ran as a fully agentic workflow (Claude Code + an Overpass MCP + a small Node/OAuth2 upload tool), in batches of ~50 refs at a time, checked in on as it went.

Results

• 886 relations touched: 873 newly created (all the missing refs found), plus 13 retrofitted with proper connectivity ordering (N13, and the N151–N200 batch from the earlier round that had the same boilerplate-fixme problem).
• 34,426 total way-members across all of them.
• 477 relations (54%) came back as a single clean connected chain — no fixme needed.
• 409 relations (46%) have genuine gaps — 2 to 15 disconnected segments — now flagged with a specific “N disconnected segments” fixme instead of hidden or blanket-tagged.

Gap distribution Segments # of relations 1 (clean) 477 2 190 3 95 4 51 5 28 6 15 7 9 8 2 9 5 10 3 11 5 12 1 13 2 14 1 15 2 Largest relations Ref Relation Members N633 21284157 309 N368 21283854 269 N13 21252251 268 N15 21283629 266 N101 21283763 265 N211 21283534 262 N369 21283856 243 N253 21283565 233 N367 21283852 225 N719 21284246 219 Full list

All 886 relations, with member count and gap count, in one table:

Ref Relation Members Segments N1c 21283594 25 1 N1d 21283595 16 2 (gap) N2c 21283596 4 1 N2d 21283597 12 2 (gap) N3e 21283598 7 1 N3g 21283599 26 3 (gap) N3i 21283600 19 2 (gap) N3j 21283601 7 2 (gap) N4b 21283602 18 1 N4c 21283603 3 1 N4d 21283604 11 1 N4e 21283605 3 1 N4f 21283606 15 2 (gap) N4g 21283607 7 1 N4h 21283608 7 1 N4i 21283609 2 1 N4j 21283610 8 1 N4k 21283611 1 1 N4l 21283612 4 1 N5a 21283613 5 1 N5e 21283614 2 1 N5f 21283615 12 3 (gap) N5g 21283616 78 3 (gap) N5i 21283617 11 1 N7a 21283618 54 3 (gap) N7b 21283619 7 1 N7c 21283620 4 1 N9a 21283621 86 5 (gap) N9b 21283622 14 2 (gap) N9c 21283623 39 1 N9d 21283624 8 1 N9f 21283625 9 2 (gap) N9h 21283626 5 1 N9k 21283627 5 1 N9m 21283628 3 1 N13 (retrofit) 21252251 268 1 N15 21283629 266 7 (gap) N16a 21283630 13 1 N16b 21283631 13 1 N16c 21283632 7 1 N16d 21283633 4 1 N17a 21283634 7 1 N19d 21283635 6 1 N20a 21283636 4 1 N21b 21283637 5 1 N25a 21283638 12 2 (gap) N27a 21283639 6 2 (gap) N29a 21283640 12 2 (gap) N30a 21283641 7 1 N30b 21283642 27 1 N30c 21283643 2 1 N30y 21283646 7 1 N30z 21283647 5 1 N32b 21283648 40 1 N32c 21283649 14 1 N32d 21283650 6 1 N34a 21283651 69 2 (gap) N34b 21283652 25 1 N34c 21283653 17 2 (gap) N34f 21283654 13 1 N34i 21283655 2 2 (gap) N34y 21283656 47 1 N34z 21283657 18 1 N35b 21283658 6 1 N35c 21283659 5 1 N35e 21283660 2 1 N35f 21283661 16 2 (gap) N35g 21283662 11 1 N36a 21283663 42 1 N36b 21283664 14 1 N36c 21283665 6 1 N36d 21283666 34 2 (gap) N36e 21283668 35 2 (gap) N36f 21283669 3 2 (gap) N36g 21283670 5 1 N37b 21283671 30 1 N39a 21283672 7 1 N42a 21283673 23 1 N42b 21283674 4 2 (gap) N42c 21283675 16 1 N44a 21283676 11 1 N48b 21283677 30 2 (gap) N48c 21283678 13 1 N49a 21283679 22 2 (gap) N50a 21283680 5 1 N50d 21283681 33 1 N50f 21283682 11 1 N50g 21283683 23 2 (gap) N50h 21283684 11 1 N53B 21283685 1 1 N53a 21283686 1 1 N53b 21283687 4 1 N53c 21283688 6 1 N54a 21283689 11 2 (gap) N55b 21283690 17 1 N56b 21283691 7 1 N56c 21283692 12 3 (gap) N59b 21283693 23 1 N60a 21283694 5 1 N60b 21283695 42 4 (gap) N60c 21283696 21 1 N60d 21283700 19 2 (gap) N60e 21283701 29 3 (gap) N60f 21283702 4 2 (gap) N60g 21283703 5 1 N61A 21283704 1 1 N61a 21283705 10 2 (gap) N61b 21283706 27 1 N61c 21283707 1 1 N61e 21283708 6 1 N62a 21283709 5 1 N63a 21283710 4 1 N63b 21283711 2 1 N63c 21283712 11 2 (gap) N63d 21283713 18 1 N63e 21283714 3 1 N63f 21283715 1 1 N66a 21283716 7 1 N67a 21283717 5 1 N68a 21283718 4 1 N70a 21283719 23 1 N72a 21283720 28 2 (gap) N73b 21283721 48 1 N76b 21283722 27 1 N76h 21283723 37 2 (gap) N76j 21283724 4 1 N76k 21283725 2 1 N78a 21283726 27 2 (gap) N79a 21283727 14 1 N79b 21283728 19 1 N80a 21283729 11 1 N80b 21283730 2 1 N83a 21283731 9 2 (gap) N83b 21283732 21 3 (gap) N86b 21283733 15 1 N86c 21283734 20 2 (gap) N86f 21283735 8 1 N87a 21283736 6 1 N87b 21283737 13 1 N88a 21283738 6 1 N89c 21283739 13 1 N89z 21283740 6 1 N90A 21283741 2 1 N90C 21283742 4 1 N90a 21283743 24 2 (gap) N90b 21283744 13 4 (gap) N90c 21283745 22 8 (gap) N90d 21283746 21 7 (gap) N90e 21283747 5 1 N90g 21283748 10 1 N90h 21283749 29 1 N90z 21283756 13 1 N92A 21283757 8 1 N95A 21283758 9 1 N95B 21283759 3 1 N95d 21283760 21 2 (gap) N95e 21283761 2 1 N95f 21283762 1 1 N101 21283763 265 4 (gap) N106a 21283764 7 2 (gap) N110a 21283765 11 1 N114a 21283766 7 1 N114b 21283767 3 1 N151 (retrofit) 21283202 10 2 (gap) N152 (retrofit) 21283203 109 4 (gap) N153a 21283768 15 1 N156 (retrofit) 21283204 87 5 (gap) N162 (retrofit) 21283205 7 1 N165 (retrofit) 21283206 22 1 N171a 21283769 6 3 (gap) N173 (retrofit) 21283207 74 2 (gap) N174 (retrofit) 21283208 117 5 (gap) N177 (retrofit) 21283209 202 4 (gap) N183 (retrofit) 21283210 21 2 (gap) N184 (retrofit) 21283211 72 1 N186 (retrofit) 21283212 9 2 (gap) N200 (retrofit) 21283213 28 3 (gap) N201 21283512 57 1 N202 21283513 87 1 N203 21283514 21 3 (gap) N208 21283533 34 4 (gap) N211 21283534 262 6 (gap) N211a 21283535 2 1 N211b 21283536 9 1 N212 21283537 78 4 (gap) N214 21283538 10 1 N218 21283539 6 1 N219 21283540 29 2 (gap) N221 21283541 34 2 (gap) N222 21283542 30 3 (gap) N223 21283543 109 2 (gap) N224 21283544 23 2 (gap) N226 21283545 98 11 (gap) N227 21283546 196 6 (gap) N227C 21283547 2 1 N227a 21283578 1 1 N227b 21283548 12 2 (gap) N227d 21283549 2 1 N229 21283550 44 2 (gap) N232 21283551 17 4 (gap) N234 21283552 23 1 N235 21283553 55 2 (gap) N236 21283554 22 4 (gap) N237a 21283555 4 1 N238a 21283579 1 1 N239 21283556 28 2 (gap) N240 21283557 123 6 (gap) N241 21283558 17 4 (gap) N243a 21283559 12 2 (gap) N246 21283560 144 3 (gap) N249 21283561 9 1 N250 21283562 58 6 (gap) N251 21283563 94 2 (gap) N252 21283564 26 2 (gap) N253 21283565 233 13 (gap) N255 21283566 116 3 (gap) N256 21283567 40 3 (gap) N256a 21283568 43 5 (gap) N256b 21283569 41 3 (gap) N257 21283570 78 4 (gap) N258 21283571 17 1 N259 21283572 7 2 (gap) N260 21283573 70 10 (gap) N261 21283574 84 6 (gap) N262 21283575 31 3 (gap) N263 21283576 55 3 (gap) N264 21283577 47 2 (gap) N266 21283770 85 1 N266a 21283771 36 3 (gap) N266b 21283772 18 2 (gap) N266c 21283773 3 1 N266d 21283774 3 1 N267 21283775 86 3 (gap) N268 21283776 48 1 N269 21283777 28 2 (gap) N270 21283778 19 1 N272 21283779 98 2 (gap) N273 21283780 64 4 (gap) N276 21283781 43 3 (gap) N276a 21283782 3 1 N276b 21283783 11 1 N276c 21283784 1 1 N277 21283785 110 4 (gap) N278 21283786 28 3 (gap) N279 21283787 158 4 (gap) N280 21283788 84 5 (gap) N280a 21283789 3 1 N282 21283790 139 2 (gap) N283 21283791 55 1 N285 21283792 211 11 (gap) N286 21283793 24 2 (gap) N287 21283794 11 1 N290 21283795 201 5 (gap) N292 21283796 1 1 N301 21283797 63 1 N302 21283798 22 2 (gap) N302a 21283799 6 1 N303 21283800 135 3 (gap) N304 21283801 60 3 (gap) N305 21283802 21 2 (gap) N306 21283803 7 1 N307 21283804 33 1 N308 21283805 129 5 (gap) N309 21283807 53 1 N311 21283808 48 2 (gap) N312 21283809 23 1 N314 21283810 37 1 N315 21283811 31 1 N317 21283812 44 1 N318 21283813 105 1 N319 21283814 38 1 N320 21283815 15 4 (gap) N321 21283816 46 2 (gap) N322 21283817 31 1 N323 21283818 17 1 N323a 21283819 21 4 (gap) N323b 21283820 27 3 (gap) N324 21283821 41 2 (gap) N325 21283822 30 3 (gap) N326 21283823 28 1 N327 21283824 136 5 (gap) N327A 21283825 1 1 N327a 21283826 4 1 N330 21283827 69 4 (gap) N331 21283828 64 2 (gap) N332 21283829 54 3 (gap) N333 21283830 56 3 (gap) N336 21283831 64 2 (gap) N337 21283832 83 4 (gap) N338 21283833 24 2 (gap) N339 21283834 36 1 N340 21283835 14 2 (gap) N341 21283836 13 2 (gap) N343 21283837 7 1 N345 21283838 13 2 (gap) N346 21283839 37 1 N347 21283840 13 1 N351 21283841 39 2 (gap) N353 21283842 84 1 N355 21283843 64 5 (gap) N356 21283844 9 1 N356a 21283845 5 2 (gap) N358 21283846 83 3 (gap) N362 21283847 24 2 (gap) N363 21283848 53 2 (gap) N364 21283849 111 2 (gap) N365 21283850 80 2 (gap) N366 21283851 85 2 (gap) N367 21283852 225 3 (gap) N367c 21283853 20 1 N368 21283854 269 9 (gap) N368c 21283855 2 1 N369 21283856 243 4 (gap) N369a 21283863 4 1 N370d 21283864 8 1 N370z 21283865 17 1 N371 21283866 199 3 (gap) N372 21283867 17 1 N373 21283868 10 1 N374 21283869 68 2 (gap) N375 21283870 60 3 (gap) N376a 21283871 9 1 N377 21283872 88 4 (gap) N377a 21283873 15 1 N378 21283874 2 1 N379 21283875 33 1 N380 21283876 27 1 N381 21283877 28 3 (gap) N382a 21283878 8 1 N384a 21283879 3 1 N386 21283880 15 1 N388 21283881 9 1 N389 21283882 5 1 N390 21283883 15 3 (gap) N390a 21283884 3 2 (gap) N391a 21283885 8 1 N391b 21283886 5 1 N392 21283887 5 1 N393 21283888 11 1 N396 21283889 78 2 (gap) N397 21283890 106 1 N397z 21283891 4 1 N398 21283892 11 1 N399 21283893 109 2 (gap) N400 21283894 22 1 N400a 21283895 7 1 N402 21283896 1 1 N405 21283897 67 5 (gap) N406 21283898 71 4 (gap) N406a 21283899 20 1 N407 21283900 82 3 (gap) N407b 21283901 22 2 (gap) N408 21283902 9 1 N409 21283903 67 1 N410a 21283904 19 1 N411 21283905 69 1 N414 21283906 41 1 N416 21283907 84 3 (gap) N417 21283908 24 2 (gap) N419 21283909 127 2 (gap) N420 21283910 63 3 (gap) N424 21283911 68 1 N425 21283912 24 1 N430 21283919 53 2 (gap) N433 21283920 90 2 (gap) N435 21283921 84 3 (gap) N436 21283922 53 2 (gap) N437 21283923 171 13 (gap) N438 21283924 12 2 (gap) N439 21283925 27 1 N441 21283926 31 2 (gap) N442 21283927 78 1 N445 21283928 148 6 (gap) N446 21283929 67 2 (gap) N447 21283930 47 2 (gap) N448 21283931 53 4 (gap) N449 21283932 113 3 (gap) N450 21283933 61 1 N451 21283934 106 1 N451a 21283935 1 1 N453 21283936 68 1 N454 21283937 106 5 (gap) N454a 21283938 7 1 N457 21283939 43 1 N459 21283940 124 9 (gap) N460 21283941 89 3 (gap) N461 21283942 112 3 (gap) N462 21283943 155 4 (gap) N462b 21283944 16 1 N464 21283945 48 1 N465 21283946 44 1 N465a 21283947 10 2 (gap) N465b 21283948 2 1 N466 21283949 145 3 (gap) N466a 21283950 35 2 (gap) N467 21283951 49 1 N469 21283952 11 1 N470 21283953 39 2 (gap) N470a 21283954 18 1 N470b 21283955 5 1 N473a 21283956 11 1 N473b 21283957 9 1 N485 21283958 38 1 N493 21283959 50 1 N494 21283960 95 4 (gap) N495 21283961 64 5 (gap) N495a 21283962 27 1 N496 21283963 30 1 N497 21283964 22 5 (gap) N498 21283965 22 2 (gap) N499 21283966 133 3 (gap) N500 21283967 41 3 (gap) N501 21283968 16 1 N502 21283970 23 1 N503 21283971 23 2 (gap) N504 21283972 45 2 (gap) N505 21283973 50 4 (gap) N506 21283974 19 2 (gap) N507 21283975 76 1 N508 21283976 43 1 N509 21283977 48 3 (gap) N510 21283978 29 1 N511 21283979 57 7 (gap) N512 21283980 76 2 (gap) N513 21283981 43 5 (gap) N513a 21283982 7 1 N514 21283983 33 2 (gap) N514a 21283984 8 1 N514b 21283985 8 2 (gap) N515 21283986 81 5 (gap) N515a 21283987 1 1 N516 21283988 13 1 N516a 21283989 6 2 (gap) N517 21283990 26 1 N518 21283991 35 6 (gap) N519 21283992 20 1 N520 21283993 29 1 N521 21283994 16 2 (gap) N523 21283995 28 1 N524 21283996 67 3 (gap) N525 21283997 83 1 N526 21283998 94 4 (gap) N527 21283999 32 1 N528 21284000 27 2 (gap) N529 21284001 120 4 (gap) N531 21284002 4 1 N532 21284003 20 1 N533 21284004 57 3 (gap) N534 21284005 19 1 N534a 21284006 8 1 N535 21284007 58 6 (gap) N536 21284008 34 1 N537 21284009 5 1 N538 21284010 75 3 (gap) N539 21284011 14 1 N541 21284012 22 2 (gap) N543 21284013 24 1 N544 21284014 70 6 (gap) N545 21284015 29 5 (gap) N546 21284016 61 2 (gap) N547 21284017 95 9 (gap) N548 21284018 19 1 N549 21284019 60 5 (gap) N550 21284026 83 11 (gap) N552 21284027 199 11 (gap) N553 21284028 56 1 N554 21284029 19 1 N555 21284030 31 1 N556 21284031 32 1 N556f 21284032 11 1 N559 21284033 45 1 N561 21284034 73 7 (gap) N561a 21284035 2 1 N562 21284036 39 1 N562a 21284037 1 1 N563 21284038 62 2 (gap) N564 21284039 8 2 (gap) N565 21284040 2 1 N566 21284041 2 1 N567 21284042 11 2 (gap) N568 21284043 79 6 (gap) N568B 21284044 6 1 N568C 21284045 1 1 N568D 21284046 4 2 (gap) N568E 21284047 1 1 N568a 21284048 46 2 (gap) N568c 21284049 2 2 (gap) N569 21284050 118 7 (gap) N569a 21284051 9 1 N569b 21284052 23 3 (gap) N570 21284053 19 1 N571 21284054 24 1 N572 21284055 48 3 (gap) N573 21284056 32 3 (gap) N574 21284057 43 4 (gap) N575 21284058 15 3 (gap) N576 21284059 29 3 (gap) N576a 21284060 5 1 N577 21284061 25 1 N578 21284062 11 1 N579 21284063 74 1 N579a 21284064 10 1 N580 21284065 4 1 N581 21284066 15 3 (gap) N582 21284067 60 3 (gap) N583 21284068 93 1 N583a 21284069 11 2 (gap) N584 21284070 33 2 (gap) N585 21284071 14 2 (gap) N586 21284072 57 7 (gap) N586b 21284073 20 2 (gap) N586c 21284074 1 1 N587 21284075 65 6 (gap) N588 21284081 74 1 N588a 21284082 75 1 N589 21284083 75 5 (gap) N589a 21284084 18 2 (gap) N591 21284085 44 1 N592 21284086 8 1 N593 21284087 41 1 N594 21284088 5 1 N595 21284089 11 1 N596 21284090 11 1 N597 21284091 8 1 N598 21284092 1 1 N599 21284093 4 1 N604 21284094 143 2 (gap) N606 21284095 60 2 (gap) N607 21284096 18 2 (gap) N607a 21284097 15 1 N608a 21284098 2 1 N610C 21284099 3 2 (gap) N610a 21284100 3 1 N610b 21284101 3 1 N610c 21284102 3 1 N611 21284103 9 1 N612 21284104 14 1 N614 21284105 121 15 (gap) N615 21284106 25 3 (gap) N616 21284109 22 1 N617 21284110 191 15 (gap) N617A 21284111 8 3 (gap) N617C 21284112 2 1 N617a 21284113 3 2 (gap) N617b 21284114 6 1 N617d 21284115 15 1 N617e 21284116 9 1 N617g 21284117 16 1 N618 21284118 161 4 (gap) N618a 21284119 20 1 N619a 21284120 2 1 N619b 21284121 1 1 N620 21284122 39 2 (gap) N621 21284123 88 2 (gap) N622 21284124 42 1 N623 21284125 10 1 N624 21284126 44 1 N625 21284127 7 1 N626 21284128 91 4 (gap) N627 21284129 150 4 (gap) N627a 21284130 10 1 N627b 21284131 5 2 (gap) N627c 21284132 1 1 N627d 21284143 2 1 N627e 21284144 7 1 N627f 21284145 26 1 N628 21284146 1 1 N629 21284147 112 2 (gap) N629a 21284148 1 1 N630 21284149 39 2 (gap) N630a 21284150 4 1 N630b 21284152 8 3 (gap) N630c 21284153 72 14 (gap) N630d 21284154 2 1 N631 21284155 15 2 (gap) N632 21284156 122 10 (gap) N633 21284157 309 11 (gap) N633a 21284158 11 1 N633b 21284159 6 1 N633c 21284160 39 1 N633d 21284161 33 1 N634 21284162 22 1 N635 21284163 48 1 N635z 21284164 27 1 N636 21284165 49 2 (gap) N637 21284166 107 9 (gap) N637a 21284167 32 4 (gap) N638 21284168 81 2 (gap) N639 21284170 49 4 (gap) N640 21284171 93 3 (gap) N640a 21284172 2 1 N640b 21284173 21 1 N641 21284174 64 3 (gap) N642 21284175 103 6 (gap) N642a 21284176 18 2 (gap) N643 21284177 73 4 (gap) N643a 21284178 13 1 N643b 21284179 7 1 N644 21284180 22 2 (gap) N644a 21284181 7 1 N645 21284182 91 3 (gap) N646 21284183 41 1 N646a 21284184 11 1 N647 21284185 68 1 N648c 21284186 5 1 N649 21284187 15 2 (gap) N650 21284188 20 1 N651 21284189 81 1 N652 21284190 85 2 (gap) N653 21284191 69 4 (gap) N653c 21284192 16 1 N654 21284193 34 1 N657 21284194 94 1 N657b 21284198 5 1 N658 21284199 69 2 (gap) N659 21284200 72 4 (gap) N660 21284201 17 1 N660a 21284202 5 1 N663 21284203 54 1 N666 21284204 53 2 (gap) N667 21284205 32 1 N669 21284206 13 1 N670 21284207 33 3 (gap) N672 21284208 41 2 (gap) N673 21284209 16 2 (gap) N674 21284210 25 1 N675 21284211 98 4 (gap) N675a 21284212 6 2 (gap) N675c 21284213 22 4 (gap) N676 21284214 170 5 (gap) N677 21284215 127 10 (gap) N677a 21284216 12 3 (gap) N678 21284217 71 4 (gap) N679 21284218 4 1 N679a 21284219 1 1 N680 21284220 58 5 (gap) N681 21284221 41 2 (gap) N683 21284222 84 4 (gap) N683a 21284223 4 1 N684 21284224 102 9 (gap) N685 21284225 6 2 (gap) N686 21284226 9 3 (gap) N689 21284227 30 2 (gap) N690 21284228 57 3 (gap) N692 21284229 9 1 N693 21284230 31 1 N695 21284231 10 1 N696 21284232 40 1 N696a 21284233 4 1 N697 21284234 76 2 (gap) N698 21284235 24 1 N701 21284236 13 1 N701a 21284237 12 3 (gap) N702 21284238 156 4 (gap) N716 21284239 86 2 (gap) N716a 21284240 16 1 N717 21284241 143 5 (gap) N717a 21284242 4 1 N717b 21284243 14 2 (gap) N717c 21284244 18 1 N718 21284245 44 2 (gap) N719 21284246 219 5 (gap) N719a 21284247 5 1 N722 21284253 88 2 (gap) N723a 21284254 2 1 N724 21284255 54 4 (gap) N725 21284256 217 7 (gap) N726 21284257 91 4 (gap) N729 21284258 94 4 (gap) N730c 21284259 34 1 N732 21284260 5 1 N735 21284261 1 1 N736 21284262 13 1 N739 21284263 30 1 N739a 21284264 6 1 N743 21284265 27 2 (gap) N744 21284266 132 1 N745 21284267 69 3 (gap) N748 21284268 130 4 (gap) N750 21284269 96 3 (gap) N752 21284270 41 2 (gap) N753 21284271 18 1 N754 21284272 155 4 (gap) N754a 21284273 14 1 N755 21284274 65 1 N756 21284275 23 1 N758 21284276 53 2 (gap) N759 21284277 69 2 (gap) N760 21284278 34 1 N765 21284279 26 1 N767 21284280 14 1 N771 21284281 102 2 (gap) N772 21284282 31 1 N775 21284283 9 1 N777 21284284 53 4 (gap) N779 21284285 83 3 (gap) N784 21284286 91 1 N789 21284287 37 1 N796 21284288 6 1 N800 21284289 11 1 N801 21284290 66 2 (gap) N802 21284291 5 1 N803 21284292 47 3 (gap) N805 21284293 6 1 N806 21284294 55 1 N807 21284295 80 5 (gap) N808 21284297 60 3 (gap) N809 21284298 4 1 N810 21284299 44 2 (gap) N811 21284300 11 2 (gap) N812 21284301 24 1 N813 21284302 47 2 (gap) N814 21284303 4 1 N815 21284308 16 1 N816 21284309 31 2 (gap) N817 21284310 30 1 N818 21284311 10 1 N820 21284312 10 1 N821 21284313 17 1 N822 21284314 84 2 (gap) N822a 21284315 6 1 N823 21284316 41 2 (gap) N824 21284317 6 1 N825 21284318 41 1 N826 21284319 174 6 (gap) N827 21284320 109 3 (gap) N828 21284321 42 2 (gap) N828z 21284322 7 1 N829 21284323 32 2 (gap) N831 21284324 29 1 N832 21284325 5 1 N833 21284326 128 2 (gap) N834 21284327 67 3 (gap) N834a 21284328 2 1 N834b 21284329 1 1 N835 21284330 73 2 (gap) N836 21284331 42 1 N837 21284332 5 1 N838 21284333 82 3 (gap) N840 21284334 57 3 (gap) N840a 21284335 18 1 N841 21284336 73 2 (gap) N842 21284337 1 1 N843 21284338 50 3 (gap) N844 21284339 15 1 N845 21284340 35 3 (gap) N846 21284341 52 2 (gap) N847 21284342 21 1 N848 21284343 129 3 (gap) N849 21284344 79 3 (gap) N850 21284345 39 1 N851 21284346 2 1 N852 21284347 13 2 (gap) N853 21284348 115 3 (gap) N854 21284349 28 1 N855 21284350 5 1 N856 21284351 56 2 (gap) N857 21284352 15 1 N858 21284353 48 1 N859 21284354 3 1 N859a 21284355 2 1 N859b 21284356 1 1 N860 21284357 60 1 N860a 21284377 2 1 N861 21284378 14 1 N862 21284379 19 1 N863 21284380 11 1 N864 21284381 7 1 N865 21284382 34 1 N866 21284383 3 1 N867 21284384 12 1 N868 21284385 32 1 N870 21284386 57 1 N871 21284387 14 1 N871a 21284388 1 1 N872 21284389 15 1 N873 21284390 28 1 N874 21284391 32 2 (gap) N875 21284392 39 3 (gap) N875a 21284393 3 1 N876 21284394 35 1 N877 21284395 8 1 N878 21284396 22 3 (gap) N878a 21284397 2 1 N878b 21284398 13 1 N879 21284399 102 6 (gap) N880 21284400 1 1 N881 21284401 40 5 (gap) N882 21284402 25 2 (gap) N883 21284403 50 4 (gap) N883a 21284404 6 1 N883b 21284405 5 1 N883c 21284406 3 1 N884 21284407 96 5 (gap) N885 21284408 45 1 N885a 21284409 8 2 (gap) N886 21284410 35 2 (gap) N887 21284411 13 2 (gap) N888 21284412 25 1 N889 21284413 50 1 N890 21284414 12 1 N891 21284415 69 2 (gap) N892 21284416 19 3 (gap) N893 21284417 24 1 N894 21284418 65 2 (gap) N895 21284419 39 3 (gap) N896 21284420 20 1 N897 21284421 57 2 (gap) N898 21284422 27 1 N899 21284423 91 4 (gap) N902 21284424 8 2 (gap) N905 21284425 23 1 N907 21284426 12 1 N908 21284508 14 1 N909 21284509 13 1 N910 21284510 27 2 (gap) N911 21284511 72 5 (gap) N911a 21284512 2 1 N912a 21284513 1 1 N912b 21284514 14 2 (gap) N912c 21284515 1 1 N913 21284516 22 2 (gap) N914 21284517 49 3 (gap) N915 21284518 30 2 (gap) N918 21284519 25 3 (gap) N919 21284520 6 1 N920 21284521 15 2 (gap) N921 21284522 112 12 (gap) N922 21284523 59 3 (gap) N923 21284524 18 1 N925 21284525 12 1 N928 21284526 38 2 (gap) N929 21284527 114 5 (gap) N929a 21284528 8 2 (gap) N930 21284529 69 4 (gap) N931 21284530 21 3 (gap) N932 21284531 70 3 (gap) N933 21284532 12 1 N935 21284533 85 1 N936 21284534 83 7 (gap) N937 21284535 68 2 (gap) N938 21284536 75 3 (gap) N939 21284537 126 7 (gap) N940 21284538 12 1 N941 21284539 30 6 (gap) N942 21284540 141 8 (gap) N942a 21284541 10 1 N943 21284542 6 1 N944 21284543 5 1 N945 21284544 48 1 N946 21284545 39 1 N947 21284546 82 3 (gap) N947a 21284547 5 1 N947c 21284548 12 1 N948 21284549 23 1 N949 21284550 72 3 (gap) N952 21284551 52 2 (gap) N953 21284552 12 1 N954 21284553 29 3 (gap) N955 21284554 11 2 (gap) N957 21284555 17 3 (gap) N958 21284556 29 1 N958a 21284557 5 1 N959 21284561 38 1 N961 21284562 17 1 N963 21284563 10 1 N964 21284564 41 3 (gap) N966 21284565 38 1 N967 21284566 10 1 N969 21284567 4 1 N971 21284568 51 1 N973 21284569 5 1 N975 21284570 66 2 (gap) N977 21284571 78 2 (gap) N978 21284572 73 5 (gap) N978a 21284573 9 2 (gap) N981 21284574 21 2 (gap) N982 21284575 32 2 (gap) N983 21284576 95 3 (gap) N983a 21284577 1 1 N988 21284578 124 4 (gap) N989 21284579 20 1 N990 21284580 47 2 (gap) N991 21284581 13 1 N992 21284582 10 1 N998 21284583 17 2 (gap) The 25 excluded refs

These didn’t get a route relation, since they don’t look like real N-road signage. Checked each one’s actual ways — most turn out to be *_link ways (motorway/trunk/secondary/tertiary/primary link roads, i.e. interchange ramps and slip roads), which points to these being junction/ramp numbering codes rather than N-road refs — plausibly something like exit or ramp identifiers that happen to start with “N” and a number, coincidentally matching the N-road regex. One (N030d) is a tertiary road with normal street names (Rue Georges Piret, Rue de l’Enseignement, Rue du Rivage) across several unrelated ways, which looks like a plain tagging mistake instead. N905011 is odder still — it’s a secondary way (not a link) whose name tag is literally also N905011.

Ref Example way highway Note N027076 47070730 motorway_link ramp/junction code, not N-road N030d 416466736 tertiary normal street (“Rue Georges Piret”), mistagged ref N052025 371537051 trunk_link ramp/junction code N089013 5028984 primary_link ramp/junction code N089027 25303832 trunk_link ramp/junction code N089141 126269936 secondary_link ramp/junction code N617011 28659125 secondary_link ramp near N617 (Boulevard d’Avroy, Liège) N617031 151233772 secondary_link ramp near N617 (Quai de Rome) N617032 28100307 secondary_link ramp near N617 (Quai de Rome) N617035 28659571 secondary_link ramp near N617 (Quai de Rome) N617036 28659535 secondary_link ramp near N617 N629011 150932796 secondary_link ramp near N629 (Route de la Gileppe) N629014 150932883 secondary_link ramp near N629 N629015 150932886 secondary_link ramp near N629 N629016 150932784 secondary_link ramp near N629 N680011 5559487 secondary_link ramp near N680 N680014 167790022 secondary_link ramp near N680 N680015 30355033 secondary_link ramp near N680 N680018 30355035 secondary_link ramp near N680 N836011 98391019 tertiary_link ramp near N836 N836012 98391020 tertiary_link ramp near N836 N836015 1246254920 tertiary_link ramp near N836 N836016 98391021 tertiary_link ramp near N836 N839001 703197297 primary_link ramp/junction code N905011 161480554 secondary not a link road; name tag is also literally “N905011” What’s next

The ~409 flagged gaps are genuine candidates for review — either the ref really is discontinuous on the ground, or there’s a missing/mistagged way segment somewhere in between. Not planning to auto-fix these; they’re flagged so a human (possibly with local knowledge) can look. The 25 excluded refs above are also open for anyone who wants to dig into what they actually represent and fix the underlying way tags.

Feedback welcome, here or in the original thread.

a day ago

רציתי רק להוסיף שביל, אבל העורך מתלונן שהשביל חוצה בניין. הנתונים על רקע העורך היו מתצלומים של בינג. אז אמרתי, במקום להזיז את השביל, אנסה להזיז את הבניינים. כי באמת גם אם זה טעות, מה זה כבר בשביל ניווט בסיסי עוד כמה מטרים. (אני לא מניח שהמפה משמשת מהנדסים ואדריכלים שאמורים לסמוך על הקואורדינטות המדוייקות כאן…). אחר כך ראיתי שהתצלומים אינם שווים בכל המקורות, אבל גם לפי מקורות אחרים, מה שעשיתי הוא תיקון! מעניין מה גרם למי ששרטט את הקווים לסטות בכל הרחוב. אולי יש מקורות מוסמכים יותר שאני לא מכיר? (לי אין מכשיר GPS) אבל בשאר האיזור לא היה כך.

3 days ago

Found by Wermak - Exit on A30 - Rheine-Kanalhafen - supposed to be only closed until May, stayed with "access=no" a little longer.

Now its fixed again thanks to changeset 187937745

♦

4 days ago

Thanks to the work of several contributors, the usage of name:fur tag in OpenStreetMap is constantly increasing and there is now a pretty good coverage of Friuli region at place level (and even down to street-level in some parts of it). This tag represents a name in Friulian language, mainly spoken in north-east Italy.

This tag is visible today in a dedicated rendering (which I created) on mapefurlane.eu and in the various multi-lingual maps like the great Americana.

Apart from the maps, another interesting use of this data is to have lists of toponyms. For Friulian language, there is already a list provided by an official organization, but besides not being very detailed, it’s also quite static (PDF). So I wanted to have something better than that by leveraging all OSM data.

My main goal then was to create a searchable web page that could show the toponyms of Friuli historical region, not only in Friulian, but also in all recognized languages, i.e. Friulian, Italian, German and Slovenian. The list should be updated automatically from OSM data.

What is DuckDB

DuckDB is an open source in-process SQL OLAP database management system. It has a builtin spatial extension that can import PBF files which can be then queried using SQL syntax.

Using DuckDB with OpenStreetmap

Since I already had a daily pipeline (GitHub Action) to update Mape Furlane that used a PBF extract as input, integrating DuckDB there was immediate: just adding the single binary, loading the PBF and then all the data was available for querying.

From that I added a few SQL queries visible on github.com/andreadecorte/mapefurlane/tree/main/scripts/duckdb that generate 2 output files: 1. all places with name:fur tag and all the other name: tags (name:it, name:de, name:sl) 2. all places in the area without a name:fur tag with a Markdown output (to help increase the coverage)

The output of the first query is stored in a CSV file which is then displayed in a sortable and searchable table visible here. This is as far as I know the best multi-lingual list available online for toponyms in Friuli region. And as mentioned, it has daily updates from OSM data. As of August 2026, it shows 2370 place names.

Conclusion

This is just scratching the surface with a simple example, but DuckDB is really an awesome tool that can be used to analyze OSM data without complicated setups. Everything described in this entry is available in github.com/andreadecorte/mapefurlane if you are interested in digging deeper.

4 days ago

Doom Scrolling through aerial images of Canada revealed this to me:

♦

And for a millisecond I wondered how this could be mapped. Maybe tourism=attraction? 🤪

5 days ago

Being a YouthMapper?

♦ For some, it may mean learning how to create and contribute to OpenStreetMap but it goes beyond putting roads, buildings and places on a map. It is about understanding the value of the data we create, building communities that can sustain themselves, and knowing the opportunities that come with being part of a global mapping network. ♦

It was with this in mind that I had to engage with the UEW YouthMappers with Enock Seth, for an interactive session covering: 1. OpenStreetMap and Data Quality 2. Chapter Sustainability, and the Worth of Being a #YouthMapper.

The session covered not only what OSM is, but also why it matters and how YouthMappers can move from being ‘hit and run’ contributors to becoming active and responsible members of the open mapping community. Every edit contributes to a global database that is used by researchers, humanitarian organizations, communities, governments the list goes on… So it’s important to prioritize accuracy, completeness, and responsible mapping practices. ♦

As YouthMappers, we therefore have a responsibility to ask ourselves not only: “How much have I mapped?” but also “How good is the data I have contributed?”

and the good thing is that the community provides opportunities to #network, collaborate, lead projects, develop technical skills, participate in #humanitarian initiatives, connect with professionals, and discover career pathways in the geospatial field and beyond! ♦

Now, the question is not “What can I gain from YouthMappers?” It is also “What can I contribute, and what can I become through YouthMappers?”

Questions left for you to answer. ♦

5 days ago

My Google Summer of Code 2026 project was Category Support in Nominatim.

The goal was to replace Nominatim’s single class/type representation with a proper categories field so that one OSM object can carry multiple categories. For eg, an object tagged as both a hotel and a restaurant can now be represented in one row with categories such as:

osm.tourism.hotel
osm.amenity.restaurant

What was completed

• Added the PostgreSQL ltree[] categories column to the main Nominatim tables.
• Generated multiple categories from OSM tags during import while keeping the existing class and type fields for compatibility.
• Updated ranking, triggers, migrations, and related database logic to use categories.
• Replaced the old place_classtype_* search tables with category-based search using indexed queries.
• Removed the old place_classtype_* table creation and maintenance code.
• Added category filters to the search API.
• Updated the SQLite adaptor and tests for category data.
• Updated the documentation for the category system and its API behaviour.

Pull requests

• #4106: Add ltree categories column for multi-tag OSM object support - merged
• #4146: Use ltree categories column instead of place_classtype tables - merged
• #4163: Remove the place_classtype tables - merged
• #4164: Add category filters to the search API - merged
• #4166: Update the documentation for the category series - documentation PR

Querying by category

The search API can now accept category filters. For example:

/search?q=restaurant+Berlin&include=osm.amenity.restaurant
/search?q=Berlin&include=osm.amenity
/search?q=hotel+Berlin&include=osm.tourism.hotel&include=osm.amenity.restaurant
/search?q=restaurant+Berlin&exclude=osm.amenity.fast_food

A parent category such as osm.amenity can match categories below it, so a query can include restaurants, cafes, bars, and other amenities without listing every child category separately.

Acknowledgements

I would like to thank my mentors, Sarah Hoffmann (@lonvia) and Marc Tobias (@mtmail), for their guidance, reviews, and support throughout the project. I am also grateful to everyone who contributed feedback and discussions during the implementation.

Thank you to OpenCage for sponsoring the development server used for the planet-scale database setup, migrations, benchmarking, and testing. I would also like to thank Google Summer of Code and the OpenStreetMap Foundation for making this project possible.

More details

• Project introduction
• GSoC midterm report
• GSoC project discussion thread

6 days ago

I need to vent for a minute.

Aligning aerial imagery terrifies me. I feel like no matter what I do, I will be off by a little bit. Whenever I come across a place where buildings are mapped and are a little bit off from the aerial imagery I’m using, I think to myself “I should probably align my imagery with those buildings,” but then I look at the primary road the buildings are right next to and realize that it is aligned with how my aerial imagery is right now. And then I see a cluster of features made 9+ years ago which is nowhere close to being aligned with my imagery and I question whether all of my contributions have been miles off of the correct location and if I’ve accidentally been vandalizing hundreds of places across Virginia without even knowing. But the worst feeling is when the same aerial imagery layer has its tiles slightly misaligned from the one right next to it, so I have to make the decision on which tile I should align all my changes with.

How can I achieve peace when it comes to aligning aerial imagery?

6 days ago

OpenStreetMap Foundation is pleased and proud to announce that Proton AG has been recognised as a Platinum Corporate Member, following two donations over the past two years totalling around €70,000.

Proton came to us with unsolicited donations both times. They believe in our project, the Foundation, but most importantly, our community. To quote them directly, “We truly value the partnership with OpenStreetMap”.

These donations, however, were not accidental. The values of the two organisations do align very well on privacy. OSMF values and recognises the privacy of our contributors. More than 10 years ago, we adjusted our consitution to allow community members to become a part of the OSMF, to vote for the board of directors, to financially support the Foundation, without requiring them to give up personally identifying information like a name or address. We recognise there are many good reasons why someone wouldn’t want everything to be recorded. Proton is in the business of offering privacy-respecting emails, VPNs, storage tools, video conferencing and office tools that don’t share your data with anybody, not even Proton themselves. The alignment between us isn’t something either of us had to explain to the other. Maybe they can offer privacy respecting maps too!

OpenStreetMap runs the largest open geographic dataset in the world, built by volunteers and used by humanitarian responders and some of the largest technology companies on the planet. OSM is free to use but running OSM costs money to pay for the servers, infrastructure, and the people who keep it working. Most of that money comes from corporate members who support the project and who subscribe to several sponsorship tiers. Proton gave us unconditional money and didn’t ask for anything in return. We really wanted to acknowledge the gift so, noting that their donations put them over our Platinum tier, our highest level of corporate membership, we have awarded them Platinum status in recognition of their awesome support.

Thank you, Proton.

7 days ago

What is the Local Chapters & Communities Congress?

The Local Chapters and Communities Congress 2026 (LCCC 2026) is a virtual event where leaders and members of various OSM communities, whether they are officially recognized Local Chapters of the OSM Foundation or just a regular user group of OSM mappers, come together to share stories and learn from each other. Each year we convenet to see what kinds of organizational efforts we can share together to support and grow our mapping communities. You can see LCCC notes and the full agenda/more info on the wiki page.

What did we discuss?

The group met on a Saturday, March 28, and over the course of 2 hours more than 30 particants joined the Congress from Italy, Indonesia, Greece, the USA, Belgium, Kenya, Canada, Brazil, Malawi, and more! To kick things off, the group went around the room and the participants shared some things their communities were working on. This included mapping rivers and streams in the Philippines, mapping toponyms in Indonesia, Spain having their first SOTM, mapping in Greece, work of the MapRVA group in Richmond VA USA, mapathons in Kenya, mapping in a shareable format for Quebec, and more fun things.

An update from the OSMF Board

In the next part of the event, members of the OSMF Board shared information about the OSMF and what things they have been up to over the year. In 2025 it welcomed new corporate members (e.g., Niantic Spatial, Regione Marche) and secured a Sovereign Tech Fund grant of €384,000 and welcomed AC3 in Colombia as a new local chapter. They are presently fundraising for an additional operations position, planning a Madrid board F2F, establishing a Belgium subsidiary, and organizing SotM 2026 in Paris (Aug 28–30). Catch up with them at the Board AMA in Paris in August!

Open Discussion: Overcoming Challenges in OSM

The next part of the congress was time for the participants to share perspective and experience, with some questions as guidance. The LCCWG used the Menti tool to get feedback asynch from participants and then space was held to discuss. You can see the full notes at this Hackpad.

If a new mapper asked you ‘what’s the hardest part about being in the OSM community’ what would you say?
Answers included challenges with language, unclear entry points, and feeling unwelcome in the community. Here are a few quotes:

• Documentation mostly in English
• Hard to explain why OSM is needed when Google Maps, Waze & Apple Maps already exist
• Not being demotivated by expert mappers who might “yell” at them for doing mistakes while mapping
• Encountering negative/unproductive discourse in OSM fora, which can be discourage participation from new users
• If you are not already technologically literate, it’s a lot to learn and unclear where to start

What makes it hard to grow or sustain your community?
Many participants found it hard to find time or funding to organize events and projects, and find it difficult to connect with mappers across a region. Here are a few quotes:

• The distributed nature of the work can make it hard to reach out to people in the region. I feel we could havea better integrated tool to talk to local mappers directly.
• Even in English, it’s difficult to find good resources like tutuorials for getting people started with mapping.
• Volunteer time is in the cracks between ‘more serious’ work. So while it is easy to get new folks in the community it’s hard to get consistent investment over longer time periods.
• Most members from the community prefer money-yielding activities and the idea of volunteer driven initiatives are not so welcomed.

Is there a gap between the ‘global OSM’ and your local reality? Where do you feel it?

• Yes, in tagging practices and how to adapt to the local reality
• There is a gap. People are drawn to local and immediate concerns by default and it’s hard to make people excited about global concerns and problems outside of conferences like SotM.
• Core infrastructure needs work and innovation, and OSMF seems to struggle making progress. We need more transparency and openness to community input. Local communities need to shape our shared website.

What support do you wish the OSMF or the wider community provided but doesn’t?
Answers to this question mentioned funding, appreciation, clear leadership, and a more friendly community space. Here are additional quotes:

• Make sure the core software project are active and support/discuss with the community
• Technical & practical starting packages for community building
• A mix of more formal and informal meetups, from “let’s hear a presentation about the person’s mapping project” to “let’s meet at a bar and hang out as friends”

What are ways you get your community together?
Answers to this question included virtual mappy hours, annual in person events/sotms, social media & chat groups for messages and announcements, and organized trainings. Here are a few quotes:

• Online meetings, and make them useful for both new and experienced users so we all learn from each other
• Daily communication via chat makes us feel close between bigger events
• Doing projects with free participation w/ a co-work mentality

What ideas do you have to help grow and sustain OSM?
This final question brought in a lot of great ideas. You can see them all in the graphic below.
♦
♦

How to Participate in the Local Chapters & Communities Working Group

As you can see, the LCCC is for everyone to share ideas and meet fellow OSM enthusiasts from around the world. And we’d love for you to join us! Here are a few ways to get involved.

1. Join the upcoming in person LCCC at State of the Map in Paris, France on August 28
2. Join a monthly LCCWG meeting. Contact local@osmfoundation.org. We meet at 10amET /14:00UTC first Thursday of the month
3. Help plan the next virtual LCCC in March 2027 – and join the conversation!

Thanks, hope to see you soon!

8 days ago