Filter small parking areas up to z17

[kocio-pl]

Currently we are filtering "P" letters if the parking area is too small (https://github.com/gravitystorm/openstreetmap-carto/blob/master/amenity-points.mss#L313). But from z17 we render them unconditionally (https://github.com/gravitystorm/openstreetmap-carto/blob/master/amenity-points.mss#L1042).

Unfortunately this is too early, since without filtering there are some small parkings, where we render bigger "P" than the area and create clutter. I think we should use filtering also on z17, because on z18 the letter will probably always fit inside the area, which is a good rule of thumb IMO.

BTW: I guess both parking-related sections could be close to each other to make this code more clear.

Warsaw, z17
before

after

Poznan, z17
before

after

[matkoniecz]

Is it intentional that motorcycle and bicycle parkings are not affected?

[kocio-pl]

I have not seen such problem with them on the map yet, they are much less frequent than car parkings and I don't even know the places where it could do any harm, so after some deliberation I left them unchanged.

[jojo4u]

The example area has not good tagging. Amenity=parking is geared towards car parks. Parking along the street is tagged with parking:lane=* and if one wants to map the area of street parking the street area proposal proposes amenity=parking_space.

[pnorman]

I'm iffy about this, this looks like a likely case of mistagging. Trailhead parking is often very small and relevant at z17.

[matkoniecz]

The example area has not good tagging. Amenity=parking is geared towards car parks.

Interesting. I used amenity=parking as described on wiki, for parkings of any size.

Use amenity=parking tag to identify a facility use for use by the public or by customers or other authorised users for the parking of cars, trucks, motorcycles, etc.

A place for parking cars

http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking

amenity=parking_space.

This is for "A single parking space on a parking lot" (though wiki has also contradictory "use capacity=* to define the number of parking spaces it represents").

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

[matkoniecz]

OK, now on wiki I see "For parking spaces along streets see parking:lane=*.".

[kocio-pl]

@jojo4u This can be a problem with tagging, but I'm not sure what tag would be proper. For example this one (from Poznan example):

http://www.openstreetmap.org/way/421652588

is definitely not a parking:lane=* (which BTW is rather just a property of the road, not a standalone tag) - it's a special, small parking area separated by grass, not a general lane on the street. The difference between amenity=parking_space vs amenity=parking is not clear (it probably is about part of the parking - like marked row of places - and there's no restriction on lowest parking size or location). We were discussing it on polish forum, but came with no clear output (@matkoniecz was active there):

http://forum.openstreetmap.org/viewtopic.php?id=53727

There are also specially marked parts of the street (not a lane) or even crossing the line between a road and footway area or service roads with some wider parts where the cars stay with no clear marking. It makes a problem of parking tagging complicated, so it's hard for me to say it's "mistagging".

@pnorman I guess "trailhead parking" means a parking near the trail start/entry for tourists? I don't want to get rid of the area color, only the letter. This is probably another case of a more general problem that outside the residential areas every amenity is more important and should be rendered earlier or stronger.

[matthijsmelissen]

I agree dropping parking from z17 likely causes more problems than it solves. Thanks for the suggestion though @kocio-pl!

[wmyrda]

If I got it right now in the code rendering of parking letter has been dropped altogether from z17? I like the idea from kocio more where we differentiate among small and large parking spaces so we still may render parkings on z17. If parking letter on large parkings is dropped than casual viewer might have harder time to differentiate that yellow space form amenities visible in the same color. In less tagged areas one might wonder if that is stadium or school just without pitch area or building being drawn on the map.
That is where the kocios code comes into help as in parking spaces which are not part of the road and we are not able to distinguish if there is 3 or 4 parking spaces having whole area tagged as amenity=parking seems more appropriate, but having the parking icon in the carto is an overkill.
https://cloud.githubusercontent.com/assets/5439713/16103038/3df68baa-3375-11e6-8abe-95de3f6d0fd6.png