Add styling for playground features

[aditya1010-max]

Addresses #12142

Adds distinct styling for playground=* features to make them visible and distinguishable from generic geometries.

Includes styling for:

• playground=zipwire
• playground=tunnel_tube
• playground=structure

Colors were chosen to be visually distinct yet consistent with related features. Happy to adjust them based on feedback.

---

After

---

Preset panel

[tyrasd]

My first thought: We should only use one single color for all playground features. And as blue and green are already used for water/natural features a lot, I think it's best to use another color. The proposed shade of pink should work fine.

If needed, for some special features like the zipline and tunnel features mentioned above, we could distinguish them by altering the stroke and/or dashing (e.g. in order to create analogies to road tunnels / bridges).

[matkoniecz]

We should only use one single color for all playground features

What about allowing at least different shades of pink?

[aditya1010-max]

My first thought: We should only use one single color for all playground features. And as blue and green are already used for water/natural features a lot, I think it's best to use another color. The proposed shade of pink should work fine.

If needed, for some special features like the zipline and tunnel features mentioned above, we could distinguish them by altering the stroke and/or dashing (e.g. in order to create analogies to road tunnels / bridges).

Yeah, colors wouldn’t work well here, since they’re already used for things like fountains, trees, and shrubs, which are commonly present in playgrounds and wouldn’t blend well with playground features.
For tunnel we can use dashed lines, for zipline i think we can keep it as plain lines.

[tordans]

I suggest we split up the effort. The initial issue and IMO most important one is to be able to see that lines / areas with playground=* are something else than any other unstyled feature.

Implementation detail: Is there a way to add this without adding all tags to the class "registry" but just the key? I assume adding all those tags will add to the performance cost that our rendering has.

The second phase could be to see how to better style specific playground=* features.
Personally, I don't see the need for this at this point; I see it more as something for #11189

[aditya1010-max]

Implementation detail: Is there a way to add this without adding all tags to the class "registry" but just the key? I assume adding all those tags will add to the performance cost that our rendering has.

I think we can try implementing this, as it would be beneficial, especially from a performance perspective.
We can treat playground=* as key-based (adding only tag-playground and skipping value-based classes), which should avoid adding multiple entries to the class registry. Value-specific styling could then be handled separately (e.g., via attributes).
This idea could potentially be extended to other tags where value-based classes add limited benefit.

[matkoniecz]

Do we want say playground=ajanahdhdbdu line (or with other gibberish) also become styled?

[aditya1010-max]

Yes , the base .tag-playground style would apply to any playground=* value, which helps distinguish these features from unstyled ones. More specific styling would only apply to known values, example-

.tag-playground { ... }
.tag-playground[data-playground="zipwire"] {
/* zipwire-specific styling */
}

Unknown values would simply fall back to the base style.

[aditya1010-max]

This plan follows the approach suggested by @tordans above, with additional details to clarify the steps. It is divided into two logic steps and two styling steps for easy implementation

a. Update classification logic

Modify tag_classes.js to treat playground=* as a key-based classification:

• Add only tag-playground and skip generating tag-playground-* value-based classes

---

b. Apply common playground styling

Define a single, consistent style to make playground features visually distinct from unstyled features:

Example:

.tag-playground { ... }

---

c. Expose playground values as attributes (Phase 2)

Add logic in the rendering layer to expose playground values as attributes

(e.g., data-playground="zipwire").

---

d. Enhance styling in a separate layer

Introduce more specific styling based on playground values, using attribute-based selectors instead of introducing additional classes.

Example:

.tag-playground[data-playground="zipwire"] {
  /* zipwire-specific styling */
}

---

[aditya1010-max]

For now, this adds special styling only for playground=structure (area only).
Other playground=* features continue to use the base tag-playground styling, which already makes them visually distinct from unstyled features.

After for playground=* (except special CSS presets):

After for playground=structure (area only)

How it blends:

Before:

After:

[aditya1010-max]

Area	Line

[aditya1010-max]

Do we want say playground=ajanahdhdbdu line (or with other gibberish) also become styled?

I get the concern about unintentionally styling arbitrary values. One option would be to treat the base class as the default style, and then apply additional styling only for specific presets. That would give us flexibility to fine-tune individual presets without over-styling everything by default. However, that approach also limits the benefits of this architecture.
As for gibberish values, those are ultimately a data-quality issue rather than a styling one. Personally, i think if someone intends to add invalid data, they can do so regardless of how styling is implemented, Styling should remain robust and predictable, and not be responsible for determining data validity

[aditya1010-max]

I just noticed that the current styling for playground=area seems to clash with landuse=industrial, so I’ll revert it to the base class styling. I think it’s better to keep this PR focused on introducing the architecture and a base style.

For the styles used in this PR, since these styles will apply across multiple tags, feedback and opinions are appreciated.