Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reviewing roads_info #5032

Open
dch0ph opened this issue Oct 29, 2024 · 2 comments
Open

Reviewing roads_info #5032

dch0ph opened this issue Oct 29, 2024 · 2 comments

Comments

@dch0ph
Copy link
Contributor

dch0ph commented Oct 29, 2024

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

reviewing the roads_info table with the z-order values #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
Copy link
Collaborator

imagico commented Oct 29, 2024

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 #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.

@dch0ph
Copy link
Contributor Author

dch0ph commented Oct 31, 2024

The number of layers is not an issue per se.

Thanks for clarifying the issues. I was wondering whether attraction=water-slide would be better in waterway-bridges. But it seems quite unlikely that you would have a water slide "interacting" with a waterway bridge. Perhaps comment in #5021?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants