czml to kml?

[Dave]

Is anyone working on a CZML to KML converter?

[Ed Mackey]

As far as I know, there are no efforts to go that direction, czml to kml. The hard part is that czml is designed to accommodate time-varying values, like the paths of aircraft and spacecraft, where positions change smoothly over time. Certainly kml can show a simple line for the path of a vehicle, often with markers on it indicating key times of interest. But you wouldn't get a file that could produce the same smooth motion as czml. Perhaps kml export is still worth doing, we would love to hear from anyone who gives it a try, but it's not on our list at the moment.

--Ed.

[Matthew Amato]

To elaborate a little more on Ed's explanation; I'll add that we (the Cesium developers) originally did not want to invent yet another specification (i.e. CZML) but ended up doing so for the reasons Ed mentioned.  As they say, necessity is the mother of invention.

Ultimately, the KML standard can not express the time-dynamic nature is inherent in CZML.  While there are non-standard extensions, such as Google's gxTrack, that allow dynamic positions; that's about it.  There's no way to express other things, such as billboard properties, polyline geometry, etc.. that change smoothly over time.  We thought about adding our own KML extensions, but realized by the time we were done, the resulting files would be nothing but non-standard extensions and effectively useless in Google Earth and other KML apps.  On top of that, KML is xml based and we wanted to come up with something that could more easily be leveraged inside of the browser.

If someone want to write a CZML -> KML converter, I'm all for it; just realize that you wouldn't be able to implement the full CZML specification (which in itself is still under heavy development).  On the other hand, I would love to have the time to experiment with implementing CZML visualizers for Google Maps, so that you could load CZML into Google's own web-based control.  As far as I know, that is completely possible and If anyone wants to work on that, let us know.

I've droned on for far too long; but I hope that sheds some light on our motives.  If you have any thoughts on the matter, please let us know.  I'd also love to know why you were interested in such a capability to begin with, because we can hopefully help you find a good solution.

Matt

On Sun, Oct 7, 2012 at 12:19 PM, Ed Mackey <elm1...@gmail.com> wrote:

As far as I know, there are no efforts to go that direction, czml to kml.  The hard part is that czml is designed to accommodate time-varying values, like the paths of aircraft and spacecraft, where positions change smoothly over time.  Certainly kml can show a simple line for the path of a vehicle, often with markers on it indicating key times of interest.  But you wouldn't get a file that could produce the same smooth motion as czml.  Perhaps kml export is still worth doing, we would love to hear from anyone who gives it a try, but it's not on our list at the moment.

     --Ed.

--

[Patrick Cozzi]

Dave - I'm curious: what is the use case for the converter?

Matt - Feel free to expand the "How is CZML different than KML?" question in our FAQ - https://github.com/AnalyticalGraphicsInc/cesium/wiki/FAQ#wiki-czml_kml

Thanks,

Patrick

--
 
 

--
www.seas.upenn.edu/~pcozzi/

[Ed Mackey]

A good case for this functionality is so that early adopters know their data won't be "trapped" in CZML format.

I'm a big fan of Google's Data Liberation Front and similar efforts.  Facebook has an "export everything" feature as well, under account settings.  Generally before you store your critical data in a new format or on someone else's cloud, you should make sure you can get it out if need be.

Granted, KML won't give us paths in inertial frames etc., but a simple export to ECF paths could demonstrate a little data interoperability as well as help us show the strengths that CZML has over KML.

             --Ed.

[Patrick Cozzi]

I wonder if the best approach is to add support to Geoserver to read CZML - in addition to our current work in adding support to write CZML.  This would allow users to convert CZML to a wide array of formats supported by GeoServer.  Of course, there would be some amount of information loss; presumably the internal Geoserver format, and end formats do not support all CZML features, but for some users this could actually help adoption of CZML because they would not have to change their client code that already renders KML, for example.  This is just an idea, and I do not consider it pressing compared to everything else we are working on.

Patrick

--
 
 

--
www.seas.upenn.edu/~pcozzi/

[Matthew Amato]

Ed,

If that's the only reason, then my recommendation would be to generate KML from the same source data that the CZML is being generated from and keep that original source data around for archive purposes.  CZML is a presentation format (so is KML for that matter) and not a data storage/transport format.  It should not be used for archiving purposes, but for visualization/presentation only.

For example, if Facebook stores all of it's data in a database and then supports a million output formats; that's great.  If we had a hunk of data, then I think that's a great approach.  But we're mostly just a viewer, and therefore don't have any data to convert manage, instead we generate CZML from other sources (like STK, Shape files, Map documents, etc.. )  We also have tools that generate KML from these sources.

Just my 2 cents.

On Mon, Oct 8, 2012 at 10:36 AM, Ed Mackey <elm1...@gmail.com> wrote:

--
 
 

[rezn8d]

I would like to add a few more cents.

I sincerely hope your team reconsiders the importance of a KML to CZML translator.  KML is beyond huge at this point.  Thousands of developers have invested time and money into their projects, and are locked into the format.  Having a working translator to convert these files on the fly would ensure less hesitation from those considering migration.  Basically Google is dragging their feet on a WebGL version of Google Earth, and my Linux users are demanding something! lol

My project, ClimateViewer 3D ( http://climateviewer.com/ ) aggregates climate/weather monitoring KML live links, and none of these excellent sources of live data will be available in Cesium without a proper conversion server.

My partner has programmed a working KML to CZML converter in windows which converts marker icon, name, and location, with some hiccups on the CDATA.  Regardless here is how far he got:

KML source is downloaded by our server, then:

• a) interpret or calculate summarization/heatmap/clustering data from its features
• b) export to JSON/CZML once all the data has been collected and transformed to CZML format

This way, any user can simply link to KML live resources in their html and display that data on Cesium.   

As soon as a working KML->CZML conversion server is live, I am converting to Cesium!

Jim Lee

http://climateviewer.com/

[Matthew Amato]

Jim,

Just to clarify, we are committed to a full featured KML to CZML converter; which is in active development in the github czml-writer project.  We hope to make the process as seamless and straightforward as possible.

What we are not working on is going the other way, starting with CZML and converting to KML.  We are not against any efforts to build such a converter, it's just not a priority for us right now and think it will have several hurdles due to the non-time-dynamic nature of the KML specification.

Matt

--
 
 

[rezn8d]

excellent! *rubs hands in anticipation