"save your project"

[mapsam]

What does this look like?

An idea: When you press "save" it builds a new, anonymous gist with each layer as it's own file in that gist, which can be loaded again. This way when we want to build in browser caching, similar to geojson.io, we can just load in that gist ID instead of caching each layer.

[alukach]

I think this feature is essential for DC (and a critical component of #130). I've thought a bit about it, here is what I had in mind:

The entire app state (or, at least layer's states) needs to be serializable. This would likely be an object with a list of layers (order of list representing order in layerlist and draw order on map). I'm going to call this the config file. Each layer would likely store its source, configurable properties (name, styling). Additionally, the config object should store a version property allowing us to make changes to the config spec in the future but still supporting past versions (similar to how mapbox gl style config stores a version).

Some cases that will need to be sorted out:

• Where to store the file? I thought the same as @mapsam suggested, dropping them into an anonymous gist (and likely in the future, a gist associated to the user similar to how geojson.io allows you to upload to your gist account). While working on a file, we could write the config object to local storage, allowing people to maintain work between browser sessions.
• Uploaded local files: Uploaded files are not going to be accessible when loading a config file. When creating a config file, we should allow the user to optionally upload the file as a gist so that it is recoverable. I would imagine that this file would be in the same gist as the config file, but will not be in the config file itself. If a user doesn't want to upload their file to github, we could either a) drop the layer from the config file; or b) create an empty layer that we can allow a user to populate with data be re-loading the data from their computer when they load the config file.
• Online files: A user should be able to choose if the config file a) stores a link to the online file; or b) stores a copy of the online file itself (in a similar fashion to the uploaded files, along side the config file in a gist). By storing a link, it will allow us to load up-to-date data whenever loading the project (keeping with the idea that DropChop can be a viewer of data). By storing the actual file, a user can either "freeze" real-time data or, if we allow a user to edit a file, keep the changes to the data that they make. As an aside, by storing the display properties in the config file rather than the source file, it will be easier to re-apply the styling upon import of a linked file.

I see this really being amazing if/when we enact the idea of operations being more like 'pipes', modifying the source data (meaning chainable, and if you make a change to the source data upstream, all layers downstream are updated). We'll save the source data, the operations that act upon the source data, and the styling of the output data. This could allow people to save/share mashup-maps of realtime data, which would be cool.

[mapsam]

I like these ideas. Why don't we each take a swing at this and see what we come up with/what we learn and come back with recommendations?

[mapsam]

Working on saving a project. The new option save project essentially takes all layers and POSTs them to the Gist API, returns a success response, and updates the URL for that new gist ID. Here it is in action.

[nickpeihl]

Whoa! That's awesome @mapsam!