Draw routes more clearly when unzoomed on large maps

[thomasnappee]

Hello, I would like to give a look to this issue found here (https://a-b-street.github.io/docs/software/ungap_the_map/plan.html#next-steps) and need some guidances

Are those map a good example of the problem ?

Do you have some constraints ? I think to first play with colors

[dabreegster]

I actually kind of forgot what the problem was. It's indeed hard to see things on an example this large -- spot the dark blue:

Happy for any ideas to make this more usable, no constraints

[thomasnappee]

So I added more contrast so that the road structure is easier to see

For the colors, I do as follow :

• Car : red
• Bus : yellow
• Bike : green
• Blue : pedestrian

Here is the result for night :

But still a mess when many roads.

Example with a more european style

Over the colors, is it only a cosmetic issue ? What are the use cases and problems related ?

[dabreegster]

These're indeed much easier to see! I just realized, are you working in the traffic simulation mode, or Ungap the Map? The "next steps" you linked is for the latter, so I've been assuming that so far. The styling / usability problems are different for different tools.

In Ungap the Map, the main view's job is to highlight 4 categories of cycle infrastructure:

It's pretty hard to distinguish these right now. And maybe color isn't the best thing to use -- looking back on this ~2 years later, line width or strokes might be better.

The original problem mentioned in the "next steps" was in some of the other modes of Ungap the Map. The animation at https://a-b-street.github.io/docs/software/ungap_the_map/user_guide.html#planning-a-trip shows one problem pretty well -- as soon as you zoom out, seeing the main and alternative routes are both not easy. And then in the next mode https://a-b-street.github.io/docs/software/ungap_the_map/user_guide.html#creating-new-bike-lanes, the same problem again, but maybe even worse, since the user is supposed to drag the route waypoints around.

You can add --ungap to get into this mode, ie, cargo run --release --bin game -- --ungap data/system/us/seattle/maps/central_seattle.bin

Any ideas for this tool particularly?

[thomasnappee]

For the ideas, yes several (some things I say will resonate with the two problems you described) :

• Clicking on a type button (trail, prot. bike lane, ...) should thicken/highlight the related roads and keep them highlited. It adds filtering (what you want is what you see).

• Clicking on the button now shows informations. The informations should be printed in an other way. When you hover the button, what is printed is already shown on the button, it's redundant. So maybe you get the informations when you hover, and choose another function (the filter for example)

• When creating a new trip, thickness should depend on the z axis but only if the number of nodes on a given area (the density) is low enough. Otherwise, I think it's the user who better have to zoom, because if the alternatives are short in lenght, and in a dense area, I don't see well why he would have to unzoom. If the user wants to drag the waypoints far away, zoom is needed. In this case, the limit is the density. An other way would be to click to pick and click to place instead of dragging. So that the user can click, unzoom, go somewhere far, zoom, and click precisely where he wants

• Moving and zooming the map should be done in a separate thread than computing the trip path. UX stonks

• The road labels can be shown in a different context. In my opinion, you would need the road name for particular cases : you want to work on a specific area (so you better have to search with a dedicated search bar), you want to describe a path with the successive roads (already shown in the trip planner, maybe you want this information to be extracted somewhere else)

And maybe color isn't the best thing to use -- looking back on this ~2 years later, line width or strokes might be better.

Both actually. Lines are better than colors but quickly limited to density, when the color contrast can keep something thin but easy to see

It's a bunch of points that can be debated ^^

[dabreegster]

I pretty much agree with all of these ideas! I haven't thought through how hard it'd be to implement some of these ideas yet.

Moving and zooming the map should be done in a separate thread than computing the trip path. UX stonks

Agreed, it's quite laggy. Using a separate thread is tough because everything needs to run natively (easy, can use one of the stdlib channels probably or similar) and in WASM (hard, because we need web workers, and getting this set up properly is a headache I haven't fought through yet). A related idea I've never tried is to rate-limit requests while dragging. We could measure the time to calculate a route and while the drag is ongoing, if that time exceeds some threshold, skip. Still would need some kind of timer to try the update after that timeout passes -- in case the user keeps the mouse held down but stops moving. None of this will be particularly nice to wire into widgetry, unfortunately. (FWIW in all my recent projects, I've been using the browser directly for UI and having a much easier time with things. Rust for the WASM "backend", something like Svelte / typescript for the frontend)