First let me qualify up front I’m very new to GIS space but learning quickly! We have a client that built a very large KML (120MB) file for Google Earth to serve over the Web and we were tasked to find a way to improve performance. Obviously downloading and the loading a file that large was not going to be a happy experience for any user. So, my first attempt was to find a way to break the file up and serve it more efficiently. But the deprecation of the GE plugin pretty much forced us to look at other 3D solutions. Thus Cesium.
I’ve created a stack of Cesium/Geoserver/PostGIS/PostgreSQL as I think this will provide the most optimum way to manage and serve this fairly complex visualization, especially as they plan to extend it going forward. I used Google Earth desktop to break the KML out to smaller files. I have some challenges with breaking down some of the layers there but I’ll leave that out of discussion here unless you can suggest a better way to break down the KML before importing into PostgreSQL. I am using ogr2ogr to import the file into to PosgtreSQL directly with the following command "ogr2ogr -f “PostgreSQL”. Some web resources suggested to convert to a shapefile first but I’m not sure that would create a different result? Seems to go pretty well so far. The issues I’m having comes to serving up the layer via WFS in Geoserver to Cesium using geoJSON and rendering using GeoJsonDataSource(). Below are 3 challenges I’m having and would like some suggestions or let me know if Cesium currently doesn’t support it. BTW I’ve tried using the KML branch to serve the KML directly but wasn’t having any luck. Regardless I think serving on the above stack is a better overall solution and if I can import into the stack then I thought geoJSON would be a better option to serve the layer than KML.
As a first attempt to validate the stack I imported the sample geoJSON file in the SampleData folder from the Cesium download. When serving that as geoJSON from Geoserver it changed the syntax of the geoJSON by replacing dashes “-” with an underscore “_”. Example property attribute “marker-symbol” became “marker_symbol”. Cesium did not understand this and the layer did not render. This may be a Geoserver issue but I’m at a loss how to fix it or if there is some variation in the spec that isn’t supported.
When importing the legacy KML into PostGIS I used EPSG 4326 as the coordinate system. Subsequently, Geoserver adds a CRS object to the end of the geoJSON data that looks like this
However, this won’t render in Cesium. But if I remove the CRS object from the geoJSON (I’m serving from a file as a testing ground in the Sandcastle app), it renders. But I’m not sure correctly as when I zoom in it seems the lines are a little off.
Any clue? Is the structure invalid? Also, if I replace the URN with this one “urn:ogc:def:crs:OGC:1.3:CRS84”, it renders fine with the same “offness” as removing it entirely.
All the imported KML that I’ve successfully imported renders in Cesium as the color Yellow. It does not seem to retain the colors specified in the KML. I haven’t spent much time trying to troubleshoot this yet but was wondering if the conversion process just lost this data or if I’m doing something wrong. Again, this might not be a Cesium issue but maybe someone can offer some clue. Or do I need to modify the imported data after the fact? If so, should I just do that in the Cesium API? Or should I do this in Geoserver? If the latter, what’s the best way to do this? Do I need a mapping software like OpenLayers to do this?
Sorry for the novice questions, but this is a lot to learn! If this is not the appropriate place to ask some of these questions, please direct me to a better source. Is something like gis.stackexchange.com a good place?
BTW here is my Cesium code in Sandcastle if that helps.
var viewer = new Cesium.Viewer(‘cesiumContainer’);
var dataSource = new Cesium.GeoJsonDataSource();
NOTE: I’m just copy and pasting the Geoserver WFS served data into the simplestyles.geojson file as a way to test temporarily. Easier than dealing with the proxy server issues for now.