I have the pleasure of once again mentoring André Nunes as part of this year’s Google Summer of Code. Long time mailing list readers may remember André from the initial KML support he worked on as part of in GSoC 2013. This time around he will be implementing native Cesium support for both GPS Exchange Format (GPX) and Shapefiles. While some users have had success converting these formats to ones Cesium already supports, like GeoJSON or CZML, native support will be more complete and also make it easy for Cesium to ingest the millions of files that already exist.
If you’re interested in either of these formats, consider this the official place to discuss them and ask any questions you may have. André will also be posting status updates and other info here as he makes progress.
Writing a parser was a possibility but I think using an existing one will be more practical, we just need to find the best parser for us… do you recommend that one?
In my initial research for Shapefile parsers I also found:
We will definitely investigate third-party data readers for Shapefiles, but we will not be converting to another format, like GeoJSON, behind the scenes. Converting to an intermediate format will not only be slower, but also be incomplete, since GeoJSON can not represent all shapefiles. For example, as far as I know there is no GeoJSON equivalent to shapefile’s MultiPatch geometry. If I’m mistaken,let me know.
André, shapfile-js has not been updated since 2011, and mbostock/shapefile is a node.js library and not fit for running in a browser. We want this to be a complete client-side implementation. If there isn’t a suitable OSS client-side shapefile reader out there, we will have to either roll our own or contribute back to an existing one to get it up to snuff. I’m pretty sure I’ve come across competent ones in the past though, so I’ll see what I can dig up.
Thanks for the links. We’re well aware of proj4js and have even considered depending on it in Cesium proper in the past, but haven’t had a good reason to yet. The shapefile-js looks promising, but if it only handles things that can be converted to geojson (as it’s project description leads me to believe), it won’t be good enough for our needs (see my original comments above). It’s worth looking into, and perhaps we can even contribute something back to it in order to improve it enough for Cesium’s use cases.
I’m sorry for the lack of progress but as I mentioned in my application, the initial part of GSoC clashes with my school’s exam season. The last couple of weeks have been very busy and I couldn’t get anything done. The rest of the week should be calmer and then I have another exam on June 16th.
My focus for the rest of the week is extending CesiumViewer to load .gpx documents and implement a GpxDataSource to process these documents generating the respective geometric types to be rendered by the viewer. I want to start experimenting with simple GPX’s Waypoints until they show up on CesiumViewer. Then I’ll move on to the other features (Tracks and Routes).
I’m also trying to draw some parallel between KML’s geometry types and GPX’s:
GPX’s Waypoints are very similar to KML’s Placemarks. Contrary to KML there’s no style, just WGS 84(GPS) coordinates of a point and possibly other descriptive information (elevation, name, comment, etc).
GPX’s Tracks are very similar to KML’s gx:Track. They are an ordered list of routepoints (waypoints) leading to a destination.
GPX’s Routes basically Tracks without timestamps. The points should be connected to form a line like KML’s LineString.
Looks like that application is using TerriaJS, which we originally developed for Australia’s National Map. Plus some unique server-side bits.
Looks like the imagery is from MapBox and looks really nice. I hadn’t realized MapBox’s imagery had gotten that good.
I’m not sure about the 4DMapper setup, but TerriaJS itself does support shapefiles via conversion to GeoJSON on the server. Once Cesium has native support for shapefiles (thanks André!) we’ll switch to using that.
Have you looked at zipped shapefile support at all? Zip.js is already being loaded for KMZ support, and it’d be great to have the additional functionality.
Right now I’m working on GPX support but I see no reasons why zipped shapefiles shouldn’t be supported in the future.
Quick question related to GPX, the format specifies symbols/icons of Waypoints by name, no href and there’s no list of “standard” icons that I could find, it depends on vendor. I found some icons supported by Garmin which appears to be the most famous vendor using GPX:
Am I correct in that the spec doesn’t specify a set list but just allow for string descriptions? If so I think the best approach would be to allow users to specify a default mapping of names to images. By default we could just use a simple pin like we do in GeoJson.