GeoJson support

[Christian Ledermann]

Is support for Geojson planned?

Reason:

Geojson is a widely spread and supported format

On the clientside there is e.g. leaflet, PolyMaps, etc

and on the serverside PostGis, Geoserver, and so on

I guess GeoJson support is quite low hanging fruit, as the format

is not so different from CZML

Support of this format would give Cesium a good position for the 

use cases where values that change over time are not 

a must have feature and people just want a beautiful globe. 

[Patrick Cozzi]

Hi Christian,

I agree with you on all accounts.

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.

Regards,

Patrick

--
 
 

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

[Matthew Amato]

Christian,

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.

Thanks,

Matt

[Christian Ledermann]

http://iwlearn.net/events/aggregator/events-map/@@geo-json.json
http://iwlearn.net/images/countries/@@geo-json.json
http://iwlearn.net/iw-projects/basins/lmes/@@geo-json.json

> --
>
>



--
Best Regards,

Christian Ledermann

Nairobi - Kenya
Mobile : +254 702978914

<*)))>{

If you save the living environment, the biodiversity that we have left,
you will also automatically save the physical environment, too. But If
you only save the physical environment, you will ultimately lose both.

1) Don’t drive species to extinction

2) Don’t destroy a habitat that species rely on.

3) Don’t change the climate in ways that will result in the above.

}<(((*>

[Matthew Amato]

Chrstian,

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.

[Christian Ledermann]

:) great! Thanks so much!

I'll try to test, but I am very busy right now so it might some time ;(

> --
> You received this message because you are subscribed to the Google Groups
> "cesium-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cesium-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[etienne....@gmail.com]

Oh, great. It seems to be very good ! :)

Do you have any example of code or sandcastle ?

Regards,
Etienne

[Matthew Amato]

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.

[linde...@gmail.com]

Matthew,

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.

[Matthew Amato]

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?

[linde...@gmail.com]

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.

[linde...@gmail.com]

Sorry, I read your reply incorrectly. Yes, I can confirm that that GeoJson works in OpenLayers.

On Friday, November 16, 2012 11:45:43 AM UTC-5, Christian Ledermann wrote:

[Matthew Amato]

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.

[linde...@gmail.com]

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.

On Friday, November 16, 2012 11:45:43 AM UTC-5, Christian Ledermann wrote:

[Matthew Amato]

I just opened this pull: https://github.com/AnalyticalGraphicsInc/cesium/pull/918

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.

--
You received this message because you are subscribed to the Google Groups "cesium-dev" group.

[linde...@gmail.com]

Thanks. I just tested it and everything is working great.