Google just announced Google Summer of Code 2015. Organization applications open on February 9, 2015. We participated in 2013 and I would like us to participate again.
Let’s use this thread to
brainstorm student project ideas
let mentors volunteer
Then we’ll use the ideas from this thread to create our list of projects like our 2013 list. I would also like to see us set the bar very high for applicants this year.
Please reply with your project ideas and/or to volunteer yourself as a mentor (must be a Cesium committer).
Google Summer of Code 2015 applications open on February 9. What student project ideas for Cesium do you have? Here’s a couple to get started:
Example/demo pack: create Cesium demos with Raphael, AngularJS, and other popular libraries (like our D3 demo). Also, create Cesium demos with cool datasets like NASA Worldview.
Improved build/test infrastructure like, for example, #652.
Patrick
Thanks the feedback. I’ve flushed out the ideas and added some new ones:
Visualizing Drone Flights in Cesium: We’ll provide an inexpensive Drone like this, and the student will write a series of demos and tutorials for visualizing a Drone flight path (using CZML), pictures taken from the Drone, video, maybe even LiDAR. More info.
Example/demo pack: create Cesium demos with Raphael, AngularJS, and other popular libraries (like our D3 demo). Also, create Cesium demos with cool datasets like NASA Worldview.
Improved build/test infrastructure: for example, Travis CI (#652) and GitHub backups (#1204).
Any thoughts? What other student projects would be useful to the Cesium community and interesting for students?
For applications in 2013, we encouraged students to try Cesium issues labeled beginner. For 2015, I suggest student applicants either (1) write a demo application using Cesium, or (2) try a beginner issue.
Here’s my random ideas that I’ve been meaning to bring up:
Redesign Sandcastle
Cesium Sandcastle is a great application for learning, demoing, and experimenting with Cesium. It’s one major drawback is the lack of responsive design, making it useless on small tablets and mobile. It also looks like a traditional application instead of a sexy web-app. We would also like to remove its dependency on dojo. This project would rewrite Sandcastle to address these issues, most likely by using Bootstrap for responsive layout, introduce data-binding to the application via Knockout, and (since Bootstrap already depends on it), use jQuery if needed in places where dojo may have been using some heavy lifting. The end result is a new Sandcastle which is easier to use, treats mobile as a first-class application, and brings more polish to our demo functionality.
Revamp Documentation Build
This is not a project that involves writing documentation, instead it is about determining whether we want to stay with jsDoc or go with an alternative such as jsDuck or something else. It will also improve how are documentation is built and incorporated into Cesium. For example, if we stay with jsDoc, our current Reference Documentation is pretty ugly and would benefit from a new template that adds a collapsible tree view, separates functionality into modules, does not include the full index on every page, etc… We also want a way to start including non-reference doc, such as our tutorials on the website, into the offline documentation that ships with Cesium. This is already supported by various doc packages, we just need someone to help make use of it and import our current doc into it.
Support for more Standard Geospatial Formats
Add a GPX Data Source and Shape File Data Source so they can be supported directly by Cesium. (Note I specifically left out GML because it is far too big an effort to undertake during GSoC).
I’ll add them to the wiki as well, let me know what people think.
For Sandcastle, another goal I would consider is ease of going from a Sandcastle example to a standalone app, e.g., export a single HTML that references Cesium.js on a CDN or whatever. Currently, we see users working a bit too hard to turn their Sandcastle code into a standalone app.
One more idea for Sandcastle: A while back Scott mentioned being able to encode an entire example in a URL so we wouldn’t have to copy and paste into Sandcastle. I’m not sure how out of hand that would get, but could be awesome.
This could be an OK plugin or maybe core feature if the format gets popular and the implementation is reasonably small.
However, I envision much bigger things for vector tiled in Cesium, e.g., metadata to avoid cracking (MapBox vector tiles are not really built for 3D), pre-triangulated polygons, extrusions, quantization, etc. Actually, I see this bleeding into streaming 3D buildings, e.g., a heterogeneous set of possible nodes, such as vector or 3D models, in an HLOD structure.
Right, there are definitely much more exciting, powerful, and complicated things we can do with vector tiles. However, I still think it’s worthwhile to add support for an existing vector tile format (and MapBox has the most popular of the open ones AFAIK), because:
We can use existing tilesets and generation tools. We don’t have to worry about the server/processing side right away.
Simple vector tile systems should map easily to QuadtreePrimitive. I don’t think the implementation will be difficult, and we shouldn’t need to write a ton of new code.
We’ll gain experience with vector tiles. We’ll learn what renderer/primitive/entity features are needed to support them better. We’ll have a better sense of what the “perfect” vector tiling system looks like.
And while I agree that “MapBox vector tiles are not really built for 3D”, the same can be said of everyone’s raster tiles. I don’t think cracking in vector tiles will be worse than what we already get with raster tiles. In fact, I think it will be a lot better, because labels and markers at least won’t be split across tiles. I definitely like your concept of heterogeneous nodes in an HLOD structure.
In any case, my argument here boils down to “it would be interesting and not that hard and we’d learn some things” rather than “this is a clearly compelling feature people need”, so a plugin might be the way to go. It’s up to you if that disqualifies it from GSoC consideration.
If you need support for this and it starts off in a plugin, I think it is an OK GSoC project.
If the format becomes an OGC or de facto standard - and the Cesium support is reasonable (given the need for client-side triangulation and I still expect cracks from T-joints, for example, unless we carefully tessellate and re-tessellate along the boundaries as LODs change, which complicate the implementation and use a lot of extra memory) - then it could be move to core.
With that said, I think we will have similar functionality - optimized and tuned for 3D - in core Cesium around the same time that GSoC will end and that Cesium would benefit more from other GSoC projects like, for example, continuous integration.
I was really sad when you didn’t apply last year. If you are a student wondering whether or not to apply for this organization let me tell you that I’ve participated in two editions of GSoC and the one with Cesium was the most enjoyable experience in every aspect.
Expect another application from me again this year
segunda-feira, 2 de Março de 2015 às 19:25:56 UTC, Patrick Cozzi escreveu:
