pyoscx / scenariogeneration

Python library to generate linked OpenDRIVE and OpenSCENARIO files
Mozilla Public License 2.0
273 stars 86 forks source link

How to directly add a straigth line road with all parameters (s,x,y,hdg,length)? #9

Closed johschmitz closed 3 years ago

johschmitz commented 3 years ago

In my use-case I have already calculated all the parameters of the straight line road I want to add s, x, y, hdg, length (see https://releases.asam.net/OpenDRIVE/1.6.0/ASAM_OpenDRIVE_BS_V1-6-0.html#_straight_line) However, there seems to be no way to add such a road when looking at the documentation: https://pyoscx.github.io/xodr/geometry.html#scenariogeneration.xodr.geometry.Line The only thing I can specify is the length. What is the correct way to do this? It seems that the first road always start at (0,0) and then the library is supposed to calculate everything else? I think that is useful for some use-cases but unfortunate for others. Can you give an example for changing the starting point? How about adding an additional "raw" API where the user has to specify all parameters when creating a new piece of road?

Like geometry = xodr.Line(s, x, y, hdg, length) and then I simply do not call adjust_roads_and_lanes()

I am wondering if that makes sense or not. On the other hand it could be very useful that the library checks if my calculations are correct. So I am quite not sure if a "raw" API is needed or not. @mander76 Would you be interested in a Audio/Video call to discuss some of the details around this topic? I could then also show a little demo of what I want to do with the library.

johschmitz commented 3 years ago

I found this example that explains how to work on the plan view level: https://github.com/pyoscx/scenariogeneration/blob/main/examples/xodr/multiple_geometries_one_road.py Nevertheless, I would be interested in a casual discussion.

johschmitz commented 3 years ago

I created a pull request to improve the documentation on this topic: https://github.com/pyoscx/scenariogeneration/pull/10 It might be usefull to add a call to set_start_point() to the planView example though.

mander76 commented 3 years ago

I don't think it is needed. you can add the initial position/heading of the road in the planview you create. The rest are calculated

MandolinMicke commented 3 years ago

I have added a new feature to the planview where all geometries are added manually (80ab218347b05da5a80d79a873a85981eb106db7), not on pip yet since I want to test some things first. This new method is called add_fixed_geometry, and within the same planview cannot be mixed with add_geometry. It will be too difficult to sort out.. However to get a nice xodr the geometries should be added in order still otherwise they will be disordered in the final xml file.

Please have a look

johschmitz commented 3 years ago

@MandolinMicke That is cool, I am going to have a look but it might take some time. I am wondering how important is the ordering? Need to think more about it. I am trying to build (currently more like a prototype) of a graphical editor as a Blender Add-on and I am not sure if pieces of roads that the user clicks together should be treated as individual OpenDRIVE roads or just geometries of a single road. I guess it depends. Maybe it would be helpful if the library could have some convenience features to convert between those ways of modeling. Like a simplify_road_network() or merge_roads() method. If this would be an automatic step before export then it could yield optimum simulation performance. Maybe after managing to release a version 0.1.0 we could have another discussion about this. Right now I believe I should first try to make use of the existing feature set.

mander76 commented 3 years ago

the ordering is "only" important if s is not calculated by the user (if not then some sorting has to be added when writing out the geometries).

If you just do single road there won't be an issue

johschmitz commented 3 years ago

Does that mean if s is calculated by the user the geometries are ordered automatically? I am getting a bit confused with your double negation here 😅

mander76 commented 3 years ago

ok sorry :) I'll try to explain better

If the user adds them in order (without s as input) s can be calculated from one geometry to the other by the framework itself and no problems writing the xml in an orderly faction (so that ).

so planview.add_fixed_geometry(Line(100),0,0,0) -> s=0 for this geometry planview.add_fixed_geometry(Line(50),100,0,0) -> s=100 for this geometry planview.add_fixed_geometry(Line(100),150,0,0) -> s=150 for this geometry this will result in an xml where the geometries are written in the s ascending order. -> geom1( s=0 ), geom2( s=100 ), geom3( s=150 ) As it is now, if a user adds with s as input, the written order in the xml will be the order that the user put them in to the planview. planview.add_fixed_geometry(Line(50),100,0,0,s=100) planview.add_fixed_geometry(Line(100),0,0,0,s=0) planview.add_fixed_geometry(Line(100),150,0,0,s=150) -> geom1(s=100), geom2(s=0), geom3(s=150)

This can be fixed by sorting on s (but that is not implemented yet)