Adding rendering for amenity=parking_space

[kocio-pl]

Resolves #428.

It adds visual clues for bigger parking areas. It's rendered the same as parking, but without "P" letter and probably without name, I think z18+ is good enough. This tagging scheme is used 118 468 times.

Example 1
Before

After

Example 2
Before

After

[kocio-pl]

It can be also rendered as just the outline, which would be good to detect lack of amenity=parking, like here:

Example 3, z18

[polarbearing]

I am not in favour of mapping individual parking spaces in the first place. In my perspective, it is too much data for too little gain.
We are getting closer to painting the world as a replication of aerial imagery, instead of providing useful abstractions.
Consequently, I am against rendering in this style.

As your examples show the tag is even used inconsistently, sometimes for the area of a collection of car spaces, sometimes for individual spaces.

The lack of amenity=parking is detected by not showing the parking fill and icon.

Thanks for the experiment, but my vote is gainst.

[kocio-pl]

Thanks for the comment.

I think this is pretty unobtrusive element - it is only relevant to the parkings and I want to show it only on highest zoom levels. Typical problem with so detailed data is that they can be in very crowded places (and we can't predict it) and can be important/visible on lower zoom levels (especially z17 and lower), but this case is much easier in my opinion. Of course this object is not only unobtrusive, but also useful - I still think this actually helps to better understand the structure of the space.

[andrzej-r]

As there are over 118k amenity=parking_space tags (almost 1% of all amenity tags) in taginfo we shouldn't dismiss this tag as uninportant.

I'm in favour of rendering it, provided it is restricted to high zoom levels.

[kocio-pl]

I think just the outline is a proper way of rendering it - it should look incomplete without amenity=parking.

What about names? I guess it makes sense to start rendering them from z20 probably - and we can add this in the current style. OSMF just won't render them, but this style is not tied to OSMF servers and there are people who render z19+ tiles.

[dieterdreist]

sent from a phone

On 27. Feb 2018, at 13:17, polarbearing ***@***.***> wrote: I am not in favour of mapping individual parking spaces in the first place. In my perspective, it is too much data for too little gain.

I completely agree for all parking spaces, but IMHO the tag is useful for special parking lots like disabled, or pregnant, or women, etc. We can evaluate if we want to show those.

[andrzej-r]

Why not. z20 is fine for the name. Likely it wouldn't fit at z19 anyway and it may provide an incentive for osmf to render z20 someday.

[kocio-pl]

I thought we have started with z20+ details recently - see #2936 (comment) (entrances) - but it seems it's even older (raceways):

openstreetmap-carto/roads.mss

Line 1542 in 730991a

[zoom >= 20] { line-width: 24; }

Special parking lots can be shown in a special way - z20+ or maybe even z19+ - but I have yet no idea how should they look like. Any ideas?

[polarbearing]

almost 1% of all amenity tags

this is just because on one real amenity=parking come 20-100 markings of spaces. Remember these are not geographical features, they are just white lines on the asphalt.

I think it clutters the map, and is more ugly than areas where every garden fence is mapped.

This style has also the mission to tell the mapper what OSM considers as important. We do not render the type of sport on pitches yet, but we would replicate white lines :-(

I agree with @dieterdreist that disabled etc spaces might be the exception.

[kocio-pl]

I think it clutters the map, and is more ugly than areas where every garden fence is mapped.

Look closer here: garden fences - and especially gates - are generic feature we render from z16 I guess and we have no way to distinguish them from single gate and bigger fenced properties. This is a clutter for me and even worse - it's hard to avoid.

With parking space we know exactly that it's a smaller part of the parking and the scale would never be low to show them. And on such high scale and on the parking (which tends to be empty space for cars with just a small roads and occasionally patches of grass) there is no clutter, just precise mapping instead of general areas only.

This style has also the mission to tell the mapper what OSM considers as important. We do not render the type of sport on pitches yet, but we would replicate white lines :-(

1. I strongly disagree with "one size fits all" assumption. We use different scales to show different things. It would be bad to show parking spaces on the city or country plan - they are unimportant on this scale, but so are gates or post boxes, so we don't start to show them there. On z18+ we show them, but we don't show the city or country name - because on this scale including such labels would be a clutter. So this is all relative to the scale and we respect this rule here.
2. It's different than with pitches: we do render parkings, for a long time, so parking spaces are just next step. We didn't skip bigger step, but extending the look with details which are relevant to this type of object. If you're not interested with parking details, just don't zoom to see them - and you don't do it by accident, because parkings are quite visible areas.

[kocio-pl]

As your examples show the tag is even used inconsistently, sometimes for the area of a collection of car spaces, sometimes for individual spaces.

It's preferable to tag each space separately, but it's also explicitly allowed to map groups:

Each single space should be mapped as a separate area. Exceptions for using one area to represent more than one space:

[ https://wiki.openstreetmap.org/wiki/Tag%3Aamenity%3Dparking_space#Usage ]

[imagico]

This style has also the mission to tell the mapper what OSM considers as important. We do not render the type of sport on pitches yet, but we would replicate white lines :-(

This statement is both in conflict with the purpose of this style and with the idea of OSM in general. There is no authority in OSM that decides what is important and what not - anything that is permanent, verifiable and public in some way may be mapped.

This is not meant to imply that rendering parking spaces in the form suggested here is a good idea - how to show something which can in principle be reasonably shown and if this can be reasonably implemented in this style is a completely different story.

[kocio-pl]

I have found no clear tagging for special parking slots, it's just a vague note on the wiki page:

https://wiki.openstreetmap.org/wiki/Tag%3Aamenity%3Dparking_space#Disabled_parking_and_other_access_restrictions

There are almost 11% cases with wheelchair=yes, but that might mean just wheelchair friendly, not a parking slot for disabled people, so I don't see a chance to select any special cases. If we would be able to select them, maybe we could use different outline color (like red or blue), but I'm not sure about it.

[imagico]

The established tagging for parking reserved for disabled is capacity:disabled=* - see:

https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking
https://wiki.openstreetmap.org/wiki/Key:capacity
https://taginfo.openstreetmap.org/keys/capacity%3Adisabled
https://taginfo.openstreetmap.org/tags/amenity=parking_space#combinations

[kocio-pl]

Thanks for the ideas. However capacity:disabled does not tell us if the whole space is for disabled and I'm not sure if we should render it in a special way. Maybe we need some logic, like checking if capacity=1 or capacity:disabled==capacity to be sure that it's the whole area - I hope that's doable with CartoCSS.

That still leaves us with other problems:

1. It's documented only for parking, not amenity=parking_space.
2. What about other special slots (capacity:parent or capacity:charging)?
3. How should we render them?

If we can't find the solution now, we can just skip this for now and try again later, of course.

[polarbearing]

Leaving the 'disabled' case aside, my vote remains 'against rendering'.

Anyway, from the visual side, have you tried white lines? Dark thin lines are barriers.

[kocio-pl]

1. White doesn't work with proper tagging (with amenity=parking in the background), only for dark backgrounds - see the examples below.
2. This is the same color as the parking outline and barriers are black in general (excluding hedge for example). However this is just a simple reimplementation of similar features, which is not the only possible choice - we might make it lighter.

[kocio-pl]

@polarbearing Which color do you propose? To make sense, it should be probably something between parking outline and parking background.

[kocio-pl]

The mix of parking background and parking outline is better for me - it's more subtle, yet still visible, so the mappers have the feedback while not making noise nor suggesting that it's a barrier:

[kocio-pl]

Any additional comments, improvements or reviews?

[polarbearing]

So many houses still to be mapped, and we encourage the armchair fraction to focus on redrawing the paint on the asphalt. :-(

[kocio-pl]

I wouldn't apply such simplistic logic. We have tons of any things missing, for example I miss landuses more than buildings (so I could see how the area is used, buildings are details that could be added later on).

Please note however, that they've tagged 120k+ such paintings without any encouragement from us, so it must have been already important enough for them.

[jdhoek]

So many houses still to be mapped, and we encourage the armchair fraction to focus on redrawing the paint on the asphalt.

@polarbearing That is highly dependent on the area being mapped though. In the Netherlands all houses are mapped, because we perform frequent imports from the national registry. I agree that it might not be very fruitful to map individual parking spots if the surrounding buildings aren't there, but I can see the appeal in areas that are mapped in more detail.

@kocio-pl I like the mix of parking background and parking outline example.

[jdhoek]

@kocio-pl It looks like amenity=parking_space is now rendered without a background colour set instead of the background colour of amenity=parking. Is this intentional?

If the two ways of mapping parking facilities coexist, shouldn't their colour schemes match?

[kocio-pl]

Yes, it's made this way exactly to show that tagging is incomplete. You can read about it above. Parking space is not a standalone feature according to wiki, it needs proper parking tagging.

[jdhoek]

https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space says to tag the individual parking spaces with amenity=parking_space, and group them in a site relation with type=site and site=parking.

The wiki doesn't seem to give a single clear answer on how to use this feature. If I understand the wiki correctly an area with related parking spaces can be mapped by:

• Mapping each parking space with amenity=parking_space
• Grouping them with type=site and site=parking

…as an alternative to amenity=parking, reducing visual clutter from all the P's rendered. Particularly when a bunch of related parking spaces are separated by other ways and areas.

Is this wrong and should there also be a multipolygon or normal area for amenity=parking below all parking spaces?

[mboeringa]

Grouping them with type=site and site=parking

Site relations are unfortunately a virtually unrenderable relation type, and most tools ignore them for good reasons. Site relations are defined so broad in the Wiki, they can contain a host of objects: node, ways, and even other relations. This makes it extremely difficult to do anything sensible with it in rendering. E.g. theoretically, site relations could have an infinite chain of relations (site in site in site)

I do actually think they have a limited function, but solely as an administrative tool, to group disparate things together, and allow you to jump from one object to the other site object using hyperlinks on the OpenStreetMap site.

So putting an amenity=parking tag on the outline of a parking is still good practice.