hey! wouldn’t be shocked if im only one of a handful of new canadian users trying to take a step away from google maps. i downloaded comaps earlier today (which uses openstreetmap) and noticed a handful of stuff in my little town is missing or out of date. so why not be the one to contribute?

im short on time this week (and there’s some awful rain right now) but i think sooner or later im going to take a stroll through town and update everything i can. it’ll be a lot more fun than just cross-referencing another map.

OsmAnd 5.4 for iOS — Now Available!

This update brings a redesigned My Places interface, a rebuilt Plan a Route tool, the new Astronomy plugin, and many other improvements and bug fixes.

🔄 Update Now

What's new​

• Redesigned "My Places" — with Favorites subfolders, pinned folders, and quicker actions
• Rebuilt "Plan a Route" — add route and POI points, and combine different route types
• New Astronomy plugin: star map with a detailed database for each object, visibility graphs, and an observation schedule
• Added "Terrain shadows" visualization type
• Edit the color palette for Tracks and Terrain
• Full icon selection now available for profiles
• CarPlay improvements and bug fixes
• Set a default appearance for Track folders
• Auto-organize tracks by year, length, activity, and more
• Split multi-track GPX file into separate files on import
• Others updates and improvements
• Bug fixes.

New "My Places" design​

The My Places screen has been redesigned with a new segmented interface, making it easier to switch between Favorites, Tracks, OSM Edits, and Travel Guides.

• Favorites now use a folder-based structure with support for subfolders. Folders are organized into Pinned, Visible, and Hidden sections, and frequently used folders can be pinned to the top. Each folder displays useful statistics, including the number of subfolders and points, modification date, and storage size. New sorting options allow folders and points to be arranged by name, date, or distance.

  Updated action menus provide quicker access to Show on map, Pin or unpin, Rename, Appearance, Share, Move, and Delete. Favorites and entire folders can also be added to Map markers, a Track, or Navigation. Selection mode makes it possible to apply actions to multiple folders and points at once.

• Tracks provides access to saved, recorded, and imported GPX files from the same redesigned My Places interface, with search, sorting, folder management, statistics, and quick actions for working with individual tracks or multiple selected items.

• OSM Edits keeps your OpenStreetMap edits, notes, and uploaded changes in a dedicated section. This tab is available when the OSM Editing plugin is enabled.

• Travel Guides contains bookmarked travel articles and guides, allowing saved travel content to be accessed directly from My Places. The tab appears when multiple guides have been bookmarked.

The new search interface also makes Favorites easier to find by displaying their folder, distance, address, and creation date directly in the results.

Updated "Plan a Route" interface​

The Plan a Route tool has been rebuilt with a new interface for creating, editing, and analyzing routes.

Separate Route + and + POI actions let you add route points or named waypoints and points of interest. Individual route segments can use different routing types, allowing you to combine, for example, cycling, walking, and straight-line sections within the same track.

The new panel includes three sections:

• POI — manage waypoints and points of interest added to the track.
• Analyze — view the elevation graph, uphill and downhill values, altitude range, speed statistics, and route composition by road type, steepness, surface, and smoothness.
• Route — view and manage route points and segments.

When elevation data is unavailable, it can be calculated using nearby roads or downloaded Terrain maps. The updated route summary also displays distance, estimated travel time, arrival time, elevation gain, and elevation loss.

Quick actions provide access to undo and redo, change segment order, reverse the route, append it to an existing track, save a copy, clear all points, or start navigation directly along the planned track.

Astronomy plugin​

The Astronomy plugin is now available on iOS. It provides an interactive Star Map with stars, constellations, the Sun, the Moon, planets, nebulae, star clusters, and other deep-sky objects.

Explore celestial objects using categories, catalogs, and the Watch now section. Detailed object information, visibility graphs, daily paths, direction indicators, Favorites, and a weekly observation schedule help you find objects and choose the best time for stargazing.

Enabled plugin (Menu → Plugins → Astronomy) → Menu → Star map

New "Terrain shadows" visualization​

The new Terrain Shadows visualization provides real-time dynamic shading based on 3D terrain geometry. Unlike raster Hillshade maps, the shadows are generated directly on the device and automatically adapt to the current map perspective.

This visualization makes mountains, valleys, ridges, and other terrain features easier to distinguish while maintaining a low impact on performance. 3D Relief is required and is enabled automatically when Terrain Shadows is selected.

Menu → Configure Map → Topography → Terrain → Visualization → Terrain Shadows

Color palette for Tracks and Terrain​

OsmAnd 5.4 for iOS introduces a built-in Color Palette Editor for customizing how track data and terrain layers are displayed.

For Tracks, you can create custom palettes for Speed, Altitude, and Slope coloring. Choose between:

Custom palettes are also available for Terrain visualizations. You can modify the color scale used for Slope and Altitude, assign colors to specific elevation levels or slope percentages, and add or remove value steps. Hillshade uses a fixed shading algorithm and does not support custom palettes.

More icons for profiles​

You can now choose from the complete collection of OsmAnd icons when creating or editing a profile. The redesigned icon selector uses grouped categories and includes the same icons available for Favorites, making profiles easier to identify and personalize.

CarPlay updates​

OsmAnd 5.4 includes several fixes and improvements for Apple CarPlay.

The 10-day free CarPlay trial has been restored after an issue that could prevent it from working correctly in recent releases. New users can once again test CarPlay navigation before purchasing Maps+ or OsmAnd Pro.

Navigation now displays warnings before starting a route when required maps are missing or when private-road access needs confirmation. The update also improves map and route centering, particularly on widescreen displays.

CarPlay appearance settings no longer override the map mode selected in OsmAnd. When Day or Night mode is selected manually, the map keeps that setting when the CarPlay interface switches between light and dark modes.

Default appearance for Track folders​

You can now set a default appearance for each Track folder. New tracks added to the folder can automatically use the selected coloring, line width, direction arrows, start and finish icons, and split interval.

The settings can also be applied to all existing tracks in the folder, replacing their individual appearance options.

Organise tracks for smart folders​

Smart Folders can now automatically organize tracks into groups using the new Organize by option. Instead of displaying every track in one list, you can group them by activity, creation date, location, distance, speed, altitude, elevation, or recorded sensor data.

Available organization types include:

• General — duration, time in motion, length, and activity.
• Date and time — year or month of creation.
• Location — country or nearest city.
• Speed — maximum or average speed.
• Altitude and elevation — maximum or average altitude, uphill, and downhill.
• Sensors — heart rate, bicycle cadence, bicycle power, temperature, and sensor speed.

For numerical values, you can adjust the grouping interval using Set step size. For example, tracks can be divided into distance ranges, altitude intervals, or speed groups. Empty groups are hidden automatically, and each group displays the number of included tracks.

Groups can be sorted alphabetically or, for numerical data, from highest to lowest or lowest to highest. You can also show all tracks from a group on the map or export them together.

Split Multi-Track GPX Files on Import​

When importing a GPX file containing multiple tracks, you can now review and select the individual tracks you want to import. Each selected track is saved separately, making it possible to manage its visibility, appearance, and other settings independently.

You can select a destination folder, import all available tracks as separate files, or use Import as one track to keep the original GPX content together.

Show Track Waypoints on the Map​

Track waypoint lists now include a dedicated Show on map button. Tap the pin icon next to a waypoint to center the map on its location without changing the current zoom level.

Tapping the main waypoint area still opens its full context menu.

Others updates and improvements​

OsmAnd 5.4 also includes a range of smaller features and interface improvements:

• Added a bicycle width setting. OsmAnd can now consider the width of your bicycle when calculating routes and avoid cycleways that are too narrow.

• More track details in What's Here. Track information now makes it easier to distinguish between tracks on the map, including identifying the folder where a track is stored.

• Added an OBD-II adapter voltage widget that displays the current voltage reported by a connected OBD-II adapter.

• Added support for Roads-only maps on iOS. These smaller maps contain the road network required for navigation and address search without the complete set of regular map details.

• Planned tracks now automatically receive an activity type based on the active profile or selected navigation type.

• Track lists now display the track folder name on the second line, making tracks easier to identify in Search, Smart Folders, and Configure Map.

• Added the Pause spoken audio option. Podcasts, audiobooks, and other spoken content can now be paused during navigation instructions instead of playing underneath them.

• Improved performance when adding or managing a large number of Favorites, reducing interface freezes and delays.

• Added the ability to share a route using a link making it easier to send a planned route to another user or open it on another device.

• POIs containing multiple website links now display all available URLs, allowing you to choose which one to open.

• Updated the Wikipedia action in the map context menu for easier access to related Wikipedia articles.

• Added the ability to open matching Travel Guides directly from Search.

• Added an option to hide the expand button in the Route Information widget for a cleaner navigation interface.

• Increased the size of road shields in the Street Name widget, improving the readability of route numbers during navigation.

• Updated turn and lane arrows to use consistent stroke thickness both on the device and in CarPlay.

Bug fixes​

• Fixed an app crash on startup when managing more than 1,000 Favorites;
• Fixed a UI freeze after adding a new Favorite to a folder containing many points;
• Fixed incorrect headers displayed above calculated public transport routes;
• Fixed the Compass button icon incorrectly following the iOS system theme instead of the selected map mode;
• Fixed an app freeze when CarPlay switches between Day and Night modes;
• Fixed a language mismatch between POI names displayed on the map and in the context menu;
• Fixed an issue where custom Track and Favorite colors were not included in exports or synchronized through OsmAnd Cloud;
• Improved map and location-marker movement during navigation to prevent periodic stuttering;
• Improved the OsmAnd Cloud synchronization checking speed;
• Fixed incorrect map centering after using the double-tap zoom gesture and then tapping My Location;
• Fixed the position of Online Photos and Street-Level Imagery in the region context menu;
• Fixed distance units being cropped in the Detailed Track Guidance settings for some languages.

If you have suggestions for improving the iOS version of the app, please get in touch with us. We appreciate and welcome your contribution to the further development of OsmAnd.

• Follow:

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

• Join:

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

• Get:

This weekend, I was at State of the Map 2026, the international OpenStreetMap conference, which took place in Paris this year. Here’s a brief, personal feedback and a round-up of a few presentations that stood out for me. You can also find all the videos at https://peertube.openstreetmap.fr.

NB: there is a French version here. This one was translated with the help of DeepL translate.

The most inspiring: cartes.app

Inspiring: cartes.app is a slightly mad project aimed at creating a new Google Maps, but without its car-centric bias. It started with a single contributor, but he’s managed to build a strong team around him: he has the insight to use the best open-source software components for his project – MapLibre for map navigation, vector tiles for map rendering, Photon for geocoding, and Transitious for public transport. Today, the developer is no longer working alone: he is securing funding and attracting contributors from around the world to improve his app and translate it so it can reach a global audience. It’s a wonderful project worth supporting, and you can do so by subscribing to cartes.app premium for just €1 a month.

The clearest: Use of OSM data by emergency services in Germany

A clear, practical and positive presentation by a contributor who is himself a member of a volunteer fire brigade. There is no longer any need to demonstrate the value of OSM to the emergency services: according to him, the use of OSM is widespread and extensive amongst German emergency services – as a base map, for specialised route planning, and for cartographic products in situation rooms, etc. A motivating call to contribute local knowledge to OSM: an unofficial address number displayed on a house number plate, the former name of a café still used by the local population, local place names, and of course all the information useful for lorry navigation: maximum width, bollards, etc.

The most surprising: How OSM inspire European standards for cycling infrastructure

This came as a surprise to me: I knew that OSM was the main source of data for numerous private cycling apps, and I’d already seen this study by the European Cyclists’ Federation, which used OSM to assess cycling infrastructure across Europe (here and there). But this presentation taught me more: some European standardisation body is actually going to use OSM as the basis for defining standards for cycling data infrastructure in Europe. To my knowledge, this is probably the greatest recognition of OSM data by a public authority to date. This does not mean that OSM data will simply be copied, identically, into the national inventories of each Member State, but rather that OSM models for cycling and existing data will serve as the basis for defining European (and potentially national) standards, as well as national databases. In my view, this is a superb outcome of the involvement of contributors who have patiently taken part in mapping cycling infrastructure at their local level. And ultimately, it is recognition of a fact: OpenStreetMap is probably the best database in terms of cycling data at a European level.

The most scenic: the French OSM Outdoor group

Let’s go hiking (or skiing or climbing), in the mountains and elsewhere, with this introduction to the OSM Plein Air group. This group brings together volunteers who are passionate about outdoor activities and mapping on OSM. It’s an opportunity to discuss certain tagging practices, the maintenance of data for 30,000 km of signposted routes, and managing links with the contributor community.

The most practical: a workshop on GNSS positioning with RTK

The SOTM programme isn’t just about talks; it also features hands-on workshops. One of these was a demonstration workshop on RTK positioning, which is a technique for improving GNSS (often referred to as GPS) positioning through the use of a GNSS antenna and a network of base stations. One such network is the Centipede network, which originated in France and is mainly used in the agricultural sector. During this demonstration, with a few antennas made available, we went outside and experimented with using these antennas to improve the positioning accuracy of a mobile phone, reducing the margin of error from a few metres to a few centimetres. This is something I’d like to try out soon with the QField app.

And the others

There were loads of interesting presentations: the one on Panoramax, those related to railways, my discovery of a map generalisation library – cartAGen (to be tested in OpenArdenneMap), the one on freemap.sk, … and all the others I missed.

Where is OpenStreetMap going?

This was already my fourth State of the Map (after Brussels, Milan and Heidelberg), not counting the State of the Map Europe event organised in Antwerp by the Belgian community. I’ve seen the OSM community and ecosystem develop significantly through all these conferences. In Milan in 2018, the community was witnessing the growing influence of Big Tech players (Facebook, Microsoft, Apple), who were investing heavily in the project through the development of software solutions, the payment of contributors (paid mapping) and attempts to infiltrate the OSM Foundation. This growing interest from these large companies was not well received by part of the community, nor by several long-standing members of the project. This year, what struck me was the absence of these companies: both in the conference sponsorship and in the presentations. I learnt that several humanitarian mapping activities previously funded by the United States have been halted, and that, overall, the proportion of paid contributions is falling. We are therefore witnessing a shift – one which, for my part, I did not expect – back towards the voluntary contributions that formed the heart of the OSM project in its early days, and a withdrawal of investment by major American companies. At the same time, however, the economic ecosystem surrounding OSM has probably never been so dynamic in Europe. This was demonstrated by the great vitality of the Fédération des Pros d’OpenStreetMap (France), and by numerous presentations on the reuse of OSM by public authorities, transport companies and businesses.

One participant pointed out to me that there were relatively few presentations on contributing to the project itself, and an increasing number focusing on use cases. This is because use cases are becoming increasingly common, successful and widespread. However, there is still much to be done to make even better use of OpenStreetMap data, and above all to continue taking care of our community.

todo bonito

Está actividad me permitió conocer más mi barrio y dar a una ubicación exacta la cual es muy factible porque así llegó a una ubicación exacta y me evita confundir la ubicación

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.

Before attending this talk, I don’t think I had ever heard of Sourdough at all. But once I learned about it for the first time, I became really interested in trying it out myself.

So interested, in fact, that I stopped writing this article halfway through and started developing this one instead. That’s why this article “stopped abruptly” for several days, and almost got abandoned entirely.

First of all, I really like Sourdough’s philosophy. I think I first tried OSM vector tiles a long time ago, back when they were still in relatively early development. At the time, I remember asking why some OSM data was “missing” from the tiles. It turned out that this was deliberate: some data is left out to keep the tiles small.

Then there’s Layercake. It is a distribution of OSM data published as GeoParquet at data.openstreetmap.us and updated once a week. It currently contains eight layers: addresses, boundaries, buildings, highways, parks, POIs, settlements, and waterways. Since the data is published as GeoParquet, we can query it using DuckDB.

This sounds interesting, but sadly, I don’t currently have a potential use case where I could actually make use of Layercake. I’m also not familiar with DuckDB yet. For similar use cases, I tend to use Overpass queries directly. And if I need speed, I usually turn to QLever, which I’ve heard is quite fast.

And for now, though, I don’t really know what the pros and cons are between GeoParquet, QLever, and Overpass.

The talk ended at around 22:41, then it transitioned into a Q&A session, which finally ended at 22:48.

At 22:49, I went to the Martinique room to join a lightning talk session. Since the session was already almost over, I only managed to catch a glimpse of the last speaker and some traces of the discussion in the chat room.

One of the things mentioned was OpenPriceData. Whoa, this is basically the same thing I’ve been trying to do for years.

So I immediately created an account on the platform. Then I realized that it still doesn’t support currencies other than dollars.

I also got stuck on the “price details” screen because of an error saying “other errors: invalid file type for”. I have no idea how to fix it.

Anyway, the lightning talk session ended at 22:52, so I went back to the Guadeloupe room.

At 22:57, the next talk started. This one was about MapLibre.

One of the most surprising things I learned while watching the talk that night was that Grab is powered by MapLibre.

Grab is my favorite ride-hailing app when I’m navigating around Indonesia. The biggest reason is that they use OpenStreetMap data. Whenever I travel with Grab, I can often see plenty of my own edits displayed on the driver’s screen. Knowing that my work is actually being used by so many Grab drivers and users makes me even more motivated to keep mapping.

Another interesting thing I learned is that one of MapLibre’s co-founders, Yuri Astrakhan, is Ukrainian (as mentioned on this final slide).

So both of my favorite mapping libraries, MapLibre and Leaflet, have Ukrainian roots? Cool.

The rest of the talk was quite technical, and I didn’t understand all that much of it, since I rarely dive very deeply into MapLibre myself. Most of the web maps I’ve made with MapLibre have been simple enough that I haven’t needed to use many of those advanced features.

During the Q&A session, the discussion with the audience was quite active, particularly around the topic of funding open-source projects. Someone mentioned this in the chat:

“Comment, not question: For the FLOSS Fund, if you are in a French company, have a look at copiepublique.fr to convince your upper manager.”

The talk ended at 23:34.

And that’s it. The first day.

There are still plenty of things to write about from the next two days.

I won’t try to write everything tonight, but I plan to continue this as a series, writing about each day whenever I have some free time at night (after work).

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