Should we enforce a single "z"?

[mapsam]

Once we go into the worker, we have the following information:

• lng/lat
• buffers with z/x/y

If we are looping through each buffer, we'll have to calculate the tile coordinates of the query lng/lat based on each buffer's z level. If we made the assumption that every buffer was at the same zoom level (defined outside of the tiles array) we could calculate the query tile coordinates once and essentially update their origin point according to each buffer's x/y values in the loop.

So the API would change to:

const tiles = [ { buffer: new Buffer(), x: 1, y: 2} ];
vtquery(tiles, lnglat, zoom, options, callback);

cc @springmeyer

[springmeyer]

👍 I think that all the tiles passed to vtquery should be at the same zoom level. We could either accept a z arg (like currently) and throw if any don't match, or accept the z as an arg like you've done.

As context, I think the logic to figure out which tiles to pass should live outside vtquery's async c++ function. That logic could potentially work like:

• Get the max zoom of the tileset
• Determine the tile z/x/ys needed to cover the provided radius using https://github.com/mapbox/tile-cover. Or maybe https://github.com/mapbox/tilebelt will be useful.
• If the tile count is > 9, then move to maxzoom-N until maxzoom-N results in <= 9 tiles (this strategy would avoid runaway COGS increase for larger radius, however this would need to be tested since result quality may degrade at lower zooms if the tile encoder used for a given tileset threw out tiny polygons - refs Make CleanPolygon call configurable/disable-able  mapnik-vector-tile#131)
• Pass those <= 9 tiles to vtquery, all at the same zoom level.

[mapsam]

Okay great! I agree @springmeyer that separating "which" buffers you query should be something implemented downstream. I like the idea of keeping z/x/y in the tiles array still and just verifying they are all equal.

[mapsam]

We are enforcing a single z level in the library now 👍 thanks @springmeyer!