TL;DR: would you find it acceptable to tag allplayground=swing which are not usable by babies with baby=no?
I’m thinking of suggesting/implementing a new StreetComplete quest to improve the tagging of swings with regard to whether they can be used by babies or not.
Before doing so, I want to hear the thoughts of the community on the tagging scheme that would be required for/used by the quest.
A bit of background info
About two years ago playground=baby_swing was suggested: Tagging baby swings
Since then, it’s gotten a wiki entry, been added to iD and Vespucci, and used 351 times (not a huge amount, but spread across several continents as can be seen below)
What playground=baby_swing achieves, is that it is less ambiguous than playground=swing+baby=yes (see thread linked above)
However, since playground=swing+baby=yes has been in use before, I will likely remain as well (and ambiguous as to whether it means only for babies or also)
The tagging scheme I want to discuss
Here’s how the tagging by the SC quest would look like:
A swing set where all of the swings are for babies: playground=baby_swing
Seems to be acceptable given above background info
A swing set where none of the swings are for babies: playground=swing+baby=no
My main concern, as at the end of this post concerns have been raised it might be seen as spammy tagging of non-existence
A swing set where some of the swings are for babies: playground=swing+baby=yes
As discussed in the thread linked above, it doesn’t clearly express if its exclusively for babies or partially, so likely the best we can do and potentially already used like that
Some additional info
Why add the baby=no for regular swings and baby=yes for mixed swings?
Due to the nature of StreetComplete quests, which require a mechanism to discern nodes that need answering (swings without baby=*) and nodes which don’t (baby_swings and swings with baby=*)
Everything that is not playground=swing (e.g. basketswing, tire_swing) would be out of scope.
My view on the pro / contra
Looking at a swing and deciding if its for babies or not can be quickly done, so it lends itself to StreetComplete. The added info would be valuable for e.g. parents searching for parks with baby swings.
On the other hand, lots of baby=no tagging could be seen as spammy tagging of non-existence, and playground=swing+baby=yescould be misunderstood as for babies only in case of mixed swing sets.
I’d also consider something like capacity:baby to explicitly mark how many swings there are for babies. It would complement the existing capacity tagging (how many swings are there in total).
If capacity:baby is greater than 0, then it’s equivalent to baby=yes, if it’s equal to 0, then baby=no, and if it’s not tagged then we don’t know (though a capacity:baby=0 would be reasonably implied).
Also avoids the whole “Does baby=yes mean babies only, or a mixed swing” question.
As for the fundamental question of tagging non-existence, I think it’s still useful in this case.
I think before a tag is pushed at scale to our data there should be an established and documented tagging. That seems to be the case for playground=baby_swing, though it seems not the case for baby=yes/no. baby=yes on a playground=swing is discouraged and playground=swing indicates nothing about baby=yes/no.
Based on this, I don’t think pushing baby=yes/no is a good idea.
I’ll first comment on the individual inputs, then say more about the bigger picture. (In separate comments b/c I’m limited to three links per comment.)
If it were not documented or established I would agree. But my impression is that baby=yes/nois documented as well as established in the context of playground=* and playground=swing specifically.
Documentation
Key:playground - OpenStreetMap Wiki , Useful additional tags > Age Specifications: “baby=yes/no – If the equipment is primarily designed for babies.”
Key:baby - OpenStreetMap Wiki specifically mentions swings as example (and then discusses the ambiguity of baby=yes)
Looking into this I was surprised to see Key:capacity:baby - OpenStreetMap Wiki already has 102 uses. So there seems to be some precedent.
If used, I think it would have to be in combination with baby=yes to avoid data consumers which don’t read/understand capacity:baby missing the information. I.e. the tagging for a mixed swing (one of each) would be playground=swing+baby=true+capacity=2+capacity:baby=1.
Regarding the bigger picture, I have the impression that using playground=swing+baby=no for swings which are not for babies is acceptable. The edge case of mixed swings (one for babies and one not for babies), however, needs more consideration.
I thought a bit more about possibilities and see the following:
playground=swing+baby=yes
what I initially suggested
problematic as it makes use of the ambiguity of baby=yes instead of being clear
if a fitting relation existed, the nodes could also be “joined”, but I’m not aware of anything fitting. Relation:site - OpenStreetMap Wiki comes the closest but seems overkill. Then again, for constructs like this with 20+ swings on one set, maybe not anymore.
=> I’ll edit the initial post to feature the two nodes suggestion for mixed swings. (looks like editing is not possible)
baby=yes/no – If the equipment is primarily designed for babies. There is also provided_for:infant=yes in use to say the same.
and further above specificly on swings:
A swing or swing-set. For baby-friendly swings, e.g. bucket swings, use playground=baby_swing (or baby=yes, but this is not recommended)
As SC does usually not inform the user about the controversy and different options, I don’t think that part is suitable for SC at the moment.
In my understanding, at the moment, there is a documented playground=babyswing (used 14 times) and a discouraged playground=swing+baby=yes (used 5215 times) and a playground=swing+capacity:baby=* (used 104 times, 74 of them also have a baby=yes)
I don’t see any difficulty here:
swings for babies would be: playground=babyswing or playground=swing + capacity:baby>0
swings for kids would be playground=swing (the assumption would be, a swing has at least one seat for kids)
I agree that the tagging scheme would be clear and unambiguous.
A swing set with only swings for babies: playground=baby_swing
A swing set with no swings for babies: playground=swing
A swing set with some swings for babies: playground=swing+baby=yes+capacity=x+capacity:baby=y
The (slight) difficulty I see is with the burden it puts on data consumers (websites, apps, data analysis scripts, etc.). If a data consumer does not know about capacity:baby=* (currently at 102 uses), the tagging scheme results in the same ambiguity that the wiki warns about with playground=swing+baby=yes (because the disambiguating capacity information is not read).
I don’t see this as a huge problem, but something to weigh up against potential drawbacks of other options.
I feel that the 5,215 uses of the now discouraged playground=swing+baby=yes speak for an SC quest that spreads some form of non-discouraged use. The idea would be to just ask the user if an underspecified playground=swing is for babies or not.
Yes → change to playground=baby_swing
No → set playground=swing+baby=no
Mixed
either set playground=swing+baby=yes+capacity=x+capacity:baby=y
or split into multiple playground=swing+baby=no / playground=baby_swing nodes
… (or maybe there’s an even cleaner way I haven’t thought of yet)
My understanding is that after your SC quest, it wouldn’t be a niche tagging scheme anymore? In any case, that argument feels a lot like Tagging for the router - OpenStreetMap Wiki, and as such I’d dismiss it on those grounds.
Yeah, this tagging could also imply that there are two separate swings, one for kids and one for babies. Not ideal.
This idea would probably need another key similar to man_made. The only workable way for this I see is to tag each individual swing seat in addition to the whole structure.
However, I don’t think this is necessary to convey the information we want. And of course would also require work by data consumers to parse the eventual relation=site.
In the context of an SC quest, capacity:baby is a good balance between simple enough tagging and expressing the intended information.
I would call the it rather “only” and think that’s reasonable to have it pushed by SC. There is no ambiguity and it’s properly defined in the wiki.
Why use baby=no and not capacity:baby=0 and avoid the ambiguity?
If there is capacity=* and capacity:baby=*, playground=swing would be “complete” in this regards. But I feel, that first need a consensus and proper documentation.
The mixed one I’m not convinced either. Definitely I would not set any baby=yes and rather would replace it with a capacity:baby=*, see above.
I don’t see this a difficulty. Yes, a data consumer need to parse more than playground=* to properly show the “mixed” swings, though this they need to do anyway (or even more).
Given that baby swings (probably) only make up a small percentage of all swings, I don’t think it’s a good idea to make this SC quest active by default and to add the tag everywhere.
Below I’ll address first premises, then points regarding the tagging scheme, then other points.
Premises
Where I live they are quite common. Looking at ten parks near me as a sample, 6 out of 16 swing sets (> 1/3) are for babies.
numbers (click to view)
#nb = number of non-baby swing sets #b = number of baby swing sets
(there aren’t any mixed swing sets in my area)
Park
#nb
#b
中道中央公園
0
1
東小橋北公園
1
1
城南公園
2
1
森之宮公園
1
0
北中道公園
1
1
中本くすのき公園
0
0
玉津公園
1
1
東小橋公園
1
1
神路公園
1
1
真田山公園
2
0
sum
10
6
Would love to hear about other areas where the situation is different.
Please correct me if I’m wrong, but you seem to imply that baby=no is ambiguous. As far as I can see there is only an ambiguity with baby=yes (in that it could mean in part or only for babies), not with baby=no.
See: https://wiki.openstreetmap.org/wiki/Key:baby#Possible_issues
" while usage of baby=no is clear; usage of baby=yes is ambiguous"
Tagging scheme
Yes, the idea wit the “two nodes” bullet point was to tag each swing seat. Each of these would not require anything fancy of data consumers, just one playground=swing+baby=no and one playground=baby_swing.
I.e., the information of what is there is easily attainable, the only information that can’t be expressed with currently established tagging is that these two are part of one swing set (where a site relations comes closest, but doesn’t really fit I think).
I see though that there seems to be more support for capacity:baby=* as a feasible solution. Furthermore my concerns regarding data consumers don’t seem to be warranted.
Other points
Good point.
I wonder what a clear and succinct question and answer set then would be.
“Who can use this swing set?” → “Only babies” / “Kids and adults” / “Uh …” (capacity details in the sub menu)
“Is this swing for babies only?” → “Yes” / “No” (… but then there’s no route to getting info on mixed swing sets)
as according to the picture in the wiki? I‘d see these more suitable for toddlers. The swing they installed here for babies was a bear shaped plastic swing where the baby could lay and there were belt to secure it. Aren’t babies aged 0-1 year? I think it would be better to describe the shape of the swing seat (with a few types, extendable as needed) rather than a binary yes/no.
Yes. The intention was to use playground=baby_swing, and therefore am going off of the wiki definition: “swings with a bucket shape with holes for the legs, or a half-bucket shape and a safety belt, that is intended to reduce the likelihood of a very young child from falling out”
What I have around here specifically, you can see for example on this website (the red bucket swing). Usually these have a sticker saying they are suitable for kinds aged 1 – 3.
I see your point, and were swing type tagging new I’d agree, but think that would clash with existing in use tagging like playground=basketswing and playground=tire_swing which essentially just describe the seat type.
My point was rather: If baby=yes is ambiguous and is replaced by capacity:baby>0, then it would be straight forward to use capacity:baby=0 instead of baby=no.
baby=no might be ambiguous for people not reading the wiki and just treating it as another access key, where no would be forbidden, which is usually not the case. A normal swing is not forbidden for infants, it’s just not practical
I will say that if we end up going the route of tagging capacity, I think the Street Complete quest should just ask for two numbers; the number of baby seats and the number of seats for older kids, and tag everything based on that.
No need to ask any yes/no questions about whether the swingset has seats for babies when you can just get all that info in one go.
Without having counted them, I can subjectively confirm that for most playgrounds my daughter (4) has tested in Germany and elsewhere. Almost every somehow up-to-date playground provides at least one baby swing, no matter how many swings there are altogether. If the playground has only one standard installation with two seats, it’s usually one standard and one baby seat. I currently tag those mixed sets with capacity=2 and baby=yes but would happily switch to a less ambiguous scheme if the community can agree to one.
I’m actually not so sure about a respective SC quest, though. For one, knowing there’s a baby swing has actually been a valuable information until my daughter switched to standard swings. But on the other hand, I see that most mappers around seem to avoid mapping on playgrounds, and that might not be without a reason. When I occasionally visited playgrounds for mapping their equipment without being accompanied by a child, people got quickly sceptical and I had to explain both OSM in general and why playground data may be valuable for parents and children.
