e-n-f
commented
6 years ago I'm in favor. @flippmoke pointed out that this doesn't allow the same tile data to be used from a sqlite view to provide identical data for many tiles (as in the case of the interior of a large polygon) so for those cases we should perhaps make the z/x/y optional, or allow z/minx/miny/maxx/maxy so that identical fill data can at least be used for large identical squares.
joto
I think we should add the tile x/y/zoom to layer. Now that we are planning to add the offsets and scaling factor of all other dimensions to the layer (#125) it is only consistent to also have the information needed for doing the same with the x/y coordinates.
This would allow low-level libraries to completely convert the coordinates to the end coordinates for all dimensions. (Of course if you don't want this, access to low-level coordinates should still be possible.)