Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [sumo-dev] netconvert of xodr files - unexplained offset
Hello,
the wording in the ticket may have been ambiguous (I just updated it). It is not just rendering. The generated lane geometries include the mentioned offset of 0.1m and this shows in the gui and all other tools that generate geometries from .net.xml.
The simulation logic ignores lateral gemetries and simply uses length and width values.

2018-04-09 9:44 GMT+02:00 Richter Gerald <Gerald.Richter@xxxxxxxxx>:

Hi Jakob,

thanks for the reply.
I am not sure, that the mentioned issue covers the problem.
What I am referring to is not a rendering issue (which is how I understood the description of https://github.com/DLR-TS/sumo/issues/3972)

When
1. converting the xodr with netconvert to sumo.net.xml
2. extracting raw geometry info from the xodr (-> wkt)
3. extracting raw geometry info from the net.xml (-> wkt)
4. visualizing those raw geometries in QGis
There apparently are noteworthy discrepancies.

or did I get something wrong?

thanks,
Gerald.


On 2018-04-08 22:12, Jakob Erdmann wrote:
Hello Gerald,
thank you for bringing this up.
the reason is explained here: https://github.com/DLR-TS/sumo/issues/3972
regards,
Jakob


2018-04-06 19:42 GMT+02:00 Richter Gerald <Gerald.Richter@xxxxxxxxx>:

Dear list,

recently I have been experimenting with xodr sources and their conversion to sumo net files.
Apart from encountering minor issues regarding the xodr compliance to standard v1.2 in netconvert,

I got suspicious of the fidelity of the geometry conversion while inserting signals as POIs.

The problem can be seen in the attached image.
It shows the rendering of lane-slabs (yellow) extracted from the odr file to wkt-files, which rather nicely matches the sat-map.
The xodr lanes are separated and bounded by the roadmarks in white and fit right next to each other.

When doing the same for the conversion result lane-data by using sumolib.net.readNet,
some differences show up. Cyan thin lines show the presumed center-lines of the lanes,
and the hatched slabs are the lane-polygons resulting from adding the width/2 left and right of the center line.
They do not fit tightly as there is some space in between.

I checked this for some scenarios and a deviation shows consistently.
The good match between the xodr lanes and the satelite-images lets me assume that I did something right on that end.

Does anybody know of this issue? How to circumvent it?
I can provide such a comparison on some test-data, given the xodr-features are not too fancy...
and am willing to help.

best,
Gerald.

--

 


_______________________________________________
sumo-dev mailing list
sumo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-dev




_______________________________________________
sumo-dev mailing list
sumo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-dev


_______________________________________________
sumo-dev mailing list
sumo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/sumo-dev


Back to the top