Skip to content
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

Start modelling movements at intersections #93

Merged
merged 5 commits into from
Jan 22, 2025
Merged

Start modelling movements at intersections #93

merged 5 commits into from
Jan 22, 2025

Conversation

dabreegster
Copy link
Collaborator

Part of #30 (with some TODOs there) and also necessary for #41. This adds a debug mode (from the "pick neighbourhood" page) to understand movements at each intersection. They're generated by looking at one-way directions and the simplest OSM turn restriction cases. Only used in this debug mode right now, not yet for routing.
image

It's going to be much easier to flesh this out with a better unit testing story. I'm thinking of manually drawing / clipping some test cases in JOSM, checking those in here. For movements, maybe the output can be expressed in the code as a list of movements between named roads, or maybe some GeoJSON / SVG output would be faster to understand.

@michaelkirk
Copy link
Contributor

image

What am I looking at here... 🤔 I initially assumed that the red arrows are illegal moves and the blue one is legal, but that doesn't seem correct. I'd expect there would need to be at least 1 way to either enter or exit each segment.

Or maybe I am reading it correctly, and we just haven't fleshed out all the legal turns from the available restrictions yet?

Copy link
Contributor

@michaelkirk michaelkirk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code seems good, but I don't quite understand the overall change yet.

to = Some(*w);
} else {
// Some other case, bail out
return;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not very familiar with this logic yet, but should these be continue?

let angle = angle_of_line(line);
Polygon::new(
LineString::new(vec![
euclidean_destination_coord(line.start, angle - 90.0, thickness * 0.5),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should put this in geo... unfortunately I have a big open LineMeasure change in PR limbo that I'd like to resolve first... I'll go kick that to see if it's still alive. 🤔

};

impl MapModel {
pub fn get_movements(&self, i: IntersectionID) -> GeoJson {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No biggie so take it or leave it: movement_arrows or movement_labels might be a better name, since these seem to be intended only as UI affordances, vs some business-logic struct.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To minimize churn, I'll leave this for now. Right now it's a debug mode, but that will probably turn into some kind of "edit turn restrictions at an intersection" mode, and the movements sent over will have a semantic ID that the backend knows how to edit.

@dabreegster dabreegster merged commit b4d9998 into main Jan 22, 2025
@dabreegster dabreegster deleted the movements branch January 22, 2025 21:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants