WIP: [styles] Let tourism attractions keep using their normal icons #3351

yannikbloscheck · 2026-01-24T19:36:26+01:00

yannikbloscheck commented

2026-01-24 19:36:26 +01:00

Fixes #2553

POIs with the tourism=attraction tag still get the same higher priority as before

Fixes #2553 POIs with the `tourism=attraction` tag still get the same higher priority as before

👍 1

yannikbloscheck added this to the February R1 release milestone

2026-01-24 19:36:26 +01:00

yannikbloscheck added the

styles

label

2026-01-24 19:36:26 +01:00

yannikbloscheck added 1 commit

2026-01-24 19:36:26 +01:00

[styles] Let tourism attractions keep using their normal icons

DCO / check (pull_request) Successful in 2s

Details

918c81ce88

Signed-off-by: Yannik Bloscheck <git@yannikbloscheck.com>

yannikbloscheck added the

public feedback needed

label

2026-01-24 20:28:53 +01:00

pastk requested changes

2026-01-26 18:51:43 +01:00

pastk left a comment

There are various issues with current attraction implementations indeed and we need to solve them.

However this change as-is will basically make attractions disappear from the map:

they won't be visible at lower zoom levels anymore
they won't be anyhow visually distinct from similar non-attraction POIs

I.e. even when zoomed in enough for an attraction POI X to appear, it won't be any different from other surrounding non-attraction POI Xs.

(keeping its priority higher helps a bit, but incomparable to drastic visibility loss)

There are various issues with current attraction implementations indeed and we need to solve them. However this change as-is will basically make attractions disappear from the map: - they won't be visible at lower zoom levels anymore - they won't be anyhow visually distinct from similar non-attraction POIs I.e. even when zoomed in enough for an attraction POI X to appear, it won't be any different from other surrounding non-attraction POI Xs. (keeping its priority higher helps a bit, but incomparable to drastic visibility loss)

data/mapcss-mapping.csv

					
				@ -1364,3 +1364,3 @@

				historic|castle|defensive;[historic=castle][castle_type=defensive];;name;int_name;1234;

				historic|castle|stately;[historic=castle][castle_type=stately];;name;int_name;1235;

				attraction|animal;1236;

				attraction|animal;[attraction=animal],[tourism=attraction][attraction=animal];;name;int_name;1236;

nit: remove useless name;int_name here and below

nit: remove useless `name;int_name` here and below

data/mapcss-mapping.csv

					
				@ -1744,3 +1739,1 @@

				attraction|historic;1614;

				attraction|big_wheel;1615;

				attraction|bumper_car;1616;

				attraction|water_slide;[attraction=water_slide],[tourism=attraction][attraction=water_slide];;name;int_name;1609;

I guess your intention here is to get rid of a separate tourism-attraction type for such POIs?

Have you tested it?
I'm pretty sure "tourism=attraction attraction=water_slide" would still produce two separate types tourism-attraction and attraction-water_slide

This should prevent it:
tourism|attraction;[tourism=attraction][!attraction];;;;147;

I guess your intention here is to get rid of a separate `tourism-attraction` type for such POIs? Have you tested it? I'm pretty sure "tourism=attraction attraction=water_slide" would still produce two separate types `tourism-attraction` and `attraction-water_slide` This should prevent it: `tourism|attraction;[tourism=attraction][!attraction];;;;147;`

I have tested it and they are still both appearing because of some special code for attractions, which is fine, but if that code ever gets changed, I want to make sure it disappears. That's why I added this despite basically no current effect.

data/styles/default/include/Icons.mapcss

					
				@ -593,3 +592,3 @@

				node|z16-[historic=tomb],

				node|z16-[tourism=aquarium],

				node|z17-[attraction=animal],

				node|z16-[attraction=animal],

why change? its often an animal cage in a zoo and it could be plenty of them

compared to it, many other attraction=* objects e.g. big_wheel, maze, roller_coaster are much more unique and prominent

why change? its often an animal cage in a zoo and it could be plenty of them compared to it, many other attraction=* objects e.g. big_wheel, maze, roller_coaster are much more unique and prominent

Because I looked at a zoo to have an overview and the animal cages weren't visible. If I look at zoo on a map, I want to see where which animals are. At zoom level 17 I don't have any overview of the zoo anymore. I'm also not against putting the other attraction types one zoom level up.

data/styles/default/include/Icons.mapcss

					
				@ -606,6 +605,7 @@ node|z17-[historic=archaeological_site],

				node|z17-[historic=gallows],

				node|z17-[historic=pillory],

				node|z17-[amenity=arts_centre],

				node|z18-[tourism=attraction],

There are still attractions mapped with only tourism=attraction tag and this would reduce their visibility too drastically. I think z15 would make sense, same as e.g. sculptures and memorials..

same goes to the priority, i.e. 1900 is way too low, its lower than most niche shops even

As said in the OSM wiki it is used for a lot of different things and really shouldn't be used alone

the wiki says explicitly

less commonly, to describe a facility which was built as a general tourist attraction. In some cases it is used alone, without another main feature tag, for a feature which is designed as a tourist attraction or "tourist trap"

the wiki says explicitly > 2. less commonly, to describe a facility which was built as a general tourist attraction. In some cases it is used alone, without another main feature tag, for a feature which is designed as a tourist attraction or "tourist trap"

libs/drape_frontend/stylist.cpp

					
				@ -163,6 +163,7 @@ Stylist::Stylist(FeatureType & f, uint8_t zoomLevel, int8_t deviceLang)

				    mainOverlayType = types.front();

				  else

				  {

				    auto const & attractionChecker = ftypes::IsAttractionChecker::Instance();

not used? and duplicated below

Yeah, just a leftover from a previous iteration. I'll remove it.

libs/drape_frontend/stylist.cpp

					
				@ -196,2 +199,4 @@

				        if (hasHatching && k.m_type == drule::area)

				          k.m_hatching = true;

				        if (isAttraction && k.m_type == drule::symbol && k.m_priority < 4300)

its better to avoid hardcoding priorities like this

libs/indexer/ftypes_matcher.cpp

					
				@ -729,6 +729,12 @@ IsTaxiChecker::IsTaxiChecker()

				  m_types.push_back(c.GetTypeByPath({"amenity", "taxi"}));

				}

				IsAttractionChecker::IsAttractionChecker() : BaseChecker(2 /* level */)

nit: please place it next to AttractionsChecker::AttractionsChecker() and add a comment explaining the difference

nit: please place it next to `AttractionsChecker::AttractionsChecker()` and add a comment explaining the difference

👍 1

pastk commented

2026-01-26 18:59:20 +01:00

Theoretically we could ignore tourism-attraction to be the mainOverlayType and always prefer other types to keep their icons. And we can still copy over tourism-attraction's higher priority and min zoom level to the POI drawing rule to keep them more prominent.

However still there are two issues with this approach:

many POIs lack an -s icon to use on lower zoom levels
visual distinction given by a different icon will be lost still

Theoretically we could ignore `tourism-attraction` to be the `mainOverlayType` and always prefer other types to keep their icons. And we can still copy over `tourism-attraction`'s higher priority and min zoom level to the POI drawing rule to keep them more prominent. However still there are two issues with this approach: - many POIs lack an `-s` icon to use on lower zoom levels - visual distinction given by a different icon will be lost still

pastk commented

2026-01-26 19:01:39 +01:00

A compromise solution would be to still use the star icon on lower zoom levels and switching to the actual POI icon when zoomed in. Not sure it'd look good though, this switching might be confusing - so this would need testing.

pastk commented

2026-01-26 19:11:27 +01:00

One more raw idea is to draw tourism-attraction icon in the geometry layer so it'd act as an underlay (e.g. just a bigger circle or a star) of the actual POI icon.

Also its of course possible to create subtypes like tourism-artwork-statue-major which would have more prominent styles and even icons. This approach gives the most flexibility and also POIs could be defined as "major" by other factors, e.g. presence of Wiki article, etc. But its manual work for every POI type.

One more raw idea is to draw `tourism-attraction` icon in the geometry layer so it'd act as an underlay (e.g. just a bigger circle or a star) of the actual POI icon. Also its of course possible to create subtypes like `tourism-artwork-statue-major` which would have more prominent styles and even icons. This approach gives the most flexibility and also POIs could be defined as "major" by other factors, e.g. presence of Wiki article, etc. But its manual work for every POI type.

yannikbloscheck commented

2026-01-26 19:13:39 +01:00

I think any icon switching would be indeed just very confusing. Also the problem that all the tourist POIs just look the same is an issue on all zoom levels.
"Here is some tourist attraction" is not of much use, but "Here is tourist attraction of type X" is - especially in many big cities, that are just swamped with tourist attractions.
I agree, that we should try to keep the zoom level.

I think any icon switching would be indeed just very confusing. Also the problem that all the tourist POIs just look the same is an issue on all zoom levels. "Here is some tourist attraction" is not of much use, but "Here is tourist attraction of type X" is - especially in many big cities, that are just swamped with tourist attractions. I agree, that we should try to keep the zoom level.

yannikbloscheck commented

2026-01-26 19:16:18 +01:00

@pastk wrote in #3351 (comment):

One more raw idea is to draw tourism-attraction icon in the geometry layer so it'd act as an underlay (e.g. just a bigger circle or a star) of the actual POI icon.

I like the idea in theory (even though it wont work with the geometry layer because of 3D rendering, but we always could add another artificial layer just for it), but not all possible POIs will be circled and that would lead to problems.

Having separate versions for everything is just too much extra work.

@pastk wrote in https://codeberg.org/comaps/comaps/pulls/3351#issuecomment-10182375: > One more raw idea is to draw `tourism-attraction` icon in the geometry layer so it'd act as an underlay (e.g. just a bigger circle or a star) of the actual POI icon. I like the idea in theory (even though it wont work with the geometry layer because of 3D rendering, but we always could add another artificial layer just for it), but not all possible POIs will be circled and that would lead to problems. Having separate versions for everything is just too much extra work.

yannikbloscheck changed title from ~~[styles] Let tourism attractions keep using their normal icons~~ to WIP: [styles] Let tourism attractions keep using their normal icons

2026-01-29 16:47:12 +01:00

yannikbloscheck removed the

public feedback needed

label

2026-01-29 16:47:23 +01:00

yannikbloscheck commented

2026-01-29 16:48:48 +01:00

(Temporarily pausing work on it as I currently don't have the mind for this. Will continue with it in a bit.)

yannikbloscheck removed this from the February R1 release milestone

2026-01-29 16:49:00 +01:00