Hello Jan, Is it the "customShape" attribute? If so, and I specify the lane shape > using "customStape", would that also mean that if I move the intersection a > bit, or the starting/ending node of an outgoing/incoming edge, the position > of the internal lanes would not move? >
Yes, it's "customShape". You can set this in the .con.xml. Also, if you edit connection shapes visually in Netedit, that shape will be recorded as customShape. If you later change the edge geometry, some attempts are done to cut/extend the internal shape so that it links up with its source and target lanes. If the discrepancy is too large you will get a warning such as: Warning: Custom shape has distance 6.11 to outgoing lane for connection -gneE3_0->-gneE2_0 I played a bit more with the original network and while I might have an > example where moving an incoming endpoint of edge at a neighbouring > intersection generates a network file with many internal lanes recomputed > (the original network has an awful lot of short edges for no apparent > reason, and also quite complicated system of pedestrian and bicycle > crossings; it has, though, been generated via netconvert with just minimum > complaints about sharp turns). I cannot reproduce it for a network that has > been manually simplified and, at least from the perspective of the updated > UI for netedit in 1.x, looks visually okay. So my guess is that it is a > some kind of geometry issue, probably triggered by too small edge segments > and too close placement of auxiliary intersections in the file. > > If you can reproduce this with a smallish network, I'd like to take a look at it. > It seems to me that the only reasonable approach now would be to edit the > network manually, hopefully only once, to clean it up, and to do all the > editing of additionals afterwards... > If the network has many useless short edges, make sure to set the netconvert option --geometry.remove If that does not help, right-click on the useless junctions in netedit and check the option "Replace junction by geometry point" If it is greyed out, there will be a reason given in brackets and that reason why for option --geometry.remove did not remove it. Maybe there are some systematic issues that you can fix with some automation. Also, why do you need to modify internal shapes? Are they wrong in a systematic way? best regards, Jakob _______________________________________________ > sumo-dev mailing list > sumo-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/sumo-dev >
_______________________________________________ sumo-dev mailing list sumo-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-dev
