Multiple style editing workflow about maputnik HOT 6 OPEN

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

from maputnik.

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.

from maputnik.

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.)

from maputnik.

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.

from maputnik.

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)

from maputnik.

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

from maputnik.