Обеспечение загородного участка автономным водоснабжением — первоочередная задача для любого землевладельца. Традиционно для решения этой проблемы применяется крупногабаритная буровая техника на базе грузовых автомобилей (ЗиЛ, УРАЛ, КамАЗ). Однако на практике буровые бригады часто сталкиваются с объективными препятствиями: плотная застройка, наличие ухоженных газонов, проложенные подземные коммуникации, узкие ворота или линии электропередач, исключающие возможность подъезда и разворота тяжелых машин.

В таких условиях оптимальным выходом становится использование малогабаритных буровых установок (МГБУ). Они позволяют проводить работы в стесненных условиях без ущерба для окружающего ландшафта. При этом гидрогеологические условия Александровского района Владимирской области отличаются крайней неоднородностью и сложностью разреза. Из-за этого применение малых технических средств возможно далеко не везде. Перед началом работ важно детально изучить специфику местных грунтов и водоносных слоев.

Важное примечание: Все приведенные ниже цифровые показатели глубин залегания водоносных горизонтов носят ориентировочный и обобщенный характер. Для получения точной информации и составления достоверного прогноза необходимо консультироваться со специалистами по каждому конкретному адресу.

Полезные ссылки про бурение на воду малыми установками:

• Большой обзор про бурение скважин малогабаритными установками на примере установки Гидробур Г1.

• Новые записи в нашем дневнике про бурение водозаборных скважин на проекте ОпенСтритМеп

Виды малогабаритной буровой техники

Современный рынок МГБУ предлагает несколько модификаций оборудования, каждая из которых имеет свои технические ограничения, габариты и область эффективного применения:

Разборные буровые установки

Представляют собой модульные металлические конструкции (переносные рамы), которые собираются непосредственно на точке бурения. Область применения: Бурение неглубоких скважин на песок (включая абиссинские колодцы) в самых труднодоступных местах, подвалах зданий или закрытых павильонах.

Ширина подъездных путей: Специальные пути не требуются. Элементы конструкции переносятся вручную через стандартные калитки шириной от 0,8 метра.

Габариты рабочей площадки: Минимальное пространство составляет около 2х2 метра при высоте потолка/навеса не менее 2,5–3 метров.

Буровые станки малогабаритные на колесном ходу

Компактные установки, смонтированные на базе прицепов для легковых автомобилей или самоходных колесных шасси.

Область применения: Сооружение скважин на мелкий и глубокий песок, а также на ближние известняковые горизонты в условиях обжитых дачных поселков.

Ширина подъездных путей: Для проезда требуется коридор шириной не менее 1,2–1,5 метров.

Габариты рабочей площадки: Для безопасного развертывания мачты и размещения сопутствующего оборудования необходима площадка размером от 3х4 метра.

Буровые малые станки на гусеничном ходу

Самоходные мини-установки на резиновом или металлическом гусеничном ходу, обладающие повышенной проходимостью и мощностью. Область применения: Бурение глубоких эксплуатационных скважин на межпластовые воды (включая известняк) на участках со сложным рельефом или мягким грунтом. Резиновые гусеницы минимизируют повреждение верхнего слоя почвы.

Ширина подъездных путей: Требуется проезд шириной от 1,5 до 1,8 метров. Габариты рабочей площадки: Оптимальная рабочая зона составляет около 4х5 метров с учетом места для бурового раствора и инструмента.

Что еще интересного почитать про подземные воды Владимирской области:

• Выход подземных вод на поверхность через Родник на улице Мира

Гидрогеологические особенности Каринского сельского поселения

Каринское сельское поселение характеризуется относительно благоприятными условиями для малогабаритного бурения. Геологический разрез здесь в основном представлен четвертичными отложениями, в которых широкое распространение имеют флювиогляциальные и аллювиальные пески московского и днепровского горизонтов.

На данной территории с высокой степенью вероятности можно оборудовать классические фильтровые скважины на песок под погружной насос. Местами встречаются обильные песчаные линзы с высоким уровнем залегания подземных вод, что позволяет обустраивать так называемые абиссинские иглы (забивные колодцы). В этих слоях формируются безнапорные грунтовые воды, доступные для легкого инструмента.

Тем не менее ключевым фактором успеха выступает геоморфология. Необходимо обязательно учитывать абсолютные высоты над уровнем моря. На возвышенностях и водораздельных плато глубина залегания обводненных песков существенно увеличивается, а верхние горизонты могут оказаться сухими или содержать лишь сезонную верховодку. В таких высоких точках вероятность успешного применения легких разборных МГБУ заметно снижается, и может потребоваться переход на более мощную гусеничную технику.

Гидрогеология Следневского сельского поселения

В Следневском сельском поселении гидрогеологическая обстановка усложняется. Хотя здесь также сохраняется принципиальная возможность бурения малогабаритными установками как под погружной насос, так и под абиссинские скважины, общая вероятность стабильного дебита на малых глубинах чуть ниже, чем в Каринском. Основные запасы чистой воды приурочены к межпластовым водоносным горизонтам, перекрытым сверху толщей моренных суглинков. При планировании работ важно учитывать следующие региональные особенности:

• Зависимость от рельефа. Как и в соседних зонах, отметки высот над уровнем моря диктуют глубину залегания стабильных водных пластов. На локальных возвышенностях маломощная техника может не дойти до обводненной породы.

• Каменистые включения. В ряде населенных пунктов поселения разрезы содержат плотные моренные отложения с обилием валунов, крупных камней и галечника. Прохождение таких интервалов легким инструментом МГБУ часто становится технически невозможным из-за заклинивания бурового снаряда. В подобных зонах эффективно отработать способна исключительно крупногабаритная техника с тяжелым ударно-канатным или мощным роторным инструментом.

• Географический градиент. При приближении к границам Ярославской области гидрогеологические условия закономерно ухудшаются: песчаные водоносы истощаются, замещаются глинистыми фракциями, а глубина залегания коренных водоносных пород растет. В связи с этим шансы на успешное применение малых установок при движении на север и северо-восток Следневского поселения стремительно падают.

Гидрогеологические условия Андреевского сельского поселения

Ситуация в Андреевском сельском поселении во многом дублирует условия Следневского, однако имеет свои специфические черты, требующие обстоятельного рассмотрения. Верхняя часть разреза сложена покровными суглинками и ледниковой мореной. Полноценный водоносный горизонт в четвертичных отложениях здесь носит мозаичный характер. Это означает, что обильные флювиогляциальные пески могут чередоваться с совершенно сухими зонами.

Верховодка в Андреевском поселении крайне нестабильна и сильно зависит от количества осадков, поэтому ориентироваться на нее при создании долговечного источника водоснабжения нельзя. Грунтовые воды часто характеризуются повышенным содержанием соединений железа и органики из-за близкого залегания юрских глинистых водоупоров.

Шансы пробурить надежную песчаную скважину с помощью МГБУ колеблются от средних до низких в зависимости от конкретной деревни. Использование разборных профильных рам оправдано только на пониженных рельефах и в поймах рек. На средних и высоких геодезических отметках бурение на песок часто превращается в разведочное, не приносящее результата. Для гарантированного получения воды приходится ориентироваться на более глубокие межпластовые воды, залегающие под юрскими глинами (в диапазонах, которые могут достигать 50–75 метров и более). Проходка таких глубин по плотным глинам требует от малогабаритной техники высокого крутящего момента и обязательного использования качественных буровых растворов.

Гидрогеологические особенности в Краснопламенском сельском поселении

Краснопламенское сельское поселение признано наиболее сложным сектором Александровского района с точки зрения автономного водоснабжения. Здесь фиксируются самые низкие шансы на успешную эксплуатацию стандартных малогабаритных буровых установок.

Главная причина кроется в специфике геологического строения:

• Глубокие пески. Водоносные песчаные горизонты здесь залегают на значительных глубинах, часто уходя за пределы технических возможностей легких станков.

• Сложные, непредсказуемые разрезы. Мощные толщи плотных моренных суглинков чередуются с валунно-галечниковыми интервалами и сухими мелкозернистыми песками, которые склонны к осыпанию и создают эффект «плывуна». Такие условия требуют постоянного крепления ствола скважины обсадными трубами в процессе проходки.

На территории Краснопламенского поселения использование МГБУ невозможно планировать вслепую или на основе усредненных районных карт. Возможность применения малой техники необходимо проверять индивидуально, с точностью до конкретного адреса в населенном пункте. Даже на соседних участках в пределах одной деревни гидрогеологический разрез может кардинально отличаться.

Полезные советы по бурению малой техникой в Александровском районе

Малогабаритные буровые установки — это эффективный и щадящий инструмент для решения задач водоснабжения, незаменимый в условиях плотной застройки Александровского района. Однако сложная гидрогеология региона, обусловленная ледниковым происхождением местных рельефов, накладывает строгие ограничения на их использование. В то время как в Каринском поселении шансы на успех легкой техники весьма велики, в Следневском и Андреевском они требуют учета каменистых включений и высотных отметок, а в Краснопламенском сводятся к минимуму.

Для получения точного прогноза и исключения финансовых потерь на бесперспективную разведку настоятельно рекомендуется перед началом работ проконсультироваться у нескольких независимых буровых бригад. При обращении обязательно указывайте точные географические координаты или адрес участка. Опытные мастера, регулярно работающие в Александровском районе, смогут трезво оценить реальные технологические лимиты своего оборудования, сопоставить их с архивными данными по соседним скважинам и дать четкий, обоснованный прогноз.

Soy nuevo espero pueda mejorar para seguir utilizando de manera adecuada esta app

OsmAnd 5.4 for Android is now available on the Google Play Store. Please update to the latest version to enjoy the new features and improvements.

At this release, we focused on improving the search experience, making it easier to find places and discover objects around a specific location. We also added the ability to attach media files to Favorites and Waypoints, making them more informative and useful for your travels.

🔄 Update Now!

Thanks to all our users for their feedback and suggestions. Your input is invaluable in helping us improve OsmAnd and make it the best navigation app for Android.

What's new​

• Refreshed search UI: sorting, category filters, cleaner look
• Attach photos and media to Favorites
• Favorites: subgroups support and pinnable folders
• New widgets appearance
• Roof shapes for 3D Buildings
• Coordinates: search, map grid, and POI display now support EPSG and Maidenhead locator
• Navigation settings improvements
• Android Auto updates
• Astronomy added solar & lunar eclipses
• AIS improvements
• New spatial search — find places and search around a place
• Others updates and improvements
• Bug fixes.

Refreshed search UI​

We introduced a refreshed Search interface designed to make finding places faster and easier.

You can now quickly choose where to search — around the Map Center or My Location — and select how results should be sorted: by Nearest or Relevance.

It is also easier to narrow down the results by selecting one or multiple POI categories, so you can focus only on the places you are interested in.

The updated interface makes Search more flexible, easier to understand, and faster to use.

History search and filtering​

The Search History menu now gives you more control over what is displayed.

You can filter history by item type and choose one or several categories:

• Tracks
• Locations
• Addresses
• POIs
• Favorites
• Photos
• Destinations

By default, all history items are shown.

You can also sort history by:

• Recent
• Nearest
• Nearest to Map Center

An additional Type filter lets you display:

• All
• Search
• Navigation

The History settings menu also includes an option to back up your history, helping you preserve your previous searches and navigation activity, make back up as file or clear all history.

Attach photos and media to Favorites​

We've made Favorites and Waypoints more informative by allowing you to attach media files directly to them.

Similar to the Audio/Video Notes feature, you can now add photos, videos, and audio notes to a saved Favorite or GPX Waypoint. You can take a new photo, record a video or audio note, or choose existing media from your device.

Attached files are displayed in a new Media section directly in the Favorite or Waypoint context menu, so photos and recordings connected to a place are easy to access when you need them.

This makes Favorites and Waypoints useful not only for saving a location, but also for keeping additional visual or audio information connected to that place.

Subgroups support and pinnable folders for Favorites​

Managing large collections of Favorites is now much easier.

Favorites can now be organized using folders and subfolders, similar to the folder structure already available for Tracks. This allows you to create a clear hierarchy instead of keeping all Favorite groups at the same level.

For example, you can organize places like this:

Netherlands / Amsterdam / Museums

or create even deeper folder structures when needed.

In My Places → Favorites, folders are displayed separately from individual Favorite points. You can create new folders, rename them, and move Favorites between folders and subfolders.

The full folder path is also shown where it is useful, including the Favorite context menu, making it easier to understand where a saved place belongs. For long folder structures, OsmAnd automatically shortens the path while keeping the most important folder names visible.

You can also pin important folders for quicker access to the Favorite groups you use most often.

The new hierarchy is supported when moving and exporting Favorites and works with OsmAnd Cloud synchronization, while preserving the existing file-based Favorites structure.

New widgets appearance​

We introduce new appearance settings for map widgets, giving you more control over how information is displayed on the map.

Instead of configuring widgets only individually, you can now customize the appearance of each widget panel — Left, Right, Top, and Bottom — from a dedicated Appearance screen.

For each panel, you can adjust:

• Widget or row size — Original, Small, Medium, or Large
• Widget icons — keep individual settings, show all, or hide all
• Text and secondary text colors
• Background color — Default, Transparent, or Custom

A live preview shows how the selected settings will look directly while you configure them.

For custom colors, Day and Night modes can be configured separately, helping keep widgets readable with different map styles and lighting conditions.

You can also copy appearance settings from another widget panel or another profile, making it easier to keep a consistent layout across different OsmAnd profiles.

Updated 3D Buildings​

OsmAnd 5.4 brings another major update to 3D Buildings, making cityscapes more detailed and closer to the real-world geometry stored in OpenStreetMap.

Buildings can now display different roof shapes instead of being rendered only as simple flat-topped volumes. When the corresponding roof information is available in OpenStreetMap, OsmAnd uses it to create a more recognizable building silhouette.

Rendering of complex buildings and building parts has also been improved. OsmAnd now handles structures divided into multiple building:part elements more accurately, including cases where only building:levels information is available instead of an explicit height.

We also improved the rendering of buildings created from relations and multipolygons, fixing cases where individual sections or lower parts of complex structures could be missing from the 3D model.

These changes make landmarks and detailed urban areas significantly more realistic when exploring the map in 3D.

To enable the feature, go to:

Menu → Configure map → Topography → 3D buildings

Coordinates EPSG systems​

We expand support for coordinate systems, making the app more useful for professional mapping, field work, surveying, amateur radio, and other activities that rely on specific coordinate formats.

You can now use EPSG coordinate systems and the Maidenhead Locator System across different parts of OsmAnd, including:

• Coordinate Search
• Map Grid
• POI and map context information

In Coordinate Search, you can select recently used formats or browse the full list of available coordinate systems. You can also quickly find the required system by searching for its name or EPSG code.

The Maidenhead Locator System is also supported on Android. It represents locations using a compact combination of letters and numbers and is commonly used by amateur radio operators.

Coordinate formats can be configured separately for each OsmAnd profile. You can choose a Primary coordinate format, add other formats to the list, reorder them, or remove formats you do not need.

Navigation settings improvements​

OsmAnd 5.4 improves navigation in situations where a route crosses regions with outdated or inconsistent offline maps.

Previously, route calculation could be interrupted by several dialogs asking you to update maps or manually continue using the downloaded maps. In some cases, this could even happen during route recalculation while navigation was already active.

Now, OsmAnd can handle these situations more smoothly. If the selected routing method cannot calculate the route correctly, the app can switch to an alternative calculation method and continue navigation without unnecessary interruptions.

You can also control this behaviour manually in:

Navigation settings → Route parameters → Route calculation method

Here, you can choose the preferred routing calculation method depending on your needs.

This makes route calculation more reliable when travelling across map borders or when not all downloaded maps were updated at the same time.

Android Auto updates​

OsmAnd 5.4 brings several improvements to Android Auto, making the search, and navigation experience more convenient on the car display.

More Useful Search Results​

Search results in Android Auto now show more information at a glance.

For POIs, OsmAnd can display opening hours in a compact format, together with distance and address information. This makes it easier to see whether a restaurant, shop, fuel station, or another place is currently open before selecting it as your destination.

Address presentation has also been simplified for nearby POIs, reducing unnecessary information on the limited Android Auto screen.

Improved Navigation Controls​

Navigation controls have also been refined. The X button next to the ETA now correctly stops the active navigation, making it easier to finish a trip directly from the Android Auto interface.

We also fixed interface issues on the arrival screen, including the duplicated Search button that could appear after reaching a destination.

Together, these changes make Android Auto cleaner and easier to use while keeping important map, search, and navigation information accessible on the road.

Astronomy added solar & lunar eclipses​

The Astronomy plugin continues to grow in OsmAnd 5.4 with new tools for exploring solar and lunar eclipses directly on the Star Map.

Solar Eclipses​

You can now explore solar eclipses around the world and see how an eclipse develops over time.

The new Solar Eclipse Explorer shows the eclipse shadow on the map and provides a timeline that you can move through to see how the event changes. Information is calculated for the selected location, making it possible to check whether and how the eclipse will be visible there.

You can also quickly switch between previous and next solar eclipses and explore their paths in different parts of the world.

Lunar Eclipses​

The Star Map now also includes a dedicated Lunar Eclipse Explorer, supporting:

• Penumbral eclipses
• Partial eclipses
• Total eclipses

The eclipse timeline shows the different stages of the event, while the visualization demonstrates how the Moon moves through the Earth's penumbra and umbra.

You can check the current eclipse phase, obscuration, Moon altitude, and where the eclipse is visible. A dedicated visibility layer on the map helps show the regions where the Moon is above the horizon during the event.

Together, these additions turn the Astronomy plugin into a useful tool not only for exploring stars and planets, but also for planning and observing upcoming eclipses.

AIS improvements​

OsmAnd 5.4 brings several improvements to the Vessel Tracker (AIS) plugin, making it easier to configure AIS connections and monitor nearby vessels.

The plugin settings have been reorganized into clearer sections for Connection, Object visibility, and Collision avoidance alarms (CPA).

You can configure AIS data reception using TCP or UDP, with connection information and status displayed directly in the interface.

New Object visibility settings give you more control over outdated AIS targets. You can define when a vessel should be marked as outdated and how long it should remain visible on the map after its signal is lost.

The Collision Avoidance Alarm (CPA) settings have also been redesigned. You can configure:

• Warning time (TCPA) — how far in advance OsmAnd should warn about a potential collision.
• Closest Point of Approach (CPA) — the minimum safe distance between your vessel and another AIS target.

When another vessel is predicted to come too close within the configured time, OsmAnd can highlight it as a potential collision risk.

AIS visibility can also be managed as a dedicated map layer through Configure Map, making it easier to enable or disable vessel information when needed.

New spatial search​

Experimental feature: In OsmAnd 5.4, the new spatial search algorithm is available only when the OsmAnd Development plugin is enabled. This allows us to collect feedback and continue improving the feature before enabling it by default in a future release.

Search in OsmAnd 5.4 has received a major upgrade. A new spatial search algorithm makes it easier to find places and discover objects around a specific location.

Previously, search was largely tied to your current location and the way individual words in a query were interpreted. The new approach takes geographical context into account, making combinations such as a place name + POI, category, street, or address much easier to understand.

For example, you can find a city or another place first and then search for cafés, restaurants, hotels, shops, fuel stations, or other POIs around that location. This is especially useful when planning a trip somewhere else instead of searching only near your current position.

The new search engine also improves how OsmAnd handles more complex queries, including combinations such as "Hotel Berlin", a POI together with a street or city, different street-name formats, translated category names, and other location-based searches.

Under the hood, this is more than an interface update. Our backend team introduced a new search architecture called Spatial Search by Name, designed to provide more relevant results and resolve many limitations of the previous search system. Search by supported POI categories has also been optimized for faster results.

Others updates and improvements​

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

• More icons for profiles. The profile icon selection has been expanded, giving you more options to visually distinguish profiles for activities such as running and other use cases.

• Extended AIDL support for external apps. External apps and plugins can now organize their OsmAnd widgets into groups and use custom widget icons, providing more flexibility for third-party integrations.

• Correct altitude on Android 16. Fixed an issue where OsmAnd could display ellipsoidal altitude instead of altitude above mean sea level (MSL) on Android 16 devices.

Bug fixes​

• Fixed multiple URLs separated by semicolons being displayed and opened as a single link.
• Fixed the Open on map action in Travel Guides.
• Fixed copying widget panels and layouts from another profile.
• Improved performance when opening GPX waypoint descriptions by resolving intermittent UI freezes.
• Fixed widgets disappearing from Analyze on map after returning to OsmAnd from another app.
• Fixed imported multi-segment tracks not appearing immediately after import.
• Corrected incorrectly calculated storage size for Favorites and Favorite folders.
• Fixed synchronization between elevation, road type, surface, and other graphs in route details.
• Improved external sensor widgets by showing the correct disconnected state and resetting values after stopping.
• Fixed a visual gap between the current location marker and the route line during navigation.
• Fixed Favorite folder colors being reset after an app update.
• Fixed deleted Favorites unexpectedly reappearing on the map.
• Fixed outdated 3D Terrain maps not appearing in the Updates list.
• Improved sorting of Favorites by proximity to the selected map area.
• Fixed the location marker being hidden or positioned outside the visible map area in Android split-screen mode.
• Fixed navigation incorrectly ending after switching to another app and returning to OsmAnd.
• Improved navigation stability by fixing a resource leak that could cause crashes during longer trips.
• Improved pinned Favorites folder behavior so folder state is preserved correctly after restarting the app.
• Improved handling of very large tracks to reduce out-of-memory crashes when working with tracks containing hundreds of thousands of points.
• Fixed incorrect 3D track rendering when using Speed as the visualization parameter.

If you have suggestions for improving the Android 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:  

  

  

When assigning Dakota and Lakota names to map elements, I am mainly drawing on the (often lifelong) work of others; very few of my changes are based on personal local knowledge. I have focused on sources who are either directly part of, or at least worked closely with, authentic Oc̣eti Ṡakowiƞ communities. This is the language of nations that are alive today, and they have things to say! My major sources include:

• My mapping work owes an enormous amount to (and sits in the shadow of) the absolutely incredible Maḳoc̣e Waṡte map by Lakota historian Dakota Wind Goodhouse, who drew on a vast range of sources to populate the names of thousands of places. His blog The First Scout is one of the best public history projects you’ll find anywhere, and you should check it out. Sometimes my research has led me to different conclusions on the precise meaning and pronunciation of some place names, and the largest limitation of his map is the one he tells you about right away (it is a Landscape Map and so rarely discusses towns and cities) but this is still the single largest, most thorough map of Lakota/Dakota place names you will find anywhere until such time as I can somehow map four times as much content as I have.
• For places in or adjacent to southern Minnesota, Paul Durand’s 1994 book “Where the Waters Gather and the Rivers Meet” is a vital source. Durand spent decades researching the names in this book, meeting with elders and communities and keeping meticulous records. Physical copies of this book (which are very rare and expensive now) included a large-scale map of the elements it describes. My copy is an ebook that did not include this map, but the dedicated folks at Wakaƞ Tipi Awaƞyakapi have a full-scale version printed on their wall at their newly opened center in Imniżaska (St Paul) which they were gracious enough to let me view and photograph.
• For places in or near the borders of the 1868 Great Sioux Reservation, a “Map of Lakota Place Names” created by communities of elders in Lower Brule and Rosebud from 2002-2017 has been a valuable resource. A copy should still be findable online at RAMADDA.
• For locations in Manitoba, I owe nearly everything I’ve mapped to the work of Dúzahan Mániwiƞ (Doris Pratt), a brilliant Dakota language teacher from Wípazoka Wakpa who devoted her long life to the restoration of her people’s language. She assembled a vast list of place names in her text “Dakota Iapi Ehdakub”, which she published in the final years of her life and which you can get a copy of for free at the Manitoba First Nations Education Resource Center.
• The New Lakota Dictionary (produced by the Lakota Language Consortium) and its Dakota counterpart the Dakhod Iapi Wic̣oie Wówapi (produced by the Daḳota Iapi Oḳodakic̣iye) have been very helpful for the research task of identifying the meanings and full pronunciation of names from sources that often represent the written language in different ways. These also included a great many place names directly, though I try to defer to the primary sources above (and make use of alt_name) parameters) when they disagree. A mention should also be made of the venerable Riggs dictionary as a reference for any number of words.
• And I am especially grateful to many current and former teachers and fellow-students at the University of Minnesota Dakota Language Program for patiently teaching me enough Dakota to have some understanding of what these sources are saying and how the logic of the language works. If you are trying to build a real understanding of the language from the ground up, I cannot recommend them enough. It won’t be quick or easy, but if you stick to it you’ll come out speaking Dakota.

There are many other “minor” sources that are the origin of one or a few place names, and there are other “major” sources that I have an eye on but am yet to get access to. I’ll edit this Diary post to add the latter if and when that changes.

I contributed by editing yay

FAWKES FUCKS WITH FLOCK. Student in Chicago, Il, USA have developed a program that makes micro changes to your image that perverts the data FLOCK is collecting. Can’t trace what they can’t see again… worth the visit if you’re serious about privacy.

Gazirchat Munshipara Darul Ulume Madrasha & Eatimkhana গাজীরচট মুন্সীপাড়া দারুল উলুমে মাদ্রাস & ইতিমখানা

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