We’re migrating our geospatial content management and display appliances from Google Earth to Cesium, and we need some more feature parity to make this happen. Specifically, we need granular Camera control from files within our CMS, as we’re now doing with KML and Earth.
I see CZML has nearly all the features we need (and more!), and we’re happy to convert our customers’ existing content from KML. But the big missing piece is fine control of the camera, as KML does through gx:Tour elements. CZML specifies positions for all those other visual elements in both time and space, so can we add camera control to it as well? Maybe add a “camera” element to the special “id”: “document” element next to “clock”?
We have a mandate for dozens of hours to add this capability to the upstream cesium core, with automated tests any anything else y’all require, and I look forward to working with you all!
Instead of setting viewer.tracked entity, you would start your camera tour logic.
Alternatively, Cesium does have KML support for many KML features and I believe we do suppport gx: Tour. You may not need to convert your files to CZML. If we’re missing a KML feature you’re using, let me know and I can add that to our KML roadmap.
Yes, we see how to control the Camera from the API, but we really need a way to serialize this into a file within our CMS, preferably the same file that contains the visual elements.
We’d like to add this feature, either within KML or CZML or both. Is there an existing ticket for this specifically? Where should we start?
To get this working quickly, we’re also considering serializing the camera control in another JavaScript file, then loading it from the CMS with jQuery.getScript() or similar. We’d strongly prefer camera control to reside within the same file as the visual elements, but we’ll take what we can get.
I’m not sure if this is something we would want to add to the CZML specification, so starting with KML or your own custom data source would probably be your best bet.
For KML, In order to have the exact same behavior seen in Google Earth you will need to make changes to both the Camera.flyTo functionality and the KmlDataSource. Currently, camera flights operate independently from the clock on the timeline. In order to make the camera fly back and forth as you scrub the timeline, you would need to make the camera update happen based on the application clock instead of the system clock. Then in KmlDataSource.load you would need to write code to create camera flights based on whatever data is in the KML document. Finally, you would need to make some changes to KmlDataSource.update to move the camera based on the time. I think that would be it. This isn’t part of the code I’m super familiar with, so I’d have to ask other members of the team to see if there’s something I’m forgetting.
If you would like to take a stab at implementing this, let me know and I’ll create an issue on our GitHub with some more details. And if you get it working, we would really appreciate the contribution back!