nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

strange turns in Network Dataset

RiccardoKlinger

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

Screenshot 2024-02-07 164029.png

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

Screenshot 2024-02-07 175112.png

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!

Finde mehr Beiträge mit dem Tag

Accepted answers

RiccardoKlinger

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

Melinda Morang

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.

All comments

RiccardoKlinger

{"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

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!

Melinda Morang

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.

Melinda Morang

RiccardoKlinger

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

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:

Screenshot 2024-02-07 224317.png

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

Screenshot 2024-02-07 224355.png

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?

RiccardoKlinger

Everything seems well connected:

Screenshot 2024-02-07 185118.png

Screenshot 2024-02-07 185136.png

Melinda Morang

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.

Nimm an der Unterhaltung teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.