Serving vector tiles

[chapmanjacobd]

Instead of {z}/{x}/{y}.png I'd like {z}/{x}/{y}.pbf

I've generated something before like this:

tippecanoe -Q --no-tile-compression --no-tile-size-limit --minimum-zoom=7 --maximum-zoom=7 --drop-rate=1 --output-to-directory=file/ file.geojson

I imagine this would be the centroids of each pixel as a vector point? Do you think this is possible?

Do GeoTiff COG overviews hinder access to the native resolution pixels of the COG? It would be nice to serve native resolution vector-tile-pixels up to a desired zoom level.

Can overview pixels be accessed explicitly? that might be interesting to experiment with for higher zoom levels than a client could easily process

somewhat related to:
#11 <-- is this the same thing?
#44 (comment)

[j08lue]

I see you really mean vector tiles (not binary tiles). But how do you want to build them from the raster (GeoTIFF) data?

Do GeoTiff COG overviews hinder access to the native resolution pixels of the COG?

No. GDAL automatically retrieves overviews if they exist, when you perform a decimated read into a smaller output shape with Rasterio https://rasterio.readthedocs.io/en/latest/topics/overviews.html, but if you do not ask for some smaller output shape, you always get the actual pixel data.

Can overview pixels be accessed explicitly?

Not sure Rasterio can do that, but GDAL Python bindings do, apparently: https://gis.stackexchange.com/a/376210.

is this the same thing?

We have discussed adding an API for vector tiles but never considered creating vector data from rasters (on the fly). Again, I am really curious, why do you want to do that?

[vincentsarago]

FYI, for rio-tiler we created https://github.com/cogeotiff/rio-tiler-mvt plugin which use https://github.com/tilery/python-vtzero to create the vector tiles. Basically we can do 2 things:

• create points vector from pixels (or polygon for each pixels) (pixels_encoder)
• create shapes using rasterio/GDAL polygonize functions (shape_encoding)

We used this in https://github.com/developmentseed/titiler-mvt

[vincentsarago]

Can overview pixels be accessed explicitly?

Not sure Rasterio can do that, but GDAL Python bindings do, apparently: https://gis.stackexchange.com/a/376210.

You can specify OVERVIEW_LEVEL option when you open a dataset

with rasterio.open(path, OVERVIEW_LEVEL=X) as src:

[chapmanjacobd]

This is super helpful! Thanks both

I am really curious, why do you want to do that?

• I like how fast terracotta is when importing lots of layers and I like COGs as a storage/archival format for this type of data. I'd rather vectorize on the fly because that seems more flexible.
• In the application that I'm working on I already have a way to generate a color scale so I'm not 100% sure how I would replace that system with terracotta manual colormaps.
• Vector shapes feel more interactive in the browser...

At the same time I see the value of png: less client-side parsing == faster. Maybe terracotta can already do everything that I want but it isn't super obvious to me. I might move to png in the future; if that is the case then pbf would only be a stepping-stone for an existing front-end that I have.

These are the main things I would need to rewrite if I was using png:

• Filtering across multiple images (a pixel is only shown when all of the selected attributes are within a user-specified range). I'm assuming this could probably done with /compute route and some boolean logic. (All of my rasters were processed with target-aligned-pixels--but what happens if they weren't? does /compute require images have the same extent?)
• Display the exact value of a "pixel" on mouse-click. I can easily do this when it is vector. I thought I saw a /latlon route when I investigated terracotta a couple weeks ago but I don't see it now ? maybe I am mis-remembering
• Custom colorscale actually might be easier than I thought. The non-dynamic scaling format seems easy enough. I could do something like this?: .png?colormap={0.0: '#ffffd9', 17.691: '#edf8b1', 35.382: '#c7e9b4', 53.074: '#7fcdbb', 70.764: '#41b6c4', 88.455: '#1d91c0', 106.147: '#225ea8'} <-- ahhh... this is rounding to the nearest key? but I need explicit steps (min or max) hmm... :/

[dionhaefner]

I'm not sure how much work it would be to offer vector tile output, maybe it's not that bad since rio-tiler has already done the hard part for us :)

That being said, I'm not quite convinced that this is a nice use case. But if you really want this and put in a PR I could imagine to merge it.

Regarding your issues:

• Filtering across multiple images (a pixel is only shown when all of the selected attributes are within a user-specified range). I'm assuming this could probably done with /compute route and some boolean logic. (All of my rasters were processed with target-aligned-pixels--but what happens if they weren't? does /compute require images have the same extent?)

/compute should work well for this. There are no requirements in terms of alignment, as the computation is done on the final tile (which is always on the same xyz grid).

• Display the exact value of a "pixel" on mouse-click. I can easily do this when it is vector. I thought I saw a /latlon route when I investigated terracotta a couple weeks ago but I don't see it now ? maybe I am mis-remembering

Not possible out of the box, but there are some tricks you can use. We've discussed this here.

• Custom colorscale actually might be easier than I thought. The non-dynamic scaling format seems easy enough. I could do something like this?: .png?colormap={0.0: '#ffffd9', 17.691: '#edf8b1', 35.382: '#c7e9b4', 53.074: '#7fcdbb', 70.764: '#41b6c4', 88.455: '#1d91c0', 106.147: '#225ea8'} <-- ahhh... this is rounding to the nearest key? but I need explicit steps (min or max) hmm... :/

It sounds like what you want is actually a custom colormap. The explicit format you quote is meant for categorical data, where you can match values to colors 1:1. If you want interpolation between values, you need a custom colormap.

[dionhaefner]

Did this end up working for you @chapmanjacobd ?

[chapmanjacobd]

yes for visualization purposes PNG is much faster than client side parsing vector tile "pixels" 😏