I am retrieving the sampler from the groundView of my scene.
It is sync and matches the currently shown ground elevation as you noted in your previous message. That is great for my use case.
A better accuracy (the async sampler) would not help my use case as I only want to display markers above the current ground.
As you also noted, one "problem" I have is that when the underlying data changes the markers could be off until their z is updated. The "changed" event is no really helpful as it basically fires at a high rate as soon as the view moves. One way to improve the situation would be to debounce the event handler. I have decided not to go down this path for now as I refresh the live tracking every 2mn or so and it should be good enough for now.
To keep things simple I am also not using "relative-to-ground" as I would have to create yet another layer. Again the ~2mn delay should be ok with my use case.
So basically I'm very happy with the integration. It is not perfect but it is great. I love working with the JS API which is simple yet powerful. Here is my code for reference - there is still room improvement on my side. I also really appreciate the great the support provided by the ESRI team, thanks for that!
I have a few ideas / comments / feedback on the API:
My live tracking data is GeoJSON. I can not use a GeoJSON layer because it wouldn't support altitude exaggeration. It would certainly be possible to subclass the layer to add support but it would be great if exaggeration is better supported out of the box.
My app tracks paraglider pilots. The "absolute" or "relative-to-ground" are not ideal for that as the lines and markers should not be below the ground. A "clamp-to-ground" mode would be ideal here - I feel it would be easier to implement within the API that trying to achieve it with client code. An example would be lines: imagine a track going over a hill. If the sampling interval is such that that there is one fix before the hill and one fix after the hill then the line would go through the hill. The current API is great if the object is on the ground but is less ideal for flying objects. I could super-sample the track to emulate a clamp to ground but it would be a lot of code. The primary use case is when pilots are higher above the ground.
Have a great day,
Vic