-
Notifications
You must be signed in to change notification settings - Fork 819
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don’t render amenity=parking access=private with low capacity #4197
Comments
If the issue is cluttering of the map, it's possible that this could be resolved by filtering out parking areas with small areas. However, since we would still want to render nodes tagged with Using the |
On the french rendering, I'm using more and more the pixel size of objects to prioritize rendering or decide not to render and not only by zoom level. For parkings, I prioritize multistorey ones. capacity=* could be used as it is more often set on large ones (and as usual, rendering them using this tag will be an incentive to add it). |
Given example seems to not be cluttered to me. And if that would be considered as clutter that should be fixed then we have many, many, many things to remove. I would be against that.
That seems ridiculously unlikely. And if someone believes his/her misinterpretation of an online map over signage - then I hope that they will lose traffic license before killing someone in traffic accident caused by their stupidity. If we would cater to that level of things, then we would need to stop rendering one-way arrows - what if someone follows badly mapped one-way road?
Not only, land usage is interesting for many things. |
It’s a matter of opinion. I’d say that given that the information about private parking is useless to almost everyone except the house owner, it shouldn’t be presented so obviously. If you zoom out to zoom level 17 or 18 you might consider it to be cluttered.
I’ve filed this issue on the basis that it has happened multiple times in different private car parks around my area. Typically with parking areas in small communities, not in urban centres. They may not have signage because the presumption in the UK is that land is private unless signed otherwise. Regardless of whether the people doing the illegal parking should have a license, the fact that the parking is happening is a demonstrable problem.
That’s an unhelpful slippery slope argument. I haven’t asked about stopping rendering one-way arrows, and I’ve tried to make this request as constrained as I can (by restricting it based on capacity).
And the tagging is still there to show that, should anyone want to consult the database. But I think that drawing a ‘P’ (even if it’s semi-transparent) on the default map is more unhelpful than it is helpful, for general purpose users of the default carto rendering. |
The truth is that situation is a bit complicated, as it is basically on level of personal preferences. I know that I removed/proposed removing what I considered as clear clutter and at least some people treated as removal of useful detail. And in this specific case I claim that it is not clutter but potentially useful detail. But I understand that others may think differently. But there were also specific additional arguments beyond "it is an unreasonable clutter" that appeared in this issue. And I think most of them is quite weak.
Note that I disputed "information that they are there is not useful to anyone except the owners of those houses". I would claim that knowledge how much land is turned into parkings is generally useful - both for someone interested in vacation in area that is not significantly parking infested or for someone interested in land usage and so on.
The problem is that if we would agree than this argument is valid then we should remove many other things.
I am not claiming that illegal parking is not happening, I am claiming that chances that it is caused by openstreetmap-carto seem vanishingly small to me.
So people are ignoring that parking is not marked as public on the ground. |
One of the main goal of the style is:
Removing rendering of some parkings would be against that goal. |
OK, how about changing the rendering of amenity=parking access=private to be a P with a strike through it (regardless of the parking area’s capacity)? i.e. https://commons.wikimedia.org/wiki/File:Road_Sign_No_Parking.jpg |
We use single color icons. So designing a strike through could be hard to design. This makes the symbol probably more visible instead of less visible. |
A place where parking is forbidden for everyone is completely different from a place where private parking is allowed. Beside the colour issue, any striking through would suggest that it is forbidden. |
It also may encourage tagging for renderer and misusing |
That is a bit offtopic here, as it is not tagged as a private parking. |
Many of these are wrongly mapped amenity=parking_space, which would be rendered just with a thin grey line w/o icon. |
@skfd Thanks for bringing this issue on table. The description might be too narrow, but the problem is clear for me. I would say that parking icons clutter the map on many city locations on z17. They are dominating there, but it doesn't look to me like other zoom levels are affected, but correct me if I'm wrong. It also doesn't matter if they are private or public. I would propose to change the topic to reflect that The solution seems to me pretty easy: tune the pixel limit for showing icons on that level, so the icons don't show for smaller areas. The patch would need just some testing which value fits the best. |
The tricky part is that either
|
I don't understand the problem, could you provide an example or give more specific description? |
Case 1: parking as nodes will be treated as having 0 area unwanted result: areas where important parkings are mapped as nodes will get worse rendering (mostly areas with lower amount of mappers and remote/forested places) Case 2: parking as nodes will be treated specially there will be situation where parking mapped as node will be displayed and parking mapped as small area will not be displayed as result deleting parking area and mapping it as node may cause it to appear on map |
OK, now I see, thanks. Case 1 seems to be fair for me, because even important parking is usually a part of something more important which will still be rendered as before. |
I opened a similar awhile back due to the area below that was also shot down where people told me it wouldn't be a problem if the parking lots had access tags. I don't think adding access tags would solve the problem though, because your still left with a ton more P symbols then anything else and most of them probably aren't "private" parking anyway. The solution also assumes someone is going to add access tags to all those parking lots. Which isn't likely to be the case any time soon and rendering something well should not be contingent on adding an extra tag anyway. As it's technically tagging for the rendering. At the time I suggested removing the P symbol altogether. I guess that's not really an option for some reason though. Maybe it would be for smaller parking lots though. I think it would be a good compromise between a ton of map clutter and still rendering parking lots that people might want to see on the map. It's extremely doubtful that most people care about a good majority of the parking lots in my example. It's not like they couldn't tell they are parking by just the area being rendered anyway if they do though. That said, this seems to be mainly a problem at z17 and maybe just rendering a blue dot at that zoom level would be an option, or just not rendering any symbol for parking lots at that zoom level. Especially extremely small ones. |
Would you like to produce a test code for this? I'd like to test that. |
Expected behavior
I think small, private car parks should not be rendered at all in osm-carto. Typically, this kind of car park is a couple of parking spaces assigned to specific houses, but grouped together rather than being on the private curtilage of any specific house. They end up being mapped, as they occupy some amount of space. But the information that they are there is not useful to anyone except the owners of those houses and people visiting them. It does not need to be on a public map, clutters the map, and potentially confuses others into parking where they’re not supposed to.
So I think anything with amenity=parking access=private capacity<10 should be rendered with the grey parking background, but not have a ‘P’ rendered.
Actual behavior
Lots of small parking areas are rendered, and the fact they’re lighter/transparent is not obvious because there’s no public car park to contrast them with. People get confused and park where they’re not supposed to. The map is cluttered.
Links and screenshots illustrating the problem
https://www.openstreetmap.org/#map=19/54.32177/-2.75600
The text was updated successfully, but these errors were encountered: