Skip to main content
  • EN

Hi!

I am trying to restrict the ShortestPathFinder from taking turns with a certain arc radius.

The reason is that the network is a rail network and so sometimes the transformer chooses routes that are impossible.

Would really appreciate any thoughts.

Unfortunately, as of FME 2017 I don't think the ShortestPathFinder supports turn restrictions based on node attributes.

 

Hopefully someone here can suggest a workaround.

Yes that's what I am looking for.

Just to illustrate further I took the screenshot below. The pathfinder should stay on the right track, but switches to the left nonetheless. A turn that is physically not possible.

In this particular case the issue is that there shouldn't be a node a that point at all, I suspect.

The lines should only break at connected intersections (allowable turns).

If your network segments are mostly one-way only, a solution could be to calculate two different segment costs based on direction:

The Orientor (or even the NetworkFlowOrientor) can help you flip segment orientations, if necessary.

In this particular case the issue is that there shouldn't be a node a that point at all, I suspect.

The lines should only break at connected intersections (allowable turns).

I'm afraid that this is just how my network is set up. I used a chopper
and topologybuilder to make sure the pathfinder could do its wo

 

If your network segments are mostly one-way only, a solution could be to calculate two different segment costs based on direction:

The Orientor (or even the NetworkFlowOrientor) can help you flip segment orientations, if necessary.

I have thought about this, but I have two-way tracks, which made me discard this solution.

 

 

I have thought about this, but I have two-way tracks, which made me discard this solution.

 

 

The issue is that the ShortesPathFinder assumes that your network is properly noded, i.e. that there are no nodes where there is no connection. As an example, there should be no node where a bridge crosses a highway, even though the lines cross "on screen".

 

 

If you create nodes on each intersection in 2D space without any consideration for real-world connectivity, then the results will not be very good (as you've seen).

 

 

You will probably have to re-consider how you're generating the network sent to the ShortestPathFinder.

Have you tried the PolylineAnalyzer?

https://hub.safe.com/transformers/polylineanalyzer

It might be useful when you preprocess your network (e.g. eliminate some unwanted connections) before running the ShortestpathFinder.

If your network segments are mostly one-way only, a solution could be to calculate two different segment costs based on direction:

The Orientor (or even the NetworkFlowOrientor) can help you flip segment orientations, if necessary.

Hi @johannesbloemen, I think @david_r's solution could be still effective if you can classify the network lines into one-way tracks and two-way tracks.

 

  1. Create a copy for every two-way track.
  2. Flip the orientation of the copied tracks and add them to the Network. That is, put two network lines (up and down lines) per two-way track.
  3. Set the Cost Type in the ShortestPathFinder to "By Two Attributes" (set a very large value to the Reverse Cost so that the reverse track should not be selected) or "By Length (Forward Only).

Thanks for the help so far.

I understand from @david_r there should not be a node in the centre of my crossings, and I do agree that noding the network correctly would be the desirable
way to go.

 

 

The crossings are made out of 4 lines connected in the middle. These lines do
share a common 'crossing' attribute. Is it possible to join them or make
it so that there is no node in the center?

 

Cheers

When you want to remove the common crossings, you will have to find a way to join the lines based on a common 'line' attribute. When the lines are joined, it is possible to remove the vertex at the crossing. I think the easiest way to do that is using a python script. I guess @takashi can provide you an example of such a script.

When you want to remove the common crossings, you will have to find a way to join the lines based on a common 'line' attribute. When the lines are joined, it is possible to remove the vertex at the crossing. I think the easiest way to do that is using a python script. I guess @takashi can provide you an example of such a script.

Thanks for the input.

 

 

What I did so far is use the angularitycalculator+attributerounder to find the lines in the crossing that are have a similar angle and are "opposite" of each other. I used a linejoiner on the ones that have similair line angle. This has worked for about half of the crossings, since some of the angles are not similair.

 

 

Reply


Community Stats

30,141
Posts
114,392
Replies
37,775
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.