ThinkGeo.com    |     Documentation    |     Premium Support

Triming routing path

#1

 Hi, I need your help again.


Please compare two screen shots below. Both of them are showing the same part of routing path starting from the exact same point. The top one is using RoutingExplore, and the bottom one is from my code, using the result from RoutingEngine.GetRouteViaVisitStops(), simply rendering RoutingResult.Route into RoutingLayer.


Could you see the path in the bottom one actually begins from behind the starting point?


Both referencing the same shape file rtg file. My application needs to be correctly starting from starting point, and get the distance as well. What can we do to fix this?


BTW same things happens at stopping points too.


Thanks,


Kaori




 


 



#2

Hi, Kaori


I have tried to recreate your problem with RoutingExtension and DesktopEdition, but what I got here is in my case, my sample got the same result with the Routing Explorer. However I noticed that in the HowDoI sample, some of the samples have got the sample problem you’re referring to. In fact, we can write our own method to trim the beginning or the end of the route. Below is the code snippet that shows how to do it, and you can apply it to the SimpleRouting sample of HowDoI sample:
private void FindPath()
        {
            RoutingLayer routingLayer = (RoutingLayer)((LayerOverlay)winformsMap1.Overlays["RoutingOverlay"]).Layers["RoutingLayer"];
 
            routingLayer.Routes.Clear();
 
            MultilineShape route = routingEngine.GetRoute(txtStartId.Text, txtEndId.Text).Route;
            LineShape line = route.Lines[0];
            PointShape trimEndPoint = new PointShape(line.Vertices[0].X,line.Vertices[0].Y);
            LineShape trimmedLine = line.GetLineOnALine(routingLayer.StartPoint, trimEndPoint) as LineShape;
            route.Lines[0] = trimmedLine;
            routingLayer.Routes.Add(route);
            winformsMap1.Refresh(winformsMap1.Overlays["RoutingOverlay"]);
        }
 

Any further questions please feel free to let me know.
Thanks.
James

#3

Hi James,


Thank you for your reply. While I was waiting, I actually tried a similar approach, and it seems working for me now. 


Also, I had taken care of mine, though, I just let you know for your reference and a future update of the library, it would happen to the stopping points too, as in the screen shot below. It doesn't always occur, but sometimes. Seems like the first segment on the feature which goes from main street to the stopping point is correctly trimmed, but the segment to go back to the main street is drawn without trimmed at the stopping point (in the length of the raw feature line segment) .


BTW when loading into RoutingExplore, this shows fine again. 



 


Another FYI, when it gets routing path, sometimes it happens that not all line segments have a common vertex with next line segment. that makes a tiny gap in the routing path, then when I tried to smooth out the path, using code from the sample, it threw an error. (no help needed for this, but just for your info)



Anyway, thanks again for all your help.


Kaori



 



#4

 


Hi, Kaori
Thanks for all the information you provided, that’s really helpful. We will create an issue on our issue system and have someone to get it fixed. As for your information about the gap between lines, I really appreciate that if you’re willing to provide us some more detailed information, like a screenshot of the gap between lines, the start point, stop points, end point of routing when this problem occurs, so that we can recreate this problem and locate where it lies.
Any update we will let you know.
Thank you very much for the precious information you provide.
James

#5

 Hi James,


The gap that I've found is so tiny, and it seems to happen for the first and second lines so far. Well, with same start point and visiting points, it seems that the visiting sequence of the stopping points become to a certain order, or the backwards of the order (it seems random which one comes next). And the gap appears only when it gets in the certain order. For instance, the first time the visiting order is A-D-C-B-E-A, and the second time routing gets as A-E-B-C-D-A, and the gap shows up only when it gets a result as A-D-C-B-E-A, or something like that.


Here's the values, and you can see the first line and second line are not jointed.



Starting Point : 

-118.38777,34.163525


Stopping Points :

-118.387765,34.16172

-118.401048,34.20115

-118.39649,34.15684

-118.39651,34.17348

-118.39737,34.16488


I'm not sure if I can give you more detail than this because the source shape file was not WMK for this one. But I'm assuming the gap shouldn't be there no matter what kind of shape file was used for routing (correct?).


Anyway, hopefully this info would help in some way.


Thanks,



#6

 Another FYI (!),


I've noticed that there are many 'Back' driving direction in the result segments, where it obviously should not be going back. So I tried RoutingEngine.GetDrivingDirection method and the passed two line segments from the result, where it said 'Back'. And with the static method, it gave me the desired driving direction actually. You may be able to observe the differences in the screen shot below..



I just adjusted my result using that static method, so no need for help for this one either. But hopefully I will be able to simplify my code with new version of the library in future!


 


Thanks,


Kaori



#7

 Wait,, about my previous post, it actually was not the desired driving direction when using GetDrivingDirection method! When it says Right, it should be Left... You can tell if you plot out the vertices of the lines. Of course, if I switch the first parameter and the second parameter, it turned to be okay,, but should it be working in that way??



 


 



#8

 


Hi, Kaori
Thanks for the detailed information.
For the first issue, tiny gap between two lines, in your case, according to the screen shot you attached, I found that the second vertex of the first line (Lines[0]) was considered the same as the first vertex of the second line(Line[1]) by MapSuite Routing. Here is the reason, when comparing the position between vertices, if the differences between x value and y value are both within the tolerance (Normally, for shape files, this tolerance is set to 1E-6), they are considered the same. In your case, the vertex (-118.3877458, 34.1640390002025) and vertex (-118.3877464, 34.164039) will be considered the same.
We’re investigating the turn by turn direction issue, normally, if the inner angle of the turn is less than 45 degrees, this direction is considered “Backward”, and I’m not sure if this is the “Backward” in your case.
Any updates we’ll let you know.
Thank you very much.
James

#9

 Ok, if those two points are the same point, then that case, LineShape.GetCross() function should return that point.But obviously it returns 0 point, and that's why the sample ended up with the error.


 
Well, the last screen shot that I uploaded, those two lines are almost 90 degrees (one goes horizontally, the other goes vertically), and should be 'Left'. You can see it if you connect all the points of the two lines in the same screen shot.But RoutingEngine.GetDrivingDirection returns 'Right' instead (see the red arrow in the screen shot), and when it was returned as RouteSegment, it shows 'Back' (see the one screen shot before). So any in cases, it appears to be wrong.
 

#10

 


Hi Kaori,
It’s a good question why two vertices are considered the same while LineShape.GetCrossing method return 0 item for the lines possessing these two vertices. That’s because the result of Routing is totally calculated from the .rtg file, for performance. While builing the rtg file, if these two vertices are considered as the same, RoutingEngine will treat them the same way, that is, if the difference is under the tolerance, the two vertices are considered the same. Somehow, GetCrossing method treats them in another way. The comparison is based on the WKT of both features, even though the result can be with more precision, it will have a serious effect on routing performance, what’s worse, in some cases, if the data is not that precise, this could lead to disastrous result, roads that are actually connected can be miss calculated as without joints, so that no routes can be found.
As for the turn-by-turn directions, we’ve noticed that there might be a potential bug when calculating the direction in some cases. We’ve already had some to look into it and try to fix it. If there’s any updates on Routing, we’ll let you know as soon as possible.
Thanks again.
James

#11

That makes sense. So then I would suggest that the smoothing path sample on the website may want to take care of that part too, otherwise it doesn’t always work as the sample claims and is tricky to find why you would get an error. To me I had no idea until you explained about it.

#12

 


Hi Kaori,
Thanks for your suggestion. We’ll try to improve our samples related the specific issue, just as you advised, the SmoothTranparentRoute sample should be taking care of that part, and we’ll fix it in future public release.
BTW, turn-by-turn directions issue has been located in the source code and created on our internal issue system, and it’s hopefully that we can have it fixed before the next public release.
We’ll let you know as soon as the issue is fixed.
Thanks a lot.
James

#13

james i have used ur code to trim my route but it didn't work


i have got the same result




#14

Hello Faryal, 
  
 This is a confirmed bug, and we are working on this, we will post the result to let you know. 
  
 Regards, 
  
 Gary

#15

Hi Gary, hi James, 



this topic has been started some time ago. Are there any news on this? I tried building my routes and still have to trim the routes. 

Concerning trimming, I tried my own simple approach. I step from each vertex to the next and check whether the start point lies on the connection line between this vertex and the next one. I acutally tried this with lineshape.Contains(), but it always returned false. Lineshape.GetBoundingBox().Contains() works, but in some cases when roads are highly intertwined, it will give a inexact result. Furthermore, I do not understand why lineshape.Contains() always returns false. Maybe I am doing something wrong here.  

But my actual question is - how can I update my Routing characteristics (driving time, distance, route segments including driving directions) after trimming the route? 



Thanks in advance!



Edit: Asked the geometry question in desktop support forum- Updating the routing characteristics is still wanted :)

#16

Sorry, I was doing something stupid. I calculated the start and end point for the route layer based on where the user clicked, but calculated the route using street IDs - of course that makes trimming necessary, as streets  are, of course, not restricted to one point but to whole line shapes. After changing the route calculation to use the start and end point (not start and end street), trimming is superfluous and the distance is ok, too - but out of interest, in case I’d change the route manually, how could I adjust the distance? Is this updated automatically?

#17

Hi Hanna, 
  
 Sorry maybe I misunderstand what’s the meaning of “in case I’d change the route manually”, but if you change any condition of routing, the distance should be updated automatically. 
  
 Regards, 
  
 Don