Pittsburg & Bay PointOpen map ↗

THE EVIDENCE BEHIND THE MAP

Build the case for
your next tree investment.

Find where shade investment deserves attention, test your priorities, and put an initial scale of planting beside the evidence. Here’s how each feature supports that decision.

For urban forestry, climate planning and public works · Project methods last updated September 25, 2026 (not independently reviewed)
Sources and data vintages are listed by topic.

Start here

About this study area

The city of Pittsburg and the unincorporated Bay Point community next to it, at seven times the county map’s resolution.

What it covers

Pittsburg (an incorporated city) and Bay Point (a census-designated community the county governs), as drawn by the Census: one contiguous built-up area on the Suisun Bay shoreline in east Contra Costa County. 570 ranked areas of about 0.04 square miles each, home to an estimated 89,581 people. This build was cut from the county map because the two together hold 15 of the county’s 100 highest-need areas.

What the data shows

Half of residents (50%) live in areas with under 10% tree cover and 85% under 15%; the population-weighted average is 10%, the lowest of the five builds. The highest-need areas under the recommended mix are older, flat neighborhoods near the shore (Pittsburg SE and Pittsburg NE) and the larger apartment complexes (Woodland Hills, Fox Creek, Crestview). Home air conditioning runs from 69% to 96% of homes by Census estimate. Use the list’s “Show” menu to see Pittsburg, Bay Point or the unincorporated pockets separately, and the “Stable top tier” filter to keep only areas whose top-tier place survives the rank-stability re-draws: of the 57 top-tier areas, 53% stay there in at least 80% of draws, so the shortlist here needs a field check more than most.

How it differs from the county map

Surface heat is shown but not scored, for the same reason as on the county map and measured on this build’s own cells: within the built-up area, position still explains 28% of the variation in summer surface temperature, and hotter areas here are slightly greener, not barer, because the newer hillside subdivisions are hot and landscaped while the older shoreline neighborhoods are cooler and bare. Scoring heat would reward distance from the water. Surface heat has the numbers. Residents are spread by land area within each block group, not by buildings, because OpenStreetMap has traced only 8% of the housing here (Population); a hillside or grassland cell inside a populated block group can therefore show residents it may not have.

Where the data is weakest
Population placement, as above. Cooling: OpenStreetMap tags only 8 cool places in the whole area (libraries, pools, a youth center), the same 8 the county build finds, so the routed median walk of 43 minutes is as much a map-coverage caveat as an access finding; two county-listed cooling sites are inside the area (Pittsburg Senior Center, Ambrose Community Center in Bay Point). Tree cover: 518 of 570 ranked areas use the 2022 aerial assessment; 52 on the marsh edge fall back to the 2009–2020 height model and 16 to the county’s lidar vegetation map (CDFW 2025), all labeled. Every source was checked against that lidar map; see “Tree canopy”. No 1930s redlining map exists for Pittsburg. Rank bands: the median area’s likely-rank band is 126 ranks wide out of 570.

Planning note This is a screening map from public data, built by a student and not reviewed by any city or county. Use it to choose where to look first; confirm ownership, existing trees, utilities and planting space on the ground.

Start here

From a map to a defensible shortlist

Find where canopy investment deserves a closer look, then explore the scale of a street-tree intervention.

Use it to

Turn a study-area canopy map into a focused conversation about where to invest. A city team can shortlist areas for field assessment, compare policy priorities, and estimate the scale of a street-tree program in one place.

Why this approach

We bring canopy, residents and home-cooling context onto the same grid so staff can compare areas without assembling separate maps. The workflow connects a priority to its evidence and a planting scenario.

Source & calculation details
1. Choose a ranked area. 2. Read its metrics. 3. Adjust the planting share. Use Explore to compare layers or change ranking weights. The map, list and score breakdown update together.

Planning note Use the shortlist to scope an assessment; confirm site feasibility and local costs before committing funds.

Priorities

Priority score & ranking

A relative 0–100 index of where canopy investment may be most needed in this study area.

Use it to

Build a first-round investment shortlist that accounts for both missing shade and the people living with it. Open any area to explain the drivers behind its position in a budget or program-scoping discussion.

Why this approach

An additive score makes each input’s contribution inspectable. Canopy carries the largest default share because this product prioritizes tree investment; A/C and age add resident context. Population adjusts potential reach. These are explicit project policy choices, not externally prescribed weights.

Source & calculation details
Defaults: 55% missing canopy + 25% lack of A/C + 20% age 65+; surface heat is built and movable but weighted 0 (see Surface heat for why). Inputs are scaled to 0–1; protective inputs enter as 1 − scaled value. Multiply the sum by (0.55 + 0.45 × scaled population), then rescale residential results to 0–100. The pipeline clips the low-need tail: heat and age at p2, canopy and A/C at p98; population saturates at p98. Exact endpoints ship in the GeoJSON norm object.

Planning note Scores compare residential cells within this study area; they are not health-risk probabilities or cross-city rankings.

Rank stability A rank is an estimate with a band, not an exact position. 05b_stability.py re-draws each block group’s population and residents 65+ and each tract’s A/C estimate inside their published 90% margins of error (neighbouring areas cut from the same block group move together), jitters each non-zero recommended weight by ±10 points, and re-ranks; 300 draws. The detail panel shows each area’s 5th–95th percentile rank and how often it lands in the top tier (best 57 of 570). In this build the median band is 124 ranks wide, and of the 57 top-tier areas 53% stay top-tier in at least 80% of draws. Surface temperature and tree cover are held fixed (measurement error, no per-area margin published), as is the allocation of residents within a block group. Treat rank differences smaller than an area’s band as not established (the bands are sensitivity ranges under stated assumptions, not confidence intervals or a pairwise test); use the top-tier share to shortlist.

Priorities

Presets & custom weights

Ask a different policy question and see the shortlist change.

Use it to

Test whether a proposed focus area remains a priority when staff emphasize shade, older residents or access to cooling. Use presets to structure a policy discussion instead of treating one ranking as the only answer.

Why this approach

Editable weights expose the value judgments behind a composite index. The JRC’s guidance supports examining rankings under alternative assumptions; it does not endorse our particular presets. Normalizing weights keeps their relative contribution explicit.

Source & calculation details
Recommended mix is the shipped model. Fewest trees isolates tree cover, still adjusted for population. Heat only isolates surface heat and population. Older residents emphasizes age; Homes without A/C emphasizes A/C; Far from cooling adds walking time. Most people raises the population multiplier. Input sliders are normalized to sum to 100%; the population slider changes the separate multiplier. Reset restores the defaults.

Count people more (the population multiplier)

The four condition sliders say what counts; this slider says how much the number of residents counts. Each area first gets a need figure from its conditions. That figure is then multiplied by a factor that runs from (1 − P) for the least-populated area up to 1 for the most-populated, where P is the slider. At P = 0% every area is judged on conditions alone. At the recommended 45%, the most-populated area counts about 1.8× the least. At 100%, an area with almost no residents scores near zero whatever its heat or shade, because there is almost nobody there to help. Population is normalized between its minimum and the 98th percentile of ranked areas (risk inputs run from their 2nd percentile to their maximum; protective inputs from their minimum to their 98th percentile), so one very crowded area does not flatten everyone else.

Worked example
Two areas with the same conditions score 0.60 before population. One holds 1 resident (near the bottom of the range), the other 948 (near the top). At P = 45% the first is multiplied by about 0.55 and the second by about 1.0, so they score 0.33 and 0.60: the populous area ranks well ahead. At P = 0% both stay at 0.60 and tie. At P = 90% the small one falls to 0.06.

Planning note Presets represent alternative priorities. They change rankings, not planting costs.

Data

Surface heat

Satellite surface temperature, not the air temperature people breathe.

Use it to

See the outdoor thermal context around proposed investments and compare it with canopy gaps. The separate heat view helps staff distinguish a shade-priority question from a surface-heat question.

Why this approach

Landsat provides a repeatable, spatially consistent thermal record. Summer medians reduce dependence on a single scene. Heat is shown but not scored here, as on the county map, and the reason is a measurement on this build’s own cells. Among ranked areas hotter than 35 °C (the built-up area, with marsh and water set aside) position alone explains 28% of the variance in summer surface temperature (39% county-wide, 11% in West Contra Costa): the gradient from the Suisun shoreline into the hills is most of the heat signal. And heat does not track missing shade here: it runs slightly with tree cover (r = +0.25), because the newer hillside subdivisions are both hotter and greener than the older neighborhoods near the shore. Scoring heat would reward distance from the water, not lack of trees. The layer, the sort and the slider all still work; the recommended weight is zero.

Source & calculation details
Landsat 8/9 Collection 2 surface-temperature band ST_B10, via Planetary Computer; medians of summer scenes in 2022–2024. Mid-morning overpasses sample particular clear-sky days, not the hottest afternoon or a continuous record.

Planning note Surface temperature is not air temperature or a live heat alert. Current scenes cover summers 2022–2024.

Data

Tree canopy

The share of assessed ground covered by tree crowns.

Use it to

Locate shade deficits and establish a baseline for scoping a canopy assessment. Staff can compare canopy coverage across candidate areas before choosing where to investigate street-tree opportunities.

Why this approach

The USFS/CAL FIRE aerial canopy classification targets tree crowns, which fits a shade-investment question more directly than general greenness. Equal-area aggregation preserves ground-area proportions; the assessed urban boundary defines the denominator. Validation. All 570 ranked areas were compared with the CDFW 2025 lidar vegetation map (returns above 4.6 m): the aerial product tracks it at a rank correlation of 0.82; the satellite stand-in it previously used for 16 areas had none (−0.05), so those areas now use the lidar canopy directly (“trees · lidar”). The 52 height-model areas on the marsh edge have almost no trees in either source and are left as assessed.

Source & calculation details
Primary layer: USFS/CAL FIRE California Urban Tree Canopy, 2022 NAIP aerial classification at 0.6 m native resolution. The pipeline aggregates canopy pixels in equal-area coordinates and clips denominators to assessed urban boundaries. Rural fringe uses the Meta/WRI canopy-height fallback where available. Where canopy remains missing, the pipeline retains Sentinel-2 vegetation; green_src identifies canopy versus ndvi in the exported data. The current build has 554 canopy-backed residential cells (518 from the 2022 aerial assessment, 52 from the 2009–2020 height model with tile coverage recorded) and 16 vegetation-proxy cells, all of them cells whose aerial assessment covered under 10% of the cell (canopy_quality = below-threshold), which is treated as unassessed. canopy_source distinguishes usfs-2022, chm-legacy and none; coverage_frac gives the assessed share where known. Legacy height-map tile coverage is recorded per cell (coverage_frac); every cell was read in full. The tree-canopy layer renders missing canopy in gray; the separate greenness layer covers all cells.

Planning note Canopy coverage uses aerial and height-map sources; 16 ranked cells use a vegetation proxy for scoring, labeled in cell details; an aerial assessment covering under 10% of a cell is not used. Percentages describe assessed cover, not individual trees or verified planting space.

Data

Population

Estimated residents allocated into map cells from larger census areas.

Use it to

Bring the scale of resident need into investment decisions. Population helps distinguish a sparsely occupied canopy gap from an area where a similar gap affects the surroundings of many more residents.

Why this approach

ACS five-year data supplies population, age and income on a consistent small-area geography. In Pittsburg and Bay Point the OpenStreetMap building mask failed the completeness check (2,889 mapped homes against 35,606 ACS housing units, 0.08 coverage), so residents are spread by land area within each block group instead, with cells whose dominant land cover is open water or wetland receiving none. That is a coarser placement than the building-based one used in West Contra Costa and San Ramon, and it is the reason a hillside or grassland cell inside a populated block group can show residents it may not have.

Source & calculation details
ACS 2024 five-year estimates (2020–2024), at block-group level, intersected with the study area and cells. This build allocates population within each block group by overlap area after clipping block-group pieces to the study area, so residents outside it are not assigned to edge cells. Cells whose dominant ESA WorldCover class is open water or wetland (174 of 755) receive no residents; before that rule, 3,796 residents sat on shoreline marsh and Suisun Bay. Dasymetric weighting was refused because OpenStreetMap has traced only 8% of the housing here.

Planning note Cell populations are allocated estimates, not household counts. Published ACS margins of error are carried into the likely-rank bands (see Rank stability), which hold heat, tree cover and walking time fixed and spread each block group’s or tract’s re-draw over cells by whole-cell overlap area, an approximation of the point model’s boundary-clipped, building-weighted allocation; the bands are sensitivity ranges under those assumptions, not confidence intervals.

Data

Residents aged 65+

An estimated, smoothed share of older residents.

Use it to

Bring older residents into the shortlist for shade investment and outreach planning. The seniors preset lets staff see how prioritizing this population changes the areas they would investigate first.

Why this approach

CDC identifies adults aged 65+ as more susceptible to heat-related problems, supporting age as one input. The project smooths small-cell percentages to avoid unstable extremes; the 100-person smoothing strength is a design choice, not a CDC recommendation.

Source & calculation details
Start with ACS block-group population aged 65+, allocate to cells, then smooth: (estimated residents 65+ + 100 × the study-area-wide age-65+ fraction) ÷ (cell population + 100). The displayed percentage and score use this smoothed result.

Planning note Shares are smoothed area estimates. They do not identify individual residents or their health needs.

Data

A/C access

Census estimates of occupied homes with air conditioning.

Use it to

Identify areas where limited home cooling adds a reason to investigate shade and public cooling access. This gives the investment discussion a housing dimension alongside canopy and population.

Why this approach

Census LACE combines AHS air-conditioning information with the ACS’s geographic coverage to estimate prevalence at tract scale. We chose it to use a documented, cooling-specific national product instead of treating local income rank as A/C availability.

Source & calculation details
US Census LACE 2023 AC_PE, joined by tract and aggregated using allocated occupied housing units from ACS 2024 B25003_001E. Each overlap contributes occupied homes × overlap fraction; A/C homes = that count × tract rate / 100. The cell rate is summed A/C homes ÷ summed occupied homes × 100. LACE is an experimental modeled product drawing on the American Housing Survey and ACS. The pipeline retains an income-rank fallback where estimates are unavailable; ac_src now explicitly records lace or income-model. ac_coverage records the share of allocated occupied homes with a valid LACE estimate; incomplete coverage does not become a zero-A/C observation. Every currently ranked residential cell is LACE-backed; estimates run 69–96% of occupied homes across the area, so the input carries real contrast and is scored at 25%.

Planning note Experimental tract estimates, weighted by occupied homes. It does not establish working or affordable A/C in a particular home.

Data

Walking access & potential cooling sites

Estimated walking time to a discovery site, with an official county directory alongside.

Use it to

Screen for areas where residents may face a long walk to a potential cooling facility. Use the map to focus a facility-verification exercise or a discussion about where additional relief may be needed.

Why this approach

OSM provides facility locations and a pedestrian graph in a common, reproducible source. Shortest-path routing represents mapped street connections more realistically than straight-line distance alone. This is a facility-access screen, not an emergency service directory.

Source & calculation details
The study-area file contains 8 mapped sites across library, community center, pool and senior/shelter categories, the same 8 the county build finds here: OpenStreetMap has few tagged facilities in Pittsburg and Bay Point, so walking times run long and should be read as a map-coverage caveat as much as an access finding. The walking pipeline uses an OSM pedestrian graph, multi-source shortest paths, straight-line snap distances at both ends, and 4.8 km/h. Revised September 9, 2026: streets tagged access=private (gated and private subdivisions) are now part of the graph, because residents can walk out of their own subdivision, and each cell center and each site is joined to its eight nearest network nodes with the best door-to-door total kept, so a point no longer snaps to an isolated footpath when a street is a few meters further. A cell whose only nearby network is a fragment (fewer than 40 nodes within 2 km, such as farm tracks) is treated as off-network and shows the straight-line estimate, labeled. In this study area the routed median walk for ranked areas is 43 min and 86% of ranked areas are over 15 min; no cell needed a straight-line estimate and none carries a detour-review flag. The shipped model puts no weight on walking time, so no score or rank changed. Of the 755 cells in the current overlay CSV, 755 are routed; none uses the straight-line fallback; 395 ranked areas carry an approach-review flag because the cell-to-network connection exceeds 100 m.

Planning note Verify designation, hours, fees and accessibility. Category filters change markers only; walking estimates remain based on all mapped sites.

County-listed cooling locations and phone numbers ↗

The county EHSD bulletin lists 17 designated locations and asks visitors to call for hours; two are inside this study area (Pittsburg Senior Center, Ambrose Community Center in Bay Point) and are drawn on the map, the rest are listed only. Its June 2026 revision says El Cerrito and Kensington libraries lack A/C; that exclusion is applied uniformly but touches nothing here. The directory is not an open-now feed. access_snap_m records the straight-line cell-to-network connection; connections over 100 m are flagged for approach review, without implying that shorter approaches are verified. Walking estimates still use the 8 discovery sites, not just the official directory.

Scenarios

Street planting share

Choose how much of the theoretical mapped street capacity to explore.

Use it to

Translate a priority area into a concrete program-scale question: what would planting a quarter, half or all of the mapped street capacity involve? Compare tree counts, canopy gain and indicative cost before commissioning site surveys.

Why this approach

Street length connects the scenario to a physical intervention that a public-works team can investigate. Both sides at 10 m spacing gives a transparent, repeatable capacity assumption. It is a project scenario convention, not a verified spacing requirement for every street.

Source & calculation details
Capacity = floor(mapped eligible street centerline meters × 2 ÷ 10), counting only street inside the study boundary, so an edge cell cannot offer streets outside the study area as capacity. Trees = round(capacity × selected share / 100), capped by cell area minus known aerial canopy area, divided by 40 m². With a usable whole-cell baseline, its remaining-canopy ceiling also applies. Surviving trees = round(trees × survival share), with the share editable beside the cost (default 70%). Added canopy percentage points = surviving trees × 40 ÷ cell area × 100; cost counts every planted tree. A change from 10% to 15% canopy is +5 percentage points, not a 5% relative increase. Scenarios require mapped street capacity, not 99% accuracy. Tree counts, cost, added canopy and illustrative air cooling are conditional on feasible planting and new, non-overlapping crowns. The remaining-area ceiling subtracts known aerial canopy without extrapolating partial coverage over unassessed land. A whole-cell current-to-future canopy total is shown only with at least 99% aerial coverage; otherwise only added canopy is shown. The slider starts at 25%; zero means no planting. Choices persist during unit and weight changes for this session.

Planning note Capacity is theoretical; confirm ownership, existing trees, utilities and space. Partial and unknown canopy coverage allow conditional scenarios; they do not establish a reliable future total or verified planting capacity.

Scenarios

Trees, maturity & cost

An indicative scale of investment; no financial return is calculated.

Use it to

Put an initial scale of investment beside the shortlist. A shared unit-cost and crown-area assumption lets staff compare scenarios consistently and prepare questions for arborists and procurement teams.

Why this approach

A linear model makes every dollar and canopy increment traceable to the tree count. The cost per tree is a band, not a point: no Contra Costa contract price is published online, so the app offers three sourced presets and lets you type your own. The 40 m² mature crown is a planning assumption.

Source & calculation details
Scenario cost = planted trees × the cost per tree, planting-side only; pruning after establishment, sidewalk repair and replacement are not costed. Three presets, from published California figures (September 2026): Low $500, planting only by city crews with no separate establishment budget, which is Bakersfield’s own estimate (its $500,000 budget funds “roughly 1,000 trees”); Base $2,000, planting plus about a year of establishment care, or a grant program’s all-in average (Concord’s USDA grant: $1 million for 500 trees including a plan and workforce); High $3,500, planting plus three years of watering and program overhead (San Francisco’s 3500 Trees project: $12 million for 3,500 street trees; Los Angeles Public Works reported $4,351 per tree with five years of watering in 2022). The default is the low band so older briefings and scenario files reproduce; the number you set is written into every export. Assume 40 m² of additional mature crown per tree. Canopy and cooling are credited only to the share of planted trees assumed to reach maturity (default 70%, editable; scenario files record it). That default is a planning placeholder: the US Forest Service’s monitoring of the Sacramento Shade program found 42.4% of trees alive 22 years after planting (Ko, Lee, McPherson & Roman 2015), and Berkeley and Oakland cohorts lost 34% in two years, so a program without a watering budget should test lower values. Crown area is an assumption, not a detected tree count; additive canopy assumes no overlap.

Planning note Indicative cost at assumed maturity; not a bid, lifecycle budget or financial ROI. Growth and crown overlap are not modeled; survival is an assumed share (editable beside the cost, default 70%), not a predicted outcome.

Scenarios

Illustrative air cooling

A literature-based scale estimate of possible cooling at maturity.

Use it to

Connect tree investment to cooler streets and shade where people walk and wait. Added crowns can reduce direct sun and surface heating; the air-cooling number describes a different, area-wide effect and does not capture the full benefit of standing in shade.

Why this approach

A review of urban cooling simulations estimates about 0.3 °C of afternoon air cooling per 10 percentage points of canopy under clear-sky summer conditions. We use that relationship for an illustrative scenario, separate from the satellite surface-temperature layer.

Source & calculation details
Apply 0.3 °C air-temperature reduction per 10 percentage points of added canopy: cooling = canopy gain ÷ 10 × 0.3. Krayenhoff et al. (2021) synthesize higher-quality numerical modeling studies at this approximate scale. The coefficient describes clear-sky summer afternoons, not annual average cooling or a calibrated local response. Fahrenheit differences multiply by 1.8, without adding 32. This is air cooling, not surface cooling. For example, +5 canopy percentage points gives an illustrative 0.15 °C air reduction. Research comparing tree-covered surfaces with built surfaces does not provide a transferable per-tree forecast for this cell; no surface-temperature change is currently modeled.

Planning note Literature-based illustration at maturity, not a locally calibrated forecast or a count of residents cooled.

Data

Cells, names & unranked land

Hexagons are consistent analysis units, not census blocks or neighborhood boundaries.

Use it to

Compare the same geographic units across all map layers. A consistent grid helps staff move from a study-area overview to an identifiable area for follow-up without changing the unit of analysis.

Why this approach

H3 cells give each area a stable identifier and allow different source geographies to be combined. Keeping developed and undeveloped cells visible preserves geographic context while residential-only ranking keeps the shortlist aligned with resident priorities.

Source & calculation details
H3 resolution 9, about 0.11 km² per cell; exact geodesic areas are stored per cell. Current build: 570 residential, 3 developed without residents and 182 undeveloped cells (shoreline marsh and Suisun Bay inside city limits), totaling 755. Residential means estimated population ≥ 1. Development uses OSM street-length/building thresholds. Names are approximate OSM locators, sometimes with compass suffixes. Each cell also carries the city or census-designated community that covers most of its land inside the study boundary (Census TIGERweb place polygons, step 04d); the list’s “Show” menu limits the list and fades the map to one of them, and exports carry it as city_or_community. A cell on a city line is attributed to the side holding more of its in-boundary land, at the precision of the cell itself; cells on the study-area edge are labelled by the part inside it, the same part whose residents are counted.

Planning note Cells are not census blocks or neighborhood boundaries. Place names are approximate; gray means unranked.

Priorities

What this build found

Headline numbers for Pittsburg and Bay Point, computed from the current data file.

Use it to

Open a conversation with one or two figures that are easy to check against the map, then inspect the candidate areas directly.

Why this approach

These figures use only the tree-cover and population fields shown on the map, weighted by residents so that a populous area counts for more than an empty one. They are independent of the composite score and its weights.

Source & calculation details
In this build 44,461 of 89,581 estimated residents (50%) live in ranked areas under 10% tree cover and 76,432 (85%) under 15% (aerial and height-model sources only). The population-weighted average tree cover is 9.9%; the simple average is 6.7% and the median ranked area has 5.4%. No income comparison has been run for this study area; the county guide’s earlier income headline does not apply here. Remember that residents are placed by land area here, so per-area counts are coarser than in the county or West County builds.

Planning note These are screening figures from allocated census estimates and an aerial canopy product, not a tree inventory.

Data

Historical redlining

Historical context appears only when the dataset contains usable HOLC grades.

Use it to

Keep historical context available where the data supports it, without distracting the current investment workflow with an empty layer.

Why this approach

The application checks for actual HOLC grades before offering the control. Mapping Inequality is the documented historical source; it has no 1930s map of Pittsburg or Bay Point, so this build has no graded cells.

Source & calculation details
This map file has no graded cells, so its historical heading and redlining control are hidden. HOLC data elsewhere comes from Mapping Inequality. Walking access remains a separate feature.

Planning note No HOLC layer does not imply no history of discrimination.

Using the map

Layers, units, basemaps & session state

Layers change the map view; weights change the ranking; planting share changes the scenario.

Use it to

Move from a quick shortlist to detailed exploration at your own pace. Switch layers to inspect evidence, adjust weights to test priorities, and change the planting share to scope an intervention.

Why this approach

One panel holds every control, in numbered steps, so a quick shortlist and a detailed exploration use the same screen. Units and basemaps change presentation only. Contextual guide links preserve the map in its original tab, so checking a method does not interrupt the scenario.

Source & calculation details
The panel shows priorities and a searchable area list. Search approximate place names or cell IDs and use Previous / Next 25 to browse all 570 ranked residential cells. The same panel exposes layers, presets, weights and site filters. Darker colors generally indicate greater need; tree canopy uses brown for low canopy. Gray and muted cells are unranked. Metric/imperial is display-only. Map/satellite changes background imagery. How to use reopens help at any time; the help card can be dragged, or moved with the arrow keys. Every “i” button opens a short plain-language card with a link to the matching guide topic. The panel is arranged as three numbered steps — what matters most, color the map by, places to cool off — followed by the legend and the priority list, which can be folded away; the ranked list marks how far each area moved whenever the mix is not the recommended one. Reset map returns to the zoomed-out Priority view without touching your mix. Fahrenheit and miles are the default.

Planning note Your mix of priorities and the map layer are kept for this browser tab: a reload lands where you were, and the home button returns to the start screen without resetting them. A new tab starts fresh at the start screen. Planting shares last for the current page session.

Using the map

Sorting, filtering and searching the list

Sort re-orders the Priority areas list by one measure; rank badges and the map never change.

Use it to

Read the same ranked list from a different angle: the most people first, the hottest ground first, the least tree cover first, the longest walk first. Filters narrow the list to areas that meet a threshold; search finds one area by name or cell number.

Why this approach

The rank badge is the answer to the question set under What matters most, so it stays fixed. Sorting is a reading aid, which is why the count line says what the list is sorted by and in which direction whenever it is not in rank order.

Source & calculation details
Sort options. Need: the priority score under the current mix, the same order as the rank badges. Residents: estimated people living in the area (ACS, allocated into the hexagon). Surface heat: summer late-morning land-surface temperature from Landsat (about 10:30 am overpass). Tree cover: share of assessed land under tree crowns (or the greenness index where no aerial assessment exists). Walk to cooling: estimated minutes on foot to the nearest mapped cool place along the pedestrian network. Age 65+: estimated share of residents aged 65 or older. Direction. “Most first” puts the largest value at the top; “least first” the smallest. Tree cover opens least first, every other measure most first, and either can be flipped. Filters. Walk over 15 minutes; 500 or more residents; tree cover under 10%; residents aged 65+ at 20% or more; plantable (mapped street capacity exists); full aerial tree data (drops height-model, lidar, partly assessed and greenness stand-in areas); stable top tier (in the best 10% in at least 80% of rank-stability re-draws). Filters combine, and the count line says “matching” instead of “ranked” while any is on. Areas with no value for the chosen measure sort as zero.

Planning note A sort is not a ranking. Use What matters most to change what the score rewards; use sort and filters to find areas within the ranking you already have.

Using the map

Export & reload a scenario

Take the ranked list or a single selected area into a meeting as a file that records exactly what produced it, and load it back later.

Use it to

Share a shortlist or one area with colleagues, keep a record of the weights and planting share behind a recommendation, and reopen the same view. A CSV opens in a spreadsheet; a JSON file reloads into this map. Nothing is uploaded: files are generated in the browser and saved on your computer.

Ranked list — the Export & share section

Save scenario (JSON) saves the ranked list with the full scenario header, for reopening. All ranked areas (CSV) saves every ranked cell in the order the current weights put them, one row per cell, with plain column names (see the column key below). Open a saved scenario… reads a scenario file back in and restores the weights, population weighting, any planting shares you set and the selected area; the status line under the buttons says what was loaded and whether the data version matches.

Selected area — in the area panel

Save this area (JSON) and Spreadsheet row (CSV) save one record for the cell you have open: its metrics, where it ranks under the weights in force and under the shipped defaults, the sources and coverage behind each number, and the planting scenario at the share you chose (trees, canopy gain in percentage points, indicative cost, illustrative cooling). Reloading an area file restores the weights and reopens that area.

Why this approach

A ranking only means something with its weights, assumptions and data version attached, so every export carries them: the weights in force, the population multiplier, the preset if one matches, the planting constants, per-cell source and coverage flags, and the SHA-256 fingerprint of the data file that was loaded. Reloading says plainly if the data version differs.

Source & calculation details
rank/score are computed live from the exported weights; rank_recommended_mix/score_recommended_mix are the pipeline defaults shipped with the data. Spreadsheet rows repeat the scenario header (city, timestamp, data fingerprint and version tag, ACS year, preset, population weight and the five weights) as trailing columns so a row can never be separated from the weights that produced it. JSON files add an interpretation note list and the column key. Loading checks the export schema and the city and refuses a mismatch; a different data fingerprint loads with a visible warning because figures may not reproduce. The fingerprint is computed in the browser at load and reads “unavailable” when the page is opened from a local file rather than a server.

Column key

Spreadsheet columns use the plain names in the first column; scenario (JSON) files use the internal keys in the second and carry this key as field_key.

Spreadsheet columnJSON keyMeaning
cell_ididStable number of the hexagon area
area_namenameNearest mapped place name
area_typeplaceres = residents ranked; activity = developed, no residents; empty = undeveloped
city_or_communitycityCity or census-designated community containing the area's center (Census TIGERweb places)
rankrankRank under the priorities in this file (1 = most need)
priority_score_0_100scorePriority score under these priorities, relative within the study area
rank_recommended_mixrank_defaultRank under the recommended mix shipped with the data
score_recommended_mixscore_defaultScore under the recommended mix
rank_recommended_mix_p05rank_loRecommended-mix rank, 5th percentile across re-draws of census margins and ±10-point weight jitter
rank_recommended_mix_p95rank_hiRecommended-mix rank, 95th percentile across the same re-draws
top_tier_sharerank_top_shareShare of re-draws in which the area ranks in the best 10% under the recommended mix
surface_heat_clst_cSummer land-surface temperature, °C (satellite)
tree_cover_pctcanopy_pctTree cover, % of assessed land; empty where only satellite greenness is available
greenness_index_0_100greenness_indexSatellite greenness index, 0–100; filled only where tree_cover_source_type = ndvi
tree_cover_source_typegreen_srccanopy = tree-cover map (aerial classification, calibrated height model or lidar; see tree_cover_dataset); ndvi = satellite greenness stand-in
tree_cover_datasetcanopy_sourceusfs-2022 aerial classification, chm-legacy height model, or lidar-2020 county lidar map
tree_cover_yearcanopy_yearYear of the tree-cover dataset
tree_cover_assessed_fractioncoverage_fracShare of the area the aerial assessment covers (0–1)
tree_cover_qualitycanopy_qualityfull, partial, calibrated (height model rescaled to the aerial line), lidar, or coverage-unknown
tree_cover_m2canopy_m2Assessed tree crown area, m²
assessed_area_m2assessed_m2Land the assessment covers, m²
residentspopEstimated residents (ACS, allocated into the area)
residents_65_plus_pctpct65Estimated share of residents aged 65+, %
homes_with_ac_pctac_pctEstimated share of homes with air conditioning, %
ac_sourceac_srclace = Census LACE; lace-pop = population-weighted LACE; income-model = fallback estimate
ac_coverage_fractionac_coverageShare of homes with a LACE estimate (0–1)
census_acs_yearacs_yearACS five-year vintage
walk_to_cooling_minaccess_minEstimated walking minutes to the nearest mapped cool place
walk_to_cooling_kmaccess_kmEstimated walking distance, km
walk_quality_flagaccess_qualitynetwork-estimate, approach-review (>100 m off-network approach) or detour-review (route far longer than the straight line)
walk_methodaccess_srcrouted = walked on the OpenStreetMap pedestrian network; straightline = straight-line distance times a detour factor because the area could not be connected to the network
share_inside_study_areainside_fracShare of the hexagon inside the study boundary (1 = wholly inside); residents, street capacity and the city label describe that part only
walk_network_connection_maccess_snap_mStraight-line meters from the area center to the walking network
area_m2area_m2Area of the hexagon, m²
mapped_street_mstreet_mMapped street centerline in the area, m: theoretical capacity from OpenStreetMap, not surveyed plantable space
street_room_tree_spotsstreet_room_positionsTree spots the mapped street could hold at 10 m spacing on both sides: an upper bound, not a site survey
street_room_bandstreet_room_bandno mapped street, little room, some room or plenty of room: city-relative thirds of the areas with any mapped street
planting_scenario_availablescenario_oktrue when mapped street capacity exists
tree_cover_baseline_completecanopy_baseline_oktrue when the aerial assessment covers ≥99% of the area
land_coverlandDominant land cover (ESA WorldCover) for undeveloped areas
redlining_gradeholc1930s HOLC grade A–D where a map exists
ward_idward_idCouncil ward or district number, where the city publishes boundaries
ward_nameward_nameCouncil ward or district name; blank = outside every ward
planting_share_pctplanting_shareShare of street capacity planted in this scenario, %
scenario_trees_plantedtreesTrees planted in this scenario
scenario_trees_survivingtrees_survivingTrees assumed to reach maturity (survival_share_pct in planting_assumptions)
scenario_tree_cover_gain_pointscanopy_gain_pointsAdded tree cover at maturity from surviving trees, percentage points
scenario_cost_usdcost_usdIndicative cost for all planted trees at cost_per_tree_usd; cost_scope says what that figure is taken to cover
field_check_statusfield_statusField-check status entered in the app (To visit / Checked · feasible / partly / not feasible / Planted)
field_check_notefield_noteField-check note entered in the app
field_check_updatedfield_note_updatedWhen the field check was last edited (ISO time)
scenario_air_cooling_ccooling_cIllustrative summer air cooling at maturity, °C
scenario_future_tree_cover_pctfuture_canopy_pctTree cover at maturity, % (only when the baseline is complete)
study_area_slugstudy_area_slugBuild (study area) this row was exported from
exported_atexported_atExport time (ISO 8601)
dataset_sha256dataset_sha256Fingerprint of the data file
dataset_versiondataset_versionData version tag
dataset_acs_yeardataset_acs_yearACS vintage of the data file
presetpresetPreset in force, or custom
population_weightpopulation_weightHow strongly population counts (0–1)
cost_per_tree_usdcost_per_tree_usdPer-tree figure behind scenario_cost_usd
cost_scopecost_scopeWhat the per-tree figure is taken to cover
survival_share_pctsurvival_share_pctShare of planted trees assumed to reach maturity, %
tree_spacing_mtree_spacing_mSpacing that turns mapped street length into tree positions, m
crown_m2_per_treecrown_m2_per_treeMature crown area credited per surviving tree, m²
cooling_c_per_10_canopy_pointscooling_c_per_10_canopy_pointsIllustrative summer air cooling per 10 canopy points, °C
weight_hotter_groundw_heatShare of the ranking given to hotter ground
weight_fewer_treesw_greenShare given to fewer trees
weight_homes_without_acw_acShare given to homes without A/C
weight_older_residentsw_age65Share given to older residents
weight_far_from_coolingw_accessShare given to distance from cooling

Planning note An export documents an exploratory scenario. It does not verify planting sites, costs or facility status, and it carries the same limitations as the map it came from.

Field checks Each ranked area has a Field check box in its detail panel: a status (To visit; Checked · feasible, partly feasible or not feasible; Planted) and a free-text note. They are saved in the browser you typed them in, per city, and are never uploaded. Every area and shortlist export carries them as field_check_status, field_check_note and field_check_updated, and the printed briefing shows them under each shortlisted area, so a colleague can see what was verified on the ground and what was seen. Clearing the browser’s site data clears them; export first.

Data

Vegetation greenness & supporting fields

Explore satellite greenness separately from tree canopy.

Use it to

Compare living vegetation with tree cover to identify areas worth investigating for shade. A greener area can contain grass or shrubs and still need trees; the two layers help staff ask that question without confusing greenness with canopy.

Why this approach

Satellite greenness supplies broad vegetation context across the grid, including outside aerial canopy coverage. It is publicly available in Explore, leaving the default priority workflow focused. The active planting calculator uses mapped street length, not the buffered right-of-way area fields.

Source & calculation details
The greenness display rescales the legacy veg field from 0–45 to an index of 0–100. The source linearly maps clamped Sentinel-2 NDVI 0.05–0.65 to 0–45; this is an index, not a measured vegetation fraction. Subtracting canopy from it does not estimate lawn or non-tree cover; row_m2 and row_canopy describe buffered street areas in the canopy pipeline. Current planting scenarios use street_m and whole-cell area, not row_m2. canopy_m2 is pixel-derived area for usfs-2022, and an older whole-cell percentage × area estimate for chm-legacy. Assessed extent is unknown for the latter. See canopy_source and canopy_quality before combining sources.

Planning note Greenness does not establish percent cover or planting feasibility; exported street-buffer fields do not establish ownership or plantability.

Using the map

By district

The ranking rolled up by district, with the starred areas’ planting totals.

Use it to

Answer “how many trees are we planting in District 2, what does it cost, and how many residents does it reach” in one row, under whatever priorities are in force and with the areas you starred.

Why this approach

No district source is configured for this study area yet. When a source is added the app rolls the ranking up by district and outlines them on the map. Each area belongs to the district containing its centre; areas outside every district (county islands, unincorporated land, edges) are grouped as such rather than dropped, because their residents are in the ranking. Need per district is the mean of its areas’ 0–100 index; “top 100” counts its areas among the 100 highest. Trees and cost add up the starred areas at their own planting shares.

Planning note Districts are political boundaries. The need lives where it lives; an even split across districts is a policy choice, not a finding. Boundaries and member names are re-fetched by the pipeline, never edited by hand, and SOURCES.md in the data folder records the fetch.

Using the map

Street room

How many trees the mapped streets in an area could hold, drawn as a layer and read as a word on every row.

Use it to

See need and feasibility together. An area that needs shade and has plenty of street room is an early win; one that needs shade and has little room needs parks, schoolyards or private planting instead, and should be planned differently rather than dropped.

Why this approach

Street room is the number of tree spots that the mapped street centrelines inside the study boundary could hold at 10 m spacing on both sides. It is the same ceiling the planting scenario starts from, shown directly. Streets come from OpenStreetMap; utilities, driveways, sidewalk width and existing trees are not known, so it is an upper bound, not a surveyed count. The words “little”, “some” and “plenty” are thirds of this study area’s ranked areas that have any mapped street; “no mapped street” means none inside the boundary. On the map, deeper colour means less room, keeping the rule that deeper always means more need.

Planning note Street room is a planning screen for where to look first, not a count of plantable sites. A city’s own right-of-way, utility and sidewalk layers turn it into a planting plan; ask public works for them.