Don't suggest capacity for amenity=parking_space

[jdhoek]

With amenity=parking_space it is possible to map separate parking spaces in a parking area. It can be used with capacity in case the space is used for more than one vehicle, but this is an exception. By default, capacity=1 is implied, and many mappers omit the capacity tag when its value would be 1, only using it when it deviates from the default.

By suggesting adding capacity=1 to parking spaces lacking the capacity tag, the editor stimulates adding a tag which is not needed in the vast majority of the cases, and novice users make edits containing many of these changes where they are not needed. I find that this suggestion is causing more noise than useful contributions.

---

We've seen this a couple of times in the Netherlands, were well meaning new mappers look to the issues-tab in ID to look for problems to fix, but adding capacity=1 to a parking lot containing hundreds of parking spaces is not very useful.

[jdhoek]

Here you can see how this particular warning drowns out other warnings:

This is common with parking spaces, because even a small parking lot can contain dozens of them, and a large one hundreds.

Suggesting the addition of capacity to amenity=parking is much more useful, and I'm actually surprised that there is no warning for that.

[1ec5]

Suggesting the addition of capacity to amenity=parking is much more useful, and I'm actually surprised that there is no warning for that.

capacity=1 was likely added here as low-hanging fruit. iD’s validator can only warn when both the key and value are known; it doesn’t have a straightforward way to warn about a key being missing and have the user fill out the value, though that would be an interesting feature enhancement.

[bhousel]

Agree with this - it should have been done this way originally.