-
Notifications
You must be signed in to change notification settings - Fork 38
Conversation
@lbud @quinnvd one thing I've always kind of wondered about the less-style operations (we used them directly in cartocss) was that
Are basically duals: saying Thoughts? |
@tmcw hm, true, and I see how if we use a slider UI centered at neutral this would make the implementation weird. But I also wonder if consistency from a Carto/LESS background is important. |
@lbud Personally I'm in favor of prioritizing UI implementation over consistency with carto/LESS. |
@nickidlugash @lbud regardless of how we end up doing this in the style JSON, the UI can do exactly what we want it to do. I was curious about this so I sketched it up: https://github.com/mapbox/app-styles/issues/1352 Basically: show more fields and assume positive input values, or show less fields and assume both positive and negative input fields. Even if we include all the filters, we can still hide the 'negative' versions of the filters in the UI. I do believe if we implement a UI more like sketch 1, having both positive and negative options available would be better usability: As a user, I know I want something to be desaturated. I'm going to look for "desaturate" first not for "negative saturate". |
@tmcw I agree with you here, lets drop the inverse filters. It'll be simpler to implement in the UI. |
I was thinking sliders, too. |
Ok, so we'll pick |
@lbud how about just 'fade' - positive values increase fade, negative values decrease fade? |
Another modification for comment:
|
What's the rationale? I'm tentatively 👎 because previous discussions have pointed towards an omnibus format for sprites that combines images and metadata, which would either duplicate or obsolete style-embedded-metadata. |
What's the rationale?
|
Sprite metadata in the style feels bloated.
If sprites aren't valid in a style, just skip showing them? Easy way to point out a problem. |
/cc @mapbox/gl Can we schedule a v8 sprint directly after the gl-native code is shipped? To ship this, we need many more hands on deck. |
Additionally: should we fold #276 Circle render type into this issue? I'm about to sketch out an implementation in gl-js |
Grabbing types on native. |
@tmcw should |
y, i'll implement that. |
Remove color ops from v8
This happens in mapbox-gl-styles. Doing it here too creates a circular dependency.
Conflicts: CHANGELOG.md package.json
- remove setConstant - add setCenter - add setZoom - add setBearing - add setPitch Issue: #338
'pitch' follows 'center', 'zoom' and 'bearing' to define the default camera position. 0 degrees is perpendicular to the surface. Issue: #341
In new versions of Node and browserify `URL.parse()` URL encodes properties on the resulting object. This has the effect of breaking the migration script in the browser. We can decodeURI the path segments we need to compare in a manner that is backwards and future compatible. Tested with: - browserify - Node 0.10 - IO 3.0
Every other layer type already supports visibility.
Types were made more specific to add extra type safety around constants. Without constants, we no longer need these more specific types. Fewer, well-known types makes tooling support easier. - '*-enum' -> 'enum' - '*-array' -> 'array' - 'opacity' -> 'number' - 'field-template' -> 'string'
Patches:
JS, Native
Changes
mapbox-gl-style-spec/reference/v8.json
Lines 462 to 471 in 2b7c377
mapbox-gl-style-spec/migrations/v8.js
Lines 44 to 50 in 2b7c377
symbol-min-distance
tosymbol-spacing
#252mapbox-gl-style-spec/reference/v8.json
Lines 315 to 326 in 2b7c377
mapbox-gl-style-spec/migrations/v8.js
Lines 51 to 53 in 2b7c377
mapbox-gl-style-spec/reference/v8.json
Line 137 in 2b7c377
text-max-size
andicon-max-size
text-max-size
andicon-max-size
#255mapbox://
URL semantics sematics for mapbox:// glyphs urls in v8 #309