Style | Standard • Cards

OpenStreetMap Blogs

Thursday, 05. November 2026

OsmAnd

Organizing Your Tracks with Smart Folders

A September morning in Vancouver. More than a thousand riders roll out of Stanley Park for the RBC GranFondo Whistler: 122 kilometres of the Sea to Sky Highway, closed to traffic, with Howe Sound on one side and the mountains on the other. Past Squamish, the road starts to climb and keeps climbing all the way to Whistler.

A September morning in Vancouver. More than a thousand riders roll out of Stanley Park for the RBC GranFondo Whistler: 122 kilometres of the Sea to Sky Highway, closed to traffic, with Howe Sound on one side and the mountains on the other. Past Squamish, the road starts to climb and keeps climbing all the way to Whistler.

You cross the line near the top of the results, and everyone says the same thing: you were lucky. With the weather, the wind, the group.

You know better. That result is made of dark February mornings on the seawall, Sunday climbs up Cypress, and long rides to Squamish and back, all recorded in OsmAnd one track at a time. Let’s see what a season of training looks like once Smart Folders put it in order.

Cycling Whistler

Photo by Ben Guernsey on Unsplash

A Folder That Fills Itself​

A training season doesn’t arrive neatly packed. Between the rides sit a few hikes and a drive to Whistler, and the Tracks tab lists everything by date, with no idea which recordings mattered.

A Smart Folder works the other way round: you describe the tracks you want, and OsmAnd collects them. The description is a filter that can check almost anything a track knows about itself, including length, duration, speed, elevation, date, location, activity type, and even heart rate. Set the activity to road cycling, limit the dates from February to race day, save the result as “Road to Whistler”, and the whole season lands in one place while the hikes stay out.

New rides join the folder on their own. The tracks themselves stay where they were, so deleting the folder never deletes a ride.

One catch: activity type is stored in each track, and older recordings may not have one. If some rides are missing, set their activity and refresh the folder.

Smart Folder FilterSmart Folder Tracks

One Collection, Many Views​

Sixty-seven rides in one folder is tidier than a few hundred, but it’s still a list. Organize by turns that list into groups, sorting the folder by a single parameter: activity, date, location, speed, altitude and elevation, or sensor data such as heart rate. The tracks don’t move anywhere; only the way you look at them changes.

Group the season by nearest city, and you see where the rides began: most of them in Vancouver, a handful from West Vancouver, where the long runs to Squamish set off from Horseshoe Bay, and four from Whistler, once summer made it worth driving up for the climbs. Switch to month and year, and the same folder turns into a calendar, from a cautious February to a crowded August.

Each group shows how many tracks it holds, and empty groups don’t appear at all. Below the list, OsmAnd adds everything up: tracks, distance, climbing, descent, and time in the saddle. It does this for the whole folder and for every group you open. That’s where the season starts answering questions.

Smart Folder Organize by Nearest CitySmart Folder Organize by Month

Drawing the Lines Yourself​

Months and cities come with natural borders. Distance doesn’t. Is a 55 km ride a long one or just a solid Tuesday? For length, duration, speed, and altitude, OsmAnd lets you decide where one group ends and the next begins.

Pick one of these parameters, and a slider asks for a step size. Drag it, and the groups rearrange behind it as you go. With a 50 km step, most of the season piles into the first group, which is honest but not very revealing. Bring it down to 20 km, and the season sorts itself out: short morning laps along the seawall, a big block of loops around UBC, the climbs on Cypress and Seymour further up, the long runs to Squamish, and, at the very end, two tracks of almost exactly the same length: the course recon in August and the race itself.

Some of this is free for everyone: grouping by activity, year of creation, and nearest city. The rest, including the monthly calendar from the previous section and every parameter with a step size, comes with OsmAnd Pro. Without a subscription, you can still open these options and preview how the tracks would split before deciding. If a subscription ends, the grouping you’ve already applied stays in place, and only changing it requires Pro again.

Smart Folder Step Size 50 kmSmart Folder Step Size 20 km

Keeping It in Shape​

The race is over, but the folder doesn’t retire with it. It keeps watching for rides that match its rules, and if the list ever looks out of date, a quick refresh brings it back in line. When the next season starts, there’s no need to build anything new. Edit the filter, move the dates forward, and the same folder starts collecting a new story.

Groups are useful beyond reading, too. Any of them can go straight onto the map, so a whole August of riding appears at once, from the seawall to the climbs above Whistler, every route drawn on top of the others. A group can also be exported in one go, which is handy when a coach asks to see your month and doesn’t want a dozen separate files.

If you plan the next season on a bigger screen, Smart Folders also appear in OsmAnd Web once Settings are synced through OsmAnd Cloud. They keep working best with common parameters such as activity, dates, or distance.

Smart Folder Group MenuSmart Folder Group on the Map

The Answer to the Question​

So, was it luck? Open February, and the folder answers modestly: five rides, 103 km, just over five hours on the bike, and 839 metres of climbing. Then open August: twelve rides, 577 km, a full 24 hours in the saddle, and 6,806 metres of climbing, including the day you rode the entire race course just to see how it would feel.

Smart Folder February SummarySmart Folder August Summary

The whole season fits into a single line at the bottom of the folder: 67 rides, 2,923 km, and more than 33,000 metres of climbing. That’s nearly four times the height of Everest, collected one Cypress hairpin at a time.

No tailwind delivers that. So the next time someone tells you how lucky you were, there’s no need to argue. Just open the folder and hand them your phone.

Share Your Story

Every track in OsmAnd has a person and a story behind it. If you’d like to share yours on our blog, whether it’s a long journey, a season of training, or a route you simply love, we’d be glad to hear from you. Write to Tina, and we’ll make it happen together.

We appreciate your interest in us and thank you for taking the time to read this article. Join us on social media to keep up to date with the latest news and share your experiences. Your opinion is important to us.

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

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

00:00 • 16 hours ago

Wednesday, 04. November 2026

OpenStreetMap User's Diaries

Update on my iD tagging schema and iD grants - completion of 612 hours of work

see 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 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:

I tested, approved and merged improvement prepared by someone else:

I suggested merging own code written before grant started and it was followed:

Changes I implemented myself:

LLMs

There is also a sad part. Recently I was also experimenting with using LLMs for part of the work. I absolutely dislike that LLM are a thing, their emergence is second worst thing that happened in my life so far.

Some complaints raised about them are just not making sense. But there are also many valid reasons to dislike then. For start I absolutely detest dependency on a proprietary SaaS. That is run by people who outright hate me, or at best merely want to exploit me. Or open weights produced in a proprietary way, in way that inherently makes impossible for me to reproduce it.

Sadly at this point LLMs are actually highly useful. It is quite easy to fall into traps of various kinds, but can be actually effective in some ways.

The question remains whether they actually should be used and which uses are legitimate. And how to avoid various novel problems. And I am still unsure about proper answer here.

Obviously undisclosed use and/or submitting vibecoded pull requests is just invalid. But there is plenty of potential uses that make sense and can potentially be helpful.

(though I hope that this thread is not going to be about LLMs, I am getting allergy to even mentions of them - though at the same time I am tempted to write a long rant why they are bad in general and also specifically for me)

Other work funded by OpenStreetMap Foundation

I recommended closing and it was followed

I closed it outright (as rejected, unclear, duplicate, abandoned, LLM with no human oversight, misplaced, impossible etc):

I recommended closing as fixed and it was followed (not listing ones closed by PR merges):

I closed it outright as fixed (not listing ones closed by PR merges):

Funded by European Union via Nlnet Foundation

Changes I implemented myself:

I tested, approved and merged improvement prepared by someone else:

I suggested merging own code written before grant started and it was followed:

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

I recommended closing and it was followed

I closed it outright as fixed (not listing ones closed by PR merges):

I closed it outright (as rejected, unclear, duplicate etc):

23:41 • 16 hours ago

Mapping Icefields Parkway, Part 1: A two-year mapping journey

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

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).

Figure1 Figure 1: North Saskatchewan River alongside the parkway. Parker Ridge (2350 m) and Nigel SE3 (3025 m) in the background.

Figure 2 Figure 2: Multiple landmark features shown on the “Tracestrack Topo” map (2026), with Figure 1 POV on the bottom right.

The Scouting Trip

I use the term “scouting trip” here, given what I learned (local knowledge) and the time I spent mapping the area afterwards, but visiting the Rockies was a project my wife and I had had for a long time, absolutely not related to OSM! The plan was to spend a week exploring Jasper, Lake Louise and the Icefields Parkway in between. Unfortunately, when wildfires struck Jasper National Park in 2024, it led to its closure and forced us to change our itinerary at the last minute. We therefore had to abandon this entire segment of the trip and reach Lake Louise via highway 11, the Saskatchewan River crossing and the southern half of the Icefields Parkway (Figure 3).

Figure3 Figure 3: Highway 11 toward the Saskatchewan River Crossing and the southern half of the Icefields Parkway.

We then had more time than expected to explore Banff National Park. Here are a few pictures taken along the parkway and showing landmark features such as Bow Lake (Figure 4) and Peyto Lake (Figure 5). Figure4 Figure 4: South view of Bow Lake with large scree slopes reaching the lake.

Figure5 Figure 5: Peyto Lake and its large alluvial fan. To the left, Peyto Peak and its glacier in the background.

We spent some time in Lake Louise, where we visited its namesake lake (Figure 6) as well as its even more popular neighbor, Moraine Lake (Figure 7); however, what we enjoyed most was hiking the trails surrounding the town, which offer multiple access points to the Bow River (Figure 8).

Figure6 Figure 6: Lake Louise and its turquoise waters. Behind me, the “Chateau Lake Louise” and hundreds of tourists like me.

Figure7 Figure 7: Moraine Lake view taken from the “moraine” crest. Out of frame, hundreds of tourists like me.

Figure8 Figure 8: Bow River, just a few hundred meters from where we stayed in Lake Louise.

Unexpectedly, the Jasper National Park authorities reopened the Athabasca Glacier area during our stay, giving us the opportunity to drive the parkway again. Along the way, we stopped at the Big Bend (Figure 9), the only hairpin bend on the parkway, before continuing on our way to reach the Columbia Icefield area (Figure 10). Figure9 Figure 9: Big Bend viewpoint, looking south toward North Saskatchewan River, and Mount Cirrus (3270 m) on the left.

Figure10 Figure 10: Icefields Parkway toward Columbia Icefield and the Athabasca Glacier.

The Columbia Icefield is not actually visible from the road, even though the Athabasca Glacier originates there. It is possible to get close to the glacier on foot by taking a trail called “Hike to Toe of Athabasca Glacier” (Figure 11). The name of the trail is misleading, as it ends where the foot of the glacier was in 2006 (Figure 12). Unfortunately, you can’t go further unless accompanied by a guide or taking an “Ice Explorer Experience” bus tour because direct access to the glacier is prohibited due to the inherent risks of such an environment.

We did enjoy the experience anyway! Figure11 Figure 11: The few hundred meters hike to reach the closest point to the Athabasca Glacier that you can do on your own.

Figure12 Figure 12: The Athabasca Glacier closest view you can reach on your own. Taken where the foot of the glacier was in 2006.

It is with all these breathtaking landscapes in mind, and fantasizing about all I had not seen, that I decided to map around the parkway and add the spectacular natural features that were sorely lacking in OSM.

The Mapping – Existing content

The area already contained data from the Canvec import. This import has a reputation for being of poor quality. Made available almost twenty years ago, the data derived from 1:50K topographic maps were much more complete than what could be mapped from the 30-80 m resolution imagery available at that time. But now, current high-resolution imagery reveals its limitations. Vegetation (wood, wetlands) is of poor quality; road and hydrographic networks are present; but need most of the time to be aligned with the imagery before making finer adjustments. I also noticed that some key features were added after the import. Maybe the most significant contribution I found came from one user who mapped most hiking trails (there are many) and routes to different summits along the parkway. In such a wild area, this information is helpful for those who, after parking to admire the view, decide to explore the surroundings (like me). However, apart from these elements, the map was empty all along the road (Figure 13), whereas on the ground, the diversity and immensity of the landscapes struck at each kilometer. Figure13 Figure 13: Standard OSM map view from early 2024. Most of the data comes from the Canvec import.

The Mapping – Adding/Editing Data

I had begun making some edits near Jasper while preparing for our trip, but after wildfires affected the town and the park was closed, I had to pause that work to find alternative routes and make new reservations. Once I got home, I started mapping again, but this time following the route we had taken. I did not yet know that I would spend two years mapping the region, thereby extending my stay and reviving my memories, day after day. By the end of this mapping journey, I had added to the map all the natural features present in an area a hiker might traverse in a day or two, between Jasper and Lake Louise. Here is a small example of what the map looks like now (Figure 14). Figure14 Figure 14: Standard OSM map view from late 2026. Same area as Figure 13, after adding/updating all natural features.

There is so much to say about this mapping journey that I plan to cover these various topics in future entries of my journal (hence the “Part 1” in my title). In the meantime, I have illustrated this journey in a short video (46 seconds), which shows the distribution of my contributions over time. Only the nodes are represented in order to achieve a better visual result.

LinkToYouTube

*Click to open the video and turn on the sound :-) *

Jfd553

14:43 • a day ago

The route a real person takes

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 st

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.

06:24 • a day ago

DinoData: a phone-first tag editor that explains every tag

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 OpenStreetMa

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

For power users, a text view shows all tags as key=value lines or as Level0 text. Paste tags with Ctrl+V anywhere: key=value lines, tab-separated lines, "key"="value" from taginfo or Overpass turbo, or Level0 text as is. key= removes a tag. Copied Level0 text contains the full object, so it can be pasted into Level0.

Saving

Log in with your OpenStreetMap account (OAuth 2.0 in a popup, so pending edits are kept), review the changes, enter a comment and pick a source. Each save is one changeset with created_by=DinoData. If someone edited the object in the meantime, the tags are merged; only keys changed on both sides need a choice.

Limitations

No geometry editing, no creating or deleting objects, no editing of relation members, one object per changeset, no offline editing. The interface of the OpenStreetMap mode is available in English, German and Dutch.

Try it

Open dinodata.toolforge.org/#osm. DinoData is free software under GPL-3.0; the code is on GitHub, and bug reports and ideas are welcome in the issue tracker.

05:18 • a day ago

OSM formats compared with TOML

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

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

  • Level0L: node 1: 52.5, 13.4, way 123, relation 5.28 (with version); -way 5 deleted, !way 5 conflict, way or way -1 new
  • JOSM and osmChange (OSM XML): an element: <node id='1' lat='52.5' lon='13.4'>, <way id='123' version='28'>; action='delete' or action='modify', a negative id for new objects; in osmChange, elements are grouped in <create>, <modify> and <delete> blocks
  • OSM JSON: an object in elements: {"type": "node", "id": 1, "lat": 52.5, "lon": 13.4}; "visible": false for deleted objects in history
  • TOML 1.0: [table], [a.b], [[array of tables]]

Value

  • Level0L: raw text up to the end of the line, trimmed: name = Main Street
  • JOSM and osmChange (OSM XML): an XML attribute: <tag k='name' v='Main Street' />
  • OSM JSON: a JSON string: "name": "Main Street" in tags
  • TOML 1.0: typed: "…", '…', number, boolean, date, array, inline table. A bare Main Street is an error

Types

  • Level0L: every tag value is a string, as in OSM
  • JOSM and osmChange (OSM XML): every attribute is a string
  • OSM JSON: id, lat, lon, version, changeset, uid are numbers; tag values and timestamp are strings
  • TOML 1.0: ref = 123 would be an integer, so it must be written ref = "123"

Key

  • Level0L: anything before the first unescaped =: name:de, addr:street
  • JOSM and osmChange (OSM XML): any string in k='…'
  • OSM JSON: any JSON string: "name:de"
  • TOML 1.0: bare keys allow only A-Z a-z 0-9 _ -, so "name:de" needs quotes, and addr.street would become a nested table

= in a key

  • Level0L: a\=b = c
  • JOSM and osmChange (OSM XML): no escape needed: k='a=b'
  • OSM JSON: no escape needed: "a=b"
  • TOML 1.0: "a=b" = "c"

Escapes

  • Level0L: only \= in keys; values are taken literally
  • JOSM and osmChange (OSM XML): XML entities: &amp;, &lt;, &apos;, &quot;, &#10;
  • OSM JSON: \", \\, \n, \uXXXX
  • TOML 1.0: \", \\, \n, \uXXXX in "…"; none in '…'

Comments

  • Level0L: # in column 0, or at the end of a header line. In a = b # c the value is b # c. A key starting with # must be indented
  • JOSM and osmChange (OSM XML): <!-- … -->
  • OSM JSON: none
  • TOML 1.0: # anywhere outside a string

Lists

  • Level0L: repeated lines, in order: nd 1, wy 2 forward, rel 3
  • JOSM and osmChange (OSM XML): child elements, in order: <nd ref='1' />, <member type='way' ref='2' role='forward' />
  • OSM JSON: "nodes": [1, 2], "members": [{"type": "way", "ref": 2, "role": "forward"}]
  • TOML 1.0: nodes = [1, 2], arrays of inline tables, or [[relation.member]]

Duplicate key

  • Level0L: warning; the first value wins
  • JOSM and osmChange (OSM XML): not prevented by the XML syntax
  • OSM JSON: names “SHOULD be unique” (RFC 8259); Python and JavaScript keep the last value
  • TOML 1.0: error (Cannot overwrite a value)

Empty value

  • Level0L: key = is invalid in Level0 (its regex needs a value); DinoData reads it as “remove the tag”
  • JOSM and osmChange (OSM XML): v='' is valid XML
  • OSM JSON: ""
  • TOML 1.0: key = "" is a valid empty string

Multi-line values

  • Level0L: no
  • JOSM and osmChange (OSM XML): only as &#10;; a raw newline in an attribute is read as a space
  • OSM JSON: only as \n
  • TOML 1.0: """…""", '''…'''

Object order

  • Level0L: one stream, types mixed in any order
  • JOSM and osmChange (OSM XML): grouped by type: nodes, then ways, then relations; osmChange: blocks in document order
  • OSM JSON: one elements array, types mixed
  • TOML 1.0: [[node]], [[way]], [[relation]] keep their order only within each type

Level0L is the better fit for typing tags by hand: no quotes, and OSM keys like name:de work as written. TOML is the better fit for tools: there is a standard grammar with parsers in every language, values can be escaped, and numbers are typed. OSM XML and OSM JSON are what the API and the tools exchange; they are exact but verbose to read and write by hand. OSM JSON and TOML have the same data model (objects, arrays, strings, numbers), so the conversion between the two is lossless.

Example

From the Level0L wiki page (CC BY-SA 2.0, OpenStreetMap wiki contributors), a Level0 version of the OSM XML example. ... stands for lines left out.

Level0L

node 298884269.1: 54.0901746, 12.2482632 # made by user SvenHRO (46882) in changeset 676636 on 2008-09-21T21:37:45Z
node 261728686: 54.0906309, 12.2441924 # versions should be stored server-side
node 1831881213: 54.0900666, 12.2539381 # comments are not allowed in tag values, '=' is screened (\=) only in keys
  name = Neu Broderstorf
  traffic_sign = city_limit
...
node 298884272: 54.0901447, 12.2516513

way 26659127.5
  nd 292403538
  nd 298884289
  ...
  nd 261728686
  highway = unclassified
  name = Pastower Straße

relation 56688.28 # member types: nd, wy, rel; roles are put after ids
  nd 294942404
  ...
  nd 364933006
  wy 4579143 forward
  ...
  nd 249673494
  name = Küstenbus Linie 123
  network = VVW
  operator = Regionalverkehr Küste
  ref = 123
  route = bus
  type = route

...

As TOML

One possible mapping: an array of tables per object type, the ID.version header split into id and version, and tags in a tags sub-table. The header comments are kept; the two that describe Level0L syntax are rewritten for TOML.

[[node]]
id = 298884269
version = 1
lat = 54.0901746
lon = 12.2482632
# made by user SvenHRO (46882) in changeset 676636 on 2008-09-21T21:37:45Z

[[node]]
id = 261728686
lat = 54.0906309
lon = 12.2441924
# versions should be stored server-side

[[node]]
id = 1831881213
lat = 54.0900666
lon = 12.2539381
# comments may follow any value; keys with '=' or ':' are quoted
[node.tags]
name = "Neu Broderstorf"
traffic_sign = "city_limit"

# …

[[node]]
id = 298884272
lat = 54.0901447
lon = 12.2516513

[[way]]
id = 26659127
version = 5
nodes = [
  292403538,
  298884289,
  # …
  261728686,
]
[way.tags]
highway = "unclassified"
name = "Pastower Straße"

# member types: node, way, relation; role is optional
[[relation]]
id = 56688
version = 28
members = [
  { type = "node", ref = 294942404 },
  # …
  { type = "node", ref = 364933006 },
  { type = "way", ref = 4579143, role = "forward" },
  # …
  { type = "node", ref = 249673494 },
]
[relation.tags]
name = "Küstenbus Linie 123"
network = "VVW"
operator = "Regionalverkehr Küste"
ref = "123"
route = "bus"
type = "route"

Notes on the mapping:

  • [node.tags] belongs to the most recent [[node]], so id, lat, lon, nodes and members must come before it. In Level0L, tags and references can be in any order.
  • In the TOML version, ref = "123" has to be quoted. ref = 123 would be an integer, while OSM tag values are always strings.
  • In TOML 1.0 an inline table must fit on one line. A member list over several lines therefore uses an array of inline tables, as above, or [[relation.member]] tables. TOML 1.1 also allows newlines and a trailing comma inside an inline table.
  • Keys like name:de or addr:street need quotes: "name:de" = "Hauptstraße".
  • If the order of objects across types matters, a single array with type = "node" on each object keeps it, at the cost of a longer header. This is how OSM JSON does it, see the OSM JSON section below.

New and deleted objects

The second example on the wiki page, taken from the JOSM file format, has a new node without ID and a deleted node:

node 26821100: 51.5077286, -0.1279688
  created_by = Potlatch 0.10f
  name = Nelson's Column
  tourism = attraction
  monument = statue
  historic = monument
node: 51.507661490456606, -0.1278000843634869
-node 346364767

[[node]]
id = 26821100
lat = 51.5077286
lon = -0.1279688
[node.tags]
created_by = "Potlatch 0.10f"
name = "Nelson's Column"
tourism = "attraction"
monument = "statue"
historic = "monument"

# new: no id (or a negative one)
[[node]]
lat = 51.507661490456606
lon = -0.1278000843634869

[[node]]
id = 346364767
deleted = true

A Level0L conflict (!node 1) would become conflict = true. The changeset object, which has only tags, would become a single [changeset] table.

JOSM file format

The JOSM file format is OSM XML as the API returns it, with additions for local edits: <bounds> with an origin for each download, action='modify' or action='delete' on changed objects, negative IDs for new objects (also usable as references elsewhere in the file), and upload='false' or upload='never' on <osm>. Objects are grouped by type, which is how the [[node]], [[way]] and [[relation]] arrays above work too.

JOSM XML

The example from the wiki page is the same data as the second Level0L example, with the metadata that Level0L leaves out:

<?xml version='1.0' encoding='UTF-8'?>
<osm version='0.6' generator='JOSM'>
  <bounds minlat='51.5076478723889' minlon='-0.127989783553507' maxlat='51.5077445145483' maxlon='-0.127774884645096' origin='OpenStreetMap server' />
  <node id='26821100' timestamp='2009-02-16T21:34:57+00:00' user='dankarran' visible='true' lat='51.5077286' lon='-0.1279688'>
    <tag k='created_by' v='Potlatch 0.10f' />
    <tag k='name' v='Nelson&apos;s Column' />
    <tag k='tourism' v='attraction' />
    <tag k='monument' v='statue' />
    <tag k='historic' v='monument' />
  </node>
  <node id='-1' visible='true' lat='51.507661490456606' lon='-0.1278000843634869' />
  <node id='346364767' action='delete' timestamp='2009-02-16T21:34:44+00:00' user='dankarran' visible='true' lat='51.5076698' lon='-0.1278143' />
</osm>

As TOML

Attributes of <osm> become top-level keys, which TOML requires before the first table. Each <bounds> becomes a [[bounds]] table. Element attributes become keys, and <tag> elements go into tags as before:

version = "0.6"
generator = "JOSM"

[[bounds]]
minlat = 51.5076478723889
minlon = -0.127989783553507
maxlat = 51.5077445145483
maxlon = -0.127774884645096
origin = "OpenStreetMap server"

[[node]]
id = 26821100
timestamp = 2009-02-16T21:34:57+00:00
user = "dankarran"
visible = true
lat = 51.5077286
lon = -0.1279688
[node.tags]
created_by = "Potlatch 0.10f"
name = "Nelson's Column"
tourism = "attraction"
monument = "statue"
historic = "monument"

[[node]]
id = -1
visible = true
lat = 51.507661490456606
lon = -0.1278000843634869

[[node]]
id = 346364767
action = "delete"
timestamp = 2009-02-16T21:34:44+00:00
user = "dankarran"
visible = true
lat = 51.5076698
lon = -0.1278143

Notes on the mapping:

  • timestamp is a TOML offset date-time, not a string; tomllib returns a timezone-aware datetime.datetime. visible is a boolean, and id, lat and lon are numbers. In XML all of them are strings.
  • version = "0.6" stays a string: it names the API version and is not a number to calculate with.
  • upload='false' or upload='never' would be upload = "false" or upload = "never". A TOML boolean false next to the string "never" would give one key two types.
  • Nelson&apos;s Column needs no escape in a TOML basic string: "Nelson's Column".
  • Ways and relations map as in the Level0L example: <nd ref='…' /> to nodes = [...], <member type='…' ref='…' role='…' /> to members = [{ type = "…", ref = …, role = "…" }].
  • A TOML mapping for both formats could use JOSM’s action = "delete" instead of deleted = true, and a negative id for new objects, which Level0L also accepts (node -1: …). Then a Level0L file converts to the same TOML as the JOSM file, minus the metadata.

OSM JSON

The API returns OSM JSON for reads (elements, history, full, map, multi fetch, relations and ways of an element) when the path ends in .json or the Accept header is application/json. It is based on the Overpass API JSON format: one elements array, type on each element, tags as an object, nodes as an array of IDs and members as an array of type/ref/role objects. "visible": false appears only for deleted versions in history calls.

JSON

The example from the OSM JSON wiki page, GET /api/0.6/relation/10000000/full.json, with its two untagged nodes left out:

{
  "version": "0.6",
  "generator": "CGImap 0.8.1 (6263 thorn-01.openstreetmap.org)",
  "copyright": "OpenStreetMap and contributors",
  "attribution": "http://www.openstreetmap.org/copyright",
  "license": "http://opendatacommons.org/licenses/odbl/1-0/",
  "elements": [
    {
      "type": "node",
      "id": 6772305769,
      "lat": 50.2106895,
      "lon": 8.5857061,
      "timestamp": "2019-09-04T15:05:00Z",
      "version": 1,
      "changeset": 74092935,
      "user": "Jonaes",
      "uid": 4433367,
      "tags": {
        "bicycle": "yes",
        "information": "guidepost",
        "ref": "OU.425.1",
        "tourism": "information"
      }
    },
    {
      "type": "way",
      "id": 5123563,
      "timestamp": "2019-09-04T15:05:00Z",
      "version": 7,
      "changeset": 74092935,
      "user": "Jonaes",
      "uid": 4433367,
      "nodes": [35352060, 35352061, 35352062, 35352063, 2056819178, 35352001],
      "tags": {
        "bicycle": "yes",
        "foot": "yes",
        "highway": "track",
        "horse": "yes",
        "lcn": "yes",
        "motor_vehicle": "agricultural;forestry",
        "surface": "asphalt",
        "tracktype": "grade1",
        "traffic_sign": "DE:260,DE:1026-36"
      }
    },
    {
      "type": "relation",
      "id": 10000000,
      "timestamp": "2019-09-18T18:21:44Z",
      "version": 2,
      "changeset": 74641141,
      "user": "HoloDuke",
      "uid": 75317,
      "members": [
        {
          "type": "node",
          "ref": 6772305769,
          "role": "sign"
        },
        {
          "type": "node",
          "ref": 35352001,
          "role": "intersection"
        },
        {
          "type": "way",
          "ref": 5123563,
          "role": "to"
        }
      ],
      "tags": {
        "bicycle": "yes",
        "colour:arrow": "green",
        "colour:back": "white",
        "colour:text": "green",
        "destination": "Friedrichsdorf;Bad Homburg",
        "destination:symbol": ";train_station",
        "distance": "8.0;4.6",
        "type": "destination_sign"
      }
    }
  ]
}

As TOML

The same structure, one to one. Each JSON object becomes a table, and elements an array of tables:

version = "0.6"
generator = "CGImap 0.8.1 (6263 thorn-01.openstreetmap.org)"
copyright = "OpenStreetMap and contributors"
attribution = "http://www.openstreetmap.org/copyright"
license = "http://opendatacommons.org/licenses/odbl/1-0/"

[[elements]]
type = "node"
id = 6772305769
lat = 50.2106895
lon = 8.5857061
timestamp = "2019-09-04T15:05:00Z"
version = 1
changeset = 74092935
user = "Jonaes"
uid = 4433367
[elements.tags]
bicycle = "yes"
information = "guidepost"
ref = "OU.425.1"
tourism = "information"

[[elements]]
type = "way"
id = 5123563
timestamp = "2019-09-04T15:05:00Z"
version = 7
changeset = 74092935
user = "Jonaes"
uid = 4433367
nodes = [35352060, 35352061, 35352062, 35352063, 2056819178, 35352001]
[elements.tags]
bicycle = "yes"
foot = "yes"
highway = "track"
horse = "yes"
lcn = "yes"
motor_vehicle = "agricultural;forestry"
surface = "asphalt"
tracktype = "grade1"
traffic_sign = "DE:260,DE:1026-36"

[[elements]]
type = "relation"
id = 10000000
timestamp = "2019-09-18T18:21:44Z"
version = 2
changeset = 74641141
user = "HoloDuke"
uid = 75317
members = [
  { type = "node", ref = 6772305769, role = "sign" },
  { type = "node", ref = 35352001, role = "intersection" },
  { type = "way", ref = 5123563, role = "to" },
]
[elements.tags]
bicycle = "yes"
"colour:arrow" = "green"
"colour:back" = "white"
"colour:text" = "green"
destination = "Friedrichsdorf;Bad Homburg"
"destination:symbol" = ";train_station"
distance = "8.0;4.6"
type = "destination_sign"

Notes on the mapping:

  • tomllib returns exactly what json.loads returns for the JSON above (see “Parsing with Python” below), so a converter can go both ways without losing anything. The only JSON value without a TOML equivalent is null, which OSM JSON does not use.
  • The top-level version = "0.6" is the API version, a string; version = 1 in an element is the element version, a number.
  • timestamp stays a string here, as in the JSON. As a TOML date-time (timestamp = 2019-09-04T15:05:00Z) it would be a datetime in Python, but no longer equal to the JSON.
  • This is the single-array layout mentioned in the Level0L notes. Compared with [[node]], [[way]] and [[relation]], it keeps the order of the objects, and every object needs a type line.

Alternatives for members

The array of inline tables above is the only form that loads to the same data as OSM JSON, so it is the default. These forms also parse with tomllib.

Array of tables. The same data as the inline tables, so it is still equal to OSM JSON. It takes four lines per member, but stays readable when a member has more keys than fits on one line. Like [elements.tags], the member tables come after the relation’s own keys (id, version, …):

[[elements.members]]
type = "node"
ref = 6772305769
role = "sign"

[[elements.members]]
type = "node"
ref = 35352001
role = "intersection"

[[elements.members]]
type = "way"
ref = 5123563
role = "to"

Array of arrays. Compact and still typed: TOML 1.0 allows mixed types in one array. The meaning comes from the position, so it is no longer equal to OSM JSON: [['node', 6772305769, 'sign'], …] in Python, converted with dict(zip(("type", "ref", "role"), m)).

members = [
  ["node", 6772305769, "sign"],
  ["node", 35352001, "intersection"],
  ["way", 5123563, "to"],
]

Strings. The shortest, close to Level0L, with the n/w/r prefixes of osmium and Overpass IDs. Every reader has to split and parse the strings, and TOML no longer checks that ref is a number:

members = ["n6772305769 sign", "n35352001 intersection", "w5123563 to"]

A table keyed by member, like members = { n6772305769 = "sign" }, does not work. A relation can contain the same object twice, which TOML rejects as a duplicate key, and the TOML spec does not keep the order of keys, which matters for members.

osmChange

osmChange (.osc) describes changes: <create>, <modify> and <delete> blocks, each holding elements in OSM XML. The API returns it for GET /api/0.6/changeset/#id/download, and the diff upload, POST /api/0.6/changeset/#id/upload, takes it as the request body. Each element is replaced as a whole: there are no tag-level changes, so a modified element lists all its tags, nodes and members.

osmChange XML

The two examples from the osmChange wiki page. A modified node:

<osmChange version="0.6" generator="acme osm editor">
    <modify>
        <node id="1234" changeset="42" version="2" lat="12.1234567" lon="-8.7654321">
            <tag k="amenity" v="school"/>
        </node>
    </modify>
</osmChange>

New objects with placeholder IDs: two nodes and a way between them.

<osmChange>
    <create>
        <node id="-1" changeset="43" version="1" lat="-33.9133123" lon="151.1173123" />
        <node id="-2" changeset="43" version="1" lat="-33.9233321" lon="151.1173321" />
        <way id="-1" changeset="43" version="1">
            <nd ref="-1"/>
            <nd ref="-2"/>
        </way>
    </create>
</osmChange>

As TOML

One flat [[osmChange]] array, with the block name as action on each element:

version = "0.6"
generator = "acme osm editor"

[[osmChange]]
type = "node"
action = "modify"
id = 1234
changeset = 42
version = 2
lat = 12.1234567
lon = -8.7654321
[osmChange.tags]
amenity = "school"

[[osmChange]]
type = "node"
action = "create"
id = -1
changeset = 43
version = 1
lat = -33.9133123
lon = 151.1173123

[[osmChange]]
type = "node"
action = "create"
id = -2
changeset = 43
version = 1
lat = -33.9233321
lon = 151.1173321

[[osmChange]]
type = "way"
action = "create"
id = -1
changeset = 43
version = 1
nodes = [-1, -2]

Notes on the mapping:

  • In XML, blocks are applied in document order, and an element can appear in several of them, for example created as -1 and then deleted. One flat array with action keeps this order across blocks and types. Nested tables like [[create.node]] would not.
  • <delete if-unused="…"> would become if-unused = true on each element; - is allowed in bare TOML keys.
  • The osmChange root attributes version and generator are optional and ignored by the API.

The upload: POST /api/0.6/changeset/#id/upload

The API v0.6 page lists what the upload requires beyond the osmChange format:

  • Every element has a changeset attribute with the ID from the URL, and a version, except in <create>, where the server sets the version.
  • Elements need no user and uid.
  • Negative IDs in <create> are placeholders. They are replaced in later references (<nd ref="-1"/>, members) for the rest of the file.
  • The upload runs in one transaction: either all changes apply or none. A wrong version fails with 409 Conflict.
  • The response is a <diffResult> with one <node|way|relation old_id="…" new_id="…" new_version="…"/> per uploaded element. For deletions, new_id and new_version are left out.

The upload takes only osmChange XML. The API page documents no other format, and CGImap has only an XML parser for it (osmchange_xml_input_format.hpp). A JSON osmChange is proposed in CGImap pull request #407, open since May 2024. Its format is the flat layout above: a root with version and generator, and an osmChange array of elements with type, action, optional if-unused, id, lat, lon, version, changeset, tags, nodes and members. The TOML above, loaded and written out as JSON, is a valid message in that format.

Parsing with Python

Since Python 3.11 the standard library reads TOML with tomllib; Python 3.15 added TOML 1.1 support. All TOML examples above parse without errors and become built-in types (dict, list, str, int, float, bool, and datetime.datetime for the JOSM timestamps):

import tomllib
from pathlib import Path

data = tomllib.loads(Path("example.toml").read_text())

The first example (abridged):

{'node': [{'id': 298884269, 'version': 1, 'lat': 54.0901746, 'lon': 12.2482632},
          …,
          {'id': 1831881213, 'lat': 54.0900666, 'lon': 12.2539381,
           'tags': {'name': 'Neu Broderstorf', 'traffic_sign': 'city_limit'}},
          …],
 'way': [{'id': 26659127, 'version': 5,
          'nodes': [292403538, 298884289, 261728686],
          'tags': {'highway': 'unclassified', 'name': 'Pastower Straße'}}],
 'relation': [{'id': 56688, 'version': 28,
               'members': [{'type': 'node', 'ref': 294942404},
                           {'type': 'node', 'ref': 364933006},
                           {'type': 'way', 'ref': 4579143, 'role': 'forward'},
                           {'type': 'node', 'ref': 249673494}],
               'tags': {'name': 'Küstenbus Linie 123', 'network': 'VVW',
                        'operator': 'Regionalverkehr Küste', 'ref': '123',
                        'route': 'bus', 'type': 'route'}}]}

The second example:

{'node': [{'id': 26821100, 'lat': 51.5077286, 'lon': -0.1279688,
           'tags': {'created_by': 'Potlatch 0.10f', 'name': "Nelson's Column",
                    'tourism': 'attraction', 'monument': 'statue',
                    'historic': 'monument'}},
          {'lat': 51.507661490456606, 'lon': -0.1278000843634869},
          {'id': 346364767, 'deleted': True}]}

Working with it is plain dict and list code. Optional fields are absent rather than empty, so use .get():

rel = data["relation"][0]
rel["tags"]["ref"]                                          # '123'
[m["ref"] for m in rel["members"] if m["type"] == "way"]    # [4579143]
[m.get("role", "") for m in rel["members"]]                 # ['', '', 'forward', '']

for node in data["node"]:
    node.get("id")          # None for a new node
    node.get("tags", {})    # {} for an untagged node

Back to Level0L takes a few lines. For the second example this gives exactly the wiki text, with tags sorted by key:

KINDS = {"node": "nd", "way": "wy", "relation": "rel"}

def to_level0(type_, o):
    head = ("-" if o.get("deleted") else "") + type_
    if "id" in o:
        head += f" {o['id']}"
    if type_ == "node" and "lat" in o:
        head += f": {o['lat']}, {o['lon']}"
    tags = [f"  {k.replace('=', chr(92) + '=')} = {v}" for k, v in sorted(o.get("tags", {}).items())]
    nodes = [f"  nd {ref}" for ref in o.get("nodes", [])]
    members = [f"  {KINDS[m['type']]} {m['ref']} {m.get('role', '')}".rstrip() for m in o.get("members", [])]
    return "\n".join([head, *tags, *nodes, *members])

print("\n".join(to_level0(t, o) for t, objects in data.items() for o in objects))

node 26821100: 51.5077286, -0.1279688
  created_by = Potlatch 0.10f
  historic = monument
  monument = statue
  name = Nelson's Column
  tourism = attraction
node: 51.507661490456606, -0.1278000843634869
-node 346364767

OSM JSON and its TOML version load to the same Python object:

import json, tomllib

api = json.loads(Path("relation.json").read_text())      # the OSM JSON example
toml = tomllib.loads(Path("relation.toml").read_text())  # its TOML version
api == toml                                              # True

The first osmChange example, loaded from TOML and written as JSON, has the structure proposed for a JSON upload:

print(json.dumps(tomllib.loads(Path("modify.toml").read_text()), indent=2))

{
  "version": "0.6",
  "generator": "acme osm editor",
  "osmChange": [
    {
      "type": "node",
      "action": "modify",
      "id": 1234,
      "changeset": 42,
      "version": 2,
      "lat": 12.1234567,
      "lon": -8.7654321,
      "tags": {
        "amenity": "school"
      }
    }
  ]
}

Things to know:

Input tomllib result
ref = 123 {'ref': 123}, an int: tag values must be quoted, or converted with str()
name = Main Street TOMLDecodeError: Invalid value
name:de = "x" TOMLDecodeError: Expected '=' after a key in a key/value pair
a = "1" and a = "2" TOMLDecodeError: Cannot overwrite a value (Level0 only warns)
An inline table over two lines, with a trailing comma Parsed with Python 3.15 (TOML 1.1); an error for TOML 1.0 parsers
  • Comments, including the # … placeholders, are dropped. So is the order of objects across node, way and relation.
  • Coordinates become float; 7-decimal OSM values print back unchanged.
  • tomllib only reads. Writing needs a package such as tomli-w, or tomlkit to keep comments and formatting.

In DinoData

DinoData reads elements, history and changesets as OSM JSON (src/osm/osm.ts). It saves tags with a diff upload of one <modify> element (osmChangeXml, saveTags), keeping the coordinates, nodes, members and version, and reads the new version from the <diffResult>.

The text view accepts key=value lines, Level0L, and one-line quoted pairs like "name:de" = "Hauptstraße" (QUOTED_TAG_LINE in src/osm/tags.ts). So simple TOML or JSON-style tag lines can be pasted. Escapes inside the quotes (\", \\) are not decoded, single-quoted '…' values are not recognised, and TOML tables, arrays and multi-line strings are not parsed.

05:15 • a day ago

Corretor de Imóveis - CRECI 216465-f

Saiba Mais: 11914261797

Saiba Mais: 11914261797

01:56 • a day ago

Calaverita Mapera SotM Latam 2026

♦

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, so

Monumental Catrina

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:

Desde cada país latinoamericano,  
salieron mapeadoras y mapeadores,  
con sus GPS y computadoras,  
¡dispuestos a trazar caminos y rincones! 

Llegaron tod@s a Ciudad de México,  
con entusiasmo y mucha alegría,  
sin imaginar que la monumental Catrina  
una gran sorpresa les tenía.

—¡Vengan tod@s, mis querid@s!  
—les gritó con emoción—,  
que mi panteón está incompleto,  
¡le hace falta cartografía y precisión!

—Necesito ubicar a mis residentes,  
sus tumbas, pasillos y callejones;  
que no se me pierdan los difuntos  
por falta de buenas direcciones. 

Se l@s llevó hasta el camposanto,  
donde empezaron a trabajar,  
un@s trazaban las avenidas,  
otr@s los nichos fueron a etiquetar.

Con OpenStreetMap y sus herramientas,  
dibujaron cada rincón;  
hasta pusieron los nombres  
de los que descansaban en el panteón.

La monumental Catrina estaba contenta,  
¡qué maravilla de comunidad!  
—Ahora encontraré a mis difuntos  
con mucha facilidad. 

Pero al revisar el mapa,  
la Flaca se puso a temblar:  
¡habían mapeado tantas tumbas  
que hasta a ella pudieron localizar!

La Catrina soltó una carcajada,  
y se puso a festejar:  
—¡Qué bueno que llegaron tod@s,  
ya nadie se me va a extraviar!

Y así terminó el State of the Map Latam,  
con gran fiesta y emoción;  
Latinoamérica había dejado  
bien mapeado hasta el panteón. 

Moraleja de esta historia,  
que no se debe olvidar:  
¡hasta la Muerte necesita un mapa  
para no andar dando vueltas sin llegar!
01:23 • a day ago

Tuesday, 03. November 2026

OpenStreetMap User's Diaries

Cleaning up Golf Courses in the United States

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 cour

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.

I saw similarities with golf courses. This broken “style” of drawing a fairway, intersecting the green, crossing over it, and then intersecting the green again on the way out to the rest of the fairway was becoming commonplace. I fixed one, then another, and another. I thought about contacting the original mappers and educating them, but these were often edits made years ago, and the mappers were probably no longer active.

This is when I came up with my “Broken Greens Theory.” Any green that was “broken” could lead to more greens being “broken” when someone stumbled upon it and thought, “Oh, so that’s how you map a fairway and a green together.”

Any corrections would need to be made soon after the error was introduced, while the edits were still fresh, the mapper was possibly still active, and the damage was limited in scope. At the same time, existing errors would have to be fixed as well, or we’d never reach a point where people weren’t learning bad practices from the existing maps.

I’ve learned a lot over the last three years working on this project, from editing techniques in JOSM (even though I was already well-versed in its use) to spatial database queries. One of the neatest things I learned was about the Dimensionally Extended 9-Intersection Model and how it could be used to query for specific ways that fairways intersected with greens.

I figured out how to construct PostGIS SQL queries to identify all of these intersections and was shocked to find well over 20,000 of them in the United States. I put together tools to group these intersections and feed them, course by course, into JOSM to be manually edited and saved back out.

At the start of the year, I set a goal of fixing this one specific type of golf course error by the end of the year. As I progressed through the year, the number of remaining fixes dropped, and it looked like I was on track. Then I started noticing some intersections on nearby holes, close to ones I was already working on, that hadn’t been caught. Uh oh.

My query only caught intersections where the fairway line crossed into the green and then back out. It wasn’t catching cases where the fairway shared a node with the green, followed the green for one or more nodes, and then crossed into and back out of the green. I was disheartened to revise my query and discover that several thousand more pairs with this slightly different intersection pattern had been overlooked.

I doubled down on my efforts and increased my daily goal. A few months later, I discovered yet another type of mapping error. Some fairways shared every single point as they went around the outside of the green, where a green’s fringe would normally exist.

So I repeated my routine: fixing the query, being disheartened by the discovery of thousands more errors, and redoubling my efforts to get the job done by the end of the year.

Along with all of these edits, when my wrists could no longer take the repetitive strain for the day, I would work on developing more tools to download daily map diffs for the entire globe.

Things are different in the diff world, no pun intended. You can’t simply load diffs for the United States into the database and query them. But I wrote some code to process the XML stream and handle the unusual way that changes are grouped together. I developed tools that would examine changes to golf courses in the target area of the United States, load only those changes into my database along with nearby data, test the new edits for errors, and generate a “report” of edits that warranted further investigation by hand.

Since the start of the year, I’ve identified about 300 cases of people making “bad” edits that were significant enough that I felt reaching out and working with the mapper to correct their behavior would benefit the community.

The first thing I discovered is that changeset comments are almost useless. I’m guessing that over 90% of them are completely ignored. It’s unclear whether they were even read in the first place. I’d love to see someone put together a study on the effectiveness of changeset comments, especially when directed at newer or “drive-by” mappers.

I started requesting blocks for some of these repeat offenders from the Data Working Group and had some success getting their attention through that method. However, some mappers were combative and felt that OSM needed to bend to their will. They were challenging conversations, to say the least.

Over time, I’ve learned that messaging a mapper directly has a much better ROI, but still nowhere near 100% effective. I believe they see the unread message count and are more likely to click on it than to check for changeset comments in an email inbox that they probably use only for spam.

As the year went on, I started seeing fewer and fewer of these fairway/green intersections. Possible explanations include there being fewer courses left to map from scratch, or perhaps it’s the weather, as the season changes and people spend less time mapping. It will be interesting to see how the numbers change over the next year.

With these two approaches to tackling the problem (fixing existing issues and finding new ones), I’ve finally finished fixing every single fairway/green intersection in the United States.

I estimate that I’ve fixed over 30,000 fairways over the past few years. I consider that a big success, and I hope that ongoing maintenance will be quick and manageable.

19:50 • 2 days ago

Wandering Around: a browser game that turns OSM into a walkable world

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: wanderingaround.games (works on phone and desktop, no account needed) Screenshots and a short video: mikehur.itch.io/wandering-around

How

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.

In the 3D view the game uses the Wikidata height for the building and takes the facade colour from the photo. So a good wikidata tag on a building directly improves what players see.

What I’d love feedback on

  • Does your own area look right? Missing buildings, odd water or bridges, or stops in strange places usually point to a tagging pattern I don’t handle yet.
  • How do performance and rendering hold up in very dense city centres, compared with rural areas?
  • Any ideas for using more OSM data in a game in a way that is fun and encourages people to improve the map.

Thanks to everyone who maps. Without your work this game would be an empty grey square.

Map data © OpenStreetMap contributors · tiles by OpenFreeMap · Wikidata · Wikipedia · Wikimedia Commons

17:29 • 2 days ago

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

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

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

06:00 • 2 days ago

Monday, 02. November 2026

OpenStreetMap User's Diaries

Champs de bataille. L'histoire enfouie du remembrement.

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étrospect

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

21:34 • 3 days ago

خانه مسکونی ساختمان مجاهد

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

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

19:47 • 3 days ago

Wie wat waar ter wereld mapt / OSM Home Predictor

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 dire

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 …

15:18 • 3 days ago

Sunday, 01. November 2026

OpenStreetMap User's Diaries

Can you find a users home?

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.

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

Edit:

<

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.

20:28 • 4 days ago

Florian Lohoff

OSM QA Routing - Playing intermodal

Currently i am investigating if a comparison of the "nearest" call between a car and a foot profile reveals issues in osm.

Basically its the difference in intermodal routing. So in the first case you get sent to the nearest point on the car legal road network. In the second case you get sent on the walkable path network.

Of course its unfair to go from the car to the foot point a

Currently i am investigating if a comparison of the "nearest" call between a car and a foot profile reveals issues in osm.

Basically its the difference in intermodal routing. So in the first case you get sent to the nearest point on the car legal road network. In the second case you get sent on the walkable path network.

Of course its unfair to go from the car to the foot point as in real intermodal routing the car point would be at the modal swap/change intersection.

Nevertheless it may reveal issues in our current modelling of the data, and how we map things.

Just for an illustration - This is an address i found while testing. You can see that the nearest road network point is very "far" away from the foot point. Routing solves the labyrinth for us.

14:51 • 4 days ago

OpenStreetMap User's Diaries

Crossroads of America

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

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

04:29 • 4 days ago

Trying StreetComplete

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…

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…

04:10 • 4 days ago

SotM LATAM 2026

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 goi

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.

02:56 • 5 days ago

weeklyOSM

weeklyOSM 849

♦[1] Prague on Paper, OSM at Its Heart | map data © by OpenStreetMap Contributors. 22/10/2026-28/10/2026 Mapping Andy Mabbett has proposed a tagging scheme for the concrete arrows and illuminated beacon towers along the historic US Transcontinental Airway System. These physical navigation aids were built to guide early airmail pilots. Concrete arrows were enormous arrows painted or laid out on the
weeklyOSM 849
[1] Prague on Paper, OSM at Its Heart | map data © by OpenStreetMap Contributors.

22/10/2026-28/10/2026

Mapping

  • Andy Mabbett has proposed a tagging scheme for the concrete arrows and illuminated beacon towers along the historic US Transcontinental Airway System. These physical navigation aids were built to guide early airmail pilots. Concrete arrows were enormous arrows painted or laid out on the ground, often on hilltops or open land, pointing pilots towards the next route segment. Beacon towers were tall structures equipped with powerful lights that helped pilots follow the route at night.

  • LordGarySugar is proposing the tags flat_ride=track and water_ride=track so that, in the case of flat rides and water rides, the track can be distinguished from the ride area. Currently, attraction=log_flume is used for both, meaning that renderers cannot interpret the tag on paths. The tag attraction:part=* is intended to identify components such as stations and platforms, whilst a site=attraction relation is intended to link all parts of an attraction. The discussion is taking place on the OSM Community forum.

Community

  • rtnF has analysed the diversity of addr:neighbourhood values in Indonesia.

  • simaransharma has been adding and fixing temple map data in Surat, Gujarat, and is currently looking for other mappers in Gujarat who are also interested in mapping temples.

Local chapter news

  • OSM US published another instalment of their Mapper Highlight series, which highlights mappers, projects, and OSM communities. This October, they interviewed William Edmisten (aka wcedmisten), a Virginia mapper who recently mapped every hospital network in the United States and kept invested followers updated on the OSM US Slack.

Events

  • As part of its Gender Programme, the Unique Mappers Network hosted a virtual breast cancer awareness and geospatial education event on Friday 23 October. The theme was ‘Every Story Is Unique, Every Journey Matters’. It covered breast cancer awareness, prevention, early detection, and the importance of seeking medical advice. It also looked at the role of open mapping in community health awareness.

  • The organisers of the fifth State of the Map Nigeria have postponed their conference from 10 to 13 November to 17 to 20 November 2026, as the University of Uyo has scheduled its graduation ceremony for 9 to 14 November. The venue remains the Town Campus of the University of Uyo in Akwa Ibom State, and the theme remains ‘Open Geospatial Innovation for Climate Action and Community Resilience’. The programme includes workshops, specialist talks on GeoAI, OpenStreetMap, citizen science, and climate action, as well as networking opportunities. Further information can be found on the conference website.

  • The Asociación OpenStreetMap España is hosting ‘SotMes 2026’ at the TomTom offices in Madrid on 6 and 7 November. This free gathering of the Spanish OSM community combines talks with an ‘unconference’. Anyone interested can register .

Maps

  • The Cunning Conquests Atlas is a free resource containing interactive maps of an ever-growing library of journeys. It was built with coastline data from OpenStreetMap and was released on 17 October. You can also watch the videos on YouTube with detailed legends.

  • Proton built a web map where you can look up any ZIP code in the US and find how many surveillance devices (flock cameras) are near your home. The device locations on this Flock camera map come from independent research by cybersecurity researcher Joshua Michael.

  • vetsurgeo launched The Church Atlas, a free map of more than 3,000 churches in 18 languages, using OpenStreetMap data, with Wikidata and Wikipedia providing addresses, summaries, and photos. He also shared the lessons learned about church tagging in a diary entry.

  • rpollock has published Walkably, a map showing pedestrian-friendliness across 31 European countries, based on OpenStreetMap data. Each hexagonal cell that intersects a road is assigned a score for the walkability of everyday destinations and for road quality (traffic, noise, shade in summer, main roads, gradient). An OSM blog post documented the checks made against census data. The full methodology is explained on the project page.

OSM in action

  • [1] Jiri Podhorecky worked on the graphic design and cartographic preparation of a printed tourist map of Prague, built directly on up-to-date OpenStreetMap data.

  • copilot.travel developed a dynamic map that shows each European capital claiming territory on the basis of the nationality of the first car to reach surrounding places, using typical road speeds and including ferries.

Software

  • Chris Debian has developed PillarPoint, an open-source Android app for people who find, visit, and record British trigonometrical points (trigs) and Ordnance Survey benchmarks. For each trig the app checks whether OSM already has a matching survey point and flags any OSM node that is some distance from the recorded station location.

  • GeoDesk released GOL Tool 2.5, adding support for incremental updates to keep local copies of OpenStreetMap data up to date.

  • Martin Faust has built Rücksitzhelden, a free app for families on long car journeys that shows ► attractions and family-friendly restaurants along the route using OpenStreetMap data.

  • Axel Piepgras has developed ► rueckenwind, an iPhone bicycle navigation app powered by OpenStreetMap data.

  • The well-known ‘Strava Slide’ algorithm, which allows drawn routes to be automatically adapted to and optimised for the Strava heatmap, is now available both as a browser extension ‘strava-heatmap-extension’ for Chrome and Firefox, or a JOSM plugin ‘josm-strava-tracer’. This tool allows the geometry of routes to be captured much more quickly and accurately based on aggregated GNSS tracks.

  • Ukrainian developers Vladyslav and Daryna Shinkarenko have developed Орієнтир, an iOS navigation app that works without GNSS. Instead, the app uses smartphone sensors to estimate the car’s speed and turns. It also offers offline maps of the whole of Ukraine, powered by OpenStreetMap data.

  • Victor explained how OsmAnd’s new search engine, built from scratch and recently released in version 5.5, works.

Programming

  • anthaas described how he automated marking small tasks, related to the Ebola campaign in the Democratic Republic of the Congo, as done in the HOT Tasking Manager using JOSM and the TM API.

Releases

  • HeiGIT has introduced a new openrouteservice web client, which replaces the two previous route planners. This article explains the new features, current limitations, and what users need to know before the old clients and deprecated API URL are shut down on 16 November.

Did you know that …

  • … the Magic Earth navigation app is based on OpenStreetMap data? It offers turn-by-turn navigation, offline maps, and speed camera alerts for iPhone, iPad, and Android; navigation is free, whilst additional features are available via a freemium model. The source code is not open. mobilsicher.de tested the Magic Earth navigation app back in 2019 and gave ► it a positive review (we reported earlier).

Other “geo” things

  • Geografías acuáticas: espacios de conectividad y sociabilidad, edited by Guadalupe Pinzón Ríos and Flor Trejo Rivera and published by the Universidad Nacional Autónoma de México, demonstrates how aquatic environments, rather than being peripheral or serving as spaces that separate societies, should be viewed as settings for diverse forms of connectivity, and within which forms of social interaction were also established that are, in fact, of great significance in a region such as this, where bodies of water deserve greater attention.

  • Sven-Erik Volberg posted a map of the approximate historical boundaries of the larger European states (those with an area over 100,000 square kilometres). The map covers around 1500 years from 500 CE.

  • The Direção-Geral do Território has announced ► the ‘XVII Jornadas Ibéricas de Infraestruturas de Dados Espaciais’ (Iberian Conference on Spatial Data Infrastructure), to be held from 11 to 13 November in Porto, Portugal. Those interested can register ► now.

Upcoming Events

Country Where Venue What When
🇲🇽 Ciudad de México Antiguo Colegio de San Ildefonso State of the Map Latam 2026 2026-10-27 - 2026-10-29
🇨🇭 Rapperswil-Jona OST RJ Gebäude 6, Rapperswil 20. Mapathon & Mapping Party Rapperswil 2026 2026-10-30
🇮🇹 Pesaro Biblioteca-Archivio “Vittorio Bobbato” Linux Day Pesaro 2026-10-31
🇮🇳 नई दिल्ली Jitsi Meet (online) OSM India - Monthly Online Mapathon 2026-11-01
🇩🇪 Hannover Kuriosum Stammtisch 2026-11-02
🇭🇺 Budapest United Platforms, Fény utca 16. OSM térképest – 2026 november 2026-11-03
Missing Maps London Mapathon Beginner Friendly (with Training) (Online) [eng] 2026-11-03
🇨🇭 Bern Provisorium46 Berner OpenStreetMap-Znacht 2026-11-03
🇩🇪 Stuttgart Forum 3 Café Stuttgarter OpenStreetMap-Treffen 2026-11-04
🇫🇷 Bar Le Schmilblik Rencontre mensuelle des contributeurs Paris sud 2026-11-05
🇪🇸 Madrid TomTom, Edificio Aqua, Calle Agustín de Foxá 4 State of the Map España 2026 (SotMes 2026) 2026-11-06 - 2026-11-07
🇫🇷 Angers L’Arrière Train, 3 rue de Frémur, Angers Angers Rencontre mensuelle OpenStreetMap 2026-11-06
🇦🇹 Salzburg HTL Itzling Maker Days Salzburg 2026-11-07
🇮🇹 Angera Mapathon @ Angera 2026-11-07
🇩🇰 København Cafe Bevar’s OSMmapperCPH 2026-11-08
CartONG : Mapathons en ligne 2026-2027 2026-11-09
🇹🇼 臺北市 MozSpace Taipei OpenStreetMap x Wikidata Taipei #94 2026-11-09
🇺🇸 Salt Lake City Woodbine Food Hall OSM Utah Monthly Map Night 2026-11-10
🇩🇪 Hamburg Voraussichtlich: “Variable”, Karolinenstraße 23 Hamburger Mappertreffen 2026-11-10
🇺🇸 San Jose Online South Bay Map Night 2026-11-10
🇬🇧 City of Westminster The Volunteer pub London pub meet-up 2026-11-10
🇩🇪 temporärhaus OSM-Stammtisch Ulm/Neu-Ulm 2026-11-10
iD Community Chat 2026-11-11
🇩🇪 München Echardinger Einkehr Münchner OSM-Treffen 2026-11-11
OSM US Mappy Hour: Mapping Route 66 Past & Present 2026-11-11
🇮🇳 Kottayam Kottayam, Kerala State of the Map Kerala (SoTM Kerala) 2026-11-14 - 2026-11-15
🇮🇪 Dublin 4 Inns Court, Winetavern Street, Dublin, D08 XY00 OpenStreetMap Ireland AGM - 2026 2026-11-14
🇮🇳 New Delhi South Delhi OSM Delhi Mapping Party No.34 (South Zone) 2026-11-15

This weeklyOSM was produced by MatthiasMatthias, PierZen, Raquel Dezidério Souto, Andrew Davidson, barefootstache, derFred, vicksun.
We welcome link suggestions for the next issue via this form and look forward to your contributions.

00:00 • 5 days ago

Saturday, 31. October 2026

Florian Lohoff

Addressextract testing

Today i made my first steps using Claude (sonnet-5) to add coverage, unit and mutation testing to addressextract. The testing needed synthetic input data which claude proudly produced.

I find it really fascinating how it derived the corner cases from the code and made the transformation into an osm.xml which contains all those cornercases.

The first shows admin and p

Today i made my first steps using Claude (sonnet-5) to add coverage, unit and mutation testing to addressextract. The testing needed synthetic input data which claude proudly produced.

I find it really fascinating how it derived the corner cases from the code and made the transformation into an osm.xml which contains all those cornercases.

The first shows admin and postal code boundaries, buildings and addresses in all sorts of relations. Some positions are to evade caching tricks in the Quad Tree. Some really present errors addressextract shall find like address A on node within building outline with address B. All kinds of missing tags, wrong tags, overlapping tags.

Some are to trick the position inside the bounding box, but outside of the geometry.

Fascinating times.

18:20 • 5 days ago

OpenStreetMap User's Diaries

OpenStreetMap Daily Challenge 2026

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

Very nice event, liked it a lot.

Report 🫡

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

31DayOSMChallenge #Maptober #Maptober2026

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

18:03 • 5 days ago

Ehiala’S Deck

Bar Ehiala’S Deck, parte das antenas

Bar Ehiala’S Deck, parte das antenas

16:03 • 5 days ago

OSM for Cities at State of the Map Latam 2026

On 29 October I presented OSM for Cities at State of the Map Latam in Ciudad de México. The project shows how well OpenStreetMap covers a kind of data in a given city, and how recently anyone touched it.

The slides are online, in Spanish.

♦ Photo by Jordan Jasuta Fischer

Most of the talk was a live demo with Mexico City bus stops, coloured by when each one was last edited

On 29 October I presented OSM for Cities at State of the Map Latam in Ciudad de México. The project shows how well OpenStreetMap covers a kind of data in a given city, and how recently anyone touched it.

The slides are online, in Spanish.

Wide view of the room from the side, every seat taken and people standing at the back by the windows Photo by Jordan Jasuta Fischer

Most of the talk was a live demo with Mexico City bus stops, coloured by when each one was last edited. When I made the slides, 317 stops had been edited in the past week, almost all along a few routes in the west of the city. Someone was mapping them right then. Most of the rest had not been touched in over 90 days.

Map of Mexico City bus stops coloured by last edit. A few routes in the west are dark purple, edited in the last 7 days (317 stops). Most of the city is light green, last edited more than 90 days ago (1,375 stops)

That is what the platform is for, following a dataset over time instead of looking at it once. Save a dataset and it is refreshed from OSM every day, and a notification arrive by email if it changes. A city team can see when its bus stops get mapped, and a mapper can see whether anyone else is keeping their area up to date.

Vector tiles are coming soon

Today a dataset loads into the page as one GeoJSON file. That works for bus stops, but not for the buildings or streets of a large city, which is why those are not on the platform yet.

Buildings matter most for disaster response and health planning. They show where people live, which is what a house-to-house campaign during an epidemic needs.

The fix is to bake each dataset into vector tiles (PMTiles), so the browser only loads what is on screen. It is ready and in testing, and should be released soon.

Development version of OSM for Cities showing the 68,500 buildings of Saint Lucia, mapped by 915 people, coloured by building type, mostly blue for untyped buildings and orange for houses

Thanks, State of the Map Latam!

It was great to be in Mexico City and see old and new friends from the OpenStreetMap community. The conference was very well organized, with an amazing diversity of talks. I’m looking forward to the next one, which will be both Latin American and global, State of the Map 2027, in Bogotá, Colombia.

Disclaimer: Written by me with AI assistance.

14:30 • 5 days ago