This gets much closer to providing value over tippecanoe -- when a tile gets too big and we have to sacrifice something, we can do it by a numeric feature property.
The tile sizes aren't respected with the current implementation, though:
Added 22922 features into 7/62/39, costing 555270 bytes (skipping some features after hitting size limit)
Added 22922 features into 8/125/79, costing 555270 bytes (skipping some features after hitting size limit)
Added 22922 features into 9/251/159, costing 555270 bytes (skipping some features after hitting size limit)
Added 4570 features into 10/502/318, costing 108612 bytes
Added 22842 features into 10/502/319, costing 552732 bytes (skipping some features after hitting size limit)
Added 178 features into 10/503/318, costing 3830 bytes
Added 8897 features into 10/503/319, costing 213575 bytes
That's because only the encoded geometry counts towards the size estimate, not any properties. Calling layer.compute_size() repeatedly doesn't work either though, because it's incredibly slow to encode the protobuf constantly.
This gets much closer to providing value over tippecanoe -- when a tile gets too big and we have to sacrifice something, we can do it by a numeric feature property.
The tile sizes aren't respected with the current implementation, though:
That's because only the encoded geometry counts towards the size estimate, not any properties. Calling
layer.compute_size()
repeatedly doesn't work either though, because it's incredibly slow to encode the protobuf constantly.