Better error handling for malformed CZML
See original GitHub issueI’m just starting to generate my own CZML and I’ve found that the Packet parser can at times be less than helpful when you feed it bad data, as in this simple example.
It bombs out parsing the second of 3 entities because I fed it an enum value (2, number) instead of the key it was expecting (FILL_AND_OUTLINE, string). That’s on me, of course, but it would be very nice to have helpful console output when this happens – something along the lines of invalid value "2" for property 'label.labelStyle'. Current behavior is that it just attempts a property access on an undefined value and throws an uncaught exception. From the user perspective, it might be nice to recover from such bad values and either ignore that individual property, or at least just discard the one entity with the malformed property and attempt to continue processing all the other entities / packets in the data.
Issue Analytics
- State:
- Created 6 years ago
- Comments:6 (6 by maintainers)

Top Related StackOverflow Question
There is a JSON Schema for CZML which does catch this error (after fixing the other JSON violations from the snippet (missing quotes, extra commas))
Invalid: data.label.style.labelStyle should be equal to one of the allowed values, data.label.style.labelStyle should be equal to one of the allowed values, data.label.style.labelStyle should be equal to one of the allowed values, data.label.style.labelStyle should match exactly one schema in oneOf, data.label.style.labelStyle should be stringhttps://github.com/AnalyticalGraphicsInc/czml-writer/tree/master/Schema
This could be the foundation of a validation tool.
validate.jsin the above directory uses Ajv to validate the example snippets which appear in the CZML spec. However, the script is pretty basic and expects each file to contain exactly one packet, so I had to manually split up the document to get it to report the above error.Just ran into this today: https://community.cesium.com/t/strange-error-when-loading-my-czml-file/10467. Here the issue was a missing “epoch”, and the error message tells you there’s a missing JulianDate but it’s hard to trace exactly what is missing.
CesiumJS already has a mechanism for catching errors without slowing down the runtime. Is there any reason not to add checks like this throughout CZMLDataSource that would be stripped out in the release version?