-
-
Notifications
You must be signed in to change notification settings - Fork 401
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
Comments
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. 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. |
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.) |
I think the discussion is really interesting - hence I'll keep it open. |
I’ll start working on this issue once 13 people react positively to this comment. :) |
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! |
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.
|
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:
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?
The text was updated successfully, but these errors were encountered: