Remove man_made=courtyard from iD presets

[matkoniecz]

While maybe man_made=courtyard has some uses, making it searchable in iD is causing problems

• makes harder to discover how to create multipolygons (as mapper is likely to think that they solved problem how to map courtyards and used it instead of using multipolygon)
• it is widely used by iD mappers for every single area inside buildings (and next to buildings), and promoting it use for every single inner area of multipolygon is a bad idea
• it is typical to see it used in way mismatching supposed definition or what "courtyard" means
• this tag is not needed, maybe except some extreme cases

See https://wiki.openstreetmap.org/wiki/Talk:Tag:man_made%3Dcourtyard

https://www.openstreetmap.org/way/850749107#map=19/25.46775/80.98729&layers=N

Ideally searching "courtyard" would show not a preset but quick info how to create multipolygon in iD as a top match (mini tutorial taking space as one of presents in preset search)

[tyrasd]

Ideally searching "courtyard" would show not a preset but quick info how to create multipolygon in iD as a top match (mini tutorial taking space as one of presents in preset search)

I really like the idea! I've created openstreetmap/iD#8904 for it.

[matkoniecz]

Though in meantime removing man_made=courtyard from preset would be an improvement in itself anyway.

Current use encouraged by iD is making map data worse, not better.

[tordans]

We could keep as a non-searchable preset, right?

[matkoniecz]

My position is that OSM would benefit from elimination of that tag and supporting it is not helpful.

This may mismatch consensus, but https://wiki.openstreetmap.org/wiki/Talk:Tag:man_made%3Dcourtyard has no response and I have not seen any case where man_made=courtyard improved data and could not be replaced by superior tagging. And even if small amount of such uses exists, vast majority of uses and overall use is not helpful.

[tyrasd]

We could keep as a non-searchable preset, right?

That's how I ended up implementing it for now. (in the above linked commit I forgot to add the non-searchable preset, see d5fddc1).

Hmm, I guess dropping it could also be a good option. 🤔 The tag has 20k usages, though. And I did find some valid use cases, like for named courtyards, like this ones: https://www.openstreetmap.org/way/834022036, https://www.openstreetmap.org/way/624420818 or https://www.openstreetmap.org/way/85081255

[matkoniecz]

The tag has 20k usages, though.

Vast majority as result of including it in iD.

https://www.openstreetmap.org/way/85081255 - here mapping as a pedestrian square and inner of building was sufficient, man_made=courtyard adds nothing

https://www.openstreetmap.org/way/834022036 - here courtyard is of a different shape (inner of a building) - I opened https://www.openstreetmap.org/note/3024641

https://www.openstreetmap.org/way/624420818 - nothing is really added by man_made=courtyard

[1ec5]

If we’re sure that an explicit courtyard tag is meaningless and the confusion above is commonplace, maybe there should be a validator warning that can automatically turn the courtyard area into an inner member of a multipolygon relation. After all, the trick for merging an area with a closed way to form a multipolygon is not especially well-known, especially among JOSM users who’ve come to expect a less elegant process.

[nc011]

This tag isn't meaningless and I strongly disagree with Mateusz on this (see the Wiki discussion) - so please don't consider there being a consensus on this.

The validator idea (setting the man_made=courtyard as the inner relation) is a nice one. However, courtyards may sometimes be the enclosed space of several buildings. Therefore it is not always the inner relation of a multipolygon relation (unless you join several buildings into one relation - which doesn't seem correct).

There is nothing wrong with using a tag to describe a feature with more specificity. That's what tagging is all about. Remember, not all inner relations are, by default, courtyards.