Closed jwalgran closed 9 years ago
A method I've used in the past for this:
Here is a tool that wraps up those last couple steps: https://github.com/MinnPost/mbtiles2s3
Also, after the initial styling, you don't need to open the TileMill desktop application to generate the tiles. You can hit it from the command line. Here's an example of that.
Just realized that the issue references using the raster versions of these datasets. The above workflows I highlighted for vector datasets, so it may not be useful here.
Still awaiting the full list of "display rasters" from Stroud, but there will be at least:
and possibly some showing density of:
So in other words, more than a few, most available at national scale. Still wondering where the inflection point is between storage and dynamically tiling + cache. I imagine cost will be the deciding factor (pre baking the tiles will always be less complex and easier to serve).
If a layer is available as a vector (soils, contours), do we prefer that for display purposes?
Not sure - my thinking was if we need the rasters for calculation, we could have them do double duty for display. A lot of the DEM derived products will be delivered as raster and it seemed like there were few straight up vector sources - that actually may be changing.
There is a WMS service (via AGS) for the NLCD. Not sure if it has enough resolution and performance for our display needs.
I pulled the NLCD up on the viewer. It seems to perform well and it looks like the cells are 30m
Using data-hub issues to track tiling requests.
We have decided that we do not need any runtime customization when we display land cover or soil rasters on the map, so we can save on redundant processing and simplify the web app by generating static tile sets.
Added to the skeleton project created in #11
The input should be a raster, and extent, a set of zoom levels to render, and an S3 bucket+directory destination. The output should be a set of PNGs like
soils/z/x/y.png