OTDR trace in Communications UN

351
2
09-14-2023 01:11 PM
rpepato_bizpoke
New Contributor II

I'm working to implement an OTDR trace in the communications domain in the same sense as described in this idea.

I was able to implement the trace and trim it to a given distance from the initial point by using an instance of the Communication Line (a Cable, in my example) as you can see in the screenshots below:

1 - Connected trace starting from Cable and without traversability function barriers:

rpepato_bizpoke_0-1694719914813.png



2 - Connected trace starting from Cable and traversability function barriers set to Add the Measured Length attribute value up the threshold 4000:

rpepato_bizpoke_1-1694719981471.png


3 - Connected trace starting from Cable and traversability function barriers set to Add the Measured Length attribute value up the threshold 8000:

rpepato_bizpoke_2-1694720004028.png

 

Although the scenarios above work, the real use case demands that the trace initial location be an instance of a connector (or a fiber) which is a non-spatial object. Executing the same scenario as above but using a non-spatial object as the trace initial location doesn't produce correct results as described below.

Since Naperville data in Communications 1.4 has the Measured Length attribute set to null for all of the Strand/Fiber records, I manually set all of them to a static value (I updated all of them to 5 just for testing purposes), followed by a validation of dirty area and update of all subnetworks. Up to this point, everything was correct and working well.

On the next trace, I set the connector as the starting point and no traversability function barriers. It seems to work as expected:

rpepato_bizpoke_3-1694721493114.png

 

rpepato_bizpoke_4-1694721512222.png

rpepato_bizpoke_5-1694721532303.png

 

rpepato_bizpoke_6-1694721552452.png

 

rpepato_bizpoke_7-1694721571901.png

 

rpepato_bizpoke_8-1694721615086.png


Now, I add a Traversability Function Barrier to Add the Measured Length attribute from the connected strands and stop the trace when the accumulated value is greater than 40:

rpepato_bizpoke_9-1694721861568.png


This configuration doesn't work as you can see in the trace results below (it still returns the whole connected trace, not stopping the trace when the condition is met). It looks like my traversability function barrier is ignored when dealing with non-spatial objects. 

rpepato_bizpoke_10-1694722004189.png

 

Does anyone know or have ideas about how to make it work as described in the idea referenced at the beginning of this post?

Thanks,

Roberto






 

0 Kudos
2 Replies
RobertKrisher
Esri Regular Contributor

What version of ArcGIS Pro (and/or ArcGIS Enterprise) is this? The traversability barrier should be working correctly with non-spatial objects in the current release of the software, as long as the attribute you're using for network analysis is correct (e.g. the measured length of the strand is accurate). Where there is currently a known issue is that the aggregated geometry currently returns the entire parent geometry instead of the partial edge when the otdr trace is performed on a non-spatial object.

0 Kudos
rpepato_bizpoke
New Contributor II

ArcGIS Pro 3.1.2, running Communications Utility NetworkFoundation 1.4 (I'm running it locally against the included geodatabase).

 

0 Kudos