We are happy to announce the deployment of Vector Tiles on OpenStreetMap Foundation servers and the publication of the layer on the OSM website! We have been working hard to bring you a fresh look to OSM data, paired with exciting technological upgrades.

Work has been progressing since last year. In June 2024 we shared progress, including the launch of the vector tiles demo site, as well as details on the technical background on the tools being used. Since then we have put the tile generation process through months of testing, focused on reliability and speed improvements, and gotten ready for full production use.

Now, with integration of the vector tiles as a feature layer on the OpenStreetMap website, mappers and visitors get a visual layer that is sharper and quicker, based on an entirely new backend.

A major benefit of vector tiles is adaptability, so developers can leverage this vector source to develop their own styles based on the existing Shortbread styles or write a new one and use the new OSMF-hosted tiles. To use OSMF vector tiles in a project, in a development or production environment, consult the Vector Tile Usage Policy. Note that the policy may be subject to change to address any issues that come up after this launch.

From this point, you can expect further evolution of the Shortbread spec and styles. Input on the direction, ideas, and issues with OSMF vector tiles are welcome. Share in the appropriate repository: spirit for styles, tilekiln for tile generation, and shortbread-tiles for the tile content specification.

Al Nabi Colony, Gujrat, Punjab, Pakistan Sells groceries, snacks, and daily household items. This is a physical and actively operating business.

10.77646948898277, 106.70553100234541 QPG4+27 Quận 1, Hồ Chí Minh, Việt Nam

April 15–19, 2025, proved to be a special landmark in my mapping experience when I participated in the OSM Spring Mapathon 2025, sponsored by Youth Innovation Lab. I am excited to announce that I won the Beginner Category for 22,922 map changes!

This acknowledgement is meaningful to me—not only as a personal achievement, but also as a personal reminder of my growth since first hearing about OpenStreetMap (OSM) during 2021. At that time, OSM was merely another name, still learning its way into my periphery. Little did I realize the meaning that OSM would take on as an important part of my learning and contribution trajectory.

I committed a certain amount of time each day during the Mapathon to updating map data. Anything from adding roads, perfecting building footprints, or fixing map glitches and errors. Each change adding to a sense of satisfaction that somewhere someone would benefit from finally going through something that they could map out into a community, and their community becoming visible, sharing their data.

The event itself was inspiring. While Youth Innovation Lab was the primary host, the Mapathon brought together fellow mappers from across the land, and beyond. Each day’s schedule created an exciting and competitive environment that made staying sedimentary contagious.

Though I did not expect to win the Beginner Category, I am even more so grateful. The motivation of this experience is further proof that with the appropriate due diligence, sprinkling curiosity and learning, anything is possible!

HOT#OSM#Youth Innovation Lab# OSM Spring Mapathon2025

아파트 건물의 이름을 생성할 때 어떻게 해야 하나요 1. 000동 2. 000(동 없이 숫자만)

То самое письмо:

Первые кривые домики:

Первое робкое сообщение в Telegram-чате:

И к чему это привело:

Такие дела.

한국어(Korean)

제가 방금 OpenStreetMap wiki에 계정을 만들었는데, 편집할 권한이 없다고 뜹니다. 제가 문서를 편집하고 번역을 하기 위해서는 어떻게 해야 할까요?

Translated English

I just created an account on the OpenStreetMap wiki, but it says I don’t have permission to edit. What do I need to do to edit and translate articles?

Vitima de assedio financeiro, fisico, intelectual, moral sem recursos vivendo com invasão de empresa pirata, peco desesperadamente a remoção de idoso usuário de produtos ilícitos urgente

IS_WIM_4

대충만들었어요

https://ifh.cc/v-9nv75s

Hi guys!

Quick midterm update from me! Just as a little refresher, my name is Anqi and I’ve been working on the Transliteration of Search Results project this summer.

Time has really flown by and we are at the halfway point! Here I hope to give a summary of the work that’s been done so far, as well as what I hope to accomplish during the next part of the summer! We want to be able to return the transliterated name as a field during search results, with a proof of concept shown here! We can see in this proof of concept that the results are as expected, with the addition of one transliterated name field.

{
"place_id":100067,
"licence":"Data © OpenStreetMap contributors, ODbL 1.0. http://osm.org/copyright",
"osm_type":"way",
"osm_id":1307932969,
"place_rank":30,
"category":"amenity",
"type":"school",
"importance":-0.004452559995167061,
"addresstype":"amenity",
"name":"丹东市第六中学",
"display_name":"丹东市第六中学, 七纬路, 站前街道, 丹东市, 振兴区, 118000, 中国",
"transliterated_name":"Dan Dong Shi Di Liu Zhong Xue, Qi Wei Lu, Zhan Qian Jie Dao, Dan Dong Shi, Zhen Xing Qu, 118000, Zhong Guo",
"bbox":[124.3804784,40.1271951,124.3830593,40.1292045],
"geometry":{
"type": "Point",
"coordinates": [124.38176886493923, 40.12819985]
},

The general flow can be visualized as below.

One additional comment: one big issue that we have run into so far is the difference between a script and a language. The script refers to the way it is written, i.e. both Cantonese and Mandarin spoken in Taiwan share the same script, the way English and French share the same script. However, language primarily refers to how it is spoken. This is important as although some languages that share the same script do pronounce characters the same way, i.e. English and French, some do not, such as Cantonese and Mandarin. This is especially important for transliteration, as the whole point is to preserve the pronunciation of the original text.

For the transliteration process, we first take in the result as to detect what country it is from. Using Nominatim’s internal list of countries, we are able to extract the languages spoken in the country. However, this does not yet work for autonomous regions Hong Kong and Macau, as they are not recognized as countries. Further work on this (and regionalization in general) is therefore needed, which I hope to tackle later. This will also allow us to potentially venture into dialects and region-specific pronunciations further in the future.

Similar to Nominatim’s current logic, if there is only one language spoken in the result country, we take that to be the given language of the result. If not, this is left undefined and no conclusions can be made. At this stage, if there is a given singular result language and the user knows it, we know that no transliteration is necessary and our new transliterated name field will just be the default name.

If the user does not know the language, or if there are multiple languages spoken in that country, we then move on to the second stage: localization. From the given name tags for a result, we try and return the best matching name from a dictionary of names containing different name variants, as well as an identifier with regards to what language used. This is slightly different from how display names are currently returned, due to the presence of a secondary return value. From this new function, we also set a new field which allows us to determine if we are in a user-understandable language. This is important as previously localization just assigned a name, but if no valid names were present, it would just default to the country default.

After this, we know that the result is not in a user-understandable script if both

• The user does not know the result country language, or if there are multiple languages spoken in that country

and

• There are no name tags at present in a user-understandable name, forcing the address component to still be in the default value.

From here, we can finally proceed with transliteration. For transliteration to any Latin-based script, we use the unidecode library. We can detect if the user knows any Latin-based script or not with a newly created list of languages, in which I have included all two letter ISO 639 codes (which can be found here) as well as the tag yue, for Cantonese. This list acts as a dictionary to see if the language has a Latin-based writing system or not, and also contains the full name of the language and a sample excerpt of the script, if available. The transliteration function will go through the list of user languages in an ordered fashion, targeting the users highest preferred languages first. This means if a user has English, Chinese, Arabic as their list of languages, transliteration will always be to a Latin-based script.

You might be wondering, what about transliteration to any non-Latin based script, what then? Well, due to the variety of tones and characters and inflections in many non-Latin languages, transliterating to their script is actually very difficult. For example, using Chinese to transliterate even the word “Normal” might result in 10 different iterations. However, we do want to provide support for this, creating a pluggable interface for future development. Therefore, for every language the user knows, not only do we check if the script is Latin-based, but we also check if we have a way of transliterating to that language. Currently, we have examples of this for Cantonese, Traditional Mandarin, and Simplified Mandarin.

The final part for this is actually understanding what languages the user does know. This is actually taken from the browser information, similar to what Nominatim currently does. However, if you have worked with browser codes before, you know that normally it is not just a nice two-letter code; the browser also tries to add some region-specific language identifiers such as en-US and en-CAD. To preserve regional locales, but remove general duplicates, we firstly preserve the ordering of the ‘importance’ of the language to the user due to its weighing, then upon the first instance of a non-generalized language code, add the generalized form directly after. This also allows us to normalize languages when needed, which is especially important for the case of Chinese, which spans Simplified Chinese script in a spoken Mandarin form, Traditional Chinese script in a spoken Mandarin form, and Traditional Chinese script in a spoken Cantonese form, and identifiers that can leave what the user actually understands unclear. Therefore, in the case of ambiguity, the largest number of languages will be added, which means that while zh-tw will only map to zh-Hant, zh could map to any of zh-Hans, zh-Hant, or yue. The normalization code can be found here.

Thank you guys so much for reading! Please leave any feedback if you have any!

Realizadas pequenas edições como número de casas, criação de edifício em vila sônia e local de interesse mercado dia também em vila sônia.

RETEX: My Urban Recycling Trekking

To be continued, maybe:

• diary entry (upcoming): choosing tags for this trekking
• diary entry (upcoming): existential questions about my encounter with Panoramax

Context

Since April 2025, I’ve been discovering OSM and trying to contribute wherever I can. Needless to say, I’m learning something new every day about OSM mapping (thanks to the Wiki, forum, and fellow contributors).

While exploring my neighborhood, I added a voluntary drop-off point (for recyclable — though not always — waste) to OSM, located 800m from my home. I then discovered that the local intermunicipal authority has an app listing a large portion of the collection points. I wondered whether it was legally and technically feasible to retrieve those, and whether it would align with the OSM ethos.

The forum quickly (and kindly) set me straight (as I said, after only 2 months with OSM, I’m learning a lot every day):

• Extracting data from a website’s database is obviously illegal unless there’s an explicit license that allows it.
• Even if there were a friendly license (which is not the case here), it would still need to be ODbL-compatible to import the data into OSM.

This led me to pursue two parallel paths:

1. Finding a sustainable solution via an open data source, which means:

   • Trying to convince the intermunicipality to publish its data, ideally on www.data.gouv.fr
   • Convincing them to make this publication sustainable (i.e., generate an export every time there are updates)
   • Assessing how, in theory, this data could be used (completeness, attribute matching, duplicate detection, handling conflicts between open data and on-the-ground data — which can either be better or simply incorrectly entered)
   • Finding out how and by whom the data could be imported
   • Seeing if all of this could happen before 2035

2. Starting manual mapping myself through field visits (the foundation of OSM’s truth)

As it happens, since retiring, I’ve enjoyed walking on cool routes (max per day: 10–30 km, 600 m elevation gain, no technical sections), and I know quite a few trails in my region.

And that’s how my Urban Recycling Trekking was born.

Purpose and Organization

Quantity

Initially, I estimated 284 PAVs (voluntary drop-off points) within the intermunicipal area, which seemed manageable by the end of the year. In practice, I was completely wrong — it’s more like 650 locations, each with 2 to 8 distinct containers. That brings us closer to 2,000 or 3,000 nodes to enter.

They’re spread across about 60 municipalities, with some hosting nearly 250.

Locomotion

I briefly considered doing a car grid with side images (I don’t have a 360° camera to mount on my roof), which might allow manual OSM input from the photos. But I quickly ruled that out:

• It’s not very “fun” and wouldn’t really be worthy of a journal post
• Many PAVs are positioned with their backs to the street, so a roadside photo often doesn’t reveal the container types, let alone their reference numbers

I also ruled out using risky transport for someone my age 😉 (skateboards, rollerblades, scooters), and — more debatably — even biking.

So I’ve settled on walking-based mapping loops through urban areas, driving to the starting point in a fully electric vehicle.

What to Record

The goal is to record voluntary drop-off points (PAVs), mostly semi-buried or surface containers. Since their locations are listed in the GPSEO app, I can pre-plan efficient routes and aim for decent coverage.

Additionally, before even starting, someone asked me to contribute photos to Panoramax of the various sites (see my [future] journal entry Existential Questions About My Encounter with Panoramax).

So I need to walk past each site, spot it, photograph it, and later upload data to both OSM and Panoramax.

I also considered combining this with other data collection:

• StreetComplete seemed like a great option, but a first test showed it to be very time- and battery-intensive. In urban areas (its main use case), I spent all my time tagging street surfaces, pedestrian crossings, and bus stop benches. I know I could filter out some quests, but I chose to exclude StreetComplete from this project (though I still use it for less targeted outings).
• Since I already use OsmTracker to log PAVs, I thought I could also record other objects for others to map later from my traces. This wouldn’t cost much extra time or battery. But I dropped the idea because mapping without photos might be too imprecise, and I didn’t want to photograph every single object. Maybe I was wrong about this (and I might change my mind later).

In practice, I’ve made one exception: fire hydrants I encounter (thus non-exhaustive, since I only note those during PAV-focused walks). I tend to walk with my head down, so I can’t miss them (they’re red and under a meter tall). So for these: OsmTracker tag + photos (for my own later mapping). I don’t upload these photos to Panoramax (but I keep them in case it turns out useful later).

These RETEX (feedback) journal entries reflect my beginner’s choices, doubts, and questions. These are my own opinions, not Wiki entries. Many of these choices have been discussed on the French forum, but not all. I remain completely open to feedback and have no intention of offering recommendations here.

(translation from ChatGPT)

RETEX : mon trekking urbain recyclage

à suivre peut-être :

• entrée de journal(à venir) : les choix de tag pour ce trekking
• entrée de journal (à venir) : Questions existentielles sur ma rencontre avec panoramax

Le contexte

Depuis avril 2025, je découvre OSM et cherche à contribuer sur ce que je peux. Autant dire que j’en apprends tous les jours sur le mapping OSM (merci WIKI, forum et autres contributeurs).

En m’intéressant au voisinage, j’ai ajouté à OSM un point d’apport volontaire (collecte de déchets recyclables - pas toujours -) à 800m de chez moi. J’ai alors découvert que l’intercommunalité locale avait une application recensant une partie importante des points de collecte et me suis demandé s’il était envisageable légalement et techniquement de les récupérer, puis si c’était conforme à l’esprit OSM.

Le forum m’a rapidement (et gentiment) recadré (quand je vous dit qu’avec 2 mois d’OSM derrière moi, j’en apprends plein tous les jours) :

• récupérer des données d’une base de données via son site Web est bien évidemment illégal si aucune mention explicite de license ad hoc n’est faite
• même si une license sympathique est exprimée (ce qui n’est pas le cas ici), encore faut-il qu’elle soit compatible avec ODBL pour l’insérer dans OSM.

Ce qui m’a conduit à deux axes d’action parallèles :

1. Obtenir une solution pérenne à partir d’une base opendata, et donc :

   • essayer de convaincre l’intercommunalité de publier ses données idéalement sur www.data.gouv.fr,
   • essayer de la convaincre de rendre cette publication pérenne (et donc d’en faire un export à chaque changement)
   • essayer de voir comment, théoriquement, pouvoir exploiter ces données (suffisance, correspondance d’attributs, détection de doublons, traitement des conflits entre les données opendata et les données terrains - qui peuvent aussi bien être meilleures que simplement mal rentrées -) .
   • trouver comment et qui pour importer ces données
   • voir s’il est possible de faire cela avant 2035.

2. entamer un mapping manuel par moi-même en consultant le terrain (la vérité de base d’OSM)

Il se trouve par ailleurs que depuis que je suis retraité, j’aime marcher sur itinéraires cool (max par jour : 10-30 km, 600m D+ , sans passages techniques) et je connais pas mal de sentiers de ma région.

Et voilà comment est né mon trekking urbain recyclage

Objectif et organisation

La quantité

Il m’a semblé initialement compter 284 PAV (Points d’apport volontaire) sur le périmètre de l’intercommunalité, ce qui m’a paru aisé à faire d’ici la fin de l’année. Dans la pratique, je me rends compte que je me suis complètement trompé et que c’est plutôt de l’ordre de 650 lieux comptant de 2 à 8 points distincts chacun. On serait donc plutôt autour de 2000 ou 3000 noeuds à entrer.

Ils sont répartis sur une soixantaine de communes, dont certaines en comporteront près de 250.

La locomotion

L’idée m’a effleuré un moment de faire un quadrillage en voiture avec une prise d’images droite et gauche (je n’ai pas de caméra 360 à mettre sur mon toit de voiture) à partir desquelles il serait envisageable de faire l’alimentaton manuelle de OSM. Mais j’ai très rapidement écarté cette hypothèse :

• Ce n’est pas très “fun” et n’aurait probablement pas mérité un article dans mon journal OSM
• Beaucoup de PAV sont orientés de telle sorte que le container est dos à la rue et donc une image à partir de la rue ne permet pas d’identifier le type de dépôt que chaque container accepte et encore moins d’identifier la référence du container.

J’ai aussi écarté les quadrillages en étant monté sur des engins dangereux pour mon âge 😉 (skateboard, rollers, trottinettes) ainsi que (ce qui est plus discutable peut-être) le quadrillage à vélo.

L’idée est donc d’organiser des mappings de zones urbaines à pied par boucles (avec déplacement pour aller au départ en voiture - 100% électrique).

Que relever

L’objectif est de relever les points d’apport volontaire (PAV), très majoritairement en containers semi enterrés ou posés sur le sol. Comme leur localisation existe sur une application GPSEO, cela me permet de préparer des itinéraires adaptés et de viser probablement une certaine exhaustivité.

Par ailleurs, avant même de démarrer, on m’a demandé d’alimenter panoramax avec les photos des différents points (voir ma [future] entrée de journal Questions existentielles sur ma rencontre avec panoramax).

Donc il faut passer devant chaque point, le repérer, le photographier, puis en différé alimenter OSM et Panoramax.

Je me suis aussi posé la question de combiner cela avec d’autres relevés :

• StreetComplete paraissait un très bon candidat mais un premier essai a rapidement montré que c’était très chronophage et consommateur de batterie. En milieu urbain (sa cible), j’ai passé mon temps sur les revêtements de rue, les caractéristiques des passages piétons et les bancs des arrêts de bus. Je sais que je pourrais écarter certaines quêtes mais j’ai préféré écarter StreetComplete pour ce trekking (ce qui ne m’enpêche pas de l’utiliser à d’autres occasions moins ciblées).
• Comme j’utilise OsmTracker pour pointer les PAV, je me suis aussi dit que je pourrais juste noter dans OsmTracker un tas d’autres objets et de laisser d’autres contributeurs les entrer dans OSM à partir de ma trace. Cela ne prendrait pas trop de temps et pas plus de batterie (puisque j’utilise déjà OsmTracker). Je n’ai pas mis en oeuvre cette idée car j’ai pensé que sans photo, le mapping de ces objets serait trop sommaire et je n’avais pas envie de photographier chacun d’entre eux. J’ai peut-être eu tort sur ce point (et pourrais changer d’avis avant la fin).

En pratique, j’ai fait une exception pour les bouches à incendie rencontrées (et donc, pour le coup, pas exhaustives car rencontrées uniquement sur les quadrillages à cible PAV) : je marche assez souvent tête baissée et ne peux pas les rater (rouges en général et en dessous d’un mètre). Donc, pour elles : tag OsmTracker + photos (destinées à mon mappage à postériori). Je ne verse pas ces photos sur Panoramax (mais les conserve au cas où je découvrirais après coup que c’est opportun).

Ces entrées RETEX (retour d’expérience) dans mon journal font état de mes choix de débutant, mes hésitations, mes questions. Ces textes n’engagent que moi et ne sont pas des entrées de WIKI. Plusieurs de ces choix ont été évoqués sur le forum France, mais pas tous. Je reste bien sûr ouvert à tout commentaire et n’ai aucunement la prétention de donner ici des recommandations.

10/07/2025-16/07/2025

Mapping

• The comprehensive proposal for mapping road markings was approved with 21 votes for, 5 votes against, and 1 abstention.

Community

• HazelCyril asked whether OpenStreetMap maintains records of the last time a user posted a diary entry or created map notes.
• KhubsuratInsaan questioned if promoting OpenStreetMap as a leisure activity could be effective, since in certain social contexts the idea of ‘doing something for free’ is viewed as repugnant.
• After the US community reached a consensus to delete ecclesiastical boundaries from OSM, Minh Nguyễn demonstrated how to map a Catholic archdiocese in OpenHistoricalMap instead.
• Andy Townsend highlighted the challenges of mapping areas without clearly defined boundaries, noting that OpenStreetMap still struggles to accurately represent such regions. The problem lies in how people perceive and define the concept of place, an issue explored in detail in Euan Mills’ dissertation, which describes a social experiment where he walked 4.5 km along the A10, stopping roughly every 200 metres to ask ten unsuspecting passers-by ‘Excuse me, what area is this?’.
• UrbanRoaming reported an amusing twist in Lima, Peru, where a hiking trail mapped eight years ago, by OpenStreetMap user BikeRoad, recently went viral on Instagram. The reason? The route still doesn’t appear on Google Maps, but shows up perfectly in Pokémon Go, which uses OSM data. As a result, adventurous Instagrammers are now giving Pokémon Go bragging rights as a more dependable trail guide than Big Tech’s map of choice.

OpenStreetMap Foundation

• The OpenStreetMap Foundation’s Operations Working Group announced that recent security updates to OSM’s OAuth requires some applications to be upgraded to remain compatible, including the HOT Tasking Manager, osm-api-js, and osm-auth.
• The OpenStreetMap Foundation has announced the launch of its 2025 Engineering Working Group Microgrant programme, aimed at supporting community members developing software projects that enhance the OSM platform and ecosystem. A total of £30,000 has been allocated, to be shared among several innovative and impactful proposals. Individual grants are capped at £6,000, but applicants with ambitious ideas are encouraged to think big and apply nonetheless.

Events

• Videos from SOTMUS 2025 presentations are now being uploaded to OSM-US’s YouTube channel.

OSM research

• Scientists from the US and Germany have investigated so called ‘death by GPS’, where drivers are distracted, drive in bad weather conditions, follow the satnav blindly, or the satnav’s map does not account for road conditions (rough shortcuts not suitable for the vehicle, for example).
• A recent study by Jakub Trojan and Tereza Srnečková highlighted how university-led mapathons, like those at Tomas Bata University in Zlín, can enhance the quality and volume of citizen-contributed geographic data on platforms such as OpenStreetMap, fostering both education and community-driven mapping for humanitarian purposes.
• Ming Liu and team used OpenStreetMap road and POI data to assess Dalian’s urban nocturnal light environment. By linking night-time brightness with urban functional zones, they identified both lighting-vulnerable areas and lighting hotspots, offering valuable insights for healthier, more sustainable city lighting.
• Researchers from MIT’s Senseable City Lab, along with collaborators from other institutions, have cited OpenStreetMap as a data source in a new study examining the relationship between street design, speed limits, and driving behavior. Using 51 million telemetry data points from vehicles, the study evaluates the influence of street features, extracted from OSM, on drivers’ compliance. Moreover, the study uses a model, based on OSM, to predict driver compliance to a 30 km/h limit when applied to areas where it is 50 km/h at the moment.
• PeopleForBikes highlighted the importance of OpenStreetMap data in evaluating urban bike infrastructure in its 2025 City Ratings. Cities such as Baltimore have improved their scores by updating OSM with more accurate low-stress bike routes, showing how better mapping directly impacts planning and advocacy, for safer, more connected cycling networks.

OSM in action

• ^[1] Christian Beutel, aka Flomp, has built Wanderer, a self-hosted, Fediverse-based trail database that allows users to upload recorded GNSS tracks or create new routes, complete with rich metadata features to build an easily searchable catalogue.
• Der Spiegel, in a recent video report on car theft in Berlin, highlighted how Saxony’s Special Commission for Vehicle Crime uses an OpenStreetMap-based application to track suspects by analysing their movements through cell tower data.
• Befristet tooted that the University of Vienna Library has launched an interactive web map using OpenStreetMap and uMap to display its various locations.

Software

• GrabMaps has introduced the KartaCam 2, a portable LiDAR-equipped camera designed for capturing high-resolution street imagery and detailed 3D indoor environments. The collected LiDAR point cloud data can also be uploaded to the newly released KartaView 3D platform.

Programming

• Sarah Hoffmann has outlined several anticipated features for Nominatim version 6, including auto-completion, improved performance, enhanced address handling, and expanded support for complex categories and complex OSM objects.

Releases

• The Organic Maps July 2025 update has been released.
• MapComplete version 0.54.0 is out now, including a ‘copy’ button feature for some types of OSM object and MangroveReview-based POI reviews now parsed with markdown.
• HeiGIT reported that a new version of ohsome-planet, a command-line tool that transforms OSM history PBF files into an analysis-ready data format, has been released.

Did you know that …

• … the OSM changeset feature was brainstormed during a 2008 hackathon in London?
• … even almost 10 years later OSM Tag History, created by Martin Raifer, is still available and can be used to consult the historical evolution of the use of OpenStreetMap tags and generate graphs automatically? This application was first published by us in September 2016, and we’re publishing it again because these detailed statistics are hard to find.

OSM in the media

• The removal of North Korea’s Ryesong River from Naver Maps has sparked ► controversy in South Korea, amid suspicions of possible data manipulation. Naver claimed that the omission resulted from using OpenStreetMap data for regions outside South Korea, asserting that the river was missing from OSM’s 2023 data. However, an OSM Foundation representative refuted this, stating the river has never been removed from OSM. The debate intensified after concerns emerged that radioactive waste from a uranium refinery upstream on the Ryesong River could be flowing into South Korea.
• The Italian National Institute of Statistics has published an update of their document ‘Use of the OpenStreetMap to calculate indicators for road accidents on the Italian roads’, based on 2023 OpenStreetMap data.

Upcoming Events

Country	Where	Venue	What	Online	When
	Noida	Noida Sector 18	OSM India monthly mapping party (online)		2025-07-20
	San Jose	Online	South Bay Map Night	✓	2025-07-23
	Kiel	Mango’s	Kieler Mapper*innentreffen		2025-07-22
	Berlin	Online	OSM-Verkehrswende #69	✓	2025-07-22
	Ciudad de México	Microsoft Teams (Remote)	Mapping Party Semanal LATAM Weekly LATAM Mapping Party		2025-07-24
	Hannover	Kuriosum	OSM-Stammtisch Hannover		2025-07-24
	Wien	Schlupfwinkel (Kleine Neugasse 10, 1040 Wien)	75. Wiener OSM-Stammtisch		2025-07-24
			UN Mappers Mappy Hour		2025-07-25
			OSMF Engineering Working Group meeting		2025-07-25
			OSM World Mappy Hour		2025-07-25
	Δημοτική Ενότητα Παπάγου	Piu Verde, Άλσος Παπάγου	OSM Greece – Συνάντηση της ελληνικής κοινότητας (Αθήνα)		2025-07-26
	Jalpaiguri	Beguntary More (Law College Gate)	5th OpenStreetMap West Bengal Mapping Party		2025-07-26
	Siliguri	Guru Nanak Chowk	6th OpenStreetMap West Bengal Mapping Party		2025-07-27
	Noida	Noida Sector 18 Metro Station	19th OpenStreetMap Delhi Mapping Party		2025-07-27
	Stadtgebiet Bremen	Online und im Hackerspace Bremen	Bremer Mappertreffen		2025-07-28
	Düsseldorf	Online bei https://meet.jit.si/OSM-DUS-2025	Düsseldorfer OpenStreetMap-Treffen (online)		2025-07-30
			[Online] OpenStreetMap Foundation board of Directors – public videomeeting		2025-07-31
			Eastern Europe Mappy Hour		2025-07-31
			UN Mappers #ValidationFriday Mappy Hour		2025-08-01
			HOT Training WG: Advanced Waterways Mapping Webinar		2025-08-02
	Amsterdam	TomTom Amsterdam	Maptime Amsterdam: Map & Meet		2025-08-04

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

Bring State of the Map to Your Community/Country!

We’re excited to invite bids for the next State of the Map conference, taking place in 2026. This is a unique opportunity to partner with us and host the conference in your city!

Why bid?

• Share your community’s experiences and successes with the global OpenStreetMap community
• Showcase your city’s unique culture and attractions
• Contribute to the growth and development of OpenStreetMap globally

How to bid:

1. Read the guidelines and selection criteria on the OSM Wiki page
2. Plan your application carefully, considering dates, venues, and logistics
3. Avoid clashes with other relevant conferences, such as FOSS4G and local SotMs

Early bird advantage:

By bidding now, you’ll have the greatest flexibility in choosing dates for the 2026 conference. Don’t miss this opportunity!

We look forward to receiving your bid and partnering with you to bring State of the Map to your community/Country

Key Dates

• Call for venues open: 13 June 2025
• Deadline of bids: 31 August 2025
• We will review the bids for State of the Map 2026 in September 2025 and will inform the teams immediately after the decision.
• Announcement of venue 2026: during State of the Map 2025 in Manila
• Also observe other relevant event dates, e.g. avoid collisions with FOSS4G and local SotMs.

Need help?

The SotM Working Group is available for any further clarifications! Please contact via email: sotm [at] openstreetmap.org as early as possible so that we can provide guidance, if needed.
We look forward to collaborating with you.

The State of the Map Working Group

The State of the Map conference is the annual, international conference of OpenStreetMap, organised by the OpenStreetMap Foundation. The OpenStreetMap Foundation is a not-for-profit organisation, formed to support the OpenStreetMap Project. It is dedicated to encouraging the growth, development and distribution of free geospatial data for anyone to use and share. The OpenStreetMap Foundation owns and maintains the infrastructure of the OpenStreetMap project, is financially supported by membership fees and donations, and organises the annual, international State of the Map conference. Our volunteer Working Groups and small core staff work to support the OpenStreetMap project. Join the OpenStreetMap Foundation for just £15 a year or for free if you are an active OpenStreetMap contributor.

OpenStreetMap was founded in 2004 and is an international project to create a free map of the world. To do so, we, thousands of volunteers, collect data about roads, railways, rivers, forests, buildings and a lot more worldwide. Our map data can be downloaded for free by everyone and used for any purpose – including commercial usage. It is possible to produce your own maps which highlight certain features, to calculate routes etc. OpenStreetMap is increasingly used when one needs maps which can be very quickly, or easily, updated.

As you might know, we’re having OpenStreetMap Awards this year! Finally, after many skipped years, we will have the honour and the joy to recognize people and teams who have made an impact on OSM, whether it’s by mapping, writing, or coding!

The process is open, and the same as the last time: first we gather all the nominees we can think of, then some groups of notable OSM members will choose a few from those who feel to be the most notable, and after that — an open community voting to choose one for each category. And the categories are:

• Core Systems Award — for building or maintaining an core project.
• Innovation Award — for making something new.
• Influential Writing Award — for blog posts, tutorials and documentation.
• Greatness in Mapping Award — for tireless mapping!
• Expanding the Community Award — for finding us more members.
• Team Achievement Award — awarded to companies and groups.
• Ulf Möller Memorial Award — like a lifetime archievement award for individuals.

Note that only achievements made or announced in 2024 or before April 1st, 2025 are eligible.

And right now, I need you help. The deadline for submitting nominees is looming, and we’ve got too few. Each category needs at least twenty to make sense, and for some, we got like two.

This needs some archive work. Like, open WeeklyOSM or big community discussions (before April 1st), and add people, projects, and teams you think made the OSM in general slightly better.

And submit them to https://awards.openstreetmap.org/

(Yes, we’ve got the official domain, thanks to Grant!)

이 도로가 계속 차로 수가 변경되서 같은 이름 다른 차로 수의 도로를 차로 수가 바뀔 때마다 끊어서 따로 새로 추가하고 있습니다. 도움 부탁드립니다.

도로 링크 : osm.org/way/392677769#map=16/35.63247/129.43854&layers=N osm.org/way/1416020854#map=17/35.624268/129.442173&layers=N osm.org/way/1416020853 (산하중앙3로, 울산광역시 북구)

※일단은 정자동 등 제외하고 강동산하지구 부근(푸르지오1차/2차, 힐스테이트, kcc 등 아파트 모여있는 개발계획구역 쪽)만 편집 중입니다. 혹시나 정자동 쪽도 도움 주실 수 있으면 부탁드립니다.

July 20, 2025 - After 17 months, I have reviewed every road in the NFSR network for the Siuslaw National Forest. Below is a summary of what was involved and the process I used.

Foundational elements

The foundational elements of this project are two public domain road datasets, the NFSR data from the United States Forest Service, and the OR-Trans dataset from the state of Oregon. NFSR is the reference for road numbers, names given to roads by the USFS, road surfaces, and geometry to a certain degree. The OR-Trans data is a reference for primary road names, geometry verification, and the tag formatting of USFS roads. I was able to use additional GIS from counties to verify geometries and primary road names.

Project management

QGIS was utilized as a way to manage the entire project. I used conditional styles on manually added attributes to break the 1,977 roads from the NFSR data into workable chunks, and to keep track of what I had done. Those workable chunks were exported as KMLs to use as a reference when working in iD.

Edits on OSM

I elected to use iD for this project to force myself to manually review everything I was doing, and to remove the possibility of an accusation of a careless import.

The NFSR data contains good geometry for the most part, but there are quite a few errors that are very significant. The NFSR data also contains several discrepancies from reality, such as roads being marked as closed and not open for use, despite the roads not being gated and definitely being actively used. Blanket replacing the geometry and tags in OSM without manual review would worsen the quality of OSM data.

This was also a good opportunity to do some TIGER cleanup and resolve road/water crossing issues. Unfortunately, with the nature of the crossing issues, resolving one can lead to getting flags for multiple others along the road or waterway, which can make it appear that you are creating these issues even though they were already present.

Tag formatting

Tag formatting is somewhat in line with what is currently on the Wiki. I will explain each tag, and why it may vary from the Wiki.

“name”

There are several roads where some or all of the road shares a name with a road name that is signed and/or used for addresses. In these cases, “name” is the road name that is on signage/used for addresses. Otherwise, “name” is “United States Forest Service Road” followed by the appropriate NFSR ID number. This ranges from 2 to 8 characters. For example, NFSR ID 5800000 is a primary route with a distinctive route marker, so it is named “United States Forest Service Road 58” where it does not share a road name that is used for addressing. NFSR ID 5800410 is named “United States Forest Service Road 5800-410”.

“alt_name”

This is for the name of the road as identified in the NFSR data. Of course, there can be several alternative names, so I elected to prefix the NFSR road name with “USFS” for ease of identification. The Wiki suggests that such names be used as the primary name of the road. It is extremely rare to see these names on signs, whereas it is almost universal to see the road number on signs. In line with the “on the ground” principle, I did not use these names for the “name” tag. Also, there are multiple instances of two or more NFSR IDs sharing the same NFSR-assigned name, even in the same forest.

Where a NFSR road shares a name with a road name used for addressing, such as a segment of NFSR ID 5800000, “United States Forest Service Road 58” and “United States Forest Service Road 5800” are also included in the alt_name tags.

“short_name”

This is to make searching easier, and to provide a matching value with the OR-Trans data, which is used in ways where having a matching value is incredibly important. NFSR ID 5800000 is tagged with both “USFS 58 Rd” and “USFS 5800 Rd”, as there are signs that display both “58” and “5800”. NFSR ID 5800410 is tagged with both “USFS 58-410 Rd” and “USFS 5800-410 Rd” for consistency in tagging.

“ref”

This is where I tag the NFSR ID as a 7 digit non-hyphenated number. This provides a match with the IDs in the NFSR data. The refs are prefixed with “NF” or “FR”, in line with the Wiki. I believe a single prefix (“NFSR” or “USFS”, maybe) should be used regardless of the route marker, but that’s a discussion for another day. NFSR ID 5800000 is tagged “NF 5800000”, and NFSR ID 5800410 is tagged “FR 5800410”.

“network”

The Wiki suggests that this be reserved for route relations. I used the appropriate “US:NFSR:Siuslaw:NF” or “US:NFSR:Siuslaw:FR” values on the individual ways, as it is a unique value to indicate that the road is part of the NFSR network.

“operator”

The Wiki suggests adding the name of the national forest, or the USFS itself, as the operator value. I originally did not use this tag at all. Considering the definition of the tag, there can be multiple operators along a single NFSR route, and these can be difficult to determine. After receiving input from another editor that does a lot of work with NFSR data, I tagged the operator as “United States Forest Service”. In due time, some segments may see their operator tag change as the actual operator is determined.

Other cleanup

The project area consists of a significant amount of poor data from old TIGER imports. Several roads and segments were incorrectly identified as being NFSR roads. I used a combination of search criteria to find these incorrectly tagged elements. For example, searching for tags containing “Siuslaw”, “National”, “Natl”, “Forest”, “Develop”, and/or “NFD”, followed by manually sorting out what was applicable, was the best way I could think of to find and remove these incorrect tags.

Final review

After all of the edits, I used several different processes in QGIS to compare an export of OSM data against the NFSR data. For example, a distance matrix was useful for finding instances where I mistyped a number. Once I had identified every error I made, I corrected them, and went through all of the processes again just to ensure everything was good.

On July 18, I thought everything was good. Today, July 20, I wanted to assess any USFS data updates that may have happened since the last time I checked for them. Just for fun, I decided to download both NFSR datasets and the MVUM dataset. I was surprised to find that the MVUM dataset does not match the NFSR datasets. One NFSR dataset has two separate roads merged into one multi-part line, which overwrote the correct information for one of the roads. Fortunately, the correct data is in the MVUM file. Meanwhile, the MVUM has roads not identified in the NFSR data at all, and also has at least one road with an incorrect road number. These discrepancies have been sorted out, and the relevant updates have been made on OSM.

Północno-wschodnia Polska (Kurpie) Potrzebują pomocy!

Na terenie Kurpii (Łyse, Myszyniec, Kadzidło, Ostrołeka) brakuje wielu kluczowych elementów, aktualnych informacji, i zwyczajnego landuse’u.

Kurpie zasługują na dobrą jakość map, lecz ja sam, nie poradzę sobie z tym dosyć sporym regionem.

Apeluje o pomoc i wspólne działanie w tworzeniu dobrej mapy Kurpii!

Zapraszam wszystkich do wspólnego mapowania tego pięknego, ciekawego i historycznego regionu Polski.

Zachęcę po Kurpiowsku :

Dawajta, róbta to razem!

Καλησπέρα σε όλους και όλες,

Σας προσκαλώ στην συνάντηση της ελληνικής κοινότητας του OpenStreetMap στην Αθήνα. Ευκαιρία να μαζευτούμε οι χαρτογράφοι της Ελλάδας και να πιούμε έναν δροσιστικό καφέ μες την ζέστη του καλοκαιριού, ώστε να γνωριστούμε καλύτερα και να συζητήσουμε διάφορα σχετικά με το OSM. Και μετά να κάνουμε χαρτογράφηση στη γύρω περιοχή :slight_smile:

🗓️Ημερομηνία και ώρα: Σάββατο 26 Ιουλίου, 15:00
🔗Τοποθεσία: Piu Verde, Άλσος Παπάγου

Το Piu Verde εκτός από καφέ, προσφέρει και φαγητό, για όποιον θέλει μιας και θα είναι κοντά μεσημέρι.
Όσοι επιθυμείτε να παρευρεθείτε, συμπληρώστε το όνομα σας εδώ.

🗓️🔗Σύνδεσμος συνάντησης στο OpenStreetMap Calendar: https://osmcal.org/event/3920/

Δεν υπάρχει συγκεκριμένη ατζέντα για το τι θα συζητήσουμε, γι’ αυτό γίνεται η συνάντηση για να γνωριστούμε από κοντά όσοι δεν γνωριζόμαστε ήδη, και θα συζητήσουμε διάφορα για το OpenStreetMap και πιθανώς και κάποια θέματα που αναφέρθηκαν στην online συνάντηση. Και φυσικά στο τέλος θα κάνουμε και χαρτογράφηση της γύρω περιοχής.

Σαν σημείο αρχικής συνάντησης για όσους φτάσουν 15:00 ακριβώς, προτείνω την αρχή του μονοπατιού επί της οδού 8ης Μεραρχίας.

Δείτε και την σχετική ανάρτηση στο φόρουμ της κοινότητας.

Για επικοινωνία με τα υπόλοιπα μέλη της ελληνικής κοινότητας, πέραν του φόρουμ, για πιο άμεση επικοινωνία στο τσατ Element.

Σας ευχαριστώ και ελπίζω να ιδωθούμε,
jimkats (Δημήτρης)

In 2020, I was presented with an opportunity to participate in the Humanitarian OpenStreetMap Team’s Data Quality Internship, https://www.hotosm.org/jobs/data-quality-internship/,a twelve-week program designed to facilitate deep engagement within the Humanitarian OpenStreetMap Team and its community while acquiring transferable geospatial skills.

Commencing on August 3rd, I undertook a three-month internship that concentrated on Geospatial Data Quality within the Humanitarian OpenStreetMap Team. The primary objective of this internship was to prepare interns to evaluate data quality, execute mapping and validation tasks, and provide constructive feedback to mappers engaged in HOT’s remote mapping initiatives, which included various activations. This experience necessitated the acquisition and application of both novel and established OpenStreetMap Quality Assurance tools to enhance the quality of data within the OpenStreetMap framework.

-Data Quality Assurance with QGIS

1. Downloading OpenStreetMap data into QGIS

https://youtu.be/Mvh5l0PiOiE

1. Editing OpenStreetMap data in QGIS

2. Using Map Composer

-Mapping and validation on Tasks e.g #8294 and #9194

-Introduction to Overpass Turbo and Umap: filter OSM data, extract/export data

-Improving data quality with Overpass and creating simple webmaps using Umap

• The graphic interface and tools for creating a basic map layout through the manipulation of vector data

-Quality Assurance Tools such as OSMCha, OSM Inspector, Keep Right and Osmose

-The use of Map Roulette and Map Paint Styles

• JOSM training i.e mapping and validation using JOSM, task #9055

우선, 저는 한국어를 못해서 자동 번역입니다. 저는 러시아 출신이지만 지난 3년 동안 서울에 살고 있어서 한국어로 글을 쓰고 싶습니다. 저는 1년 동안 OSM을 사용해 왔지만, 일주일 전에 지도 제작에 손을 대기로 했습니다. 제 첫 프로젝트는 «석정리». 세계문화유산화순고인돌군에서 멀지 않은 외딴 마을이에요. 어디서부터 시작해야 할지 몰라서 그냥 무작위로 이 마을을 선택했습니다.

제가 알기로는 한국의 OSM 커뮤니티는 그다지 활발하지 않은 것 같습니다. 하지만 한국에서 3년을 보냈지만 여전히 같은 관심사를 가진 친구를 찾을 수 없었기에, 이번 시도가 시간이 지나면서 결실을 맺기를 바랍니다. 어떤 식으로든 제 작업이 유용하기를 바랍니다.

제가 뭔가 잘못한 게 있다면 알려주세요. 번역가가 좋은 일을 해서 여러분을 울게 하지 않았기를 바랍니다 :) 화이팅!