No tiles at zoom 0

[zerebubuth]

When we render the job called 0/0/0, we generate tiles at the nominal zoom associated with the tile size and metatile size. For example, with 8x8 metatiles and 512px tiles, we generate tiles at zoom 2 with a nominal zoom of 3.

This means we cannot respond to requests for tile 0/0/0 because we haven't generated a tile (of any size) with that coordinate.

[nvkelso]

Is this a tilequeue issue or a new trick to teach tapalcatl?

On Jul 4, 2018, at 10:45, Matt Amos [email protected] wrote:

When we render the job called 0/0/0, we generate tiles at the nominal zoom associated with the tile size and metatile size. For example, with 8x8 metatiles and 512px tiles, we generate tiles at zoom 2 with a nominal zoom of 3.

This means we cannot respond to requests for tile 0/0/0 because we haven't generated a tile (of any size) with that coordinate.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[zerebubuth]

I think it's probably a little of both.

Here's a table showing how weird it gets if we wanted to extend the current scheme "below zoom 0".

Requested Tile	Metatile size	Metatile zoom	Requested Metatile	Requested Offset
256/3/0/0	8	3	0/0/0	3/0/0
256/2/0/0	8	3	-1/0/0	3/0/0
256/1/0/0	8	3	-2/0/0	3/0/0
256/0/0/0	8	3	-3/0/0	3/0/0

The odd thing about a -1/0/0 metatile is that it wouldn't have 8x8 256px tiles at 3/x/y, it would only have 4x4 - because there are only 4x4 tiles in the world at zoom 2. The other "negative metatiles" would be similarly underpopulated.

Since we've got "empty slots" in the 0/0/0 metatile, it seemed more sensible to re-use those - even if it does constitute a corner case. The downside to this approach is that it doesn't generalise to different tile sizes - it's abusing the offset zoom within the metatile to mean zoom when it usually means tile size.

In a world where we've got mostly 512px (and perhaps 256px) tiles, I think this makes sense. In a world where we'd have a wider range of tile sizes, then it doesn't work so well.

I've got a PR in tapalcatl-py to handle the low-zoom stuff, and I think a previous PR handles the "overzooming" case. I can't remember where we are with tapalcatl-go, but if we wanted to port these changes over, I don't think it would be too onerous.