Decide on cycleability colour ramp

[joeytalbot]

Here's an example colour ramp I used in the ACTON project last year

[Robinlovelace]

Looks good, blue to red sounds fine. Good paper + reproducible code on the topic: https://www.jstatsoft.org/article/view/v096i01

[Robinlovelace]

Who is actioning this? Please assign yourself @joeytalbot or @Siequnu if you're up for giving it a bash and put ideas discussed in the meeting below. Need to nail this down so I'd say this is a priority.

[Robinlovelace]

You happy to action this one @Siequnu?

[Siequnu]

Ok — I’ll work out a few prototypes.

On 29 Jan 2021, at 20:33, Robin notifications@github.com wrote:

 You happy to action this one @Siequnu?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[Robinlovelace]

Great, thanks @Siequnu, keep us posted on any options/question.

[Robinlovelace]

Hi @Siequnu just following-up on this, please can you post the 'starter for 10' ramp you mentioned on Teams? That can get us going. For ramps, most important are the 2 or 3 colours in the beginning/middle/end. Keen to get this side of it sorted. Thanks!

[Siequnu]

The 10 step ramp that was discussed during the call is embedded below. This is a single-hue ramp, with the saturation decreasing as the steps increase.

                [100, '#DFDCD9'], //Westar
                [90, '#F4C7B1'],
                [75, '#F7B295'],
                [60, '#F18D6F'], //Apricot 
                [45, '#E7735A'],
                [30, '#D34C40'],
                [15, '#C43032'],
                [0, '#B60B27'] //Shiraz

During the call, a tentative consensus appears to have been reached regarding the use of single-hue ramps, however, these do have significant visual limitations:

• Ordinal data will have to be treated differently to continuous quantitative data
• Visual distinction between the steps is reduced in proportion with the amount of steps. After some trials, I found that when using the same colour (and altering the saturation), anything over 5 steps becomes hard to differentiate. Multi-hue ramps do address this — however moving from red to blue would have to include a third intermediary colour, most often white, in the centre
• Different data sets will have different distributions. For example, in the CycleStreets Cycleability API, the data appears to skew between 70 and 100, rendering, in the above ramp, a large amount of the data in a similar saturation.

Excellent research by the NASA AMES research centre does hint at the use of saturation and lightness rather than hue in ordinal data layouts, however, the question is further muddied when considering nominal or continuous quantitative data-sets, as

"in addition to failure of discriminability or identifiability, the visual spacing of the coding colors may not conform to the spacing of the coded quantities"

For the time being, I propose we use the above ramp as a stop gap. If we are to attempt to unify our "colour" steps among the different data sets, as discussed in the call, the logical solution would be some kind of dynamic step generation which identifies the distribution of the data points and calculates the ramp appropriately. This is of course additional time and effort, and I propose we revisit this issue once we have a good idea of the story behind the data.

For those who are further interested in common pitfalls when using colour to represent data, please do c.f. University of Texas' Claus Wilke's seminal work, Data Visualisation

I have included here a few more alternatives for you all to play around with: --xiketic: #03071eff; --dark-sienna: #370617ff; --rosewood: #6a040fff; --dark-red: #9d0208ff; --rosso-corsa: #d00000ff; --vermilion: #dc2f02ff; --persimmon: #e85d04ff; --carrot-orange: #f48c06ff; --orange-web: #faa307ff; --selective-yellow: #ffba08ff;

--purple: #7400b8ff;
--french-violet: #6930c3ff;
--slate-blue: #5e60ceff;
--tufts-blue: #5390d9ff;
--blue-jeans: #4ea8deff;
--vivid-sky-blue: #48bfe3ff;
--sky-blue-crayola: #56cfe1ff;
--medium-turquoise: #64dfdfff;
--turquoise: #72efddff;
--aquamarine: #80ffdbff;

--rosewood: #4f000bff;
--claret: #720026ff;
--brick-red: #ce4257ff;
--coral: #ff7f51ff;
--sandy-brown: #ff9b54ff;

--amaranth-purple: #b7094cff;
--jazzberry-jam: #a01a58ff;
--amaranth-m-p: #892b64ff;
--palatinate-purple: #723c70ff;
--cyber-grape: #5c4d7dff;
--bdazzled-blue: #455e89ff;
--sapphire-blue: #2e6f95ff;
--cg-blue: #1780a1ff;
--blue-munsell: #0091adff;

Colorbrewer2.org provides a few options, both multi-hue and single-hue.

[Robinlovelace]

Hi @Siequnu thanks for the options, the first one is visualised using reproducible code below:

colours_8 = c('#DFDCD9', '#F4C7B1', '#F7B295', '#F18D6F', '#E7735A', '#D34C40', '#C43032', '#B60B27')
colorspace::demoplot(colours_8)

^{Created on 2021-02-02 by the reprex package (v1.0.0)}

[Robinlovelace]

Here is a plot illustrating the trajectories of color palette in two-dimensional HCL, as described in the paper on in the Journal of Statistical Software linked to above:

colours_8 = c('#DFDCD9', '#F4C7B1', '#F7B295', '#F18D6F', '#E7735A', '#D34C40', '#C43032', '#B60B27')
# colorspace::demoplot(colours_8)
colorspace::hclplot(colours_8)

^{Created on 2021-02-02 by the reprex package (v1.0.0)}

[Robinlovelace]

What do you think of this, which goes to blue rather than white for the least busy roads, a multi-hue sequential palette:

[Robinlovelace]

I think this one looks pretty good, 5 and 10 color versions shown below:

colours = c("#A93154", "#BA4B8E", "#BC6EB9", "#B494D5", "#AEB6E5")
colours_10 = c("#A93154", "#B23A70", "#B94789", "#BC569E", "#BD66B0", "#BB77C0", 
            "#B788CD", "#B398D7", "#B0A8DF", "#AEB6E5")

colours
#> [1] "#A93154" "#BA4B8E" "#BC6EB9" "#B494D5" "#AEB6E5"
colours_10
#>  [1] "#A93154" "#B23A70" "#B94789" "#BC569E" "#BD66B0" "#BB77C0" "#B788CD"
#>  [8] "#B398D7" "#B0A8DF" "#AEB6E5"
colorspace::demoplot(colours)

colorspace::demoplot(colours_10)

^{Created on 2021-02-02 by the reprex package (v1.0.0)}

I suggest we go with that, what do other people reckon?

[Siequnu]

It's fine.

I think a larger issue brought up by this thread is the way we approach different types of data (nominal, ordinal, quantitative scales) and present them in the UI.

This hasn't been answered here, nor is it within the scope of this particular issue number.

As the colour schemes themselves are easy to edit — I assume — but the underlying philosophy less so, I suggest that we reconvene in a separate issue further down the road, which I imagine will lead to tweaking not only of our palettes and stops but also the debate between mono, binary- and poly- hued ramps and how we integrate these into our story.

Until then, I propose we go with your above suggestion for the cycleability colour ramp, which I'm affectionally nicknaming "The Poison Palette", after the Wisteria and Deadly Night Shade tones which make up constituent parts.

[Robinlovelace]

Good stuff @Siequnu. Although the issue is 'done' I suggest closing it only when we've got a few working examples using the palette. One question: what file format is best for saving palettes for JS/R interop?

[Robinlovelace]

This raises the wider question of colourschemes for the apps and visual identity. Worth opening a separate issue I think.

Thoughts @mvl22 / @Siequnu / @joeytalbot ?. Would be good to think about the colours used and aim to be consistent. I think the zoom level 2 colours are fine but a bit bright maybe, could we try a few more toned-down/sedate/cool colours?

webshot::webshot("https://actdev.cyipt.bike")

^{Created on 2021-02-02 by the reprex package (v1.0.0)}

[mvl22]

Yes, we didn't really think much about the colour scheme, mainly as this is just an alpha so we can all see what's on the map.

They are the background-color entries in the CSS stylesheet: https://github.com/cyipt/actdev-ui/blob/master/css/style.css

(Incidentally, your webshot::webshot thing presumably doesn't support WebGL which is why there is that white space.)

[Robinlovelace]

They are the background-color entries in the CSS stylesheet:

Good to know where the colours are. I think there are some good colours in the discussion above - suggestion on which to use for the visual identity very welcome but yeah I think it would be good to tone it down a bit from the red tone currently in there.

[mvl22]

Just to say I've centralised the colour scheme references in the CSS so it's now far easier to edit.

I had a quick play to try to implement the colours_8 one above, but it ended up brighter than the current scheme, which I think is already quite 'pastelly'. @Siequnu I think will probably know how to get a good result.

I agree we should go with something that is quite 'cool' (in the colour temperature sense) for this alpha map, for the week or two while we're looking it a lot before the proper UI.

[Robinlovelace]

Follow-up on this: is the colourscheme implemented in the actdev-ui site, how best to share the palette and what should the project colours be? Looking for input on this @Siequnu and @mvl22 if possible.

[mvl22]

Just to say that the legend is switched on (and shows some kind of error with the blues in the current ramp).

is the colourscheme implemented

Colour scheme is on @Siequnu's todo list.

[Robinlovelace]

Are these the same palettes?

[Robinlovelace]

Colour scheme is on @Siequnu's todo list.

Aha OK sorry yeah should have read that.

[si-the-pie]

The quietness field now appears in the CycleStreets journey planner API v1 output for the streets (which in v1 are stupidly called segment).

The value is an integer in the range 0 to 100 inclusive. It represents the quietness value of the owning way.

It is only available for newly planned routes and is included by default - you do not have to specify any change in parameters. The value will not appear in retrieved routes, which are those obtained by sending the number of a previously planned journey.

Add your API key to this url to see an example:

https://www.cyclestreets.net/api/journey.json?itinerarypoints=-0.1275,51.507222,CharingCross|-0.094722,51.514167,WestcheapCross&plan=balanced&segments=1&key=INSERTKEYHERE 

E.g. the above route includes this segment:

{"name":"Charing Cross (roundabout)",
 "legNumber":"1",
 "distance":"9",
 "time":"40",
 "busynance":"31",
 "quietness":"30",                 <---The_new_field
 "flow":"1",
 "walk":"0",
 "signalledJunctions":"1",
 "signalledCrossings":"0",
 "turn":"",
 "startBearing":"231",
 "color":"#3333aa",
 "points":"-0.12746,51.50722 -0.12750,51.50720 -0.12757,51.50718",
 "distances":"0,4,5",
 "elevations":"9,9,9",
 "provisionName":"Major road",
 "type":"segment"
}

[Robinlovelace]

Great to see, another tangible change resulting from the project. This plus the addition of separate cycleways by @dabreegster are changes that could benefit many people for many years to come. Many thanks Simon!

[joeytalbot]

Thanks Simon that's great! A quick rundown of exactly what goes into this quietness value would be very helpful. I'm guessing 100 broadly corresponds to a traffic-free path and 0 to a busy dual carriageway with a high speed limit. But what exactly are the contributing factors?

[Robinlovelace]

First thought: use quietness as the basis of an updated busyness rating which I still think would range from 1 to ~10 for 90%+ of segments in most places, right @si-the-pie ?

Based on the principle of 'fix things as far upstream as possible to save time in the future' I've opened this issue so our cyclestreets package can consume the shiny new variable. I think it's worth incorporating into the app and should only involve changing a couple of lines of code to do so, on the basis that the busyness on the segment highlighted would be

100 / 30 = 3.3

Clearly if there are segments with quietness values of 0 that will lead to infinitely busy segments. Can you give an indication of how frequent quietness values of 0 are (if they appear at all) and how you would deal with this in terms of visualising busyness @si-the-pie ?

[Robinlovelace]

Issue in the cyclestreets package: https://github.com/Robinlovelace/cyclestreets/issues/19

[mvl22]

But what exactly are the contributing factors?

Listed here: https://www.cyclestreets.net/api/v1/journey/

[joeytalbot]

First thought: use quietness as the basis of an updated busyness rating which I still think would range from 1 to ~10 for 90%+ of segments in most places, right @si-the-pie ?

I'd imagine we can simply use the new quietness value, ranging from 0 - 100. Or if we want to call it busyness, just use the same scale in reverse.

[joeytalbot]

Listed here: https://www.cyclestreets.net/api/v1/journey/

But the detailed explanation in that link just says: quietness int A measure of the cost of quietness of the route, a percentage value from 0 to 100.

The list of factors at the top of page includes "hills and inclines", which given our previous conversation I thought will not be a contributing factor to this metric.

[Robinlovelace]

Simple way to test it: find the quietness in 2 direction up and down hill.

[si-the-pie]

The information about how the quietness is calculated is old and incomplete.

The quietness values used in CycleStreets are shown at the percentage value for each highway type in the right most column at: https://www.cyclestreets.net/views/osmHighwayTranslation/

Those are the initial values assigned to the ways based on the value of the highway tag. Then lots of inference rules are applied that change the quietness based on presence of other tagging information such as width of cycle lanes, presence of lighting etc. Finally the impact of hill climbing / descending adds or subtracts from the busyness cost per way.

There has been some work going on over the years to clarifiy how the cost factors in CycleStreets are calculated, but these have never got to a state where they are ready for publishing.

The lowest value of Quietness is 1%. Any lower is not considered to be walk or cyclable. Not many ways have quietness less than 10%.

[Robinlovelace]

Closing because we have decided and because this issue has been superseded by https://github.com/cyipt/actdev-ui/issues/23