Orbit eTOG Listing Service: RFC-60 .WET FILE SPECIFICATION
Description: This is the first RFC for discussing the details of the .WET file format specification. Offshoots to discuss particular aspects are welcome.
RATIONALE:
A WET file encodes wetness in space. WET files will, in the coming days, be critical to the purchase of WET bonds, as WET bonds require proof of very specific wetness conditions for purchase.
Comments:
- Wet files should specify a voxel size in real units as well as the lengths in voxels of the X, Y, and Z axes of the volume described by the file
- What follows should be a raster of voxels where each voxel's value is the mass of water present in that voxel. Maybe the unit of mass should be specified in the header, or we can choose a standard
- Ooh there should be options for specifying data as an octree so you can have different precision in different parts of the volume
- there needs to be basis that we can extract and automatically apply to other specifications to get .foo.wet files that are semantically different. A wetation algebra
- are you measuring water mass or humidity or dew point?
- also we should support non-raster .WET data too
- .VET for vector wetness files?
- also i think the spec should be insistent that it's NOT an image
- There should be "smooth WET", a mode in which each voxel encodes a 3D gaussian distribution of water mass within the voxel
- To account for compressability of water at great pressure, which might make the more massive of two equally wet environments appear more wet, the header should optionally specify a wetgrading curve dependent on (x, y, z) indices into the volume. The curve will yield, for some indices, a scalar by which interpreted wetness should be multiplied for accurate results
- my comment about this ^ was moreso that we should think hard about what we mean by "wetness" (unless it being water mass was part of the original joke) because we might be better served by humidity; dewpoint; partial pressure; or molar fraction
Home