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.rich...@ait.ac.at>: > 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.rich...@ait.ac.at>: > >> 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 >> firstname.lastname@example.org >> 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 listsumo-...@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visithttps://dev.eclipse.org/mailman/listinfo/sumo-dev > > > > _______________________________________________ > sumo-dev mailing list > email@example.com > 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 firstname.lastname@example.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/sumo-dev