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 ↩

身近な標高(3/13追記・修正)

　標高といえば、一般的に山頂の高さをイメージすると思う。
あとは水準点、基準点とか… なので、eleを日常的に入力する機会は多くないかもしれない。
JA:Key:ele

入力したことないって人も多いだろうが、意外と標高は身近なところで表示されている。
それは…

1. 海抜（標高）表示板

　国土交通省が東日本大震災による津波被害を踏まえ、対策として海抜情報(海抜表示シート)を提供。
街路灯に信号、道路標識などに貼り付けており、海沿いの地域では多く設置されている。

ele=3
inscription=ここの地盤は海抜(標高)3m
man_made=sign

自治体も電柱に貼ってたりする。向きによって見落としがち。

ele=2
inscription=この付近の地面は標高約2m
man_made=utility_pole

防災意識の向上、避難の目安として設置しているが、スルーして通り過ぎてませんか？
私はマッピングするまで、まともに見たことありませんでした…

探すつもりがないときによく見かけ、いざ探すとなかなか見つからない…

※タグのつけ方は、調べ方が足りないかもしれないけど、
サンプルがみつからなかったので勝手にいれてます…
有識者の方々、ご教示ください

2. 避難施設案内標識看板

　学校、公民館などの指定緊急避難場所に設置されている。

ele=5
emergency:social_facility=shelter
emergency=assembly_point
assembly_point:earthquake=yes
assembly_point:flood=yes
assembly_point:landslide=yes

　あと、津波避難ビルや公園の地震時の緊急避難場所の看板にも書いてたりする。

ele=3
emergency=assembly_point
assembly_point:earthquake=yes

ele=2.7
emergency=assembly_point
assembly_point:tsunami=yes

　自治体などがオープンで公開しているので狙い撃ちで探せる。 　 OSMには（少なくとも自分の周りでは）あまり登録されていない印象。
オープンデータからインポートを… ていうのは、いろいろメンドイから割愛。
私は周りのマッピングも兼ねて現地確認してます。

※避難場所についてはWikiに詳しく書いてあります
JA:Tag:emergency=assembly_point

いる？

　地理院地図ではDEMから取得できるし、等高線という素晴らしい表記方法もある。
なんならマップに描画されないんだから、いるのか？って感じだが、
ピンポイントの数値として残して記録しておくと、

• OSMの防災マップとしての質の向上(あわせて避難所のタグ付けも)
• 上記から地域の防災マップを作成
• 浸水想定の確認
• 地域研究

などで役に立つかもしれない。

〆

見かけはするけど、気にせずそのまま通り過ぎるこの2つ。
防災の意識を見直すついでに、自分が立っている高さ(Z軸・人によってはY軸）にも目を向けてみるのも面白いかもしれない。

Mentre scarico alcuni dati dal geoportale della Regione Lombardia, guardo gli ultimi nodi mappati e noto che molti di questi sono defibrillatori.

Ma perché?

Direi che è iniziato per caso, quando ne sono stati aggiunti alcuni nel campus universitario che frequento. Il senso però lo trovo qualche tempo dopo, quando alla festa di laurea di una delle mie migliori amiche la zia della festeggiata - cardiologa - mi fa giustamente notare che durante le emergenze, quando la velocità conta, è meglio sapere dove sono piuttosto che non saperlo affatto.

E questa cosa mi fa riflettere, mi risuona ininterrottamente nella testa, soprattutto se consideriamo l’attività di mapping non solo come “raccolta di dati georiferiti” ma anche come possibilità concreta di migliorare (e talvolta salvare) la vita delle persone intorno a noi.

Da allora, anche aiutandomi con MapComplete che in questo caso mi risulta utilissima, mappo tutti i defibrillatori che mi passano davanti agli occhi. Anche allungando i tempi di viaggio per fermarmi a quella fermata che mai avrei frequentato (dai, chi scende a Caiazzo?), anche per confermare lo stato di quelli esistenti.

Avrà effettivamente dei risvolti positivi sulla vita delle persone? Chi lo sa. Intanto ci proviamo.

quelli che ho mappato

l’andamento a Milano

l’andamento nella Città Metropolitana

Rail trails with route relations with railway=abandoned to denote a rail trail is not working. When the named “bike route” enters city streets or along side walks where the railroad never went this becomes and tagging nightmare.

I have had to remove railway=abandoned from a route relation in British Columbia and in New Hampshire where these were both issues. osm.org/note/5066887#map=15/41.40203/-73.62096

osm.org/note/4680502#map=15/49.49511/-121.22581

Can we find a better tags to mark bike routes with rail trail?
this is specific to route relations and not current tags for infrastructure, railway=abandoned still works for infrastructure

I would propose something like railway=trail so we keep this straight. It looks like railtrail=yes is a tag.

Yours in Mapping Natfoot

this is related to my other project on routing and bike routes. ask if you want to know more.

26/02/2026-04/03/2026

About us

• StreetComplete now has in-app support for weeklyOSM notifications, including a daily update from the weeklyOSM RSS feed, along with user settings to control message types. Also included in this update are notifications about OSM events nearby from the OpenStreetMap Calendar. You can read about all the improvements of v63.0 in the release notes.

Mapping

• James Wheare has started a wiki discussion on the conflicting definitions of the wetland=tidalflat tag.

Mapping campaigns

• ^[1] Daniele has just launched a Podoma instance on the Wikimedia Cloud Services platform to monitor ► OpenStreetMap Italia’s Project of the Month initiative.
• The Italian community’s February mapping campaign ► has ended. Thanks to all participants 100,000 street lamps were added, including details on support types, lamp types, and orientation.

Community

• In the latest instalment of their OpenStreetMap interview series, OpenCage has spoken with DW Innovation about SPOT, a tool designed to search for geospatial patterns within OpenStreetMap. The discussion explored how the project originated, the technical hurdles encountered during development, and the key insights gained following its launch.
• France’s Direction interministérielle du numérique has published ► an interview with Christian Quest discussing the Panoramax project, tracing its origins and early development, the initial challenges in building an active contributor community, and the obstacles it may face in the years ahead.
• MapRVA has launched The Yesterdays Bot, a Mastodon account that automatically shares geotagged historic photographs from the Yesterdays of Richmond, Virginia (USA), offering followers a glimpse into the city’s past through location-based archival images. The source is available on GitHub.

OpenStreetMap Foundation

• The OpenStreetMap Foundation Board has formally submitted comments on a proposal by the Open Geospatial Consortium to standardise the Overture Maps Foundation’s Global Entity Reference System. In its response, the Foundation clarified that it does not oppose the concept of a globally interoperable geographic identifier system. However, it urged the OGC to recognise that geographic reality cannot be reduced to a single authoritative source. The board argued that geographic knowledge is generated not only within the data centres of major technology firms, but also through the distributed efforts of volunteers mapping streets, neighbourhoods, and communities around the world. Any standard seeking OGC endorsement, the Foundation said, should be inclusive enough to accommodate both centralised and community-driven sources of geographic data.

Maps

• OpenStreetMap Americana has made several more multilingual improvements to support language dialects and apply dual language labels to more places. Web developers can install Diplomat to give any MapLibre map the same localised labels as OSM Americana.

Software

• GanderPL has built an OSM tagging MCP server using the iD Tagging Schema.
• Conveyal has developed Osmix, a collection of composable libraries for reading, querying, merging, and transforming OpenStreetMap PBF data in browsers or Node.js.
• Sarath Sabarish has published a diary entry explaining how SafeStreets, a free walkability scoring tool, uses OSM data, Nominatim for geocoding, Overpass API for pedestrian infrastructure and 15-minute city scoring. The post includes a concrete Chiang Mai example showing how missing highway=crossing tags produce near-zero crossing scores, and calls on SE Asia mappers to improve pavement (sidewalk) and crossing tagging.

Programming

• Pascal Neis described his experience of using LLM AI programming applications. He tested several AI coding assistants to automate coding tasks, building tasks iteratively in a local environment ‘from Flappy Birds to WebGIS’. He compared Microsoft Copilot, OpenAI Codex, and Anthropic Claude. He is seriously considering trying this kind of setup with his students next semester.
• HeiGIT explained how street-level imagery combined with deep learning methods is transforming how we detect and map critical infrastructure characteristics, which are often missing from existing datasets. Applications range from road surface classification and waste detection to pavement width measurement and weather-adaptive routing.

OSM in the media

• At FOSDEM 2026 Petya Kangalova, Senior Tech Partnerships Manager at HOT, spoke about how this humanitarian NGO has built a comprehensive technology stack based on the OpenStreetMap environment, designed to support local communities in mapping their surroundings, to strengthen disaster response efforts and support humanitarian operations worldwide.

Other “geo” things

• NASA and DevGlobal are hosting an online session on the Lifelines Data Studios, resources for collaborative work in some important thematics related to disasters, like wildfires, flooding, and landslides. The one-hour meeting will occur on March 11, 2026, 11:00 ET (UTC-4). You can register for free.
• Chromy showcased Flexport Atlas, an interactive global map partially powered by OpenStreetMap data that tracks cargo vessels, ports, and aircraft with live data updated every two hours, including precise vessel statuses (moored, at anchor, or in transit), and port dwell times.

Upcoming Events

Country	Where	Venue	What	When
	София	Rectorate of Sofia University St. Kliment of Ohrid	FOSS4G:BG Open GIS Conference 2026	2026-03-06 – 2026-03-07
			OSMF Engineering Working Group meeting	2026-03-06
	Tiranë	Destil Creative Hub Tirana	OpenStreetMap Community Meetup – Tirana	2026-03-06
	Gent	Wijgaard	OpenStreetMap meetup in Gent – Pre-VLA-congres editie	2026-03-06
		Hogeschool Odissee Hospitaalstraat 23 Sint-Niklaas	Vereniging Leraars Aardrijkskunde (VLA) conference 2026	2026-03-07
	Perth	Espresso Perk U Later	Social Mapping Sunday: Moort-ak Waadiny / Wellington Square Perth	2026-03-07
	Perth	Espresso Perk U Later	Social Mapping Sunday: Moort-ak Waadiny / Wellington Square Perth	2026-03-08
	København	Cafe Bevar’s	OSMmapperCPH	2026-03-08
	Delhi	Books and Beans Café, Mayur Vihar Phase 1	OSM Delhi Mapping Party No.27 (East Zone)	2026-03-08
	London	Social Sciences Centre – Western University	Friends of MSF UWO Mapathon	2026-03-09
			Missing Maps : Mapathon en ligne – CartONG [fr]	2026-03-09
	Brno	Geografický ústav, PřF MUNI, Brno	Březnový brněnský Missing Maps Mapathon na Geografickém ústavu	2026-03-09
	Grenoble	La Turbine Coop	Découverte d’OpenStreetMap	2026-03-09
	臺北市	MozSpace Taipei	OpenStreetMap x Wikidata Taipei #86	2026-03-09
	Hamburg	Voraussichtlich: “Variable”, Karolinenstraße 23	Hamburger Mappertreffen	2026-03-10
	Cork	Logitech, Cork, Ireland	Logitech Missing Maps – Office Mapathon	2026-03-11
	Reston	George Mason University, HUB VIP 3	The GAIN Mapathon	2026-03-11
	Zürich	Bitwäscherei Zürich	185. OSM-Stammtisch Zürich	2026-03-11
	Zürich	Schweizerisches Rotes Kreuz	Missing Maps Zürich Mapathon	2026-03-11
	Milano	Building 3A Ground Floor – Politecnico di Milano	PoliMappers Maptedì	2026-03-12
	Berlin	Dieselhaus, Forum a. d. Museumsinsel 10	213. OSM-Stammtisch Berlin-Brandenburg	2026-03-12
	München	WikiMUC	Münchner OSM-Treffen	2026-03-12
		Magrathea Laboratories Chaos Computer Club Fulda	OSM-Tools: Wenn die Welt zur Spielwiese wird	2026-03-13
	Leuven	Romaanse Poort	Camera’s in kaart brengen	2026-03-14
			Missing Maps London: (Online) Mid-Month Mapathon [eng]	2026-03-17
	Lyon	Tubà	Réunion du groupe local de Lyon	2026-03-17
	Bonn	Dotty’s	198. OSM-Stammtisch Bonn	2026-03-17
		Online	Lüneburger Mappertreffen (online)	2026-03-17
		MJC de Vienne	Réunion des contributeurs de Vienne (38)	2026-03-18
			Online Mapathon – Ärzte ohne Grenzen	2026-03-18
	Stainach-Pürgg	Online	20. Österreichischer OSM-Stammtisch (online)	2026-03-18
	Heidelberg	DEZERNAT#16	Rhein-Neckar OSM Treffen // Intro iD-Editor	2026-03-19
	Olomouc	Přírodovědecká fakulta Univerzity Palackého	Missing Maps Day Olomouc 2026	2026-03-21
			Frühlingsmapping 2026	2026-03-22
			Missing Maps : Mapathon en ligne – CartONG [fr]	2026-03-23

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

This weeklyOSM was produced by PierZen, Raquel IVIDES DATA, Strubbl, Andrew Davidson, barefootstache, derFred, izen57, s8321414.
We welcome link suggestions for the next issue via this form and look forward to your contributions.

This is not about the Linux Foundations Overture Maps attempt to hoodwink the Open Geospatial Consortium into standardising Overtures GERS (Global Entity Reference System) ¹. There is so little technical content available in that proposal that it is difficult to write even a short paragraph about it. But it is motivated by Overtures attempt to engage in the great American tradition of selling snake oil by suggesting that GERS solves real problems ². None of the following is new, and all this has been discussed many times in the OSM community.

It isn’t as if having a persistent id for an entity isn’t useful, for example if you are running a restaurant review site³ you definitely want a way to reference and track the state of the object you have reviews for in your geodata source, be it be based on OSM or some other data. The issue is simply:

your persistent id is not my persistent id.

Or perhaps better, your persistence is not my persistence. Lets illustrate that with the restaurant review example again: assume you’ve generated an id in some fashion and map that to an OSM object (more on that below), when do you consider the current restaurant different from the original, and when do you consider it different enough that you will want a new id?

Is it

• when the name changes?
• when the location changes? What about if it has just moved to the next block?
• when the cuisine changes?
• when the chef changes?
• when the owner changes?

And so on.

The answers to these questions depend on your use case and your business logic and a global one size fits all is very unlikely to be of any help at all. Now you might say, but there are objects, places, buildings and geographical entities that have less tendency to change, at least on a typical humans time scale and yes ids could be useful for these, but they are by their very nature easily referenced by their location⁴.

In summary a global persistent id decoupled from your use case doesn’t provide much utility and if you would utilize such a system it is likely that you would add a level of indirection to shield your internal business logic from being dependent on that of your id provider.

So if you are in the end creating your own ids anyway, how could you map them to OpenStreetMap entities?

Our holistic data model doesn’t make it very straight forward to continuously follow an entities modelling over its life cycle. To use the restaurant example again, it might start off as restaurant tagging on a building outline, morph to a Node⁵ with a location in that outline, be changed to an entrance on the outline or change to a room in the indoor mapping scheme and back again. The OSM data model doesn’t provide direct linkage between any of these, though mappers can reuse geometric elements in mapping, in the end you can’t rely on that happening in a consistent fashion. But if you can detect that such a change has happened you can use the tags (attributes) of the original element to find its current representation⁶.

Referencing a specific OSM object can be as simple as noting its type, its id and its version⁷. If the version has changed you can check the current attributes (tagging) and if they differ in a way that you consider relevant take appropriate action, which should likely always include a search for a nearby object with compatible tagging. If you find one, your id should then be mapped to the replacement. The same if the original element has been deleted. None of this is particularly difficult and you could easily use Overpass or a similar service to automatically find replacement mapping of the object you are interested in.

Enters OSMs data model curve ball: while the above works fine if your referenced object is a Node, geometry changes to linear and area features⁸ do not necessarily increase the objects version. This is not inherent in the data model, it is more convention than anything else, but it is a convention that is near universally observed. This means that I can move a building half way around the globe and its version will not change and for objects modelled by relations it can be even wilder.

The fix for this is simple: you need to not just store the elements_type_, its id and its version, you need to store an associated timestamp, in the simplest case the time when you retrieved the element to create the mapping⁹. To then check if the object has been further modified if the version hasn’t changed, retrieve the element and recursively compare your timestamp to that of the child elements¹⁰, if any of them are more recent than your timestamp, yes the object has been changed. No need to use historic data or anything exotic, the current OSM data is enough. You could even envision providing an API for this.

In summary: you don’t need Overtures GERS and you can link to OSM objects in a reasonably reliable fashion¹¹.

This is diary post 101, I should really just shut up

1. see https://github.com/opengeospatial/requests/issues/3 ↩

2. essentially the proposal just defines the output format of Overtures id generation process, without providing a specification or mechanism to generate them in a compatible format. More suspicious minds than mine might come to the conclusion that Overture actually wants to start a, probably commercial, id generation service and that this is simply the initial step to entrench it before announcing. It is interesting that all of their examples are centred around conflation/de-duplication and that can only work for a third party dataset if you use a compatible method to generate the ids, aka Overtures secret sauce. Unluckily given that the Linux Foundation gave Overture a corporate structure with zero public transparency and accountability we do not know if this is something their financials could require or not. ↩

3. See https://community.openstreetmap.org/t/a-crowd-sourced-review-service-for-openstreetmap/ for a recent discussion on the matter. ↩

4. naturally the nitpicking example here is if the Gulf of America is the same thing as the Gulf of Mexico. ↩

5. For an overview of OSMs data model see osm.wiki/Elements ↩

6. Overpass permanent ids directly use such a mechanism to link to OSM elements: osm.wiki/Overpass_API/Permanent_ID. ↩

7. Overture bridge tables do exactly that for GERS to OSM data mapping. ↩

8. Linear features are modelled as Ways that contain references to Nodes that contain the actual location, moving a child Node changes its coordinates and version, but as it is only referenced by the Way object this, as a convention, doesn’t change the Way version. Areas can be modelled in 3 different way, but relevant for this discussion are really only simple polygons that are closed Ways (that is start and end Node are the same) and multi-polygons that are modelled using Relations with individual Ways either directly closed or building closed rings. ↩

9. How well this works depends on how stale the data is when you create the mapping, a better approach would likely be to use the timestamp of the most recent child element. ↩

10. For Ways this implies simply inspecting the child Nodes. For Relations this depends on the specific type, for the most relevant multi-polygons, the members are Ways and you would need to check against the Way and child Node timestamps. ↩

11. I didn’t address the topic of ids for streets and similar objects at all, this would seem to have even less utility than for the discussed objects and you would likely be better off by simply using linear referencing. I might expand on this is a separate posting. ↩

Today I received an invitation to attend the bi-monthly OSM US Maintainers Working Group.

But due to timezone difficulties, I don’t think I’ll be able to attend it live.

The meeting agenda has been shared, mainly focusing on the topic of standards and interoperability. There are some interesting starter questions there, so I’m intrigued to answer those questions in an OSM diary instead, hoping that I’ll be able to join the discussion asynchronously.

So, here we go :

“What standards (geospatial file or data formats, metadata schemas, wire protocols, structured text formats, encodings, etc.) does your project depend on or interact with?”

I frequently use GeoJSON format in several of my projects.

“Are there any standards that you wish would be evolved/extended but aren’t actively maintained? Or implementations that aren’t fully compliant that you wish would be?”

GeoJSON fits pretty much all of my required use cases. My only concern right now is how to make GeoJSON files more compact. I haven’t researched much about this since there’s currently no urgent performance issue that needs to be handled, but I love tweaking my apps for performance.

“Are there standard formats or protocols that you would like to use, but aren’t well supported in your language/ecosystem?”

The General Transit Feed Specification.

I’ve been interested in this data format for a long time, but I still don’t know how to properly tinker with it. Last time I worked on this, I had to make my own Python implementation to read and navigate GTFS files. I don’t know what the current situation is right now. Maybe it’s already supported, maybe not.

“What are your thoughts on Overture’s OGC proposal?”

I already posted my thoughts in a certain Slack thread somewhere. Here’s the verbatim quote:

“Does an OGC standard become legally binding worldwide or something?

I’ve been thinking for quite some time about the idea of having a single global geographic identifier for every place. Ideally, any online content that refers to a location — whether a blog post, tweet, video, or photo — would include that global GeoID so it could be reverse-searched more effectively, such as finding every piece of content that references a specific place. For now, I use OpenStreetMap node, way, or relation IDs as links whenever I mention a place as a rough workaround, but I still hope that vision could be developed further.”

“What role do you think maintainers in the OSM community should play in giving feedback on or submitting standards to formal bodies like OGC?”

I guess maintainers would only care about standards if those standards personally affect their lives (their projects depend on them).

One day, a certain still-popular web APIs were unilaterally deprecated by a certain majority market-share holder browser company. Several maintainers (me included) staged a protest on their mailing list, practically begging them not to cut our collective lifeline. A representative from that company personally told me a quick fix on how to navigate that situation, and I’ve been using that quick fix for years. I don’t know the rest of the story, but if my app is occasionally broken without a clear reason, I suspect that quick fix is no longer enough to resolve the deprecation issue. That was the last time I participated in a “standardization” discussion.

“Anything new with your project(s) you’d like to share?”

Not exactly my project per se, but several weeks ago I saw someone in an OSM diary who recommended SCEE as one of the best available OSM editors on mobile. So lately, I’ve tried doing field mapping with SCEE.

They were right, it’s so good.

But somehow preset tags are still missing (I can’t add ATM, recycling center, or power pole yet). I don’t know how to add new preset tags to the app. Is there a hidden menu somewhere, or should we make a pull request to the repository? I’m now quite interested in this topic.

Finished adding villages in Nagqu City with Tibetan names listed in the Place Names Database KNAB and having a Q-id in wikidata; I’m continuing with Ngari Prefecture.

Place names in Tibetan script are viewable using maps.wikimedia.org with lang parameter set to bo.

Salut,

J’ai beaucoup édité OSM vers le milieu de l’année 2025. Maintenant, j’ai décidé de revenir!

Je vais peut-être travailler davantage sur l’Australie, et peut-être aussi sur la France, la Tchéquie, et d’autres endroits.

Tonight I finished mapping Maud, meaning the bulk of Fairview California is mapped. There are still some places along Fairview Avenue as it goes around in a circle and becomes Hayward but this is area shared by Hayward, Castro Valley and Fairview.

It feels so good to see my home there and recognizable.

I started this project in earnest on November 18th (although I did my own street back in June).

Proposal for Tagging Detector‑Operated Pedestrian Signals in OSM

Author: Derlamaer
Date: 18 February 2026

Introduction

I’m new to OSM and to cartography in general, so please excuse any imperfections in this post. As I’ve been mapping my surroundings, I noticed a gap in how we describe certain modern pedestrian crossings, and I would like to propose a way to fill it.

More and more signal‑controlled pedestrian crossings are equipped with automatic presence detectors. These sensors detect a pedestrian (or sometimes a vehicle) and trigger the traffic signal phase without requiring a push button. This behaviour is common in newer installations, but OSM’s tagging does not yet have a clear, standard way to capture it.

This diary entry describes the situation, proposes a tag, and invites feedback.

Current OSM Tagging for Signalised Crossings

Today, a typical signalised pedestrian crossing in OSM is tagged as:

highway=crossing
crossing=traffic_signals

To refine this, the OSM Wiki documents a couple of useful additional keys:

button_operated=yes/no Indicates whether a pedestrian must press a button to request the green signal.

traffic_signals:sound=yes/no Indicates the presence of an acoustic signal for visually impaired users. (See the wiki page for crossing=traffic_signals for details .)

However, there is no widely documented, standard key that says:

“This traffic signal is triggered automatically by a detector, with no need for a push‑button.”

That is the missing piece I am trying to address.

Real‑World Example (Toulouse, France)

One concrete example can be found in Toulouse, France, where several pedestrian crossings use overhead or roadside sensors (camera, infrared, radar or similar) to detect pedestrians as they approach the kerb.

A representative location is shown on Google Street View (link as used in the forum post). In such setups:

There is no button (or the button is optional). *A presence detector starts the pedestrian phase automatically. *This strongly affects how the crossing behaves for pedestrians and vehicles, and is therefore relevant for routing, accessibility, and safety analysis.

What I Initially Wanted: A New Key

My first thought was to introduce a simple, descriptive key:

detector_operated

Suggested values *yes – the crossing’s traffic signals are activated by an automatic presence detector. *no – there is no detector; the crossing is not automatically triggered this way (typically a button is required). Example usage:

highway=crossing
crossing=traffic_signals
button_operated=no
detector_operated=yes

This combination would explicitly describe a crossing where:

*The pedestrian does not have to press a button. *The signal phase is triggered automatically by a detector.

Why This Distinction Matters

Explicitly capturing detector‑operated signals in OSM would bring several benefits:

Accessibility and convenience

People with reduced mobility, small children, or those pushing strollers or wheelchairs may not find it easy to reach or operate a button. Automatically triggered crossings are easier and safer to use, and routers or accessibility tools could prioritise such crossings. Better routing and user expectations

Pedestrian and multimodal routers could distinguish between: crossings that require waiting for a button press, and crossings that react automatically to presence. This can influence estimated waiting times and route attractiveness. Traffic modelling and safety analysis

Transport planners and researchers using OSM data could more accurately model: where “smart” crossings exist, how traffic phases are activated, and the potential safety benefits of detector‑based systems. Consistency with existing tags

detector_operated would sit naturally beside: button_operated= traffic_signals:sound= Together, these describe how a crossing is activated and perceived, without conflicting with current conventions.

Community Feedback: The Existing traffic_signals:detector Key

After publishing the idea, I learned (via the Community Forum discussion) that OSM already has a key in use that represents essentially the same concept:

traffic_signals:detector

A fellow mapper pointed out that:

traffic_signals:detector is already in active use. According to Taginfo, it has values such as: yes (used >100 times) remote_sensing (dozens of uses) The key is not yet well documented on the wiki, but is clearly in real‑world use across multiple users [1]. The conclusion from that discussion was that introducing a completely new key is unnecessary. Instead, the best path forward is:

Use the existing traffic_signals:detector key. Document it properly on the wiki. Encourage consistent values to cover detector‑operated signals.

Recommended Tagging Based on the Outcome

Rather than detector_operated=*, the community feedback suggests we should do this:

Basic case: generic detector

highway=crossing
crossing=traffic_signals
button_operated=no
traffic_signals:detector=yes

This tells data consumers:

There is a traffic‑signalised crossing. No button is needed (button_operated=no). A detector triggers the signals (traffic_signals:detector=yes). More specific case: remote or automatic sensing Based on current Taginfo usage, a refined value could be:

highway=crossing
crossing=traffic_signals
button_operated=no
traffic_signals:detector=remote_sensing

This expresses that:

The detector operates at a distance (camera, IR, radar, etc.), not just a simple loop or push button. Over time, the community could standardise a small, clear set of values under traffic_signals:detector=* for common detector types, such as:

yes – some form of detector is present (generic). remote_sensing – non‑contact sensor like video, infrared, or radar. induction_loop – vehicle loop detector (if needed for some installations). The key point is that the existing key can already represent “detector‑operated” behaviour without creating new, parallel tagging.

Die Strasse L170 von Göschweiler hört bei Schattenmühle auf. Diese sollte meiner Meinung nach weitergehen bis zur Strassenmündung K6516. Ich bin nicht zu 100% sicher, kann das jemand überprüfen und gegebenenfalls korrigieren.

Une petite investigation pour évaluer l’actualité de notre carte. Voici deux cartes:

• cinémas de Genève
• anciens cinémas de Genève et actuels

Cinémas ouverts

Cinémas fermés

• Auditorium Arditi (Cinéma Manhattan)
• Cinéma Plaza
• Cinéma ABC/Les Arcades
• Cinéma Alhambra
• Cinéma Broadway
• Cinéma Grottes
• Cinéma Hollywood
• Cinéma Splendid
• Cinéma La Strada

Changements

Trois nouveaux:

• Blue Cinema (à la place des Rex, Confédération Centre)
• CinéTransat (en plein air, juillet/août, Parc de la Perle-du-Lac)
• Allianz Cinema (en plein air, juillet/août, Port Noir)

Deux fermés:

• Cinéma Central
• Dreamscape VR

Changement de nom:

• Ciné 17 (a retrouvé son nom, “Astor Film Lounge” pendant un temps)

“Temporairement” fermé pour travaux ou autre:

• Auditorium Arditi (Manhattan)
• Plaza (manquait)

Comme les salles persistent souvent, on peut aussi trouver certains anciens:

• Cinéma Hollywood
• Cinéma Broadway
• Cinéma Splendid etc.

Clés OSM utilisées

En principe, il devrait y avoir:

• amenity=cinema
• name
• addr:* addr:floor, addr:housename, addr:street, addr:housenumber, addr:postcode, addr:city, addr:country
• website
• operator
• operator:ref:CH:UID
• ref:CH-GE:REG

Parfois:

• screen
• capacity:person
• wheelchair:url
• architect
• old_name
• start_date

Pour le cinémas open-air:

• opening_hours avec Jul-Aug:
• seasonal=yes
• indoor=no
• outdoor=yes
• open_air=yes
• drive_in=no

Certains ont saisi:

• opening_hours (sauf pour les open-air, ça me semble pas utile)
• payment:*
• email
• phone

Reste à faire

D’autres salles de projection et anciens cinémas pourraient certainement être rajoutés.

Entrées à vérifier/compléter:

• CDD
• Fonction:Cinéma

Le contenu de la clé opening_hours devrait être normalisé ou supprimé. On pourrait se contenter de Mo-Su "30 minutes avant les séances". J’ignore quelles applications invitent les mappers de le compléter.

Les éléments suivants manquent parfois:

• screen
• capacity:person
• architect
• start_date

From the Build Plan developed with Claude

Project Purpose A web application enabling mappers and data quality analysts to select a geographic area, fetch Overture Maps POI data and OpenStreetMap data in parallel, algorithmically compare them, and produce two outputs: a reviewed, selective upload to OSM via OAuth2, and an annotated GeoJSON export classifying each Overture POI by assessment category.

No edits to OSM happen without manual review. Overture is more of an attention guide (at least that’s my hypothesis)

Here’s the chat

Lots of UX fine tuning to come. Quick observations:

• Overture is very noisy, lots that is irrelevant (business mailing addresses in personal houses, mislocated POIs, closed places, duplications with differences across Meta/Microsoft/4SQ sources)
• Matching is hard but can be improved
• There is useful signal in Overture, places that need addition to OSM in new developments, but you have to have means to easily sort through and keep a record.

I’m going to work on refining the workflow, add means to link features across Overture, ability to not just add but adjust OSM features, audit trail so it’s possible to share reviews and apply reviews against new releases….

In May 2025, the OpenStreetMap (OSM) website introduced two optional fields in public user profiles: company and location (see Github). Both fields accept unstructured free text and are not validated in any way. Since these fields are publicly visible, I wondered whether they could be useful for my “How Did You Contribute to OpenStreetMap?” (HDYC) page, particularly for identifying organized (paid) mappers. Some more background information about organized editing can be found on the OSM Wiki. According to the wiki, contributors involved in organized editing projects should be documented there and should ideally include a short description in their OSM user profile. This information is currently one of the signals used by HDYC to mark or flag potential paid editing accounts. Until now, I have relied on a semi-automated script that detects paid contributors based on text patterns found in OSM user profile descriptions. This works reasonably well for larger technology companies such as Apple, Amazon, or Meta, where contributors often mention their employer directly in their profile text. The newly introduced company and location fields therefore looked like interesting candidates for a small data quality and content analysis. The goal was to evaluate whether these fields could serve as an alternative or complementary signal to my existing semi-automated detection approach.

Data Collection and Analysis
The internally maintained OSM user profile dataset used by my services is updated daily for all contributors who have been active within the last 24 hours. For this analysis, I evaluated approximately 66,000 OSM user profiles. These profiles belong to users who:

• have been active since May 2025
• have mapped on at least three distinct days
• have created at least three changesets

Usage of the Company and Location Fields
A simple aggregation grouped by company and location provides an initial overview of how these fields are used. By the end of January 2026, only a relatively small number of users had filled the company field. In total, around 1,000 distinct company names were identified, although some entries likely represent spam or low-quality data. The “small numbers” here refer not to the number of companies themselves, but to the number of users associated with each company entry. Interestingly, large technology companies still appear to rely primarily on the free-text profile description rather than the dedicated company field. The location field provides slightly more interesting insights. Most users appear to enter their country name, although other formats also appear. By the end of January 2026, around 2,200 unique location values could be identified.

Conclusion
At the moment, my conclusion is that I will probably not use these fields for HDYC. The HDYC profiles currently contain, in my opinion, more reliable signals derived directly from collected and analyzed contribution data rather than from self-declared free-text profile fields. While working on HDYC improvements, I also implemented another feature that has been on my wish list for quite some time: username history. Inspired by the “Who’s That?” page, I finally implemented my own username history feature. The information is derived from the complete minutely changeset replication history. However, I am not fully satisfied with the current presentation. The feature may not work equally well for all users, especially for accounts with a long change history. I would therefore appreciate some feedback. Which option would you prefer?

1. Move the username section further down the page
2. Add a time-based filter (for example showing only the last 3–5 years or 10 years)
3. Remove it – I don’t find it useful

If you prefer, you can also leave feedback on my OSM diary here.

In May 2025 the OSM website introduced two new optional fields in user profiles: company and location. I recently analyzed whether these fields could be useful for detecting organized (paid) editing accounts for my How Did You Contribute (HDYC) pages. Short summary:

• Around 66k active user profiles analyzed
• About 1,000 unique company entries
• About 2,200 location values

Interestingly, large companies such as Apple, Amazon, or Meta still mostly appear in the profile description, not in the dedicated company field. I wrote a more detailed blog post here.

While working on this analysis I also added username history to HDYC, derived from the full changeset replication history. I am not fully happy with the current presentation and would appreciate feedback:

1. Move the username section further down?
2. Add a time-based filter (e.g. last 5–10 years)?
3. Remove it.