Native GPX and Shapefile support

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.

Welcome back André!

do you intend to use this repository ( to parse shapefile?

Thanks Matt.

Hi everyone, it’s a pleasure to work with Cesium once again.

If you want to follow my progress, here are the links for my branches:



GPX is smaller and easier than shapefiles so I will begin with that format. Feel free to discuss and ask any questions you may have.

terça-feira, 26 de Maio de 2015 às 17:07:55 UTC+1, Matthew Amato escreveu:


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:

Other suggestions are welcome.

terça-feira, 26 de Maio de 2015 às 17:43:39 UTC+1, escreveu:

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.

Welcome back André! I’m looking forward to your progress. Have you posted the roadmap?


Thanks Patrick!

I’ve posted the initial draft for each format’s roadmap as a GitHub issue:


Please add the label when you can, feel free to edit and/or give feedback.

Thanks André, the roadmaps look good. Any thoughts on Shapefile metadata and using it for styling?


Another suggestion for javascript shapefile processing

the author of this was also working on

this appears to the official javascript port of proj4, a major component of the OSGeo/gdal stack

the coordinate transformations are going to be a big part of the shapefile processing

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.

André - do you have an update on your work?




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.


André Nunes

Thanks for the update. Good luck with your finals.

Once you are in full swing, please make sure to post demos as you have them.


came across this article today

quick look at source, looks like they are using cesium leaflet ... not sure if there is any issues no credits being displayed

they have proj4js in there

no support for .shp files

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.

Hello everyone!

I want to apologize for the lack of progress, I was really busy with my final exams and couldn’t focus on both things at the same time.

I’m done now and I’ll be able to give my full attention to this project, more updates soon.

Thanks for your patience.

Good luck Andre.

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:

[Garmin symbols]( Symbols)

More Garmin

Big icon library with all gps symbols supported by Garmin

GPSBabel icon list

What icons should be supported by Cesium? I’d like to read input from the community and the main developers.


terça-feira, 21 de Julho de 2015 às 03:06:50 UTC+1, Denver Pierce escreveu:

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.

You are correct, but how will the user specify the default mapping? How will that work in practice?

quinta-feira, 30 de Julho de 2015 às 23:56:23 UTC+1, Matthew Amato escreveu: