Reviewing roads_info

[dch0ph]

Picking up on one of the many topics raised in #5027 :

reviewing the roads_info table with the z-order values https://github.com/gravitystorm/openstreetmap-carto/pull/4431 had added busway there - which might be a good idea to pre-emptively add in case we decide to render those in some form.

Adding a suitable slot for highway=busway would make sense, in (slightly) reducing the barrier to development. There was a promising start in #4226, and one point of apparent consensus was that rendering for highway=busway ought to be combined / visually coherent with highway=bus_guideway. I suspect it is a historical anachronism for guided busways to have their own layer (guideways). So would we want to create a slot for both and dump the separate guideways layer?

This connects to a more general question (triggered by #5021) of whether we have too many layers?

[imagico]

I would not want to mix in the discussion on actually rendering highway=busway here - inclusion in the z_order definition does not prejudice that decision. #4952 opened options for rendering both implicitly and explicitly tagged bus only or bus priority roads - but that should be a separate discussion.

So would we want to create a slot for both and dump the separate guideways layer?

Fixing #3581 will require integrating highway=bus_guideway into the road layers.

This connects to a more general question (triggered by https://github.com/gravitystorm/openstreetmap-carto/pull/5021) of whether we have too many layers?

The number of layers is not an issue per se. Separate layers are useful for modularization when

• they don't overlap too much in terms of the features shown or in the query logic contained in them.
• the intended drawing order is to have one fully after the other.

We should not just combine unrelated things into one layer just to keep the layer count low. There is very little benefit in that and making changes becomes more difficult.