At an earlier stage of the proposal, we considered subtags (see, e.g., this discussion), but have noted that this does not meet acceptance nor is it compatible with the existing way in which playground devices are mapped. Instead, the proposal introduces the concept of fallback values (e.g. balance
or climbing
). To us, this seems to work very well in practice and the rate of devices whose tagging remains unclear has decreased extremely.
In fact, the tyre_swing
example is one of the last ones where I am still unsure whether it is solved well. After all, special subtags have already been established for baby or wheelchair swings, which an data consumer should take into account anyway. Maybe it would be better to map tyre_swings as swings, but with material or something? Other opinions on this?
(The various playground device values are also grouped into different categories in the wiki. Here we need to merge the old and new categories into a new system.)
Of course, there will always be individually designed devices for which no documented value will fit and which are difficult to match with a fallback value. But the “typical” range on playgrounds (predominantly Western, due to our point of view) seems to us to be well covered now, even after we have searched through many catalogs and websites of international manufacturers.
Yes, a value like megaphone
might seem very special and could be skipped, but that’s the way we map playground equipment in OSM. I don’t think it would be useful to try to agree on something like playground=audible
+ playground:audible=megaphone
instead - such a kind of system would only have disadvantages compared to a simple tagging as playground=megaphone
, where evaluators can decide for themselves whether such a value is relevant for them or they just treat it as generic “rest”.
Structures can be very different and mapping it’s parts is a way of making that evaluable.
It is not only about categorizing structures into size categories (from mini to giant adventurous), describing possible activities and listing that a structure consists of X bridges, Y platforms and Z climbing elements (which would already be interesting enough!), but it is also possible that detailed structure mapping can be used to make age and target group statements (which also affect an automated “age categorisation” of the entire playground).
In my surroundings, for example, there are about 50 playgrounds with structures and some of them I perceived as perfect at a certain age level of my child, others, however, as unsuitable (e.g. due to the type of bridges, number of steps on ladders and stairs, height of the elements, age group-appropriate possibilities to enter the structure…). We want to make things like this visible and evaluable in an automated, differentiated way.