For some reason, the sidewalks near main roads in Sandy have been deleted without much warning. I just have to question what is with these changes and who is responsible for removing the work of mine and others.

Hello,

I recently noticed that Someone, Which I do not know of, Has vandalised clyst vale by Removing the entire school, and replacing it with a sainsburys, ive wrote this to alert a mod to hopefully revert the changes at clyst vale

-SouthWestTrains1

This article was originally written in French here. This English version was partly translated with DeepL.com.

OpenArdenneMap is an open-source map style designed for the production of topographic maps for printing. Based on OpenStreetMap data, it is available for use with QGIS and the Mapnik/cartoCSS libraries. Here is the winter 2025–26 release.

I started working on OpenArdenneMap about nine years ago. My aim was to create a map style for producing high-quality topographic maps intended for printing, using mainly OpenStreetMap data. The main challenge is to automate map production, to limit ‘manual’ corrections as much as possible (without eliminating them entirely). Since then, the style has been used in several mapping projects: together with colleagues, I have set up a website for downloading hiking maps (hiking.osm.be) and have been able to test the deployment of a tile server on https://www.nobohan.be/webmaps/oam-tile/.

One might think that, since it allows for the production of complete topographic maps, the development of a cartographic style in itself has reached its conclusion. This is not the case. I believe that the techniques and practices involved in developing topographic styles from OpenStreetMap data, in all their diversity and complexity, are still in their infancy. Recent years have seen the advent of numerous cartographic styles for on-screen maps, as well as the emergence of virtual tiles and 3d rendering. However, simple cartographic generalisation techniques and basic principles of cartographic semantics are rarely utilised in these new map styles.

This winter, I was able to draw on the work of a master’s student in geography, Noé Monjoie, to investigate these cartographic generalisation techniques in particular using OpenStreetMap data. The aim was to test algorithms for transforming geographical data to address certain representation issues in OpenArdenneMap (and in other digital cartographic styles). Only a very small part of his work has been incorporated into this new release. I hope the rest will follow in future updates. In the meantime, here are the new features of the “Winter 2025–26” version:

Avoiding label overlap between layers

Using the QGIS overlay_intersects() function, you can prevent labels from one layer from appearing on top of another. In this case, the aim is to prevent waterway labels from appearing within bodies of water. For reasons of hydrological continuity, OpenStreetMap contributors are encouraged to ensure that waterways feeding into bodies of water cross them from both sides. As the waterway segment is often interrupted at the boundary of the body of water, this causes a conflict between the labels of the water area and the waterway. A conflict that previously often resulted in the absence of labels for the water area.

Rendering of a culvert symbol

When a stream or drain passes under a road or path, this is a culvert, which differs from a bridge that provides a wider passage for the stream. This difference between a bridge and a culvert exists in OpenStreetMap data (tags bridge=yes vs tunnel=culvert). By using the orientation of the waterway segment passing through this culvert, as well as the entry and exit points of this passage, we arrive at this rendering indicating the culverts, a rendering directly inspired by Belgian IGN maps from the 1960s to the 1980s.

Bridge symbol rendering

Using the same principle, here is a rendering of small bridges (on paths) and boardwalks (differentiated by length) that takes into account the length of the bridge.

Grouping elements with QGIS clustering

Finally, an improvement based on Noé’s work, involving the clustering of certain point symbols (in this case, a picnic table) in QGIS. This was already handled well in Mapnik, but I hadn’t yet figured out how to do it in QGIS (in reality, it’s simply a symbology option for points).

Looking ahead, as mentioned earlier, Noé’s work has opened up several possibilities for data generalisation that I hope to be able to implement. Finally, QGIS 4 is due out this year, and so the new features brought by this major new version of QGIS will inevitably help OpenArdenneMap to evolve.

One of the most memorable phases of my OpenStreetMap journey was being part of the Autumn Mapping Sprint 2025, sponsored by Youth Innovation Lab. This was a funded mapping sprint that lasted for one full month, making it both exciting and challenging at the same time.

What made this experience even more intense was that, during the very same month, I was also involved in a one-month field campaign in Dolakha district as part of my studies. Managing both at the same time was not easy.

My days were filled with fieldwork—collecting data, traveling, and completing academic responsibilities. And yet, despite the physical exhaustion, I stayed committed to mapping. Every evening, I tried to make time—sometimes small, sometimes longer—to contribute to the sprint. It required discipline, time management, and a lot of determination.

There were moments when I felt overwhelmed, but I didn’t want to give up. Being part of a funded program and representing myself among advanced mappers motivated me to keep going. I reminded myself why I started this journey and how far I had already come.

Throughout the month, I continued mapping—adding buildings, improving roads, and refining data with care. Even with a busy schedule, I managed to stay consistent and complete my contributions.

Being recognized as one of the advanced mappers during this sprint made the experience even more meaningful. It wasn’t just about mapping anymore—it was about proving to myself that I could handle challenges and still stay committed to my goals.

Looking back, this month feels like a true test of my dedication. Balancing fieldwork and mapping taught me resilience, time management, and self-belief.

This experience showed me that no matter how busy life gets, with determination and passion, I can always find a way to keep going.

Looking back at my OpenStreetMap journey, two dates will always hold a very special place in my heart—June 21 and October 14.

On June 21, I achieved something I had been working toward for a long time: I became the top mapper in KU Youth Mappers. That moment felt surreal. From the days when I was just learning how to draw my first building on the map to reaching the top position—it was a journey filled with patience, consistency, and continuous learning. Every late night of mapping, every small correction, and every effort finally felt worth it.

But the journey didn’t stop there.

On October 14, I reached another incredible milestone—I became a top mapper in UN Mappers. This achievement felt even bigger, as it connected my work to a global level. Contributing alongside mappers from around the world and being recognized among them made me realize how far I had come.

These milestones are not just about rankings or titles. They represent growth, dedication, and the impact of consistent effort. From starting out as a beginner to becoming a leading contributor in both university and international communities, my journey has transformed me—not just as a mapper, but as a learner and contributor.

Sometimes I pause and think about how it all started with simple curiosity. And now, those small steps have led to achievements I once never imagined.

This journey reminds me that with passion and persistence, even the smallest edits can lead to the biggest milestones.

In the first half of March, we ran a survey to better understand how people use OsmAnd and what they expect from it. At OsmAnd, we often talk about offline maps, route planning, and outdoor navigation. But the most important question is simpler: how do people actually use OsmAnd, and what do they need from it?

To explore that, we collected feedback across five language groups: English, German, French, Italian, and Spanish.

The results gave us a clear picture. Users value OsmAnd for its depth, flexibility, and offline capabilities — especially in situations where reliability and preparation matter. At the same time, the survey highlighted areas where the app still creates friction, particularly around usability, search, and routing confidence.

This post shares some of the main themes that appeared across all five surveys.

Who responded​

We received responses from users across five language groups:

In total, that gave us 2,488 responses.

Most respondents were already experienced OsmAnd users. In every language group, the majority had used the app for more than a year. This means the feedback mainly came from people who know the product well and use it regularly in real situations.

What users value most​

Across all languages, several themes appeared again and again.

Users consistently described OsmAnd as most valuable for:

• Offline maps while traveling
• Planning routes in advance
• Hiking and trekking
• Walking and exploring
• Cycling
• Navigation in remote or rural areas
• Recording and following GPX tracks

This confirms something important: for many people, OsmAnd is not just a general-purpose map app. It is a tool for prepared travel, outdoor activities, and offline navigation.

That was especially visible in the strongest use cases by language:

Even with those differences, one core idea was shared across all groups: users rely on OsmAnd when they want control, flexibility, and offline confidence.

What users appreciate about OsmAnd​

The survey shows that users see OsmAnd as:

• powerful
• flexible
• feature-rich
• useful in remote and offline scenarios
• well suited for outdoor and advanced navigation needs

Many users clearly trust OsmAnd in situations where mainstream navigation apps may not be enough — for example during hiking trips, travel abroad, off-road navigation, or route planning far from a stable connection.

This is one of OsmAnd’s strongest product and brand advantages.

The main friction points​

The feedback was positive overall, but one message came through very clearly:

Users value OsmAnd’s power, but many find it too complex.

This theme appeared in all five surveys.

The most common issues mentioned were:

• Interface complexity
• Too many settings or hard-to-find options
• Search quality
• Routing trust and route quality
• Map/data reliability in some cases
• Performance or stability problems for some users
• Friction in GPX and track workflows

In other words, the main challenge is not simply a lack of features.

The challenge is that the value of those features is not always easy to access.

For many users, OsmAnd feels extremely capable — but sometimes harder to learn or use than it should be.

A strong product, but with usability pressure​

One of the most encouraging findings is that overall loyalty remains strong.

Across all language groups, recommendation scores were high. Users clearly believe in the product. But that does not mean there is no risk.

Many respondents said they had at least occasionally considered using another app because of issues such as complexity, search friction, or routing behavior.

That creates an important tension:

• users respect OsmAnd
• users trust its strengths
• but some still turn to other apps for faster, simpler, or more convenient everyday tasks

This suggests that OsmAnd’s biggest opportunity is not only to add more capabilities, but to make the existing capabilities easier to use with confidence.

What users use alongside OsmAnd​

Many respondents also mentioned using other navigation apps in parallel with OsmAnd. This is not surprising — most people have multiple apps for different purposes.

The reasons were fairly consistent:

This comparison is useful because it shows that OsmAnd is not mainly competing on “how many features it has.” In many cases, it is competing on clarity, convenience, trust, and speed of everyday use.

What differs by language group​

Although the overall themes were similar, each language group had its own profile.

German-speaking users​

German-speaking respondents showed the strongest concentration around hiking, walking, cycling, and offline travel. This looks like a highly outdoor-oriented group with regular use patterns and strong engagement.

English-speaking users​

English-language responses were the broadest in profile. They combined offline travel, walking, hiking, route planning, and rural navigation, showing a wide mix of travel, outdoor, and practical navigation use cases.

French-speaking users​

French-speaking respondents stood out as strong offline and travel-oriented users, with high mentions of route planning, GPX recording, and hiking. This group reflects a power-user profile that values preparation and track-based workflows.

Italian-speaking users​

Italian-speaking users showed a distinctive mix of hiking, GPX use, route planning, and motorcycling. Compared with some other groups, motorcycling was especially visible here.

Spanish-speaking users​

Spanish-speaking respondents stood out most clearly for route planning, remote-area navigation, motorcycling, and daily car use. This group appears more road-navigation-oriented than the German or French groups, while still valuing offline and advanced use.

What all groups have in common​

Despite these differences, the common patterns are more important than the differences.

Across all five surveys, users consistently described OsmAnd as:

• a strong offline navigation tool
• especially useful for travel and outdoor scenarios
• more flexible than many mainstream alternatives
• valuable for users who want control over routes and maps

At the same time, all five groups also pointed to similar improvement areas:

• make the interface easier to understand
• make search more reliable
• improve routing trust
• reduce friction in core workflows
• keep the power, but make it easier to use

This consistency across languages is one of the strongest findings in the entire survey.

What this means for OsmAnd​

The survey confirms that OsmAnd already has a clear identity.

Users do not mainly come to OsmAnd because it is the simplest navigation app. They come because it offers something deeper:

• offline confidence
• route control
• outdoor readiness
• map flexibility
• support for advanced use cases

That is a real strength.

At the same time, the survey also shows a clear direction for improvement. Users do not want OsmAnd to become generic or stripped down. They want it to remain powerful — but to feel clearer, easier, and more trustworthy in everyday use.

That is an important distinction.

The goal is not to reduce what makes OsmAnd special.
The goal is to make that value easier to reach.

Thank you​

We are grateful to everyone who took the time to answer the survey.

Your feedback helps us better understand how OsmAnd is used in the real world — across countries, languages, and navigation styles. It also helps us see where the app already delivers strong value, and where the experience still needs work.

Across all five surveys, one message stands out:

Users trust OsmAnd for its offline power, flexibility, and outdoor capabilities. The biggest opportunity now is to preserve that depth while making the experience simpler and more intuitive.

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

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

Before

After

A future version of the UrbanEye3D plugin will support trees and other objects.

(Picture: Cathedral of the Assumption of Mary, Zagreb)

Note: this version is still in development, but should be relesed by the end of this month

Hello people, I’ve been Hoping to help my local town of Exeter and nearby plymouth, ive so far made houses in both sherford and torpoint, ive also named the schools of Clyst vale and Stoke hill, And im hoping to do more to help the community of OpenStreetMap

-SouthWestTrains1

Ciao a tutti. Come molti di voi già sapranno, ho aperto il voto sulla proposta OSM Civil Protection Areas, per mappare in OpenStreetMap aree di protezione civile ufficialmente designate come aree di attesa, ricovero, ammassamento soccorsi e accessi logistici di emergenza.​

In questo momento il voto è molto tirato, quindi ogni voto favorevole conta davvero. ​ Link diretto alla proposta: osm.wiki/Proposal:Civil_Protection_Areas ​

Mini guida per votare:

Fate login nella wiki OSM con il vostro account. ​

Aprite la proposta e scendete alla sezione Voting. ​

Cliccate su Edit source. ​

Aggiungete una riga con il vostro voto, seguendo il formato già usato nella pagina, per esempio I approve this proposal … –~~~~. ​

Salvate la modifica. ​ Grazie a chi riesce a leggere e votare.

Ihr wisst ja, ich hab’ einen OpenStreetMap-Fetisch :) Schon sehr lange trage ich gemeinsam mit der Schweizer OSM-Community die Idee rum, dass die ~2000 erfassten Gemeindegrenzen in OpenStreetMap besser gepflegt werden sollten.

Diese wurden vor ~14 Jahren in einem sogenannten Import in die OpenStreetMap-Datenbank eingepflegt und seither bei Gemeindefusionen Anfangs Jahr immer mal wieder gepflegt, aber nicht in toto überwacht.

Vor einiger Zeit habe ich im OSM Forum die Diskussion zur Grenzpflege begonnen, das dort angesprochene Tool der serbischen Community ist zwar sehr toll, aber der Umbau auf die Schweizerischen Gegebenheiten hat nicht befriedigend geklappt. Dies trotz der tollen Hilfe der SOSM mit einer virtuellen Maschine (mersi Datendelphin im Speziellen) auf der SOSM-Infrastruktur. Auf dieser VM lief das serbische Tool mit Anpassungen für die Schweiz, war aber nur schwer zu “bedienen”.

In einem Projekt bei der Arbeit habe ich mich etwas eingehender mit den sog. GitHub Actions beschäftigt, mit denen es möglich ist, ja nach Zustand eines GitHub-Projektes Aktionen durchzuführen, die ebenso auf einer virtuellen Infrastruktur (aber halt von Microsoft laufen). Eine solche Action baut beispielsweise aus etwas LaTeX-Code, der online liegt automatisch meinen Lebenslauf (ich hab’ keine Bewerbung offen, brauchte aber letzthin aus anderen Gründen einen Lebenslauf). Oder aus etwas Textschnipseln eine Webseite und ein PDF, das eine Pubikation ergeben wird.

Item, Programmcode im Internet etwas machen zu lassen, ist mit solchen Actions einfach, schnell iterierbar und etwas weniger komplex, als per ssh auf einem Server Python-Code laufen zu lassen.

Um die Gmeindegrenzen in OpenStreetMap zu überwachen habe ich jetzt nicht Programmiercode im Netz zum laufen gebracht, sondern diesen Programmiercode nicht selber geschrieben. Das geht mit sog. vibe coding gemacht. Zu Beginn habe ich das Large Language Model von Claude.ai mit einem Prompt gefüttert, der beschreibt, was ich machen will.

I have the boundaries of the swiss municipalities in https://data.geo.admin.ch/ch.swisstopo.swissboundaries3d/swissboundaries3d_2025-04/swissboundaries3d_2025-04_2056_5728.gpkg.zip. Help me produce a report on how well these match geographically with the boundaries mapped in OpenStreetMap, preferrably via Overpass Turbo. The boundaries in the geopackage have bfs_nummer=355, the boundaries in OSM have swisstopo:BFS_NUMMER=355 as a matching ID.

Can you query Overpass in Python, too?

Can you make this all work in a GitHub action?

Das heisst, ich habe Claude informiert, dass die Gemeindegrenzen der Schweiz in OpenStreetMap in sogenannten Relationen mit z.B. swisstopo:BFS_NUMMER"=355 für Köniz erfasst sind. Die BFS_NUMMER wird vom Bundesamt für Statistik vergeben und taucht genauso in den offiziellen Gemeindegrenzen von swisstopo, swissBOUNDARIES3D auf. Ich hätte die Abfrage der Gemeindegrenzen gerne mit Overpass turbo abgefragt, den Vergleich in Python gemacht und das Ganze per GitHub Action z.B. täglich laufen gelassen. Schon die erste Antwort von Claude lieferte Resultate, die ich dann in VS Code mit CoPilot mit vielen Prompts immer weiter verfeinert habe. Ich habe nur extrem wenig Code selbst geschrieben, praktisch Alles wurde gesteuert durch meine Eingaben maschinell erstellt, minimalste Zwischenschritte wurden von Anderen beigesteuert.

Nachem Simon Poole bemerkt hat, dass Gemeindegrenzen mit Enklaven/Löchern nicht korrekt ausgewertet werden und einigen weitern Korrekturen der Berechnungslogik hat die Schweizer OSM-Community nun ein Tool, das den Vergleich der Gemeindegrenzen von swisstopo mit den Gemeindegrenzen in OpenStreetMap bietet: http://boundaries.osm.ch

With a diversion through Newbiggin today's ride took me from Amble to Cambois and back along NCN1.

The cycle path isn't far from a number of former collieries and colliery villages. At each end are ports used for export of coal. Between Hauxley and Cresswell is a series of nature reserves created from the results of coal mining. East Chevington nature reserve was passed to Northumberland Wildlife Trust following opencast restoration. Hauxley Nature Reserve was originally part of Radcliffe open-cast mine. Druridge Pools are a former opencast coal mine. Cresswell Pond is the result of subsidence from collapsed mine works.

Cambois is a former colliery village on the north side of the River Blyth. The colliery closed in 1968. That left access to a deep-sea port, a skilled work force, a rail network and coal was still available from nearby collieries. So from 1970 aluminium ore from overseas was landed here and taken by rail to a smelter at Lynemouth. Electricity was generated at Lynemouth power station, which burnt coal from Lynemouth and Ellington Collieries.

Lynemouith Colliery closed in 1994 and Ellington Colliery in 2005. Lynemouth power station could continue to burn coal sourced from elsewhere, but from 2004 biomass was introduced into the mix, and the power station has relied entirely on biomass since 2015. However, the Lynemouth smelter was now un-economic, and it closed in 2012. Alumina is still imported, and transferred by rail to Lochaber Aluminium Smelter near Fort William on the west coast of Scotland. Lochaber is powered by a hydro-electric scheme.

Lynemouth Power-station now supplies the national grid. But the former coal yards are no longer needed. In 2021 plans were approved for a factory on the site that would manufacture batteries for electric cars. However, construction ceased in 2024 as a result of funding difficulties. In 2025 plans were approved for a datacentre on the site.

This isn't the most beautiful part of Northumberland, but a memorable experience today was watching a family of deer at Druridge Bay Country Park. Happily grazing alongside the cycle track, they were clearly aware that a couple of us were nearby, but they seemed quite relaxed. Eventually they wandered off. The track through the country park is well-used by walkers and cyclists and presumably the deer get used to seeing people. There are different ways of adapting to the area's complex industrial history.

Westhay Moor & Honeygar Farm: osm.org/#map=16/51.19215/-2.78186

Shapwick Heath Nature Reserve & RSPB Ham Wall: osm.org/#map=15/51.15109/-2.79207

Erste Schritte

Ich habe gerade diese Funktion entdeckt. Und eigentlich klingt es nach einer tollen Idee, meine Ausflüge in einem persönlichen Blog zu dokumentieren. Vielleicht freue ich mich ja eines Tages, wenn ich das hier lese ^^

Ostatnio zauważyłem, że styl OSM Americana nie wyświetla w szczególny sposób numerów dróg wojewódzkich, w przeciwieństwie do dróg krajowych, w tym dróg ekspresowych i autostrad, co zgadza się z definicją, a raczej jej brakiem. Na podstawie opisu jednego z pull requestów w repozytorium tego stylu wywnioskowałem, że generator opiera się na tagu network w celu wywnioskowania kategorii.

Postanowiłem więc sprawdzić, jaka wartość tagu network jest wykorzystywana do oznaczania dróg wojewódzkich. Szybka kwerenda, wykonana przy użyciu głównej strony OSM, Overpass API i Taginfo doprowadziła mnie do wniosku, że drogi te oznacza się tagiem network=pl:regional.

Postanowiłem również sprawdzić, jak oznacza się drogi powiatowe i gminne. Jako że w artykule wiki o tagu network tego nie określono, postanowiłem dokonać samodzielnej analizy. W tym celu napisałem skrypt Pythona, który odpytuje server Overpass i wykorzystuje bibliotekę pandas w celu wygodnego przetwarzania tych danych.

Parametry wejściowe

Zapytanie do serwera Overpass miało następującą postać:

[out:csv(::id,name,ref,unsigned_ref,network)]; area(3600049715)->.pl; rel(area.pl)[type=route][route=road][network~"pl:.*",i]; out geom;

Najistotniejszymi tagami branymi pod uwagę w tej analizie są network, ref i unsigned_ref (ostatni z nich wzięty pod uwagę ze względu na sposób użycia w relacjach analogiczny do tego na liniach). Numer relacji i tag name są wykorzystywane w celu ręcznej weryfikacji zarówno wyników analizy, jak i samych relacji, a ponadto numer relacji służy jako indeks dla tabel biblioteki pandas.

Wyrażenia regularne dla numerów poszczególnych dróg wyglądały następująco:

• autostrady: ^A[0-9]{1,2}$
• drogi ekspresowe: ^S[0-9]{1,2}$
• pozostałe drogi krajowe: ^[0-9]{1,2}$
• drogi wojewódzkie: ^[0-9]{3}$
• drogi powiatowe: ^[0-9]{4}[ ]?[BCDEFGKLNOPRSTWZ]$
• drogi gminne: ^[0-9]{6}[ ]?[BCDEFGKLNOPRSTWZ]$

Uwzględnienie potencjalnej spacji między częścią cyfrową a wyróżnikiem województwa numerów dróg powiatowych i gminnych wynika z tego, że część z tych numerów jest zapisana razem z tą spacją. Kwestia ta wymaga poprawy, jednak problem ten nie jest powiązany z przedmiotem tej analizy.

Wyniki analizy

Wstępne wyniki analizy prezentują się następująco:

Ponadto, skrypt zwrócił następujące drogi, których wartości tagów ref i unsigned_ref nie pasują do żadnych z wymienionych wcześniej wyrażeń regularnych:

Dzięki ręcznej weryfikacji powyższych dróg liczby podane w 1. tabeli zwiększają się na potrzeby analizy:

• dla zwykłych dróg krajowych z tagiem network=pl:national — o 1;
• dla dróg wojewódzkich z tagiem network=pl:regional — o 2
• dla dróg gminnych z tagiem network=pl:local — o 1;
• dla dróg gminnych z tagiem network=pl:municipal — o 3.

Należy podkreślić, że nan oznacza brak wartości, a nie wartość o takim brzmieniu.

Wyniki ostateczne analizy prezentują się następująco:

Wnioski

Oznaczenie sieci dla dróg krajowych (w tym dróg ekspresowych i autostrad) i dróg wojewódzkich jest spójne. Wyjątkami są obwodnica Nowego Miasta Lubawskiego, która jest oznaczona tagami network=pl:local, gdyż obwodnica jako taka odciąża to miasto, i ref=15, jako że stanowi ona część drogi krajowej nr 15, oraz droga wojewódzka nr 864, która jest oznaczona tagiem network=PL:regional, zgodnie z zasadą ze wspomnianego wcześniej artykułu wiki, która stanowi, że kody krajów powinno zapisywać się wielkimi literami.

Niespójności występują w oznaczaniu dróg powiatowych i gminnych. Ponadto, stosowane są kolidujące schematy oznaczeń: tag network=pl:regional jest używany zarówno przez drogi wojewódzkie, jak i powiatowe, a tag network=pl:local — zarówno przez drogi powiatowe, jak i gminne.

Drogi powiatowe wykorzystują w zdecydowanej (74,8%) większości tag network=pl:local. Tag network=pl:regional jest stosowany przede wszystkim dla dróg w okolicy Rzeszowa, jak również w śląskiem i opolskiem. Z tagu network=pl:district korzystają drogi na obszarze między Gdynią a Lęborkiem.

Drogi gminne wykorzystują w przytłaczającej (96,4%) większości tag network=pl:municipal; są to drogi w części siedleckiej województwa mazowieckiego. Z tagu network=pl:local korzystają drogi w okolicach Wrocławia i Piotrkowa Trybunalskiego.

Analiza nie objęła dróg nieoznaczonych jakimkolwiek tagiem network=*, jako że problem spójności oznaczania sieci nie występuje dla nich obecnie, a ich oznaczenia można podjąć się później, jak również tych oznaczonych tagiem innym niż network=pl:*, jako że w ich przypadku problem jest głębszy niż tutaj analizowany.

Dalsze działania

Problem oznaczania sieci dla polskich dróg zostanie podniesiony na polskiej sekcji OSM Community w celu ustalenia nowych standardów, szczególnie dla dróg powiatowych i gminnych, oraz korekty obecnych oznaczeń w zgodzie z istniejącymi standardami.

Analiza zwróciła również uwagę na błędnie oznaczone relacje, m. in. drogę krajową nr 11 (brak tagu ref), Małoposki Szlak Solny (niepoprawna wartość tagu route) czy miejscowość Zwardoń (błędne wykorzystanie jako relacja szlaku turystycznego). Te, jak i inne relacje wskazane w 2. tabeli zostaną wskazane jako wymagające weryfikacji i naprawy.

Ceci recense les bibliothèques cartographiées sur OpenStreetMap à Genève et dans le canton, avec leurs catalogues en ligne.

Survol

Voici un petit survol de bibliothèques publiques, semi-publiques ou peut-être accessibles aux spécialistes.

a. “Bibliothèque de Genève” et les bibliothèques des musées

b. Bibliothèques municipales (BM) à Genève et dans les autres communes du canton

c. Bibliothèques de l’université de Genève (UNIGE)

d. Bibliothèques des Hautes-Ecoles Spécialisées (HES)

e. Bibliothèques CO, collèges, ESII, Ecolint, Webster university

Sur env. 50, deux bibliothèques sont actuellement cartographiées :

• Centre de documentation Madame-de-Staël
• Centre de Lullier Bibliothèque

f. Bibliothèques et archives d’organisations internationales

g. Centres de documentation, archives et bibliothèques spécialisées

h. Ludothèques

pour mémoire (Elles devraient utiliser amenity=toy_library)

Avancée

La cartographie de (a.) et (b.) était plutôt bonne. Les bibliothèques municipales de Genève utilisent OSM sur leur site, y compris osmapp. Pour le catalogage: (a.) utilise Swisscovery, (b.) leur propre catalogue. La bibliothèque du Muséum d’histoire naturelle est fermée.

(c.) avait besoin d’une mise à jour suite aux changements intervenus ces dernières années (déplacement de sites, regroupements, chantiers de construction en cours). Ceci malgré l’utilisation d’OSM sur le navigateur de Swisscovery et sur le site web de l’université. Certains instituts et leur bibliothèques pourraient encore être rajoutés.

(d.) Les bibliothèques, infothèques et centres de documentation des Hautes-Ecoles spécialisées (HES) étaient partiellement couverts. Ces bibliothèques utilisent un module de Swisscovery et sont accessibles aux lecteurs avec une carte du réseau.

(e.) La couverture de ces bibliothèques est quasiment nulle car elles sont accessibles uniquement aux élèves et aux enseignants. Il y a un catalogue commun “Flora” de ce qui relève de l’Etat. On a désormais Médiathèque SEM et Centre de documentation du SRED destinés aux enseignants (voir g.). Bibliothèque du Centre de Lullier est partagé avec la HES.

(f.) La couverture devrait être améliorée. L’accès à ces bibliothèques varie et les collections recentes sont souvent avant tout numériques.

(g.) C’est un groupe très varié et potentiellement infini.

(h.) Les ludothèques qui avaient “amenity=library” ont été changées en “amenity=toy_library”. La couverture pourrait être améliorée.

Keys utilisés

Il y a des tags, avec les keys suivants:

• amenity=library ou amenity=archive, government=archive
• name, short_name, alt_name
• addr:, y compris, parfois, addr:housename, addr:floor
• website, website:catalogue
• operator devrait indiquer l’institution à laquelle elles sont rattachées.
• network pour Swisscovery
• Souvent il y a ref:isil ou ref:isil=none en l’absence. Pour quelques cas, il y a ref:CH-GE:REG.

Comme des opening_hours étaient déjà saisis, j’ai rajouté opening_hours:url . check_date:opening_hours devrait également être présent.

Couverture ailleurs

Les bibliothèques (a) (c) (f) sont plutôt bien couverts par le répertoire suisse d’ISIL. (g) en ce qui concerne les archives. Certaines entrées “actives” n’existent plus ou ont déménagé.

Le guide de Swisscovery est plutôt à jour, même si certains sites y répertoriés ne sont plus ou actuellement pas accessibles au public.

REG.APP.GE.CH couvre (a) et (b) et quelques (g).

Le ville édite une carte/liste qui semble lacunaire et pas à jour.

Il existe également des listes complètes par HES-SO, UNIGE, DIP (Flora), BM Genève.

Cartes

• Bibliothèques et centres de documentation du canton de Genève
• Bibliothèques, archives et centres de documentation du canton de Genève
• Institutions avec ref:isil=none
• Ludothèques

Développements possibles

• (a), (c), (d) en cas de réouverture, mettre à jour les entrées
• (b) rajouter le bibliobus
• (e) éventuellement les rajouter, si vous en voyez l’utilité.
• (f) faire un survey détaillé, rajouter ceux qui manquent
• (g) reste à développer, notamment les archives
• (h) regarder s’il en manque (plutôt hors Ville de Genève).
• compléter “opening_hours:url”
• détailler le type d’accès
• rajouter “operator:type”
• suggérer une mise à jour d’ISIL, à la Ville

In this edition of our OpenStreetMap interview series we speak with Martin Ždila of Freemap Slovakia, the Slovak local chapter of the OpenStreetMap Foundation. Founded in 2009 and run entirely by volunteers, the organisation promotes OpenStreetMap in Slovakia, develops the freemap.sk map portal, and helps improve national map data. In this interview, Martin shares insights into the Slovak mapping community, its achievements, and the challenges it faces.

1. Who are you and what do you do? What got you into OpenStreetMap?

Martin: We are Freemap Slovakia, the Slovak local chapter of the OpenStreetMap Foundation, established in 2009. Our main goals are to promote OpenStreetMap in Slovakia, to build and operate our own map portal freemap.sk, and to improve OSM data coverage — including negotiating access permissions and performing imports from open government sources. The organisation is run entirely by volunteers.

2. What would you say is the current state of OSM and the OSM community in Slovakia?

Martin: Slovakia has a small but technically skilled and dedicated community. On a typical day, around 10–20 mappers are active, and the top contributors are very prolific. Many active Slovak mappers are not yet members of Freemap Slovakia — if you map in Slovakia, we’d love you to join us! We’d also like to attract more mappers overall, especially from rural areas and smaller towns that are still less well covered.

Data coverage is strong for a country our size. Address coverage stands at around 96%, road networks and hiking trails are well-maintained, and we have excellent open government geodata to work with: the Ortofotomozaika SR provides high-resolution aerial imagery updated in regular cycles, and high-quality LiDAR data is publicly available — we actively use both for improving landcover, waterways, and terrain shading.

We also have a close relationship with the Czech OSM community — cross-posting in each other’s forums is common, and we jointly organise the annual State of the Map CZ+SK conference.

3. What are the unique challenges and pleasures of OpenStreetMap in Slovakia? What things should the rest of the world be aware of?

Martin: The landscape is a genuine pleasure to map — Carpathian mountain ranges, dense forests, thousands of kilometres of marked hiking and cycling trails, castles and historical sites. There is always something interesting to add or refine.

We are proud of www.freemap.sk — our non-commercial map portal built on OSM data, offering a detailed outdoor map for hiking, cycling, skiing, and horse riding across Central Europe. It includes marked trail overlays, route planning for many transport modes, a GPX track viewer, live tracking (OsmAnd, Locus, Traccar), offline map export, GPS device map downloads, and a community photo layer — available in seven languages. We also maintain LiDAR-based tooling for landcover tracing and waterway accuracy improvement.

On the challenge side, the open government data situation has been deteriorating. Our government has been gradually closing datasets that were previously freely available, and the cadastral office suffered a serious cyberattack with poor backups, slowing access to up-to-date cadastral data. This is a real concern for OSM in Slovakia going forward.

4. What is the best way to get involved? Is there a regular meet-up? A mailing list? Where does the community meet (in person and online)?

Martin: The best starting point is our Google Group:— technical discussions, import proposals, and mapping questions all happen there.

For news and updates we also have a Facebook page and a Mastodon account .

In person, we hold an annual general assembly once a year as a weekend gathering — talks, planning, and always some local mapping. A good chance for remote contributors to finally meet.

5. What steps could the global OpenStreetMap community take to help support OSM in Slovakia?

Martin: Anything that helps OSM globally helps Slovakia too — better tooling, broader public awareness, stronger core infrastructure.

One area worth highlighting specifically: the OSM tagging schema. Documentation for many tags is unclear or unfinished, and the same feature often has multiple competing tagging conventions. The community should be less afraid to clean up legacy tags and consolidate — AI tools could actually be a real asset here for auditing and rationalising tagging at scale.

6. OpenStreetMap recently celebrated its 20th birthday — a natural time to reflect on how far the project has come, but also to look forward. Where do you think the project will be in 10 years, both globally and in Slovakia specifically?

Martin: Globally? Hoping for OSM API 0.7 😄. More seriously, I expect OSM to become the default base layer for geospatial applications worldwide, with AI-assisted mapping accelerating coverage in under-mapped regions — though quality assurance and community governance will need to keep pace.

For Slovakia, I hope to see address coverage climb from ~96% toward complete, and a general improvement in precision across all feature types — landcover from LiDAR, more accurate waterways, better building footprints. The data is largely there; the next decade is about refining and deepening it.

Many thanks to Martin and the Freemap Slovakia team for taking the time to share their perspective and for the work they do supporting OpenStreetMap in Slovakia.

Forward!

Danielle and the OpenCage team

Please let us know if your community would like to be part of our interview series here on our blog. If you are or know of someone we should interview, please get in touch, we’re always looking to promote people doing interesting things with open geo data.

Hello

I have been using OpenStreetMaps for navigation across the globe for multiple years free of charge. I think the time has come for me to give something back to this community.

Thank you wonderful people at OpenStreetMap for such a wonderful project! I hope my contributions will help.

Kind regards

The Vilnius Stroller

I’ve been mapping crosswalk corners using a single point for the curb (lowered or otherwise) on a small spur connecting the sidewalk to the crossing way, trying to balance: - One entity per feature (not duplicating the curb) - Not blocking the sidewalk routing (on the sidewalk, you don’t need to cross the curb to turn the corner) - Not blocking the crossing routing (if you cross one edge, then the next edge, you don’t necessarily need to stop at the curb unless the intersection has signals)

When I update an intersection that has the two sidewalk ways and two crosswalk ways meeting at a single curb point, or sidewalks crossing and connecting two separate curb points to the crossings (except where there actually are two curbs), I’ve been reworking the ways to match this structure.

The latest Pedestrian Working Group/Guide suggests a slightly different approach (examples at that link):

• Use a single point for the kerb where it meets the road.
• Only use a second curb POI if there are two distinct curb features.
• Use a spur connecting the curb to the two branches of sidewalk.
• Allow the crossing ways to meet at the curb point.

It makes sense, and it’s cleaner than the way I’ve been trying to put the curb in the middle of that stub (and more accurate in that the kerb isn’t in the middle of the sidewalk), so going forward I’ll use that scheme instead.

Unfortunately I can’t just turn off the “Barrier blocking highway” rule in Osmose, because it’s still needed to find places where the sidewalks meet incorrectly at the curb. :shrug:

Today the Federal Council approved its proposal for a mobility data infrastructure law (MODI). While we support the fundamental goal of making mobility data more comprehensive and easily accessible, and emphasised this in our consultation response three years ago, this should not obscure what this proposal is also about:

• financing the Federal Office of Topography’s entry into a market created over decades by private sector and civil society initiatives,
• creating a market advantage for the Federal Office of Topography by linking MODI usage to their other data products – without any technical or economic necessity and without any discernible social added value,
• introducing a de facto monopoly on navigation and related services following the Austrian model – with the result of less choice, higher costs for providers and users in the mobility sector and is a competition regulation misstep.

SOSM therefore continues to firmly reject the proposal in its current form. At the same time, we reaffirm our offer to cooperate with the Federal Council and the Federal Office of Transport to jointly develop a fair, market-oriented, and cost-effective solution.

More information can be found in the FAQs https://sosm.ch/modi-faq/.

Bergdietikon, May 14th, 2025

Proudly powered by WordPress

I am happy to annouce that, after a long time we, the OpenStreetMap Carto maintainers, have prepared a new major release of the OpenStreetMap Carto stylesheet (the default stylesheet on the OSM website). Once changes are deployed on openstreetmap.org it will take a couple of days before all tiles show the new rendering.

The main change that warrants a new major release is the move to the osm2pgsql flex backend. This now requires an osm2pgsql version >= 1.8.0. It, so far, only comes with very few and subtle changes in rendering results related to changes in defaults in polygon/linestring classification of closed ways. The database schema is explicitly meant to be backwards compatible from the style side so style users who render different styles from the same database should be able to continue to do so without problems. We hope to use the additional flexibility of osm2pgsql in the future, but we have decided to do this step by step - and with this release only make the formal move but not yet make larger changes to the database. Deployments none the less should do a full database reload.

What we have, however, in this release is an additional table with the commonly used values for shop and office tags. This is generated and filled with an sql script (common-values.sql) that is included in the style. This needs to be run on the database before using the style - like existing indexes.sql and functions.sql.

Here are some details on the visible changes this release brings to the style.

Stop shop/office catch-all

For shop and office tags OSM-Carto has so far implemented a catch-all - meaning that we have rendered these with a generic dot and label for any value except a number of exclusion values (like shop=no, shop=disused etc.). This has not been in line with our goal of providing constructive mapper feedback, because mappers got positive feedback even for obviously nonsensical values or typos. The solution we have now implemented is to use a positive list of supported values that is generated from taginfo data - practically meaning we support any value that is used at least 25 times in OSM at the time of the OSM-Carto release.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5169

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5186

Thanks to contributor dch0ph for implementing this change.

Remove low zoom landuse fading

Many years ago we had added a mechanical fading of landcover colors at the lower zoom levels - a change that was and still is highly controversial. We had already reduced the fading previously, but we have now reached consensus to roll this back completely. This is going to make consistent color design across all zoom levels significantly easier.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5148

Thanks to contributor dch0ph for implementing this change.

Unpaved rendering for turning circles / mini-roundabouts

We are now also rendering turning circles and mini-roundabouts on unpaved roads with an unpaved pattern.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5069

Thanks to contributor dch0ph for implementing this change and sommerluk for previous work on this.

Remove natural earth boundaries for z1-3

The last remaining non-OSM geodata OSM-Carto used so far are the administrative boundaries at z1-3. Because these are not consistent with the data in OpenStreetMap, people have rightfully expressed the wish to remove those.

We have - so far - no good method to render administrative boundaries at z1-3 in decent quality so we decided to simply remove their rendering at these scales.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5123

Thanks to contributor ZeLonewolf for implementing this change.

access=destination markings on additional road types

Previously, access=destination was only rendered on some road types while not on others. We have removed this differentiation and now render access=destination on all road types where we render access=no as well.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5049

Thanks to contributor dch0ph for implementing this change.

Move bus guideways to road layers

The rendering of highway=bus_guideway has been highly non-ideal for a long time. We have now managed - as a first step - to move bus guideways into the road layers and this way to at least correctly layer them with the other roads.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5057

Thanks to contributor dch0ph for implementing this change.

Change drawing order for leisure=track and attraction=water_slide

leisure=track and attraction=water_slide were previously rendered at confusing positions in the layer stack. We have moved them to a more sensible location.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5046

Thanks to contributor dch0ph for implementing this change.

Make slipway rendering consistent in different layers

slipways are rendered in OSM-Carto like minor service roads, but there were inconsistencies with this for bridges and tunnels. This has been fixed now.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5035

Thanks to contributor StyXman for implementing this change.

Tidy up leisure polygon labelling

Symbol and label display of various leisure related features has been in a very inconsistent state for a long time. We have now managed to make some first steps in clearing this up.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5179

Thanks to contributor dch0ph for implementing this change.

Improvements of landuse outlines

The rendering of subtle outlines on landuse polygons has been somewhat inconsistent in the past and we now managed to unify this a bit.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5086

Thanks to contributor dch0ph for implementing this change.

Remove operator label on ATM

So far we have displayed the operator on amenity=atm with a label, but it became clear that this does not make a lot of sense - hence we removed it.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5055

Thanks to contributor dch0ph for implementing this change.

Add symbol for shop=motorcycle_repair

shop=motorcycle_repair is now rendered with a dedicated symbol instead of a generic dot.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5066

Thanks to contributor dch0ph for implementing this change.

Show hole ref for golf holes

Rendering of labels on golf=hole lines had been broken in the past and we have decided to replace it with a display of ref.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5133

Thanks to contributor robert-ancell for implementing this change.

Add natural=peninsula labels

We have added rendering of nodes and polygons tagged natural=peninsula with a name label.

Thanks to contributor quincylvania for implementing this change.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/4778

Render entrance=shop

We added rendering of entrance=shop in the same design as entrance=yes. Further improvements to this by rendering entrance=shop in a dedicated design are welcome.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5108

Thanks to contributor deevroman for implementing this change.

Add avalanche_protector to tunnel types

tunnel=avalanche_protector is used to tag roads that are covered for protection against avalanches. We added rendering this on roads like we already render tunnel=yes/covered=yes.

https://github.com/openstreetmap-carto/openstreetmap-carto/pull/5166

Thanks to contributor dch0ph for implementing this change.

Other changes

This release also includes various other, non-visible changes. For a full list of commits, see

https://github.com/openstreetmap-carto/openstreetmap-carto/compare/v5.9.0…v6.0.0

Note for deployments: This release moves to use the osm2pgsql flex backend and therefore requires a database reload and osm2pgsql version >= 1.8.0. It also newly requires an additional table to be generated on the rendering database using a supplied SQL script. Instructions how to do that can be found in INSTALL.md.

Thanks

The OSM-Carto maintainers thank all contributors. Particular thanks go to the new contributors:

deevroman, gy-mate, joto, quincylvania, robert-ancell, zuzak

As always, we welcome any bug reports at

https://github.com/openstreetmap-carto/openstreetmap-carto/issues

Android 13 was released in August 2022, not yesterday, but on the other hand not so long ago.

Why is this relevant?

With Android 14 google started updating the root certificates¹ with updates to its “play” services², prior to that they were only updated with full system updates and while now you can count on such updates for multiple years that used to be very different.

This is a problem for apps running on older devices that need to access resources on the Internet with encrypted connections (that is with https) as not only can such a resource change its certificate provider and potentially by doing that change the relevant certificate authority, certificates can expire or otherwise be invalidated. If that happens the resource is essentially unusable without an update to the certificate authorities.

This is not a new problem, particularly for Vespucci³ as we support devices going back to Android 5 and without the app bringing its own copy of the relevant root certificate for Let’s Encrypt⁴ along, you wouldn’t have been able to access openstreetmap.org for years on old phones.

So it shouldn’t have been a surprise when on last Saturday an issue was opened complaining that the Polish governments geoportal was erroring⁵, but what issues users report is not always straight forward, and this was likely the first “important” source that ran in to the problem.

Now there is a quick fix and that is that the user installs the relevant certificates on their device themselves, this requires that the relevant app trusts user installed certificates and I’ve enabled that on V21.2.4 that is being distributed now. What the situation is with this configuration with other apps is unclear.

Asking a user to install a certificate themselves is rather high friction and something that I would like to avoid if possible, the alternative to it is to add further certificates to the app itself. This is not something anybody really wants to do, as on the one hand these certificates can become invalid just as the systems ones, and on the other hand this requires additional work to determine which certificates to provide and is just a general PITA (sorry for the language).

But the first order of the day is to determine what the full extent of the issue is which I did by creating a test that loops over all sources in the Editor Layer Index⁶ and then running it on a selection of Android emulators for Android 13, 9, 7,1 and 7 (7 because this is the oldest version Ilya supports in everydoor⁷). The results⁸ show that this is a limited issue back to 7.1 and then starts getting quite a bit larger, but as noted in the github issue we can largely resolve it back to 7.1 with a small number of additional certificates for now. This will be available in V22 and likely backported to the next maintenance release of V21.

The situation will degrade further over time and if you find a source that is potentially showing the problems use Vespuccis Test function⁹ on the layer or the equivalent in the app you are using to determine if this is really due to a missing/unknown root certificate. You should always be able to workaround the issue yourself by install the certificate on the device.

1. https://en.wikipedia.org/wiki/Root_certificate ↩

2. De-googled devices and 3rd party Android versions are out of scope for this discussion. ↩

3. https://vespucci.io/ ↩

4. https://en.wikipedia.org/wiki/Let%27s_Encrypt ↩

5. https://github.com/MarcusWolschon/osmeditor4android/issues/3144 ↩

6. https://github.com/osmlab/editor-layer-index ↩

7. https://en.osm.town/deck/@simon/116198808610759728 ↩

8. https://github.com/MarcusWolschon/osmeditor4android/issues/3149 ↩

9. https://vespucci.io/help/en/Main%20map%20display/#layer-control ↩