We do not have GeoJSON support yet, but it is on the roadmap. Our original plan was to write a GeoJSON reader and use our CZML writer library to convert GeoJSON to CZML. However, given that we are working on CZML writing in Geoserver, we may use Geoserver instead, which I imagine might already read GeoJSON. Ultimately, we plan for web services to automatically do the conversion, so for example, we could drag and drop GeoJSON on Cesium and seamlessly visualize it.
I agree that it is low-hanging fruit to write a GeoJSON-CZML converter, and it would be a welcomed contribution. We should first hear what Matt thinks since he is working on Geoserver.
Do you have any good examples or links to examples that we could use to validate/develop against? Coding to the spec is obviously the first step, but real world examples make things way easier.
Since you were the first person to ever suggest it, I wanted to let you know that I’ve just opened https://github.com/AnalyticalGraphicsInc/cesium/pull/890, which adds native support for GeoJSON. I expect it to go into the next release, but if you or anyone else would like to play with it in the mean time, we are always happy to hear feedback.
I’ll be writing up a Sandcastle example soon, for now there is a small example in the documentation:
//Load a GeoJson file, changing the default styling
//for points to use a billboard, rather than a simple point graphic.
var dataSource = new GeoJsonDataSource();
var defaultPoint = dataSource.defaulPoint;
defaultPoint.point = undefined;
var billboard = new DynamicBillboard();
billboard.image = new ConstantProperty(‘image.png’);
defaultPoint.billboard = billboard;
dataSource.loadUrl(‘sample.geojson’);
If you are using the Viewer widget, you would just add dataSource to the viewer.dataSources property.
Thanks for your work on this. I did some testing and ran into one issue I wanted to run by you. My use case for this is integrating with GeoServer to display WFS data. I made my WFS call to GeoServer and this is what my 'crs' object looks like coming back:
{
'properties': { 'code': '4326' }
'type': 'EPSG'
}
However, it looks like GeoJsonDataSource is looking for the 'type' property to be 'name' and then and additional 'name' property which would be 'EPSG:4326'. Not sure if this is an issue or just a problem with my GeoServer setup or the way I'm making my WFS call. Would appreciate any insights you have. Thanks.
According to section 3.1 of the specification, your CRS is not valid GeoJSON. However, if this non-standard CRS is common, we could add the ability for users to add customer handling for it. Does anyone know if GeoJSON like this works in other libraries, like Leaflet of OpenLayers?
Yes, you are correct. I've looked at sample data from a couple of different GeoServer instances though and they all return it in this format. I'm not familiar with Leaflet, but I did look into OpenLayers. I could be reading their code wrong, but I think they just ignore this value. It seems that it is up to the developer to make sure the CRS of the GeoJson data matches the CRS of the map.
I did some digging around and it looks like old draft versions of the GeoJSON spec supported the EPSG crs type. So while it’s technically incorrect in the official standard, it was correct in the past. We should add support for it so that it works both out of the box and also allow people to specify their own EPSG type callbacks. This should be an easy fix. Since we’ll probably have multiple people trying out GeoJSON soon, I’ll see if I can get it into the b18 release, which is actually happening today.
Sounds good. I put in a pull request earlier in the day which was a very basic workaround that just mapped a type of 'EPSG' as if name was 'EPSG'+ properties.code. Your idea sounds more full featured though so you can feel free to use the pull request if it's helpful or just reject it if not.
It is similar to yours but adds a new public property so people can use data with any EPSG type. I’ll try and get it into b18, which is releasing today.