Skip to content
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

Open
pwithnall opened this issue Aug 27, 2020 · 20 comments
Open

Don’t render amenity=parking access=private with low capacity #4197

pwithnall opened this issue Aug 27, 2020 · 20 comments

Comments

@pwithnall
Copy link

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

image

@jeisenbe
Copy link
Collaborator

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 amenity=parking, this would lead to the odd result that mapping the parking as an area might cause the symbol to disappear.

Using the capacity= tag is unlikely to work in most cases, because only 6.6% of amenity=parking features have a capacity= tag:
https://taginfo.openstreetmap.org/tags/amenity=parking#combinations

@cquest
Copy link

cquest commented Sep 1, 2020

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.
It is computed by PG: way_area / (!pixel_width! * !pixel_height!) as pixels

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

@matkoniecz
Copy link
Contributor

matkoniecz commented Sep 10, 2020

The map is cluttered.

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.

potentially confuses others into parking where they’re not supposed to.

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?

But the information that they are there is not useful to anyone except the owners of those houses and people visiting them.

Not only, land usage is interesting for many things.

@pwithnall
Copy link
Author

The map is cluttered.

Given example seems to not be cluttered to me.

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.

potentially confuses others into parking where they’re not supposed to.

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.

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.

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?

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

But the information that they are there is not useful to anyone except the owners of those houses and people visiting them.

Not only, land usage is interesting for many things.

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.

@matkoniecz
Copy link
Contributor

matkoniecz commented Sep 10, 2020

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.

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.

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.

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

The problem is that if we would agree than this argument is valid then we should remove many other things.

the fact that the parking is happening is a demonstrable problem.

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.

They may not have signage because the presumption in the UK is that land is private unless signed otherwise.

So people are ignoring that parking is not marked as public on the ground.

@HolgerJeromin
Copy link
Contributor

One of the main goal of the style is:

It's an important feedback mechanism for mappers to validate their edits and helps to prevent unfavorable fragmentation of tag use.

Removing rendering of some parkings would be against that goal.

@pwithnall
Copy link
Author

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

@HolgerJeromin
Copy link
Contributor

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.
But IMO often it would be nice to distinguish access=private from access=customer.

@polarbearing
Copy link
Contributor

a P with a strike through it

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.

@matkoniecz
Copy link
Contributor

It also may encourage tagging for renderer and misusing amenity=parking access=no to use for "no parking allowed" areas.

@skfd
Copy link

skfd commented Sep 18, 2020

Please allow me just chime in with even funnier example

image

@matkoniecz
Copy link
Contributor

matkoniecz commented Sep 18, 2020

That is a bit offtopic here, as it is not tagged as a private parking.

@polarbearing
Copy link
Contributor

Many of these are wrongly mapped amenity=parking_space, which would be rendered just with a thin grey line w/o icon.

@kocio-pl
Copy link
Collaborator

kocio-pl commented Sep 19, 2020

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

@matkoniecz
Copy link
Contributor

The tricky part is that either

  • node parkings are also not displayed at that level what will degrade map in cases where quite big ones are mapped in this way (mostly areas with lower amount of mappers and remote/forested places)
  • or small parking mapped as an area will not be shown and the same parking mapped as node would be shown

@kocio-pl
Copy link
Collaborator

I don't understand the problem, could you provide an example or give more specific description?

@matkoniecz
Copy link
Contributor

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

@kocio-pl
Copy link
Collaborator

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.

@Adamant36
Copy link
Contributor

Adamant36 commented Sep 19, 2020

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.

Screenshot 2020-09-19 152648

@kocio-pl
Copy link
Collaborator

Would you like to produce a test code for this? I'd like to test that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants