Projecting and Tiling Aerials

I hate aerials.

That’s not really true. Aerials are pretty. What I hate is waiting. Jobs measured in hours instead of minutes drive me crazy. It’s the same reason fishing with a bobber drove me crazy as a kid. The is-the-bait-still-on-there-or-did-it-fall-off was a Schrödinger’s cat dilemma I couldn’t deal with.

Our aerials come in state plane, which further complicates things. They also come as JPEG’s. Go figure. At least it isn’t MrSID any more.

If you’ve gotta:

1
2
3
4
5
6
7
8
9
10
11
12
13
#! /bin/bash

echo "building initial vrt..."
gdalbuildvrt -overwrite tiles.vrt NCMECK17-TILES-1METER/*.jpg

echo "make projected tiff..."
gdalwarp -t_srs EPSG:3857 -overwrite -multi -co "NUM_THREADS=ALL_CPUS" tiles.vrt tiles.tiff

echo "cut tiles..."
./gdal2tilesp.py -z 8-18 tiles.tiff tiles

echo "create mbtiles..."
mb-util tiles aerial2017.mbtiles

This does our 1 meter aerials to zoom level 18 in ~2 hours on a craptackular government-issue Dell laptop (dual core 4 thread i5 8GB RAM). The resulting MBTiles file is 12GB and flings images like nobody’s business.

Our bunch (thousandish) of tiles are perfectly square in state plane, and hauling them to web mercator individually yields breathtaking edge matching problems. Building a VRT and dropping it into a single TIFF fixes that problem.

gdal2tiles.py (thanks Paul!) enhances gdal2tiles with parallel processing and cranks out XYZ which is a bit easier to reduce to MBTILES.

mbutil takes that folder of images and tosses them in a MBTILES file. This feels slower than it should be, but it could be that I’m literally sitting on my CTRL-C hand at this point in the process.

Big hat tip to Pvanb’s post on Ecostudies, which helped me get the wall of GDAL command usage output from bad arguments fewer times than I normally do.