strange turns in Network Dataset

[RiccardoKlinger]

I am creating a network dataset and I see some strange maneuvers on the data:

SO coming from the NorthWest, I am passing the stop and make a turnaround.

Coming from the southeast I am making this detour.

Yet if the stop is not placed on a junction the route just looks fine!

I have tried several settings in the curb approaches and yet I was not a able to get the shortest/fastest route.

Does anyone have an idea where to look at? I tried all travel modes and all measurements, recreated junctions and so on. Still I have no clue where this might come from!

 

[MelindaMorang]

Hmm, I wonder if this is a sign that your network is not connected properly somehow?  If the stop is located on a junction that is only connected to one edge and not the other, then the route might have to pass the stop and loop back.  It seems kind of unlikely that it would be able to travel down the road at all (that the roads would be somehow connected even if the junctions aren't), but it's a possibility.  Try using the Explore Network tool to click on the roads and junctions in that area to see what they're connected to.

Also, in general, locating stops on junctions can lead to some problematic behavior.  For instance, if all the streets surrounding the junction are restricted, but the junction isn't, the point will happily locate on the junction and then be unreachable.  Also, CurbApproach is ignored for a junction because, as a point, it has no concept of directionality or sides.  Unless you have a specific reason you need to locate on junctions, you would be better off adjusting the locate settings to turn off locating on junction sources.

[RiccardoKlinger]

Everything seems well connected:

 

 

[RiccardoKlinger]

Hi Melinda,

I've checked the data again and created a network from scratch which works just fine and routing is as expected. Yet I need to consider single direction restrictions and it seems like it is using a restriction from the single direction road as the limitation if the desired trip stops at a junction:

once I move the target (2) away from the node it behaves correctly:

my code block for the restrictions:

def OnewayFromTo(dt):
    if dt == "T":
        return True
    if dt == "N":
        return True
    if dt == "B":
        return False
    return False

can I design the behaviour at junctions as well?

[MelindaMorang]

I'm having trouble following exactly what you're describing here. The evaluator logic looks okay to me.  I suspect the behavior might have something to do with locating on endpoints as I described in my other comment.

If my most recent comments don't give you enough clues, you might have better luck contacting Esri Support so they can look at your network dataset in detail and help you debug it.

[RiccardoKlinger]

and location on junctions is turned of, if I look and interpret this dialogue correctly:

[MelindaMorang · Accepted solution]

Okay, if you didn't change any of the locate settings on the layer or in the Add Locations tool, then by default it won't locate on the junctions.  This would explain your earlier behavior.  When you said it was locating on junctions, what it was actually doing was locating on the endpoint of one of the streets at that intersection.  If you had oneway restrictions or some kind of configuration that allowed travel only in one direction, then it probably had to go around so it could get to the correct endpoint.  Note that there is some kind of tie-breaking logic to determine which of the endpoints it locates on, but I don't know if it's deterministic.  Possibly if you re-created the feature, it might locate on a different endpoint, so the behavior might be different from one test to the next.

[RiccardoKlinger]

Seems strange but you're right:

I copied the single direction road in my street dataset and removed the old one. The new one recieved an higher objectid and I recreated the NDS. Now it behaves correctly. Can i somehow interfer with this in ArcGIS Pro by adding some sort of rule like:

If stop on Node:

use edge settings from higher ranking functional class!

?

[RiccardoKlinger · Accepted solution]

quick "recap"
During stop creation it creates some fields including sourceID, sourceOID, PosAlong and SideOfEdge. These fields are not filled initally but will be resolved during the route finding process. 
The route finding process seems to only check for edges on this position and will take the settings of the first edge it finds. In my personal case the objectID of the edge with single direction traffic was the lowest of the three edges so it was chosen. You can check this solution, when you open the Stops attribute table and scroll to the above mentioned fields. SourceOID is the objectID of the edge it found and used.

To solve this in ArcGIS Pro you can alter the Stop table and fill in the four fields with the desired values and than start solving the route problem.
On arcGIS Server with a Route Solver NAS you can alter the stops feature set:
instead of sending 

{"features":[{"geometry":{"spatialReference":{"latestWkid":32632,"wkid":32632},"x":4712.0,"y":816.0},"attributes":{}},{"geometry":{"spatialReference":{"latestWkid":32632,"wkid":32632},"x": 4711.0,"y":815.0},"attributes":{}}]}

you should send defining attributes:

{"features":[{"aggregateGeometries":null,"geometry":{"spatialReference":
{"latestWkid":32632,"wkid":32632}
,"x":4712.0,"y":816.0},"attributes":{"SourceID": 2, "SourceOID": 26142977, "PosAlong": 0, "SideOfEdge":1}},{"aggregateGeometries":null,"geometry":{"spatialReference":
{"latestWkid":32632,"wkid":32632}
,"x":4711.0,"y":815.0},"attributes":{"SourceID": 2, "SourceOID": 26156789, "PosAlong": 0, "SideOfEdge":1}}]}

The determination of the SourceOID is the up to you. It will not be overwritten by ArcGIS Server. 
Tested with ArcgIS Server 10.9.1 

in ArcGIS ENterprise 11, you can also check with the new locateSettings Parameter described here:

Direct request—ArcGIS REST APIs | ArcGIS Developers