Adding a Cesium.GeoJsonDataSource.readFeature method

[spatialillusions]

In some cases I would like to process GeoJSON feature by feature and create Cesium entities from them, similar to how readFeature works in Open Layers.
http://openlayers.org/en/latest/apidoc/ol.format.GeoJSON.html#readFeature

Today this is not possible, what you can do is to load GeoJSON data and receive a promise, but that will be hard to handle when you want to loop through all your features and handle them one by one. (What I want to do is to process each feature to an entity and apply a visualization based on a lot of the feature attirbutes.)

If I read the code it would be possible to do this is parts of the load function in the load method for GeoJsonDataSource was broken out as a pure feature parser and added as a method to GeoJsonDataSource. The readFeature method would return a entity or an array of entities based on what kind of feature that was parsed.
https://github.com/AnalyticalGraphicsInc/cesium/blob/1.31/Source/DataSources/GeoJsonDataSource.js#L857

If this was done I would not have to write my own feature parser for creating entities.

[hpinkos]

Thanks for the suggestion @spatialillusions! If you would be interested in implementing this, we would be happy to review a pull request. You can see our Build Guide for instructions on checking out and building the code base, and our Contributing Documentation for instructions on opening an pull request.

[mramato]

Today this is not possible, what you can do is to load GeoJSON data and receive a promise, but that will be hard to handle when you want to loop through all your features and handle them one by one. (What I want to do is to process each feature to an entity and apply a visualization based on a lot of the feature attirbutes.)

I'm not sure why you say this is impossible. See this Sandcastle example which does exactly what you're describing (the Custom styling option).

What benefit does your request provide over the above approach?

[spatialillusions]

@mramato I might have been a bit unclear in my previous post. I know that it is possible to do it this way, and I have done exactly that previously. The thin is that that reads several features and converts them to entities, and then you loop the entities and apply the style. Since I'm handling extended GeoJSON I will loose the extra information when they are converted to entities, and this makes it impossible to use this approach this time.

The styling I'm trying to do is quite special since it is military graphics, and I'm making it more complex since I want to be able to support Open Layers and Cesium. (And in some cases both at the same time.)

Because of this I want to be able to process each GeoJSON feature individually, and add the entities one by one, and since you have written good code to process features to entities, I thought it would be nice if that functionality was a public method.

Does this explain a little better why I would like to do this?

You can find the early development code here: https://github.com/spatialillusions/milgraphics/tree/master/src/graphicslayer
(As you can see in the code the ordinary GeoJSON feature is extended with the property symbol and the property graphic, that are objects containing a lot of functionality. Symbol is a milsymbol with a lot of methods for providing military icons.)

[thw0rted]

I know this ticket is crazy old, but I came across it while looking into a related GeoJSON topic. @spatialillusions , did you ever get this working the way you wanted? (Also: hi! I know you from milsymbol.) I don't know what the behavior was 3+ years ago, but the current GeoJsonDataSource is supposed to preserve all GeoJSON feature properties as Entity properties. Was that not the case for your "extended GeoJSON"?

I've poked around in the existing code a bit and what you described in your original post would not be simple to implement. The problem is that in Cesium, an Entity has at most one of any graphical primitive, while a lot of other feature-description systems (like GeoJSON) have concepts like a "multi-polygon" or disjoint line strings. Cesium represents these using entity hierarchies, with one child entity for each piece of the multi-polygon. In order to implement this, the conversion methods in GeoJsonDataSource pass around the source's underlying EntityCollection and dynamically create new entities as needed, to handle the one-to-many nature of feature-to-Entity conversion. The existing code could be refactored to pass a collection of one or more Entities up (out of the various process functions) rather than passing the entity collection down (into the functions), but it would be a major effort, and who knows how it would effect performance.