Playground=climbing/climbing:frame/...: "Namespacing" in key values?

General talk Tagging general discussion
, ,
1

Together with two other mappers, I am currently working on a proposal to extend the playground equipment mapping, because during years of playground mapping, we have repeatedly encountered gaps that we would like to fill.

In this context, we ask ourselves how we should name the values for new devices. Playground equipment is very diverse, but there are common “classes” of equipment that are intended for similar activities: e.g. swings (" standard" swings, baby swings, basket swings, tyre swings, rope swings…), climbing devices (frames, walls, poles, slopes…), water play equipment (pumps, canals, barriers, water wheels, sprinklers, water cannons…), balancing devices, rotating devices, sand play equipment, and so on.

Therefore, I wonder if it might be a good idea to use some kind of “namespacing” in the value of the playground key, e.g. playground=climbing/climbing:frame/climbing:wall/climbing:pole… or playground=water/water:wheel/water:channel.

A namespace in OSM is defined as “a prefix, suffix or infix to a key”, but here, we are talking abound values. Is there a reason why this should be limited to keys? Couldn’t a value like climbing:pole just as well be evaluated as a fixed term like climbingpole or climbing_pole, but with the advantage that one could theoretically check unknown values for a prefix component like climbing:* to be able to assign a rare device to a device class and to basically evaluate an unknown device (e.g. climbing:rare_device_with_unique_name)? So far, I know this kind of namespacing only for the surface key, e.g. surface=conrete/conrete:plates/concrete:lanes.

A background info on this: TagInfo currently knows 1,099 values for playground=*, 969 (88%) of them are used less than 10 times, 61% only a single time! A significant number of them cannot be evaluated in any meaningful way. Many of them could certainly be better categorised in this way.

P.S. In other contexts, we might use playground=<class> + <class>=<device>, but I don’t think that’s a good idea for playground equipment (it would lead to a lot of unnecessary new homonymous uses like playground=water + water=basin).

3 Likes
2

I think it is an excellent idea to have more documented playground equipment in the wiki.

But I don’t think we should add a prefix system to this tag, as it will only encourage to add more values that nobody will ever evaluate.

I don’t think this will ever happen. If I ever find the time to work at Babykarte again, I will add new playground equipment values but only documented ones, not some regex like

show all that start with climbing: as “unknown climbing equipment”.

3

The problem here may remain the same as it is right now in that mappers that don’t find something that immediately fits will resort to leaving the feature out. The proposal would at least give a somewhat clear path towards common fallback values.

In a way this is just a bit more structured than what already exists for, e.g., buildings. Buildings have something of a hierarchy, just with parents that are not as apparent from the tags, e.g. apartments is a subtype of residential, which is a subtype of yes, and so on.

I think data consumers may very well decide to ignore all this and treat unknown values as playground=yes. Babykarte is admittedly the only data consumer I know that looks at playground equipment (thanks for that!), but there might be others as well.

1 Like
4

Yes… without a prefix. playground=climbing_frame is kind of a subtype of playground=climbing. I am not against designing such a system.

1 Like
5

Hi, I have to say that I like very much your proposal to better define and categorize playground equipment. On the specific question about namespace, I don’t see a big advantage in using an explicit namespace as climbing:pole instead the more standard combined value climbing_pole, but I fully support the attempt to clarify and make examples for a wide variety of equipment so that we can reduce and “standardise” more the values.

6

typically playground=* would be some subtype of playgrounds, we usually do not use keys as is done here, although there are few similar cases (“golf”).

in part this is normal, one can imagine many words for playground equipment, and this is not the first long tail we are looking at :wink: Don’t be fooled by the percentage, it is not the usage percentage, but the percentage of different values that taginfo has counted. 60% of all playground tags are sandpit, slide, swing and the not very meaningful “structure”.

A proposal to document more values, so that they become wider known, is a good thing,

I don’t like the water idea. There is playground=water with the definition “A special water device.” (this is misleading, maybe add “see subcategories above” or sth. similar), then you propose various water “subtypes”:
pump
channel
stream
seesaw
basin
barrier
archimedes_screw
wheel
cannon
sprinkler

my suggestion would be to flatten this hierarchy, why would we want to have water features in a second level? water_wheel, water_cannon, etc,

On the playground key page, there is already another, very narrow definition for playground=water: “Archimedes’ screw a water pump for making mud, and similar”, so it should be made clear that this part would be a redefinition, not merely an extension.

7

Using appended tags looks awkward and will likely cause problems when querying tags. The underscore character is often treated as a space in a multiple word name. Most query parsers treat the resulting value as a unique because it would expensive to check whether it might be a set of multiple tags. Preventing the parser from effectively searching for both collapsed and expanded version of the namespaced key:pairs at the same time.

Note: playground:climbing=frame is the same as playground=climbing + climbing=frame.

8

Thats the idea. water is totally unspecific and only suitable as a generic term/fallback value that should be specified more precisely if possible (like building=yes, surface=cobblestone…). water_wheel, water_channel, water_cannon etc. become new values that specify this. (Or I was thinking of “:” instead of “_”, but I realise that this is not very useful).

We are therefore not talking about a redefinition, imho (because the meaning remains the same), but new possibilities of specification. We will make that clear.

9

this is why I would not introduce it. We can have a suggestion for all kinds of such features and have them tagged directly, instead of using 2 tags of which one is almost useless.

10

You mean, you would not use “fallback” values like “water”, “balance”, “climbing” etc.? And deprecate “water”? This general terms are very useful to map special devices and edge cases without having to come up with a new tag every time. E.g. there is a broad variety of devices that are “somehow” intended for balancing, but a more precise specification is difficult because they are a mix from ropes, bars, beams, bridges…

2 Likes
11

I’m very happy with the expansion of possible equipment to map. So keep up the good work.

I would like to see very clear examples on how to map structures with multiple slides, ladders, … I see a lot of very creative structures that have a lot of features and I don’t think a node for each of the features is a good approach. So the question on how to map bigger strutures should be answered on the wiki. A picture of the structure and the exact tagging used.

12

Yeah, we should definitely add something like that to the wiki (but I would keep this independent from the proposal, because the proposal is about the values of the devices themselves and not about giving playground tagging guidelines).