Add 2 quests for Swings on a playground (playground=swing) info

[Tex2002ans]

General

Affected tag(s) to be modified/added: baby=yes and capacity= on playground=swing

Questions asked:

I believe adding 2 more quests would be helpful:

1. "Does this have any bucket swings?" / "Does this have any swings for babies/toddlers?"
   • baby=yes
   • In the example image below, the:
     • 2 on the right are "bucket swings" / for babies.
     • 4 on the left are normal.
2. "How many swings are here?"
   • capacity=
   • So in the example image below:
     • capacity=6.

According to taginfo, there are currently 40k playground=swing nodes/areas marked, but ~9k have any sort of capacity added.

---

The "# of swings" or "type" is something that is nearly impossible to tell using satellite footage only, and needs on-the-ground info.

Satellite image (from Bing):

On-the-Ground view:

Perfect use-case for StreetComplete users to go visit the parks and enhance! :)

---

Checklist

Checklist for quest suggestions (see guidelines):

• 🚧 To be added tag is established and has a useful purpose
• 🤔 Any answer the user can give must have an equivalent tagging (Quest should not reappear to other users when solved by one)
• 🐿️ Easily answerable by any pedestrian from the outside but a survey is necessary
• 💤 Not an overwhelming percentage of quests have the same answer (No spam)
• 🕓 Applies to a reasonable number of map data (Worth the effort)

Ideas for implementation

I suspect "swing capacity" can be very similar to "bike parking capacity" quest.

You visit the spot, count up how many swings there are, and submit. :)

• baby swing quest
  • 1 or 2 cropped/zoomed-in photo showing a baby-type swing, so people can instantly tell the difference without needing to understand the "bucket" terminology.
    • Or maybe a (green ✓ + baby-type photo)... and a (red ✗ + swingset with only normal swings showing)
  • User chooses: Yes / No
    • Yes -> baby=yes
    • No -> baby=no
• capacity quest:
  • Maybe 0 or 1 photo showing off a normal swingset.
    • (Although it might just be implied by question / title of quest.)
  • User types: # or leaves / swipes away to cancel.
    • -> capacity= whatever number the user typed in.

---

Side Note: I see there was some Swing enhancement discussion back in 2021:

• Is this swing suitable for babies? #3174

where it was "denied" as too niche until getting more usage:

[...] only a tiny percentage of playgrounds are micromapped to include playing equipment. Looking at taghistory/taginfo, my rough estimation would be around 1-5% of all playgrounds. [...] For this data to be reasonably usable [...] playgrounds would first need to reach a certain coverage.

In July 2023 though, 33 new additions to playground equipment were overwhelmingly accepted (51 yes, 0 no):

• wiki.openstreetmap.org: "Key:playground"
• See original "Extended playground equipment" proposal

So I believe these "micromapping" of specific playground equipment will go up... Especially if it becomes as easy as adding a Thing/"Bench"/"Fire Hydrant"/"Trash Can" like you currently can in StreetComplete.

Tie those Wiki photos with some sort of new "Playground" quest, and I think it'll help boost these objects into much more usage. :)

---

... And if StreetComplete users randomly see a "# of Swings" quest pop up, perhaps that might encourage them to properly add/tag more "Swing" nodes/areas too! :)

[mnalis]

While "🤷 Useful purpose" quest guideline might perhaps be debated for such micromapping (see e.g. this comment) (especially, as you note and I agree, there is growing trend of mapping those, so people seem to care for some reason), there are two important ambiguities which IMHO make it problematic from both "🐿️ Easy answer" SC mapper standpoint, and later for actual data consumers:

• Is this swing suitable for babies? #3174 (comment) ambiguity relating to capacity=* (i.e. "does it relate to whole swing-set, or to a single swing?")
• baby=yes ambiguity in Is this swing suitable for babies? #3174 (comment) (I've now documented it at https://wiki.openstreetmap.org/wiki/Key:baby#Possible_issues)

[Tex2002ans]

[...] (especially, as you note and I agree, there is growing trend of mapping those, so people seem to care for some reason) [...]

I was inspired by the "fire hydrant" quest too.

I only got started in OpenStreetMap ~2 weeks ago, (and someone mapped a single fire hydrant in my area years ago). I saw the quest, answered it, and thought:

• "I didn't even KNOW you could map FIRE HYDRANTS!"

Before, they were completely "invisible" to me.

Now, I go out of my way to map every single fire hydrant I see. (>100 mapped so far.)

Because of StreetComplete's quest... this lead me to map otherwise "invisible" objects. And now that I learned how to use the "Things" submenu, I then ventured into what OTHER types of missing objects I could map!

I visit a park, and now I mark all the:

• Benches
• Water Fountains
• Trash Cans

A quest like this would potentially add Swings onto that list too! :)

---

Side Note: Swing nodes -> Swing areas can then potentially be mapped by someone who wanted to do the work when they get back to a more powerful editor.

---

While "🤷 Useful purpose" quest guideline might perhaps be debated for such micromapping (see e.g. this comment) [...] there are two important ambiguities which IMHO make it problematic from both "🐿️ Easy answer" SC mapper standpoint, and later for actual data consumers:

Hmmm... interesting. Thanks for the links/discussion. :)

I would personally say "6 swings total", then leave it up to baby accessible "yes".

Similar to bathrooms, you don't have to go down to the "# of wheelchair accessible stalls inside" or anything... all that really matters is that there IS at least 1 wheelchair accessible area inside.

In that case, a binary "0 vs. 1+" is much more important than an exact "1 vs. 2 vs. all" baby seats.

[mnalis]

"I didn't KNOW you could even map FIRE HYDRANTS!"

I know the feeling; welcome to your new lifelong hobby 😄

I absolutely agree with you with "let's make the best and most detailed map on the planet". It is just that the different concepts are better suited for different tasks. For example, in StreetComplete you use Places/Things Overlays to add new POIs to the map, but you cannot add any detail in them. And with Quests you add details to existing things. You can sometimes combine Overlay+Quests to add new POIs with details, but not always.

As you're new user, I'm going to recommend you another nice mobile app you maybe didn't know about: Every Door. It is kind of like Places/Things Overlay + all their Quests combined into one, but different UI avoids the problem with spamminess. It is tailored toward easy and efficient micro mapping of details. I think it might suit your "let's map everything with all details" enthusiasm!

Side Note: Swing nodes -> Swing areas can then potentially be mapped by someone who wanted to do the work when they get back to a more powerful editor.

Note that in StreetComplete, you can long-press on any position on the map and choose Create new note.
Then you can describe the situation (and even leave pictures!) to let people (hopefully yourself too) do the more complex work in more powerful editor later. Only problem compared to direct editing is that it creates extra work which easily accumulates and becomes overwhelming if not enough people are solvng Notes, so don't overdo it (e.g. don't leave notes all the time instead of making changes yourself if you can make such a change in your mobile editor)

all that really matters is that there IS at least wheelchair accessible area inside.

If you are person in wheelchair, that is correct, you are primarily interested if there is at least some wheelchair access (although you'd of course prefer if it was fully accessible). And persons without mobility issues don't really care as it is accessible to them always, regardless if it is wheelchair-enabled or not.

baby=yes is however different in one important way - sure, it is important for parents with babies to know if the small baby can safely use that swing, so there need to be at least some swings with baby baskets. However, contrary to wheelchair example above, it is also important for older children -- as they cannot use baby swings (they don't fit physically). So if playground has only baby swings -- those swings are unusable for older children.

Thus, while baby=no is clear; baby=yes is ambiguous -- it might mean that there are some baby swings but there are also regular swings, or it might mean that there are only baby swings available (i.e. there is not even one swing for older children to use).

(suggested tagging alternative of e.g. playground=swing + capacity=10 + capacity:baby=2 is not only more detailed than baby=yes, but more importantly it avoids that ambiguity completely, due to math: 10-2=8, so older children can use swings in that example too)

[Tex2002ans]

This video may be relevant too:

• State of the Map US 2022: "Micromapping Phoenix City Parks" by Sean Whitcomb
  • His OSM username is: mycota ... and he still looks very active. (Unsure if he has a Github account.)

On babies, he mentioned parents "wanting to take kids to a shady playground". And how the Phoenix weather is brutally hot, so this kind of micro-level info is helpful. :)

Or his wife "wanted to have a party in a park...":

• with some shady ramadas
• that had picnic tables
• near a bathroom
  • ... but not TOO close to a bathroom!

(and he was able to figure that out using the OSM data! "No other tool has that!").

(Both examples were mentioned ~2 minutes into the video.)

---

And @ltog (the original baby swings user) might have some more input in the past 3 years too. :)

---

Side Notes:

Note that in StreetComplete, you can long-press on any position on the map and choose Create new note. Then you can describe the situation (and even leave pictures!) to let people (hopefully yourself too) do the more complex work in more powerful editor later.

Yes, that's pretty much what I've been doing. Any problems I spot, I make sure to update a day or two later back on Desktop.

(Wouldn't want to leave more work for others, I'd rather do it as complete as possible... in passes if needed, and while it was still fresh in my mind.) :)

And like I said in my previous comment... the StreetComplete quests alerted me to what was even possible, which let me map more efficiently on the Desktop as well.

For example...

1. Being able to add these from desktop was MUCH faster than one-by-one choosing in the app:
   • a whole row of house "Street" addresses
     • -> Now, as I add houses/businesses, I just tag the nearby streets as well.
     • I could then verify "House Numbers" easily in-person on app.
   • Parking lots as Surface/Asphalt
     • Then I could verify "pay or not" in app.
2. I'd do a quest or two in StreetComplete to see how it tagged/changed an object...
   • -> Then replicate that on Desktop for other objects in the area.
3. I could also use StreetComplete's "Building" UI to quickly pan/scan and see any "red buildings" which were missing metadata. :)
   • -> Then categorize them more correctly.

---

Funny side note on Notes: As I was first using the app, I left 2 Notes for myself, but had no idea it would be completely public information.

(I accidentally put in a wrong street / house number and had no idea how to undo yet, so I left a Note for myself. Quickly corrected it a few days later on Desktop, but got an email from someone on my Note saying "the Note was left in the middle of the street!" So they weren't sure which house # I meant... lol.)

So... here's a potential enhancement too:

• If a new StreetComplete user is leaving their very first note... perhaps one little warning letting you know:
  • "Hey, this Note is going to be publicly posted/shared onto OpenStreetMap!"

[ltog]

Thanks for tagging me. Not sure if I can add much to the discussion. My critique on capacity=... in this context still stands. See #3174 (comment)

[mnalis]

Thanks for tagging me. Not sure if I can add much to the discussion. My critique on capacity=... in this context still stands. See #3174 (comment)

Yeah... Although, nowadays we have different tags for other types of swings.
In particular, that thing looks more like playground=rope_swing than playground=swing to me, although it is likely somewhere in the middle... It is a specialty type, not something most people would recognize as a "regular" swing. So I wouldn't tag it as playground=swing at all but differently (just like e.g. playground=basketswing which has its own type - because it differs too much from "regular" swing).

Truth be told, I personally would also prefer something like playground=baby_swing.
Using playground=swing+baby=yes+capacity=1 smells too much like a Trolltag -- "here a swing for you; haha just kidding you can't actually use it because you're 7yrs old".

But this if global tagging decision, so not well suited for StreetComplete issue tracker, so I've opened discussion for that at https://community.openstreetmap.org/t/tagging-baby-swings/112832 - feel free to give your opinion there

[westnordost]

I've skimmed through the forum thread, my conclusion is that playground devices tagging is a fucking mess and I really don't want to burn my hands with that. I remember voting against the proposal because I was and still am of the opinion that the type of swing should be a subtag of playground=swing as it is really somewhat open-ended. So, we now have the issue I predicted - baby swings not being in the original proposal and thus people becoming creative with how to fit this particular swing into the tagging schema without extending it. But, well.

As per the original proposal:

• How baby swings should be tagged aside, 💤 asking if any swing is for babies or not would be spammy. Most are not specifically for babies. Also, as explained above, as per the approved proposal, playground=swing is not meant to mean "a generic swing, could be any other more specific swing, too" but it is meant to mean "standard swing, nothing unusual", hence, you can't really ask whether this standard swing is in reality not a standard swing.

• 🚧 asking for the capacity of swings seems not that useful to me. First of all, who would plan their playground trip according to the capacity of some swings? More realistic would just be to look at the size of the playground as a whole to decide whether a playground looks interesting. (Also, the capacity can already be estimated by the size of the swing outline, if it is mapped as an area)