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

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

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

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). Figure 4: South view of Bow Lake with large scree slopes reaching the lake.

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

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

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

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). Figure 9: Big Bend viewpoint, looking south toward North Saskatchewan River, and Mount Cirrus (3270 m) on the left.

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! Figure 11: The few hundred meters hike to reach the closest point to the Athabasca Glacier that you can do on your own.

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

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

Jfd553

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

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.

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: &, <, ', ", 

• 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 
; 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'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:

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

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:

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!

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.

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: [link naar je itch.io-pagina]

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

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

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.

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.

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.

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.

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.

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

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

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.

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.

Registered in 2014, but I only started using OpenStreetMap actively last year.

After watching some Aboriginal movies of Australia, I switched from the Himalayas to Down Under, and then with chasing tracks in the outback of Australia—uncovering hidden reservoirs, basins, homesteads, cattle stations, farms, and surprisingly, some generous peaks. From there, I switched over to China, where the clever use of land through greenhouse horticulture stands out as one of the best examples of resourcefulness.

Flipping to Ethiopia brings a blend back to Nature: homes and huts constructed from natural elements offer a grounding perspective, even as the region slowly turns toward the so-called “blinded modernization.” Crossing over to South America, dense forest covers reveal hidden streams and alpine lakes tucked high in the mountain ranges, though the sheer scale of deforestation is disheartening to see.

Jumping to Japan and the Korean peninsula, the structured, disciplined approach to farming is among the finest in the world, matched by remarkable urban and human development.

Further north, the vast expanses of Alaska and Siberia ground you completely—reminding us of our fragile place within Nature and how quickly our so-called "development" will simply be reclaimed by time.

OSM has helped keep me calm, though it is still easy to get agitated. Now, I’ve even started mapping via my mobile browser as well, which has been a lifesaver while traveling on public transport. In a world full of towering billboards and aggressive roadside slogans, mapping on the move gives me the perfect excuse to ignore the visual pollution.

Of course, whenever I'm passing through true valleys and breathtaking landscapes, the phone goes straight into my backpack so I can take it all in.

Title: OpenHVRA: a free hazard, vulnerability and risk assessment tool built on OpenStreetMap

Hello mappers!

For years I have watched the same thing happen. A flood or any hazard hits a place, and the first questions are always the same: how many people live near the river, which schools and health posts are in the way, and what will it cost? Very often the best data to answer those questions is already sitting in OpenStreetMap, mapped by volunteers. But turning those buildings and waterways into a risk picture usually needs desktop GIS, paid software, or a specialist.

So I built a tool based on my professional experience, OpenHVRA (Open Hazard, Vulnerability and Risk Assessment) with help of my friend Claude, a free web map that does that analysis straight in the browser, using only open data.

Try it: gomalhunzai.github.io/openhvra Code (MIT License): github.com/gomalhunzai/openhvra

No login, no install.

How it works

You draw an area on the map (or upload a boundary as Shapefile, GeoJSON, KML, GeoPackage and a few other formats). OpenHVRA pulls buildings, roads, waterways and facilities from OSM through the Overpass API, adds open elevation tiles, and walks you through eight steps:

1. Area and data: download OSM layers, with a “light” mode for slow connections.
2. Population model: estimates residents per building from footprint and storeys, which you can calibrate with a census total.
3. Cursor probe: hover anywhere and see live counts of people, buildings and facilities within a radius.
4. Exposure by distance: what lies within X metres of rivers, streams or roads. It also checks height above the channel, so homes high on a hillside in a mountain valley are not wrongly counted as flood-exposed.
5. Flood risk and risk finance: flood depth per building for different return periods, damage using JRC depth-damage curves, average annual loss, and how losses could be split between reserves, credit and insurance.
6. Social vulnerability: a 0 to 1 index per home based on access to health care, emergency services and roads, housing fragility and crowding, plus optional census data and World Bank figures for vulnerable groups.
7. Multi-hazard risk: scores every building for river flood, flash flood, landslide, earthquake (USGS catalogue), coastal flood, glacial lake outburst flood (GLOF) and snow avalanche, then combines hazard and vulnerability into one risk score and a likelihood × impact risk matrix.
8. Report and downloads: one click gives a ZIP with CSVs, GeoJSON layers, 300 DPI map layouts and charts, all stamped with the tool version so results can be traced and cited.

There is also a 3D view that raises buildings to their mapped height over the terrain, which turned out to be a great way to explain risk to people who do not read maps every day.

Where you come in: better mapping, better risk estimates

OpenHVRA is only as good as the map underneath it. Some tags make a real difference:

• building:levels drives the population estimate and the 3D view. Even a rough count of storeys helps a lot.
• Building type (building=house, hut, apartments, commercial, etc.) feeds both the population split and the housing fragility score. Plain building=yes gives the tool much less to work with.
• Waterways drawn in the direction of flow are used to trace GLOF paths. A stream drawn backwards breaks the trace.
• Health facilities, schools, shelters and emergency services (amenity, healthcare, emergency) are what the critical facility analysis counts. If the clinic is not on the map, it is not in the report.
• Bridges and road classification matter for access and exposure.

If you run mapathons for disaster preparedness, this is a nice way to show volunteers what their mapping is used for: map an area, then open it in OpenHVRA and see the risk picture appear.

Status and feedback

OpenHVRA is in beta (v0.10.1). The methods are documented in the README and CHANGELOG, and version 1.0 will come once they are validated against real events. It is a screening tool to help prioritise, not a replacement for a detailed engineering study.

I would really like to hear from you:

• Try it on an area you know well and tell me if the numbers make sense.
• Open an issue on GitHub for bugs or ideas.
• If you use it in a project, mapathon or paper, please let me know. The “Cite this repository” button on GitHub gives you a citation.

Thanks to everyone who keeps mapping the places that need it most. This tool exists because of you.

Happy mapping!