I’ll give you the benefit of the doubt that you actually read the post before reaching for the pitchfork.

Nothing in the proposal talks about “subordinating” anyone to a “central management.” It’s an engineering post asking whether a blogging feature bolted onto the API codebase should live on a platform that already does blogging, threading, and moderation better. That’s it. No one is stripping OSMF of anything — if anything, the diaries would gain a modern editor and proper moderation tooling that the current bare-bones form has never had.

And here’s the part that really undercuts your framing: https://c.osm.org/ is also run by the OSMF, and its moderators — same as diary moderation today — are determined by the community, not appointed by the faceless technocracy you’ve invented for dramatic effect. So the whole “self-determined cooperation vs. managed paradigm” contrast collapses on inspection. You’re not comparing OSMF-governed vs. independent, you’re comparing one community-moderated OSMF platform to another, one of which happens to have actual software behind it instead of a form from another decade.

You also skipped the practical upside, which is odd for someone so invested in what’s “essential” to OSM: diary moderation currently sits with the Data Working Group, a team created to handle data disputes — vandalism, edit conflicts — not to referee blog comments. Moving diaries to c.osm.org frees DWG to do the job it actually exists for, instead of splitting attention between data integrity and diary policing. That’s not “stripping a hallmark feature” — that’s letting the people responsible for the map’s integrity focus on the map.

And the “irony” you’re so pleased with — spending a grant on the website while “stripping a hallmark feature” — is a similar reach. Reducing the surface area of a codebase is the maintenance work that grant is meant to support.

What this actually reads like is discomfort with any change to a corner of the site you’ve gotten comfortable with, dressed up in grand language about paradigms and sovereignty that doesn’t survive contact with how either platform is actually governed. Maybe engage with the real open questions in the post — identity mapping, localization, migration cost, DWG workload — instead of announcing that asking the question at all is “ridiculous.”

🚨 osm.org/relation/5684738

Див. Name — тільки для назв та Uk:Префікси життєвого циклу 😉

❓

З тим, що інформація від місця до місця дуже сильно різниться, ви, звісно, праві. Для когось тих даних, що є вже цілком достатньо, для когось, наприклад велосипедистів на шосейних велосипедах – ні.

Варто зазначити, що кожен мапер робить в проєкті щось, в першу чергу, для себе, а якщо це ще стає в пригоді комусь іншому так це взагалі  – win-win.

З вашого допису зрозуміло, що для певної групи споживачів є проблема. Але як її подолати – “щоб отримати це, потрібно зробити спочатку це, а потім оце, а далі…” і в такому ж дусі – такого немає. Схоже ваш допис не має результативної частини, чи може я не уважно читав.

Докладніше можна продовжити обговорення на форумі - https://community.openstreetmap.org/c/communities/ua/66

I prefer to use JOSM + builtins_tools for this type of work (merge address point with building outline)

Here is a video with an example - https://youtu.be/8QJNjmn3o7I?t=1313 (the video is in Ukrainian 🇺🇦, you can turn on subtitle translation)

Ну, я б не сказав, що позначення саме воріт (в’їздів у двори приватних помешкань) є непотрібними. Те що на стандартному стилі вони досить помітні не робить іх завим компонентом даних. Можливо стиль потребує корегування - не дані ;)

Можливо у мапера було бажання показати входи у будинки, які в свою черго позначаються тегом entrance=* (https://wiki.openstreetmap.org/wiki/Uk:Key:entrance)

Гарний допис, хтось мав це написати.

Але, кожен має вирішувати для себе, де, що і як мапити, чи не робити цього. Зважити 1000 разів можливі наслідки від власних дій!

А поки що, я дотримуюсь цього заклику від української спільноти https://wiki.openstreetmap.org/wiki/Uk:Російсько-українська_війна

Для чого цей та наступні переліки тут? Який з цього зиск?

Thank you all for your greate contributions. 👏

❓Dear maintainers of OSM-Carto, could you post release notes here -https://github.com/gravitystorm/openstreetmap-carto/releases/tag/v5.4.0

Have you ever thought that they may have their own sources for this, such as data received from their cars?

On behalf of the Data Team at Mapbox, I’d like to thank everyone for your feedback and insights. After considering your responses, we’d like to support the “Kreuz Köln-Süd” style, which places the junction node at the theoretical gore. Thanks to It’s so funny and Paul Johnson for the suggestion.

The Kreuz Köln-Süd style prevents navigation software from prematurely advancing to the next instruction before the driver has taken the ramp. At the same time, it avoids the steep angle of approach 3 that several of you commented on above, and it accommodates lane-level tagging such as turn:lanes=* and change:lanes=*.

We will adopt the Kreuz Köln-Süd style and recommend it in our navigation mapping guide.

Thank you once again. Have fun mapping!

spam!

I would rather have one consistent tagging style for the United States (and other countries where TWLTLs are common. I would prefer to use the lanes / turn:lanes tagging for that. What do you think?

@mvexel I support you on your willingness to have consistency in the data in the US and around the world.

As you see on the screenshot, turn:lanes:both_ways tag has three values: for the left or right turn and for the case when the center lane is used for reversible driving. It is much clearer tagging then just cent{er,re}_turn_lane=yes (and I just like namespace approach 😏).

@mvexel what you think about adding this task to MapRoulette or to-fix?

Распознавание знаков также поддерживается в плагине JOSM, примерно вот так

@naoliv If you need to get data for post-processing just add render_csv=True to osmcha URL http://osmcha.mapbox.com/?reasons=13&render_csv=True
☝️don’t run without adding some extra filters due to big amount of data.

naoliv could you try http://osmcha.mapbox.com/ ?

osm.org/user/PlaneMad/diary/40722

Thank you for the timely review, I’m just going to tell about OSMCHA this week at the GIS Forum in Kharkiv, Ukraine.

К сожалению, работа над устранением этой проблемы 👆 еще не завершена.

Такие места (где удаленные объекты все еще показываются на карте) есть не только в Балаково. 🙁

🚧🚧🚧🚧🚧🚧🚧

Так, вилучення таких доріг - правильне рішення.

Якщо розглядати зрошувальну установку як механізм - то вона займає всю площину круга. Взагалі, має сенс позначати лише шляхи які використовуються щоб дістатись до поля, а от уже по самому полю їх креслити не треба.

Для потягів 🚉 ми не мапимо кожну рейку окремо 😉