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

[FEATURE] Support zoom-levels higher than 14 #128

Closed
msbarry opened this issue Mar 8, 2022 · 5 comments · Fixed by #303
Closed

[FEATURE] Support zoom-levels higher than 14 #128

msbarry opened this issue Mar 8, 2022 · 5 comments · Fixed by #303

Comments

@msbarry
Copy link
Contributor

msbarry commented Mar 8, 2022

Planetiler currently limits the maximum zoom level to 14 since that was the highest needed for the OpenMapTiles port. Other schemas may want to go higher though. It should at least be possible to go to z15, and possibly z16.

@msbarry
Copy link
Contributor Author

msbarry commented Mar 8, 2022

The main issue to resolve to go higher than z14 is how TileCoord packs z/x/y coordinates into a 32-bit integer:

// since most significant bit is treated as the sign bit, make:
// z0-7 get encoded from 8 (0b1000) to 15 (0b1111)
// z8-14 get encoded from 0 (0b0000) to 6 (0b0110)
// so that encoded tile coordinates are ordered by zoom level
if (z < 8) {
z += 8;
} else {
z -= 8;
}
y = max - 1 - y;
return (z << 28) | (x << 14) | y;

So that the tile coordinate can be used as the most-significant 32-bits of the 64-bit long key that features get sorted by to group into tiles:

static long encodeKey(int tile, byte layer, int sortKey, boolean hasGroup) {
return ((long) tile << 32L)
| ((long) (layer & 0xff) << 24L)
| (((sortKey - SORT_KEY_MIN) & SORT_KEY_MASK) << 1L)
| (hasGroup ? 1 : 0);
}

There are 1.4 billion tiles <=z15 so it should be possible to pack them into a 32-bit integer, but since there are 5.7 billion tiles <=z16 we'd need to steal one bit from another part of the sort key so that we have 33 bits available for the tile ID.

@msbarry
Copy link
Contributor Author

msbarry commented Jun 21, 2022

@ZeLonewolf what do you think about z15 vs. z16 as the upper limit for tile generation for "micro-mapped" features?

bdon added a commit to bdon/planetiler that referenced this issue Jun 21, 2022
@ZeLonewolf
Copy link
Contributor

ZeLonewolf commented Jun 21, 2022

@ZeLonewolf what do you think about z15 vs. z16 as the upper limit for tile generation for "micro-mapped" features?

With regard to feature utility in a map, there are lots of features that don't make sense to display until very high zoom. If I were rendering manhole covers for example, I'd probably start them at z19 😁

Is there a technical reason why we wouldn't make the maximum zoom level user-configurable? It's really just a trade-off between disk space and download tile size.

@msbarry
Copy link
Contributor Author

msbarry commented Jun 22, 2022

@ZeLonewolf what do you think about z15 vs. z16 as the upper limit for tile generation for "micro-mapped" features?

With regard to feature utility in a map, there are lots of features that don't make sense to display until very high zoom. If I were rendering manhole covers for example, I'd probably start them at z19 😁

Is there a technical reason why we wouldn't make the maximum zoom level user-configurable? It's really just a trade-off between disk space and download tile size.

A few reasons to limit:

  1. We're packing feature sort keys into 64 bits and tile id into a 32-bit integer now, which can fit z15 but to go to z16 or beyond we'd need to adjust. Not impossible but only want to do it if there's a strong use case
  2. output mbtiles size is currently ~80gb, it would be 200-300gb for z15 and close to 1tb for z16 so it starts to get unwieldy
  3. processing time goes up by similar multiples

Since a client-side style can limit showing some feature until a higher zoom level, the only real benefit to generating higher zoom levels is to limit tile size of the max zoom level you generate. Currently with the openmaptiles config, the biggest z13 tile is 366kb but a few z14 tiles get up to 1.8mb. If you include more detailed poi's/trees that might push 3-4mb.

So maybe the best way to guesstimate this is to make a schema with all the "micro" features you might want to include in openmaptiles, then generate z14 and collect some stats on the avg/max bytes used per layer per tile to know how far we'd need to push down the micro features to make tile sizes reasonable.

My hunch is z15 would keep tiles under 1mb, and z16 would keep max zoom tiles comparable with the rest of the tiles (200-300kb max)

@ZeLonewolf
Copy link
Contributor

I'd say z15 is the most important because of the openmaptiles plan to add that zoom level, while we don't have a specific use case for z16.

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

Successfully merging a pull request may close this issue.

2 participants