Skip to content
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

raster tiles or vtile-wrapped rasters? #16

Open
rclark opened this issue Jun 20, 2014 · 2 comments
Open

raster tiles or vtile-wrapped rasters? #16

rclark opened this issue Jun 20, 2014 · 2 comments

Comments

@rclark
Copy link
Contributor

rclark commented Jun 20, 2014

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
@yhahn
Copy link
Member

yhahn commented Jul 2, 2014

Per discussion, we're going to defer this until after raw raster data (TIF, non RGBA) can be output from Mapnik (#15).

@springmeyer
Copy link
Contributor

Next action is to find time to work on mapnik/mapnik#2491

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants