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

import internal lane shapes from OpenDRIVE #4331

Closed
namdre opened this issue Jul 15, 2018 · 7 comments

Comments

@namdre
Copy link
Contributor

commented Jul 15, 2018

No description provided.

@chengyuny

This comment has been minimized.

Copy link

commented Aug 16, 2018

Hi, I am very interested in this feature. How is it going now? Thanks

namdre added a commit that referenced this issue Aug 16, 2018
namdre added a commit that referenced this issue Aug 16, 2018
namdre added a commit that referenced this issue Aug 16, 2018
@namdre

This comment has been minimized.

Copy link
Contributor Author

commented Aug 16, 2018

Some networks look better when setting option --opendrive.advance-stopline 0.

@namdre

This comment has been minimized.

Copy link
Contributor Author

commented Aug 16, 2018

@chengyuny Please test out the new option --opendrive.internal-shapes
There are still some geometry issues (see above comment)
If you could provide example xodr inputs that would be great as well.

@chengyuny

This comment has been minimized.

Copy link

commented Aug 17, 2018

Hmm. Your change is almost the same as what I did locally. However, this solution is highly dependent on the fact that the connecting road geometry is precisely connected at the start/end point with the incoming road or outgoing road which is not always guaranteed according to the OpenDrive files I tested.

@namdre

This comment has been minimized.

Copy link
Contributor Author

commented Aug 17, 2018

Yes. The internal lane shape has to be taken into account when defining the edge and junction geometry.
Currently, the process consists of three steps:

  1. junction geometry is computed based on the edge geometries
  2. edges that do not reach the junction shape are extended and those that go beyond it are cut off
  3. internal lane geometries are computed based on these modified edge geometries

I see at least two options to deal with pre-defined internal lane geometries:
a) take internal lane geometries into account when computing junction geometries (basically, use them to define where the junction starts)
b) extend the internal shapes or cut them off to match the computed junction shape

The answer should depend on the quality of junction shapes that can be achieved with option a) In the past I had some networks were that did not look feasible. Option b) seems safer in this regard but it could also lead to the loss of useful information.

I think b) should be implemented first and a) should be implemented as an option at a later time.

namdre added a commit that referenced this issue Nov 30, 2018
namdre added a commit that referenced this issue Nov 30, 2018
namdre added a commit that referenced this issue Nov 30, 2018
namdre added a commit that referenced this issue Nov 30, 2018
namdre added a commit that referenced this issue Nov 30, 2018
@namdre

This comment has been minimized.

Copy link
Contributor Author

commented Dec 3, 2018

b) doesn't solve all problems so a) is needed as well.

namdre added a commit that referenced this issue Dec 12, 2018
namdre added a commit that referenced this issue Dec 12, 2018
namdre added a commit that referenced this issue Dec 12, 2018
@namdre

This comment has been minimized.

Copy link
Contributor Author

commented Dec 12, 2018

a) is already working. remaining issues where due to #4812

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.