How to prioritize blocks for planting using a thin-canopy map

A citywide canopy average of 28% tells you almost nothing about where to send the next planting crew. Somewhere in that average is a block at 4% and a block at 55%, and the spreadsheet doesn't know the difference. If your department is working toward a planting target, the question isn't "what's our average cover," it's "which blocks are thin enough to matter, and which of those are worth planting this budget cycle."

Start with the gap, not the average

A canopy gap map shows cover block by block instead of folding everything into one citywide or even one neighborhood number. That distinction matters because planting targets usually get measured and reported at a level finer than "the city." A council member asking why their ward still looks bare isn't going to be satisfied by a number that includes the wooded blocks three miles away.

Pull the block-level layer and sort blocks against your target percentage directly, since a citywide average can hide which specific blocks are thin. A target of 40% cover means a block at 12% is a real deficit, even if the citywide number looks fine on paper. These are your thin-canopy blocks, and they're the raw material for a priority list, not the finished list itself.

Turning the map into a priority list

Low cover alone doesn't make a block plantable this year. A block can show thin canopy because it's genuinely short on trees, or because it's mostly parking lot, or because the right-of-way is six feet wide and already full of utility conflicts. So the map gives you the candidate pool, and then someone on staff still has to walk the short list and check what's plantable: open tree wells, available parkway width, no overhead conflicts, no pending utility work.

A workable process looks something like this:

1. Rank all blocks by canopy percentage against your target, lowest first.
2. Drop blocks that are mostly non-plantable surface (industrial yards, highway frontage) unless your program covers those.
3. Cross-reference against known equity priorities, since thin-canopy blocks and heat-vulnerable neighborhoods tend to overlap.
4. Flag blocks due for a biennial recheck so you're not planting into a gap that closed last cycle.
5. Hand the short list to field staff for a stocking check before it goes into the planting schedule.

That last step matters more than people expect. A block can read as thin canopy from imagery and still have five vacant tree pits that got skipped two seasons ago. The map tells you where cover is missing, not why, and not whether a crew can do anything about it without a sidewalk survey first.

Why block-level beats a one-off survey

Most departments still lean on a consultant canopy study done once, maybe every five or ten years, or they fall back on a citywide percentage pulled from an old land-cover dataset. Both approaches leave you guessing at what's changed since the study was done. Storm damage, emerald ash borer losses, a development boom that paved over a dozen street trees. None of that shows up until the next full survey, which might be years away.

A canopy layer refreshed on a regular cadence catches those shifts closer to when they happen, so the priority list reflects this year's gaps, not a dated snapshot from the last grant cycle. It also gives you a way to show progress against the planting target block by block in whatever report goes to council or to a grant funder, instead of defending one citywide number that doesn't move much year to year even when a lot of planting happened.

The practical upshot: treat the canopy map as the first filter in a two-step process, not the whole decision. Let it narrow a few hundred blocks down to the twenty or thirty that are actually thin, then let your field crews and GIS staff do the on-the-ground check that turns a ranked list into a planting schedule.

Urban Tree Canopy builds that block-level layer from VHR imagery on a two-year cadence, so the gap map you're ranking against is current, not a holdover from the last consultant study. If block-by-block prioritization is where your program is stuck, that's the layer worth looking at next.