Oh hey! I’m Agasta… I believe you don’t know me, so here’s my intro. This summer I was selected for GSoC to work on Nominatim with Sarah and Marc.

For anyone unfamiliar: Nominatim is a geocoder that uses OpenStreetMap data to turn place names and addresses into coordinates. Every place in OSM gets tagged with a key/value pair like amenity=restaurant or tourism=hotel, which Nominatim stores internally as a class/type combination. That’s the system this project changed.

At the start of GSoC, I wanted to give Nominatim a proper category model. By the end of the coding period, I had changed the import pipeline, the PostgreSQL schema, ranking and trigger logic, the search indexes, the migration path, the API, the SQLite adaptor, and quite a few tests.

That sounds nicely planned when written as one sentence. It did not feel that way while I was doing it.

The project started with a fairly clear problem: Nominatim only allowed one class/type pair per place. That works for a simple object, but it becomes awkward as soon as one object has multiple main tags. A hotel that also contains a restaurant could become two database rows. Administrative boundaries needed special handling through admin_level, and there was no useful way to express hierarchical filters such as “anything under osm.amenity”.

My midterm post covered the first half of the implementation. This is the final part of that story. If you don’t know Nominatim’s database schema, that is fine. I will explain the pieces that matter as they come up.

the project became a data-model change

The original model looked roughly like this:

The category model keeps both identities on one row:

The existing class and type columns did not disappear. They are still useful in API responses and for compatibility with existing consumers. Their role changed: categories became the source for filtering and classification logic, while class and type remained the familiar presentation fields.

The main storage choice was PostgreSQL’s ltree extension. A category is a dot-separated path, so PostgreSQL can understand that osm.amenity.restaurant is below osm.amenity without making the importer store every prefix explicitly.

-- Match all descendants of osm.amenity
WHERE categories <@ 'osm.amenity'::ltree

-- Match one exact category
WHERE 'osm.amenity.restaurant'::ltree = ANY(categories)

I had considered a TEXT[] column with prefix expansion and a GIN index. That approach would have avoided the extension dependency, but it would also have moved hierarchy handling into application code and stored more data. After testing the alternatives on real Nominatim data, ltree[] was the better fit.

There was one compatibility detail that mattered immediately. Nominatim supports PostgreSQL versions where ltree labels cannot contain all the characters that can appear in OSM tag values. The importer therefore normalizes labels, replacing hyphens with _ and falling back to yes for values that cannot be represented. The original value remains available through the normal class/type and extratags data.

That means a value such as:

shop=car-repair

becomes a category that can be stored safely across the supported PostgreSQL versions:

osm.shop.car_repair

PR #4106: generating one row instead of merging rows later

The first major implementation landed in PR #4106. It added the categories ltree[] column to place and placex, generated categories in the Lua import code, updated the SQL ranking and trigger functions, and added migration support.

One of the most useful review comments came from Sarah. My first implementation still produced one row per main tag and merged the rows afterwards. That model could work, but it created several rows only to immediately collapse them again.

So I moved the merge into process_tags(). The importer now collects the categories first and writes one row:

local categories = {}

for _, tag in ipairs(main_tags) do
    table.insert(categories, get_category(tag.key, tag.value))
end

insert {
    class = selected_class,
    type = selected_type,
    categories = categories,
    extratags = extratags,
}

The class/type winner is selected deterministically. The current rule is deliberately boring: use a stable ordering so that the same set of tags always produces the same legacy value. That stability matters during updates. If the winner changed randomly, an update could look like a different place to downstream logic even when the OSM tags had not changed.

Ranking was a bigger part of this PR than I expected. Nominatim calculates search_rank and address_rank from the place classification. Once one row can carry several categories, ranking has to inspect all of them and choose the best applicable result. The SQL functions that used to check conditions such as this:

class = 'boundary' AND type = 'administrative'

now use category paths instead:

categories <@ 'osm.boundary.administrative'::ltree

The same idea had to be applied to trigger code and the indexer. Yk I realized changing a db column in a mature system is rarely a local schema task. Every place that quietly depended on the old representation has to be found.

migrating a planet database without starting over

Fresh imports were straightforward once the schema and Lua code were in place. Existing installations were harder because placex is large enough that “just backfill everything” is a real operational decision.

The migration initially used lazy backfilling. When an existing row was touched, its category could be derived from the old class and type values. A smaller proactive backfill was still needed for places used as linking targets, especially higher-level address objects.

I tested the migration several times on a planet database. The first version created indexes before the bulk update and took about 63 minutes for 22,221,508 rows. Disabling the update trigger during the backfill and creating the indexes afterwards reduced that to about 47 minutes.

The temporary-table experiment was worse:

indexes first, triggers enabled       ~63 min
backfill first, indexes afterwards   ~47 min
temporary table approach              1 h 40 min

PostgreSQL’s plan for the temporary-table insert was poor, so the more complicated approach gave us a slower migration. The final process was simpler:

1. Add the column
2. Disable the relevant trigger
3. Backfill categories
4. Build the indexes
5. Re-enable the trigger
6. ANALYZE the affected tables

The final production-style migration took about 42 minutes on my planet database. The exact time depends on the machine, storage, and the state of the database, but the important result was that an operator did not need to wait three days for a complete reimport just to get the new column.

testing the first half, and one testing mistake

The geocoder tester became the main way to check whether the category changes affected ordinary search. On a full planet database, the corrected comparison was:

master       7919 failed, 11113 passed, 3264 skipped
PR #4146     7919 failed, 11113 passed, 3264 skipped

The first run made the PR branch look roughly twice as fast, but that was a cache artifact. When I changed the order and ran the tests repeatedly, whichever branch ran first was slow and the later runs settled around 15 to 16 minutes. The failure counts were the more important signal, and they were identical after the database was correctly indexed. For the larger tests, Marc gave me access to a server with a planet database and the extra postcode and ranking files. That setup used PostgreSQL 18 instead of PostgreSQL 17, so its absolute failure count was not directly comparable to mine.

Before that correction, I had blamed the category migration for a large group of airport regressions. The real problem was an interruption. In last PR testing I ran nominatim replication --catch-up, which left about 4.5 million rows at indexed_status = 2. Those places were not searchable because indexing had stopped part-way through.

That was my own testing mistake. I had changed the database state, failed to check the indexing status, and then started explaining the results as if the code were the only variable. A benchmark is only useful when the database behind it is understood.

PR #4146: replacing the old category search path

PR #4146 moved POI and near searches away from the place_classtype_* tables and onto the categories column.

Those old tables were materialized per class/type pair. A large installation could have hundreds of them, each with its own centroid index and trigger maintenance. The new query was conceptually much smaller:

-- Old path
SELECT place_id
FROM place_classtype_amenity_restaurant
WHERE centroid @ box;

-- New path
SELECT place_id
FROM placex
WHERE categories <@ 'osm.amenity.restaurant'::ltree
  AND ST_CoveredBy(centroid, box);

The first version of the new path exposed an index problem. The categories index could find every restaurant, but it knew nothing about the requested area. The geometry index knew about the area, but it was very large. PostgreSQL ended up building large bitmaps and combining them.

On a fully backfilled planet, osm.amenity.restaurant matched roughly 1.8 million rows. A near search could therefore pay to build a bitmap for almost every restaurant on Earth before applying the spatial filter.

The first numbers looked bad:

The fix was a combined GiST index and a return to centroid-based filtering:

CREATE INDEX idx_placex_centroid_categories ON placex
USING GIST (
    centroid,
    categories gist__ltree_ops(siglen=8)
);

The two changes had to land together. Switching only to centroid while keeping the old categories-only index was actually worse. With the combined index, the same tests looked much better:

The new index was still slower than the specialized old tables in some cases, but it replaced 428 tables and about 8.2 GB of separate table/index storage with one general-purpose index. The design also gave us a single place to extend category filtering later.

So, is it faster? The answer depends on the query. The combined index brings the new POI path close to the old specialized tables and makes near searches much better than the first category-only version. The bigger win is that the database no longer needs hundreds of separately maintained tables.

The index discussion changed my understanding of PostgreSQL GiST indexes. I initially explained the column order using an incomplete argument about which columns could be used by a multicolumn index. The real advantages of the chosen order were the measured index size, build time, and the way the centroid queries behaved. I remember we had some crazy testing and discussions over email about this before the change was finalized.

PR #4163: removing 428 tables

Once searches no longer depended on the old tables, PR #4163 removed the place_classtype_* table creation and maintenance code.

That removed more than a database object. It removed the special-phrase importer code that created those tables, trigger paths that maintained them, SQLite export code that copied them, and the --min option whose meaning only existed because those tables existed.

This was a satisfying change because the result is easy to explain:

before: one materialized table per class/type combination
after: one categories column and one indexed search path

It also made the architecture easier to reason about. A category is now data on the place, not a collection of side tables that happen to represent the same idea.

the API was originally a stretch goal

The project proposal treated API filtering as a stretch goal. Since the database work landed early enough, I added include and exclude to /search in PR #4164. This means users can now ask Nominatim for results under a category, or leave out a category, without knowing how the database stores the place.

Examples:

/search?q=restaurant+berlin&include=osm.amenity.restaurant
/search?q=berlin&include=osm.amenity
/search?q=hilton&include=osm.tourism.hotel&include=osm.amenity.restaurant
/search?q=restaurants+in+berlin&exclude=osm.amenity.fast_food

The semantics follow Photon’s category filters. A comma and a repeated parameter mean different things:

include=a.b,c.d       -> match a.b OR c.d
include=a.b&include=c.d -> match a.b AND c.d

exclude=a.b,c.d       -> exclude when both are present
exclude=a.b&exclude=c.d -> exclude when either is present

The last two rules look strange until the boolean logic is written down. They follow from applying De Morgan’s law to the exclusion groups, and they are compatible with the behaviour users already see in Photon.

The filter is applied across the search paths that return placex rows, rather than silently doing nothing on a normal name search. Sources without categories, such as postcodes, interpolations, TIGER data, and some country fallback tables, cannot satisfy an include filter.

The API work also found a bug in the PostgreSQL array result processor. It was returning the raw '{a,b}' array literal as a string. Once the new API started reading categories, SQLite export could interpret that string as individual characters.

That was a latent bug in the earlier category work, not something I had planned to fix. It is one reason I now try to test new data paths through every supported backend instead of only testing the path that motivated the change.

The final API tests cover validation, repeated parameters, hierarchy matching, AND/OR semantics, SQLite behaviour, and the POI, near, place, address, and country search paths.

documentation is part of the implementation

The last open piece is documentation. PR #4166 updates the migration, API, customization, and developer documentation for the category series.

I also had to be careful with terminology. Nominatim already uses “category” in a few older contexts, while the new data is stored in categories. Now calling the old class/type values categories made the documentation ambiguous. The final docs use “main tag” for the legacy class/type identity and reserve “categories” for the new paths.

wrapping up

The technical result is a category system, but the more useful outcome for me was learning how to make a cross-cutting change in a production-oriented open-source codebase. Once these changes land in a release, users will be able to filter search results by category directly through the API. For example:

/search?q=hilton&include=osm.tourism.hotel
/search?q=berlin&include=osm.amenity
/search?q=restaurants+in+berlin&exclude=osm.amenity.fast_food

No more second-guessing which “restaurant” result is the one you meant. You ask for hotels, you get hotels.

Getting to that simple API surface meant tracing a single concept across Lua, SQL, PostgreSQL indexes, Python search builders, HTTP adaptors, SQLite conversion, migrations, BDD tests. I also learned that reviews are part of the design process. The most important changes in this project came from questions such as:

• Why create several rows and merge them later?
• Which old class/type checks still need to become category checks?
• How much of the planet needs proactive backfilling?
• What happens when the category index sees 1.8 million restaurants?
• Can SQLite read the same category data?

Some of my first answers were wrong. Yk I remember my mentors telling me at the very first meet that we might get surprises and unplanned turns that always happen when a good plan meets reality. I get it now.

The GSoC period is ending and, according to our scope plan, the project is done. There is no unfinished follow-up task needed to use the feature. The category work can still grow later: current categories are derived from main OSM tags, and a future step could add richer categories such as cuisine.italian or access.wheelchair.yes once there is a clearer set of real use cases. The foundation now exists for that work without requiring another redesign of the search database.

For me, this summer turned a side-project curiosity about maps into a much better understanding of how a geocoder works under load. I got to work with a planet database, learned a lot about PostgreSQL, ranking, triggers, migrations, and so on. I had a really great time. It was crazy, in the best way.

Thanks to Sarah and Marc for their guidance, patient reviews, and all the unexpected questions that made the implementation better. Thanks to OpenCage for supporting the project with the server I used for the large database tests. And thanks to the OpenStreetMap community and the OpenStreetMap Foundation for making this work possible.

I had a great summer. Thanks for reading :)

If you wanna connect, find me on X or GitHub.

Agasta signing out.

The amount of data in OSM is climbing continually, and therefore the memory and disk requirements of osm2pgsql have risen as well. To address this issue we have applied for and won a grant from the NGI0 Commons Fund. In this project we want to reduce the memory and disk usage of osm2pgsql by implementing more efficient storage formats, specifically for “intermediate” data used while processing, often called the “middle”. We are tentatively calling this CODA, the Compact OpenStreetMap Data Archive. This will not only help with resource consumption on the community-run OSM servers, but also enable wider use of OSM data, even on planet-scale, in low-resource environments available to small NGOs or to students.

Long-time osm2pgsql developer Jochen Topf will be funded to work on this project for the next year or so. Progress and all the details will be published on the project’s webpage.

This project is funded through the NGI0 Commons Fund, a fund established by NLnet with financial support from the European Commission’s Next Generation Internet programme, under the aegis of DG Communications Networks, Content and Technology under grant agreement No 101135429. Additional funding is made available by the Swiss State Secretariat for Education, Research and Innovation (SERI).

so we have gotten a few questions about the project, mostly present in the first diary post we have made, but here we wanted to state a few basic things as a foundational- idk, statement so to say.

firstly, what are we actually doing and why?

so one night, at a random hackspace on the 25th of august, we were bored. and so with that boredom, we decided to fix something that had been annoying us for a long time; nearly every train station in germany that is not a transfer station, and honestly a lot that are!, are missing basic information about their track numbering, as well as generally just having a low quality of track and platform geometry (likely because most of that was put in automatically and no one bothered fixing it)

very quickly we realized, putting the exact sources (which, to be fair were more for reference than actual sourcing) into every single commit, of which there is at least one changeset per train station, was extremely tedious

so we made a post “hey we’re doing this thing”, to then go and have a way to simply refer to that project in the changeset commits, instead of the exact sources every single time.

this, has already gotten the attention of a few others on here, which honestly is both surprising, and humbling, as well as very motivating.

we are doing this, we will not stop doing this until we are done :3

secondly, how actually is information being sourced?

so this is fairly simple, but also very important to mention; while we have listed Bahnhof.de as a source, which at the time we did not realize could even theoretically be an issue, we technically did not even use it as a source- it simply is a good way to double check our work and to shove a url into the source field of our commits

in reality, here’s our source (in a sense); https://umap.openstreetmap.de/en/map/arson-railing_57214#7/51.075920/11.107178

^ that is a manually curated map we maintain, of every single railway we have travelled on since the beginning of 2024. obviously that itself is not a source but it shows something that needs to be said here; We Know Our Shit.

we have admittedly not been to Every single train station in germany, but we have been to a Lot of them. we map this out manually, with brouter and do our very best to make sure that every single entry is as accurate to the track we have been on as possible. (that process of mapping is largely why we have been so annoyed by how incomplete the data actually is on OSM)

we obviously don’t know everything, but we know german trains work, we know they run on the right side of the track, generally. we know where they go, generally, and we have been living in germany for years now- so we know what we’re doing.

anywhere that our experience is not enough to justify, we use services such as Bahnhof.de (https://www.bahnhof.de/) for specific stations (which, just so you know, is a publicly available source of information, reachable by anyone, without any kind of account or credentials within DBinfra), we use DBnavigator (https://int.bahn.de/en/ [DB’s website] // the mobile app called DBnav) but specifically the full route view of any given train, which is easy enough to find for pretty much any currently running passenger train across the entire network.

further, when we don’t want to use a stripped down frontend by DB themselves, anyone can easily access the data directly within HAFAS, by using Bahn Experte (https://bahn.expert/) to see the route which any given train operated by DB is scheduled to run along.

DBnav and Bahnexperte or any other train route viewer, is itself not specifically enough to say with certainty which tracks are which, However, that coupled with our own knowledge of how german railways operate and our own experience travelling throughout them, Is very much enough to say with certainty which tracks are which.

we’re not going to pretend we are infallible, but we aren’t going to pretend we don’t have experience and a lot of knowledge on the subject, which itself is useful to the broader goals of OSM. if anyone has an issue with that, then by all means we are more than happy to be supplied with more sources to use for this endeavour ^-^

finally, what if others want to help with this project?

we are more than happy to coordinate with others on this, and as is a comment thread on the previous diary entry about this project is concerned, we already are pursuing this :3

want to help? reach out. we’re gonna try and figure out the best way to organize this more formally, and it’s all still in the early stages obviously - we’ve only started this last week x3 - but we’re gonna do this and while we might not necessarily, strictly speaking Need help, we do very willingly accept it ^-^

Σήμερα έκανα λήψη 12 αρχεία gpx από τον εξειδικευμένο ιστότοπο του Δήμου Μεγίστης kastellorizotrails.com και προσπάθησα να τα προσθέσω στο openstreetmap.org. Η διαδικασία ολοκληρώθηκε κανονικά, προσθέτοντας τα αρχεία ένα ένα από το web interface, αλλά μόλις τελείωσα δεν εμφανιζόταν κανένα αρχείο στο μενού Τα ίχνη μου. Θα περιμένω 1-2 μέρες και θα το ξαναδώ. Έχω την εντύπωση ότι ίσως η ταχύτητα αποστολής των αρχείων να ενεργοποίησε κάποιο φίλτρο προστασίας.

I’m supposed to write a full report about my attendance at State of the Map 2026. But there are so many materials to discuss, especially the technical ones, and I’m already still stuck on day one already.

If you check my latest OSM Diary entry in my State of the Map 2026 series, you’ll see that my writing stopped rather abruptly at Jake Low’s talk, titled “Sourdough and Layercake.”

It was a very interesting talk. In fact, while watching it live through the Venueless platform, I had already started thinking about some projects that I wanted to build on top of Sourdough.

So instead of continuing to write that report, I started tinkering with Sourdough immediately.

The cool thing about vector maps is that they are so easy to customize on the client side. We can selectively show some data layers and hide the rest. We can emphasize one aspect while pretending that everything else is “not important” and simply not showing it at all. And I think that’s quite a powerful concept.

I’ve seen plenty of serious battles over OpenStreetMap edit wars whose underlying reason seems to be rooted in the “battle for dominance” in the OSM Carto raster map. The never-ending flipping of highway classifications. Arguments over which value a place=* tag should have (because some place values are prioritized for rendering over others). And so on and so forth.

Meanwhile, there’s this one limitation of raster maps that has been bothering me since I first started contributing to OSM.

Some POIs simply disappear. They aren’t rendered because their icons clash with other POIs. When two or more POI coordinates are too close to each other, the renderer has to choose which one gets priority and which one gets hidden.

And because the zoom level of the standard OSM Carto raster map is limited to 19, some POIs still can’t be shown even when we zoom all the way in. Well, theoretically, if the zoom level were increased beyond 19, those POIs would eventually become visible. But since the map stops at zoom level 19, they simply remain missing from the rendered map.

That’s quite disappointing, especially when you’ve already spent a lot of effort doing serious micromapping. It feels like some of your hard work has simply vanished into thin air.

So, for a long time, I’ve wanted to create an alternative “map view” that tries to solve all of these problems.

First, there is no highway classification. All highways are equal. From a motorway to a living street, every road is rendered with the same line width.

Second, it tries to show as many POIs as possible. Areas with a high density of mapped POIs are emphasized, and when you zoom in far enough, all the POIs are guaranteed to have their text labels shown.

Third, it is optimized for mobile use. Users can visit the web app, press the “zoom to my GPS coordinate” button in the bottom-left corner, and immediately zoom the map to their current location. The idea is that users can simply explore what OpenStreetMap has to offer in their own surroundings.

My hypothesis is that this could potentially be a better way to explore the world around you than g**e maps, which often prioritize advertisements rather than neutrally showing everything that has been mapped around you.

Fourth, don’t show anything else. The map focuses almost entirely on two things: uniformized road lines and POIs. The rest of the map data is omitted as much as possible.

The one exception is place=* objects. They are still shown as a guide, giving users some sense of where they are and helping them navigate the map.

And this is the result.

Here’s the source code.

You can access the live demo here.

I haven’t named the app yet. For now, I’m simply using the temporary name “sourtest,” which basically means “Sourdough test.”

Mapear en OpenStreetMap es dibujar el mundo real para que todos lo puedan usar.

1. Observas: Sales, miras a tu alrededor o usas fotos satelitales libres.
2. Dibujas: Pones un punto, una línea o un área en el editor (como iD).
3. Etiquetas: Le dices qué es con etiquetas, por ejemplo amenity=cafe o highway=residential.
4. Guardas: Tu aporte ya queda en el mapa global, libre y verificable por todos.

Empieza por lo que conoces: tu calle, tu tienda, tu parque.

How this started

A researcher from Puerto Rico reached out to me with a question about sub-national population figures in Iraq. While trying to help, I realised something surprising: although Iraq had conducted its first full population and housing census in decades — the 2024 Iraq Census — those population figures had not been mapped onto the administrative boundaries in OpenStreetMap. The data existed and was public; it simply had never been connected to the polygons.

This diary documents the work of closing that gap, from the national level down to district (qada) level, and — just as importantly — it records why some of the numbers on the official Arabic source do not line up one-to-one with the population now tagged on OSM polygons. If you are comparing the source document against OSM and something looks off, this entry is meant to explain it.

Primary source

The governorate and district figures come from the published 2024 census results:

https://alssaa.com/post/show/43032-iraq-2024-population-census-results-for-the-governorates

The page is in Arabic and lists each governorate’s total and a breakdown by qada (district). I worked from this document throughout. Where I refer to a name by translating it from the Arabic source, I put the translation in quotation marks — the official/authoritative spelling is the Arabic one, and I don’t want to imply my English rendering is canonical.

The guiding principle: population follows the polygon

The single most important decision in this whole exercise: each population figure was tagged onto the OSM polygon that geographically contains that place — not necessarily onto the governorate or district the census table lists it under.

This matters because Iraq has disputed and cross-listed territories where the census table and the OSM boundary disagree about which governorate a place belongs to. In every such case I let the OSM polygon decide where the number goes, and I documented the deviation. The result is that OSM stays internally consistent (a polygon’s population reflects what is inside that polygon), even where that means a governorate’s tagged total differs slightly from the census table’s governorate total.

The journey: national → governorate → district

admin_level 2 — the country

Iraq (relation 304934) already carried the correct national total, so this was a verification step rather than an edit:

• population=46118793
• population:date=2024
• source:population=2024 Iraq Census

admin_level 3 — the Kurdistan Region

The Kurdistan Region (relation 5392650) sits between the country and the governorates. It already carried population=6519129 (2024), which matches the sum of the four Kurdish governorates in the census (Erbil, Sulaymaniyah, Duhok, Halabja). Verified, no change needed.

admin_level 4 — the governorates

I checked all 19 governorate polygons. Most already carried correct census figures. The important structural points:

• OSM models Halabja as its own governorate (relation 3826029), whereas the census table folds Halabja in with Sulaymaniyah. OSM’s split reflects Halabja’s status as a separate governorate: the Kurdistan Region recognised Halabja as its fourth governorate around 2013–2014, though federal Iraq only made it official much later — the Iraqi parliament voted on 14 April 2025 and the law was published in the official gazette on 5 May 2025, making Halabja Iraq’s 19th governorate. The census’s combined “Sulaymaniyah” figure is therefore distributed across OSM’s separate Sulaymaniyah and Halabja polygons.
• Duhok (relation 2969732) is tagged 1,530,592 — see the Shaykhan note below for why this deliberately excludes one disputed district.

admin_level 6 — the districts (qada)

This is where the bulk of the work happened: tagging population on individual district polygons, using the census qada breakdown. The primary tags added on each district were:

• population=<figure>
• population:date=2024
• source:population=2024 Iraq Census

I worked governorate by governorate, and for every district I verified the district figures summed back to the governorate total before tagging.

Primary tags used

Across all levels the population tagging uses standard keys:

• population — the integer count
• population:date — 2024
• source:population — 2024 Iraq Census

Why some census numbers don’t match OSM polygons one-to-one

This is the section to read if you’re cross-referencing the Arabic document against OSM and puzzled by a mismatch. There are three distinct reasons.

1. Disputed / cross-listed districts (population follows the polygon)

Some districts appear in two governorate tables in the census, or are listed under a governorate that differs from where OSM draws the boundary. In each case I tagged the OSM polygon that physically contains the district, and used the figure consistent with that polygon.

• “Shaykhan” (الشيخان) appears in both the Nineveh table (117,621) and the Duhok table (69,279) — it is a single disputed district counted in two places. OSM draws its polygon (relation 3829511) inside Nineveh, so I tagged it 117,621 there. As a direct consequence, OSM’s Duhok governorate total (1,530,592) is exactly 69,279 lower than the census’s Duhok table total — because those people are counted once, inside Nineveh, where the polygon places them. This is not an error; it is the disputed boundary handled consistently.
• “Kifri” (كفري) — OSM’s polygon (relation 11063403) lies in Diyala, so it carries the Diyala-table figure 66,437. (It had previously been tagged 50,714, the Kurdistan-side slice; I corrected it to match the polygon.)
• “Khanaqin” (خانقين) — polygon (relation 11063394) is in Diyala and carries the Diyala figure 260,907.
• “Makhmur” (مخمور) — counted under Nineveh in the census and drawn inside Nineveh by OSM; the two agree, so no adjustment.

The general rule: if a governorate’s OSM total doesn’t match the census table, a disputed district on its border is almost always the reason, and the difference will equal that district’s population.

2. Composite districts (OSM has one polygon where the census lists several units)

In many governorates the census lists sub-district (nahiya) rows, or lists districts that OSM does not model as separate polygons. Where OSM has a single polygon covering an area that the census splits into several rows, I summed those rows and tagged the total on the one polygon — otherwise the people in the unmapped units would be lost. Each such polygon’s tagged value is therefore larger than the matching single row in the census table.

The composite districts, with what each is made of:

Anbar

• Al-Ramadi (11059955) = 716,314 — Ramadi 573,672 + الحبانية / “Habbaniyah” 142,642
• Al-Falluja (11059954) = 710,773 — Falluja 485,474 + الكرمة / “Karma” 147,125 + العامرية / “Amiriyah” 78,174
• Al-Qa’im (11059980) = 185,229 — Qa’im 140,923 + العبور / “Ubur” 44,306

Diyala

• Al-Khalis (11063406) = 431,184 — Khalis 356,395 + المنصورية / “Mansuriyah” 74,789
• Balad Ruz (11063398) = 166,845 — Balad Ruz 117,497 + مندلي / “Mandali” 49,348

Karbala

• Karbala (11058046) = 1,476,842 — Karbala markaz 811,368 + الحر / “Al-Hurr” 362,102 + الحسينية / “Al-Husayniyah” 194,589 + الجدول الغربي / “Al-Jadwal al-Gharbi” 108,783

Wasit

• Al-Suwaira (11052280) = 292,092 — Suwaira 226,734 + الزبيدية / “Zubaidiyah” 65,358
• Al-Hai (11052272) = 197,969 — Hai 136,984 + الموفقية / “Muwaffaqiyah” 60,985
• Al-Nu’maniya (11052275) = 196,006 — Nu’maniya 135,177 + الأحرار / “Ahrar” 60,829

Maysan

• Amarah (11045978) = 759,526 — Amara 719,898 + الكميت / “Kumait” 39,628
• Note: OSM’s “Western Ali District” (11045982) is the census علي الغربي / “Ali al-Gharbi” — a name difference, not a data difference.

Dhi Qar

• Al-Nasiriyah (11044703) = 845,276 — Nasiriyah 789,847 + البطحاء / “Al-Batha” 55,429
• Souq al-Shuyukh (11044692) = 373,378 — Souq al-Shuyukh 279,085 + كرمة بني سعد / “Karma Bani Sa’d” 94,293
• Al-Rifa’i (11044709) = 308,533 — Rifa’i 194,946 + النصر / “Al-Nasr” 113,587

Basra

• Al-Basrah (11042188) = 1,531,202 — Basra 1,337,707 + الهارثة / “Al-Hartha” 193,495
• Al-Zubair (11042178) = 682,482 — Zubair 598,460 + سفوان / “Safwan” 84,022
• Al-Qurnah (11042193) = 345,827 — Qurna 211,499 + الدير / “Al-Dair” 134,328
• Al-Midaina (11042180) = 309,525 — Madina 196,008 + الصادق / “Al-Sadiq” 113,517

Muthanna

• Al-Samawa (11042617) = 443,656 — Samawa 373,770 + السوير / “Al-Suwair” 69,886
• Al-Rumaitha (11042619) = 300,238 — Rumaitha 141,946 + المجد / “Al-Majd” 59,570 + الهلال / “Al-Hilal” 51,482 + النجمي / “Al-Najmi” 47,240

Qadisiyah (OSM has only 4 polygons; the census lists 13 units)

• Al-Diwaniyah (11048766) = 704,743 — Diwaniyah + الدغارة / “Daghara” + الشافعية / “Shafiya” + السنية / “Saniya”
• Al-Shamiya (11048776) = 292,108 — Shamiya + غماس / “Ghammas” + المهناوية / “Mahnawiya”
• Al-Hamza (11048771) = 266,560 — Hamza + السدير / “Al-Sadir” + الشنافية / “Al-Shanafiya”
• Afak (11048764) = 213,899 — Afak + آل بدير / “Al-Badir” + سومر / “Sumer”

Baghdad

• Al-Kadhimiya (2964709) = 1,085,792 — سما الكاظمية / “Sama al-Kadhimiyah” 639,059 + Kadhimiyah markaz 238,720 + فضاء الكاظمية / “Fada al-Kadhimiyah” 208,013
• Al-Istiqlal (11083458) = 323,517 — الزهور / “Al-Zuhur” 250,170 + الراشدية / “Al-Rashidiyah” 73,347. (Al-Istiqlal is a newer district with no standalone census row; its two nahiya sit inside this polygon.)

Erbil / Kurdistan — a few Erbil districts absorbed neighbouring units that OSM does not model separately:

• Erbil District = 1,329,246 — Erbil 1,288,538 + عنكاوة / “Ankawa” 40,708 (no separate Ankawa polygon exists)
• Soran District = 198,805 — Soran 179,596 + سيدكان / “Sidakan” 19,209 (no separate Sidakan polygon exists)
• The Bnaslawa district polygon appears in OSM as دەشتی هەولێر / “Dashti Hawler” (Kurdish).

3. Districts still pending (Babil)

Two Babil polygons are deliberately left untagged for now, because the census and OSM disagree in a way I could not resolve cleanly at district level without risking double-counting:

• Al-Hashimiyah (الهاشمية) (11053207)
• “Western Al-Hamzah” (الحمزة الغربي) — centred on “Al-Madhatiyah” (المدحتية) (11053204)

The census reports a القاسم / “Al-Qasim” qada (247,784) and a الهاشمية / Hashimiyah qada (359,137), while OSM nests these differently: OSM places القاسم / “Al-Qasim” as a sub-district inside the Al-Hashimiyah district polygon, and models المدحتية / “Al-Madhatiyah” — historically split from the Hashimiyah district — as its own separate district polygon (labelled الحمزة الغربي / “Western Al-Hamzah”). The census does not break the Hashimiyah figure down finely enough to know how much of it belongs to the Al-Madhatiyah polygon versus the Hashimiyah-centre area, so I could not split it across the two OSM polygons without guessing. Rather than invent a split, I tagged the other five Babil districts (الحلة / Hilla, المسيب / Musayyib, المحاويل / Mahawil, الكفل / Kifl, كوثى / Kutha) and left these two untagged.

The figures, for anyone who wants to assign them (at their own risk): the two polygons together hold 606,921 — that is القاسم / “Al-Qasim” 247,784 + الهاشمية / Hashimiyah 359,137. One reading (following OSM’s nesting, with Al-Qasim inside Al-Hashimiyah) would put the whole 606,921 on Al-Hashimiyah (11053207) and leave “Western Al-Hamzah” (11053204) blank. Another reading would put 247,784 on the “Western Al-Hamzah” polygon and 359,137 on Al-Hashimiyah. Neither is confirmed by the census — which is exactly why I left them untagged — so whoever assigns these should pick one, document their choice, and understand it is not certain. Either way the population is not lost: it remains accounted for in the governorate total (2,482,324).

Summary of what changed on OSM

• Verified national (admin_level 2) and Kurdistan Region (admin_level 3) totals.
• Verified/confirmed all 19 governorate (admin_level 4) figures, keeping Halabja separate and Duhok excluding disputed Shaykhan, per the polygons.
• Tagged population, population:date=2024, source:population=2024 Iraq Census on district (admin_level 6) polygons across all governorates except two pending Babil districts.
• Corrected one district (Kifri) whose previous tag did not match the polygon’s governorate.
• Wherever the census splits an area into units OSM does not model, summed those units onto the containing polygon (documented above).
• Throughout: population assigned to the polygon that geographically contains it.

A note for anyone comparing the census to OSM

If a governorate or district total on OSM doesn’t match the Arabic census document, it will be one of three things, all intentional:

1. a disputed district whose polygon OSM places in a different governorate than the census table (e.g. Shaykhan, Kifri);
2. a composite polygon whose tag sums several census rows because OSM has one polygon where the census has several units;
3. the two pending Babil districts (الهاشمية / Al-Hashimiyah and الحمزة الغربي / “Western Al-Hamzah”), not yet tagged, holding 606,921 between them.

None of these are data errors — they are the unavoidable consequence of reconciling a tabular census with a set of real-world polygons, resolved in favour of the polygon.

Source: 2024 Iraq Census — governorate and district results, published at alssaa.com (https://alssaa.com/post/show/43032-iraq-2024-population-census-results-for-the-governorates).

What an event.

The local community prepared a really nice venue with a surprising Guest as entertainment as well as really tasty snacks. Well done.

I should have asked on the first day so now it’s just some thinking: Was there no way of getting better ventilation into the rooms at the university? But as I said, it’s now too late and I won’t linger on that any more.

More thoughts are still to come.

After a few “shakedown cruises” with the Max2 I began collecting imagery in earnest in August, and learned a few lessons.

1. Massive 10Gb files overwhelm older MicroSD-to-USB card readers. I struggled to copy the .360 files from the SD card to my desktop computer’s SSD drive, and resorted to Disk Drill (sometimes worked) and Roadkill’s Unstoppable Copier (sometimes worked) to copy them when copy, xcopy, and the Windows copy utility failed. I asked GoPro if it could identify the problem. When GoPro asked if I had tried a different card reader, I blew $7 on a new one rated USB-2 and it worked without problem. Issue solved, and something learned–just because a piece of hardware worked flawlessly for a decade doesn’t mean it will work today with the larger file sizes inherent to 360-degree imagery.

2. The battery lasts about 2 hours or less and a 64Gb SD card fills up in about 2 hours. Letting the camera battery die while filming is a headache, because the file isn’t closed properly. This is where Disk Drill came in handy to repair it so it could be copied and uploaded to Mapillary. A similar issue appears if you run out of storage. I blew $99 on a 256Gb SD card to avoid running out of space and put my wife in charge of monitoring battery life on the Quik smart phone app. Her reward for this is lunch at restaurants we have discovered while collecting imagery.

3. The Max2 can be toggled between collection at 5.6K and 8K resolution. I have experimented with both. Mapillary recommends 5.6K video at 30 frames per second but I have found that this makes reading house numbers difficult to impossible, and signage of businesses becomes very iffy. When experimenting with 8K resolution, I found both house numbers and signage become clearer and thus readable for addition to the OSM database. The tradeoff is file size, which quickly becomes an argument for a larger SD card (the Max2 can accommodate up to 1 Tb if you are willing to spend the money).

We have found a marvelous antique shop (even though we don’t need any more furniture), a fabulous Uyghur/Uzbek restaurant, and a shoe repair shop we didn’t know existed.

Salut

Une belle personne m’a parlée de QuackOSM quand je lui faisais part de la difficulté d’installer un serveur Overpass-API pour faire des requêtes en locales sans charger les serveurs communautaires.

Alors j’ai essayé … Et ça déchire de simplicité. 🤩

📢 ATTENTION: la doc est explicite : relations must be of type boundary or multipolygon. Il y d’autres contraintes, ce sera donc à voir selon les besoins …

Comme QuackOSM est un module Python et que je m’y perd tout le temps j’ai utilisé uv. QuackOSM se charge du téléchargement des fichiers PBF par exemple sur GeoFabrik OpenStreetMap Data Extracts.

Il suffit donc d’une seule ligne :

uvx --from 'quackosm[cli]' quackosm \
 --osm-extract-query France \
 --osm-extract-source geofabrik \
 --working-directory ./ \
--ignore-cache \
--cpu-limit 8

Ou si vous avez déjà le fichier “france-latest.osm.pbf”

uvx --from 'quackosm[cli]' quackosm france-latest.osm.pbf \
 --ignore-cache \
 --cpu-limit 8

Pour obtenir le fichier “geofabrik_europe_france_nofilter_noclip_compact_sorted.parquet” (9 Go) au format GeoParquet.

À noter:

• l’extra quackosm[cli] pour éviter “ModuleNotFoundError: No module named ‘click’”
• Au premier appel, uv télécharge et résout les ~40 dépendances (duckdb, pyarrow, numpy, shapely, etc.) et les met en cache localement

En suite on peut utiliser DuckDB pour faire des requêtes sur des objets OSM.

Par exemple avec l’outil de bureau DBeaver on créer une connexion DuckDB (le driver est téléchargé automatiquement), on ouvre une console SQL sur la connexion et :

-- les points d'eau potable dans le périmètre de "Tours Métropole Val de Loire"

INSTALL spatial;
LOAD spatial;

-- Récupérer la géométrie de "Tours Métropole" (un POLYGON)
WITH tours_metropole AS (
    SELECT geometry
    FROM geofabrik_europe_france_nofilter_noclip_compact_sorted
    WHERE tags['boundary'] = 'local_authority'
      AND tags['name'] = 'Tours Métropole Val de Loire'
    LIMIT 1
)

-- Récupérer les points d'eau potable (POINTS) dans cette géométrie
SELECT
    feature_id,
    tags['name'] AS name,
    ST_X(geometry) AS longitude,
    ST_Y(geometry) AS latitude
FROM geofabrik_europe_france_nofilter_noclip_compact_sorted
WHERE
    -- Filtre sur les points d'eau potable (amenity=drinking_water)
    tags['amenity'] = 'drinking_water'
    -- et que la géométrie est un POINT
    AND ST_GeometryType(geometry) = 'POINT'
    -- et que le point est dans la géométrie de "Tours Métropole"
    AND ST_Within(
        geometry,
        (SELECT geometry FROM tours_metropole)
    );

-- Et 3.7 secondes plus tard :

|feature_id|name|longitude|latitude|
|----------|----|---------|--------|
|node/7285184855||0.5381852|47.3109468|
|node/2431342938||0.5143303|47.3412371|
|node/461205675||0.5452565|47.3481125|
|node/6624591422||0.5471518|47.3482322|
|node/3613483888||0.5489893|47.3489299|

Notes:

• le “FROM” est le nom du fichier GeoParquet sans l’extension

Et on peut utiliser tout plein d’autres connecteurs DuckDB pour l’utiliser dans son langage préféré.

J’adore ! Il est content Rosco. 🥳

(Пост написан без использования ИИ)

Песок, вода и вид

Нормальный песок, без мусора. Вода тёплая, но после чистая только утром и в обед. Виднееться остров Тафос.

Транспорт и парковка

Утром всё пусто, нигде нет знаков “Парковка запрещена”, эвакуваторов нет, все паркуються нормально, ничего не заграждают, мотоциклисты не бояться стоять на тротуарах, все велосипедисты - местные. Остаёться вопрос - где автобусы и такси?

Инфраструктура

Есть открытый душ, кран для мития ног, небольшая унисекс раздевалка, рестораны. Гостинные везде. Главные проблемы:

• узкий выбор еды в ресторанах
• нет просто магазинов
• и самое главное - НЕТ ТУАЛЕТА, даже в кусты лучше не ходить

Развлечения

Есть небольшая спортплощадка (возможно при школе/клубе т.к. она ограждена), место для пляжного волейбола, типо велодорожка (больше походит на обычный тротуар). Типо проблема - не туристический район. Более реальная проблема - нет детской площадки, дети возможно будут сидеть в телефонах

Местные

В заведениях все работники могут разговаривать на английском, но не на болгарском/русском. Иногда слышно знакомую болгарскую речь. На одну грецкую машину здесь 1 болгарская/румынская/молдавская, западных европейцев мало. Людей даже вечером немного

Цены

ошибка 404, ищите самостоятельно

Итог в двух словах

Неплохой пляж, стоит брать гостинницу на одну ночь, но маленьким детям может быть скучно.

According to my personal schedule, I was supposed to attend the Guadeloupe room at around 14:50, for a talk titled “State of Panoramax.”

But in reality, the opening speech was still continuing at least until 15:02, and I had to sign out at 15:16.

I managed to finally come back at around 15:56, but by that time, the Guadeloupe room was already empty.

I managed to access the “traces of discussion about the talk” that were still left behind in the Venueless chatbox.

Someone asked this question at 15:21: “Question for Panoramax: What’s your take on privacy. Even with blurring, by having people take photos across a wide time range, AI will be able to deduct when someone was at home, where certain cars were parked and so on, revealing lots of personal info. Is that a good thing that we want to support?”

I have known Panoramax for a long time.

While editing WeeklyOSM’s entries, I frequently received news about their releases and updates. I also happened to learn about updates regarding Baba, a mobile app for contributing to the Panoramax project, because of my activity with WeeklyOSM.

But recently, I finally installed Baba and uploaded photos to Panoramax for the first time, thanks to someone’s suggestion on c.osm.org. I documented the whole train of thought behind this decision in this Mastodon thread.

The real reason was my realization that photographs uploaded through StreetComplete’s note feature are temporary and are going to be deleted soon. I wanted something similar, but permanent. Someone on c.osm.org – I forget who and in which thread – suggested using Panoramax instead. I tried it, and it worked.

Even so, at first, I had quite a hard time finding the right Panoramax instance, because most of them are limited to specific geographic regions, and my country is not listed.

MapComplete’s Panoramax instance promises an “Anywhere you like” guarantee, but I didn’t know how to simply upload photos without picking the right MapComplete theme. I couldn’t find the theme I needed. I wanted to upload photos taken on a specific road.

osm-fr? “Pictures preferably in France but allowed for Worldwide test”. That “test” thing made me uneasy. Does it imply that everything will be cleared after the test is over?

After scrolling all the way down, I finally found an instance that suited my needs : panoramax-ulm.

“Worldwide. The picture can be sent from anywhere in the world. 67k++ pictures. 19 contributors. Last activity 1 minute ago.”

Cool.

So I configured my Baba app to send photos to the panoramax-ulm instance. I tried uploading two photos while specifying the coordinates and angle of each shot.

Success. Nice.

But when I tried to upload my third photo, Baba showed an error warning without specifying what the error actually was.

I assumed that maybe the panoramax-ulm instance was temporarily down.

So I waited for several hours and then tried uploading the photo again.

Nope. Still an error.

So I tried uploading it to a different Panoramax instance.

Nope. Still an error.

Frustrated, I uninstalled the Baba app.

And that’s the real origin story of why I wanted to attend this talk.

What is the “State of Panoramax” today?

But while preparing this article, I started thinking of a different solution to fix this mysterious “third photo error”: what if I uploaded it directly through the web interface instead of uploading it via Baba?

And it still returned an error.

But at least this time, it gave me a nice, informative error message.

It said that there was missing metadata in my third photo, specifically the “date taken” field.

Weird.

Even though my first and second photos worked normally, I wondered what had actually caused this problem. My phone?

So I modified the metadata directly, aligning the “date taken” field with the actual date the photo was taken, which was conveniently stored in the filename, actually.

Then I tried uploading it again.

Success.

Nice.

So, it was partly Baba’s fault. Instead of simply showing an error message without any explanation, it should show the actual reason why the operation couldn’t continue.

But at least now I know that I can simply upload photos directly through the web interface.

Case closed.

Alright, let’s get back to the afternoon of August 28.

At 15:56, I found the Guadeloupe room already empty. After reading all the traces of discussion in the Venueless chat room, at 15:58 I went to the La Réunion room.

But nothing was being streamed there.

I went to Martinique.

Another empty room.

I went to Corse.

No stream.

I went to “TV Set.”

There was a video message:

“Up next. Guadeloupe. Geodesk 11:15–11:35 (start in 15 minutes).”

Then there was this message broadcast on the Venueless platform:

“Session will resume at 11:15 Paris time!”

That’s 16:15 in my local time.

So I still had around 15 minutes to kill.

I decided to go to osmbc.openstreetmap.de to do my daily WeeklyOSM duty.

At 16.19, I went to the Martinique room to attend a talk titled “Sneaking in OSM data into a Big Old Company” by Tristram Gräbener and Céline Durupt.

It turns out that the “big old company” is SNCF Réseau, the state-owned national railway infrastructure manager in France.

In their talk, they introduced osrd.fr, “Open Source Railway Designer,” a free and open-source software that simulates the operation of a railway network.

They also discussed the current state of OSM railway data in terms of usability and data quality, ranging from good (tracks, speed limits, electrification, and gauge), to okay (signals), and… bad (?) (stations).

They explained their workflow for “working” with OSM data in the wild, only to discover that a certain OSM contributor had already done one of the hard part : “integrating” the OSM data into their own internal reference system, which had already been published as open data.

And then came the final cherry on top : how to slowly overcome the inertia of a big corporation and get it to start adopting “the OpenStreetMap way” (… by luring them with cake).

They also noticed that other SNCF entities in France are already using OSM, contributing to OSM, and even meeting with each other at SotM.

In the final slide, they shared their concluding remarks about working with OSM data in the context of a big old company.

The talk ended at 16.37, followed by a Q&A session that lasted until 16.50.

At 16.51, I joined the La Réunion room, where there was a community panel discussion titled “The Democratic Stakes of Mapmaking.”

The panel featured Ksenia Ermoshina, Christian Quest, Françoise Bahoken, and was moderated by Matthieu Chatry.

Well, I didn’t watch it in full because there was another talk I was interested in watching that was running in parallel. So I had to move back and forth between La Réunion and Guadeloupe, then back to La Réunion again, and so on and so forth. But here’s some gist of the discussion that I managed to catch.

During the panel discussion, Christian Quest, as the product owner of Panoramax, occasionally shared several anecdotes from building and maintaining the Panoramax project, especially some of the unexpected use cases that emerged from real users.

Ksenia Ermoshina explained several map-based civic movements that took place in Saint Petersburg.

Françoise Bahoken gave a presentation as well. Of all the slides, this one resonated with me the most… You can probably guess why.

I was literally at the edge of my seat when I saw the heading “A combat sport”. I thought it was going to be a deep dive into the intricacies of OpenStreetMap edit wars.

Turns out, it was about rigging elections and world domination.

“Whoever controls the maps controls the world. Indeed, maps are formidable instruments of power, whether for controlling a country or rigging an election. But are they not also formidable weapons for challenging the established order? Cartographers of all nations. Unite!”

At 16.51, I joined La Réunion, only to discover that there was a sound problem. So I switched to Guadeloupe.

In the Guadeloupe room, the speaker, Pieter Vander Vennet, was comparing the iD editor and JOSM based on “ease of use” versus “powerfulness.” His talk was titled “Perspectives on Editors.”

At 16.55, I went back to La Réunion. The sound problem had already been fixed, but the panel discussion had not started yet. They were still doing the introductions.

At 16.58, I went back to Guadeloupe. The speaker there was introducing himself as the main developer of MapComplete.

At 17.00, back to La Réunion.

At 17.15, back to Guadeloupe.

At 17.23, Pieter showed this slide, which I quite strongly agree with.

At first, I was simply an iD editor user.

Then someone persuaded me to try JOSM. Even though the initial learning curve was steep, JOSM eventually grew on me. After getting familiar with JOSM, I started switching between iD and JOSM depending on the use case. A simple, small POI addition? iD. A huge edit spanning a large area? JOSM.

Then recently, I stumbled upon the profile of a veteran OSM mapper and noticed that they endorsed StreetComplete as one of the best mobile editors for OSM. I tried the “EE” (Expert Edition) of StreetComplete, and I’ve been falling in love with this editor ever since.

At 17.28, the talk in Guadeloupe finally ended.

At 17.33, back to La Réunion.

At 17.40, back to Guadeloupe. This time, it was a different talk: “Update on Attribution Enforcement for Users of OpenStreetMap Servers.”

There, Mateusz Konieczny explained the grim consequences for app developers who fail to properly comply with OpenStreetMap’s licensing and attribution requirements: getting blocked from the OSM tile servers. Instead of displaying the map tiles, the app shows an error notice: “ACCESS BLOCKED. THIS APP IS BLOCKED FOR NOT ATTRIBUTING OPENSTREETMAP’S VOLUNTEER-RUN SERVERS”

Thanks to this direct enforcement action, several app developers stopped using OpenStreetMap altogether and switched to Google Maps instead.

And apparently, you can enlist yourself in the “hunting team” too, by finding strong evidence of a web app or mobile app that does not properly comply with OSM’s attribution requirements, then submitting your tip here.

At around 17.48, I had to sign out because of some IRL activities.

7:36 pm, I jumped into Guadeloupe to watch the talk titled “Emergency Services Using OpenStreetMap in Germany.”

David Ganske from the German Fire Protection Association (vfdb) explained how OpenStreetMap data supports the operation of emergency services, ranging from OSM basemaps in command-and-control systems to various OSM-related apps used by crews on their personal phones, as well as several OSM tags that help support the team’s operations, such as surface=*, lane_markings=*, cycleway:separation=*, entrance=*, and paths to entrances.

The talk ended at 8:13 pm, followed by a Q&A session that lasted until 8:17 pm.

At 8:18 pm, I switched to La Réunion. There was a talk that looked very interesting, titled “Publishing 14,000 Businesses to OpenStreetMap: How Community Feedback Reshaped Our Publisher.”

Based on the talk description, it seemed that there was this French startup, Digitaleo, that allows business owners and chain managers to update information about their stores simultaneously across several platforms, including Google Business Profile, Apple Business Connect, Bing Places, Facebook, and OpenStreetMap. Apparently, there had been some pushback from the OpenStreetMap France community regarding the OSM edits related to this startup. After some discussion, they fixed the process. “A single complaint is an opportunity to correct the system upstream so the same class of problem can’t repeat. That philosophy, more than any technical decision, is what I’d like other organised editors to take away,” they said.

Unfortunately, the talk was in French, and I can’t understand French. But at least I could copy and paste the discussion and questions from the chat into a translation app:

“Digitaleo seems to target chains. How can an independent store manage its presence on OSM?”

“Are you working on the project alone?”

“Can you share some details about the technical stack used in your contribution process?”

“Since you retrieve OSM data, how do you handle data licensing issues?”

“Over the course of a week or a month, for example, how much data do you estimate retrieving from OSM versus how much data Digitaleo contributes to OSM?”

“Have you considered open-sourcing your contribution stack (at least the OSM component) to receive direct contributions to your codebase from the OSM community?”

It seemed that the discussion was quite lively.

At 8:41 p.m., I switched to Guadeloupe to watch a talk titled “Do Maps Have a Future in OpenStreetMap?” by Christoph Hormann, one of the maintainers of the OSM-Carto project.

The talk ended at around 9:09 p.m. I immediately switched back to La Réunion. Over there, the talk titled “OSMPID: A Persistent ID Specification and an Object Identity Service” was still happening midway through, despite having started at around 8:40 p.m.

The discussion, both in person and in the chatroom, seemed very lively. SK53 shared a blog post related to the discussion about some oddities found in the OpenStreetMap history files. It was quite relevant to the topic of persistent OSM object IDs.

The talk finally ended at 9:25 pm. It was time for a coffee break.

At 9:43 p.m., I joined Guadeloupe to watch a talk titled “Client-Side Transport Maps on OpenStreetMap.org” by Andy Allan, a maintainer of the OpenStreetMap website.

The talk started at 9:48 p.m.

He shared his experience working with vector tiles to develop and deploy the vector-based “Transport Map” layer, which is now available on openstreetmap.org.

While working on the project, he noticed several differences between working with Mapnik, which powers the raster tiles, and MapLibre, which powers the vector tiles.

He discovered several hacks that could be used as workarounds to fix some of the “visual bugs” he encountered in MapLibre.

Here’s one of the demonstrated visual bugs, which makes the railroad line look quite messy.

However, in some specific cases, Mapnik still contains plenty of features that have not yet been implemented in MapLibre at all. This makes the quest to create beautiful map tiles, or at least ones as beautiful as the “gold standard” Mapnik-based raster tiles, considerably harder.

Another problem he discovered involved MapLibre’s .json stylesheet source code, which requires a lot of copy-pasting of repeated styles when designing a complex stylesheet.

To address this, he developed “glug”, a markup language designed to simplify stylesheet development in MapLibre. He admitted that some of the more recent features in glug were developed specifically to solve problems he encountered while creating the “Transport Maps” layer.

The talk ended at 10:09 p.m.

After the talk was over, I immediately switched to La Réunion, hoping to catch another talk titled “Mapterhorn Terrain and Imagery,” but it seemed I was too late. The talk in La Réunion had already ended as well.

So, at 10:15 p.m., I went back to Guadeloupe. The Q&A session from the previous talk was still going on until 10:17 p.m.

The next scheduled talk in the Guadeloupe room was titled “Sourdough and Layercake: Removing Technical Barriers to Using OSM Data for Cartography and Analysis” by Jake Low of OpenStreetMap America. The talk finally started at 10:20 p.m.

Muy bien planteado, se realiza con mucha facilidad y se puede encontrar muy rápido para el destino deseado, excelente opción

Whenever I run, I carry a GPX device to track my route. Over time, I’ve collected a large set of personal GPX traces. It made me realize that this personal dataset isn’t particularly valuable when I look at individual traces, but it can be made useful once I’ve collected multiple traces over the same city neighborhood. The problem is that I have no idea where OSM ways are missing. This sounds like a great use case for aggregated personal data, because you tend to run the same streets most of the time. The basic idea is very simple: split GPX files into smaller segments, cluster them, and check whether each cluster maps to a known path or street in OSM. Then create an OSM extract for the new paths, along with the original GPX files, so that edits in JOSM are faster. It works! The slow part is making the edits, but at least you are aware of where OSM is incomplete in your neighborhood. The source code is on GitHub

– Portuguese below  

DO THE RIGHT THING AND RECEIVE GOOD IN RETURN: THE ETERNAL CYCLE OF CONSTRUCTION

First Moment - That was the question: to attend in-person the SotM 2026 Paris or to support groups in Africa?

Around the same time that the organizers of State of the Map 2026 were offering early-bird tickets for the OpenStreetMap global community event, I was approached by groups of mappers from Africa, asking my company to support (as a sponsor) the initiatives they were planning, focusing in mapping features that were important to them and their community, based on their local realities.

So, rather than spending our resources on a sponsorship for the SotM 2026 event and attending in person in Paris, we decided to support three groups of young mappers from african countries: Cameroon, Kenya, and Ghana.

CityMapper Externship: Urban Street Level Mapping by the UN Maps Community Ambassador Initiative Cameroun - Link

UN Mappers Kenya Youth Climate Mapping Externship 2026 by the UN Maps Community Ambassador Initiative Kenya - Link1 and Link2

First 2026 mapathon by the YouthMappers UEW (Ghana) - Link 1 and Link 2

Source: YouthMappers UEW group

Second Moment - Presentation of the ODbL/FPOSM booklet translations done by Editora IVIDES

The translations of the booklet on the ODbL license, originally published by the Fédération des Pros d’OpenStreetMap (FPOSM) - Tout savoir sur la license ODbL : la licence d’OpenStreetMap pour cartographier en commun, were mentioned at the global State of the Map 2026 event, held in Paris.

Session of the SotM 2026 where translations were presented by the FPOSM.

You can access the publications in three languages on the Zenodo.org - Portuguese, English and Kiswahili:

Tudo o que você precisa saber sobre a licença ODbL - PDF Link - PT;

Everything you need to know about ODbL license - PDF Link - EN;

Kila Kitu Unachohitaji Kujua Kuhusu Leseni ya ODbL - PDF Link - SW.

The three front covers to translation for Portuguese, English and Kiswahili.

On the Editora IVIDES, you can find the other books already published in Portuguese and English.

– PT –

FAÇA A COISA CERTA E RECEBA O BEM DE VOLTA: O ETERNO CICLO DA CONSTRUÇÃO

Momento 1 - Essa era a questão: participar presencialmente do SotM 2026 Paris ou apoiar grupos da África?

Na mesma época em que os organizadores do State of the Map 2026 estavam disponibilizando a compra antecipada de tickets para o evento global da comunidade OpenStreetMap, eu fui procurada por grupos de mapeadores da África, para que a minha empresa apoiasse (como patrocinadora) as iniciativas que estavam planejando para mapear feições importantes para eles, de acordo com suas realidades locais.

Assim, entre gastar nossos recursos com um patrocínio no evento SotM 2026 e estar presencialmente em Paris, decidimos apoiar três grupos de jovens mapeadores, em países africanos: Cameroun, Quênia e Gana.

CityMapper Externship: Urban Street Level Mapping by UN Maps Community Ambassador Initiative Cameroun - Link

UN Mappers Kenya Youth Climate Mapping Externship 2026 by UN Maps Community Ambassador Initiative Kenya - Link1 e Link2

First 2026 mapathon by the YouthMappers UEW (Ghana) - Link 1 e Link 2

Fonte: YouthMappers UEW.

Momento 2 - Apresentação das traduções da cartilha ODbL/FPOSM realizadas pela Editora IVIDES

As traduções da cartilha sobre a licença ODbL, publicada originalmente pela Fédération des Pros d’OpenStreetMap (FPOSM) - Tout savoir sur la license ODbL : la licence d’OpenStreetMap pour cartographier en commun, foram mencionadas no evento global State of the Map 2026, realizado em Paris.

Sessão do SotM 2026 onde as traduções foram mencionadas pela FPOSM.

Você pode acessar as publicações em três idiomas no website do Zenodo.org - português, inglês e Kiswahili:

Tudo o que você precisa saber sobre a licença ODbL - PDF Link - PT;

Everything you need to know about ODbL license - PDF Link - EN;

Kila Kitu Unachohitaji Kujua Kuhusu Leseni ya ODbL - PDF Link - SW.

As três capas dos volumes traduzidos para português, inglês e Kiswahili.

No portal da Editora IVIDES, pode encontrar os demais livros já publicados em português e inglês.

Translated from Portuguese to English with DeepL.com (free version)

Nota importante: IVIDES.org® e IVIDES DATA® são marcas registradas. OpenStreetMap® é uma marca registrada.

Important disclaimer: IVIDES.org® and IVIDES DATA® are registered trademarks. OpenStreetMap® is a registered trademark.

*Para entrar em contato, por gentileza, envie mensagem para ivides [at] ivides.org ou utilize nosso [formulário de contato]

*To contact us, please send a message to ivides [at] ivides.org or use our [contact form]

On 29-30 August, I attended the State of the Map (SotM) conference, in particular the scientific part. It's been 15 years since the last time that I attended the SotM conference (last time 2011!), and it's an opportunity to fill in a knowledge gap that I developed over this period. Unlike other conference reports that … Continue reading State of the Map 2026 – OpenStreetMap conference →

Agregar Beit Ya’akov Salama

The first time I became aware of the very existence of the “State of the Map” event was, I think, around 2022.

At that time, it was held in Italy. I think I heard about it somewhere online. All I remember is the group photo of the participants (there were plenty of people there) and the beautiful, cool-looking SotM 2022 logo.

That year, I had just recently graduated, so I could get involved in the OpenStreetMap movement more intensely than I had in the years before (before that, I usually only actively mapped during college holiday seasons. Once the holiday was over, I didn’t map anymore). That’s why at that time I started interacting with the community more, and eventually learned about this “State of the Map” event.

Even though I still don’t remember exactly where I first received the news about the event.

At that time, my first reaction was, “I don’t think I’m able to commute farther than either Jakarta or Bandung.” So, back then, I thought, “I don’t think I’m able to visit Italy.”

Fast-forward to after 2022. I gave several technical and/or philosophical talks about OSM sporadically, mostly online. From a technical standpoint, I talked about things like “how to map,” “how to use this particular tool,” or “introducing a tool that I recently built.” From a philosophical standpoint, I talked about ideas and dreams about “how the OSM platform should evolve in the future,” “how we should organize the people in the OSM movement,” etc., etc.

I finally had a chance to attend an OSM-related meeting physically, rather than online, for the first time around 2025. In this case, it was still within the boundaries that I had defined back in 2022 (Jakarta), so I was able to go.

In the same year, 2025, the global SotM was held in Manila. Relative to the rest of the cities on Earth, Manila is quite close to where I live, but still, “I don’t think I’m able to commute farther than either Jakarta or Bandung.” So I passed on it again. But at least I sent my poster there, which became my first-ever contribution to SotM.

Also, in the same year, 2025, I became pretty involved in the day-to-day editing of WeeklyOSM. There, I saw plenty of news submissions about SotM events all over the world, not just the yearly global SotM, but also region-specific SotM events. There were so many of them, but I don’t think I ever saw one being held in Jakarta and/or Bandung. So there went my chance to participate.

Then, on 30 July 2026 at 8:24 pm, I received an email from HOT. I only read it later, around 31 July 2026 at 1:50 pm. They were offering 100 free online tickets (GBP 10.00, including 20% UK VAT). Without any hesitation, I quickly filled out the registration form.

I assumed that these 100 tickets would be given on a “first come, first served” basis. And considering how late I was checking my inbox (for the sake of my own mind, I had decided to turn off notifications, but I still regularly checked my email at a specific time every day), I was quite afraid that I was already way too late to the party.

The registration form was sent. And all I could do was wait. If I failed to get the ticket, then it was what it was.

Then, on 20 August 2026 at 6:12 am, I received an email from the SotM Working Group:

“Hello, a ticket for State of the Map 2026 has been ordered for you. You can view the details and status of your ticket here. Best regards, Your State of the Map 2026 team.”

Alright. Cool. This was going to be my first SotM ever in my whole life.

On that same day, I immediately read through the programme page thoroughly.

There were plenty of parallel sessions, so I needed to plan ahead and decide which room I should go to at a certain time. I picked the topics based on my personal interests, while prioritizing attending all the “lightning talks” (I didn’t know the exact topics of those talks, but well, surprise me. I hoped I would feel lucky enough to stumble upon some interesting talks there).

Sometimes there were two topics that I liked equally, but they were running in parallel at the same time. I still marked both of them, just in case. Maybe I’ll go to the other room once this session is over. Maybe I’ll switch back and forth between them. I don’t know. Let’s see how it goes.

And on the same day (20 August 2026), I published that plan in this OSM Diary.

While researching the programme, I also learned that there was a Telegram group for all SotM 2026 participants. I joined it.

Inside that group, apparently someone had also made “country-specific groups” for SotM 2026 participants. That gave me the idea to make a specific group for people who attended this event through HOT’s free-ticket programme. Maybe we could talk in depth about the talks being presented, or network with each other.

From 20 August to 28 August, it was about one week. So during that time, I basically did nothing except wait in excitement.

So let’s just skip the story ahead to 28 August, the first day.

Alright. Timezone issues.

In Paris, the event started in the morning at 9:30 am, followed by the morning coffee break (10:40–11:15), lunch break (13:00–14:30), afternoon coffee break (16:15–16:45), and finally the end of the day’s programme at around 17:55++.

If this schedule is overlaid onto my own personal schedule and timezone, the event starts at 14:30 and ends around midnight. The mandatory breaks that I need to take are around 15:00–15:30 and 18:00–19:30. And the plan that I drafted beforehand didn’t actually take this into consideration. So I just had to improvise along the way.

Not to mention that there might be other “unexpected circumstances IRL” where I might not be able to access my laptop and attend a talk.

On that day (28 August), I opened my laptop at around 14:00, 30 minutes before the actual event started.

There was quite a lot of activity in the SotM Telegram group, so to kill time during those 30 minutes, I read through the chat one message at a time.

I learned that people were using trains to reach Paris from Toulouse, Marseille, Düsseldorf, etc. Meanwhile, among the people who had already reached Paris, they were discussing the arrival train station (Paris Austerlitz), the hotels they were staying at (mostly in noisy, near the SotM venue), and the location of the pre-event social event (Ground Control, also near Austerlitz).

I identified all the place names that were mentioned in the Telegram group, then put the coordinates of each place into LocationPad as a quick personal pet project, just to kill time while waiting for the event.

From the Telegram group, I learned that Paris had been raining the night before the event, and that “there has been some disruption to the RER C due to trees falling.” I also learned that registration started at 8:15 Paris time.

I jumped onto the Venueless platform at 14:30 (my local time). The chat room on the Venueless platform is quite crowded with people introducing themselves. I noticed at least 21 people introducing themselves, from Scotland, London, Brazil, Bangladesh, Nepal, Madagascar, Nigeria, and Zambia. The event finally started at around 14:43.

I encountered some severe connection issues at this point, so I failed to watch it uninterrupted. I only managed to get glimpses of it at particular times before the video got stuck again. I guess my own unstable internet connection was to blame here.

Here are the glimpses that I managed to watch:

14:48: Notice about the Code of Conduct (https://2026.stateofthemap.org/codeofconduct/) and information about the venue (https://2026.sotm.org/venue).

14:48: “Group photo. Join us on Saturday at 14h20 at the main hall stairs for the traditional SotM group photo!”

14:49: Information about coffee breaks and lunches.

14:49: I took this screenshot.

14:50: “Social event, Saturday 29 @ 19:30.”

14:51: “Thank you to our sponsors!”

14:53: Opening speech from TomTom.

14:56: Opening speech from the Director of Mapping Factory at Michelin.

15:02: Opening speech from the Head of Geodata Paris.

At 3:00 pm, I had to take my own personal break, so unfortunately I had to sign off.

And apparently, I also had another urgent personal matter, so I had to travel outside for a bit at that time.

As a result, I was only able to rejoin the event at around 3:56 pm.

(To be continued in Part 2…)

why does OSM have diray entries? i guess i’ll try to find out

20/08/2026-26/08/2026

Mapping

• In early August, v7.1.0 of the iD tagging schema was released, bringing new features to iD, GoMap!!, EveryDoor, and other editors. It includes multiple new presets (for example, for rooftop solar thermal collectors and building=tent), marks some fields as openinghours-like, new values in fields such as cuisine, some region-specific tweaks, many better icons, fixes destination fields, and stops asking translators to translate the same phrase twice in many places, also better documentation, better repository structure, and many other improvements.

Community

• A poll by Mateusz Konieczny asks which improvements to iD presets are especially wanted.
• Sven Geggus discussed how to integrate data from Nomady, an Airbnb-like booking portal for small private campsites, into OpenStreetMap and OpenCampingMap.
• Rphyrin prepared for the State of the Map 2026, which took place in Paris and online from 28 to 30 August 2026.

OpenStreetMap Foundation

• The OpenStreetMap Foundation announced that Proton AG has been recognised as a Platinum Corporate Member, following two donations over the past two years, totalling around €70,000.

Local chapter news

• FOSSGIS tooted that the FOSSGIS Conference is seeking a host venue for 2028. Interested parties can submit applications to host FOSSGIS 2028 by email until 16 October 2026. They also welcome expressions of interest in hosting future events, such as FOSSGIS 2029 or FOSSGIS 2030.
• OpenStreetMap US announced that the OldInsuranceMaps project has joined YouthMappers, Yesterdays, and OpenHistoricalMap as an OSM US Charter Project.

Events

• ^[1] You can visit the page featuring the amazing posters which are being presented at State of the Map 2026.

OSM research

• Radim Štampach et al. have assessed the performance of the fAIr mapping environment (we reported earlier) compared with manual mapping in JOSM. They concluded that fAIr reduced the performance gap between novice and experienced contributors but introduced AI-related errors, while manual mapping in JOSM was faster and more accurate overall.

Maps

• Mobi Mapr built ► a visual dashboard to analyse the accessibility of ice cream parlours in Germany, using OpenStreetMap data.

OSM in action

• OK Lab Flensburg have developed ‘Open City Planner’, an interactive city planning GIS application for Flensburg’s city centre, powered by OpenStreetMap data.

Software

• The Prototype Fund is offering a new funding line aimed at young individual developers or small teams residing in Europe, focusing on open-source software infrastructure or data security.
• Stadia Maps explained their initiative around reworking their cartography from the ground up. There are some details about their recent overhaul of water name labeling.

Programming

• Yassa9 explained how to geolocate a photograph using OpenStreetMap data, geometry analysis, and CUDA GPU programming.

Did you know that …

• … the Valhalla router can route through pedestrian areas? OSRM has it too; after a pull request, which started in May 2025, was recently merged.
• …. r/Fahrrad invited the German cycling community on Reddit to improve the data quality of Komoot, Strava, and Bikerouter by contributing to OpenStreetMap through the StreetComplete app?
• … there’s a discussion on the OSM Wiki about mapping the Moon using the same principles as OpenStreetMap?

OSM in the media

• Ivan Nechaev, of Georgia Today, reported that the Georgian OpenStreetMap community worked online with 2025 aerial imagery from the National Agency of Public Registry, tracing buildings, checking roads, and adding addresses in Ambrolauri (western Georgia) and the surrounding area.

Other “geo” things

• The Iconoclasistas celebrated 20 years of participatory mapping ►.
• Radio France Internationale reported ► on the digitalisation of documents (including maps, documents, and photos) related to the historic mineral exploration in the Democratic Republic of Congo, which are archived in the AfricaMuseum. According to François Kervyn, a geologist and head of the museum’s Earth Sciences department, the documents were previously available only by special order for researchers, but digitisation is expected to make them more accessible.
• Shachar Maidenbaum has published a study analysing how Israel’s military GNSS spoofing tactics affect local people, eliciting reactions ranging from navigation apps being disrupted, to grocery deliveries being directed out of the country, and users of dating apps matching with people across borders.
• Jennifer Ouellette, of Ars Technica, reported that Japanese researchers have developed the muometric positioning system, an alternative to GNSS that uses cosmic-ray muons instead of radio signals. Muons are highly penetrating, charged particles constantly reaching Earth’s surface from different directions. By placing synchronised muon detectors at multiple locations and comparing the timing and directions of the same muons passing through them, the system can determine their relative positions. This could enable positioning underground, indoors, and underwater, where radio signals cannot penetrate effectively.
• NDR reported that Laura Hantschel, Lukas Hort, Annika Neumann, and Clara Mülle of ‘Pipapo Games‘ have developed MapMap, a cartography-themed puzzle game, during their studies. The gaming community has responded enthusiastically to its release, noting a sudden emerging trend of cartography-themed games. They mentioned another recent example, ‘Beware of the Cartographer‘, which focuses on mapping a mysterious land during the Age of Enlightenment, drawing borders between two warring kingdoms, meeting the locals, and balancing their demands with the requirements of the mission (we reported earlier).
• Duan Yuanqiang and others have updated their S2Coast-2023 dataset (version 3), the first global 10 m resolution coastline dataset derived from enhanced Sentinel-2 composite imagery, under a CC-BY 4.0 International licence. There are polyline and polygon features, modelled tide data for some places, and coastal examples. The OSM coastline dataset was used for validation. The article was published in Remote Sensing of Environment.
• Jules Rumeau has developed Scopus, an HD LiDAR viewer using IGN data that runs entirely in the browser. For a given area, the tool calculates the terrain hidden beneath vegetation and displays it side-by-side with aerial photography. Sunken lanes, low stone walls, ruined huts, and other features obscured by trees in standard imagery become visible within seconds.

Upcoming Events

Country	Where	Venue	What	When
		Cité Descartes	State of the Map 2026	2026-08-28 – 2026-08-30
	Essen	Verkehrs- und Umweltzentrum	Essen OSM-Treffen	2026-08-28
	Bengaluru	Nagarabhavi	OSM Bengaluru Mapping Party	2026-08-29
	Jalpaiguri	Kadamtala Madrasa Math, DBC Road, Jalpaiguri	14th OpenStreetMap West Bengal Mapping Party + AnkushTheHero Day	2026-08-30
		Gurukripa, Sion	OSM Mumbai Mapping Party No.14 (Sion)	2026-08-30
	Uppsala	Datorföreningen Update	Mapping meetup in Uppsala	2026-08-30
	Hannover	Kuriosum	OSM-Stammtisch Hannover	2026-08-31
	Saint-Étienne	Zoomacom	Rencontre Saint-Étienne et sud Loire	2026-08-31
	Heidelberg	DEZERNAT#16	Rhein-Neckar OSM Treffen	2026-08-31
	Salzburg	Bewohnerservice Elisabeth-Vorstadt	OSM-Treffpunkt	2026-09-01
	Münster	BRASSERIE Münster	OSM-Stammtisch Münster	2026-09-01
	San Jose	Online	South Bay Map Night	2026-09-01
			Missing Maps London Mapathon Beginner Friendly (with Training) (Online) [eng]	2026-09-01
	Brno		Kvartální OSM pivo – SOTM/2 CZ [Brno]	2026-09-02
	Praha	Přírodovědná fakulta Univerzity Karlovy	SOTM/2 CZ	2026-09-02
			OSM Indoor Meetup	2026-09-02
	Stuttgart	Biergarten Tschechen & Söhne	Stuttgarter OpenStreetMap-Treffen	2026-09-02
	Bordeaux	Aquilenet, 20 Rue Tourat, 33000 Bordeaux	Rentrée bordelaise du groupe local OpenStreetMap	2026-09-03
	Angers	L’Arrière Train, 3 rue de Frémur, Angers	Angers Rencontre mensuelle OpenStreetMap	2026-09-03
		Bar Le Schmilblik	Rencontre mensuelle des contributeurs Paris sud	2026-09-03
	नई दिल्ली	Jitsi Meet (online)	OSM India – Monthly Online Mapathon	2026-09-05
	Osaka	中崎町ホール Nakazakicho HALL, Salon de AmanTo天人 (Osaka)	State of the Map Asia 2026	2026-09-06 – 2026-09-07
	臺北市	MozSpace Taipei	OpenStreetMap x Wikidata Taipei #92	2026-09-07
	Braunschweig	Stratum 0	Braunschweiger Mappertreffen im Stratum 0 Hackerspace	2026-09-08
	Madrid	Online	Mappy Hour OSM España	2026-09-08
	Hamburg	Voraussichtlich: “Variable”, Karolinenstraße 23	Hamburger Mappertreffen	2026-09-08
		temporärhaus	OSM-Stammtisch Ulm/Neu-Ulm	2026-09-08
	München	WikiMUC	Münchner OSM-Treffen	2026-09-10
	Bochum	Das Labor, Alleestraße 50, Bochum	OSM-Treffen Bochum	2026-09-10
	København	Cafe Bevar’s	OSMmapperCPH	2026-09-13
	New Delhi	Outside Delhi	OSM Delhi Mapping Party No.32 (Outside Delhi)	2026-09-13
	Greater London	1 Cabot Square, 7th Floor, Canary Wharf E14 4QJ	EAW Volunteering Event	2026-09-14
			CartONG : Mapathons en ligne 2026-2027	2026-09-14

Note:
If you like to see your event here, please put it into the OSM calendar. Only data which is there, will appear in weeklyOSM.

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

My first diary entry. Testing 123

(english below)

JugoTour 26

Am 1.Juli 2026 bin ich zum 20. Mal zu einer kontinentalen Fernradreise aufgebrochen. Dieses Jahr ging es endlich daran, den weißen Fleck auf meiner persönlichen Karte zu füllen: Ich hatte mich noch nie tief in den Balkan getraut. Auch wenn meine Reise 2001 von Israel nach Ägypten und zurück politisch aufregend und fern der EU war, so ist das doch schon fünfundzwanzig Jahre her und die Grenzübertritte im ehemaligen Jugoslawien jedesmal begleitet von einem gewissen thrill: Wird jetzt alles ganz anders sein?
Das Nebeneinander von Islam und Christentum war spannend zu sehen; sehr eindrücklich war auch, die Christen als historische Aggressoren und die muslimischen Gebiete als deutlich entspanntere Gesellschaft zu erleben.

Fokus auf Städte

Ich bin meinem Habitus treu geblieben, eine Perlenschnur durch die Hauptstädte zu fahren und sich nicht aus Liebe zur Natur auf besondere Abwege zu begeben. Trotzdem bekam ich natürlich geologisch allerhand zu staunen. Für die Anreise nach Klagenfurt buchte ich ein Zugticket nach Villach, für die Heimreise bekam ich über Flixbus einen Fernreisebus von HAK gebucht, der mich für 120€ in einem Rutsch mit Fahrrad bis Köln brachte.

Dauer und Übernachtungen

Die Tour mit kleinem Zelt dauerte drei Wochen; übernachtet habe ich meist abseits der Siedlungen, manchmal aber auch in AirB’n’B (Sarajevo) oder privat indoor (z.B. in Skopje), wenn ich spontan abends dazu eingeladen wurde, was häufig vorkam.

Po deseti letech přispívání do OSM mě stále baví objevovat nová místa na mapě. Tak snad mi to ještě chvilku vydrží.

Bonjour, as our gracious hosts like to say.

The French community, together with the university, put together a fun experience. Keep in mind that this is my first (larger) OSM gathering of any type.

As an longtime inhabitant of the forum at c.osm.org I already read a few views on different types of members of our actually very diverse community. While there are quite some typical German Mappers on OSM (mapping away without ever interacting and kinda thinking of OSM as their personal project) there are so many different people out there working with and for OSM.

To all those “brickheads” out there: There’s so much more out there than just your personal interest!

In this first installment of my random musings I’ll just leave a link to a good talk I saw on day one that touches some frequent points of concern:

https://2026.stateofthemap.org/sessions/3GRKKJ/

To all you people in Paris: See you around :)