added isochrone color palettes and opacity control

[s4chinjha]

This PR Closes #283 and adds an Isochrone Settings Section to the isochrone summary panel.

🛠️ Fixes Issue

As mentioned in issue #283, the default isochrone colors are way too opaque and are not very accessible (see also #191). There is also no way of changing opacity right now, which makes it harder to read the map underneath when multiple contours overlap.

👨‍💻 Changes proposed

New file - src/utils/isochrone-palettes.ts
Added a utility that defines the available color palettes and handles color interpolation across any number of contours.

Color Palette selector
Added an option for the user to choose from a few predefined color scales - Default, Viridis (colorblind-friendly), Plasma, and Blues.

The Default option keeps the existing API-provided colors so nothing changes for users who don't touch the setting.

Opacity slider
Added a slider (0–1) to control fill transparency. Useful when contours overlap or when the map details underneath need to stay readable.

Both controls update the map live - no need to redraw the isochrone after changing palette or opacity.

Palette is a global setting, not per-isochrone, so it will continue to work correctly when multiple isochrones are supported in the future.

Fixed rendering order so smaller contour rings are always visible on top of larger ones instead of being hidden underneath.

Updated tests to include the new store fields so all existing tests continue to pass.

I have used AI in assisting me

[ghost]

Preview is ready! 🚀 You can view it here: https://valhalla-app-tests.gis-ops.com/340

[s4chinjha]

Hii @nilsnolde
Could you please review this Pr when you get a chance?
Thanks!

[nilsnolde]

@s4chinjha pls don't send reminders before 3-4 days of no review. We're all aware of our projects and get to it when we have the time. This PR was also in draft until a few hours ago, which is communicating that it's not ready yet.

[nilsnolde]

few things:

• hardly any tests, you need to add some that are reasonable
• comment style issue(s)
• this PR is breaking current color picking for isochrones, see further below

[s4chinjha]

@s4chinjha pls don't send reminders before 3-4 days of no review. We're all aware of our projects and get to it when we have the time. This PR was also in draft until a few hours ago, which is communicating that it's not ready yet.

I am really sorry for that and will keep in mind to not send reminder before 3-4 days.
By the comment what I was trying to do was just ask you that if you could take a look whenever you were available.
But, I made a mistake of tagging you, my bad ig.
also from now I will try to ask for review only when the Pr is fully ready.

[s4chinjha]

few things:

• hardly any tests, you need to add some that are reasonable
• comment style issue(s)
• this PR is breaking current color picking for isochrones, see further below

I have tried to fix them, just take a look if the changes are good or any improvements are required.

[nilsnolde]

I commented on that before:

@s4chinjha s4chinjha force-pushed the isochrone-settings branch from 26453bb to 27fd413
4 hours ago

force-pushing after a review makes my life a LOT harder as a reviewer. pls re-write the history, so that you have a single commit pre-review and then at least one commit post-review, so that I can see what changed after my initial review.

[nilsnolde]

I realize that I'm being quite pedantic & strict. however, GSoC is all about learning and IMO the first thing to learn is open source etiquette.

[s4chinjha]

I commented on that before:

@s4chinjha s4chinjha force-pushed the isochrone-settings branch from 26453bb to 27fd413
4 hours ago

force-pushing after a review makes my life a LOT harder as a reviewer. pls re-write the history, so that you have a single commit pre-review and then at least one commit post-review, so that I can see what changed after my initial review.

I am really sorry again for repeating the same mistake.

But, I would like to explain why I force-pushed in the first place.
Before the review there were two commits, which are still part of the branch history.
After your review I made 3 more commits addressing the feedback.
Later I combined those 3 commits into a single commit to keep the history cleaner, and that required a force push.

For ref:
Commit pre-review (7e3b545)
Commit post-review (27fd413)

I wanted to ask what workflow you would prefer in this situation. If I make several commits addressing review comments, should I keep them as separate commits instead of squashing them (to avoid force-pushing), or is squashing them into one commit acceptable?

I’d like to follow the workflow that makes reviewing easiest and learn the correct way to handle this going forward.

[s4chinjha]

I realize that I'm being quite pedantic & strict. however, GSoC is all about learning and IMO the first thing to learn is open source etiquette.

I think that's how it should be everywhere.
Otherwise newbies like me would never properly learn how things work in open source and might develop wrong assumptions about how things should be done.

Having someone like you guiding us on these practices is really valuable, so I appreciate the feedback and the time you take to review.

[s4chinjha]

Will remove the comments.

[nilsnolde]

I wanted to ask what workflow you would prefer in this situation. If I make several commits addressing review comments, should I keep them as separate commits instead of squashing them (to avoid force-pushing), or is squashing them into one commit acceptable?

@s4chinjha I think my comment should explain that fairly ok. basically, try to be clean: 1 commit per post-review fix (e.g. 4 change requests -> 4 post-review commits with a good commit message). it's not so bad if you break that, that's just for me the most ideal situation. but really, zero force pushes after initial review, never if you can.

[nilsnolde]

IMO open source projects are the best to learn being a software engineer/developer. it should really be part of every comp sci program, e.g. complete 1000 hours of documented contributions in well-established OSS projects. that'd make it eventually so much more tolerable to work for tech companies.

[s4chinjha]

@mustaphaturhan i could not see your suggestion before, the one you added 2 days ago.Most of the comments were for me i forgot to remove them really sorry.

[s4chinjha]

IMO open source projects are the best to learn being a software engineer/developer. it should really be part of every comp sci program, e.g. complete 1000 hours of documented contributions in well-established OSS projects. that'd make it eventually so much more tolerable to work for tech companies.

Yep, they really are one of the best places to learn. If documented contributions became part of our coursework, I think we would learn far more than many lectures ever teach us.
OSS also forces you to develop the skills that actually matter in software engineering like understanding large codebases, communicating clearly, and collaborating with people across the world.

[nilsnolde]

I’ve fixed this by changing how colors are picked, each contour now gets a color based on its value relative to the largest contour, so the same contour always gets the same color even if the no. of contours changes.

hm, that's not true though, colors change depending on the no. of contours. I actually had in mind what you're writing here, so that all isochrones have a fixed color, e.g. largest one: max(color), 2nd largest one: max(color) - 1, 3rd largest one: max(color) - 2 etc. while I think that's better UX when changing intervals, the current PR implementation is more future proof, we should only need min & max of the palette.

[nilsnolde]

from UX this fine for me now. wdyt @mustaphaturhan ?

[mustaphaturhan]

the current UX looks fine to me as well. I just can't be sure if we would want to show the isochrone settings in the left panel or in the right, settings panel. either way, implementation looks fine.

[nilsnolde]

yeah the isochrone settings are currently a bit hidden, or at least for me it's hard(er) to notice them

[nilsnolde]

thanks @s4chinjha !

[s4chinjha]

I’ve fixed this by changing how colors are picked, each contour now gets a color based on its value relative to the largest contour, so the same contour always gets the same color even if the no. of contours changes.

hm, that's not true though, colors change depending on the no. of contours. I actually had in mind what you're writing here, so that all isochrones have a fixed color, e.g. largest one: max(color), 2nd largest one: max(color) - 1, 3rd largest one: max(color) - 2 etc. while I think that's better UX when changing intervals, the current PR implementation is more future proof, we should only need min & max of the palette.

Thanks for the clarification and for approving the Pr, glad the current approach works for the UX.