Pretty simple idea. Allow the JS SDK be able to take advantage of network topology.
It was to my utter surprise that I learned that Trace Networks have been a exposed capability at the server level for a while, and that it isn't just a "Pro" thing. See below screen shot (apologies for the quality - I took this picture at this year's 2026 ESRI UC at the geodatabase kiosk). Notice that Utility and Trace Networks are distinct server side capabilities. They are not the same. It seems incomplete to have this server side capability with no JS SDK ability to use it.
I started to put things together with the help of Jose at the JS SDK booth that even though the Trace Network capability is exposed, there is no current ability for the JS SDK to use network topology - hence no JS components, hence no widgets in any ESRI web product that can trace Trace Networks on the web (only in Pro). Jose seemed to indicate that there might be a JS project already in place to look into enabling topology in the SDK. I want this idea to lend credence to it if such a project is on the books.
Additionally, it would be good for ESRI to do this as there is a lot of headwinds coming for utility networks due to the upcoming NSRS 2022. Also, there is a lot of hydro networks that do not lend themselves to utility network implementations. It would be good for organizations to have other alternatives (albeit more simplistic) to trace networks on the web than the UN which is the only option currently.
Since you mention both the utility network and the trace network, it's not clear which industry domain you are referring to here.
Esri does NOT recommend using the Trace Network for water, wastewater, gas, telecom, or electric networks. These industry domains are the reason we built the utility network in the first place.
One reason we do not recommend the Trace Network is that we lack mobile and web support.
We have been steadily adding web and mobile support for utility networks for several years now. We're not done yet, and still have at least a few more years of work to go. As you've noted, it's two different services with two different REST APIs. That would mean two different JavaScript APIs, two sets of Web Components, two sets of extensions for Map Viewer, Web Editor, and Experience Builder, etc. And the same on the mobile side. Adding full support for Trace Networks would roughly double the amount of work required.
Like every other company, we have limited development resources and dividing them to support two different network types would inevitably delay full utility network support. At this point, we have no plans to do this.
If the hydrology market is interested in web support, we will of course consider it in the future, but only the functionality needed to support hydrology-specific workflows.
--Rich
All of our needs are almost always single starting point. I can't think of a time we needed more than one. Sometimes simple barriers are useful, like selecting certain nodes and edges as barriers.
Correct. No editing or validating topology.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.