Streetside parking should be rendered differently than normal parkings

[413Michele]

Expected behavior

Streetside parking is only rendered at zoom 19 (or maybe 18 too) in a less intrusive way than a blue P

Actual behavior

Each parking tagged with parking=street_side shows a blue P

Links and screenshots illustrating the problem

A new way of tagging streetside parking was approved a few days ago, with the goal to clarify how to map this type of feature.
Given that this method only adds an additional tag to the already in use amenity=parking tag, the parking spaces are represented each with a blue P, the same as actual parkings.
As a representation, this is probably too heavy, and something similar to parking spaces should be used

Zoom 18

Zoom 19

Link to the area of the screenshots

[imagico]

About 4000 uses so far, nearly all of them added during the last month, coverage is patchy at a hand full of locations in Europe so far.

Would need to be seen if there is broad adoption of this by mappers. Could also be useful to look at other forms of tagging streetside parking in the wider sense, like parking=lane (about 12k uses) and parking:lane:* on roads (about 200k uses).

[413Michele]

Maybe I should have waited a bit, the proposal was only approved on the 28th of November. However, I think it's useful to begin tracking the question. The (admittedly limited at the moment) issue here is not of absence from the map but of an existing symbol spam on the map

[imagico]

It is completely fine to open this issue here - We just tend to be careful in making rendering decisions based on new tags the adoption as well as exact meaning of which has not been established in practical use. This is especially the case if - like here - the tag would be used to adjust the starting zoom level because that can incentivize people to misuse the tag as an importance tag (i.e. apply it to any parking they want to only be rendered later).

[jeisenbe]

Are we sure that this is only an issue with parking=street_side? There can be many small off-street parking lots, for example in automobile-oriented commercial zones of American cities, especially where many older buildings were torn down and the space used for parking instead. I thought @Adamant36 had showed an example of this problem in a previous issue, but can’t find it now. However you can see what I mean here: https://www.openstreetmap.org/#map=17/40.58691/-122.39157

See also #4197

Right now we render all amenity=parking polygons at z17, without regard to size, since that is the level when nodes are rendered. But we only render bike parking, motorcycle parking and parking structure entrances at z18 and z19. Perhaps we could change amenity=parking nodes and small areas to only render at z18 and up, like the other kinds of parking:

openstreetmap-carto/style/amenity-points.mss

Lines 1445 to 1451 in b10aef3

	[feature = 'amenity_parking'],
	[feature = 'amenity_bicycle_parking'],
	[feature = 'amenity_motorcycle_parking'],
	[feature = 'amenity_parking_entrance'] {
	[zoom >= 14][way_pixels > 750],
	[zoom >= 17][feature = 'amenity_parking'],
	[zoom >= 18] {

Another issue is that the current parking background color is not very distinctive, so if we don’t show the icon it might not be clear what we are looking at. See #3891 and #3974.

[jeisenbe]

@imagico what do we think about using [way_pixels > 750] all the way to z18 for polygons, and still rendering the points at z18/z17?

About 89% of amenity=parking features are mapped as areas, and mapping as an area is recommended in the wiki, except when this is not possible. I don’t think this would create excessive pressure to re-map nodes as areas or vis-a-versa.

[imagico]

You mean showing the symbol only for way_pixels > 750? at z17/z18 but showing it for nodes from z17?

I am not sure. Would need to look at the data. My assumption is that amenity=parking on nodes is primarily used in non-urban settings where mappers want to indicate this is a place where people park their cars but where there is no defined and verifiable extent of this parking area.

The thing with this issue and streetside parking is that the polygons might be quite large (see the samples by @413Michele) - but the large symbol might still hide/block other important features. That is because streetside parking is by definition narrow. So way_area filtering does not really help that much with this issue.

Another idea is not to start with a bold 14 pixel symbol at z17 but with a smaller symbol. We have so far not used POI symbols that vary across zoom levels with very few exceptions (fountains, trees) but in principle that can work quite well. You could for streetside parkings also consider a non-blocking single symbol pattern like i showed for sport pitches. That would work better with a more distinctive color probably of course.

[Adamant36]

I thought @Adamant36 had showed an example of this problem in a previous issue, but can’t find it now. However you can see what I mean here: https://www.openstreetmap.org/#map=17/40.58691/-122.39157

That was one of my examples. The other one was here https://www.openstreetmap.org/#map=17/40.80275/-124.16301

If I remember correctly the suggestion at the time was to tag the ones that I can as private so they don't stand out as much. Although, I don't think that's a good solution because I don't have access to that information and it would be kind of tagging for the rendering if I was doing it mostly to make the map look better anyway. Really, it should it look good out of the box without the need for extra tags.

[jdhoek]

(I am a co-author of the parking=street_side proposal. @SupaplexOSM is the other author.)

While size gives some indication of relevance for a parking amenity, it is not a complete solution. Some small parking areas can still be very relevant in terms of navigation, like a small parking=surface at some road-side attraction.

With street-side parking it is much the opposite: this whole class of parking amenity is much more ambient. It is relevant for navigation in a broader scope (e.g., “Is there a place to park near this shop?”) rather than something specific to navigate to (e.g., “Show me the quickest route to the parking lot for the Biggest Ball of Twine in Minnesota.”). parking=street_side is very relevant for orientation and generally in getting a feel for an area. In this sense it acts much like areas of grass, scrubs, ponds, buildings, and the roads themselves. You would expect them rendered, but not quite as verbose as a parking lot or multi-storey parking garage.

So when considering de-emphasising parking amenities, please consider treating those tagged with parking=street_side as a single group, disregarding size.

In the proposal we showed a couple of rendering examples to illustrate our point:

Personally, I am quite fond of the smaller P variant.

[polarbearing]

I'm in favour of a smaller P for smaller areas, I would make it even smaller than shown above, e.g. the size of the letters in labels (like the B in Bäcker above). Thus initially, we have two sizes of P directly related to the pixelsize of the area, which can be replaced depending on zoom level.

However, the idea to group several parking=street_side along one particular road to assign one single icon might be difficult to implement from the coding approaches here in Carto.

[jdhoek]

Thus initially, we have two sizes of P directly related to the pixelsize of the area […]

As mentioned above, for parking=street_side rendering should probably not vary based on size of the mapped area.

This should probably be considered for other parking values as well. Size is a decent indicator for parking=surface (and the lack of parking tag which I believe implies parking=surface).

parking=lane can probably be treated similar to parking=street_side.

For parking=multi_storey and parking=underground size cannot be inferred as easily. Here capacity might be more useful to consider.

parking=layby on the other hand might benefit from rendering sooner when zooming in rather than later. These are parking amenities that can be used by motorists for a break along a major road (usually outside of built-up areas).

However, the idea to group several parking=street_side along one particular road to assign one single icon might be difficult to implement from the coding approaches here in Carto.

If the rendering is subtle enough the individual parking areas can be rendered, just as they are now. The grouping is not necessarily relevant to rendering.

[cicku]

It could be surface parking but surface lot does not necessarily endorse curbside. To distinguish curbside parking, I suggest using "𝙿̲" or "P̲" (underlined P) instead.

[Adamant36]

It could be surface parking but surface lot does not necessarily endorse curbside. To distinguish curbside parking, I suggest using "𝙿̲" or "P̲" (underlined P) instead.

Is there even a need to distinguish curb side parking? It's not like people can't tell that's what it is from looking at the map anyway and parking is parking. Rendering it some special way compared to "normal" parking seems like rendering for it's own sake and not because it would serve an actual useful purpose. I don't think that people would necessarily understand that something like an underlined P means "curb side parking" either. To me it seems like an icon for "surface level parking" and that's stretching it. Nothing says "curb side" about it though.

[jdhoek]

I have offered a proposal for parking=street_sde rendering in #4301. This follows one of the concepts that was part of the original tagging proposal. Please have a look!