Pour la première fois, fin août 2026, la France accueillait le State Of The Map Monde, la réunion annuelle de la communauté OpenStreetMap, dans les locaux de l’Ecole Géodata Paris, temple français de la géomatique. Comme plusieurs membres de Mapadour, LaNum Pays Basque était présente parmi les 535 participant⋅es venant de 45 pays.

Comment résumer les plus de 180 conférences, ateliers, démonstrations qui ont illustré ce qu’il est possible de faire avec les données OSM ?

Nous partageons les 5 faits qui nous ont le plus marqué pendant ces 3 jours.

1. Des acteurs industriels de la tech valorisent la communauté OSM

A une époque où plusieurs événements tech connaissent des difficultés, les SOTM sont soutenus chaque année par des entreprises comme Michelin, TomTom, esri, Thales, Capgemini démontrant l’intérêt de ces groupes.

Deux géants de la tech américaine Amazon et Fastly font des donations techniques pour permettre le téléchargement mensuel :

• de 394 Térabytes de données ;
• de 1,7 Pétabytes de fonds de carte ;
• des 1,6 milliard de requêtes sur le site web mondial.

En 2020, Accenture avait valorisé la base de données OSM à plus d’1,6 milliards de dollars.

2. Des organisations intègrent OSM dans leurs stratégies

L’IGN collabore avec la communauté OSM pour créer Panoramax, intègre ses données dans son application phare cartes.gouv.fr et institue une « démarche géocommuns ».

Le SOTM a permis à des acteurs de la mobilité comme la SNCF, Ile-de-France Mobilité ou Géovélo de témoigner de leurs contribution dans OSM pour déployer des services numériques performants.

Digitaleo, qui opère une plateforme de marketing local pour gérer la présence numérique de plus de 14 000 points de vente en France, est venu expliquer que la communauté OSM connaissait mieux le territoire que ses clients et s’appuyait sur elle pour améliorer ses services.

3. L’engagement et les compétences de la communauté OSM

Cette confiance provient de la nature même de la communauté OSM. En France, elle a fait l’objet de deux études à 8 ans d’intervalle (2016 et 2024). Retenons qu’elle est composée à 81% d’hommes, en majorité très diplômés (76% bac+3 et plus) en informatique et en géomatique.

Déformation professionnelle sans doute, les contributeur⋅rices sont très précis⋅es et très engagé⋅es dans la qualité de leurs contributions, ils/elles prennent un soin important à le faire. Les discussions que nous avons eu avec les différent⋅es participant⋅es confirment cette impression.

4. Le modèle de gouvernance d’OSM garantit la souveraineté des données

Sébastien Soriano, directeur de l’IGN est intervenu pour défendre une vision de la souveraineté numérique basée sur la collaboration. Si un acteur public souhaite être souverain, il a deux choix possibles : soit tout contrôler, soit faire en sorte que personne ne contrôle tout.

C’est ce modèle de gouvernance distribuée qu’il a plébiscitée et elle prend tout son sens à l’heure où le président Trump décide de débaptiser le lac Ontario en lac d’Amérique. Google suit dans la foulée tandis que la communauté OSM débat librement et cherche un consensus entre contributeur⋅rices.

5. Les IA submergent les services d’OSM

Grant Slater, Senior Site Reliability Engineer (SRE) de la Fondation OpenStreetMap, a réalisé une présentation très éclairante sur les dégâts réalisés par les sociétés éditrices de solutions d’IA pour les services ouverts et partageurs comme OSM.

Les robots d’indexation de ces sociétés collectent massivement les contenus OSM (site web, le wiki, les listes de diffusion) car ils sont gratuits et de qualité. Ils le font d’une manière particulièrement violente et de façon anonyme pour ne pas être filtrés. La Fondation Wikimédia en est aussi victime.

Concrètement, il en résulte une augmentation du trafic et une consommation énorme et continue sur les serveurs de la Fondation qui ne peuvent plus suivre la cadence et dégradent ses services. De plus, les IA favorisent la création de faux comptes OSM (400 par jours) pour augmenter artificiellement la visibilité de pages web commerciales ou produire du spam.

Pour aller plus loin

De très nombreux autres sujets ont été abordés pendant ces 3 jours, la plupart des interventions ont été filmées et diffusées sur la chaine Peertube d’OSM France. Bien qu’en langue anglaise, elles sont toute de même accessible grâce à l’option sous-titres traduits en français.

D’autres contributeur⋅rices ont produit des comptes-rendus du SOTM de Paris :

• Stéphane Branquart : State of the Map Monde 2026 : les Communs Numériques font la preuve de leur efficience
• Juminet : My State of the Map 2026
• Rphyrin : State of the Map 2026 (Day 1 – Part 1) – State of the Map 2026 (Day 1 – Part 2)
• samuel_geovelo : State of the Map Paris 2026: OpenStreetMap is scaling up
• Raquel Dezidério Souto : My participation in the State of the Map 2026 / Minha participação no State of the Map 2026
• Christoph Hormann : State of the Map 2026 impressions

https://gis.epa.ie/EPAMaps/

Whether you are from, Saint-Louis-du-Ha! Ha!, Springfield or Ea names are important. They help us identify where we are, where we are from and where we want to go to.

Almost everything has a name and OpenStreetMap volunteers have mapped 115 million names.

Local name of features on www.openstreetmap.org

In OpenStreetMap, the verbal identifier with which people refer to something is documented by the name= tag. This usually is the most common name in the local language and is the most obvious name of the feature. For example, if you are in France and map a road called “Rue des Beaux-Arts”, you add name=Rue des Beaux-Arts so that everyone knows what that road is called.

There are many map styles based on OpenStreetMap data. On www.openstreetmap.org, we display “osm-carto” style by default, with a layer switcher for many others.

There are a few simple rules that the OpenStreetMap community follows, including:

• name= is typically the commonly used name in the local language. A street in Paris has as name= its French name, not the name in English.
• name= should be verifiable.
• name= should be a proper name – not a description or a reference id.

The recording of names is a complex issue, but these are the main rules we use.

The OpenStreetMap community tries to ensure that the name= tags in the OpenStreetMap database are correct, for mapped features with names such as shops, places, streets, lakes or even oceans.

Additional names of features on www.openstreetmap.org

In addition to the local name, set by name=, objects in OpenStreetMap very often have one or more names. Such additional names are classified by their function – how they are used in contrast to the local name, or what purpose they serve for data users. We can store old names, local names, official names, and alternative names.

Both local and other name keys can also be suffixed with a language code. If you want to add a name in another language, you use a separate tag like name:en= for English or name:fr= for French, and leave the name= tag in the local language. The ISO language code system we use allows more details, such as the writing system used, or even the region and dialect. The English spoke in Britain isn’t the same as that spoken in Australia.

Therefore, the OpenStreetMap database contains features with multiple names.

On the default layer of the www.openstreetmap.org website (osm-carto) we don’t show different names based on where you are, this means everyone will see the name of the feature in the local language. It’s important that the website has a layer where this is the case. This is mostly a technical reason.

While only name= is displayed on the default layer of www.openstreetmap.org, there are additional layers on the website and there is ongoing work on the new Vector layer to show names in your local language, but more about that in a later post. There are other map styles showing names only in German, or only in English.

One database – unlimited maps: create the map you want

It is important to note that OpenStreetMap data is offered to everyone for free, under the ODbL licence, and used for any purpose – including commercial usage.

It is possible to produce your own maps which, for example, show only a subset of the mapped names or features. The www.openstreetmap.org website’s main purpose is to facilitate OpenStreetMap mappers and not to be a single map for every use. OpenStreetMap data is used by individuals, big companies, game companies, grassroot organisations, governmental agencies, humanitarian groups and many others and the data can be used to create unlimited maps and for other purposes.

What about official names?

Mostly the official name will match the commonly used name of a feature. Sometimes people will continue to use the original name, so our name tag will stay. We can store the official names of mapped features when different, in the official_name= tag

In cases like the executive order related to Lake Ontario, it’s not unusual that there will be a community discussion and in this case the tag official_name:en-US=Lake America has been added to the lake on OpenStreetMap, to record the new official en-US name. The primary name of the lake remains the same. Since a lot of people still use the name “Lake Ontario” we keep it as name. The addition of the official_name:en-US=Lake America name means that anyone searching for Lake America on www.openstreetmap.org and apps/services using OpenStreetMap data which have all the feature names, will find Lake Ontario.

The Name of the Game

OpenStreetMap’s flexible data model means that if you want to show a map, with certain names, or certain langauges, we provide a world-wide freely-usable database for you to use. Just adjust your map style to prefer one name tag over another, and you’ll automatically get the map you want.

OpenStreetMap’s community base, and non-commerical freedom, international project structure, and “on the ground rule” means that if you use the name tag, then the names on the map will be based on what people are actually using.

When it comes to maps, OpenStreetMap is the only name in town!

Today I ran across an article about Vienna’s Globe Museum.

That reminded me I’ve never been to Vienna before. Now I definitely need to go: Looking at old maps is an aesthetic experience, and it’s a great way to see how politics, wars and peace have passed.

And when I go, I might as well extend the trip in a south-east direction and visit another city where I haven’t been before: Bucharest in Romania, because they have a museum of old maps.

What do you think – are there other places I should put on my bucket list of destinations which are interesting for folks interested in maps and mapping?

03/09/2026-09/09/2026

Mapping

• Voting has started on the lgbtq=* proposal and is open until and including 19 September.

Mapping campaigns

• In a talk at State of the Map 2026, Enock Seth Nyamador explained how massive mapathon campaigns carried out by paid mappers affiliated with large companies or organisations could potentially ‘kill’ the OpenStreetMap movement in Ghana.

Community

• [1] The editors at weeklyOSM don’t just collect and write articles to keep you as well informed as possible about the OSM universe; they also map , some with such great success. We would like to offer our warmest congratulations to @ediyes, from our Spanish team, on this achievement! With her Peruvian team , Edith came second , behind the Guatemalan team .
• rphyrin explained the situation around Jakarta following the recent Anak Krakatau eruption, while showing how OpenStreetMap data is being used in an early warning system to alert people about the areas expected to be affected by volcanic ash. Anak Krakatau, meaning ‘child of Krakatau’, is an active volcano in the Sunda Strait between Java and Sumatra that emerged from the caldera left by the catastrophic 1883 Krakatau eruption, which killed an estimated 35,000 people.

Local chapter news

• Katja Haferkorn reported ► that the FOSSGIS e.V. networking meeting took place on 2 September, with 25 participants joining the online networking platform. The next networking meeting will be held on 9 December 2026.

Events

• Are you a Stadia Maps customer? They just announced that they’re sponsoring local meet-ups to align with their core values of providing fair, transparent treatment for developers.
• Christoph Hormann shared a general commentary on the State of the Map 2026 conference in Paris, which he had recently attended.
• State of the Map Asia 2026 was held in Osaka, Japan, on 6 and 7 September.

OSM research

• Maurizio Napolitano wrote ► about ‘Stress in bici’, an experimental map based on OpenStreetMap that shows bicycle routes in Italy, colour-coded according to stress level. The development of the platform is also described in a research paper, ‘TS-BikePlan: A Data-Driven Tool for Enhancing Cycling Infrastructure and Safety’, published in the Journal of Urban Technology .
• Giuliano Cornacchia et al. have studied the recommended routes given by software navigation services and found out that as adoption increases, route diversity declines. Further, traffic and emissions converge onto fewer roads leading to lesser benefits (which eventually turn negative over a certain threshold) in terms of CO₂ emissions and traffic load. For the purposes of this study, the road networks were sourced from OpenStreetMap.
• The OSM Road Monitor team presented their work at SotM 2026 in Paris. By combining community-driven mapping with independent Earth observation data, the project aims to support more reliable and timely road information.

Maps

• Continuing the discussion around the recent UN shift from the Mercator to the Equal Earth projection, the OpenStreetMap community on Reddit has started discussing whether OSM should make the switch as well. Meanwhile, back in 2025, also prompted by a discussion about OSM map projections, Andy Townsend had already shown us that anyone can render OSM data in whatever projection they want.
• Mathias has published a map, ‘Polizeikarte’ , which brings together public press releases from German police authorities. It shows around 63,600 incidents from 260 locations across 14 federal states. Geocoding is handled by Nominatim, whilst the visualisation is provided by MapLibre GL JS using tiles from OpenFreeMap. Official reference layers can be overlaid, such as the accident atlas from the statistical offices, which contains 585,815 accidents from 2018 to 2025. The project is non-commercial and is not affiliated with any public authority.

Open Data

• Iconem has recently updated terrain-viewer, an app made to ingest, style, and render open-data terrain-sources for relief visualisation, feature detection, and mapping! They’re using it to detect archaeological sites, and there is some overlap with mapping landmarks within OSM from terrain sources, whether public worldwide like Mapterhorn, or national, since the tool can ingest custom national mapping agencies data sources.

Software

• Stadia Maps explained the distinction between forward geocoding and reverse geocoding and how choosing the right endpoint and parameters can make a big difference for any application.
• Strongly motivated by the urge to avoid getting a speeding ticket, Moonshot Studios GmbH have developed YouSpeed, a mobile intelligent speed-assistance app powered by OpenStreetMap speed-limit tags, area context, and daily diffs. Other apps of Moonshot Studios include Woladen (where to charge your electric car) and Tankzeit (best time to fuel up your car).
• rphyrin has made ‘ivebeen_here’, a platform for OSM users to share their personal stories about particular places.

Programming

• Agasta08 published the full report for their 2026 Google Summer of Code project, ‘Category Support in Nominatim’, thanking mentors Sarah Hoffmann and Marc Tobias, as well as OpenCage for sponsoring the development server used for the planet-scale database setup. Agasta explained how the category model has been implemented in Nominatim.
• Inspired by a discussion at the recent State of the Map, rphyrin tried out ‘Photon‘, an open-source geocoder built for OpenStreetMap data, and built a custom front end that allows users to copy the coordinates of search results.

Releases

• OsmAnd released version 5.4 for iOS with a redesigned My Places interface, a rebuilt Plan a Route tool, and a new Astronomy plugin. The Android release came with a refreshed Search UI, the ability to attach media to Favorites, and 3D Buildings with roof shapes.
• Altilunium LocationPad v26.9.5 has been released – a web app for marking, labeling, and revisiting places on an OpenStreetMap-based map.
• Sourtest v26.9.6 has been released.
• The August 2026 release of Organic Maps has been released, introducing several new features, including multi-selection for bookmarks and tracks, a CarPlay dashboard, the ability to hide tracks on the map, and more readable share links.

Did you know that …

• … the recent ChatGPT update can now show OpenStreetMap-based map data based on your chat query, complete with proper OpenStreetMap attribution?

OSM in the media

• Brian Bergstrom has launched Dulcet GIS, a podcast about cartography and civic mapping. The first episode covers the UN General Assembly’s adoption of the Equal Earth projection and sets it alongside the executive order renaming Lake Ontario, noting that OpenStreetMap was the only major map that did not change the name. The episode explained the on the ground rule and how disputed names are handled in the data model, and closed by pointing listeners to OSM-based apps and to the Humanitarian OpenStreetMap Team.
• The latest event of the Ingolstadt Citizens’ Network was held ► on Sunday 6 September, focusing on the theme ‘Navigation using OpenStreetMap data’. The event demonstrated how OpenStreetMap can be used in everyday life, which apps are based on it, and how people can contribute to improving the maps themselves. The event was free and open to everyone, with no prior knowledge required.

Other “geo” things

• The United Nations General Assembly has voted by an overwhelming majority in favour of adopting a world map based on the 2018 Equal Earth projection, which more accurately reflects the actual size of countries and continents, moving away from the Mercator projection. In New York, 164 states voted in favour of the resolution, which was sponsored by Togo and backed by the African Union. The United States was the only country to vote against ► it, describing the initiative as an ‘ideological agenda’. Six countries abstained.
• Scientists, led by space physicist Endawoke Yizengaw of The Aerospace Corporation in the US, have discovered that the solar flares of 11 November 2025 caused widespread, coast-to-coast disturbances in the atmosphere across the continental US. The disturbances could potentially throw GNSS positioning off by more than 10 metres in some places, the researchers say, significant enough to disrupt precision agriculture and autonomous vehicles.
• After announcing that Lake Ontario would continue to be called that on their maps, the MapQuest app went to number one for navigation on the iOS App Store in the US.
• Maggie Downs, of the BBC, visited Vienna’s Globe Museum, the only public museum in the world dedicated entirely to globes.
• Oliver Bünte, of Heise, reported that the US Department of Defense’s Defense Innovation Unit has tested a quantum sensor-based flight navigation system over the Pacific that allows an aircraft’s position to be determined precisely without relying on GNSS. Instead of relying on signals from navigation satellites, the system detects changes in the Earth’s natural magnetic field and creates a magnetic field map from these measurements. Based on this map, the system can determine an aircraft’s position entirely independently of GNSS signals, weather, and visibility conditions.

Upcoming Events

Country	Where	Venue	What	When
	København	Cafe Bevar’s	OSMmapperCPH	2026-09-13
	Greater London	1 Cabot Square, 7th Floor, Canary Wharf E14 4QJ	EAW Volunteering Event	2026-09-14
			CartONG : Mapathons en ligne 2026-2027	2026-09-14
	Madrid	Online	Mappy Hour OSM España	2026-09-15
			Missing Maps London Mid-Month for Advanced Mappers (no training provided) (Online) [eng]	2026-09-15
	San Francisco	Near BART 24th St. Mission station	Bay Area WikiSalon	2026-09-15
	Lyon	Tubà	Réunion du groupe local de Lyon	2026-09-15
	Bonn	Dotty’s	204. OSM-Stammtisch Bonn	2026-09-15
	Chemnitz	Kaffeesatz, Chemnitz	OSM-Stammtisch Chemnitz	2026-09-15
	Stainach-Pürgg	Online	22. Österreichischer OSM-Stammtisch (online)	2026-09-15
	San Jose	Online	South Bay Map Night	2026-09-15
		Online	Lüneburger Mappertreffen (online)	2026-09-15
	St. Gallen	Rosenbergstrasse 59, 9000 St.Gallen	Map The Climate! Ein Mapathon	2026-09-16
		MJC de vienne	Réunion du groupe local de Vienne	2026-09-16
	Köln	Lokal K, Hackländer Straße 2, Köln-Ehrenfeld	OSM Stammtisch Köln	2026-09-16
	Nantes		COntrib’atelier	2026-09-16
	San Francisco	Et al.	A Synesthete’s Atlas: Cartographic Improvisations Between Eric Theise, Gusty Winds May Exist, Ron Heglin, and Petra Zélie	2026-09-16
	Karlsruhe	Schwarzer Kater	Stammtisch Karlsruhe	2026-09-16
	Kiel	Kieler Innovations- und Technologiezentrum	OSM auf der Kielux 2026	2026-09-18 – 2026-09-19
			OSMF Engineering Working Group meeting	2026-09-18
	Catania	Centro Atena, via Fimia 34, 95128 Catania (CT)	Modifichiamo Wiki e OSM insieme! – Catania	2026-09-18
	Mumbai	Lokhandwala Garden, Andheri	OSM Mumbai Mapping Party No.14 (Andheri)	2026-09-19
	Delhi	Too Mikkii Tapas, South Extension	OSM Delhi Mapping Party No.31 (South Extension)	2026-09-20
	Madrid	Online	Mappy Hour OSM España	2026-09-22
	Derby	The Brunswick, Railway Terrace, Derby	East Midlands pub meet-up	2026-09-22
	Berlin	Online	OSM-Verkehrswende #79	2026-09-22
	Catania	Piazza Roma, Catania (Punto di incontro)	Mappiamo le piste ciclabili – Catania	2026-09-22
	Nantes	Le Wagon Nantes	OpenStreetMap, la carte à la carte !	2026-09-23
	Hannover	Kuriosum	Stammtisch	2026-09-23
	Würzburg	FabLab Würzburg	Würzburger OSM-Treffen	2026-09-23
	City of Westminster	Blue Posts pub	London pub meet-up	2026-09-23
			Pravidelný Missing Maps CZ-SK online Mapathon	2026-09-24
		100% online	Lançamento de livros sobre mapeamento colaborativo	2026-09-24
	Freiburg im Breisgau	CCCFR, Adlerstr. 12 a, Freiburg/Br.	OSM-Treffen Freiburg/Br.	2026-09-24
	Bengaluru	NIMHANS Convention Center	OSM India @ IndiaFOSS 2026	2026-09-25 – 2026-09-27
			UN Mappers Mappy Hour	2026-09-25
	Torreón	Universidad Tecnológica de Torreón	Conferencia “OpenStreetMap: Datos abiertos y más”	2026-09-25
	Torreón	Universidad Tecnológica de Torreón	Taller “Mapeando mi entorno”	2026-09-25
	Düsseldorf	Online bei https://meet.jit.si/OSM-DUS-2026	Düsseldorfer OpenStreetMap-Treffen (online)	2026-09-25
	Karlsruhe	Geofabrik, Amalienstraße 44, 76133 Karlsruhe	Karlsruhe Hack Weekend September 2026	2026-09-26 – 2026-09-27
	Nantes	Le Wagon Nantes	OpenStreetMap, la balade de la data	2026-09-26
			Sudan Solidarity Series	2026-09-26
	Uppsala	Datorföreningen Update	Mapping meetup in Uppsala	2026-09-27
			CartONG : Mapathons en ligne 2026-2027	2026-09-28

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

This weeklyOSM was produced by MarcoR, MatthiasMatthias, Rob Yoegel, Strubbl, Andrew Davidson, barefootstache, derFred, tkk.
We welcome link suggestions for the next issue via this form and look forward to your contributions.

Силка на наш телеграм канал t.me/Enduro_Travel_Help

Тиждень тому засновник EDR поставив ціль: привести в порядок околиці с. Бехи (20+ км), а також розпочати кампанію з повного позначення всього в межах 50 км від Коростеня. Мета кампанії — розвиток ендуро в Коростені. Карти OSM станом на 2025 рік приблизно на 25–30% неправильні в Коростенському районі в плані туристичних доріг (путівців тощо).За понад тиждень наша команда провела роботу майже над усіма точками даних OSM в радіусі 25 км від с. Бехи. Робота виконувалася в таких локаціях:С. Бехи та околиці (5+ км): додано річку Октасувака, а також додано й відредаговано путівці.С. Вороневе та околиці: додано житлову зону, кладовище, путівці, а також болота, ставки та лісові масиви.С. Немирівка: робота ще триває, але вже додано новозбудовану дорогу, а також видалено й відредаговано наявні путівці та дороги.Робота над двома дачними масивами: збільшено об’єм (русло) річки Уж на карті, додано кросову трасу. С. Васьковичі: також додали річку. Компанія з розвитку околиць с. Бехи триває. У планах до початку зими — повністю довести до ладу 50+ км околиць міста Коростень.

I maintain OSM Edit MCP, an MIT-licensed Python tool that connects an MCP-compatible AI assistant to an OpenStreetMap survey-review workflow. It is alpha software, and I would welcome feedback from mappers on its review steps and failure cases.

The workflow is: local GPX → selected segment → current/proposed geometry preview → explicit confirmation → changeset. The mapper chooses the surveyed section and the target road; the tool does not select a road or infer junctions automatically.

For production writes, the normal profile requires a separate confirmation in the MCP client bound to the exact proposal digest. It rechecks the OSM account and object versions before an atomic upload. These checks do not establish that a proposed edit is correct: GPS accuracy, topology, tagging, permitted sources and local knowledge still need human review. This is not a bulk-import or autonomous mapping tool.

Version 0.2.1 is available with uvx osm-edit-mcp. The README includes client configuration. Starting the server, analyzing a local GPX and previewing a selected segment need no OAuth. Preparing an account-bound road-edit proposal does require authentication, even before an upload. Start with read-only inspection and the separate OSM development API.

The server does not upload the GPX as an OSM trace. The newer nearby-discovery profile documented in the repository is still unreleased.

I am particularly interested in which topology warnings and before/after views you would need before trusting a proposal. OSM community, import and automated-edit policies still apply; per-edit confirmation is not a substitute for community consultation.

You've ridden the Transfagarasan three times now, and the story you tell afterward never changes: good climb, brutal hairpins, freezing at the top. Same three sentences, every time, because that's genuinely all a memory holds onto.

Your phone remembers more. It was recording the whole ride — every meter of elevation, every km/h, the exact spot where you stopped pretending you weren't struggling. None of that shows up in a photo. It shows up in the track, if you know how to ask it the right question.

Photo by Tiberiu Potec on Unsplash

Giving Color to Your Ride​

Standard monochromatic lines on a map tell you where you went, but they remain completely silent about how the ride actually felt. OsmAnd solves this by allowing you to color your tracks using real ride data — Speed, Altitude, or Slope.

Color transforms a flat line into a visual profile of your physical effort. A steep climb up the southern approach of the Fagaras Mountains shifts into warm, intense gradients, while steady valley roads cool down into gentle tones.

However, default track coloring relies on generalized scales that don't always capture the nuances of specific terrain or activity types. To give your map absolute visual accuracy, OsmAnd Pro includes the Color Palette Editor — an advanced tool available with an OsmAnd Pro subscription that gives you complete control over how data thresholds map to visual colors.

Relative vs. Fixed Values: Choosing the Right Scaling​

When creating or customizing a palette in the editor, you choose between two fundamentally different ways to interpret data.

Using a Relative palette, colors scale automatically based on the specific track's minimum, average, and maximum values. If your ride spans from 600 meters at the base to 2,034 meters at the Bălea Tunnel summit, the gradient stretches evenly across that exact range. This mode is ideal for isolated rides where you want the highest possible visual contrast across a single trip.

A Fixed Values palette operates differently by assigning colors to specific, absolute numbers, such as 10 km/h, 50 km/h, or exact elevation steps like 600 m, 1,200 m, and 2,000 m. The scale remains constant regardless of which track it is applied to. This approach is essential when comparing multiple rides or setting personal benchmarks, as 2,000 meters of elevation or a 10% slope gradient will always render in the exact same color across every track on your map.

Working with the Color Palette Editor​

Accessing the editor is seamlessly integrated into your track's appearance settings. Opening the track's Appearance menu, selecting a data-based color mode, and tapping the palette icon opens the All colors screen. Here, tapping the + button allows you to build a new palette in either Relative or Fixed Values format.

The editor provides an intuitive set of tools for fine-tuning your data visuals. At the top of the screen, a live gradient preview reflects your changes in real time as you adjust values. You can add new threshold steps using the + Add step button, assign custom colors, or remove unneeded steps to simplify the scale.

The editor also automatically respects your system profile settings, seamlessly displaying values in metric or imperial units — such as meters, feet, km/h, or mph — without disrupting your underlying color scales.

Mountain terrain frequently introduces data gaps. As you ride through the 900-meter Bălea Tunnel near the summit, GPS reception naturally drops. To handle these moments, the editor includes a dedicated No Data step, letting you assign a distinct, neutral color to track segments where logging was temporarily interrupted.

Managing your personal collection of palettes on the All colors screen is equally simple. Opening the three-dot menu next to any custom palette provides quick options to rename, edit, duplicate, or delete it whenever your preferences change.

Harmonizing Track and Terrain Colors​

A custom track palette works best when it stands out clearly against the underlying map background. If your elevation track uses deep red shades for high mountain peaks, those segments might blend into intense terrain contour lines or dark relief shading.

OsmAnd allows you to customize map background palettes as well, giving you the flexibility to adjust elevation and slope visualizations under Menu → Configure map → Terrain → Color scheme on Android, or Visualization on iOS. Selecting complementary terrain color scales keeps your track lines sharp and legible, whether you are navigating dense forest valleys or barren, high-altitude alpine passes. While custom palettes can be applied across various terrain layers, keep in mind that Hillshade relies on a fixed shading algorithm and operates independently of custom palettes.

Customize Your Map Experience​

Custom color palettes allow you to turn complex GPX data into clear, meaningful visual stories. Whether you are analyzing steep mountain passes or setting up standardized color scales for daily training routes, full control over your track visuals is right at your fingertips.

This feature is part of our latest release updates. Take a moment to explore our new release blog posts to discover all the new tools, optimizations, and features we've recently added to make your navigation experience even better!

We appreciate your interest in us and thank you for taking the time to read this article. Join us on social media to keep up to date with the latest news and share your experiences. Your opinion is important to us.

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

Fehlende Smootness-Daten

brouter könnte profitieren!

Wie soll brouter gute Rennrad-Tracks finden, wenn in OSM smoothness kaum gepflegt wird? Ein kleines Tool TagCoverage, welche ich geschrieben habe, zeigt, dass smoothness wenig gepflegt wird. In NRW sind gerade 8,6 % der erfassten Ways dafür dokumentiert! Natürlich gibt es Ausnahmen, in Köln gibt es deutlich höhere Werte, im Ortsteil Blumenberg sind es sogar 88,4 %! Berlin ist mit im Schnitt 37,3 % auch deutlich besser.

Abhilfe

Aber hier kann was getan werden, ich arbeite an einer App ACCoGPS, die georeferenzierte Vibrationsdaten per Handy am Fahrradlenker aufnimmt und diese über ein Backend aufbereitet und daraus saubere Smoothness-Daten ermittelt.

Beide Tools stelle ich am 16.9. beim OSM-Stammtisch in Köln kurz vor.

When OpenStreetMap put a slippy map on its front page on its front page in 2005 it used a Mercator map. This made excellent sense at the time: true north was at the top everywhere, angles were good (spherical Mercator less so than geoidal Mercator) and the raster tiles at then in use could be scrolled without spending computational power on changing their shape. Other maps at the time made the same decision for the same reasons.

Twenty years on desktop and even mobile processors can render vector tiles with consummate ease, keeping the labels in the right shape while they do so. The need to keep tiles the same shape has evaporated and many maps can be spun to put whichever direction the user wants at the top. But the disadvantages of Mercator remain: at small scales Canada and Greenland are exaggerated in size compared to Africa. At large scales this is more subtle, each zoom level maps Helsinki at a linear scale twice as large as Bogota with four times the area and shifting a zoom level doesn’t mix well with map styles that use the level to show differing amounts of detail. There is more than a further zoom level of difference between Helsinki and Longyearbyen. The widest used scheme for tile URLs leaves a hole 1000km across around each pole; this was tolerated because the is no land in the Arctic hole and, as any Australian will tell you, the southern hemisphere doesn’t count.

Many vector tiles, however, are still based on Mercator leaving the different scale at each zoom level depending on latitude in place along with the holes at the poles. This made the transition from raster to vector tiles easier but is less relevant now apart from holdouts like the OSM-Carto layer. An alternative tiling scheme is how OSM stores its coordinates: latitude and longitude. A large scale map of a small area could simply use the coordinates directly scaled by the cosine of the latitude and the scale will stay the same as the map pans north and south. A small scale map could use the Equal Earth projection favoured in a United Nations vote, another equal-area projection or one that isn’t such as an orthographic globe view — or even Mercator.

These opinions are my own.

I am happy to announce that we, the OpenStreetMap Carto maintainers, have prepared a new 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.

This is a minor release, but it still contains quite a lot of high impact changes to the map. We are also introducing a number of new design techniques in the style like scale dependent de-duplication of features and abbreviation of long labeling strings.

Under the hood we have added quite a few performance improvements, that we hope will ease resource requirement for style users and free resources for both mappers to add more data and for us to further improve the design of the map.

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

Motorway junction improvements

Density of highway=motorway_junction labels has been too high in some areas, leading to junction labels often blocking other labels (in particaular highway shields) while not being too useful themselves. We have made two changes in that regard:

• moving the starting zoom level for the labels up by one (ref starting z12 instead of z11, name starting z14 instead of z13).
• de-duplicating junctions with the same ref/name at the lower zoom levels.

The latter is important for motorway junctions because they are often mapped in pairs for both directions of the motorway. This previously often led to two identical labels and avoiding that helps a lot in reducing label density without removing substantial information. We also de-duplicate suffixes on ref (like 42a, 42b)

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

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

Thanks to contributor leijurv for implementing these changes.

Unification of the fill colour for power plants etc. with the fill colour for industrial landuses for zoom levels 10-12

This fixes the error of the fill color for power=generator and similar tags not being unified with all the other builtup landuses at lower zoom levels.

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

Thanks to contributor olafkryus for implementing this change.

Remove golf=pin rendering on polygons

We had previously displayed symbols for golf=pin on both nodes and polygons while mapper consensus is clearly that it is only used on nodes. This is changed now.

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

Thanks to contributor dch0ph for implementing this change.

Remove highway=bus_guideway oneway arrow offset

We had rendered oneway arrows on highway=bus_guideway with an offset next to the line for a long time, but it was noticed that this leads to confusion in case of several closeby roads. We therefore changed this to centered oneway arrows.

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

Thanks to contributor dch0ph for implementing this change.

Rework waterway lines

One of the biggest changes of this release is reworking of the waterway line rendering.

This includes, in particular:

• substantially narrowing the line signature of waterway=canal, which we had shown much stronger - like waterway=river - before, which does not reflect mapper consensus on the use of the tag though. This had led to mappers feeling discouraged to use waterway=canal on smaller artificial waterways. We have now adjusted this to a much more moderate line width.
• fixing errors and inconsistencies in bridge/tunnel rendering in some cases.
• reducing the halo of small waterways at high zoom levels, which had previously led to an inbalance between darker and brighter backgrounds.
• starting minor waterways earlier (at z12) in a subtle way to better communicate the drainage structure and provide better feedback on waterway mapping on a coarse scale.

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

Thanks to contributor dch0ph for implementing this change.

Render waterway=fish_pass and tidy waterway bridge/tunnel code

waterway=fish_pass has been established as tagging for structures at weirs or dams that are meant to facilitate fish passing by the barrier during migration. We have now added support for rendering those and at the same time re-organized rendering of waterway tunnels and bridges a bit. That leads to us no more rendering waterways that are tagged both bridge=yes and tunnel=yes - which is not really meaningful tagging anyway and which had broken rendering before.

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

Thanks to contributor leijurv for implementing this change.

Merge bridge and waterway-bridge layers

OSM-Carto has the most sophisticated and most accurate framework of layered roads rendering of all OSM based map styles in production use - yet there are various aspects in which our rendering is not properly reflecting the mapping in OSM. One of them is waterway bridges (like aqueducts) - which we have so far not correctly layered with the roads. The waterway bridges were always rendered above all road bridges, even if the layer tagging indicated othewise.

We have now integrated the waterway bridges into the road bridges layer and render them in correct order.

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

Thanks to contributor dch0ph for implementing this change.

Improvements of waterway=dam and other water barriers

A number of improvements were made to the rendering of waterway barriers, in particular dams.

waterway=dam is used to map dams in the sense of contructed barriers to contain a standing body of water (usually called a reservoir). This is not to be confused with man_made=dyke, which is a barrier to prevent flooding during seasonal or weather related higher water levels.

These can be and are mapped with either nodes, linear ways or polygons.

OSM-Carto has rendered waterway=dam for a long time, but we have had various issues with the rendering that needed work. Some of them have been addressed now.

First the appearance of dams at the first zoom levels (z13-z15) was often considered heavy, especially for smaller dams. We tuned the rendering parameters to address that - and also the high zoom level design to better show that linear way and polygon design are representations of the same feature class.

Then we removed rendering of name labels on the outline of waterway=weir mapped with polygons. We had stopped rendering polygons tagged waterway=weir because that is not consensus mapping, but the label rendering was remaining as a stray label. This is now fixed. Also we changed the drawing order to provide better feedback on overlapping waterway barriers by rendering linear ways above polygons.

As you can see there are still some issues not yet addressed - like the stray labels for dams mapped with nodes at the lower zoom levels and the offset of dam polygon labels.

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

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

Thanks to contributor dch0ph and leijurv for implementing these changes.

Remove rendering of name of amenity=charging_station

Like for many other points of interest we had - so far - rendered amenity=charging_station with a name label. But charging stations rarely have a proper name so the name tag on these is mostly abused as a label tag - not in line with the consensus among mappers about name tagging. Hence we decided to remove those labels. This also opens space for better differentiating charging stations in the future in a meaningful way - like indicating the vehicle types supported, plug standards, payment methods etc.

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

Thanks to contributor GA-Kevin-Codes for implementing this change.

Add rendering of man_made=ceremonial_gate

Some time ago mappers have discussed the idea to unify tagging of different types of ceremonial gates (common in east and southeast Asia) to a single primary tag and thereby making it easier for mappers to tag these (without requiring up-front knowledge of the specific type) and for data users to interpret them.

We have now added basic support for rendering these.

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

Thanks to contributor daishu0000 for implementing this change.

Delay minor accommodation text label

So far we have started showing symbols and labels of tourism accommodations (like hotels) all at the same zoom level (z17). With this change we now delay the name labels of the minor accommodations (tourism=guest_house and tourism=chalet) until z18.

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

Thanks to contributors dch0ph for implementing this change.

Shorten multi-component flat and housenumber lists

There are addresses mapped containing long lists in addr:housenumber or addr:flats, which led to very long labels in OSM-Carto. We now addressed this problem by abbreviating long lists in such tags with an ellipsis.

We deliberately did not try to fully parse the content of these tags and label them in an abbreviated and normalized form since there are no firmly established conventions for the form of these tags when containing more than a single number.

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

Thanks to contributors dch0ph for implementing this change.

Hide fake admin boundary segments on the 180 degree meridian

In OpenStreetMap we ought to map things in geographic coordinates, but unfortunately mappers often tend to map in equirectangular projection (which essentially means treating geographic coordinates as cartesian coordinates). And many data users also rely on them doing so.

This leads - among other things - to mappers creating fake geometries at the 180 degree meridian to formally close geometries in equirectangular projection (while, ironically, breaking them in geographic coordinates).

We in OSM-Carto have been in an unfortunate position since we - like many others - rely on software that expects data in equirectangular projection and is unable to process data in geographic coordinates. So we essentially are unable to support mappers in mapping things in geographic coordinates. So far we have displayed data as is - including the fake closures at the 180 degree meridian. We have now changed that for the administrative boundaries by explicitly removing those parts of the boundary directly on the 180 degree meridian. This works only because there are no actual administrative boundaries direcly on the 180 degree meridian of course.

There are still other issues related to the problem of the software we use only dealing with equirectangular projection and not being able to properly implement the periodic boundary conditions of the Mercator projection in longitude direction. We would like to do better in that regard, but have only limited options to do so.

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

Thanks to contributor leijurv for implementing this change.

Rework railway=crossing rendering (starting zoom level, prioritization)

So far we have rendered railway=level_crossing/railway=crossing in a very simple fashion, starting with a small symbol at z14/z15 and switching to a larger symbol at z16. The symbol also had very low priority, meaning it was often hidden by road labels despite there being space for the road label to not block the crossing.

We now changed that by making the starting zoom level depend on the type of crossing railway. Also we indicate if a crossing is mapped not on a railway track by using a different symbol.

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

Thanks to contributors dch0ph for implementing this change.

Lighten design and increase starting zoom level for minor service=* variants of some railways

We have also reviewed and re-designed the zoom level progression of minor service=* variants (service=spur/siding/yard) of some railways. railway=light_rail yards, in particular, were very heavy in appearance at the medium zoom levels and there were various inconsistencies in the zoom level progressions in general.

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

Thanks to contributor leijurv 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/v6.0.0…v6.1.0

Note for deployments: This release updates all of the SQL scripts that you need to run on the rendering database before using the style (indexes.sql, functions.sql and common-values.sql). See INSTALL.md for details.

Thanks

The OSM-Carto maintainers thank all contributors - including those who contributed changes not visible in the map that are not listed above. Particular thanks go to the new contributors:

olafkryus, daishu0000, Harvester57, wangi

I want, in particular, to thank Nakaner (geofabrik) and leijurv for work on efficiency improvements of the style.

Thanks also go to Mapnik developers for addressing various issues and implementing improvements of particular interest for OSM-Carto.

As always, we welcome any bug reports at

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

recent hdyc.neis-one.org feature update is really something else. it forces you to read “that thing”. sometimes i accidentally read something that makes my blood boil.

alright, instead of replying there, i’m gonna reply to it here instead.

place=city: The largest settlement within a territory, including national, state and provincial capitals, and other major conurbations (an extended urban area, typically consisting of several towns merging with the suburbs of one or more cities).

place=town: An important urban centre that is larger than a village, smaller than a city, and not a suburb. Towns normally have a good range of shops and facilities which are used by people from nearby villages.

place=village: A smaller distinct settlement, smaller than a town, with few facilities available, with people travelling to nearby towns to access these.

place=hamlet: An isolated settlement.

i can confirm by myself that “that place” is not isolated.

meanwhile, administrative borders should be mapped as ways/relations properly. for a node, just stick with this global consensus definition as stated on the wiki page.

but where can we get that administrative border data?

someone in “that Telegram” group claimed to own all the copyright to this country’s administrative data, even though it is clearly already licensed as open data on “that site”.

i’m not a lawyer, so i don’t know the legality of manually tracing that border from an official source. this is why i hate mapping from official sources. i’d rather stick to local knowledge and direct surveys.

and… that’s it, pretty much.

For ages, I’ve been wanting to tell my stories around a specific place in OSM. Not specifically a “review” of a business, but simply a personal anecdote about me and that particular place.

Years ago, I received my first invitation to give a talk about OSM. On that occasion, I proposed this project: “What if we create a platform where people can share their personal stories around a specific place?”

But I was probably just an “idea guy” back then.

My programming skills weren’t developed enough to build the platform all by myself, and I had no idea how to get funding to pay for a hosting service anyway. So I shelved the idea for a long time.

Fast-forward to 2026, I eventually thought to myself: maybe it’s finally the right time to revisit that old dream.

So I built this.

First, you log in using your OSM account.

I want this platform to be somewhat of an extension of OSM Diary.

Here, you can not only write an “OSM Diary” entry associated with your OSM account, but also link it to a specific place. Every story is tied to a particular location. If a place is significant enough that many people have posted their stories about it, you can see all the other stories associated with that place.

Then, you have three ways to choose a place. You can search for it using the “Search places with Photon” feature. You can manually zoom in on the map and pick a location. Or you can use the GPS button to automatically zoom to your current location.

Then, pick a location and write your story.

Try it here : https://bisikbekasi.rf.gd/o/

Source code : https://github.com/altilunium/altilunium.github.io/blob/main/util/ivebeen_here/index.php

Alright. Day two. As I finally have some free time to write this one.

At 2:27 pm, I went to the Martinique room, planning to attend the “OSM Science” opening talk.

At 2:37 pm, I saw a slide showcasing the QR codes for each OSM Science output, starting from 2019 to 2025 (including the IJGI special issue).

I went back and forth, decoding all those QR code links one by one, and posted them on my Mastodon.

• https://zenodo.org/records/3405431 (2019 - Heidelberg)
• https://zenodo.org/records/3928675 (2020 - Cape Town (x) - Online)
• https://zenodo.org/records/5116434 (2021 - Online)
• https://zenodo.org/records/7004791 (2022 - Firenze)
• https://zenodo.org/records/10443403 (2023 - Antwerp)
• https://zenodo.org/records/17370615 (2024 - Nairobi)
• https://zenodo.org/records/21009418 (2025 - Manila)
• https://zenodo.org/communities/osmscience2026/records?q=&l=list&p=1&s=10 (2026 - Paris)
• https://www.mdpi.com/journal/ijgi/special_issues/OpenStreetMap

The Q&A session started at 2:51 pm, and finally ended at 2:58 pm.

After that, I stayed in the Martinique room. The researchers who had submitted their publications to OSM Science started presenting their work, one by one, in quick succession, around five minutes each.

Around 3:02 pm, I had to close the stream for a little while because I had something to do.

I came back at 3:38 pm, still in the Martinique room. The OSM Science paper presentations were still ongoing, and finally ended around 3:44 pm.

Then, it was coffee break (10:44 am Paris time). The programme said it would resume at 11:15 Paris time.

I closed the stream, killed some time by editing WeeklyOSM, then came back at 4:12 pm, this time in the Corse room.

The talk had not started yet. It finally began at 4:15 pm.

The topic was very interesting: how to make your GNSS (a.k.a. “GPS”) reach centimeter-level accuracy.

Turns out, you need special hardware and a special “network to distribute GNSS correction streams”.

The talk ended at 4:43 pm.

At 4:44 pm, I went back to the Martinique room. The next talk started at around 4:50 pm, this time about visualizing lanes in road networks. Really interesting.

When I edit WeeklyOSM, I sometimes come across several contributors who are working on this exact same problem: how to properly visualize lanes in the OSM road network.

And this problem is really complex. Sometimes, for example, you need to account for the width of each road’s geometry, which can even vary along a particular segment.

The talk ended at 5:18 pm.

At 5:22 pm, I went to the Corse room. This time, the talk was about the “Fédération des pros d’OpenStreetMap” (FPOSM).

From the talk description, it is “a French non-profit organization that unites companies and professionals whose services and tools are built on OpenStreetMap, and who are committed to keeping OpenStreetMap a healthy digital commons”.

I discussed this talk quite a lot in the internal HOT chat group while watching the stream online, especially the possibility of starting a similar organization ourselves.

At 5:48 pm, I had to close the stream again because I had something to do.

At first, I planned to rejoin at around 8 pm, but then I got an urgent invitation from my neighbor to attend an event. So I tried to watch the stream on my mobile phone while traveling outside, around 8 pm, in the Guadeloupe room.

It was one of the talks that I really wanted to watch. It was about OpenStreetMap’s “core software” projects, explained by the key people behind those projects themselves.

Unfortunately, I failed to watch the rest of the talk, since the neighbor’s event was starting soon. So I had to close the stream and move on.

Thankfully, as I am writing this OSM diary right now (September 9th, while the second day was August 29th), the full recording of that talk is already available on the SOTM 2026 website, hosted by OSM France’s PeerTube instance.

Well, I think I want to watch the video in full first before continuing this OSM diary…

Online-Konsultation für einen weiterentwickelten Rahmen für Open Data

Die Bundesregierung plant, den strategischen Rahmen für Open Data weiterzuentwickeln. Das Bundesministerium für Digitalisierung und Staatsmodernisierung lädt daher die Open-Data-Community, Stakeholder und die interessierte Öffentlichkeit zu einer Online-Konsultation ein.
Ziel dieser Konsultation ist es, Vorschläge und Anregungen für einen weiterentwickelten Rahmen als „Fahrplan für Open Data“ zu sammeln. Die Bundesregierung strebt die Verabschiedung und Veröffentlichung für Anfang 2027 an.

Mitglieder aus dem FOSSGIS e.V. haben anhand der Leitfragen die wichtigsten Aspekte, Themen und Handlungsfelder zusammengetragen, woraus eine Stellungnahme entstanden ist, die fristgemäß eingereicht wird.

Danke an alle, die unterstützt haben.

Hier ist die komplette Stellungnahme zum Nachlesen und Herunterladen als PDF.

September 6–12

September 8

• Fixed David Lane and Country Brook Lane.
• Modified Rickly Street; added note that signage by the Street Department is incorrect. Correct spelling is Rickly Street, not Rickley Street. (Contacted city and should be fixed soon with new work order)
• Added a driveway and multiple road names (Buckeye Alley, Cherry Alley, Hickory Alley, Elm Alley, Maple Alley, Ash Alley, Walnut Street, Cypress Alley, and the rest of Beech Alley).
• Added info to (now closed) Hannah J Ashton Middle School.
• Added Unzinger Ditch and name of Dysar Run.

September 13–19

September 13

• Fixed and added streets and their names in Northeast Reynoldsburg, including:

1. Extending Mueller Drive into Maplewood development,

2. fixing name of Old Summit Road,

3. splitting Eastwood Drive into Eastwood Drive E and Eastwood Drive W, and

4. adding Allegro Drive, Capriconus Drive, Luna Drive, Henley Avenue, Lucy Drive, Sunny Drive, Park Place N, Park Place S, Little Jordan Run Street, Sun Gold Loop, Lucky Cross Run, and Heirloom Lane.

• Fixed name of Victoria Meadow Lane and added note about sources incorrectly calling it “Victoria Meadow Drive.”
• Added driveway to 8741 Canada Court.
• Fixed street names in the Wheaton Village neighborhood.
• Fixed Tanglewood Drive.
• Fixed streets in the Taylor Chase Condominium and Laurel Bluff Apartments complexes.
• Added Meisner Court and remainder of Walsh Drive.
• Fixed streets in the Spring Hill Farm and Brookside Park neighborhoods.
• Added apostrophes to Peggy’s Cove, Jackie’s Bend, and Going’s Lane. They officially have apostrophes, even if USPS doesn’t recognize them.
• Added Ofosua Court.
• Added Conservation Development District on Waggoner Road.
• Added Swisher Creek, Cole Ditch, and multiple unnamed streams and ponds as seen from satellite images and as seen and named on the National Water Quality Monitoring Council website.
• Added new developments of The Residences at Eastwood, Maplewood North, and Summit Crossing.

September 14

• Added street names to Thornton Hall Apartments.
• Removed “Taylor Square Drive” north of Taylor Road SW. Taylor Square Drive is only south of Taylor Road SW, as indicated by an arrow pointing south on street signs.

September 15

• Added name of Street Department Road, as indicated by construction signage.

Wrapping up GSoC 2026: Making closures.osm.ch production ready

This summer I had the chance to spend my second Google Summer of Code working with the OpenStreetMap Foundation, this time on closures.osm.ch, a community platform for reporting temporary road closures in real time so that routing engines can actually route around them.

closures.osm.ch started life during GSoC 2025 as a solid prototype: a FastAPI backend, a Next.js frontend, OpenLR location referencing, and a first attempt at routing integration with Valhalla. My job this summer was to take it from “working prototype” to something closer to a real production service.

The routing problem

The biggest issue going in was architectural. The frontend was fetching closures, pulling out raw coordinates, and handing them to the public Valhalla instance as exclude_locations. It worked, sort of, but it had a hard 49-point cap, ignored one-way closures entirely, and duplicated business logic between two different frontend components. None of that scales.

Before writing any code, I actually went and discussed the right approach with the Valhalla maintainers themselves in a public GitHub discussion. That conversation confirmed the long-term correct architecture is Valhalla’s live traffic tile infrastructure rather than anything at the exclude_locations level. That’s a bigger undertaking than fits in one summer, so the plan became a two-stage one: build a solid stepping-stone now, leave the graph-level integration properly documented for later.

That stepping stone is what shipped: a self-hosted Valhalla instance, and a new backend endpoint that buffers closure geometries with Shapely and passes them to Valhalla as exclude_polygons instead. The frontend got a lot simpler as a result, it just asks for a route now and gets one back with closures already avoided, no more duplicated logic living in the browser.

OpenLR, for real this time

Somewhat embarrassingly, the OpenLR codes the platform was generating weren’t actually spec-compliant OpenLR, they used a custom marker byte that no standard decoder could read. That’s now fixed, with encoding going through Valhalla’s map-matching, so closures.osm.ch’s location references should now interoperate with other OSM-based navigation tooling that speaks real OpenLR.

Vector tiles

Active closures are now served as MVT vector tiles straight out of PostGIS with ST_AsMVT, so the map layer updates live instead of requiring a page reload. Small feature, but it makes the map feel a lot more alive.

What’s left

Government data ingestion is the piece I didn’t get to finish. The plan was CIFS and DATEX II importers so the platform could ingest authoritative closure data from municipal agencies directly, but partway through the summer that scope shifted: OST offered to push pre-processed Swiss ASTRA data to us directly instead of us having to parse it ourselves, which changes the shape of that work. I’ve made a start on it, but it’s genuinely not done, and I’ll be continuing on it after GSoC officially wraps up. UI internationalisation is also still untouched, it’s documented as deferred work for now.

Thanks

Huge thanks to my mentors Simon Poole and David Haberthür for the guidance this summer, and for trusting me to make real architectural calls on a project that real people depend on. Also thanks to the Valhalla maintainers for taking the time to talk through the routing architecture with a stranger on the internet before I’d written a line of code.

If you want the full technical rundown with links to every PR, I’ve written that up separately in the project’s final report.

Development on closures.osm.ch continues, I’m not stopping here.

Sou um usuário novo, e desde que comecei a editar locais que conheço, acabei não lendo a guia de direitos de autor, onde indica-se que sites como Google não deverão ser usados para preencher informações. Acabei cometendo esse erro, e peço minhas sinceiras desculpas pelos erros que cometi. A partir de agora, estarei usando os sites oficiais do município e os sites oficiais das instituições e prédios que irei adicionar, junto com fotos aéreas e, se eu puder, visitarei esses lugares.

I sincerely apologize for my lack of reading the guide for this website when I shouldn’t use map sites related to Google. I’m lazy at first when I tried to use the site for the first time. Especially for mapping broadcast stations, and missing barangays for like 9 months now.

:/

(UPDATE: This has been edited 2 times now.)

hola esta app me servira para hacer seguimiento a un celular?

In 2026, the question is no longer really:

“Can OpenStreetMap truly be used professionally?”

State of the Map 2026 in Paris once again showed that this question has largely been settled.

OSM now serves as the foundation for national reference datasets, is influencing European standardisation work on cycling infrastructure, supports research into data quality, and is part of an increasingly structured professional ecosystem.

Around it, other digital commons are also emerging, such as Panoramax.

At the same time, some talks reminded us of something essential: behind tags, ontologies and data pipelines, a map remains a representation of the world — and therefore the result of choices.

A few reflections, with a cycling-data bias, after three days at #SOTM2026 at Géodata Paris 👇

(french version here)

State of the Map Paris 2026: OpenStreetMap is scaling up

For the first time, the global State of the Map conference took place in France, from August 28 to 30, 2026, in Champs-sur-Marne, near Paris.

The location itself felt quite symbolic. The international OpenStreetMap community gathered at Cité Descartes, including at Géodata Paris, IGN’s school, alongside École nationale des ponts et chaussées and Université Gustave Eiffel.

For three days, contributors, researchers, public authorities, institutions, associations and companies met in a place dedicated to education, research and new uses of geographic data.

This connection between OSM, academia, research, public institutions and professional geodata users actually sums up quite well what I took away from this edition.

A few days after SOTM 2026, one impression stands out:

OpenStreetMap is scaling up.

Of course, OSM has long ceased to be merely “a collaborative map” sitting on the margins of large private or governmental mapping platforms.

But this year’s conference showed particularly clearly how deeply the project is now embedded in professional applications, research, public policy and even standardisation work.

And it was particularly interesting to see this evolution taking place at IGN.

IGN was not only one of the event’s partners. Several topics discussed during the conference — including Panoramax, digital commons and the relationship between institutional datasets and OpenStreetMap — also illustrate a deeper evolution in the relationship between the French institutional geographic ecosystem and OSM.

A few years ago, IGN and OpenStreetMap could easily have been portrayed as two separate, perhaps even competing, worlds. I have quite vivid memories of this opposition from when I studied here myself.

SOTM 2026 told a rather different story:

one of complementarity, commons and collaboration.

Among the many talks, a few topics particularly caught my attention.

OSM is starting to inspire cycling standards

The presentation “How OSM inspires CEN standards for cycling infrastructure”, by Tu-Tho Thai, sent a strong signal.

As part of European work on the digital description of cycling infrastructure, the Cyclinfra project is examining OpenStreetMap tags and mapping practices.

OSM is therefore no longer simply adapting itself to institutional standards.

It is also starting to inspire them.

France’s Base Nationale des Aménagements Cyclables (BNAC) — the National Cycling Infrastructure Database — follows a similar approach: using OSM as a source, transforming the data into a national data schema, and enabling public authorities to improve the shared OSM dataset in return.

For cycling, this convergence between OSM, national datasets and European standards is particularly promising.

It is also very close to what we have been promoting within the Geodata team at Geovelo.

When mapping a pothole becomes political

The discussions around “The democratic stakes of mapmaking”, with Ksenia Ermoshina, Christian Quest and Françoise Bahoken among others, were a useful reminder of something that is often overlooked:

Mapping is a political act.

A simple example illustrates this well.

Mapping potholes or problems in public space may seem trivial. But making those issues visible also makes it possible to assess public policies and helps residents organise or advocate for improvements.

Choosing what we represent, what we describe, and what we leave invisible is already a decision.

Technical choices in a database or a map are therefore never entirely neutral.

Panoramax: a new geographic common

Panoramax was also highly visible throughout the conference — starting right from the opening session.

That was particularly satisfying for us at Geovelo, as we helped fund the first viewer back in 2021, when the project was still called GeoVisio.

Panoramax provides a free, open and federated alternative for sharing street-level imagery.

Its value is not only in the photographs themselves.

Its architecture is equally important: multiple organisations can host their own imagery while remaining connected through a common federation.

Like OpenStreetMap, Panoramax demonstrates that it is possible to build an open, decentralised geographic infrastructure that does not depend on a single provider.

The French Federation of OSM Professionals is helping structure the ecosystem

The French Federation of OpenStreetMap Professionals, of which Geovelo is a member, was also very visible during the event: through its booth, talks, discussions with participants and an OpenStreetMap TV studio.

This reflects another important evolution.

Over the past few years, a genuine professional ecosystem has been developing around OpenStreetMap.

The Federation brings together companies and professionals working in mobility, accessibility, energy, urban planning, tourism, GIS tools, data quality and other fields.

Its purpose is not simply to represent businesses using OSM.

It also builds bridges with public authorities, explains the ODbL licence, documents professional uses of OSM and advocates for the commons-based model.

We also followed several more technical and applied-research topics.

Making OSM easier to use

Jake Low’s presentation “Sourdough and Layercake” addressed another major challenge: OpenStreetMap’s complexity.

Sourdough provides vector tiles that remain close to the logic of OSM tags.

Layercake transforms OSM data into thematic layers, including in GeoParquet format.

The objective is straightforward: allow more people to work with OSM data in tools such as QGIS, DuckDB or notebooks without first having to master the full complexity of PBF files, relations and tagging conventions.

Making OSM easier to access without losing the connection to the original data is probably one of the major challenges facing the ecosystem.

Understanding changes in OpenStreetMap

The work presented by Camille Bernard and Pedro Pinheiro focused on detecting and semantically annotating changes in OpenStreetMap.

Their research was presented as:

Bernard, C., Pinheiro, P., & Viry, M. (2026). Detection and Semantic Annotation of Changes in OpenStreetMap Data. OSM Science 2026 at State of the Map 2026.

Detecting that an object has changed is relatively easy.

Understanding why it changed is much harder.

Imagine that a cycleway suddenly appears in OSM.

Was the infrastructure actually just built?

Was it already present on the ground but had never been mapped?

Was it simply a tagging correction?

Or a geometry improvement?

Being able to distinguish between these situations is essential when analysing how a territory evolves.

This is something we will be following closely.

Comparing the number of kilometres of cycleways in OSM between two dates is not enough. We need to distinguish changes in the real world from changes in how the real world is represented in OSM.

OSM is no longer just a map

Although, to be fair, it probably never was.

All these examples tell a similar story:

• Panoramax is building a new commons around street-level imagery.
• Sourdough and Layercake are making OSM data easier to use.
• The Federation of OSM Professionals is helping structure an economic ecosystem while building bridges with public institutions.
• Research is helping us better understand how OSM data evolves.
• European cycling standards are beginning to learn from OpenStreetMap.
• Discussions about mapping remind us that technical choices can also have democratic consequences.

The question is therefore no longer really whether OpenStreetMap can be used professionally or institutionally.

That has already been answered.

The more interesting questions are now:

• How do we industrialise without closing things down?

• How do we standardise without oversimplifying?

• How do we professionalise without taking ownership away from the community?

That is what I will remember from State of the Map 2026 in Paris.

OpenStreetMap is no longer simply a map that we improve feature by feature.

It is an infrastructure and a digital common around which tools, companies, standards, research and public policies are now being built.

Geovelo at SOTM 2026

We also contributed two presentations during the conference:

• Geovelo & cycling infrastructure, a discussion in the SOTM TV studio, in French.
• “How OpenStreetMap became the backbone of France’s National Cycling Database”, presenting the history of the BNAC and making the case for the relationship between institutional cycling data and OpenStreetMap.

A busy State of the Map, and plenty of ideas to bring home.

See you at the next one!

in-browser editor

##JOSM ###Potlatch ####Merkaartor

History Export ***GPS Traces **User Diaries ***Communities **Copyright **Help ****Donate *******About

1. United States
2. Kentucky

[kramdown](https://kramdown.gettalong.org/quickref.html

37 Degrees North & -85 Degrees West

Das Vernetzungstreffen des FOSSGIS e.V. hat am 02.09.2026 mit 25 Teilnehmenden in der Netzwerkwelt stattgefunden. Die Idee ist, das gegenseitige Kennenlernen und gemeinsamer Austausch zu Anliegen und Themen. Menschen im Umfeld des FOSSGIS-Vereins erhalten Gelegenheit Kontaktpunkte zu finden. Viele Teilnehmende waren schon beim letzten Mal dabei und kannten sich in der Benutzung der Netzwerkwelt aus.

Eindrücke vom Treffen, Start im FOSSGISeV-Raum

Spannende Themen im Austausch

Zu Beginn trafen sich alle Teilnehmenden im Raum FOSSGIS e.V. für einen gemeinsamen Einstieg und um den Ablauf der Veranstaltung miteinander zu teilen. Vier Räume waren thematisch vorgeplant.

Die Idee der Vernetzung im Bereich Blaulicht/BOS/Gefahrenabwehr wurde von Jana Thomas und Mirco Schindler weiter vorangetrieben. Es wurden konkrete Schritte bsprochen, um eine Arbeitsgruppe im FOSSGIS e.V. zu gründen. Die Gruppe hat schon eine eigne Mailingliste sowie erste Ideen für den Namen und was erreicht werden möchte.
Auf der SOTM 2026, die Ande August in Paris stattgefunden hat, gab es einen Vortrag passend zum Thema, “Emergency Services using OpenStreetMap in Germany”.

Der diesjährige Geodaten-Hackathon (#hack4GDI_DE) findet vom 13. - 14.11.2026 an der Hochschule Mainz statt. Die Challenge 2 zum Thema Flächenentsiegelung & Schwammstadt wird von Emmanuel Tobey gestaltet. Um den Einstieg zu erleichtern, nutzte Emmanuel das Vernetzungstreffen. Die Gruppe formulierte eine Wikianleitung für einen FOSS-Einstieg beim Hackathon und tauschte sich zum Umsetzungskonzeot aus. Details & Anmeldung zum Geodaten-Hackathon sind auf den Webseiten der GDI-DE zu finden.

Das Thema KI und heterogene Geodaten treibt nicht nur Johannes Lauer um. In der Gruppe geht es um die Frage, kann KI bei heterogenen Geodatenbeständen helfen? Welche Tools gibt es? Welche Use Cases haben sie Teilnehmenden? Als Usecases wurden Softwareentwicklung, Landoberflächenklassifikation oder der Support für non-GIS-Experts und weitere besprochen. Vor- und Nachteile von KI-Nutzung waren Thema, beispielsweise haben die Repo-Betreiber Codeberg e.V. eine Entscheidung zum Schutz der FLOSS-Commons vor LLMs getroffen und hier aufgeschrieben, die CivicDataLab Community hat ein selbst gehostetes KI-Tool auf den Weg gebracht. Das Thema wird beim nächsten Vernetzungstreffen fortgesetzt.

Im Themenraum Praxisbeispiel QGIS-(Analyse-)Werkzeuge stellte Anja Eisert das Sichtbarkeitsanalysetool Visibility Analysis vor. Im Anschluss tauschten sich die Teilnehmenden allgemein zu QGIS-Tools und PlugIns sowie über Weiterbildungsmöglichkeiten und Jobperspektiven aus.

Das Treffen in der Netzwerkwelt hat auf Basis von Workadventure stattgefunden. In der Netzwerkwelt ist die Interaktion von Teilnehmenden möglich, man ist mit einem Avatar unterwegs, gibt sich beim Eintreten einen Namen. Trifft man eine andere Person, öffnet sich ein Videochat, eine Unterhaltung ist bis maximal 4 Teilnehmende möglich. Die Räume (Inselchen) sind Videokonferenzräume, man tritt einem Jitsi-Videochat bei, dort fanden die Austauschrunden statt. Vielen Dank an Stella fürs Bauen der Netzwerkwelt und danke den FOSSGIS e.V. für die Unterstützung des Treffens mit den Entgelt an die Betreiber der Plattform.

Abschluss und Feedback

Abschluss und Feedback

Die Rückmeldungen waren durchweg positiv, die Teilnehmenden kommen wieder und wollen sich weiter über verschiedene Themen austauschen.

Das nächste Vernetzungstreffen am 09.12.2026 wird wieder ab 17:30 Uhr in der Netzwerkwelt starten, um entspanntes Ankommen, ersten Austausch und einen gemeinsamen Beginn um 18 Uhr zu gewährleisten.

Folgende Themen wurden gewünscht und werden voraussichtlich angeboten:

• Fortsetzung Vernetzung BOS/Gefahrenabwehr (Jana + Mirco)
• Beispiele aus der Praxis: QGIS, QGIS Layertool, ArCGIS2QGIS (Anja E., Christian S.)
• Fortsetzung Raumes zu KI und Geodaten, da die Entwicklung so schnell geht, dass regelmäßiger Austausch sinnvoll erscheint (Johannes L.)
• Konzepte studentischer Vernetzung (David.stud)

Wer Interesse hat einen Raum anzubieten, meldet sich bitte vorab bei Katja oder per mail an socialmedia@fossgis.de.

Infos aus dem Verein

Die Aktivitäten des Vereins sind im FOSSGIS-Vereins-Kalender zu finden.

Vom 9.-13-03.2027 findet die FOSSGIS-Konferenz 2027 in Heidelberg statt. Erste Infos sind auf der Konferenzhomepage veröffentlicht, Beitragseinreichungen sind im Rahmen des Call for Participation vom 01.10. bis 01.11.2026 und die Anmeldung ist ab Januar 2027 möglich.

JETZT OSM-Förderer werden und die digitale Souveränität stärken!: https://openstreetmap.de/foerderer/

Das aktuelle Projekt: OSM-Schulungen, gefördert durch die DSEE (transform_D) läuft noch bis Ende 2027. Die Idee ist Schulungsmodule mit Inhalten zu entwickeln. Eine Arbeitsgruppe begleitet den Entwicklungsprozess inhaltlich, erste Schulungen werden zu Beginn 2027 stattfinden. Für die Organisation der Schulungen in der Koordinierungsstelle des FOSSGIS e.V. kommt ab 01.10.2026 eine neue Kollegin.

Das wichtigste zuletzt: Der FOSSGIS-Verein sucht einen Schatzmeister, die Position ist derzeit bis zur nächsten Mitgliederversammlung mit Wahl komissarisch zu besetzen.