Users' Diaries

Recent diary entries

Силка на наш телеграм канал 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.

Posted by PeterLd on 10 September 2026 in German (Deutsch).

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.

Location: Ehrenfeld, Köln, Nordrhein-Westfalen, Deutschland
Posted by Wynndale on 10 September 2026 in English.

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.

See full entry

Posted by imagico on 10 September 2026 in English.

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)

See full entry

Posted by rphyrin on 10 September 2026 in English.

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.

Posted by rphyrin on 9 September 2026 in English.

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.

See full entry

Posted by Kay Covey on 8 September 2026 in English. Last updated on 9 September 2026.

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.

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

See full entry

Location: Διοικητήριο, 1st District of Thessaloniki, Thessaloniki Municipal Unit, Municipality of Thessaloniki, Thessaloniki Regional Unit, Central Macedonia, Macedonia and Thrace, Greece

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.

Posted by ClaveScottPH on 7 September 2026 in English. Last updated on 8 September 2026.

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

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.

See full entry

Posted by rocketcake on 5 September 2026 in English.

good things compared to yesterday: no rain!!

bad things: nearly 30°C outside and So. Many. Bees. okay it wasn’t as many as i make it sound like but i am admittedly afraid of bees. not a great time

ANYWAY. i went and finished the side of thames street that i started yesterday, then did the other half on the way home. so im pretty sure ive accounted for almost everything on that street now! so i guess next on the list is the side streets. hopefully we get some days that are nice and cool so i dont suffer doing this haha

Location: Ingersoll, Oxford County, Southwestern Ontario, Ontario, Canada