https://stackoverflow.com/questions/80802/does-use-of-anonymous-functions-affect-performance

This old PR (visgl/deck.gl#1003) contained a PathMarkerLayer, which rendered symbols along a path. I might end up reimplementing this layer anyways, for e.g. text labels along roads.

https://github.com/adobe/jsonschema2md

If I combine multiple source layers into a single deck layer for performance reasons, then by default when you pick any line within the PathLayer, you'd pick the entire collection. However, there must be some way for picking to pick a subset, since a GeoJSON layer and Path Layer already do this... You can add many objects but pick one

https://github.com/kylebarron/deckgl-mapbox-style/blob/a4d17bc3b56fa5b277e75f52e0176b893ca804e9/lib/parse-mapbox-style.js#L54-L58

This issue was generated by todo based on a TODO comment in a4d17bc. It's been assigned to @kylebarron because they committed the code.

Use the mapbox style spec's filter!

var ff = require('@mapbox/mapbox-gl-style-spec').featureFilter;

// will match a feature with class of street_limited,
// AND an admin_level less than or equal to 3,
// that's NOT a polygon.
var filter = [
    "all",
    ["==", "class", "street_limited"],
    ["<=", "admin_level", 3],
    ["!=", "$type", "Polygon"]
]

// will match a feature that has a class of
// wetland OR wetland_noveg.
// ["in", "class", "wetland", "wetland_noveg"]

// testFilter will be a function that returns a boolean
var testFilter = ff(filter);

// Layer feature that you're testing. Must have type
// and properties keys.
var feature = {
    type: 2,
    properties: {
       class: "street_limited",
       admin_level: 1
    }
};

// will return a boolean based on whether the feature matched the filter
return testFilter({zoom: 0}, feature);

Note that to validate filter, you'll probably need to pass the filter keys to validateFilter manually, because the rest of the specification won't be a valid Mapbox GL style.

I.e. if I want to snap features to tin inside this layer, if I end up also doing the mvt parsing inside this layer, see #10

https://github.com/kylebarron/deckgl-style-spec/blob/5aec52afb1fda99589c561c1e9265513d9585e7f/lib/util.js#L1-L6

This issue was generated by todo based on a TODO comment in 5aec52a. It's been assigned to @kylebarron because they committed the code.

What shared deck.gl layer attributes do you need to include, i.e.

• id

And what mapbox-style-spec-like attributes?

• source
• source-layer

https://github.com/kylebarron/deckgl-style-spec/blob/fdee88afbbf2defb0f7c58587cc8e86b6daa66a6/lib/parse-mapbox-style.js#L94-L98

This issue was generated by todo based on a TODO comment in fdee88a. It's been assigned to @kylebarron because they committed the code.

How should layers be created from the spec?

new DeckglStyleSpecLayer({...})

Props:

• Style JSON
• features (optional, because I can download them from the style json sources section. If provided, layer names must match.)

Then inside renderSubLayers I render individual layers.

How should the data process work?

• Render individual deck.gl layer for every layer object in the Style JSON? I'm not sure what the overhead is on number of layers, but that seems like a lot, especially if rendered as a sublayer of a tile layer. You could have 20+, 50+ layers per tile. That seems like too much.
• Then the other option is to combine Style JSON layers into a single Deck.gl layer per type of data. I.e. only ~3 layers would be rendered as sublayers of the style spec layer, one PathLayer, one SymbolLayer, one TextLayer (though start with the PathLayer).

I think the latter option makes more sense, so the following will pertain to that.

https://deck.gl/#/documentation/developer-guide/performance-optimization?section=use-updatetriggers

It's worth exploring whether you can use a portion of the Mapbox style spec, without additions within the Style JSON.

Advantages

• Can use the entire breadth of Mapbox Style expressions, etc
• Don't have to do any of my own parsing
• Can define specific fields that I use, while ignoring all other fields.

Expressions

To parse expressions:

arr = [ '==', 'brunnel', 'tunnel' ]
stylespec.expression.isExpression(arr)
// true
exp = stylespec.expression.createExpression(arr)

{
  result: 'success',
  value: StyleExpression {
    expression: Literal { type: [Object], value: false },
    _warningHistory: {},
    _evaluator: EvaluationContext {
      globals: undefined,
      feature: null,
      featureState: null,
      formattedSection: null,
      _parseColorCache: {},
      availableImages: null
    },
    _defaultValue: null,
    _enumValues: null
  }
}

Note that value is a StyleExpression object, which has an evaluate() method.

Note that an expression must begin with one of these keys:
https://github.com/mapbox/mapbox-gl-js/blob/9489d7654ef9bb36a44c9b98446b84eccb98628a/src/style-spec/expression/definitions/index.js#L49-L83

Properties

Need to do a deeper dive here. This seems to be the best way to loop over properties. Look closer at the flow types for help

stylespec.visit.eachProperty(style, {paint: true}, x => console.log(x))

This could have several performance improvements:

• Deal with single web worker. Instead of loading/parsing the MVT in one worker, returning the data, and then passing to this package in another web worker, loading, parsing, and styling happens in the same worker.
• Use TypedArrays. In the current MVTLoader, everything is parsed as regular JS objects and arrays. If you parse the MVT at the same time as you're creating binary objects to return to Deck.gl, maybe you'd be able to always use TypedArrays
• Load directly to dict/Map. Currently, loaders.gl parses to a flat array, which I then need to loop over again when searching for features pertaining to a particular source layer. Could theoretically always work directly with the pbf, but would it take time to parse features every time you iterate over the pbf? Could be better to parse the mvt once for the layers you know you'll be looking at later.

https://github.com/gpujs/gpu.js

For now while developing I'll just stick with geojson features/js objects, but eventually you should support binary attributes for performance.

https://deck.gl/#/documentation/developer-guide/performance-optimization?section=favor-constants-over-callback-functions

Keep data the same, but changing scale with zoom might be able to simulate the same effect as zoom-dependent functions.

https://github.com/kylebarron/deckgl-style-spec/blob/fdee88afbbf2defb0f7c58587cc8e86b6daa66a6/lib/parse-mapbox-style.js#L90-L95

This issue was generated by todo based on a TODO comment in fdee88a. It's been assigned to @kylebarron because they committed the code.

https://github.com/kylebarron/deckgl-style-spec/blob/c4034c5bef9fbe2f9e342c4c2b00f3481ef7fae7/lib/parse-mapbox-style.js#L37-L42

This issue was generated by todo based on a TODO comment in c4034c5. It's been assigned to @kylebarron because they committed the code.