Change z-order of highway=road

[imagico]

As pointed out in #4905 highway=road has currently the same z-order value as unclassified/residential roads. This is not ideal - both in terms of line widths and in terms of semantics.

There are three options that could be considered:

• below the normal road classes (z<300)
• below the link roads (z<200)
• below all other roads

[dch0ph]

I would suggest below all roads with casing, i.e. between service and track, otherwise you'll surely get the clash of fill colours seen below?

This would also semantically be consistent with highway=road being a fixme state that doesn't otherwise fit in the sequence of road priorities.

Can we avoid a database reload? I would have thought that a snippet of SQL "update database to version X" would be sufficient to reset a loaded database to a new clean state?

[imagico]

I would suggest below all roads with casing, i.e. between service and track

I don't see any good argument for that. And the fill color difference would be visible in the inverse form with highway=service then.

Reasoning for the three options mentioned would be

• below the normal road classes (z<300) - conservative approach
• below the link roads (z<200) - matching the line width progression
• below all other roads - priority to any road with more specific tagging

Can we avoid a database reload?

Only through #4819.

[dch0ph]

Isn't "below all roads with casing, i.e. between service and track" the same as "below all other roads - priority to any road with more specific tagging"?

And the fill color difference would be visible in the inverse form with highway=service then.

Yes, any road branching off a highway=road will presumably create a bit of a mess. But (a) it is unlikely that a specifically tagged highway will branch off a non-specific one, and (b) it's fair enough that the highway=road is disfigured in preference to a well-tagged one. So the two are cases are not really symmetrical.

Are we not always going to have some mess with highway=road because it doesn't fit within a road hierarchy? It's a question of which road suffers.

Only through #4819.

Yes, that would be the ultimate way forward. But there may be mileage in introducing the principle of "update database to version X" SQL to allow more normalisation of data via lua transforms (thinking of some double tagging examples). At the moment, it's tricky to tackle the entropy of user tagging for fear of the dreaded database re-import.

[imagico]

Isn't "below all roads with casing, i.e. between service and track" the same as "below all other roads - priority to any road with more specific tagging"?

No, this means below tracks and paths as well.

Please no discussion of our data import process and database schema here - that is a separate matter. Database layout changes are not a big deal, they just need to be considered in release planning.