Highlight changes

[XioNoX]

Working on a neighborhood with already pedestrian and one way streets, it would be useful to highlight when a street segment has been changed/touched.
This to see what needs to be changed from the initial state to get to the"desired" state. Especially if for example a one way street needs to have it's direction reversed.
Maybe by "just" making the arrow or modal filter bolder (even though that would help if we were to remove a restriction).
Or maybe it's possible to "bold" the street segment without impacting the shortcuts "readability" ?

[dabreegster]

This has been a big challenge from the beginning. Existing modal filter icons are slightly faded out right now, but that's it. We could do the same for one-way arrows, but they're so hard to see in the first place.

We could try...

• much bolder outlines for new arrows and filters
• using line width / outline thickness
• pointing out roads that get busier or less busy relative to the baseline (with a diverging color scheme?)

Not sure if it's relevant, but from https://youtu.be/hoi1BNT-oXs?t=41, another idea is showing cell color per road line, not as an area. That maybe frees up the background area to show some kind of relative change heatmap?

I'll try and post some mocks later, maybe temporarily add settings to try switching for real cases

[dabreegster]

By the way, if you wanted to try adjusting the frontend styling, it's much easier than working on the backend -- just maplibre styles. You'd follow setup instructions at https://github.com/a-b-street/ltn?tab=readme-ov-file#installation, then modify things like

ltn/web/src/ModalFilterLayer.svelte

Line 22 in a967857

"icon-opacity": ["case", ["get", "edited"], 1.0, 0.5],

and

ltn/web/src/RenderNeighbourhood.svelte

Line 26 in a967857

$: lineColor =

, and have most things live-update in the browser. But if you have ideas / color palettes in mind, I can also just plug them in and paste screenshots

[XioNoX]

Maybe scope creep, but looking at your "lines" example, it made me realized that the cyan area in the screenshot below could also be seen as 4 different areas. Even though they share a one way "entry" or "exit" street, a car needs to go back to the main street to enter the next area.

Not sure if it could be highlighted by your tool.

The middle (between cyan and yellow) could also be its own cell. As a network of interconnected pedestrian (or no exit) streets.

Not sure if it's relevant, but from https://youtu.be/hoi1BNT-oXs?t=41, another idea is showing cell color per road line, not as an area. That maybe frees up the background area to show some kind of relative change heatmap?
Maybe a cell highlight toggle with 3 options: disabled/area/lines ?

Or the other way around, let the user decide what is shown as area, and what is shown as lines for example :
Lines = None/cells/shortcuts/modified
Area = None/cells
As we usually don't need to have all the information shown at once.

[dabreegster]

Even though they share a one way "entry" or "exit" street, a car needs to go back to the main street to enter the next area.

I honestly don't know how to visualize the cells for one-ways. I tried a while ago with a-b-street/abstreet#1043. If you could sketch in this example how you'd imagine the cells to look, I could try implementing, but it kind of breaks the idea of a "fully inter-connected" area without using the main road.

Or the other way around, let the user decide what is shown as area, and what is shown as lines for example

Ah, I like this. If you look in settings, there's already a way to try the cell coloring on roads instead. Let me add in this option just to show roads with any kind of edit directly on them.

[dabreegster]

Classic shortcuts:

Cells:

Edits:

Color suggestions welcome for the last; white is unchanged, grey is changed

[XioNoX]

I honestly don't know how to visualize the cells for one-ways. I tried a while ago with a-b-street/abstreet#1043. If you could sketch in this example how you'd imagine the cells to look, I could try implementing, but it kind of breaks the idea of a "fully inter-connected" area without using the main road.
I think the cell border should be on the one way street and not in between two streets. No idea how your cell algorithm works though.

Ah, I like this. If you look in settings, there's already a way to try the cell coloring on roads instead. Let me add in this option just to show roads with any kind of edit directly on them.
Oh nice !! It does look cleaner to me. But it's probably just personal preference here.

The "Road thickness depends on shortcuts" isn't too useful to me as it doesn't help distinguish a 0 shortcut road from a 2 shortcuts road (where the 2 could be bad).
With #69 it might become enough to "just" highlight roads with any kind of shortcuts.
One idea, maybe, is to animate the roads that have shortcuts, like on https://cyclopolis.fr/carte-interactive

[dabreegster]

Ooh, I like that animation as a possible axis for communicating -- it could leave color free to indicate something else. For reference for later implementation, this is called "ant path" and can be done like this: https://github.com/alan-turing-institute/uatk-spc/blob/77c942f96a76ffb0fe1eccf432cb6bdeaf3fc2cb/web/components/Flows.svelte#L59

The speed of animation could potentially be based on the number of shortcuts.

[XioNoX]

Color suggestions welcome for the last; white is unchanged, grey is changed

I've just tested it, and it's perfect !

I think it would be a bit more convenient to have "Style for roads in a neighbourhood" on the main screen and not have to go to a menu to permit for quicker changes between styles. But that's just a detail at this point.

[TFCx]

Clearly, coloring the roads instead of the blocks is cleaner ux-wise. :) but we lose the notion of shortcuts.

The shortcuts could be visualized using the animated dots. Imagine using a few hundreds / smaller ones like a boids demo. However I'm pretty sure there's a problem in the current implementation (the performances are really bad in my browser even with hardware acceleration). There's nothing dynamic to handle (on the computing side) so it should "just be" about moving a few hundreds simple entities on pre-computed paths, no? (i'm not saying the performance issue comes from LTN code, maybe it's originating from svelte).

I'm not too fond of the ant paths from cyclopolis, as I've removed them in my own version (just for your information, @XioNoX is another french activist, also forking cyclopolis for his own city). The animated ant paths are very "intense" cognitive-wise. Maybe by making them very slow (and increasingly faster the more shortcuts traverse through a segment), it might work.