Question

shortestpathfinder problem

  • 17 September 2013
  • 10 replies
  • 4 views

Hi Guys,

 

 

I am using shortestpath problem but facing some issues. Not able to get shortest path for every row.

 

 

I have columns with from_x ,from_y, to_x ,to_ y and then i am using 2dpointadder and passing from_x and from_ y to this and again adding one more 2dpointadder and passing to_x and to_y for  from and to point columns.   But i am having more than 3000 rows with these attributes but not able to get shortest path for all the rows. 

 

 

Please help what could be the cause.

 

 

thanks in advance

10 replies

Userlevel 2
Badge +17
Hi,

 

 

The ShortestPathFinder assumes ends of FROM-TO line match with network node (end of network lines) by default. I guess one or both of ends possibly doesn't match with network node.

 

At first check this point. If end of FROM-TO doesn't match but it is close to a network node, "FROM-TO and NETWORK Snapping" option of the ShortestPathFinder could be effective.

 

Takashi
Hi Takashi,

 

 

Thanks for your support. But i have verified all these points and endpoints are fine and snapping point is also taken care of. No idea why it is not giving the path for all the rows. I have mailed the screen shot also. Please help.

 

 

thanks in advance

 

Userlevel 2
Badge +17
Hi,

 

 

I haven't received mail yet. Could you please upload the screenshot to a free server like Dropbox and link to the URL here?

 

 

In addition, if the feature have a geometry before adding the first point with the 2DPointAdder, you cannot create expected FROM-TO line.

 

In such a situation, consider using the 2DPointReplacer instead of the first 2DPointAdder or using the GeometryRemover to remove the original geometry before adding the first point.

 

 

Takashi
Thank you very much for the reply Takashi.

 

yes i am removing the geometry through GeometryRemover transformer. I have checked more cases where shortest path is not created and found that in some cases everything is ok as suggested by you but no idea why path is not created but yes in some cases there is issue with the NETWORK. Network needs to be stitched. But no idea as this gap between the two line features is more than 15m and if i am afraid using snapper with 15 m tolerance will create some damage to other parts of network. It will be very helpful if you can suggest some workaround to stitch these type of lines in the network.
Thank you very much for the reply Takashi.

 

yes i am removing the geometry through GeometryRemover transformer. I have checked more cases where shortest path is not created and found that in some cases everything is ok as suggested by you but no idea why path is not created but yes in some cases there is issue with the NETWORK. Network needs to be stitched. But no idea as this gap between the two line features is more than 15m and if i am afraid using snapper with 15 m tolerance will create some damage to other parts of network. It will be very helpful if you can suggest some workaround to stitch these type of lines in the network.

 

 

link for the screenshots

 

https://www.dropbox.com/s/s33nximma2p9qta/screenshotShortestPath.png

 

https://www.dropbox.com/s/s8ruyj8f606i63b/workbenchScreenshot.png
Userlevel 2
Badge +17
I guess the LineJoiner caused the unexpected result. The LineJoiner connects lines that meet each other at end nodes. That is to say, it could reduce network nodes with no branching. It's not necessary to use the LineJoiner in this case, try removing it.

 

And if some FROM / TO points can touch with a network line except at its end nodes, consider using PointOnLineOverlayer to split network lines at FROM / TO points before finding shortest paths.

 

 

P.S. I saw your screenshots last night (Japanese time), but the links seems to be disabled now.

 

 

Takashi
Userlevel 2
Badge +17
How to stitch the network lines.

 

If there are correct network nodes (point geometries) and each line has attributes which refer to start/end nodes' ID, you can modify ideally the lines into a stitched network.

 

If there are network nodes but the lines have no attributes referring to nodes, the AnchoredSnapper (use the nodes as anchors) could be more effective than the Snapper.

 

Otherwise, the Snapper (End Point Snapping) still seems to be a suitable solution.

 

 

When using AnchoredSnapper or Snapper, as you said, there is the tolerance problem. But I don't think there is a general answer unfortunately, since the appropriate tolerance value depends on the actual data condition. I think you need to do some trial-and-error to find it.

 

 

Takashi
Userlevel 2
Badge +17
How to stitch the network lines 2

 

 

I would try these steps:

 

1) Snap the original lines by small tolerance so that it doesn't give any damage to the network structure (Snapper). Almost stitched network will be constructed.

 

2) Input the snapped lines to the TopologyBuilder (LINE port) to create current network nodes.

 

Specify "Yes" to "Assume Clean Data" parameter of the TopologyBuilder to prevent creating self-intersection nodes.

 

3) Calculate the number of touching lines for each node using the PointOnLineOverlayer.

 

Input the nodes to POINT, the snapped lines to LINE port, then "_overlaps" attribute of the output node will contain the number of touching lines. 4) Divide the nodes into stop-nodes (touching with only one line, _overlaps = 1) and non-stop-nodes (1 < _overlaps).

 

5) Find the closest non-stop-node to each stop-node in a certain tolerance (NeighborFinder), and create line segments between the stop-node and the closest node.

 

6) Find pairs of stop-nodes which are closest to each other in a certain tolerance (NeighborFinder_2), create line segments between paired nodes, and remove duplicate line segment.

 

 

If you can assume the line segments created in 5) and 6) as the missing links in the network, use the snapped lines + the missing links as the network lines when finding shortest paths.

 

Although the tolerance problem remains, these steps might be able to create more preferable network lines than using only a Snapper.

 

Takashi
Userlevel 2
Badge +17
By the way, 15m seems to be too large for a tolerance in general.

 

I think you should also consider the resolution, precision etc. of the source dataset when deciding tolerances.
Hi Takashi,

 

 

Thank you very much for the support. Avoiding Linejoin has solved the purpose. Still now only issues left are with the major gaps like 10-15m which is a data problem for me  as these are very few cases. Without using linejoin i am getting the expected result.

 

 

Thank you very much your support. Will raise another issue if i will find it.

 

 

Thanks

Reply