Hello Jakob, I have attached the net.xml file.As you can see the junction 1's shape is calculated away from node 1's pos (0,-20) And if you change node 2's pos from (-6.00,-50.00) to (-5.95,-50.00), then (-5.95,-50.00) will be within the calculated junction shape.This difference is caused by the "fabs(ccad - cad) < DEG2RAD(22.5)" be true/false.
Thanks,Yifeng From: [email protected] Date: Thu, 8 Sep 2016 10:10:03 +0200 Subject: Re: lane alignment issue in NETEDIT 0.27.1 To: [email protected] CC: [email protected] Hello, the threshold is meant to discriminate between cases where geometries are somewhat parallel and thus intersections may be hard to compute and simpler cases (see the comments in the code). It certainly won't hurt to experiment with different threshold values. In regard to your mail from Sept 1st, I would like to take a look at the issue if you could send the network directly to my address regards, Jakob 2016-09-06 22:26 GMT+02:00 Yifeng Zeng <[email protected]>: Hello Jakob, >From my previous emails I mentioned the issue that the junction shape may be >calculated at where far away from the node originally given (x,y) position.I >have located the source code.in >NBNodeShapeComputer::computeNodeShapeDefault(bool simpleContinuation) {} the (!simpleContinuation && fabs(ccad - cad) < DEG2RAD(22.5))) will decide how the shape be calculated differently. My question is that is there a reason why the threshold is set to '22.5' degree? What is the disadvantage/side-effect if I increase this threshold? Say from '22.5' to '60'? Thanks,Yifeng From: [email protected] To: [email protected] CC: [email protected] Subject: lane alignment issue in NETEDIT 0.27.1 Date: Thu, 1 Sep 2016 16:25:24 -0400 Hello Jakob, I mentioned this issue a while ago for version 0.25.0. And I tried the same network in 0.27.1, it seems that the issue still exists. Would you please take a look at this? Basically the network has 3 nodes and 2 links. The computed junction for node 1 has shape="-6.55,-34.68 3.25,-34.68 -0.47,-38.92 -6.84,-37.65">, which is very far from its specified x-y coordination x="0.00" y="-20.00" 0 0 || || 1 || // 1// //2 2 I used the default spread type 'right' for all edges.The lane 1 of gneE0_1 should have align with the lane 0 of gneE1_0. Instead, the lane 0 of gneE0_1 is now aligning with lane 0 of gneE1_0.Could you please tell me where in the source code is assigning this alignment? Thanks,Yifeng From: [email protected] To: [email protected] CC: [email protected] Subject: RE: SUMO netedit issues Date: Mon, 25 Jul 2016 12:32:40 -0400 Hello Jakob, Thank you very much for your explanations. And again, my apologies for the redundant emails. As for Question 2), I did not define separated functions for the incoming and outgoing legs, neither replace junction '7' with geometry points for both edges.I simply moved node '8' away from '7' so that the distance between '7' and '8' are "36.5" now. '7' position remain (100.00,-100.00), '8' position moved from (100.00,-130.00) to (100.00,-136.50), in this case, the junction shape on node '7' seems okay.However, if '8' position is (100.00,-136.00), the junction '7' shape is off. I'm not sure why this 0.5 meter difference makes so big of the offset of junction '7'. I would consider this to be some kind of defect.I zipped and attached the network for this question just for your convenience. (Q2_node7.net.xml) As for Question 3), I also attached the network (Q3_alignment.net.xml). Junction '2' and '16' are the ones I think might have issue. The center line between 'gneE6' and 'gneE7' should align with the center line between 'gneE5' and 'gneE4'. It seems that it was incorrectly aligned with the center line between lane 0 and lane 1 of 'gneE4'. We can see the similar issue at junction '16'.To study this situation a little bit more, I added the traffic lights for all the junctions to see how the lanes are connected by default. It seems that the lane 0 of the incoming edge are aligning with lane 0 of the outgoing edge. My understanding is that when there is a lane drop (junction '2') or a lane gain (junction '16'), the lane has the highest index of the incoming edge should align with the lane has the highest index of the outgoing edge. Not lane 0 of incoming edge align with the lane 0 of outgoing edge.Then created junction '4' and '19' to compare, and they seems okay to me at first, but after adding the traffic light, it looks like they all aligned lane 0 to lane 0, which seems a bit odd to me. I did not change the 'spreadType', so they all default as 'right'. I should mention that I specified '0' to 'default.junctions.radius' instead of default '1.50', but I don't think this affect anything. I don't know if these two issues are critical enough for you guys to open up a ticket, or if they are already fixed in 0.27.0? Thanks, Yifeng From: [email protected] Date: Mon, 25 Jul 2016 09:27:43 +0200 Subject: Re: [sumo-devel] Shape for junction has long distance to its given position To: [email protected] CC: [email protected] Hello, the general reason for the problem is this: The heuristical algorithm that computes junction shapes got confused by the (slightly) unusual input. This may happen from time to time and can be fixed by setting the node shape expliclity (via netedit or xml input). In your specific example it would be sufficent to define seperate junctions for the incoming and outgoing legs at junction '7'. Even better, to replace junction '7' with geometry points for the incoming and outgoing edge. regards, JakobFrom: [email protected] Date: Mon, 25 Jul 2016 09:31:26 +0200 Subject: Re: SUMO netedit issues To: [email protected] Hello, questions 1) and 2) are answered in previous mails. Regarding question 3), this is most likely caused by mixing different 'spreadType' values (see http://sumo.dlr.de/wiki/Networks/Building_Networks_from_own_XML-descriptions#Edge_Descriptions) or by specifying custom edge geometry endpoints. If you send me the input files for the 'failed' case I can take a look. Also, for sending larger files, either - zip them up - or send the download link to a file-sharing website. - or send them to me directly regards, Jakob 2016-07-22 6:07 GMT+02:00 Yifeng Zeng <[email protected]>: Hello Jakob, I'm sorry to write to you directly, my previous three emails were all larger than 40 KB so they got rejected by the mailing list.Would you please let me know if there is anyway to avoid getting rejected? I've got three issues here. 1) netedit.exe (0.27.0) crashes after changing numLanesI was trying netedit.exe 0.27.0 from http://sumo.dlr.de/wiki/Downloads where it says "Release date: 12.07.2016" Download as zip: sumo-win32-0.27.0.ziphttp://prdownloads.sourceforge.net/sumo/sumo-win32-0.27.0.zip?downloadThe netedit.exe is in sumo-win32-0.27.0\sumo-0.27.0\bin I create a new edge, then choose inspect, change the numLanes from "1" to "2" and hit "Enter".The program instantly crashed. 2) Junction has long distance to its given positionI have this test net.net.xml network attached.I opened the net.net.xml network with netedit.exe (0.25.0) and pressed "F5" to compute the junction.For junction '7' I got the following warning: "Warning: Shape for junction '7' has distance 34.91 to its given position" The pictures before and after the computation are attached. The computed junction shape locates very far from the giving position (100,-100) and it looks like that edge does not end at where node 7 is.Is there a particular reason why this happens? 3) Lane alignment issue in netedit 0.25.0I've attached 4 pictures. As you can see, from north to south, first edge1 has 1 lane, second edge2 has 2 lanes.The example goes from north to southwest connects the lane0 of edge1 to lane0 of edge2 after junction computation.The example goes from north to southeast connects the lane0 of edge1 to lane1 of edge2 after junction computation.The first southwest example lane alignment looks too odd to me.Would you please explain this issue a little bit? Why does this difference happens? I've been asking a lot questions. So thank you very much for you patience and your consistent help. Cheers,Yifeng 2)
------------------------------------------------------------------------------
_______________________________________________ sumo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sumo-devel
