A 'complete workflow' design-lab.

[alukach]

I think that DropChop has been coming together really well since first started. It's getting the bits and pieces needed to be usable (operations, downloading, etc). However, I'm unsure if there's a unified target at the moment. This Issue is intended to spur discussion about what DC should become. A general design-lab. We can continue add features here and there, but I think it's helpful to have a complete user experience that we work towards.

When I was looking into how to add some raster operations into the project, I came across the Turf: GIS for web maps introductory post. What stood out to me was the last example:

I feel that this is what the target of DropChop should be. Everything within the above GIF should be doable in DC.

Workflow

The following is an imaginary workflow that hopefully someone would be able to follow using DC:

A user reaches dropchop.io. They then:

1. Upload a file with a line representing the path of the 'Bay to Breakers race route'. This produces layer raceroute.
2. Style the raceroute line to be bright pink.
3. Upload a file of 'Water Fountains within San Francisco'. This produces layer fountains.
4. Style the fountains points with small black icons of a drop of water.
5. Run a buffer operation on the race route. This produces layer raceroute_buffer.
6. Run a within operation to find all drinking fountains within 500 feet of route. This produces layer fountains_within_raceroute_buffer.
7. Style the fountains_within_raceroute_buffer points to have larger blue icons of a drop of water.

Okay, so that's pretty simple so far. We're not far from that workflow today. The only thing we're missing is applying style, which is somewhat addressed in issue #126.

Let's keep going. The user then decides that they'd be willing to go up to 1000 feet off the route for a drinking fountain (rather than the earlier 500). They:

1. Alter the buffer operation's output to have a buffer output of 1000 feet. The within operation is automatically rerun and fountains_within_raceroute_buffer is updated.

This is something that seems pretty cool and different than any other GIS. The idea that layers can be bound to each other and updates cascade downstream. This could be implemented by having each layer subscribe to their parent layers. When a parent layer updates, it calls for all subscribing layers to rerun themselves. pitfall: If any changes were made by hand to a downstream layer (more on this below), they would be overridden. We'd have to either create a new layer or warn the user that they may lose their changes.

Another one: The user remembers that they plan to make a quick detour to a coffee shop halfway through the race. They:

1. Edit the raceroute line, adding an couple extra vertices and dragging one to their coffee shop. Naturally, all layers downstream update automatically.

I think it's important to have the ability to create and edit layers by hand. This could likely lean heavily on Leaflet.Draw.

So, what does a user do with this awesome styled map that they have? The user decides that they want to share this route on their blog. They:

1. Set the bounds of the map to best encompass the route and then click the 'Download Map' button. This downloads a .zip file with all visible layers, appropriate CSS, and an index.html. The index.html is basically the exact same as the DC view (matching the zoom level and extent of map when download began), but without the menubar or layerlist.

Now we're basically talking about a webmap generator. Someone can edit datasets and output them to a format that is directly uploadable to a server. I don't know of any service that currently does this (maybe CartoDB?), but I feel like this could be a popular feature.

But why stop there? The user then remembers that they have no idea how to upload things to a server. They then:

1. Presses Get embed code, providing them with code that embeds an iframe of the map.

So, this feature is similar to the above feature, only the data is instead posted to a third party service that will host the HTML, CSS, JS, and GeoJSON. This could lean on something like bl.ocks.org/gists. This would hopefully give people the code they need to embed maps as 'widgets' into their blog CMS (eg Wordpress).

And lastly, to finally close the loop and completely mimmic the GIF: The user realizes that other racers may want to know where the nearest water fountains are, but each has a different level of tolerance for running off track. They:

1. Press Get embed code and check allow layer edits within a form. They select the raceroute_buffer layer, select the operation parameter they want users to edit (distance), set some extra configs (disable panning, disable zooming), and add description Water Fountains accessible within {{ field }} feet of Bay to Breakers race route.. This provides them with code that embeds an iframe of the map and a text section above with an input field to allow a user alter the data.

This is now describing basically packaging up the entire DC app (without menubar and layerlist), uploading it to a third party (although download would be possible), and allowing a viewer to run the turf.js operations within their browsers on a predefined dataset (basically recreating pages that are exactly like the example at the bottom of 'Turf: GIS for web maps'). The details are a bit fuzzy (regarding how someone would create the input section), but I think you can get the idea.

In summary, the new features kind of all revolve around:

• Styling data
• Cascading operations
• Outputting actual maps, not just the data

  Execution

I think, at this point, DC could be really useful to people trying to make webmaps. It's a pretty lofty set of features. Given the current speed of the project, all of these could take between 6 - 12 months. If people are into these ideas, I'll break out the features into separate issues and put them all under a single Milestone. Any ideas on what that's be called? Any push back on the features? Any additional suggestions?

[mapsam]

Despite never responding to this, I figure the following GIF is an important first step into this direction. We can actually do the operations!

[alukach]

@mapsam nice, great example of use-case!

To drive home the idea of embeddable Dropchop maps, take a look at this example. There's probably a better way to embed a map than via <iframe>, but it's a start. Imagine if we could store semi-complex data operations in a config (see #209) and load them with an additional GET param (?theater=true)to hide all DC controls (map-view only). I could see it having a lot of utility to people wanting to display geodata and the product of geospatial operations but don't want to write JavaScript code or worry about hosting the data.