Move "tourism=information" and "office" to lower priority in amenity-points query

[jeisenbe]

Fixes #3481

Changes proposed in this pull request:

• Move tourism=information to the lower priority tourism query within project.mml
• Move office to below the second tourism query

Explanation

This change makes sure that natural features and other amenities render first, and are not blocked by a tourism=information tag on the same node.

Since tourism offices are more important than most offices for a general map users, they can be tagged with office=* which would then be rendered as a blue office dot and text label after this change. Therefore, office is moved after tourism in the relevant layers within project.mml

A few features which are double-tagged with "office=*" and another major tag will be affected by this change, for example, an office in a building that is also tagged as "historic=manor". This should be a neutral or beneficial change, because offices are low-importance features for a general map.

Test renderings:

Before

After

Krzyzne Saddle

https://www.openstreetmap.org/node/1200864424#map=18/49.22847/20.04718
Before z18

z19

After z18

z19

Residenz des Botschafters

Double-tagged with office=diplomatic and historic=manor; this is one of the very rare possible combinations of office with a feature that is currently queried later that might be correct tagging (though I don't have any local knowledge about this area to confirm).
https://www.openstreetmap.org/way/23547938#map=19/52.48378/13.28926
z19 before

after

[Tomasz-W]

Please add #1372 with peaks priority.

[matkoniecz]

@Tomasz-W It can be also done with a separate PR.

[imagico]

Looks fine. Ultimately the prioritization of tags in the feature COALESCE() should be the same as the sorting order so prioritization of two tags on the same node is the same as for two nodes next to each other. And as said elsewhere prioritization should also be synchronized with starting zoom levels.

Managing all of this together by hand is next to impossible with the number of POI types we have meanwhile of course.

Relates to #3712.

[imagico]

Since this heavily interferes with #3712 it would be good if you could re-base and re-test this with the new code structure.

[jeisenbe]

I fixed the merge conflicts.

Thank you for #3712, it's a huge improvement, @pnorman

I notice that tourism=viewpoint ended up duplicated on two different lines after #3712:

                'tourism_' || CASE WHEN tourism IN ('viewpoint') THEN tourism ELSE NULL END,
                'barrier_' || CASE WHEN barrier IN ('toll_booth') AND way_area IS NULL THEN barrier ELSE NULL END,
                'waterway_' || CASE WHEN waterway IN ('dam', 'weir', 'dock') THEN waterway ELSE NULL END,
                'man_made_' || CASE WHEN man_made IN ('cross') AND way_area IS NULL THEN man_made ELSE NULL END,
                'historic_' || CASE WHEN historic IN ('wayside_cross', 'wayside_shrine') AND way_area IS NULL THEN historic ELSE NULL END,
                'tourism_' || CASE WHEN tourism IN ('viewpoint', 'attraction') THEN tourism ELSE NULL END
              ) AS feature,

I can remove one of the duplicates in this PR, or open another PR to discuss it.

[imagico]

Yes, i think you can remove the duplication here just as well.

[jeisenbe]

OK, I think a node double-tagged with "tourism=viewpoint" and "man_made=cross" or "historic=wayside_shrine" should show the physical object preferentially (the cross or shrine), rather than the viewpoint icon, so I've removed "viewpoint" from the first line.

I also checked that the test renderings are the same as those previously shown above

[imagico]

Nice, thanks.