Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No tiles at zoom 0 #341

Open
zerebubuth opened this issue Jul 4, 2018 · 2 comments
Open

No tiles at zoom 0 #341

zerebubuth opened this issue Jul 4, 2018 · 2 comments

Comments

@zerebubuth
Copy link
Member

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
Copy link
Member

nvkelso commented Jul 4, 2018 via email

@zerebubuth
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants