Playground equipment tagging discussion

[une_abeille]

This is a sort of high-level, preliminary brainstorming session on my end. I feel like I need input from the community in order to be able to refine it into anything resembling a proposal that can be submitted for comment.

Essentially, I have been micromapping playground equipment recently and have run into a few difficulties. Some of them I have a fairly solid idea of how we could improve them; others, not so much. I would appreciate input!

Inconsistent, sometimes confusing names

One issue I run into while tagging playground equipment is inconsistencies in the naming of the tags, that can make it difficult to find the right one without consulting the wiki page repeatedly.

The first issue is the one of using underscores, versus not using underscores. I struggle to remember which tags do or not not use them, especially when similar tags use different conventions. Examples: climbingwall versus climbing_slope, basketswing versus baby_swing

Another issue is the inconsistent naming of similar devices. basketrotator, aerialrotator, spinner, spinning_disc, spinning_circle, and spinner_bowl are all devices that rotate/spin, but they follow three different naming themes (spinner/spinning/rotator). It would be helpful to have consistency.

Ultimately, I am not familiar with the social history of renaming existing tagging standards, so I only present these frustrations for comment from users who can offer more insight into whether or not restandardization is common or even possible.

One feature: one element — or swings, and their issues

On the wiki page for playground equipment itself, it is indicated that baby=yes|no is a problematic tag. I did not discover this until recently, after tagging many swings with baby=yes when baby seats were present (but not the only type of swing seat available). I had been under the impression that it worked somewhat like a parking lot: where indicating baby=yes implied that there was at least one baby seat, not that the entire swing was for babies.

There exists playground=baby_swing to specifically denote swings that are for babies, and it could be used to tag a section of a swing set, but in my mind this violates the “one feature: one element” convention. As it stands, there is no way to tag a swing set as having multiple different kinds of seats, which is a common configuration.

Other kinds of swing seats also exist, some of which are covered by tags on the existing wiki page, but all of which suffer from the same shortcoming that baby=* does — namely, that they do not clearly denote whether or not they apply to the entire swing set, nor do they denote capacity.

My idea for improving swing tagging is as follows:

• Introduce capacity:baby=* in addition to the existing capacity=* to denote the number of baby seats on a swing set. And possibly other tags, for other kinds of seats such as these combined baby+adult ones, or these ones that can securely hold an adult. I would appreciate tag suggestions for these! Wheelchair-accessible swings also exist, and could also possibly benefit from capacity tagging.
• Deprecate playground=baby_swing in favour of the above.

Potentially missing equipment tags

Non-exhaustive list, but some of the things I’ve run into in the past few weeks that I have struggled to tag under the existing system. Happy to have my usage clarified on any of these.

1. Acrobatic rings
   Definitely a missing tag. These have an equivalent tag in the fitness_station tag space, but often feature in playgrounds. playground=rings would seem appropriate.
2. Wobbly ladders
   If playground=wobble_bridge is distinct from playground=bridge, then I believe something similar would be appropriate for ladders. Chain or rope-based ladders are common in playgrounds, and may represent a significant obstacle to some playground users being able to climb the equipment. (Example, left)
3. Wobbly stepping posts
   Maybe this is fine being tagged as a normal stepping_post? (Example)
4. Rope net bridges
   rope_traverse doesn’t feel right for this, nor necessarily does wobbly_bridge. (Example)
5. Running wheels
   A sort of inverse playground=hamster_wheel where one runs on top of the wheel. (Example)
6. Halfpipe simulators
   By far the coolest and most impossible-to-tag thing I’ve found yet! Hard to explain, so see this video for an example.

• What is defined as a rope_swing currently is very different to what I know as a “rope swing”, which is simply a thick rope hanging from a tree, with either a knot or a small seat at the bottom. I am uncertain as to whether or not to use this tag for this kind of swing.

Element type guidelines

Some types of playground equipment are listed in the wiki as only being suitable for nodes or areas — and subsequently throw errors on iD when you tag them as ways. However, many of these features are commonly in a configuration that would make the most sense to tag as a way, such as this climbingframe that would not make sense as anything but a way. (Actually on second look, climbingframe is approved as a way on the wiki, so this particular case might just need to be entered as a bug report on the iD repo.) Another feature type that comes to mind is platforms, which may be quite long, but differ from bridges in my mind.

Similarly, there are types of playground equipment that give errors when drawn as areas, despite them being large enough to justify it. This large patch of stepping_posts makes sense as an area.

---

Conclusion

I feel confident in my idea regarding swing capacity tagging, but everything else here is more nebulous. I would very much appreciate any discussion on this topic to help me refine my ideas, and clarify usage of existing tags so I can discard any irrelevant ones!

[Casey_boy]

@une_abeille

The first issue is the one of using underscores, versus not using underscores. I struggle to remember which tags do or not not use them, especially when similar tags use different conventions.

From the syntactic conventions for new tags:

• Ideally, the value of a feature tag is one word, in lowercase, using British English if possible.
• When that can’t be the case, the value of a feature tag should be one concept, whose words are underscore_separated.

I think ideally we’d have gone with climbing_wall (for example) but I can see why someone may have seen the one word emphasis and thought best to combine. Maybe that needs some clarification.

Interestingly, the value climbingframe (rather than climbing_frame) was actually part of the original playground proposal .

@une_abeille

Another issue is the inconsistent naming of similar devices. basketrotator, aerialrotator, spinner, spinning_disc, spinning_circle, and spinner_bowl are all devices that rotate/spin, but they follow three different naming themes (spinner/spinning/rotator). It would be helpful to have consistency.

I suspect this is because there is no clear authority on what to call these pieces of equipment and so mappers have used “any tag you like”. If you were to consider expanding the playground proposal with your own, then you could look to formalise some names.

Ultimately, I am not familiar with the social history of renaming existing tagging standards

Typically, we don’t tend to rename established tags or values, unless they’re wrong or causing inconsistencies (and even then not always!). But it has happened and a full proposal reworking the playground tagging values may be a good reason for doing so.

Also, note, there is a difference between introducing new values and encouraging mappers to use those instead versus wholesale re-tagging existing features.

@une_abeille

Introduce capacity:baby=* in addition to the existing capacity=* to denote the number of baby seats on a swing set.

I like this but would you use it on swings that are only baby swings (i.e., capacity:baby=capacity), or would you continue to map those as playground=baby_swing?

Acrobatic rings

Also known as gymnastic rings. Presumably, if you were intending to match the fitness_station tagging this applies to a set of two rings? What about the case of a horizontal course of suspended rings (similar to the horizontal ladder)?

Wobbly ladders

There is some use of chain ladder and rope_ladder - would these not suffice, or do you think they should be combined?

Rope net bridges

Some use of ropebridge. I think there may be some ambiguity about whether this could be a single rope (like a tight rope) or a net. However, the wiki page does document rope_traverse as a “tightrope or slackline to walk across while keeping balance”.

(Also, going back to your naming conventions, maybe this should be rope_bridge).

@une_abeille

Some types of playground equipment are listed in the wiki as only being suitable for nodes or areas — and subsequently throw errors on iD when you tag them as ways.

I wouldn’t worry too much about that. Just map as seems appropriate.

Hope that helps!

[une_abeille]

Thanks for replying!

@Casey_boy

I suspect this is because there is no clear authority on what to call these pieces of equipment and so mappers have used “any tag you like”. If you were to consider expanding the playground proposal with your own, then you could look to formalise some names.

They seem to have come from a combination of two proposals, one very old, and one quite new. The old proposal did not use underscores, while the new one did. The old proposal used “rotator”, while the new one used “spinn[er|ing]”.

As far as I can tell, all of the tags on the playground equipment wiki page are formalized, just not necessarily harmonious.

@Casey_boy

I like this but would you use it on swings that are only baby swings (i.e., capacity:baby=capacity), or would you continue to map those as playground=baby_swing?

No, the intention here would be to do away with the need for playground=baby_swing. As an example:

For this swing set, I would tag it as:

playground=swing
capacity=4
capacity:baby=2

And for this one:

playground=swing
capacity=8
capacity:baby=8

Similar to how capacity=* is currently used for parking spaces.

[une_abeille]

@Casey_boy

Also known as gymnastic rings. Presumably, if you were intending to match the fitness_station tagging this applies to a set of two rings? What about the case of a horizontal course of suspended rings (similar to the horizontal ladder)?

A row of rings like you describe is currently the example photo for playground=monkey_bars and wouldn’t be covered by this new tag. Yes, I am talking about a set of two rings on long (and sometimes adjustable) ropes or chains, that can be used to do acrobatic manoeuvres.

[Casey_boy]

@une_abeille

A row of rings like you describe is currently the example photo for playground=monkey_bars

Ah OK. I’d have thought they would be classed as separate things (bars indicating solid linear features rather than swinging hoops/rings). But I guess the motion across both of them is similar to a swinging monkey. Thanks.

[yvecai]

We probably need to add some kind of picture search on the wiki for playground equipment

[Matija_Nalis]

Disclaimer: I’ve been heavily involved in original discussion at: Tagging baby swings which describes the problem (and possible solutions), so my opinions are only my opinions, and all that.

@une_abeille

Ultimately, I am not familiar with the social history of renaming existing tagging standards

It depends on what you mean by “renaming”. Changing the meaning of existing tag is very hard if not impossible. Adding a new, clearly defined and non-ambiguous tag is OK , and deprecating existing tag is possible (but requires some work).

Usually, the result is that both old tagging and new tagging will coexist for quite some time (making more work for data consumers), hopefully with new non-ambiguos tagging growing in use, and old (ambigous&problematic) tagging shrinking in use.

@une_abeille

As it stands, there is no way to tag a swing set as having multiple different kinds of seats, which is a common configuration.

I agree about commonness. I personally work around the issue by micromapping each swing if they differ, i.e.:

• if it is only 4 regular swings, I’d map whole swingset as single node tagged playground=swing + capacity=4, but
• if it is a swingset with 1 regular + 2 baby swings, I’ll map it is two nearby nodes: one as playground=swing + capacity=1 and other as playground=baby_swing + capacity=2 )

That solves ambiguity in clear way which is easy for data consumers, and is not too much work for me (as I’m micromapping playground equipment anyway), preserving all usable information, and only information that is lost is mechanical structural implementation details (i.e. how are swings divided between swingsets) – a good tradeoff IMHO, as in vast majority of the cases it really does not matter much is there is 2 swingsets with 2 swings each - one next to the other, or one swingset with 4 swings (with or without middle support).

[Matija_Nalis]

@une_abeille

playground=swing
capacity=8
capacity:baby=8

The main issue with that approach is that of trolltagging – i.e. tagging as a swing something which cannot be used by any child as a swing.

In other words, it requires data consumers to support capacity:baby=* (and any number of other existing or future capacity:*=* tags) in order to not completely misinterpret the playground=swing, which is problematic (for hopefully obvious reasons).

Using separate nodes for playground=swing (i.e. baby=no) and playground=baby_swing (as suggested in my post above), makes it easy for data consumers – e.g. in OsmAnd, if you are e.g. teenager you’d look for playground=swing and if you’re parent carrying a baby you’d look for playground=baby_swing.

[une_abeille]

I don’t see how this is trolltagging. Parking spaces work exactly the same way.

[Matija_Nalis]

@une_abeille

Parking spaces work exactly the same way

And (technically) it could be problematic there too. Imagine (intentionally exaggerated for purpose of explanation; I know such full-blows situations would be quite rare to say the least) amenity=parking + access=yes + capacity=100 + capacity:charging=100 + capacity:women=100 + capacity:disabled=100.

I would definitely call that problematic, as it’s basically saying “Here is a car parking for you, but only if you are women who is disabled and is driving an electric vehicle. Otherwise, no parking for you!”. Imagine the chaos is significant amount of car parkings were tagged as such!

The issue is that each data consumer would have to know not only to parse all those tags, but also ask all those questions about driver (sex, disability card ownership, ICE/electric car, etc.) before it could reliably show you parkings. And if the new tag appears (say capacity:h2, it would again mislead all data consumers if capacity:h2 = capacity until they were all upgraded. Such data model would not be sustainable)

Luckily, such combinations (e.g. capacity=capacity:women) are extremely rare for whole car parkings (tagged with amenity=parking), thus the issue is mostly moot there. Not so for swingsets: there are many swingsets which are baby-only. Thus, the issue becomes the real problem there.

The other crucial difference is that in the case of the parking the restrictions go only one way, while in a case of swings restrictions go both ways, which makes even regular-only swings problem (something which is never a problem for car parkings).

IOW, if there are 100 “regular” parking spaces, even women and disabled persons and electric cars owners CAN park there too. But if there are only 10 “regular” swings, babies CANNOT use them. You have to have specialized baby swings for them.

---

To summarize, capacity:* tags (or any other additional tags) are just fine if they only add details and can be completely ignored without changing the meaning (i.e. capacity:whatever=* value would practically never be equal to capacity=* value!)

Same is fine for swings : if the swingset has 4 baby swings and 6 regular swings, it would be fine to use capacity=10 and capacity:baby=4), as it does not change the meaning of a playground=swing if data consumer ignores all capacity* tags (as most of them do). There are after all regular swings there and they can be used as such; and if you do not know about detailed tags like capacity:baby, you’d just lose knowledge that there are additionally some baby swings there if you don’t process those extra tags.

That is crucial difference – it that particular case; you’d just provide less detail (just as if you for example forgot to map some amenity=bench that are present), but you will not mislead data consumer which do not know about your additional tags. Thus, it is OK.

But if it is somewhat regularly occurring situation that whole swingset has only baby tags (e.g. capacity=8 and capacity:baby=8 on that playground=swing) as in that example picture above, that it is hugely problematic to use only those capacity tags to distinguish – as someone not knowing about capacity:baby=* tag will be mislead that there is a regular swing, when there is not.

Using playground=swing + playground=baby_swing (with optional capacity on each) solves that problem completely, which is why I find using that preferable.

I hope I have managed to explain the rationale why that option (separating playground=swing and playground=baby_swing) has been deemed most popular by the community.

Note that I have no particular intention of telling anyone what they must do: you’re free to tag any way you like, I just thought it prudent to provide you with enough information to weight why some solutions are worse then others, and help you make an educated decision. It’s your choice in the end!

Happy mapping!