New quest: Installations on a playground

[rugk]

General

Affected key(s) (or tags) to be modified: playground
Question asked: What elements are there on this playground?

Checklist

Checklist for quest suggestions (see guidelines):

• 🚧 To be added tag is established and has a useful purpose (finding different installations)
• 🤔 Any answer the user can give must have an equivalent tagging (Quest should not reappear to other users when solved by one); there can't be "nothing" on a playground, so the user can always answer something
• 🐿️ Easily answerable by everyone from the outside
• 💤 Not an overwhelming percentage of elements have the same answer (No spam)
• 🕓 Applies to a reasonable number of elements (Worth the effort); 129 173 playground nodes are there; "Only" 4 302 have the playground=* key, i.e. the majority has no elements/installations specified, or has them specified as own objects (cannot easily calculate them)

There are many small playgrounds in parks, in residential areas (where you otherwise only have the boring lit, streetsurface and house quests 😉) and so on and these small ones are more likely to miss the data what installations are there.

Ideas for implementation

Element selection: Nodes and – if possible – small areas/relations or areas/relations where no other thing is inside them, tagged with leisure=playground (and, of course, without any object/installation already specified)

The reason for the specific condition for areas is just, that the objects on the playground can also be mapped . For nodes this is no problem, because nodes are well… nodes. They are only one point and thus you have to specify the installations on the playground in that node (if mapped correctly).
For areas, however, you either just include the small areas (max. 5m or so…), where you are sure no one can reasonably map installations as separate items, or, you check whether installations are associated with the leisure=playground relation and ignore them.

Metadata needed: Maybe the most common values per country? (although I am not sure whether they vary that much…, maybe an international dataset might also be sufficient) Could be extracted/use the already-existent OSM data for that.

E.g. from taginfo:

Proposed GUI: multi-selection, with images and text

[westnordost]

I am not sure if this sentence from the wiki makes sense:

Only when the position of the individual objects cannot be mapped yet, the tag can be added to the playground node as a first step.

This kind of first-mapping would not be very helpful in detailing out the data. It is like adding something like amenity=school;phone;pharmacy to a landuse=residential for a block. Mappers trying to expand on this data will not be able to detailing out the data without completely re-surveying it by themselves.

[westnordost]

Also, there are less than 100 objects globally who are tagged the way I mentioned in the previous comment, so this is really irrelevant.

[rugk]

Yeah, but expanding this data is not always possible/useful. Just think of the small 5x5m playground (with one or two installations)… You cannot even see the things on a satellite image and such a detailed mapping would hardly make sense.

Also, there are less than 100 objects globally who are tagged the way

Wow, really? How did you get that data?

As I said previously when only considering nodes (where we don't care about the special case with installations mapped inside relations) 124 855 nodes do not have the playground tag. I.e. 98,92% are missing it…

[westnordost]

Not sure if we are talking past each other...

Also, there are less than 100 objects globally who are tagged the way

Wow, really? How did you get that data?

With "that way", I mean the way described in the previous comment: leisure=playground + playground=something;and something else.
The vast majority of any playground will have multiple structures on it. So, if StreetComplete would start mapping these as described above (instead of adding the single structures as separate nodes), my point is, that SC would be the one to start with this practice because it isn't a practice yet (less than 100 objects globally tagged that way) and I explained previously why it might not be a good idea.

[rugk]

Ah, that's what you mean… (But it's not bad practice according to the wiki.)
But yes, maybe for relations it is indeed rare. I mean if you draw an area you may also see the individual items.

However, that does not change one fact: Still useful for nodes through.
So maybe we do not care about relations and only about nodes?

[westnordost]

I did not mention relations at all.

[rugk]

I know, but what you describe is only possible in relations/areas. You won't put a node "playground" and 20m away another node for the installation.

[matkoniecz]

Proper mapping requires separate node (or way) for every object, what makes it outside scope of SC.

I am not sure if this sentence from the wiki makes sense:

Also, there are less than 100 objects globally who are tagged the way I mentioned in the previous comment, so this is really irrelevant.

I attempted to clarify that in https://wiki.openstreetmap.org/wiki/Key:playground#Mapping_all_objects_on_one_node (BTW, it is not changing anything but between 100 and 200 playground tags are with : character).

[andrewharvey]

How about using the playground:*=* scheme documented at https://wiki.openstreetmap.org/wiki/Key:playground:.

Quest would be asked on leisure=playground where it contains no playground=* elements inside it and no playground:*=* tags on the object.

The quest would ask which equipment the playground has, displaying a grid like surface quest, but allowing multiple selections.

Yes, mapping individual playground=* elements is best, but tagging playground:*=* on the leisure=playground object is still a good stepping stone.

[mnalis]

@andrewharvey see #589 (comment) - if you look at taginfo, it is still very rarely used (there is only about 0.36% tags worldwide using that syntax).

It perhaps still might be worth doing, if there was some data consumer which used those tags - do you know of any?

[matkoniecz]

is still a good stepping stone

It seems to me that it would not help at all in mapping position of specific objects.

And anyway it is basically unused and I am not aware of some consensus that it is a good idea.

[smichel17]

It perhaps still might be worth doing, if there was some data consumer which used those tags

It seems like a catch-22: Why would a data consumer spend effort to use these tags, if they are rarely used? So, I don't think this is a good reason not to map something. In other words, the criteria for mapping in general are different from the criteria for inclusion in streetcomplete.

[mnalis]

@smichel17 sure, many things in life are catch-22. But if there are no users of such data in that format, and the effort is going to be made to micromap such details from scratch, then perhaps it is wiser to micromap it properly (as [separate nodes],(https://wiki.openstreetmap.org/wiki/Key:playground#playground-values) via Vespucci, perhaps?) which is way more popular and thus much more likely to be supported in other data consumers.

But as the tags are the same, only difference if there are mapped on area with leisure=playground or on a node, perhaps data consumers would find them anyhow. That is why I asked if there exist some data consumers for those tags - so it can be checked if both version might work, or only the more popular one.

[andrewharvey]

Agree with @smichel17. I'm not concerned if usage at the moment of those tags is small, the whole point of this is to make it easier to map, so of course usage is low now because SC doesn't support it, add it to SC and see the usage skyrocket 🚀. I'm not concerns about if these tags are used at the moment my interest is mapping first, so it's in place for data consumers in the future should they choose to use it.

[andrewharvey]

Mapping with Vespucci is a lot harder than with SC to the point that many playgrounds I'd like to add data for I don't. GPS is not accurate enough for me to map out individual locations of objects, when tree cover blocks imagery, best I can do is drop dots randomly at roughly the playground location. So a SC quest which asks about equipment at the playground would be much easier.

[smichel17]

I think you misunderstood me. I did not argue in favor of a SC quest. SC generally only has quests for established tags; it is about *completing* the mapping of tags which have been started. My argument applies to using new tags in a different editor.

…

On September 3, 2021 1:12:42 AM UTC, Andrew Harvey ***@***.***> wrote: Agree with @smichel17. I'm not concerned if usage at the moment of those tags is small, the whole point of this is to make it easier to map, so of course usage is low now because SC doesn't support it, add it to SC and see the usage skyrocket 🚀. I'm not concerns about if these tags are used at the moment my interest is mapping first, so it's in place for data consumers in the future should they choose to use it.