Too many possible values for class and loss of POI category due to promotion of subclass value

[JannikGM]

https://openmaptiles.org/schema/#fields says that "class" has a fixed set of possible values, however, if there's no class, then it will be the value of subclass.

However subclass has the original OSM value of fields like leisure which itself has 113 options: https://taginfo.openstreetmap.org/keys/leisure#values

Example; the feature for https://www.openstreetmap.org/node/421419270 is:

  "class": "hackerspace",
  "subclass": "hackerspace",

As many map styles will likely choose the POI image from the class, this adds a considerable number of icons a map designer would have to provide (200+ icons).

Currently, the information that "hackerspace" is of type "leisure" is lost, so the map renderer would have to map back these names to the type (which might not even be possible due to ambiguity in the field values which can be promoted to class/subclass)

I think this is a bug in the spec, because class should probably just be leisure (the source of the subclass value) then, i.e.:

  "class": "leisure",
  "subclass": "hackerspace",

---

This would mean the only possible values for class would be:

Originally specified:

1. shop
2. town_hall
3. golf
4. fast_food
5. park
6. bus
7. railway
8. aerialway
9. entrance
10. campsite
11. laundry
12. grocery
13. library
14. college
15. lodging
16. ice_cream
17. post
18. cafe
19. school
20. alcohol_shop
21. bar
22. harbor
23. car
24. hospital
25. cemetery
26. attraction
27. beer
28. music
29. stadium
30. art_gallery
31. clothing_store
32. swimming
33. castle
34. atm

Promoted from source of subclass (some existed in class already):

1. amenity
2. barrier
3. historic
4. information
5. landuse
6. leisure
7. railway
8. shop
9. sport
10. station
11. religion
12. tourism
13. aerialway
14. building
15. highway
16. office
17. waterway

[TomPohys]

Hi, the meaning of the class attribute is to make a sub-hierarchy for general OSM keys. In the end, you would like not to style the class=leisure but you would like to group similar entities and style the e.g. class=office and subclass=hackerspace.

It is similar to school class where you can make an icon for class=school or a different icon for sublcass=school and subclass=kindergarden

You are correct, that there are a lot of POIs in mapping.yaml that are not included in poi.yaml, and then there is class=hacerspace with subclass=hackerspace. This should be probably part of the office class.

[JannikGM]

class attribute is to make a sub-hierarchy for general OSM keys

Fair enough.

But as a stop-gap measure I believe that OMT should use the existing key from OSM as OMT class: "leisure=hackerspace" in OSM should become "class=leisure" and "subclass=hackerspace" in OMT.

you would like to group similar entities and style the e.g. class=office and subclass=hackerspace.

Even if "class=leisure" is not an ideal value, it's much better than "class=hackerspace" and "subclass=hackerspace"... "hackerspace" is too specific for "class", and the "leisure" information is lost (= the meaning and existing grouping assigned by OSM).

In the end, you would like not to style the class=leisure

It can still be manually remapped to "class=office" in OMT later (even though I don't think that makes a lot of sense for "hackerspace"), but currently the information that hackerspace is "leisure" is completly lost.

You are correct, that there are a lot of POIs in mapping.yaml

Instead of having a couple of classes, OMT currently has 200+ different "class" values.. and that defeats the purpose of class/subclass.
I also don't think it's a good idea to remap all 113 values (for "leisure" alone, let alone the other keys being promoted to subclass) to new classes as part of OMT. - it's not just "some of the POIs" (as you said on Slack), it's literally hundreds, if not thousands!

[ZeLonewolf]

Instead of having a couple of classes, OMT currently has 200+ different "class" values.. and that defeats the purpose of class/subclass. I also don't think it's a good idea to remap all 113 values (for "leisure" alone, let alone the other keys being promoted to subclass) to new classes as part of OMT. - it's not just "some of the POIs" (as you said on Slack), it's literally hundreds, if not thousands!

I disagree, I think that's exactly what OMT should be doing. class=leisure isn't useful to a style author - it's not likely that you would want to style all lesiure=* with common styling. The whole point of the class hierarchy is to group together elements that might share common styling and leisure, amenity, etc., are too diverse to use them as-is. Now maybe 200 is too many and it should be 100 or 50 or whatever, but thematic grouping is absolutely a desired feature for style authoring.

[JannikGM]

Above I said leisure only has 113 options; I'm not even sure how I arrived at that value anymore. I checked https://taginfo.openstreetmap.org/keys/leisure?filter=all#values again and it's 2144 values, not just 113.

You are correct, that there are a lot of POIs in mapping.yaml that are not included in poi.yaml

Does that mean this is only affecting those POIs which are listed in mapping.yml because all other POIs are dropped anyway?
In that case, shouldn't there be some step which verifies that all POIs in mapping.yaml also exist in poi.yaml or a safe-default mapping (instead of class=subclass) to avoid adding accidental "class" values (originating from "subclass")?

class=leisure isn't useful to a style author

I think it's still much better than "class=hackerspace", because it's one of 2144 options for "leisure", so it's nearly impossible to anticipate that you'll need an icon for that specific "hackerspace" value.

I believe I've also seen "class=butcher" (promoted from OSM "shop=butcher") in our maps (maptiler OMT data from April I think), so the POI had no icon (as we derive icons from class names).
"shop=butcher" is similar to "leisure=hackerspace": it appears in mapping.yaml but not in poi.yaml.
The fact that we'd need an icon for "butcher" is really unexpected and caused rendering errors.

So even if just temporarily, it would be more helpful to promote the OSM key to the OMT class:

1. Reduces the number of OMT classes. Even if some classes will be dropped eventually, people don't care wether "hackerspace" or "leisure" is being removed, their existing styles will need changes.
2. Re-establishes existing OSM hierarchy: Even if not perfect, at least there'll be some hierarchy and people can have symbols for all POIs, even if they aren't always perfect. For some obscure tags, it will take years before they are included properly (as many values must be remapped, including mapping errors, so they don't accidentally show up as "class" in OMT):
   • leisure: 2144 different values (= potential "class" values)
   • shop: 11212 different values (= potential "class" values)
   • ...
3. No loss of information, but more information provided to style creators: In maplibre and mapbox, style creators could adapt their style expressions to detect "class=leisure"+"subclass=hackerspace" if they want to add support for "hackerspace" POI ahead of OMT / they likely won't care if they have to match "class=leisure" or "class=hackerspace".
4. Fixed set of classes: If all possible classes are part of the spec, then it's managable to create icons for all of them. There won't be rendering errors because of missing icons. Specialization of icons should only have to be done on "subclass".