KML Roads loading with custom terrain and imagery

[Scott Haynes]

I've been trying to figure out why our KML roads are not rendering the clampToGround option properly.  I ended up creating a sample sandcastle application locally with some of our sample kml files only to end up a little more confused.  I had previously thought that some of the properties of the of the LineString were causing the problem.  Maybe the  tessellate or the altitudeMode need to be set a certain way.  I modified the sample sandcastle terrain application to load 4 different version of the roads.  With agi's https://assets.agi.com/stk-terrain/world terrain loaded I got the following results. ( CTG - clampToGround, RTG - relativeToGround  )

Reproducing the issue:  zoom the camera close to the some of the lines and the pitch the camera back so it's get's closer to the globe.  

orlando.kml – works great, roads are locked to the ground.

orlando_tessellate.kml – roads are not very visible, but do not move.

orlando_tessellate_CTG.kml – roads are not very visible, but do not move.

orlando_tessellate_RTG.kml – works great, roads are locked to the ground.

Here’s the interesting thing:

 

I switched the terrain provider to: 'http://www.vr-theworld.com/vr-theworld/tiles1.0.0/73/'.  The exact same kml lines start to move when the camera is moved around(ie they do not appear to be clampToGround).  It appears that there is something special about agi’s terrain?  If I switch back to https://assets.agi.com/stk-terrain/world the lines do not move around.

// code to load the different kml files( I'm adding the clampToGround option )

var options = {

   "camera" : viewer.scene.camera,

   "canvas" : viewer.scene.canvas,

   "clampToGround": true

}; 

//viewer.dataSources.add( Cesium.KmlDataSource.load( '../../SampleData/kml/orlando.KML', options ) );

//viewer.dataSources.add( Cesium.KmlDataSource.load( '../../SampleData/kml/orlando_tessellate.KML', options ) );

//viewer.dataSources.add( Cesium.KmlDataSource.load( '../../SampleData/kml/orlando_tessellate_CTG.KML', options ) );

viewer.dataSources.add( Cesium.KmlDataSource.load( '../../SampleData/kml/orlando_tessellate_RTG.KML', options ) );

Is there anything we can do to fix the LineStrings from moving?

[Rachel Hwang]

Hey Scott -- we're having some trouble reproducing your issue locally. Can you post screenshots of the issue with the stk and vr-the-world datasets? Also what browser, OS and graphics card are you using?

- Rachel

[Left Gully]

My understanding was that ClampToGround is not supported (yet?) for polylines, linestrings, anything linear including the boundary of polygons. Only points and polygon (fills) can be clamped to ground.
ClampToGround option also requires XY coordinate pairs with no explicit third Z value, not even zero. It does not work with the same data that GE would clamp to ground.

[Rachel Hwang]

You're correct that it's not yet supported for polylines on terrain, but we work around this specifically for loading KML using corridor geometry. Check it out here:

https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Source/DataSources/KmlDataSource.js#L1171-L1181

- Rachel 

[Left Gully]

Rachel, my one attempt using the corridor geometry for KML datasource on 3D terrain was a waste of time. It was unsatisfactory for visualization. It is not a solution, it's a workaround by definition. Good luck to you with that workaround in your use case, but I don't think the limited resources of the cesium team are intended to help make workarounds into client solutions. I quit going down that road, because anything i develop based on a corridor geometry workaround may go down the drain, if/when a polyline clamping solution is implemented. Consider corridor geometry better than nothing, but manage your expectations. If it worked well, then polygon boundaries could simply be rendered as corridor geometry, IMO, and this forum would be filled with happy reports from developers satisfied with the result. I share your pain, don't shoot this messenger, and the cesium team is welcome to correct me if I'm wrong

[Scott Haynes]

Chrome, Windows 7 Enterprise, NVIDIA Quadro K2100M

These two pics are from the exact same camera position.  All I did was change the terrain provider.  As you can see the kml LineStrings have moved quite a bit.

Thanks,

Scott

[Left Gully]

Scott-
Have you considered that the KML line-strings may NOT be moving, and that the terrain is what's different? There certainly are differences in the vertical values of different terrain sources. What is the horizontal accuracy of the two terrain sources?

You have demonstrated a very interesting issue, but it may not be related to the Cesium data viewer at all. 

Best regards, Jon

[Scott Haynes]

Jon,

If the camera is in a top down view the roads line up perfectly.  As I rotate(pitch) the camera down the roads move away from the underlying imagery with the VR terrain.  This doesn't happen with the AGI terrain.  I'm really not sure why this is happening, and I don't really know anything about the terrain sources.

Scott

[Left Gully]

Yes, exactly. I noted that the "same camera position" shows the roads in identical locations compared to the screenshot frame, but the underlying aerial imagery shifts with the VR terrain.

I think you have an issue with the VR terrain data, not the Cesium data viewer. You confirmed that "top down" is okay, so its not a horizontal accuracy issue, the issue is the relative vertical accuracy of the two terrain sources you compared.

The underlying imagery moves away from the roads, not the other way around.

The roads are your "reality check", they are the one constant, remaining in the same position.

It caused by the parallax, or perspective view. The VR terrain (with the aerial imagery draped over it) is noticeably different, and lower, than AGI STK terrain, and as you change the camera pitch, you are looking underneath the roads, which appear suspended in the air above the VR terrain. But the roads are in the same position as when you viewed them compared to STK terrain. The roads didn't move up, the VR surface moved down,

[Left Gully]

Scott (and Rachel) 

Frankly, this gets back to my earlier rant with Rachel. Scott's line-strings are NOT "clamped to ground".

[Hannah Pinkos]

Hi Scott,

Yes, this is happening because your polylines are actually under the terrain instead of on top of it.  We have a workaround in KmlDataSource that will tell the code to use a corridor that is clamped to terrain instead of a polyline if you set the following properties on your LineStrings

<tessellate>1</tessellate>
<gx:altitudeMode>clampToGround</gx:altitudeMode>

The corridors have a width in meters so they don't stay the same width in pixels the way polylines do when you zoom in and out.  But this is the best workaround we have until we have full polyline on terrain support.

Best,

Hannah

On Tuesday, March 28, 2017 at 12:19:08 PM UTC-4, Scott Haynes wrote:

I also have some other features that need to render clampedToGround.  I'm having trouble with billboards and polylines.  Is there anything I can do to keep these objects from appearing to move as the camera is pitched?   The attached pics are of corridors, that had previously been polylines.  

[Scott Haynes]

That definitely fixes the problem, however the performance is not acceptable.  The frame rate drops down to 12-4 FPS.  Is this issue being worked on?  Or is this something that will be fixed by the 3d-tiles/vector features coming up?

Scott  

[Hannah Pinkos]

Hi Scott,

Yes, with the amount of data you have using 3D tiles will ultimately be the best solution for you.  I think we're going to be working more on vector tiles soon.

Best,

Hannah

[Scott Haynes]

We have a graphics service that creates kml for points, lines, and areas.  The areas are clamping to the terrain correctly, but I'm still having trouble getting LineStrings to clamp to the terrain.  

Is there a sample KML file that demonstrates the proper way to get lines to clamp to the ground?

Scott

[Scott Haynes]

I wasn't setting clampToGround = true when the kml was loaded.  I added that, and the lines are now clamping to the terrain correctly!

[Omar Shehata]

Glad you figured that out, and thanks for posting your solution back here!