Why are my draggable points jumping to static point locations?


I’ve written a few functions to draw draggable and static points in Cesium. However, I have a big issue when using these together.

I can draw draggable points by clicking on the map, and move them around by clicking and dragging. But if I plot a static point after plotting a draggable point, the draggable point jumps to the location of the static point! I can still drag the point, but it always snaps back to the static points location.

Here’s a Sandcastle demo to illustrate my problem - http://cesiumjs.org/Cesium/Apps/Sandcastle/?src=Hello%20World.html&label=Showcases&gist=54a2252d95768ca89d23948ad010356a

In this example, any click on the map will create a draggable point (red points). There are two timeouts at the end of the script, one of which will draw a static point after 5s, and the other will plot a static point at a different location after 10s. The static points are purple and a lot smaller than the draggable ones.

As you’ll see, if you draw a draggable point in the first 5s, it will jump to the location of the first static point.

What’s going on?!

Kind Regards,


After playing around with my Sandcastle a bit more, it seems that if you don’t draw any draggable points before the first static point is drawn, every single draggable point you plot jumps to the location of the last drawn static point.

Ah, looks like this is caused by a small bug. This:

    let positionCallback = () => {

        return waypointPosition;


Should be:

    let positionCallback = (time, result) => {

        return waypointPosition.clone(result);


The reason is that the signature for the CallbackProperty callback (https://cesiumjs.org/Cesium/Build/Documentation/CallbackProperty.html#~Callback) takes a time and result. If result is provided then you MUST store the result into that existing object and return it (otherwise you should return a new value). Calling clone(result) does just that. The reason it is done this way is because we make heavy use of scratch variables to avoid memory allocations.

This should probably be better documented and we could probably make some changes at the Cesium level to remove this restriction so it will work (at the cost of possible performance if result isn’t used because of extra memory allocations in client code).

For now, I’ll add improved documentation for this issue to my todo list.

Hope that all made sense!


  • Rachel

Thank you so much, Rachel! That works perfectly.

This has been plaguing me for a while now; I’m very pleased that there’s a solution!

No problem, Harry! Glad we were able to help. :slight_smile:


  • Rachel