Select to view content in your preferred language

Line Of Sight Widget produced lines partially

240
5
Jump to solution
07-17-2025 08:57 PM
JuanMarvinW
Emerging Contributor

Hello All, I need help on solving problem regarding Line Of Sight Widget's lines. I was using ArcGIS Javascript 4.33. And I was using the Line Of Sight widget on my code, like:

const lineOfSight = new LineOfSight({
            view: view,
            container: "losWidget",
          });
 
which originally I followed from this sample: https://developers.arcgis.com/javascript/latest/sample-code/widgets-line-of-sight/, and modified it by using my own WebScene layers.
 
However, the lines that comes from the LOS widget seems weird. They are not completely hidden, nor completely showed. This is what happen when I created the observer and the target from clicking the points on the map:
 
lineOfSight_javascriptwidget.png
 
However, I also tried to use the same WebScene (all the layers are the same), and created and used the LOS widget by using WebExperience. The result is different. LOS Widget from the Experience Builder created the lines properly after creating the observer point and target point on the map. These lines below were created from Experience Builder's LOS widget.
 
lineOfSight_experiencebuilder.png
 
Does anyone know why the results are different between LOS Widget from Javascript and LOS Widget from Experience Builder? Does anyone know any reference I can read/follow to produce the proper LOS lines using Javscript API like the one from Experience Builder's LOS Widget?
0 Kudos
1 Solution

Accepted Solutions
GreteSoosalu
Esri Contributor

Hi @JuanMarvinW 

I was able to replicate the problem with another dataset I had, but it is something we cannot quickly fix. 

The problem occurs when creating the line-of-sight with clicks on datasets with big extents, e.g. where lot of buildings are grouped into one feature. 

Why?

It occurs because of a mechanism that makes the analysis more stable in case of changing LODs (e.g. when one zooms in and out in the scene). When the line-of-sight is created with clicks, the widget automatically saves a feature property to the observer and each target classes. This is an ID of the clicked building/feature to exclude it from the intersection tests. This mechanism of course assumes that each building is a separate feature - which is not the case in this data set. 

Workaround

A workaround is to set the feature = nullHere's the app showing this: 
https://codepen.io/gsoosalu/pen/GgpZvYB 

The app loads a line-of-sight layer with an analysis I had created with clicks, and connects the widget to it. You can see an incomplete visualization similar to your report. If you click the two buttons at the bottom left, the visualization becomes complete. Those buttons set the feature = null. But if you now create a new line-of-sight with the widget, the problem will show up again. This is because, whenever creating new observer/targets, automatically the feature property gets set again. So your app should watch the observer and targets array for changes and make sure the feature gets cleared.

Let me know if this helps you. 

Best regards,
Grete

PS: here's a simpler app that doesn't use the already existing line-of-sight layer/analysis. This shows that the same workaround also functions for cases where the line-of-sight is created only with the widget:
https://codepen.io/gsoosalu/pen/vENKJNy 

View solution in original post

5 Replies
GreteSoosalu
Esri Contributor

Hi @JuanMarvinW 

Thanks for reaching out! Could you maybe share the apps or the layer with me (either here or via direct message) so that we can look more into this? 

Is there a chance that all these buildings are one feature? Also, what I didn't 100% understand - did you create the lines of sight in the EB also by clicking in the scene/map? 

0 Kudos
JuanMarvinW
Emerging Contributor

Hi @GreteSoosalu ,

Thank you for your reply. As you expected, all of these buildings are one feature, with Scene Layer Type = 3DObject. When I select one building, all buildings are selected.

Also, when I created the lines of sight in the EB, I also did the same thing as the Javascript :
- Created the observer point by clicking the side of a building
- Created target points by clicking the scene/map at locations behind a building.

0 Kudos
GreteSoosalu
Esri Contributor

Hi again, 

Thanks for the additional infos! We'll investigate this further - there are some limitation for 3DObject features with big extents but I wonder why you get different results in JS-app vs Experience Builder. 

0 Kudos
GreteSoosalu
Esri Contributor

Hi @JuanMarvinW 

I was able to replicate the problem with another dataset I had, but it is something we cannot quickly fix. 

The problem occurs when creating the line-of-sight with clicks on datasets with big extents, e.g. where lot of buildings are grouped into one feature. 

Why?

It occurs because of a mechanism that makes the analysis more stable in case of changing LODs (e.g. when one zooms in and out in the scene). When the line-of-sight is created with clicks, the widget automatically saves a feature property to the observer and each target classes. This is an ID of the clicked building/feature to exclude it from the intersection tests. This mechanism of course assumes that each building is a separate feature - which is not the case in this data set. 

Workaround

A workaround is to set the feature = nullHere's the app showing this: 
https://codepen.io/gsoosalu/pen/GgpZvYB 

The app loads a line-of-sight layer with an analysis I had created with clicks, and connects the widget to it. You can see an incomplete visualization similar to your report. If you click the two buttons at the bottom left, the visualization becomes complete. Those buttons set the feature = null. But if you now create a new line-of-sight with the widget, the problem will show up again. This is because, whenever creating new observer/targets, automatically the feature property gets set again. So your app should watch the observer and targets array for changes and make sure the feature gets cleared.

Let me know if this helps you. 

Best regards,
Grete

PS: here's a simpler app that doesn't use the already existing line-of-sight layer/analysis. This shows that the same workaround also functions for cases where the line-of-sight is created only with the widget:
https://codepen.io/gsoosalu/pen/vENKJNy 

JuanMarvinW
Emerging Contributor

Hi @GreteSoosalu ,

This is a great and working workaround. I can use your solution for now. Thank you so much for your help. 

For others, please note that the observer and target classes exist in both: viewModel AND viewModel.analysis. Use the classes in viewModel.analysis.

 

Regards,

Marvin

0 Kudos