Render amenity=parking_entrance with access=customers|permit

[paganella31]

Currently, the parking_entrance icon is only rendered when access is different from 'private', 'no', 'customers', 'permit' and 'delivery':

openstreetmap-carto/project.mml

Line 1616 in 3c60a7b

AND (access IS NULL OR access NOT IN ('private', 'no', 'customers', 'permit', 'delivery'))

While I can see the point for the first two to be excluded (as also noted in #3672 (comment)), I think the last ones are worth considering since they provide useful information to the general public. For example, to know the entrance location of a supermarket/mall/etc. underground parking.

Rendering could possibly be done using a lighter icon, much like with the ordinary amenity=parking tag.

[imagico]

The cited logic is the result of #4717 where we unified the logic for access tag interpretation on POIs and removed the problematic catch-all - resulting in the binary classification that access=private|no|customers|permit|delivery is restricted while anything else is unrestricted. This rule is applied to all POIs with a distinct handling of access tags.

Now i understand the idea that parkings of public shops legally limited to customers but often without substantial enforcement for some map use cases are closer to public parkings than to private parkings. But keep in mind that:

• access=customers has a very broad meaning. The guests-only parking of a hotel qualifies just like the parking of a shop that is free to anyone who is going shopping.
• we are talking about access restrictions to the amenity=parking_entrance, not to amenity=parking. My impression is that much of this tagging is incorrectly applied to the amenity=parking_entrance while it is meant to apply for the parking. If we'd further differentiate interpretation of access tagging on these that could further incentivize this problematic use of tagging.

[dch0ph]

This looks like a bug in PR #4717. Currently amenity=parking_entrance is not selected by the SQL query if access is a member of the list, which is surely not the intention.

Shouldn't the selection condition read:
access IS NULL OR access IN ('private', 'no', 'customers', 'permit', 'delivery')
?

P.S. But I'm puzzled why this condition is applied only to parking_entrance and not to parking. If the logic of the PR was to ignore access=foo (and not treat it as as restricting access), then this condition is unnecessary.

[imagico]

This looks like a bug in PR #4717. Currently amenity=parking_entrance is not selected by the SQL query if access is a member of the list, which is surely not the intention.

It is, #4717 unified the access tag conditions for amenity=parking_entrance (distinguishing between rendering and not rendering) and amenity=parking (distinguishing between normal rendering and lighter color rendering). This could be re-considered - but keep in mind that different conditions for both could be confusing at least in cases where both the amenity=parking_entrance and the amenity=parking are shown (that is for non-underground parkings).

Shouldn't the selection condition read:
access IS NULL OR access IN ('private', 'no', 'customers', 'permit', 'delivery')
?

No, that condition would be true for features with no access tag applied and those with the listed limited access values. It would be false for either access=yes or access=foo. We definitely do not want that.

Keep in mind that we are talking about access tagging on the amenity=parking_entrance, not on the multi-storey/underground parking the entrance leads to.

[dch0ph]

OK, I see this was the intention. It just seems counter-intuitive for access=customers to make the parking entrance disappear, while access=foo is passed through, e.g. for a multi-story car park restricted to railway users:

Personal render without access selection (i.e. everything passes, with reduced opacity for restricted access):

Plus: Clearer what is happening when road "joins" building
Minus: Doesn't look that pretty (too much clutter).

[BertMule]

Please render the entrance.
It is relevant for customers to find the access to their hotel, restaurant, shopping mall, or whatever.
My example: George Marina.

Now it is invisible. And pointless & frustrating to model it at all.

Just mark it differently from public access.

Don't render underground garages #3506.

[imagico]

The shown example is an entrance (https://www.openstreetmap.org/node/9201255147) to an unmapped parking. Based on the data it is impossible to determine if this is a private parking or just a private entrance to a public parking. See also discussion above in #4890 (comment)

And this issue is about changing interpretation of access=customers/permit, not access=private. Private parkings (for example of apartment buildings) and private (service) entrances to public parkings are a completely different matter.

[dch0ph]

Irrespective of this particular example, I do think the question of access rendering on parking_entrance needs a fresh look. As far as I'm aware, this is the only case where setting an access restriction can cause an POI not to be rendered at all (as opposed to reduced opacity), so we already have a differentiation.

So mapper 1 sees a parking_entrance to a hotel and adds it without any access information (indeed might not add the associated parking at all since it is invisible). Entrance appears on map. Happiness (or at least mild satisfaction) ensues. Mapper 2 adds more detail, adding access=customers. Entrance disappears as if it were never mapped! This is not intuitive behaviour, either to the mapper or map user (who would like to find the parking entrance, often tricky).

Background figures:
192k parking entrances
~33% have an access tag.
Mostly this is to mark a private parking entrance (24% of total).
Only 4% of the total are access=customers (but still 8.5k)

There are various options:

1. We could argue that access restrictions only apply to the parking itself. The logic of this is to ignore the access tag and render all parking entrances. I'm not sure this is desirable as it will result in a lot of "full strength" (but uninteresting) symbols in a typical city area:

Note how, quite reasonably, none of these have an associated parking POI.

2. Use the same logic as other POIs, where restricted access (including customers) causes the POI to rendered with reduced opacity. This would be more consistent, but I guess the original reason for suppressing parking entrances with access=private etc. was that reduced opacity doesn't look great as it is always sitting on top of something.

3. Accept that parking entrance is already a special case, and be conservative about applying the access restriction - allow through access=customers, either with reduced opacity or "full strength" (i.e. same as no access restriction).