Extragate point features in 3D scenes

[cbp-geus]

We are trying to make a presentation of registered earthquakes in Denmark since 1954 using 3D feature points in a local scene. The points are showing their registered magnitude on the Richter scale at their depth, but unfortunately the scene only allows real world units for the vertical axis, so all the points are clamped to the bottom of the terrain. This is really a shame, that there are no options for vertical exaggeration like in ArcGIS Pro. We understand that it would be heavy to display for global scenes, but why not for local scenes, knowing the fact, that it is always difficult to show features at vertical depths at larger scales.

[AndreasUlmer]

Vertical exaggeration in scenes has been requested often, and is a candidate on our roadmap. No specific plans yet, but we can hopefully tackle this in the near future.

For now the only workaround I can think of is to export the data with hardocded exaggerated z values for display (and maybe store the original z value in a field for reference if needed).

Would that be a doable workaround for you?

[AndreasUlmer]

I stand corrected: Completely forgot we actually have support for this case: using featureExpressionInfo one can exaggerate vertical position of point features using expressions, see this sample.

There is currently no UX to set this in Scene Viewer. However when such an expression is set in ArcGIS Pro and exported to a webscene it is supposed to come over and display as expected (as in Pro). In SceneViewer UI elevationMode will show as `<<custom>>`.

Could you try if this is working for you?

[cbp-geus]

Hi @AndreasUlmer,

Thank you for suggesting this. I will try out this tomorrow and see if it works. If the scene viewer can handle the expression, wouldn't it be more or less easy to implement this capability in the scene viewer in the future?

[cbp-geus]

Hi @AndreasUlmer,

I tried to set the elevation properties of my layer to Custom as you suggested, using the link you provided. I couldn't get the featureExpressionInfo to work and if I tried with just the Geometry($feature).z * 10, it got validated it, but nothing happened. Instead I extracted the z-value as an attribute and defined the layer elevation using this expression instead, $feature.Depth_km*10. This works in ArcGIS Pro, but when I share the layer as a scene in AGOL, I get the same result as before. I even tried with a factor 100 and has an effect in ArcGIS Pro, but not in AGOL. The Elevation mode is however set to <<custom>> in AGOL.

$feature.Depth_km*10

$feature.Depth_km*100

[AndreasUlmer]

Hmm this is unexpected.

Would it be possible to share the published webscene / the published layer with us (i.e. make it public and share the link)? This would allow us to track down if the problem is in Scene Viewer (when consuming the scene / layer) or in Pro (when publishing the layer).

>  If the scene viewer can handle the expression, wouldn't it be more or less easy to implement this capability in the scene viewer in the future?

Yes it is correct that the underlying ArcGIS Maps SDK for JS supports this already. Adding UI to Scene Viewer for features supported in the underlying SDK is not always a trivial change though unfortunately. In this case for example new UI for editing arbitrary expressions is needed.
As mentioned we understand this is an important feature and is on our roadmap, but without a specific date yet.

[AndreasUlmer]

Did a test of this scenario now, and can confirm it works for me.

* If elevation comes from z-values: use Arcade expression Geometry($feature).z * factor
* if elevation comes from attributes: use Arcade expression $feature.attributename * factor

In my test in both cases the published webscene has the correct expression set, and point features display on the expected exaggerated elevation in Scene Viewer (same elevation as in Pro).

See also: https://developers.arcgis.com/javascript/latest/arcade/#z-values

----

In case this still does not work for you we'd need to see the problematic webscene, and the version of Pro used to track this down further.