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, > Jakob > ------------------------------ > From: [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 numLanes* > I 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.zip > http://prdownloads.sourceforge.net/sumo/sumo-win32-0.27.0.zip?download > The 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 position* > I 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.0* > I'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
