Waterbody search (wb_window)

Flood hazard layers are built from 30 m resolution raster pixels. Each pixel stores an encoded flood level (or special values such as open water).

Flood hazard maps mark open water with a dedicated encoded value at the pixel that corresponds to your location. For many use cases you still want a landside flood signal when the building or point of interest is near the shore, so the API can look at neighboring pixels and choose a fallback value.

The request field wb_window controls how large that neighborhood is when the center pixel is water.

Allowed values

wb_window	Neighborhood	Behavior
1	— (center pixel only)	No neighbor search. The API keeps the value for that pixel as returned by the map—which for open water will return the maximum score level.
3	3×3 grid centered on the point	Search neighboring pixels for a suitable non-water value; see below.
5	5×5 grid (default if you omit the field)	Same logic, larger search area.
7	7×7 grid	Same logic, largest standard search area.

Only 1, 3, 5, and 7 are valid. If you omit wb_window, 5 is used.

What “search” means (in plain terms)

When the center pixel is classified as water on the flood layer, and wb_window is 3, 5, or 7, the service examines the square patch of pixels around that point (size as in the table). It looks for pixels that represent actual hazard levels rather than water, and uses a high representative value from that neighborhood so your scores reflect nearby flood risk rather than only “water.”

If you set wb_window = 1, that search does not run: you retain the strict center-pixel result.

When to change it

• Use 5 (default) for a balance between locality and finding a land signal near water.
• Try 7 if a point on a narrow water strip still needs a broader land context.
• Use 3 if you want a tighter neighborhood only.
• Use 1 only when you explicitly want no waterbody neighborhood substitution.

Where to set it

Include wb_window inside the location object on both the address and coordinates endpoints.