Confusing amenity=parking_space rendering

[jeisenbe]

Expected behavior

• The feature amenity=parking_space is supposed to be used to show individual places where a motor vehicle can be parked within a larger parking lot (amenity=parking or rarely amenity=motorcycle_parking, amenity=bicycle_parking). It's main use is for tagging parking spaces with special characteristics, such as accessibility for wheelchair users or drivers with disabled parking permits or electric vehicle charging or for carpools/vanpools only
• Therefore, these features should be rendered in a way which shows the useful information: the state of access= tags, electric charging, and so on.
• The rendering should not be similar to an area tagged with amenity=parking, which shows the full extent of a parking lot
• The rendering should not be similar to barriers such as fences or curbs, because amenity=parking_space features are only marked visually by paint or plastic lines on the pavement, and there is no barrier to movement.
• The rendering should only be shown at very high zoom levels, since these features are quite small

Actual behavior

• Currently amenity=parking_space is rendered with only an outline, which is in a 50% mix of the amenity=parking outline color and fill color.
• There is no indication if a parking space is limited to wheelchair users, disabled people, electric vehicles, carpools, or any other restrictions
• The outline shows from z18, which is too soon at mid and low latitudes.
• Additional issue: the original proposal for this feature allowed it to be used alone, and for more than 1 parking space if they had shared characteristics. This mapping technique is much more common than I expected, and the current rendering is not easy to understand in this case.

Links and screenshots illustrating the problem

• Large parking lot with many spaces mapped at 50 degrees north: still too soon to show this
  z18 https://www.openstreetmap.org/#map=18/50.60402/3.40649
  

z19 - perhaps ok at this high of lattitude, but note that at the equator this zoom level would look like z18 above.

• Example of an 'amenity=parking_space' next to an amenity=parking_lot, not inside - this mapping was allowed by the original proposal and is still quite common.
  z19 https://www.openstreetmap.org/#map=19/43.61853/3.89878
  

• 3 parking spaces on z19 - it's not really clear that these are parking spaces rather than say a planter surrounded by a kerb or fence. Especially imagine if the central parking space was not there and there were just 2 rectanges alone: this would be hard to interpret.
  

• Small parking lot or space mapped alone in a residential area. I would not have know what this is.
  z19 https://www.openstreetmap.org/#map=19/53.08310/8.85147
  

[kocio-pl]

There is no indication if a parking space is limited to wheelchair users, disabled people, electric vehicles, carpools, or any other restrictions

Thanks for examples of what we might show. I was thinking specially about disabled people icon, but that needs some clarification of tagging first. Also some other special cases like P+R or K+R would be very useful extension of this feature. Refs are another thing worth rendering here. In general these are places which don't interfere with other features, which makes it easier to design symbols.

The cases of standalone parking spaces indicate that probably parking tag is missing first, so an incomplete tagging is revealed, which is expected and positive outcome.

[jeisenbe]

My preferred way to solve this would be to stop rendering amenity=parking_space for now, and then reconsider how to render it at z20 and above, in concert with barrier=kerb and area:highway. These features are all forms of micro-mapping, and require a different rendering context to make sense. I think they could be rendered nicely if we have a very different rendering for z20 which focuses on showing small area features rather than prioritizing showing the large-level road hierarchy like the current style.

It would also make more sense to show this feature if we distinguish between different kinds of parking spaces, especially disabled parking spaces, otherwise showing these features does not provide much information for a general map user.

It might also be possible to improve the rendering by changing it to z19+ only and using a color that is not so similar to the amenity=parking outline. Perhaps the line could be lighter, like a 50% mix of parking fill and white? This would require testing.

[jeisenbe]

P+R or K+R

Is that an abbreviation for "Park and ride" (for places where you park to take a transit vehicle, like a train or bus)? What is K+R?

EDIT: Oh, its "Kiss and Ride" - these are places where you can temporarily stop your vehicle to drop off a passenger who is going to ride the train or bus. In the USA these are not considered parking spaces, but perhaps they are in Openstreetmap.

[jeisenbe]

An issue about rendering icons is that most parking spaces are about 3 meters wide, and rarely are they more than 4 meters wide. At the equator 3 meters is only 10 pixels at z19, so only very small icons could fit at z19 and they would look quite crowded at mid-lattitudes.

It would be more reasonable to show small symbols for special parking spaces at z20 and higher, where the spaces would be at least 20 pixels apart.

(It might also be possible to render the outline or fill color of special parking spaces differently even at z19, but I don't have any ideas about how to do that.)

[kocio-pl]

Is that an abbreviation for "Park and ride" (for places where you park to take a transit vehicle, like a train or bus)? What is K+R?

Yes. K+R is similar concept - "kiss and ride".

My preferred way to solve this would be to stop rendering amenity=parking_space for now, and then reconsider how to rendering it at z20 and above, in concert with barrier=kerb and area:highway. These features are all forms of micro-mapping, and require a different rendering context to make sense.

I agree that it's micromapping and from my experience z18+ is exactly for this kind of objects. Using only typical cartography, z17 is the last zoom level needed. Anything above is useful only for showing more details (even as small as trash cans and bollards) or the way to zoom some things that were obscured by something other. And since micromapping is about scale, the basic context is a scale itself.

It would also make more sense to show this feature if we distinguish between different kinds of parking spaces, especially disabled parking spaces, otherwise showing these features does not provide much information for a general map user.

This is another comment about limiting rendering based on perceived usefulness, not on making map more diverse and rich. On z18+ it's taking away the most basic feedback for mappers, since this style is not only a nice preview for general users. Extending with details is always welcome, but not necessary to show easily visible on the ground objects.

It might also be possible to improve the rendering by changing it to z19+ only and using a color that is not so similar to the amenity=parking outline. Perhaps the line could be lighter, like a 50% mix of parking fill and white? This would require testing.

z19+ does sound to me like too far - these features are relatively big.

[kocio-pl]

An issue about rendering icons is that most parking spaces are about 3 meters wide, and rarely are they more than 4 meters wide. At the equator 3 meters is only 10 pixels at z19, so only very small icons could fit at z19 and they would look quite crowded at mid-lattitudes.

z19 sounds OK for icons. At the same time special cases of parking spaces are not that crowded from my observation.

There is no cure for crowded items anyway (other than adding zoom levels) and we just skip rendering all the other things based on the layers priorities and Mapnik algorithms.

[jeisenbe]

There is no cure for crowded items ... other than adding zoom levels

We don't show all shop icons at z16 because most of them would be blocked by other icons in confusing and inconsistent ways.

I believe we should hold to this rule: a clear majority of icons should be visible on the first zoom level when they are shown. If half are blocked by an adjacent icon which is rendered with the same or higher priority, then this means they are being shown too soon.

So if we rendered 12 pixel x 12 pixel disabled parking icons for parking_space=disabled at z19, this might just work in Warsaw (54 degrees N) where a parking space is ~18 pixels wide, but it would not work in the tropics where a z19 parking space is only 10 pixels wide: half of adjacent icons would be blocked by collisions with neighboring parking space icons.

You are right that adding z20 would change this math.

[kocio-pl]

It depends on assumption that there are a lot of crowded special cases, which I believe is not true. There are also possible inditations like additional color lines inside etc.

But I think this is too early to make such detailed analysis, since first thing is to make tagging more specific than just indicating how many special spaces are on the parking (only for capacity:disabled currently, anyway). Flexible tagging is needed for a single space to cover all typical special cases and allow for more of them.

Also according to https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space :

Mapping parking spaces is an addition, not a replacement, to mapping a whole parking lot with amenity=parking.

so any example of parking space without the parking context is really an incomplete tagging, as I supposed.

[kocio-pl]

z19 - perhaps ok at this high of lattitude, but note that at the equator this zoom level would look like z18 above.

It looks as it should at both levels - the outline is clear and not too strong, no other objects are competing visually, shapes and distribution of them are very common and the parking gives the familiar context. In fact, this is the most typical kind of object I expect to find on big parking, apart from the inner roads.

In high latitudes there are different visual problems, but really tough and populated all over the place, like a lot of crowded small buildings which render as tiny outlines noise (which is more or less a fair depiction of reality), together with tertiary roads glued to the buildings even at z18 (which is an artifact of a road system inconsistency - see #3540 (comment)). From what I have just looked, parking spaces are used only as a wrong replacement for parkings, so the solution is to correct tagging there - which current rendering helps to identify.

[imagico]

I agree with the description of the problem. This is a good example of the kind of problems that result from giving priority on feature additions over map readability.

There is no usable room in this style in terms of thin, faint and dark lines between the stronger rendering of barriers and the weaker rendering of landuse outlines at high zoom levels like for landuse=residential. In fact we still have cases where the outline rendering is too dark to be properly distinguished from barriers - like with quarries (example: https://www.openstreetmap.org/way/28555341). There is definitely no room in between there to add another readable class of line rendering.

[Fizzie41]

Just been wondering about this topic. We render normal car parking areas, motorbike & cycle parking, but not accessible / disabled parking? e.g. https://www.openstreetmap.org/edit#map=19/-28.16782/153.53832 (you may need to move slighter closer in to see motorbike parking top-right corner) has all four types of parking mapped, but https://www.openstreetmap.org/#map=19/-28.16789/153.53822 shows that only 3 are rendered. In this day & age, not rendering accessible spaces seems a bit strange?

Just a normal wheelchair icon should be sufficient to indicate them.