Make locality thinning grids smaller

[iandees]

Extending #2001 with a few tweaks to the queries.yaml arguments for the locality thinning.

The grid_width: 3 was way too small, resulting in way too few localities showing up:

Changing to grid_width: 10 results in a more reasonable number of localities:

[nvkelso]

If this is a 512 px tile size versus 256 issue, then should we try doubling the grid_width instead? Your example from 3 > 10 looks far too dense to me.

[iandees]

Sounds good. I was trying to roughly match the styled map from before thinning (where the client was doing all the thinning), and a plain doubling seemed to be missing some of the smaller localities. But here's a new round of screenshots with plain doubling:

	Before thinning	This PR as of e0fe150
z7
z8
z9

[nvkelso]

Looking good, let's see it in a build :)

[nvkelso]

Build says the numbers still aren't right.

If Tilequeue is operating on a larger window (like 4x4 grid of requested tiles), then we should we instead apply multiplier to vector-datasource for an allowlisted list of config props values (like also for kind_tile_rank)?

[iandees]

Sounds like we're happy with this most recent change. So last couple things here before we merge:

• Fix integration test 1999
• Merge the first two queries.yaml sections using gridded thinning function (for zooms z8-z9 and z9-z11) into a single range, since their values are the same

[nvkelso]

We also need to fix the config and logic so it works for both Tilequeue and Tileserver, please.

[iandees]

We also need to fix the config and logic so it works for both Tilequeue and Tileserver, please.

I haven't found a path to do that yet. I'll keep thinking.

[iandees]

After talking with Travis for a bit this afternoon we weren't able to find an approach that handles both tileserver and tilequeue. I'm going to spend the rest of the evening trying to get tilequeue meta-tile running locally so I can do some debugging and maybe find something we're missing.

The sticking point is that metatile-based builds run the functions in queries.yaml (like grid thinning) once for all the data in the metatile and the functions only get the nominal_zoom to work from. For metatile builds, that is the zoom level of the metatile that is being built, for tileserver-based requests that is the zoom level of the tile being requested (including adjustments for 512 or 256-sized tiles).

[nvkelso]

It's not obvious this is in meters... should the param name be grid_width_meters?

Is the fractional meters necessary?

[iandees]

I suppose they're not necessary, but using fractions means we get closer to exactly 3x3 subdivisions in a single 256px tile at this zoom level. If we go to integer values here, then the tiny subdivisions at the edge of the tile are slightly bigger and are more likely to get an extra feature in there.

[iandees]

Changed to grid_width_meters in 2eca280.

[nvkelso]

Is this already flexible to whole number grid_width meters? It's rounding it to an int, so maybe? If it's already padded then seems like it's fine.

[iandees]

It's rounding to an int after doing floating point math.

[nvkelso]

Two nits but otherwise LGTM and works in a QA build.