The issue with elevations that I mentioned earlier is going to affect kml absolute as terrain elevation is ellipsoidal.
Elements with altitudeMode absolute will be offset vertically by the amount of the egm96 geoid undulation using Ellipsoid.WGS84.cartographicToCartesian
Yes, that will be the case for the initial release in 1.7. We will definitely address it some time soon and most likely provide a way to arbitrarily query MSL as a core feature.
Could processTimeSpan() be set to allow both ogc and gx namespaces? Without or available the result is the same for placemarks (at least in google earth gx:TimeSpan and TimeSpan on anything other than or worked identically).
I can’t really identify why one namespace has been used over another, but looking at some different KML’s, I’ve seen some with one, some with another, and a few with both.
Thanks for the heads up Denver. Even though the docs say gx:TimeSpan is only for specific elements, it looks like Google Earth does indeed let you specify a gx:TimeSpan anywhere you can also specify a TimeSpan. I just submitted some code to handle this case.
I was looking at making a javascript implementation of the fortran code for calculating the egm96 undulation,
http://earth-info.nga.mil/GandG/wgs84/gravitymod/egm96/egm96.html
googled to see if there was an implementation in a more modern language and came across
also came across this
http://egeoint.nrlssc.navy.mil/geoid_height_v2/geoid_height_service/example_restful_calls.jsp
The normal of the geoid can be in a different direction from the normal of the ellipsoid at the same lon/lat. So lets say you have a bunch of absolute points all sharing the same lon/lat but with different alts. Well each of those points would be hovering over different lon/lat locations even though they are all defined with the same lon/lat.
Anyone know of an area where there is a large angle between the geoid normal and the ellipsoid normal? It would be a good place to test GE to see if height is really in the direction of the geoid normal, or the ellipsoid normal.
Berwyn, while I appreciate the links, you should know that your second link to agi.com is actually the company that started Cesium (and is still its main source of funding). Most of the core team works here and most of us worked on the product you linked to (STK Components), myself included. Trust me when I say that you have nothing to worry about when it comes to Cesium’s planned support for MSL. It’s just a matter of carving out the time to do it and do it efficiently given a browser environment.
Matt
When I saw the AGI class documentation the first thing I thought to myself “Oh here it is, it’s probably on the long todo list”
Sorry, I should have added a comment along the lines of
“with the EarthGravityModel96MeanSeaLevel class in AGI’s other libs I imagine its going to be in cesium one day”
from the kml spec
H≈ h - N
the larger discrepancy for terrain will be at terrain with higher elevations. Typically the angles involved are so small you wont see any practical difference. The geoid model itself is more of an issue, hence the newer geoid models http://www.ngs.noaa.gov/GEOID/
Check out this diagram from that site you linked (found on page http://www.ngs.noaa.gov/GEOID/geoid_def.html )
http://www.ngs.noaa.gov/GEOID/IMAGES/d04.jpg
So Orthometric Height H of terrain is actually along a curved plumb line from the Geoid? When you say an object is X meters above MSL at a certain lon/lat, does that mean X meters along a curved plumb line rising through the air from that lon/lat?
With 1.7 now out, I encourage anyone using KML to switch to the official release of Cesium. Please continue to provide feedback about any problems you encounter (I’ve actually already fixed 3 KML issues for 1.8 that should help compatibility out a lot, and expect plenty more to be found).
Thank you to everyone who provided test cases and feedback during the dev process, and a special thanks to André Nunes, who was our Google Summer of Code student who did the initial KML work way back in summer of 2013. This was truly a team/community effort.
While this is just the beginning and there is still a lot to be done to completely support the KML spec, I feel like Cesium already has one of the best implementations available outside of Google Earth, and it will only get better. In the coming days we’ll have a blog post to help everyone get the most out of the current functionality and I’ll follow that up with a new thread to let people voice their preferences as to where to go from here.
Thanks again,
Matt
Hello, I'm thankful for your wonderful development!
I am a professor and developer of Google Earth contents. Google Earth API deprecation was very regrettable for me.
Thanks to you, We switched my Typhoon Realtime Watcher (a typhoon early warning system) to cesium.
We could use the previous KMZ file just as it is. But, groundOverlays with TimeSpan couldn't be indicated well. We used 'SingleTileImageryProvider'.
Our team made "digital archive of the Hiroshima atom bomb" using Google Earth API.
We will also switch it to cesium.
We are grateful to you for your help.
Thank you Matt!
Well done to everyone involved, especially Matt who did most of the work, I know this was a huge undertaking and I’m glad to see it working out.
I’m really happy to see some of my code being used by so many people, please let me know if I can help out in any way.
terça-feira, 3 de Março de 2015 às 02:26:43 UTC, Matthew Amato escreveu:
Still getting to grips with Cesium. I need to get a proxy going for my website, as I have two subdomains my kml files can be obtained from. Is there any documentation on building your own proxy?
Dylan.
You only need a proxy if you are planning on loading data from servers you don’t have control over. If you do have control over them, it is recommended you enable CORS
That being said, if you do need to make a proxy, it’s highly dependent on what server software you are using, node/apache/IIS/etc…
I am a semi-programmer abandoned by Google Earth and grateful for the amazing effort here to support GE users. Matt & Team, you are awesome, thank you.
For me, I have tours in Google Earth I need to be able to run somewhere else. But I am certainly happy with whatever you choose to support!
Thanks again
Hi,
Thanks for your efforts and contribution and make more convenience. Does Cesium supports export .kml or .kmz format now? Thanks a lot~
Matthew Amato於 2015年3月3日星期二 UTC+8上午10時26分43秒寫道：
Export is not something we plan to do. The main problem is that Cesium itself can do a lot more than what KML can, so you can easily have visualization in Cesium that is literally impossible to express in KML. That being said, it would be pretty easy to write a plugin that handles the stuff that KML can do and I think that’s a great idea, (it’s just not something on the core Cesium roadmap). We do eventually plan on supporting CZML export, but I have no solid timeline for that yet.
http://mramato.github.io/CesiumViewerKML/ link not working
That’s because KML support is now officially part Cesium. You can see it in action via the Sandcastle Example: http://cesiumjs.org/Cesium/Apps/Sandcastle/index.html?src=KML.html&label=Showcases or you can drag and drop your own files on the Cesium Viewer: http://cesiumjs.org/Cesium/Build/Apps/CesiumViewer/index.html
None of the links/files posted here should be used any longer and you should just download the latest Cesium release instead: http://cesiumjs.org/downloads.html
