v1 spec that hit a wall due to me having my numbers of a bit (performance was impractical)
-
tiles are processed and put into a leveldb store
-
downloaded tiles are cached
-
each z15 vector tile's geometry is encoded as z25 tile voxel equivalents
-
./process --bbox w,s,e,n -
runs tile-cover on the bbox at the specified zoom
-
gets a vector tile for each tile in the cover -- downloads and saves if necessary, or reads from disc
-
for each voxel (a z25 tile) within the bbox, run point in poly against the features in the enclosing z15 tile
-
repeat step 4 with a custom rendering function for each feature type (trees, landcover, buildings, etc.)
-
scanline raster aliasing will be drastically faster than point-in-poly for each voxel
-
this will be multiple scripts
-
scripts should be able to incorporate previous transforms such as elevation processing
-
rendering will use onMissingChunk and perform a simple match against leveldb for each voxel
-
position is all relative to 0/0/0 (starting out with hight tiles leads to perf quirks in voxel.js)
-
user will have to specify the bbox they want. It's not ideal, but the performance for processing z15 vector tiles into z25 geom is just not fast enough.
-
depending on how fas processing is, it might make sense to allow for background processing for tiles in the distance, but we can set it aside for now.
for now everything is meant to run on one machine, but eventually this could be split out
-
hapi server to serve the client, query the db for voxel chunks, etc.
-
client that uses voxel.js for rendering
-
leveldb for storing voxel values
-
processing scripts that take VT data and apply it to the voxel store
-
storage is kept simple in a leveldb store on the same server as hapi
-
index is an xyz in the form: '121/432/13'
-
voxels will probably be stored in chunks
-
storage is persistent, and incremental updates should be possible
-
each item will look something like '121/432/13': 3 << where 3 is a material type