We are visualising (time-changing) data from a PostGIS database in CesiumJS. Until now we have had great success writing CZML using our own (simple) python code, and this works fine for simple geometries, sadly now we need to support polygons with holes, as well as multipart geometries.
Before doing this ourselves, on searching i see signs that holes may be supported by the czml-writer project, but it is written in .NET..(we run linux) meaning if we build the project with mono then back up and write KML instead and then launch command line procs in our chain to get back CZML.... seems like an overly complicated pathway.
I have not found any examples of CZML docs representing polygons with holes, i see there is a method for punching a hole in a poly in javascript (PolygonPipeline.eliminateHoles()).. and how they can be built from a polygonHierarchy, but not how they can be described in CZML.
so my question is: what is the currently recommended way to communicate complex geometries to cesium, can they be represented in CZML? perhaps do we need to add custom attributes to our CZML to describe holes, and build them ourselves in the JS ?
thanks for any ideas and great thanks for the awesome project.. we're really excited about what we've been able to achieve !
The short answer is that complex geometries can currently be created with the Geoemtry & Appearances system. Unfortunately, CZML and the DynamicScene layer currently don’t have support for this. The good news is that we are working on it and plan on having it done in the next couple of months. I just created a thread about these new features and what has to happen to get there, see here: https://groups.google.com/d/msg/cesium-dev/9jzhk3Hv8v0/BCMOvUf1jRsJ
Your thread regarding the roadmap is very interesting, as a user its great to have visibility of the future developments like that.
If I can add my 2c:
- if CZML is to be able to transmit complex geometries in the future i would vote for the incorporation of either geojson or WKT into the CZML format, rather than a new method for describing that.
- in terms of workarounds an easy method for us would be for an attribute placed on a feature in CZML to be available on the primitive when it appears in the dynamic object.. so we can then apply modifications. Currently this is not the case (i think/correct me?), and i would therefore vote for the 'czml to dynamic object' process to copy all attributes across, even if they are not recognised as part of the CZML spec.. which be useful for other applications later.