Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple style editing workflow #50

Open
muesliq opened this issue Jan 4, 2017 · 6 comments
Open

Multiple style editing workflow #50

muesliq opened this issue Jan 4, 2017 · 6 comments

Comments

@muesliq
Copy link
Collaborator

muesliq commented Jan 4, 2017

I currently maintain four styles, a number that will rise considerably in the foreseeable future. Some improvements that I make to one of the styles will also improve the other styles (or some of them).

Currently I use the following workflow:

  1. I work on a style for a session of some hours (up to one day)
  2. Then I fire up a file merge tool (I use DiffMerge) loading the style I worked on as the source, and one of the other three styles as the target. It is important that I do this as long as I still remember what the changes I made were meant to achieve.
  3. I merge all changes that make sense in the target style into it.
  4. Repeat with style number three and four.
  5. I commit all styles to GitHub

This workflow works surprisingly well but I know I will run into problems once I have to maintain five, ten or 50 styles.

In an ideal world Maputnik (or a Maputnik version for advanced users) would help me with this workflow. I am not sure yet how but I would like to open this up for discussion. What do you guys think? How do you work with multiple styles, and what role could Maputnik play here?

@lukasmartinelli
Copy link
Collaborator

We should use your merge strategy 👍

But the problem for us stemmed more because we were iterating on the vector tile schema and field values and layers were changing.

I guess a common pattern is that you have a base style (with some layers) and then a lot of other styles are just layers on top of that or changed colors.

Perhaps one idea would be to specify a base style URL in the metadata (which would be displayed as immutable layers) and only the layers on top of it can be edited.
But that solves kind of a limited use case.

My goal is that we always operate on a valid JSON style as described by the Mapbox GL style spec. If we have additional needs it must be described via metadata.
That's also why I am not sure variables are a good idea.

@muesliq
Copy link
Collaborator Author

muesliq commented Jan 4, 2017

There are various approaches that came to my mind, that could possibly be implemented in Maputnik (just some quick ideas):

A. Includes

The CSS way. Layers could be bundled into sub-stylesheets that could be included into styles. This would make sure that , yet as (unlike with CSS) that's not part of the GL spec this would create a Maptnik-proprietary format that would have to be converted to standard GL files in the end.

Another downside would be that a setup of includes that really fits a specific use case well would require quite some brainwork, as we know from the CSS world. Not very novice user friendly.

B. Copy/Merge on file basis

Basically a replication of the workflow I described above: The possibility to display the difference between to styles in some way (map? comparison slider?), with the option to transfer selected differences from one style to another.

C. Copy/Merge on layer basis

A layer could have a function "Copy layer to another style". The user would select a target style and Maputnik would check if that layer existed (by layer name? or maybe by comparing filters). If not, it would be added (on the same position if possible). If yes, a JSON diff view could show differences and let the user accept or cancel.

If Maputnik knew all my styles (e.g. all the styles in my Github repo) than the function could be "Copy layer to [layer list dropdown]".

D. Variables

Variables that are configured somewhere centrally. Also proprietary, such as A.

(And yes, all these options assume that all styles are similar, share layer names, etc. Such a feature wouldn't make much sense between completely unrelated styles.)

@lukasmartinelli
Copy link
Collaborator

I think the discussion is really interesting - hence I'll keep it open.
However I don't think that I will provide a solution for this any time soon - since this is one of the more advanced features - while it is probably better to work on the lower hanging fruits that can still be improved.

@gregwolanski
Copy link
Contributor

I’ll start working on this issue once 13 people ​react positively to this comment. :)

@tomass
Copy link

tomass commented Mar 18, 2018

Being able to have a "base" style and then add new layers or change properties of "base" layer (without changing the base style itself) would be very useful!
For example if we have a number of base layers (general, topo, light, dark, ortho etc.), it should be possible to create new derivative styles (thematic maps) and update those thematic styles easily when base style changes.
(do not know how much this is in line with Mapbox plans: mapbox/mapbox-gl-js#4225)

@orangemug
Copy link
Collaborator

orangemug commented Apr 9, 2018

I guess the complexity comes with the ordering of layers. For example with a base map in which you want to add a traffic layer this would sit in between the two layers in the original style.

road                <--- base style
transit overlay 
road label          <--- base style

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants