On Wednesday, May 12, 2010, at 07:31PM, "Tom Browder" <tom.browder@...> wrote:
>Well, in AJEM the "air code" as an integer can have various values to
>indicate various types of air for compartments. Here is an extract of
>Table 5.4.1-1, "Air Code Associations for Ground Mobile Vehicles," in
>the AJEM User/Analyst Manual, Version 2.18:
Okay, that's actually what I thought and matches how it's used elsewhere. The docs I summarized from had it wrong, hence the mixup.
That said, 'aircode' is one of those non-geometric properties that would be nice to get rid of (i.e., let applications set their own analysis-specific attributes), but it's actually a number that affects behavior. Regions marked with a non-zero air code get treated differently by the boolean evaluator, ray tracer, and tree walkers.
Line of sight equivalence is another one that would be good to get rid of or -- even better -- generalized, but it shouldn't be changed until we have parametric equation support completed. With parametrics, we could define a region that represent non-uniform densities and response curve behavior (e.g., instead of los=0.4, maybe los=COS(t) or los=x^2+y^2-t, etc). Alternatively, with material objects, support for air could be merged in there with similar properties.