-
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Work on predict impact mode's visualization. #215
Conversation
- Workaround a bug where there are no example routes crossing somewhere - Add a legend and outline the colors on the map - Show neighbourhoods, for context where to expect green interior roads
let idx = 0; | ||
|
||
if (routes.length == 0) { | ||
window.alert( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this happening? The count of trips crossing a road before and after edits is changing, but we can't produce any specific examples?
Line 93 in d1e32b0
let Some(route1) = map.router_before.route_from_roads(*r1, *r2) else { |
Right now we're insisting both the path before and after edits exists. When one of them doesn't exist, the count will be lower, but we don't return it yet.
I think it's probably better to show one of the paths is missing, similar to #181. I am not sure what's going on yet, but I suspect the route happens to start or end right on a road with a filter, and so it outright gives up instead of going the other direction on the road. So both parts of #181 may actually be pretty important to get better results here!
filter={["==", ["get", "kind"], "boundary"]} | ||
paint={{ | ||
"fill-color": "grey", | ||
"fill-opacity": 0.5, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried a few and settled on this. In a large study area, I just want to remember where the edits have happened / are targeting
["linear"], | ||
["get", "after"], | ||
0, | ||
1.5 * minRoadWidth, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Line outlines in maplibre have to be done with a second layer underneath that's thicker
web/src/common/index.ts
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lots of small diffs due to just refactoring this a little
web/src/PredictImpactMode.svelte
Outdated
</p> | ||
|
||
<SequentialLegendBucketed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it make sense to use the buckets here? At first glance these seem more like limits than buckets, and thus should use the old legend.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if it's new to this PR, but I'm confused by this:

There are 3 numbers on this bit of interface:
before: 470
after: 27
prev/next: 30
What do the prev/next routes correspond to? It seems close to the "after" route count, but not quite equal.
LGTM - feel free to address any of my comments before merging if they seem reasonable, but I'm not overly worried about them in any case.
- seq legend - temporarily clarify the impact counts
Thanks for the review!
I put a little paragraph beneath temporarily. We have zone-to-zone OD data, saying there might be 100 trips from zone 1 to zone 2. Right now, we only pick one random point in zone 1 and 2, calculate that one route, and multiply the per-road-segment counts by 100. That's for faster processing. I'm going to add controls to let the user wait longer but see more accurate results, and think through how to communicate this better. |
Towards #36. Nothing in this mode here is really that nice yet, these're just little steps.
Before:


After:
I'm also thinking about optionally hiding or de-emphasizing some icons when zoomed. I'm having trouble seeing what's "important" here that the user did to cause all the changes shown:


If I hide unedited filters and TRs, the patterns of green and red in the neighbourhood make more intuitive sense:
Any opinions here?