office features should be lower priority

[sommerluk]

Consider the following screenshot, that was taken at z18:

In the left bottom corner, you see building “Immeuble Dogue”, and within this building a lawyer’s office rendered. There is also an embassy in this building, but it is not rendered.

In general, I would consider embassies as more important than lawyers, so they should be rendered with priority. (I’m not sure however, if this is practicable.)

[matkoniecz]

I agree that offices soups have priority lower than other amenities and it should be achievable.

[andrzej-r]

This is not an easy fix. At z18 the embassy icon is obscured by a building label. At z19, the embassy icon is visible but the label is obscured by the icon of a lawyer's office. These inter-layer priorities are deeply encoded in the style and I would rather not touch them, or many other things may be affected.

At the same level of hierarchy, amenities take precedence over offices (amenity icons are rendered before office dots, amenity labels - before office labels) but in this case this is not enough.

By the way, at this latitude we really need z20 or higher.

[sommerluk]

At z18 the embassy icon is obscured by a building label.

No. It was visible at z18 before we started rendering offices. The conflict is between office and amenity.

At the same level of hierarchy, amenities take precedence over offices (amenity icons are rendered before office dots, amenity labels - before office labels)

No. That’s exactly what’s currently not happening.

• The layers amenity-points-poly and text-poly have ORDER BY way_area desc which means that for features that are mapped as areas, bigger areas have precedence over smaller areas within the same layer.

• The layers amenity-points and text-point have ORDER BY score DESC NULLS LAST which means for features that are mapped as nodes, they are ordered by ele and height tags within the same layer.

We could change the ORDER BY statement without touching the layer order – and giving amenity=embassy a higher priority than office. Obviously, this would solve the problem for the example in the ticket description, because there both conflicting elements are mapped as nodes. But also obviously, as layer order has precedence over element order within a layer, this would mean that another office that is mapped as area would still have precedence over another amenity=embassy that is mapped as a node.

By the way, at this latitude we really need z20 or higher.

Yes. We have indeed yet even some (though not much) specific rendering rules for z20 in openstreetmap-cart. Now openstreetmap.org does only show tiles up to z19, but that’s a different fact.

[andrzej-r]

Can't test it at the moment. there were no intentional changes affecting building labels and amenity points but there was a bug that is fixed in 4.11. Would be good to wait a few days to see if the behaviour has changed.

Your proposal for sorting points according to their importance is sound and worth considering. Not quite sure how to implement it in sql, though.

I don't think it is the sorting order that is causing the issue at z19, though. Points and their labels are rendered separately (first points, then labels) and Mapnik will hide a label if there's already another object conflicting with it.

[jeisenbe]

Related to #3880