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
feat: Render roller_coaster=track ✨🎢 #4666
Conversation
Yea, I’m not quite sure how that happens, but I think this is caused if the layers don’t change and it’s the same way, see: way/106610418 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't reviewed the cartography, but there's a few technical issues first.
I think you want to use attachments to get the layering correct for overlapping ways, but am not positive without checking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have not tested this yet, but i would suggest to reconsider rendering of the name tag.
In contrast to roads/paths a roller coaster track does not usually have a local and locally verifiable name. The name that gets tagged will almost always be inferred from the name of the overall structure. And for tagging the name of the overall structure attraction=roller_coaster
is clearly the more established method.
Also note cases of roller coaster tracks tagged with railway tags at the moment show that line labels of those often work poorly because they often end up overlapping other parts of the track, badly affecting readability in general:
https://www.openstreetmap.org/#map=18/49.03685/9.05351
I would suggest also to check and make a conscious choice about the results when a way is double tagged with roller_coaster=track
and railway=*
- which is a common occurrence at the moment.
Thank you all for the feedback 👍, I have removed the name rendering as I agree it looks cluttered. I chose not to render roller_coaster=track if there is a railway=*, to avoid double rendering. And I adjusted the tunnels and widths at z 20 and 19. I’m not sure how I can solve the extra table issue, so suggestions are welcome. Example of double tagged and single tagged roller coasters: Toverland, The Netherlands |
split the rendering in layers to avoid gaps
As most (if not all - can anyone come up with another real reason for double tagging? Perhaps there's a semantic argument to be made that a rollercoaster track is a type of rail track?) |
I’ve thought about this the last past days, but I can’t think of a good reason why you can double tag a rollercoaster and a railway. You are right that roller coaster track is a type of rail track, however it is not a railway. This Is because the functions are different. A roller coaster only gets build for entertainment purposes. While a railway is a road that transports people or goods, except for some exceptions like educational railways.
The last few days I have been experimenting with the correct background layer, I have added an line-cap:round background that makes shure there are no gaps between two track pieces. A problem with this is that where there is a looping, and the track makes an almost 180 degree turn the round fill-in is undesirable and looks weird. I need some more time and experimenting to get that right. |
CASE WHEN (tunnel = 'yes' OR tunnel = 'building_passage' OR covered = 'yes' OR tags->'indoor' = 'yes') THEN 'yes' ELSE 'no' END AS tunnel, | ||
CASE WHEN (bridge = 'yes' OR bridge = 'covered' OR bridge = 'viaduct') THEN 'yes' ELSE 'no' END AS bridge |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had overseen this before - this extends the tunnel rendering to also cover indoor=yes and limits the bridge values compared to those supported for highway/railway, which is:
openstreetmap-carto/project.mml
Line 983 in 17b6bbf
WHERE bridge IN ('yes', 'boardwalk', 'cantilever', 'covered', 'low_water_crossing', 'movable', 'trestle', 'viaduct') |
@matkoniecz - i think it is fine in general - especially compared to the monorail rendering, which is occasionally used right now as tagging for the renderer. The bridge rendering with the changed black casing is however - as already hinted - somewhat too heavy. I'd suggest to narrow the bridge casing width (half of the current seems to work quite well, maybe a bit more at the highest zoom levels) and limit the bridge casing display to z16+. |
I have adjusted the bridge casing widths. On roads a bridge is used when there is extra structure to hold up the road. With roller coasters this structure is always there and therefore you could say that roller_coaster=track has an implied bridge=yes. I’m currently content with the rendering. But to comply with your statements above an option could be to remove the bridge=yes completely or always show it. What do the other maintainers think of this? Like pnorman pointed out earlier there is not a real solution for this problem it is going to be a compromise anyhow. I feel like I have balanced the meaning of the secondary tags and rendered the data as is as good as possible. In my opinion it is wrong to render covered sections always below normal sections. Let’s say there is a covered lift hill high up in the air, the track below the covered lift hill is not covered because of the height difference. And therefore, should be below the tunnel section. But I could do something like this for the render order: |
Any updates ongoing? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My view here is essentially unchanged since i last reviewed this. The bridge casing seems fine now - because the signature of the roller coaster track is fairly heavy it is a bit difficult to recognize at times, but this is something that can be adjusted later as well.
I still think it would be best if the layering logic matches that of roads. After having looked at various roller coaster tracks in the database it is clear that there is no consensus among mappers about using layer/bridge/tunnel tagging on these with different semantics than for roads - hence providing feedback on this that is consistent with that for roads/railways seems prudent. If this is the goal, putting roller coaster tracks into the road layers would probably be more convenient than separate layers - even if interleaving between roads and roller coaster tracks is rarely necessary.
But this is not a big deal for me - if others are fine with the current approach i won't object.
I also still think the two things i remarked on the code (interpreting bridge
and tunnel
the same way as for roads, using @bridge-casing
instead of a color literal) would be good to change. Yes,cases where bridge=*
and covered=yes
are used in combination are an open question - but this is the case for roads as well, nothing specific to roller coasters IMO.
But likewise - if others are fine with the change as is i would be ok with that.
I'm happy to consider implementing changes to the rendering if there is a consensus that something needs to be changed. In my opinion, adding road logic to the mapping of roller coaster tracks could be problematic since it may require the use of bridge=yes, which could potentially create confusion when it comes to verifying the actual bridge structure. As in contrast with roads there is not a clear point where an overlapping track “bridge” starts and ends. That in turn may incentivize adding bridge=yes to all parts of the track, which could make bridge=yes on roller coaster track meaningless. I understand the importance of finding a solution that works well for everyone. I believe that the current rendering system is flexible enough to accommodate the forming of a consensus. Not having the extra tag bridge=* and covered=yes and adding the layering heuristics could inhibit the formation of a new consensus. I would like to hear some more opinions on this matter. |
Thanks you for working on this topic. I have the same opinion as you @tjur0 . On roller coasters you should not have to mark everthing as bridge=yes (what makes it indead meaningless). To add bridge=yes only to parts where it passing over a other roller coaster track is even more problematic. As you said, there would not be a clear end or start of this bridge, a bad idea. Using just layers is better imo. @imagico But as you also said, since many mappers map for the openstreetmap carto map (even it should not be goal to map for a map layout), there is much chaos in mapping roller coasters like having bridge=yes everywhere or railway=..... It even gets changed many times on the same roller coaster over the time. |
My (certainly limited) studying of mapping of roller coaster tracks indicates that the semantics of The key here is to consider our goal to support mappers in consistent use of tags. For that the bridge vs. non-bridge difference is not an issue, both this change and the traditional road rendering provide intuitive feedback. The handling of |
I can’t wrap my head around that you keep comparing roller coaster tracks to roads. Maybe that is my mistake from implementing many road features. From the start I took the water slide rendering as inspiration because IMO the closes thing to roller coaster tracks are water slides. And those also layer correctly without additional tags. |
I can see that and therefore i tried to explain in detail how - as far as i can see - the semantics of layer/bridge/tunnel tags on roller coaster tracks and on roads are the same for mappers and that there does not seem to be a consensus on a different meaning of those on roller coaster tracks. I am open to the possibility that this is a wrong impression but i would need evidence for that. Someone would need to explain to me the distinct meaning of those tags for roller coaster tracks.
I see. Two things to keep in mind here:
Again - i am not categorically against the approach chosen, my aim is for us to make a conscious and well informed choice here taking the different arguments into account. |
I looked at some parks in the US and Europe and I found no evidence that the bridge tag is often used for roller coasters/crossing roller coaster tracks. Most of the time the layers get used. Obviouly this is not a complete overlook. https://www.openstreetmap.org/edit#map=18/38.51458/-90.67468 [no bridge tag, different layers] |
Is this mergeable? It looks so cool!😁 |
Also wonder what is still needed now for a merge? Would be cool to have it included. |
Fixes #3596
Changes proposed in this pull request:
I based the design after typical rollercoaster track. I made sure that the track is not too wide, so small roller coasters and tracks next to each other render properly. While also making sure that it cannot be confused with railways.
Test rendering with links to the example places:
Before
Maverick:
After
Maverick zoom 18:
Cedar Point Ohio USA zoom 16:
Gemini zoom 18:
Millennium Force zoom 19:
Millennium Force zoom 19:
Millennium Force zoom 18: