raster tiles or vtile-wrapped rasters?

tl;dr @GretaCB @yhahn and I talked about this yesterday but @springmeyer wasn't in on it and we need to talk more. The current raster branch makes the decision to expose raster tiles, not vector-tile-wrapped rasters, and messing around today in tm2 brought up some reasons why this might not be the right approach.

I spent the afternoon trying to figure out why rasters piled into a tm2 source wouldn't show up in a style unless I toggled the xray-inspector.

The source I built in tm2 is a tilelive-bridge one with _type = 'raster';. It returns a single image from all .getTile requests, amalgamating 15 different rasters that I put into my source. These 15 rasters end up listed as vector_layers because of the XML that tm2 feeds tilelive-bridge.

When I take that to the style side, it becomes the backend to a tilelive-vector source. Now when that source receives a getTile request, it queries my bridge source, receives a raster, realizes its not a vector tile and so wraps it up in one before mashing it up with my cartocss and encoding the result as an empty png.

The png is empty because

• my cartocss defines rules for symbolization based on the names of those 15 vector_layers, and
• the vector tile that tilelive-vector created for me only has one _image layer.

So what's weird about this?

• it doesn't work for styling rasters because you can't write cartocss that will apply to the tilelive-vector-generated layer
• even if did work, it wouldn't be the way you expected. That is, you could not apply different rules to different source layers
• it is a very convoluted code path that can only be described as like being in a creepy house of mirrors

Proposal

• tilelive-bridge (and hence source side of tm2) exposes a source that wraps rasters in a vector tile, layer-by-layer
• users tweak styles per layer and build a tilelive-vector source that delivers raw image tiles
• eventually, band selection occurs in the source-side of tm2, unlocking raster-colorizer symbolization which should absolutely be a target

Start with the raster branch in tilelive-bridge/index.js and trace the getTile flow through tilelive-vector/backend.js and index.js. Compare the current raster and vector-tile-wrapping behavior with the proposal; done would require an agreed design for layer-by-layer raster wrapping and styling, but the issue does not define implementation or tests.