Next Tuesday the OSMLondon pub meet-up will be at “The Volunteer” pub near Baker Street!

Last time we were at the Blue Posts near Tottenham Court Road. We’ve been there many times before, but not for several years (we’ve been avoiding Sam Smiths for reasons, as I explained last time). It didn’t seem to have changed much though. We took over a large part of the pleasantly quiet upstairs area. I think someone else took a photo, so I didn’t bother (?). Anyway we had maptastic chit-chat as always. I noted down a couple of interesting conversation topics:

We talked about a recurring topic: Should we send automated welcome emails after users sign up? It’s pretty odd that we don’t do this, if we compare ourselves to just about any other user sign-up website, but I think the counter-argument has always been that we’re a very international community, and so we can do this by providing data on new contributors in a region, and letting local communities craft much better more friendly language and context-aware welcome emails. I’m sure this topic has been re-hashed many times over the years.

A leading welcoming tool is “OpenStreetMap Welcome Tool” https://welcome.osm.be from LCCWG. I’ve not tried it. I see it’s not enabled for UK/GB/England (I think some UK people are welcoming new mappers in small areas using OSMCha) but a key feature would seem to be the ability to mark a recipient as “has been welcomed”. I was thinking an alternative hack would be to always welcome user’s via a discussion on their first changeset, just as a “weird trick” to turn it into a publicly viewable rather than private message, so we can see who’s been welcomed.

But anyway I personally think the idea of a brief automated welcome email on registration should still be considered, because manually welcoming seems unlikely to reach everyone, and also there’s that frustrating fact that many users sign up then never get as far as making an edit.

… See full entry

see https://community.openstreetmap.org/t/update-on-my-id-tagging-schema-and-id-grants-completion-of-612-hours-of-work/149730 for overview

see below for more specific list, it was too long to be posted on forums

Funded by OpenStreetMap Foundation

I tested and reviewed this changes prepared by others, recommended changes to be merged and it was followed by maintainers:

… See full entry

I spent two years mapping the areas surrounding one of the most beautiful drives in the world. Each morning, I looked forward to discovering and mapping an area adjacent to a one I did the day before. This diary entry serves as an introduction to a series of texts covering the challenges I encountered and how I overcame them. Included below are a few snapshots taken in the field, which capture the majestic landscapes along the Icefields Parkway. I have also added a “before and after” map excerpt, as well as a short video, to illustrate how my work gradually took shape over time.

The Place

The Icefields Parkway (Highway 93N), in Alberta, owes its name to the spectacular icefields and glaciers that line the road. The parkway, which is a 232 km stretch of highway cutting through Banff and Jasper National Parks, attracts between 1.2 million and 2 million visitors per year. The parkway offers exceptional alpine landscape, with glaciers, rivers, turquoise lakes, and breathtaking mountain views directly from the roadside (Figure 1). Best of all, many of these landmarks can be reached in a single day’s hike (Figure 2).

… See full entry

Spent the morning with the Bicycle wiki page and a 300-post thread about access=dismount, and the same thing kept coming up: our cycling data is really good at describing the road, and a bit less good at describing the person on the bike.

We tag the surface, the separation, the access. But the thing that decides whether I actually ride a route is rain, fatigue, and whether I trust the stretch where the cycle lane ends and the traffic doesn’t slow down. None of that is in the data, and it’s the part that matters on a Tuesday morning when it’s pouring.

I keep coming back to the idea that the gap between “legal to ride” and “would actually ride” is where the interesting mapping is. Maybe that’s a project for a quieter evening.

DinoData is a web-based tag editor for OpenStreetMap nodes, ways and relations, designed for phones first. Open an object, see what it is and what each tag means in your language, edit the tags with inputs suited to them, and save as a changeset. Geometry is not edited.

It runs entirely in the browser and is hosted on Wikimedia Toolforge. It started as a Wikidata editor; the OpenStreetMap mode lives next to it in the same app.

Finding an object

Search for a place, or paste what you have: an openstreetmap.org URL (including edit and API URLs), an iD or JOSM remote control link, a short ID like n123 or way 123, or coordinates. Other text is a place search with Photon and Nominatim. “Near me” lists the tagged objects around you via the Overpass API, handy while surveying.

Understanding the tags

• What the object is (“Cafe”), from the translated presets of the iD tagging schema
• Every tag explained from the wiki’s data items: description in your language, status, image, links to the wiki page and the Wikidata concept
• Deprecated and discouraged tags marked
• A small map, the parent ways and relations, and the history: tags added, changed and removed per version, with user and changeset comment

Editing

• Preset fields with matching inputs: chips for yes/no and other choices, a value picker with translated options and the most used values from taginfo, chips for multiple values like cuisine=pizza;pasta, toggles for diet:*, names per language, a search for wikidata=*, and number, phone and URL keyboards
• Issues with one-tap fixes: deprecated tags, values not matching the format documented on the wiki, tags not meant for the element type, incompatible tags
• Undo per field or tag; pending edits survive reloads and the login

… See full entry

OSM formats compared with TOML

OpenStreetMap data comes in several text formats. OSM XML is exact but verbose, OSM JSON has no comments, and Level0L is easy to type but has no grammar beyond its parser. TOML has comments, a spec and parsers in most languages, including Python’s standard library. So what would OSM data look like as TOML? I came across this question while adding an OSM tag editor to DinoData. Below, each format is compared with TOML using the examples from the OSM wiki, and the TOML versions are checked with Python’s tomllib.

Level0L is the text format of the Level0 editor. DinoData reads and writes it in the OSM text view (src/osm/level0.ts, src/osm/tags.ts). It looks a bit like TOML: key = value lines, # comments, and headers that start a section. But the two formats are not compatible. This page compares them, together with the other formats DinoData meets, and shows how OSM data could look as TOML.

• Level0L (lines of text): editing in Level0. OSM API: –. DinoData: text view, read and write.
• JOSM file format (OSM XML with action, <bounds>, upload): saving edits in JOSM. OSM API: plain OSM XML is the default response, and the body of PUT for single elements. DinoData: –.
• OSM JSON (JSON): reading. OSM API: elements, history, full, map and more, with a .json suffix or Accept: application/json. DinoData: reading elements, history and changesets.
• osmChange (XML with <create>, <modify>, <delete>): changes. OSM API: GET /api/0.6/changeset/#id/download, and the only format of the upload POST /api/0.6/changeset/#id/upload. DinoData: saving tags.

The Level0 behaviour described here follows its parser, www/level0l.php.

Differences

Section header

… See full entry

Saiba Mais: 11914261797

En muchas partes del mundo se recuerda a los difuntos de una manera u otra; en México se tiene la tradición del día de los muertos (festividad declarada por la UNESCO Patrimonio Cultural Inmaterial de la Humanidad), en donde se levantan altares dedicados a determinada persona ya fallecida y la creación de calaveritas a personas (por lo general) vivas. Éstas últimas, las calaveritas, son versos a modo de epitafio burlesco y como modo de expresar ideas o sentimientos que en otras oportunidades sería difícil decir.

Este año escribí mi primer calaverita inspirado en el State of the Map Latam 2026 (SotM Latam 2026) realizado en CDMX este año:

… See full entry

Written 2025-10-30… Published 2026-11-03

About three years ago, during my day-to-day mapping activities, I came across a golf course that had some obvious errors. I didn’t think much of it at the time. Just a fairway that was drawn right across the top of a green. But the more golf courses I looked at, the more frequently I encountered this error.

I soon learned about a golf course simulator video game that was built on OpenStreetMap data and was attracting a large influx of simulator enthusiasts who weren’t seasoned OSM mappers. Along with that came various tools to aid in converting OSM data into these simulators, as well as tutorial videos that made some very bad assumptions about how golf courses should be mapped. These factors set the stage for some very bad mapping practices to spread around the world.

My understanding is that attempts were made to correct these bad habits at the source, but the tutorial author wasn’t interested in revising or removing his video. Combine that with YouTube’s bad decision to hide down votes on videos, and you’re left with de facto training material that is widely disliked but that new golf course mappers have no way of knowing is a poor source of truth.

So this is where I come on the scene and try to make the map better.

I’m a big fan of the broken windows theory. I’ve seen it play out in my own town. A minimally maintained but abandoned pizza parlor near me stood for years waiting for a new occupant to lease it. You’d see prospective tenants touring it every once in a while, but no takers. Eventually, someone tagged the building with graffiti. It wasn’t cleaned up in a timely manner, and things spiraled downward from there: more graffiti, broken windows, stolen copper, garbage left behind by homeless people, and eventually, the building was razed.

… See full entry

I’ve been building Wandering Around, a free browser game in which you can walk around any town or city on Earth. The whole world comes from OpenStreetMap, so I’d like to share how it uses OSM data and ask this community for feedback.

Play it here: https://wanderingaround.games (works on phone and desktop, no account needed) Screenshots and a short video: https://mikehur.itch.io/wandering-around

How the map is built

• Streets, buildings, water, parks and bridges come from OpenFreeMap vector tiles (zoom 14, OpenMapTiles schema). The game fetches the tiles around the player, decodes them in the browser, stitches buildings that are split across tile edges and turns everything back into OSM-style features with tags. The game logic works on those tags, so it is the same code whether the data comes from tiles or (as a fallback) from Overpass.
• 2D and 3D: the same data drives a 2D map and a 3D eye-level view. Building heights come from OSM where they are tagged.
• Transit: train routes and stations, city buses, ferries and signposts come from Overpass queries, so you can travel between real stops and stations.
• Country map: towns, airports and ferry ports within 100 km come from pre-built tiles made from Overture, OurAirports and Natural Earth.

What the game adds itself

Vector tiles leave out some details, such as single trees, benches, crossings, traffic lights and roof shapes. The game fills those in itself so streets don’t look empty. These are decoration, not data: they are never written back anywhere.

Wikidata postcards

Every feature with a wikidata tag (and, in the Netherlands, ref:rce for national monuments) becomes a landmark. When you visit one you get a postcard with:

• a photo from Wikimedia Commons (P18), with the photographer and licence shown,
• year built (P571), height (P2048) and floors (P1101),
• a summary from Wikipedia in your language.

… See full entry

قشلاق ساری قوئی میکائیل

Bande dessinée qui explique en partie la situation actuelle des chemins perdus plus ou moins facile à retrouver, voire parcourir. Ce voyage dans le passé de nos campagnes m’en a rappelé d’autres ; notamment les films Farrebique (1946), puis Biquefarre (1983) ; mais aussi une série d’émissions radiophoniques et télévisuelles, peut-être diffusées en 2009, sur l’essor agricole français, rétrospectivement.

https://www.editions-delcourt.fr/series/serie-champs-de-bataille

بندرعباس کوی فرهنگیان کوچه گل افشان بن بست اول ضلع شمال غربی ساختمان مجاهد.

https://yamatt.github.io/osm-user-home/

Er is vooral goed te zien wie waar ter wereld zoal mapt. Na een rondje medemappers bekijken bleek: we mappen tamelijk consequent in eigen land en overschrijden de landgrens zelden.

Edit: De OSM Home Predictor laat in het gunstigste geval zien in welke plaats je woont en zeker niet in welke straat en nog minder in welk huis. In OSM zit trouwens direct onder je account de functie “Mijn dashboard”, waarmee je >Andere gebruikers in de buurt< kunt zien. Die hebben veelal zélf hun exacte adres opgegeven en hebben soms ook nog hun eigen naam als accountnaam en in het beste geval ook nog een profielfoto …

While walking around, surveying, I’ve often theorised it would be possible to work out where I lived based on the centre of all the edits I’ve made.

So I made a tool to estimate it. And it’s pretty close.

It gets closer or further away depending on how much history you look at.

But you might find it informative.

https://yamatt.github.io/osm-user-home/

Edit:

It’s an interesting problem.

OSM needs and wants contributions. But by it’s very nature it can give away users data, without them even realising.

I don’t think there is even a technical fix for that.

But there does need to be a serious discussion with contributors about their data privacy.

Some might not care.

Some might be alarmed.

And alarmed is good.

We need to talk about how we balance users privacy and the power of OSM contributions.

X marks the spot to the crossroads of America. Route 30 travels east to west and Route 41 north to south spanning the whole country. Schererville, Indiana

A fantastic guide. But my god, could it make the changeseys a bit more bulky instead of creating a new one for every single edit?

I feel like I’m spamming now…

I had a great time at SotM LATAM in Mexico City this past week. I got to hear so many talks on diverse subjects, I met friendly and interesting people, and there was a general acceptance that a random person from Canada would be there. Kudos to the organizing team and volunteers who put on a smooth, well run event.

I have never been to a State of the Map before despite thinking about going since way back in 2016 when I happened to already have a visa for Brazil. That certainly would’ve been harder with my level of Spanish understanding then. I will definitely be back.

Gracias a la comunidad y hasta la próxima. Espero encontrar oportunidades para colaborar.

Surprised myself and participated for rrrreal! (well, ok, missed the first day)

Very nice event, liked it a lot.

Report 🫡

https://m-d.me/notes/osm-dailychallenge-2026/

31DayOSMChallenge #Maptober #Maptober2026

Bar Ehiala’S Deck, parte das antenas