Hi @SomeoneElse sure ok thanks for confirming! 
@B972025, c’mon, at least own up to it. You didn’t write this post, you prompted AI to write it for you. It was the laziest possible approach you could have taken. I’m flabbergasted that people think this passes for organic text. And your first post on the forum too!
Please, don’t pee on our legs and tell us it’s raining. — – -
Clearly not ChatGPT, just a fan of the introductions to BBC Radio 4’s “One song to the tune of another” round on “I’m sorry I haven’t a Clue” - that has very similar extended similes for comic effect 
I see that you’ve also been struggling with the prominence of service roads on OSM Carto (the Standard layer on the homepage). Deleting the roads was counterproductive, and we’re lucky that Grab noticed and restored the roads. If you accurately classify service roads according to their function, rendered maps will generally avoid giving them too much prominence. But OSM Carto isn’t the only renderer we care about, so don’t go out of your way to optimize the tags for that one map style’s design choices.
And you are complaining to the wrong render. OSM.org is not ment for you and for navigation! You should look for more adequate renderers.
Still I do care about cluttering at osm.org , but not the bitmap-styles.
The vector styles could have fare more zoom levels (or rather values). If there is to much data, now it prioritises and hides things I may prefer. So I thing, a heat map may be neutral and avoid priority; zoom in if there is only a red dot with a number in it.
The other way would be, I define the priority in my frontend/client/browser. But that would not be a map for the OSM contributors but a map for consumers. It should be on a different web homepage.
Hi, welcome to OSM!
Just to clarify, OSM is not a map. The default map style is but one consumer of the data stored in the database. Depending on the use case, you can generate very different maps with different focus from OSM geodata. Try out the Layer icon on the right of the main website.
2 and 3 are already being done, though possibly not to your satisfaction.
Point 1 is problematic in the sense that it is also the default style to check that the mapping is correct. Of course, one shouldn’t map for the renderer, but it’s visual confirmation that the update went through. Some things already aren’t shown - if more details get lost, this might further degrade the mapping activity. Not to mention the people that map because their stuff gets shown on the map.
I myself don’t really care that much about it, considering I’m mapping barrier=kerb as lines, though it’s still nice to see my work reflected on the map or some other tool. We shouldn’t underestimate the importance of this.
Hi everyone
Thanks for your inputs which help me better understand and appreciate OSM’s positioning and mission.
I’ll explore alternatives for navigation apps, while also still keeping a lookout on possible refinements for OSM based on ground truths and realities
You are raising sensitive topic. OSM does have problem with cluttering, but not on rendering side. That can always be handled by renderer.
Problem is in editing. In some areas there is so much details that editors are struggling to load data even for high zoom. Editing became painful. Editors do not have good options to filter out data that is not needed to be loaded for current edit.
There is indeed need to make some kind of separation of standard mapping and micromapping.
The simplest would be that some kind of tags (example: trash bins, parking blocking posts on sidewalks, flower pots etc.) to be officially considered as micromapping thus allowing users to easily filter out such data in editors. I mean instead of having to make complex filters by specifying each and every tag scheme that is nuisance, user should be able to simply disable micromapping objects and get rid of them all.
Editors also should be improved to cover this. Most of them, when filters are used just do not display them, but objects are stil loaded and taking lots of resources slowing down editor anyways.
A kind of layer, in other words ?
This is unavoidable* with the current OSM data model and moving away from that to a non-holistic one would lead to some of the same issues that cause concerns with the potential getting rid of way nodes. But I doubt that this is really any substantial kind of performance problem, at least not compared to everything else a editor has to do (for example assembling multipolygons on the fly).
* at least if you don’t want to break existing data.
Hi,
(As some had pointed out earlier, this is talking about “display” of data here)
@Pedja thanks for raising the idea of having filters when doing map edits / editing data on OSM, so that we can selectively choose not to display some of the data when editing. I agree that it can make editing easier, and would also agree if we can streamline the filters so that filtering doesn’t become too complicated. “The simpler, the better”, which is also a new General talk topic that was just created earlier today.
I was coincidentally also just thinking that it might be helpful if there can be filter functions when just viewing on the main OSM base map too. For example, the ability to hide and filter away “Underground Objects” on the main OSM base map, similar to what OSMAnd offers for its offline maps.
In MS Excel, adding filters to an Excel list of 1,000 rows (entries) would enable those working with the 1,000 rows (entries) to sort and manage the data more easily. Filters in MS Excel enable better data management in the Excel. Similarly, I think adding filters for the main OSM base map would help in better sorting and managing OSM’s rich database.
Perhaps the OSM Data Working Group or others working on the OSM website backend could consider setting up filters for the main OSM base map, as the next step of enhancement in OSM?
(DWG person here) Haha, no, that’s not really what we get involved in (although one of our number is also involved in website improvements).
The good news is that OSM data is free to use so that (subject to attribution) anyone can create a map from it.
It’s not that hard to edit an existing map style and remove things, although you need to be a bit familiar with what you are editing. For example, f you edit a map style based on the Shortbread schema you’ll need to look at that schema definition to see what layers there are and what things there are in each layer.
In MS Excel, adding filters to an Excel list of 1,000 rows (entries) would enable those working with the 1,000 rows (entries) to sort and manage the data more easily. Filters in MS Excel enable better data management in the Excel. Similarly, I think adding filters for the main OSM base map would help in better sorting and managing OSM’s rich database.
think of many excel sheets where all your sheets and table cells depend on (reference) some other table cells or ranges, if you hide cells without taking these connections into account, you might perform edits which damage the whole structure but you won’t see them easily because the effects could be hidden.
Hmm I see…
/me screams in OpenHistoricalMap
(Fortunately the desktop editors do come with date filters, but still.)
The map that you see when you visit osm.org has one purpose and one purpose only: to display everything that has been mapped. A database dump, if you will. Concerns about “a usable map for everyone” are misplaced, as the front page map is NOT for everyone.
That‘s clear now. We are at clutter while editing.
Again, that‘s not a topic for the OSM data but the Editor you use. Osm.org offers iD anf Josm, Can I filter out underground pipelines, building Parts etc. if they disturb me?
Filtering is still critical as I may see and change Nodes, also used by filtered objects.
Both iD and JOSM have filtering options. iD is category based, you can turn certain categories on and off. JOSM allows you to filter using its search syntax.