natural=saddle missing as it is blocked by information=guidepost on the same node

[matkoniecz]

See https://www.openstreetmap.org/node/1200864424 - especially https://www.openstreetmap.org/node/1200864424#map=18/49.22847/20.04718 where information=guidepost is not rendered and still blocks natural=saddle

It can be argued that it is a tagging error, but guidepost is exactly on saddle and marks it so I feel that splitting it into two nodes would be tagging for renderer.

[kocio-pl]

I guess this is general problem with multiple tags on the same objects.

When we select objects from database, we look in this order (example code from amenity-points layer in project.mml, longer selection elements removed for clarity):

        (SELECT
            way,
            name,
            COALESCE(
              'aeroway_' || CASE WHEN aeroway IN ('helipad', 'aerodrome') THEN aeroway ELSE NULL END,
              'tourism_' || CASE WHEN tourism IN ('artwork', 'alpine_hut', 'camp_site', 'caravan_site', 'chalet', 'wilderness_hut', 'guest_house', 'apartment', 'hostel', 'hotel', 'motel', 'information', 'museum', 'picnic_site', 'gallery') THEN tourism ELSE NULL END,
              'amenity_' || CASE WHEN amenity IN ( ) THEN amenity ELSE NULL END,
              'advertising_' || CASE WHEN tags->'advertising' in ('column') THEN tags->'advertising' else NULL END,
              'emergency_' || CASE WHEN tags->'emergency' IN ('phone') THEN tags->'emergency' ELSE NULL END,
              'shop' || CASE WHEN shop IN ('no', 'vacant', 'closed', 'disused', 'empty') OR shop IS NULL THEN NULL ELSE '' END,
              'office' || CASE WHEN tags->'office' IN ('no', 'vacant', 'closed', 'disused', 'empty') OR (tags->'office') IS NULL THEN NULL ELSE '' END,
              'leisure_' || CASE WHEN leisure IN ( ) THEN leisure ELSE NULL END,
              'man_made_' || CASE WHEN (man_made IN ( ) THEN man_made ELSE NULL END,
              'natural_' || CASE WHEN "natural" IN ('peak', 'volcano', 'saddle', 'spring', 'cave_entrance') THEN "natural" ELSE NULL END,
              'waterway_' || CASE WHEN "waterway" IN ('waterfall') THEN waterway ELSE NULL END,
              'historic_' || CASE WHEN historic IN ('memorial', 'monument', 'archaeological_site', 'fort', 'castle', 'manor', 'city_gate')
                             THEN concat_ws('_', historic, CASE WHEN tags->'memorial' IN ('plaque') THEN tags->'memorial' ELSE NULL END)
                             ELSE NULL END,
              'military_'|| CASE WHEN military IN ('bunker') THEN military ELSE NULL END,
              'highway_'|| CASE WHEN highway IN ('bus_stop', 'elevator', 'traffic_signals') THEN highway
                                WHEN tags @> 'ford=>yes' OR tags @> 'ford=>stepping_stones' THEN 'ford' ELSE NULL END,
              'power_' || CASE WHEN power IN ('generator') THEN power ELSE NULL END,
              'tourism_' || CASE WHEN tourism IN ('viewpoint') THEN tourism ELSE NULL END,
              'barrier_' || CASE WHEN barrier IN ('toll_booth') THEN barrier ELSE NULL END,
              'man_made_' || CASE WHEN man_made IN ('cross') THEN man_made ELSE NULL END,
              'historic_' || CASE WHEN historic IN ('wayside_cross', 'wayside_shrine') THEN historic ELSE NULL END
) AS feature,

so when there is any tourism-related object, it skips every other, including amenity, natural... etc, up to historic.

But hey - there are two tourism lines! The second one is only for viewpoints to not be selected as viewpoints when there are some other tags. In this case peak (natural=peak) is selected and the rest is just skipped, so the end result is natural tag being rendered:

https://www.openstreetmap.org/node/5727619395

The solution for this issue seems to be easy - move information element from the first tourism line into the second one. However it means that we should be aware that all the information objects will not get rendered if there will be some natural, historic, man_made(=cross) etc. tags. And this is hard to really evaluate all the possible cases to make sure this is what we want.

Using multiple lines in SQL query is a dirty hack we do to deal with multiple tags when we want certain key values to be treated as less important.

[jeisenbe]

Currently we render icons for:

information = 'audioguide'
information = 'board'
information = 'guidepost'
information = 'office'
information = 'map', information = 'tactile_map', information = 'tactile_model'
information = 'terminal'

All of these are small, low-priority features, except perhaps for information='office'
However, I would think that if a single feature is double-tagged with information=office and another feature such as cafe or community_centre or shop, it would be more specific to show the other feature rather than the tourist information icon.

The one problem would be a feature tagged tourism=information, information=office and office=tourism - this would then show with the small office dot and text, rather than with the tourism info office svg icon. This seems to be unnecessary tagging, but it exists. I found 34 examples in Germany as an initial check: overpass-turbo

Rendering test:
(Top row: tourism=office with office=tourism (left) and without office tag (right))
Current:

After changing tourism=information to lower priority

[jeisenbe]

The issue with offices might be resolved by moving the line for offices till after the second tourism layer. In general, a feature that is only tagged with office=* is not very important for a general map, and an office is unlikely to be tagged with any of the low-priority items (i.e. man_made='cross', historic='wayside_cross', historic='wayside_shrine'

After moving office:

I thought we also had a general issue about prioritizing icons based on the initial zoom level at which they appear, so that a hospital (for example) would not appear at z16, but then be blocked by a hotel icon at z17. I searched the issues but I can't find a specific issue about this problem. #1026 and #964 are somewhat related but not exactly it. Perhaps we've only been discussing it in comments under other issues?