search

gravitystorm / openstreetmap-carto

A general-purpose OpenStreetMap mapnik style, in CartoCSS
Other
1.53k stars 819 forks source link

Change z-order of highway=road #4908

Open imagico opened 10 months ago

imagico commented 10 months ago

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:

dch0ph commented 10 months ago

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?

image

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 commented 10 months ago

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

Can we avoid a database reload?

Only through #4819.

dch0ph commented 10 months ago

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 https://github.com/gravitystorm/openstreetmap-carto/issues/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 commented 10 months ago

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.