Improve colour scheme of timing pins about better-intersections HOT 5 CLOSED

Hey Jake, for the "possible future work", we can make more issues for those as we go along. I didn't want to do it in one issue.

from better-intersections.

Hey Jake, I am taking up this issue. Thanks

from better-intersections.

Needed some clarity on this issue -

The current implementation takes the average "cycle length" at an intersection and maps it to a colour. These comparative values are constant for all intersections i.e 30, 45, 60, 90 etc. The lighter the colour, the lesser the average cycle time.

"Perhaps green should be best practice and shades of orange/red/purple/back up to a constant of the worst timing measured" - what I understand - I take some constant time difference starting from black. And after each constant time, a lighter colour is assigned. Black will be represented by the worst time measured at that intersection. The colour will be decided on - which values the average falls between. Am I correct in interpreting this ? If so, how would you like me to take the constant time ?

A proposal - Since a constant time will have to be chosen for the above method - Currently, your method has 7 colours. I could split the best and worst cycle lengths of that intersection by 7 and each split can represent a colour.

from better-intersections.

Sorry for the delay - I'm in the process of moving house!

By splitting cycle length times into colours I was thinking of across multiple intersections.

I strongly think that the colour for an intersection should be:

1. By default, based on the total cycle time (green + flashing red + solid red) as this is how SCATS internally represents cycle times
2. Chosen based on the average (or median, but likely not enough values) of all cycle time measurements for that intersection

However I don't have strong views on which colours or how to choose the colours! Your proposal of 7 "buckets" sounds like a good idea, spanning green to black. I'm also open to continuously variable colours (ie. a gradient, no steps).

Cycle times tend to be whole numbers (eg. 50 seconds or 90 seconds) so if colours are discrete, perhaps the "buckets" of times that one colour represents should make sure to account for observational errors. Eg. If choosing 10 or 20 second steps, assigning orange to 45-55 seconds would make sure all intersections with a cycle time of approximately 50 seconds are shown as equivalent. I assume a scatter graph of total cycle times will demonstrate this.

Happy for you to experiment and we can merge and tinker further!

Possible future work:

• Building on point 2, handling vastly different cycle times (eg. bimodal distributions for different peak & off peak cycle times) will eventually be an issue. Perhaps we could have a time selector (min time cutoff and max time cutoff) or just a min/max/avg dropdown, but I'll make a separate issue for this.
• On point 1, you could argue it's more important to visualise the median wait time for a pedestrian arriving at a random time rather than the cycle time, which will depend on the ratio of green to flashing red + red - this could be an additional checkbox/dropdown.

from better-intersections.

Fixed in #7

from better-intersections.