-
Notifications
You must be signed in to change notification settings - Fork 85
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
Option to set default behaviour of road junctions based on max turn angle or lanes? #689
Comments
Get sketching Will this coexist/coincide with lane arrows/lane connectors? |
Asset authors can define the max turn angle of their roads. If a road has too big/small (can't remember which) angle, then the main road shouldn't connect to it by default. Basically this, bsaed on junction angle defined by roads (and/or mod setting): There's also median road (and single-segment two-way highways) situations like this that can be filtered based on angle:
Random thought: Some asset authors won't configure their roads properly, so we could have mod option that lets user define their own 'override default vanilla value' max turn angle? We should ideally visualise to user (in lane arrow/connector tools) why a route through a junciton wasn't facilitated by default (eg. a thin bar or arc depicting turn angle limits). As always, there are gotchas like this lurking around (this would need filtering by median detection instead): Random thought: I don't know what's computationally faster - median detection or using angles. Whichever is faster should be tried first, but then again, whichever situation is most common should be tried first? However, in real life sometimes sharp angles do get connected, for example:
|
For medians we can crowdsource that by hardcoding a list of most common road ids (do they have unique ids? i hope they do) which for sure have medians. And by allowing users to override/customise median setting by flagging their own assets as having or not having medians, and then submitting a text export snippet to TM:PE for updating our list. |
As i learn more how you want this UI to look i will sketch some ideas. |
CSUR team have provided some great info on medians here: #503 (comment) |
This sounds great! If I'm connecting a road at 45°, I can't think of a single time I've wanted the car to take the 135° corner -- especially not if that involves crossing multiple lanes of traffic. It would probably fix the infamous 2 one-way streets converging to a two-way street U-turn problem too. Does the enhanced pathfinder look at angles at all today? It would seem plausible to have a small penalty for a >100° corner and a large penalty for a >125° corner, as a step towards this... |
I will need to update my mods if this gets done. |
For some road networks, it would be useful to have mod option that, when enabled, prevents traffic taking far-side turns (cutting across oncoming traffic) in certain situations:
This would improve traffic on most medium, large and highway roads by limiting vehicles to only take near-side turns. It would also save asset authors the hassle of having to explain to their users the need to use TM:PE lane connectors to prevent far-side turns.
Note that, for road traffic at least, the user should still be able to choose to override the default on junction by junction basis when using either lane arrows or lane connectors. (real life example in #684 (comment))
However, when using lane arrows/connectors, it would be nice (but not essential) if we could somehow remind users about the default setting (if it's enabled) - for example they might be wondering why traffic isn't using a certain route through a junction. This could perhaps be a subtle (yellow?) bar across the exit road indicating "from your selected icoming lane/segment, this outgoing route is blocked by mod option".
Better still would be some way to visualise the normally allowed turning arc for given incoming route of a junction. That sort of UI would also be useful for lane arrows to depict the "arc of allowed exits" of a given arrow direction.
The text was updated successfully, but these errors were encountered: