KML viewer.flyTo placemark goes underground

[hpinkos]

Reported on the forum: https://groups.google.com/forum/?hl=en#!topic/cesium-dev/E27D7WJHWZ8
Using viewer.flyTo for a pin created by this KML file results in the camera going under ground.

var viewer = new Cesium.Viewer('cesiumContainer'); 
var options = { 
    camera : viewer.scene.camera, 
    canvas : viewer.scene.canvas,
    clampToGround: true
}; 
var zoomTarget; 

var kmlFile = "https://raw.githubusercontent.com/googlemaps/kml-samples/gh-pages/kml/Placemark/placemark.kml"; 
var promise = Cesium.KmlDataSource.load(kmlFile, options); 
Cesium.when(promise, function(dataSource) { 
    viewer.dataSources.add(dataSource); 
    zoomTarget = dataSource.entities.values[0]; 
}); 

Sandcastle.addToolbarButton('Fly to Placemark', function() { 
    viewer.flyTo(promise); 
}, 'toolbar'); 

Interestingly enough, the same thing does not happen when you create a pin at the same location with the entities API

var viewer = new Cesium.Viewer('cesiumContainer'); 
var options = { 
    camera : viewer.scene.camera, 
    canvas : viewer.scene.canvas 
}; 

var pinBuilder = new Cesium.PinBuilder(); 
var entity = viewer.entities.add({ 
    position : Cesium.Cartesian3.fromDegrees(-122.087461,37.422069), 
    label : { 
        text : 'pin', 
        verticalOrigin : Cesium.VerticalOrigin.TOP 
    }, 
    billboard : { 
        image : pinBuilder.fromColor(Cesium.Color.SALMON, 24).toDataURL(), 
        verticalOrigin : Cesium.VerticalOrigin.BOTTOM, 
    } 
}); 

Sandcastle.addToolbarButton('Fly To Entity', function() { 
    viewer.flyTo(entity); 
}, 'toolbar'); 

[hpinkos]

"The difference between the two examples appears to be the initial bounding sphere computed for the entity. For the second example, the center of the bounding sphere is identical to the entity's position. Not so with the KML example -- the z-component in particular is much smaller. After the second button click, the bounding sphere gets recalculated and the center becomes roughly the same. "

[hpinkos]

This was fixed sometime between 1.26 and 1.27, but I'm not exactly sure by what

[mramato]

The only reason this appeared fix was because the clampToGround setting in KmlDataSource is now properly added, I updated the original code sample to properly trigger the bug again.

[hpinkos]

var viewer = new Cesium.Viewer('cesiumContainer'); 
var options = { 
    camera : viewer.scene.camera, 
    canvas : viewer.scene.canvas,
    clampToGround: true
}; 
var zoomTarget; 
var kml = '<?xml version="1.0" encoding="utf-8"?>\
<kml xmlns="http://www.opengis.net/kml/2.2">\
  <Placemark>\
    <name>My office</name>\
    <description>This is the location of my office.</description>\
    <Point>\
      <coordinates>-122.52087481,37.422069</coordinates>\
    </Point>\
  </Placemark>\
</kml>';
var parser = new DOMParser();
var promise = Cesium.KmlDataSource.load(parser.parseFromString(kml, "text/xml"), options); 
Cesium.when(promise, function(dataSource) { 
    viewer.dataSources.add(dataSource); 
    zoomTarget = dataSource.entities.values[0]; 
}); 

Sandcastle.addToolbarButton('Fly to Placemark', function() { 
    viewer.flyTo(promise); 
}, 'toolbar'); 

[hpinkos]

Also reported here: https://groups.google.com/d/msg/cesium-dev/9i62vHWn438/NeA5woENCgAJ

[ggetz]

Also reported here: https://groups.google.com/forum/#!topic/cesium-dev/a-m284HtIiA

[mramato]

To fix this, I think we just need to update BillboardVisualizer.getBoundingSphere to sample terrain (if available) rather than relying on _clampedPosition (which is only using the highest level loaded instead of the highest available). I think we can get the terrainProvider from the EntityCluster, but haven't looked that closely.

[mramato]

Will also need to update other visualizers with clamping behavior.

[ainthek]

The original sample with KML is still not working.
a) So do you have any real code fix to fix this code ?
b) what a user of https://cesium.com/cesiumjs/cesium-viewer/index.html? can do to fix this ?
c) shell the users fix the KML ? how ?
It is very unclear from all this cross communication. thanx for help.

It is important to instruct users of viewers app
`var viewer = new Cesium.Viewer('cesiumContainer');
var options = {
camera : viewer.scene.camera,
canvas : viewer.scene.canvas,
//elipsoid:Cesium.Ellipsoid.WGS84,
clampToGround: false
};

viewer.extend(Cesium.viewerCesiumInspectorMixin);

var zoomTarget;

var kmlFile = "https://raw.githubusercontent.com/ainthek/map-projects/master/data/samples/BMXRaceTracks.googleearthpro.kml.gdal.gpx.gdal.kml";
var promise = Cesium.KmlDataSource.load(kmlFile, options);
Cesium.when(promise, function(dataSource) {
viewer.dataSources.add(dataSource);
zoomTarget = dataSource.entities.values[0];
});
viewer.flyTo(promise);`

[OmarShehata]

@ainthek I can still reproduce the bug. Until there's a fix, one workaround is to initiate a second flyTo after the first one, which seems to always go to the right location:

viewer.flyTo(promise).then(() => viewer.flyTo(promise)); 

Sandcastle. Obviously not ideal to go underground in the first place though.

[ainthek]

@OmarShehata thanx for workaround, but WHY is this magic hack
not part of the default Cesium Viewer app ? So when I publish link
https://cesium.com/cesiumjs/cesium-viewer/index.html?src=..... my friends can actuale see something ? ;-0)))))

[OmarShehata]

@ainthek I replied in your forum thread here about ways you can solve this for your particular use case.

[ncutt010]

Here's a workaround that worked for me

Get the camera height after flyTo is complete. When the camera height is a negative number is when we run into the bug. If that's the case, simply run the flyTo method again until the height is a positive number

function flyToCustom (entity, attempt = 0) {
    let hpr = new HeadingPitchRange(CesiumMath.toRadians(0), CesiumMath.toRadians(-90.0), 0)
    viewer.flyTo(entity, {duration: 1.0, offset: hpr}).then(() => {
        const ellipsoid = viewer.scene.globe.ellipsoid
        const height = ellipsoid.cartesianToCartographic(viewer.scene.camera.position).height
        if (height < 0 && attempt < 50) { // only attempt 50 times before giving up
          flyToCustom(entity, attempt + 1)
        }
      }
    })
}

Also, increasing the altitude of the HeadingPitchRange seemed to mitigate the problem