按照官网示例的 var flydata = { "name": "贴地表表面漫游", "interpolation": true, //是否setInterpolationOptions插值 "clockLoop": true, //是否循环播放 "camera": { "type": "gs", "distance": 500 }, "points": [[116.043233, 30.845286, 392.48], [116.046833, 30.846863, 411.33], [116.052137, 30.848801, 439.45], [116.060838, 30.850918, 442.91], [116.069013, 30.852035, 435.14], [116.18739, 30.854441, 244.53], [116.205214, 30.859332, 300.96]], "speed": 160, "model": { "show": true, "uri": "data.marsgis.cn/gltf/mars/q…", "scale": 0.2, "minimumPixelSize": 50 }, "path": { "color": "#ffff00", "width": 3, "show": true } }; 本身由于points数据量较少，模型漫游不会出现卡顿，但是实际应用中points可能会是一个比较大的数据量。
不仅在漫游过程中会卡顿，而且在开始漫游的一瞬间，示例上会有一个比较大的模型一闪而过，然后会与模型拉开距离，但是实际应用过程中，不知道是不是因为数据量大的问题，偶尔这个比较大的模型闪不过去接着就一直是一个较大的模型在跑。
model可以设置clampToGround为true，意为贴地，如果不设置在转动视角的时候，模型位置会发生偏移
使用这个flyLine最大的问题在于，难以和后台数据进行关联，如果通过timeinfo的x/y/z经纬度点和数据的经纬度点进行全等比较,这不仅是一个很大的数据遍历，而且需要通过setInterval进行不断的比较，最重要的是这些点并不能完全匹配得上。 换了一种思路就是拿当前漫游点和数据中每两个进行比较看是否在这两个数据之间，然后酌情使用数据。然而这种方式目前针对循环往复得运动就不适合了，因为点总是会进入到第一个符合条件的两个数据之间。
目前公司用的mars3D也是基本按照例子写，没有更深入的进行优化，这个东西我也是这两周才开始看，目前遇到的问题难以继续优化，网上例子也少，只能先这样放着了
