Is this swing suitable for babies?

[ltog]

General

This quest aims to gather information whether swings on playgrounds are suitable for babies or not. Since most playground items are not suitable for babies (regular swings, slides, basket rotators, etc.), the presence/absence of swings suitable for babies may be an important factor for parents for deciding on visiting a playground or not.

Affected tag(s) to be modified/added: playground=swing, baby=yes/no
Question asked: Is this swing suitable for babies?

Checklist

Checklist for quest suggestions (see guidelines):

• 🚧 To be added tag is established and has a useful purpose: See above
• 🤔 Any answer the user can give must have an equivalent tagging (Quest should not reappear to other users when solved by one): Yes
• 🐿️ Easily answerable by everyone from the outside but a survey is necessary: Yes
• 💤 Not an overwhelming percentage of quests have the same answer (No spam): Currently,
• 1'394 objects are tagged with playground=swing and baby=no (53%),
• 1'257 objects are tagged with playground=swing and baby=yes(47%).
• 🕓 Applies to a reasonable number of map data (Worth the effort): There are 16'750 objects tagged as playground=swing. Of these objects, 14'088 (84%) are without baby=*.

Ideas for implementation

Element selection: playground=swing without baby=*

Metadata needed: Not needed

Proposed UI:

• Option "No": With image like https://wiki.openstreetmap.org/wiki/File:Accessibleplay-Swing.jpg
• Option "Yes": With image like https://wiki.openstreetmap.org/wiki/File:Inclusiveplay-Babyswing.jpeg

The Wiki has examples for swings for users with sitting disability/with wheelchairs: https://wiki.openstreetmap.org/wiki/Key:playground#Advanced_examples . One could consider providing these as options too.

[HolgerJeromin]

Adding the data would be a good idea (for the few month you need it :)
But currently there is no project to extract these information. osmand does not even show playground equipment.

wheelchair (never found a wheelchair swing in the wild only few playground=roundabouts) and sitting disabilities (another tag: playground=basketswing) should not be added in SC.

[matkoniecz]

But currently there is no project to extract these information. osmand does not even show playground equipment.

That is not a problem by itself, I would be also fine with a clear potential use.

My bigger worry is that with multiple playground=swing next to each other it would be nearly impossible to identify which is being asked (this problem appears also for other objects, but they tend to not be clustered so close like swings)

"show objects of type being asked about" would be very helpful in general, but it is very big task to implement

[HolgerJeromin]

I expect capacity=* instead of multiple objects in most/all cases.

[ltog]

I expect capacity=* instead of multiple objects in most/all cases.

I tried to gather some data regarding this question. I came up with the following Overpass query which returns two counts (visible in the Data tab):

node["playground"="swing"]({{bbox}})->.swings;
node.swings["capacity"]->.swingsWithCapacity;
(.swings; - .swingsWithCapacity;)->.swingsWithoutCapacity;

foreach.swingsWithoutCapacity->.swing(
  (.swingsWithoutCapacity; - .swing;)->.otherSwings;
  
  (
    node.otherSwings(around.swing:10);
    .swingsInClusters;
  )-> .swingsInClusters;
);

(.swingsInClusters;);
out count;

(.swingsWithCapacity;);
out count;

I believe the query works, unfortunately it is too slow to run over large areas. So I was not able to come to a conclusion. :-(

[peternewman]

"show objects of type being asked about" would be very helpful in general, but it is very big task to implement

I assume you mean #2354 (asking mostly for the linking).

From what I understand via the Element First class stuff, the relevant data is now in the DB already, so it's "just" a case of writing something that shows all the other nearby swings on the map when you pick one and start answering this quest...

Which I'm sure is a lot more complicated than I'm making it sound. 😢

[westnordost]

Well then it is blocked at least.

Though I am also not that convinced about a meaningful application of that data. The action radius of young parents with babies is in my experience usually not that big. They are glad if there is any playground near the home that they can reach conveniently with a baby buggy that fits into one changing-of-nappies cycle.

That parents would search in some app for certain baby-friendly features of playground and make a detor or even drive there with a car seems somewhat construed.

[matkoniecz]

I was rather thinking about using it for measuring whether given town/city has baby friendly features, maybe in some advocacy program (I do this with bicycle parkings).

[HolgerJeromin]

Use case:
You are in a car driving a long distance and want to plan at which playground you take a break.

[ltog]

My bigger worry is that with multiple playground=swing next to each other it would be nearly impossible to identify which is being asked

I fully acknowledge that this is a problem and would suggest to postpone an implementation after this has been (generically) fixed.

The action radius of young parents with babies is in my experience usually not that big. They are glad if there is any playground near the home that they can reach conveniently with a baby buggy that fits into one changing-of-nappies cycle.

Well, I might be just one datapoint, but IMHO visiting the same playground over and over again gets boring quite quickly. With a baby carrier and 30mins of time you can cover quite an area. (And as a side note: the vexed thing with changing-of-nappies cycles is that they tend to be not as predictable as parents would like them to be.)

[westnordost]

Still, 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. So as a consequence, enhancing data on single playing equipment will only enhance this tiny percentage. For this data to be reasonably usable in any (end-user) application, micromapping of playgrounds would first need to reach a certain coverage.

[Cj-Malone]

Still, 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. So as a consequence, enhancing data on single playing equipment will only enhance this tiny percentage. For this data to be reasonably usable in any (end-user) application, micromapping of playgrounds would first need to reach a certain coverage.

I believe StreetComplete can drive edits outside of StreetComplete as well. I never mapped sidewalk= via JOSM until after I did in StreetComplete, now I try to add sidewalk data when tracing residential areas. The same goes for bus stop shelters.

By adding this quest, you could encourage (and make contributors aware of) micro mapping playgrounds.

[westnordost]

I get your point, but the comparison does not fit that well. Sidewalks are tagged on roads. Roads are already mapped. Playground equipment is often not mapped yet.

[Cj-Malone]

I kinda meant new residential areas, where I would be tracing the roads at the same time as adding the sidewalk data. Anyway, just this conversation alone has convinced me to add some playground equipment, so I'm probably just easily influenced.

If you do decide that the cost of implementing this is too high to be worth it, fair enough, but I hope you re visit the idea if usage increases in the future.

[HolgerJeromin]

ref #589 (comment)

[matkoniecz]

Still not sure is it worth implementing for tiny subset of micromapped playgrounds and given relatively low usability of info.

Also still blocked by lack of display of nearby objects of similar type.

But feedback was given.

[Cj-Malone]

After mapping a few parks I now think baby=yes/no on playground=swing is the wrong way to go. (In the UK) the vast majority of these have 1 baby swing and 1 normal swing on the same piece of equipment. I've been tagging them capacity=2 + capacity:baby=1.

[ltog]

@Cj-Malone : When I see

playground=swing
capacity=2

I think that would look something like this:

In the case where two or more persons can swing independently, something like

I tag them as separate nodes. It needs slightly more effort but IMHO is

• unambiguous (capacity=* in the context of swings is not documented on the Wiki AFAICS)
• easily extendable (e.g. with baby=*)
• richer in information: One can see the orientation in which swings are arranged
• better readable on a map: Large installations of swings will appear with a certain spatial spread, creating a good mental image for people reading such a map
• compatible: All applications understanding swings can understand this kind of tagging.
• reducible: If multiple swings clutter your map/application, you can still compress them into one data element. Expansion on the other hand is not possible.

Apart from reduced mapping effort, is there any advantage of using capacity=*?

[Cj-Malone]

Erm, I'd have though that the second image is actually 1 peace of equipment. But looking at the wiki it actually describes playground=swing as "A swing or swing-set." so I guess it's ambiguous.

We make a lot of compromises in OSM to make it easier to map. As an example I'd map the below as playground=structure not playground=climbingframe, playground=tunnel and playground=slide.

Or we mainly map roads as ways, not areas. Areas are undoubtedly better, but it's not feasible to do on a large scale, yet.

So I guess, in an area I super care about micromapping I'll start mapping each swing separately with baby=yes/no (and capacity=1), capacity=x in other areas, and playground:swing=yes in quick mapping.

[westnordost]

Hm, I will close this ticket. (Such detailed) playground mapping is IMO too fringe.

[mnalis]

(ref. https://community.openstreetmap.org/t/tagging-baby-swings/112832)