Update the “Cost” field of the Walkways layer directly through the REST endpoint and immediately reflect those changes in routing results.

Question

Hello Everyone! I have published a routing service, and I'm looking for some help with a scenario where I'd like users to update the Cost attribute through the REST endpoint for the walkways. Any assistance would be greatly appreciated!

Data/ Software

-ArcGIS Pro 3.5
-The network data resides and is published from the FGDB

I understand that this can be handled by using an Enterprise Geodatabase to reflect the changes. However, my goal is to give end users the ability to update these values themselves through an application or UI where the REST service is exposed to them.

deelesh · Answer

Hi @AmrikJasrotia08

> The data wouldn’t be permanently updated for that specific section of the walkway to be prioritized later on, right?

Yes the cost stored in your walkways source is not altered. In fact, the approach I suggested does not rely on actual walktime stored in the sources. It is completely based on length of walkway features and a walk speed which can be specified per request.

However if you already have a walk time cost and would want to "change it" per request such as either slow down or speed up walk time, you can do the same using another attribute parameter may be called "ScaleFactor" that essentially allows you to adjust the walk time. For example, if you have another cost attribute called "AdjustedWalkTime", the evaluator for this new cost atrribute can be ""WalkTime" * ScaleFactor"

> Other than using an Enterprise Geodatabase (EGDB), publishing a feature service from the same Walkways layer, editing the attribute value for a specific walkway section through the web app/webmap, and then rebuilding the network — are there any alternative workflows worth exploring?

Editing network dataset sources via feature services (called as Branch versioning in Esri doc) is currently not supported. Network datasets in enterprise geodatabase currently only support traditional versioning.

> Also, are there any performance considerations or limitations when using an EGDB compared to a File Geodatabase (FGDB)?

In general, routing services that work against network dataset in enterprise geodatabase have slower performance as compared to routing services that work against network dataset in FGDB

It is still unclear to me why you think you need an enterprise geodatabase since your requirement is to adjust the cost (walktime) which can be achieved with an attribute parameter.

AmrikJasrotia08 · Answer

Hi @deelesh,

Thank you so much for taking the time to share this valuable information. I have a quick follow-up question: these changes would apply only for the current session, correct?

The data wouldn’t be permanently updated for that specific section of the walkway to be prioritized later on, right?

I am using the cost from the attribute table of the walkways layer, Similar to your suggestion.

Other than using an Enterprise Geodatabase (EGDB), publishing a feature service from the same Walkways layer, editing the attribute value for a specific walkway section through the web app/webmap, and then rebuilding the network — are there any alternative workflows worth exploring?

Also, are there any performance considerations or limitations when using an EGDB compared to a File Geodatabase (FGDB)?

For context, our current FGDB is around 18 GB in size and contains several million walkway features, and is expected to grow continuously.

Thanks!
Amrik

deelesh · Answer

@AmrikJasrotia08

After you publish a routing service based on a FGDB network dataset, the routing service locks the FGDB. So editing costs in a network dataset stored in a FGDB is not supported via REST endpoints.

However if your workflow is to allow users to change the costs used when finding routes, this can be achieved by adding an attribute parameter value to your cost attribute that allows changing the costs using a simple function.

For example, Lets say you want the users to adjust the walk time and you have a cost attribute called WalkTime defined in your network dataset. You can have an attribute parameter associated with WalkTime called "Walking Speed (km/h)". The default value for this attribute parameter can be most common for your context like 5 km/hr. The value for WalkTime cost attribute needs to derived from the walking speed and the time walking at a constant speed of 1Km/Hr.

In terms of how this all looks in the network dataset, You need to first define a new cost attribute called "TimeAt1KPH" whose evaluator is based on the length of your line features and a constant. For example, in my screenshot I have the evaluator for TimeAt1KPH set to METERS * 0.06 since my network dataset has a length field called METERS that stores the length in meters.

Once you have defined a TimeAt1KPH cost, you can define a function evaluator for the WalkTime based on the Walking Speed attribute parameter and TimeAt1KPH cost attribute as show in this screenshot

After you rebuild the network dataset and publish the routing service, when calling the REST endpoint of the routing service, you can use WalkTime as your impedance and pass a different value for Walking Speed attribute parameter to change the walk time used by the service. A sample REST request that passes walking speed as 10 km/hr would look like

&stops=-117.3,34.3;-117.31,34.31
&impedanceAttributeName=WalkTime
&restrictionAttributeNames=Walking
&attributeParameterValues=
[
    {
     "attributeName": "WalkTime",
     "parameterName": "Walking Speed (km/h)",
     "value": 10
    },
    {
     "attributeName": "Walking",
     "parameterName": "Restriction Usage",
     "value": "PROHIBITED"
    }
]

Hope this helps

Deelesh