Closed iandees closed 2 years ago
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 |
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
)?
Sounds like we're happy with this most recent change. So last couple things here before we merge:
We also need to fix the config and logic so it works for both Tilequeue and Tileserver, please.
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.
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).
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: