Not in-memory formats to read/write

[noamross]

Possibilities:

• Raster native and other on-disk formats. If they are straight on-disk binary without compression, should be doable to write without too much effort. Probably would be much enhanced by moving to a line-by-line, rather than polygon-by-polygon. Marching squares should also be doable by reading line-by-line. Easiest to implement slices/layers first.
• Read shapefiles from a database? Would require some kind of chunking, might interfere with line-by-line above. But might be fine if we can hold the whole edgelist in memory. Would definitely want to use another library's API for generating GeoJSON, WKT or other on-disk/database output.

[mdsumner]

the first is made easier by #11 - I'm working on that outside of this project and will figure out to fold it in, you have start and end columns to fill between which you organize by tile, can write to tiles with vapour::vapour_write_raster_block or with stars/terra update mode (if they support) - cell logic is in hypertidy/vaster` (a port of the cell abstraction function from raster itself)

the second is in play with vapour reading features at-a-time, and conversion with {wk} - we have an example of an edge- and vertex-dense workflow that builds a mesh this way, a naturual way to run a very large (abstract) rasterization:

https://gist.github.com/paleolimbot/8dcddcc12e8b0c9b8efd99e124dc1e24